Hello,

I've been making mods (modifications) for the game Minecraft for about a year and a half now, and am interested in starting up my own project (a simple game). I just have a lot of questions before I jump into anything first:

1) 2D or 3D? It seems to be a lot easier to make a 2D game rather than a 3D game because it eliminates a lot of tedious work, but would it be best to start out with a 2D game, and eventually turn it into a 3D game?

2) What language? I would prefer Java, and would like to make a game in Java (as it is my first, and really only language), but I've heard it isn't that powerful and can be limiting at times.

3) Engines. I'm not too familiar with game engines, but is it easier to use an existing one (and have to learn that engine), or to build your own? I would like to build my own, but I know it may be a bit tricky and time consuming.

4) What are some general steps to making a game? For example, what obstacles should be tackled first?

If someone could answer these, that would be awesome!

Best Regards,
TheXFactor117

1) 2D or 3D? It seems to be a lot easier to make a 2D game rather than a 3D game because it eliminates a lot of tedious work, but would it be best to start out with a 2D game, and eventually turn it into a 3D game?

2D is generally easier.. but that's mainly due to the fact that people usually make much simpler games in 2D than 3D. Either can have great complexity and in general most of the deep down systems will be almost identical between the two.

But 2D is usually better to start with because it removes some of the burden from you, 3D does add some concepts to things like how objects interact, collision detection, physics becomes an issue.. things like that. The main point to make is that if you learn 2D first a lot of the concepts you get to practice there will transfer to 3D as well.

2) What language? I would prefer Java, and would like to make a game in Java (as it is my first, and really only language), but I've heard it isn't that powerful and can be limiting at times.

The golden question!.. the answer being.. it depends. If you said you were just getting into college and wanted to work at some big AAA company when you graduate I would probably highly push a language like C++, but since you're just making games to make games and you already have experience with Java, you could certainly use it.

Java is in general, going to be slower than the ideal C++ implementation. I'm sure someone will disagree but that's kind of a point to get out of the way. But with that said, that probably won't even become noticable unless you were making a very complex game, like a 3D fps with all kinds of fancy rendering and such where dealing with memory could be make or break for your game.

Basically.. use what you want to.

3) Engines. I'm not too familiar with game engines, but is it easier to use an existing one (and have to learn that engine), or to build your own? I would like to build my own, but I know it may be a bit tricky and time consuming.

Again, it depends. As far as I know there aren't really any full "engines" for Java that are wildly available, stuff like slick is more like a framework library. It's definitely better to use a library like that than to start from scratch, trying to learn to make every little thing at once is just asking for failure. If you make multiple games you'll begin to naturally learn how each subsystem works and how you could make your own implementation anyway.

4) What are some general steps to making a game? For example, what obstacles should be tackled first?

Sit down and think about what you want to make, even if its just sitting there with notepad and typing out the game idea and the different parts, I find this makes you think about a lot of things that you would forget otherwise. The nitty gritty details of how to make your game communicate internally can be nightmarish, like figuring out how you want to split the game up into screens, how screens will communicate with each other, what kind of data you need and how to load it.

Number one rule I've found though.. don't overengineer, pretend someone hired you to make the game you have in mind and sit there and think "how can I reasonably reach this goal, what tools will my code need before I start fleshing it out." Stuff like that.

1) 2D or 3D? It seems to be a lot easier to make a 2D game rather than a 3D game because it eliminates a lot of tedious work, but would it be best to start out with a 2D game, and eventually turn it into a 3D game?

2D is generally easier.. but that's mainly due to the fact that people usually make much simpler games in 2D than 3D. Either can have great complexity and in general most of the deep down systems will be almost identical between the two.

But 2D is usually better to start with because it removes some of the burden from you, 3D does add some concepts to things like how objects interact, collision detection, physics becomes an issue.. things like that. The main point to make is that if you learn 2D first a lot of the concepts you get to practice there will transfer to 3D as well.

2) What language? I would prefer Java, and would like to make a game in Java (as it is my first, and really only language), but I've heard it isn't that powerful and can be limiting at times.

The golden question!.. the answer being.. it depends. If you said you were just getting into college and wanted to work at some big AAA company when you graduate I would probably highly push a language like C++, but since you're just making games to make games and you already have experience with Java, you could certainly use it.

Java is in general, going to be slower than the ideal C++ implementation. I'm sure someone will disagree but that's kind of a point to get out of the way. But with that said, that probably won't even become noticable unless you were making a very complex game, like a 3D fps with all kinds of fancy rendering and such where dealing with memory could be make or break for your game.

Basically.. use what you want to.

3) Engines. I'm not too familiar with game engines, but is it easier to use an existing one (and have to learn that engine), or to build your own? I would like to build my own, but I know it may be a bit tricky and time consuming.

Again, it depends. As far as I know there aren't really any full "engines" for Java that are wildly available, stuff like slick is more like a framework library. It's definitely better to use a library like that than to start from scratch, trying to learn to make every little thing at once is just asking for failure. If you make multiple games you'll begin to naturally learn how each subsystem works and how you could make your own implementation anyway.

4) What are some general steps to making a game? For example, what obstacles should be tackled first?

Sit down and think about what you want to make, even if its just sitting there with notepad and typing out the game idea and the different parts, I find this makes you think about a lot of things that you would forget otherwise. The nitty gritty details of how to make your game communicate internally can be nightmarish, like figuring out how you want to split the game up into screens, how screens will communicate with each other, what kind of data you need and how to load it.

Number one rule I've found though.. don't overengineer, pretend someone hired you to make the game you have in mind and sit there and think "how can I reasonably reach this goal, what tools will my code need before I start fleshing it out." Stuff like that.

Thanks for the information.

I've been doing some more research about it, and I'm kind of leaning towards making a simple 2D Java game using Slick2D / LWJGL. However, the kind of game I want to make is something similar to Terraria / Minecraft (but dialed down a lot [less content]). What would I need to do to incorporate this?

I've been doing some more research about it, and I'm kind of leaning towards making a simple 2D Java game using Slick2D / LWJGL. However, the kind of game I want to make is something similar to Terraria / Minecraft (but dialed down a lot [less content]). What would I need to do to incorporate this?

Nothing else you "need" necessarily, it would be very specific to your game. At its core a game is really just code running a simulation of some kind, taking input from the physical computer and translating it into changes in the simulation. Game libraries like Slick tend to give you the tools you need to more easily communicate with each thing. I.e. they abstract away rendering and give you some texture classes that you can just load with data and tell some rendering class to draw it.

I will warn you that making a game from scratch is a wholly different experience to modding one, you can make some really cool seeming mods and not even know how to make a pong clone if you don't know all the basic subsystems and how to string them together. Best advice I could really give if you're using something like slick would be to get it set up, go through the documentation and familiarize yourself with the library before you start throwing things together.

There's not really any roadmap to making a game usually, most of what you learn will be "okay, I want this to happen in the game now, how do I add it?" That will naturally lead you to look things up usually.

If you are making a simple game, almost any language will do.

Since you know Java sticking with Java will be a whole lot easier that attempting to learn C++ along with Open GL or Direct X (whatever version is out now) .

You don't even need a game engine, or third party libraries, as the built in Swing library has all the tools necessary to make a good 2D game.

First you need to take BABY STEPS ... try making a "game" were square moves around the screen avoiding falling squares ( Experienced Java programmers can do this in under 10 minutes without external libraries ) .

Next you can try your hand at random "world" generation with ASCII characters representing various landscape elements.

From there add in basic "MineCraft" elements of mining rocks, chopping down trees, inventory, e.t.c. .

Next refine your world generation to include rivers, biomes.

Now is a good time for a crafting system.

Next add in mobs and path finding.

Now comes a basic combat system and skills .

You'll probably at this point want to include some kind of network programming for multi player.

Next, tweak your entire game engine to run more efficiently, and improve world generation.

Now comes the point in time to replace the ASCII graphics with actual art.

From this point, continue to improve your engine, add in features, and listen positive criticism .

Edit: I have my own top - down engine I have been working on for a while now ... kind of looks like Dwarf Fortress ( adventure mode ), but played over a network . I managed to have a working version completed in 8 months - however the final version will probably take years if I continue work .

1) 2D or 3D: this is now highly subjective, and you need to look at it from different perspectives.

Art cost:

from my dabbling in art I can tell you, depending on the game you are building, art can get more "expensive" for a 2D game than a 3D game quickly.

This comes down to the way high quality animations are done in 2D Games, which will need you to redraw the moving sprites for every frame. Granted, an expierienced artist might not have to redraw the comple sprite, might split sprites into parts to save time and image size, and so on.

Fact is: a well built and rigged 3D Object can be animated any way you see fit.

Now for the flip side: creating a good 3D Object takes time, even for a simpler one (you have to work from all 6 directions instead of just one for 2D. You can use mirroring and other tricks, still, more to model and texture). Rigging (setting up the model for animation) then will also use up a good chunk of time.... and animation will again eat up a lot of time.

So, just as art cost in general, the question wheter 2D or 3D art is more expensive comes down to complexity. It is much easier creating 2D art for a graphically simple game. 3D art has some overhead cost because of the third dimension and the way animations are done.

Even if you go fully cheap with no animations, you still need to create your art in 3 Dimensions instead of 2 (Arguably, if you do a "Thomas was alone" clone in 3D, art budget would not go up much... just level and game design would be much harder to do )

Engine / Low level Programming:

Now I lack extensive expierience in these fields, but you can be certain that programming a fully blown 3D Engine is MUCH harder than coming up with a simple 2D one. The third dimension makes a lot of the calculations needed much more difficult, you will have to use heavier frameworks to get any graphics going, and so on. This is IMO why a lot of people claim 2D Games to be easier to do than 3D games.

Using Engine:

If you use an existing engine, the question about 3D or 2D becomes mainly a game design / art cost one. Do you really NEED 3D? Will your game NOT work in 2D?

You still need to come with a plan to reduce your art cost to a minimum that will still work with your game design (do you really NEED animations? Do you really need organic creatures? Can you go with an abstract art style (see "Thomas was alone")?).

And you will still face some added complexity for 3D games (having to calculate a projectile trajectory in 3D IS harder to do than in 2D Space).

But more or less, you better go with what you know (if you are expierienced in creating 3D models but suck at drawing, choice is easy), or what you can afford (getting small unanimated pixel art 2D assets will be much cheaper than even simple 3D models), or what will be more useful to your game idea (you need an isometric view with fully animated characters? Think long and hard why you want to go 2D... ).

Commercial 3D Engines generally cost more, 3D models generally are a little more time intensive to produce, and level / game design in 3D space is a little harder to pull off. But as soon as you cut out the low level plumbing, it is not leagues apart anymore. And then as complexity of graphics rises, 2D Graphics budget explode. Ther is a reason why you rarely see isometric 2D spites being used anymore (at least AFAIK)... usually it is used in throwback games that want to tap into fond memories of the big 90's classics.

2) Language choice:

AFAIK, you will see people promoting them all. Don't expect Java or Python to be as much hyped as C++ is in the Game dev world. Also don't expect it to perform the same as a well written C++ program.

But as long as you are not looking for max performance, you are free to use any language you like to write your game, as long as it compiles for your target platform.

Now, you will find there are a lot of people using Java for game dev, it is the standard choice in the Android world AFAIK, and there are even some big Indie engines built around Java (JMonkey Engine for example)

IF you decide to go with an Engine though, I would advise you to not base your choice of Engine on the language it supports, but your choice of Language ond the language your engine of choice supports.

The really big, good Engines that are affordable for Indies out there support C++ (Unreal) or C# (Unity), a lot of the smaller Indie Engines are building upon C++, so your choice in Engines will get quite limited if you are not ready to learn a new language.

Also, coming from Java, you should be up to speed with C++ or C# in an existing Engine in no time (especially as the engine API is proprietary anyway, and a lot of the language specific oddities might be hidden by the engine framework (like memory management in C++ for example)).

3) To write an Engine or to write a game:

IF writing an engine is what you want to do, concentrate on that. The whole topic is fascinating, and if you are only really interested in programming as opposed to also doing art, level- and gamedesign, creating your own engine is a worthy project.

Don't expect to be able to write anything sellable quickly. The market for engines is oversaturated, the big boys are racing the prices to the bottom (good for Indie game devs, bad for Indie Engine devs), a lot of the small Indie Engine developers are struggling to make a dime from their engine they developed over ten years sometimes. You might be able to come up with a good niche engine. Still, with engines being pretty much jack-of-all-trades nowadays, differentiating yourself becomes a problem.

IF creating a game is your target, the scale of your game should dictate if you start from scratch or use an existing engine.

Want to create a simple 2D game (like tetris)... almost any engine will be overkill, and add an overhead to your performance cost.

Want to create a mid complex 2D game or simple 3D game: Only start from scratch if you are REALLY interested how it will work low level, or you are really expierienced and want to squeeze out that last bit of performance that an existing engine might eat away.

Anything more complex: Don't even try to re-invent the wheel. A lot of very expierienced devs poured many years of dev time into the existing engines. Choose the one that fits your needs best, tailor it if you need to (and have access to the needed source / plugin system), and start working on your game ASAP instead of wasting time trying to come up with a very complex engine that might take you years just to understand all the moving parts you have to come up with.

About Engines:

The big 3D ones in the Indie space currently are Unity and Unreal 4. Both have large communities, are affordable (different free / paid options, both have options that are free / almost free), are up to date and powerful, have released commercially successfull game made with them, lots of tutorials and community driven extensions available (some of them paid).

For 2D I hear a lot of good things about Game Maker.

But have a look yourself at the engine DB on devmaster.net ... you might find another engine you want to give a try

4) Steps to take:

Highly subjective. Professional Game devs usually start with a Game Design Document (GDD), which is kind of the high level project plan. There will be a pre production phase to test out new technology, art style, come up with and test core game design elements, and generally see if the planned project is viable. What follows is the production phase, were the game is programmed, art is created, sound is done (usually outsourced), level design happens and so on. At the end you have an Alpha release. And this is were the real fun starts (Alpha / Beta testing, Bugfixing, Marketing....)

For you as a small Indie, depending on your plans, most of these things do not matter that much.

Generally, you first need a good idea. Then comes a plan to execute this idea. This will include the decisions you already mentioned (2D / 3D, Engine or starting from scratch, Language choice (based on engine chosen)), but also others that are also important (how to source art (stock art vs. outsourcing vs. doing it yourself), art style (will be biggest influence on your art costs (time or money), detailed game design (you CAN come up with game design as you program... but try to at least have a very solid base, else you are walking blind), a good idea about the scope (the second big influence, not only on your art cost, but your overall project cost), and if you want to go commercial with it, a market analysis (do you even have a market?)).

Then you should start to prototype, prototype, prototype. They don't have to be fancy, you can use placeholder art and crappy code (altough you SHOULD try to come up with example art, or commision that by a good artist, so you have a good idea what you will need down the line).

What you are trying to achieve with all this prototyping is the same as a big studio does with their pre-production: Test if your idea is fun, try to make it fun if it isn't yet, if this is successful, refine the idea so that the production phase is as cheap and productive as possible (as in: you don't need to recomission finished art because you just found X or Z does not work anymore with your new idea).

Then you start crunching out the code and the art that will transform your rough gameplay prototype into a finished game.

Oh, and before I forget: Disclaimer Time!

Game development is a long and hard process. If you want to develop anything more complex, you will need a lot of skill and time, or the money to buy that skill and time from others!

Scope your project according to what amount of time and money you want to invest, and the skills you already posess!

You CAN bite off more than you can chew... this is a free world after all. Just be prepared for the hard reality that comes with it. If you get demotivated quickly, don't try that at home, and keep it to baby steps as others have sugessted. Your mental and physical health will thank you for it (even though your doctor would most probably welcome seeing you more because of stress related issues ).

Game development done by the big studios is so expensive for a reason! They don't blow it all on booze and parties, they need that money for work!

If you are going to use Java, have a look at http://jmonkeyengine.org/

The website has some good tutorials explaining how to use the engine.

Wow, this one should have been some of the shortest advice we ever gave given what the OP asked.


Java is fine, stick with Java. Slick2D is dead, even the author of Slick has moved to use LIbGDX. There is a tutorial link in this message footer, it will more than get you started. Ignore Swing, it's kinda crap and I'll suited for games.


Don't worry about performance, what's the difference between fast enough and fast enough? The answer... Nothing. Until you hit the point of "not fast enough", it's not even a topic you need to consider. As a new developer frankly, you are more likely to be the cause of slowness than your language for quite some time.

2D vs 3D isn't really the question it used to be, as due to the nature of technology, almost all 2D engines are 3D games that ignore one D. That said, some logic problems are quite a bit easier to solve in only 2 dimensions. Art difficulty is generally a wash, depending on style.

Edit: oops, I didn't link the LibGDX series in my footer. http://www.gamefromscratch.com/page/LibGDX-Tutorial-series.aspx

Wow. Thanks for all the advice!

I really want to stick with using Java as my language, but I've now gotten to the point where I should either go 2D or 3D.

I've actually written out a design document for a game I want to eventually make (something I would like to work on in the future), but it would be better to start of small and learn how things work before making a somewhat complex game.

Would it be a wise choice to make a simple 2D game (like @Shippou said about the moving squares avoiding falling squares), and then proceed to make a somewhat more complex 2D game / a simple 3D game? I'm really taking this first step as a learning curve, so what I am really asking is what would be the best route to take in order to learn how everything works.

As I said, eventually I would like to create a 3D game, with world generation similar to Minecraft (a block filled world randomly generated), but have it feel like your playing an RPG game (in comparison to Skyrim [by Skyrim, I mean incorporating a quest like system along with the exploration aspect]). As for a game like this, I feel it'd be best to make a custom engine, but are there engines out there that would help me in the process? Now I wouldn't begin working on this for some time (maybe a year or so) as I want to learn the basics first.

Would it be a wise choice to make a simple 2D game (like @Shippou said about the moving squares avoiding falling squares), and then proceed to make a somewhat more complex 2D game / a simple 3D game? I'm really taking this first step as a learning curve, so what I am really asking is what would be the best route to take in order to learn how everything works.

If you attempt to take on a more complex project with out having experience with simpler games first, you will "burn out" very fast.

Gave development is like building blocks, you need to learn simple concepts before attempting more complex ones.

One small step at a time gets you up the mountain a lot better that trying to run at full speed.