Many people over the past few months have asked me “how exactly do you learn how make games?” For every time the question was asked I had to come up with a long answer, and because that question will probably be asked another huge amount of times in the future, I decided to write my definitive answer so that I can point people to it, and also so that I can improve it later on.
First off, I would like to say that I’m not a professional. Heck, I don’t even have a full officially released game yet. Over the past two years I’ve done lots and lots of prototypes, that is games that aren’t finished, but are just a rough draft of the final projects. I’ve mostly never finished a game because I lost motivation someway throughout the development process – sometimes I get very close to finishing, then just drop the project and start a new one instead. At first it may seem like a huge waste of time, but it actually isn’t. It generates tons of practice and experience for future endeavors, so don’t feel too bad about not completing a project. You probably learned tons of useful stuff from it and you’ll be able to apply it to newer projects.
To start off, decide what game engine you’re using. Of course this sounds like gibberish to someone who’s never programmed before, but try googling around for 2D game engines. Why 2D? Well, 2D games are easier to make – physics, art, and programming are way easier to manage in a 2D system than a 3D system. For starters, make sure you find a game engine, not a game framework (ex: PyGame). Frameworks give you the tools necessary for you to write your own game engine, but unless you want to focus on writing an engine rather than a game I recommend selecting a game engine. I wish I knew that when I was starting out.
I began with PyGame. It’s a cool framework, but Python is really not an ideal language for game development, and also because PyGame was a framework, I had to implement my own animation, physics, particle, etc. systems. They were less than stellar since it was my first time programming, and my game sucked. That’s okay – I learned a lot from implementing my own engine, but I don’t think it’s necessary to take that painful path – just use a game engine.
Next thing I tried was Flixel. It used the ActionScript 3 language and ran on Flash Player and Adobe Air – in my opinion vastly superior platforms than what Python offered. It was fun, and taught me even more. With Flixel taking care of the game engine, I was able to concentrate on actually making games.
Eventually, I found the Flash Player and Adobe Air platforms quite terrible, so I moved over to Haxe, which is an awesome programming language that takes the best of ECMA script syntax and merges it with some C++ goodies. It can also deploy to tons and tons of different platforms (mobile, native, web, etc.), which makes it usable for a gigantic amount of purposes. Luckily, there was a port of Flixel to Haxe, called HaxeFlixel. At the moment I’m using HaxeFlixel, but I might use Luxe and Snow from Snowkit one day.
Okay. Let’s talk about art now. I’m a programmer. I’m not a composer and I can’t draw anything decent. So, how do I get music and drawings? Well, if you look hard enough on google, chances are you’ll find open-source or creative commons (aka stuff you can usually use free of charge) both music and art that correspond with your game idea. Sites you can use are opengameart, freemusicarchive and nosoapradio, for example.
So, to learn how to make games:
- Find a 2D game engine you want to use – make sure you like its platform and programming language – USE GOOGLE
- Read/watch tutorials about the game engine and its programming language (I strongly suggest learning the programming language before attempting to learn the game engine) – USE GOOGLE
- Find art/music or learn how to make art/music – USE GOOGLE
- Get some fun game ideas and try to make games out of them