Zanzlanz

Sorry about the super long delay! :)

---

It's a great question, and I honestly think there's no right answer to it. It depends on a lot of things, including how comfortable you are working with a team. Some people work way more efficiently on their own, and others really succeed when they have a team.
Teams work well if everyone can contribute their own expertise to the project - something orthogonal to the abilities of the others. The personalities in the team should meld together well too, otherwise conflict will happen and the project wont work out in the end. It's usually not worth drama.

---

If you're a programmer, working with an artist and musician usually is a great idea, because they're very different aspects to a game. Everyone will feel like they're contributing meaningfully to the project in a creative way.

---

Personally I like working alone, because I have full control over the project vision. I do like outside feedback, but only when I'm ready for it, in a way.
Especially if I'm not sure if the project will succeed or not, I don't want to drag anyone else into a project that can fail and disappoint them. If a project fails, I don't have to worry about anything other than the lost time.
Because of this, I wear a lot of hats - I do the programming, art, music, and deployment of the stuff I make. I enjoy it, but many people would find it tedious and pointlessly time consuming versus just working with actual artists/etc.

---

Specifically working with more than programmer is tough for me, because it means source control, documentation, and organizational standards. It would set me back trying to make the code super easy to understand for other members. That's just me though, some people thrive in that environment. And some projects don't even require people to all code in the same parts of the project at once, which is ideal.

---

But yeah in general, I start all projects on my own until I know they need outside help. If they do, then I might go an rally up some talented friends to do art/music. I find it the least risky way to casually work on projects :D

---

It really depends on who you are and the resources the project needs.

View more

It depends on your "business model": type of game, target platform(s), and target audience.

---

People aren't really going to question ads in web and mobile games, especially if they're getting a quality game for free. A lot of people are uneasy about purchasing things though, and will complain if something is priced higher than $0.99 haha.

---

But usually if you intend to make money from a desktop game, you may have to come up with a fair price that the players expect. In most cases, advertisements are simply unwelcome in desktop games.

---

Either way, many games will have options to purchase cosmetics, in-game currency, and... well, DLC. So it's totally possible to make a game for free, with no ads, but still make a good amount of money on a community, if the game is good.

---

Personally I love to be able to provide my games for free, whether they have ads or not. It means more people get to play it, instantly. This wont always be the case, but it's what I prefer.
Instead of making some features paid additions, ads are really simple to set up and don't come with problems of tracking transactions and dealing with insecure or lost credentials. Also, there are no worries about relying on a platform like Steam or stuff like piracy.

---

For fun, here's some considerations: There's also donationware games (Patreon is a modern way to make this work), merch-driven monetization, YouTube/Twitch marketing monetization, and even simply selling game assets or soundtracks.

---

So yee, it's definitely a case-by-case situation! :)
Default to what you're comfortable with, and build up on what is reasonable to sustain the game's resources and its development.

View more

Considering Android natively runs on Java, you'll probably get the best performance with that. The big limitation compared to the other option I have is you can't make it a web game. At least until we see what WebAssembly can do...

---

Unity, Haxe, JavaScript, and ActionScript can all be used to make games on all the platforms you're interested in, so it's a lot about what is most convenient for you.

---

- With Unity you get an easy interface for making games. I don't like how difficult it is to control at a fine level though. It's too high level in a way. But the industry has really accepted it and provided tons of community support. If you're willing to work around the issues, it's a fine option.

---

- I haven't dug too deep into Haxe yet, but it does take a bit of research and learning to be able to support all the platforms you want. You'll probably want to use a library like HaxeFlixel to make creating your game engine easier (this is like the LWJGL of Java). However it's also based on ECMAScript, so if you know JavaScript well, it wont be too hard to pick up. I think this is a workable option for someone like you.

---

- JavaScript is great for web-based development for sure. But to make native apps there's a lot of consideration on a separate framework to support it. You can make cross-platform native apps and games with NW.js apparently. JavaScript might not be your first pick if you want to publish natively to platforms.

---

- ActionScript can make Adobe AIR apps, which run on mobile and desktop, as well as Flash for web. I'd say that the support is awkward, and probably not a good choice for making a complex game right now.

---

- One I haven't mentioned yet is GameMaker Studio! This is also capable to compiling to any platform you might want. I know pretty much nothing about this program, but the industry has benefited from some really great games made with it. Might be worth exploring!

---

There are pros and cons to each for sure. Hope maybe that gave you some context!
I'd say, either stick with Java, or check out Haxe, Unity, or even GameMaker. The other options are great for smaller games, but require you to have a different business model. Not sure if that's what you want ^^

View more

Of course, with multiplayer games, you must always have Internet, whether or not it is a browser game. So I'll assume this is all about single player games :)

---

Browser games can usually be run without the Internet being on. In most cases, a developer can release a desktop version with basically no issues. Specifically, JavaScript (HTML5 games) can run on all operating systems as a browser script or a desktop application, all modern browsers, on tablets, most modern mobile phones (in a browser and in an app). The same code is fairly universal, giving the biggest audience for a game developer.

---

Desktop games can usually only run on the platform they're developed for - Windows, Mac, and sometimes Linux. It takes extra effort and build resources to compile versions for mobile apps and web, if even possible.

---

There are a ton of exceptions to both of these of course.

---

One major flaw with web games is they are not as technologically advanced. Graphics support is really minimal currently, making games look bad and run slowly compared to what is possible with native desktop games.

---

Another downfall is it is often very easy for players to view and alter the source code of web games. They are more vulnerable from a security aspect, which is less of a problem with desktop games. This also makes web games rely on ads or subscriptions, because you can't really sell a web game if the source code can easily be seen.

---

So mainly, the way I see it is if you work within the thinner limitations of web and mobile technology, you can release games pretty much anywhere, as long as the controls still make sense ^^ just, you don't have super fancy technology, have to use small file sizes, and have to have a different revenue model.

---

Those are my thoughts about that topic at least :3

View more

Java's great! Have you tried LibGDX?

---

I was making games many years prior to Mine Blocks, it was not my first project. It was actually my 3rd attempt at making a block-based mining game. The two first attempts didn't result in anything, and they were somehow deleted from my computer. But the world generator from the second one became the basis of Mine Blocks. It's also where the spinning diamond on the main menu came from! :D

---

But yes, I made dozens of tiny random games before Mine Blocks. :)

---

ActionScript is technically free on its own. But if you want to code games within Adobe Animate (Flash), yes it is the price of Adobe's Creative Cloud subscription, which can be really expensive. You can make ActionScript games without using Flash though.

---

ActionScript is based on the ECMAScript specifications, so it is incredibly similar to JavaScript. It has explicit type definitions and formal classes. For a while I was saying it's somewhere between Java and JavaScript on the spectrum of language features.
In terms of benefits, it's so easy to make a prototype with it. There's basically no setup required to make a window, and there are so many right ways to use it, making it convenient, no matter what style of programming you like.

---

But right now I'd like to make games in either JavaScript (which owns the web and even mobile these days), or Haxe (which is a language inspired by ActionScript, that can compile to a ton of other languages and platforms). They have their own set of benefits. I especially appreciate how JavaScript game development continually improves as web technologies evolve. JavaScript is so flexible - I'm making servers, applications, games, and websites all withe one language... how awesome is that?

---

Oops, I answered way more than I needed to again xD! Hope it was interesting!

View more

Great question :D It's similar to the one I just answered before yours, about modding.

---

When block properties are general, such as name, color, material, and flammability, for example, they all fall under the blockData structure, which is a massive table of all blocks and items.

---

Let's take a pumpkin for example (hopefully this looks okay without code formatting):

---

blockData["pk"] = {
name: "Pumpkin",
identifier: "pumpkin",
tool: false,
mining: {WoodenAxe:25, StoneAxe:25...},
isWood: true,
pistonDrop: true,
flammable: true,
flamRate: 700,
shiftClickBlock: true,
placeable: true,
endermenCanChange: true,
color: "orange"
}

---

"pk" is the identifier I refer to in the code whenever I want to access the block data. I have a function (getBlockData(id, property)) that will retrieve the block's information easily and still handle any errors, in case a block doesn't exist or something.

---

But as you can see, each block can have a ton of properties, and it's super easy to add. I can set something to "stairBlock" or "halfBlock" and it will be treated like stairs or slabs for collision.

---

Now when the behavior of the block is unique, you'll often find it doesn't have a property. Slipperiness and bounciness haven't yet been converted to block data, for example. Currently the system just asks if the block underneath is an ice block, and if so, make the player (and mobs/items) slide.

---

There's a whole set of behaviors for each block that happen every frame. Or when you place it, break it, or shift-click it. These behaviors are currently scattered throughout the program, a lot of it being directly on a giant "block type" MovieClip which contains instances of all the blocks you see in the world. It's a mess, and everything will eventually be moved to the main code (that'll be in the two updates after 1.29, actually!).

---

:3

View more

Maybe!! It's a bit tricky to make an entire game data-oriented, but there's definitely a good level of flexibility with blocks, for example.

---

I'll get a bit technical with this, so sorry if it's confusing :3

---

As you may know, I'm still re-coding Mine Blocks to separate logic from the rendering, which makes it more data-oriented (think of it like... loading a simple text file to determine was properties each mob has, or what color a block is). Right now I'm doing this conversion to mobs.

---

Let's take skeletons and zombies. They're very similar, and run on the exact same logic now.
However, skeletons have "attackProjectile" enabled and "attackContact" disabled, and that's mostly how their behaviors differ. Skeletons can now shoot projectiles, while zombies can only attack by hitting you. This change is a simple thing that can turn on and off for each type of mob.
They also have different sound effects, animations, and item drops. These are just lists of data that can easily be swapped out during the game, making it extremely easy to "mod" the sound effects of zombies to sound like skeletons, or make all zombies drop 100 lemons when they die. xD
So essentially, a mod would simply be adding a new mob that swaps these various behaviors. It's totally possible to make a creeper that sounds like a wolf, shoots snowballs rapidly, drops diamond pickaxes when it dies, and is only hostile to spiders...

---

Apart from mobs, this type of system can be applied to blocks, items, player actions, visuals, and so much more. And as soon as you open these systems up for any player to be able to edit, you end up with a modding API!

---

The one huge limitation right now with a modding API is that it would not be able to support custom code. So, you couldn't make creepers do backflips unless it was officially supported as a mob behavior. If every aspect of the game could be generalized and dynamic, it could have a separate parser for modding which would be a "Mine Blocks Programming Language" in a way. This is what commands in Minecraft are turning into, and I intend to continue making commands more complicated in Mine Blocks to add similar features.

---

And maybe some day I can be able to get around these complicated limitations by porting Mine Blocks to JavaScript, which allows an "eval" function (it can run code that was passed to it as a text file, during the game).

---

These issues would apply to both Mine Blocks 2 and 3 as well. It depends what programming languages they'll end up being written in. It'd be really great to design both of them to be fully moddable - it's better to start designing that early, which is super helpful. Mine Blocks has been hard to work with because it was not designed to be flexible like that. With every update, it's been improving a ton though. xD

---

That was WAY more than you wanted to know! :D But hopefully it was interesting!

View more

I don't! I find that Perlin Noise is too hard to fine tune and control for situations like seamless biomes, cliffs, and other very specific scenarios.

---

For Mine Blocks 1 it just keeps track of a slope variable and linearly traverses the whole world when it generates.

---

For Mine Blocks 2, each world genchunk (worth one biome of size, but encompasses half of two adjacent biomes) calculates a start and end height depending on the biomes (this is sort of like Perlin noise, sure). Here's what it looked like in its early stages:
http://zanzlanz.tumblr.com/post/43397340027

---

But then, for the hills, it uses a stacking and removal technique I "invented" here: https://www.youtube.com/watch?v=e7Dwh9U71lM and first implemented it into this thing: https://youtu.be/3thB8uQ-H6I?t=21s

---

So I guess MB2 *effectively* uses one layer of Perlin noise and fills it in with a custom algorithm :D

View more