Game Development, First steps

The idea is that this will be a sort of a walkthrough for the independent game developer.

So you’ve been playing lots of games, and you have decided that you might like to have a crack at making one on your own, or with some friends. Congratulations. This is not going to be easy. At times, it won’t even be fun (but honestly, most of the time it is).

If you’re reading the above paragraph, and thinking “Well, I play some games, but maybe not a lot of games,” then you need to go to step zero, play some more games. You need to know what’s out there in order to take part. Just like writers should be readers, filmmakers should watch films, teachers should be lifelong learners, you will learn more from practitioners of your craft (good and bad) than you can imagine.

OK, so you’ve played some games and now you’re ready to start one of your own. Turn off the computer. Take out a pencil and a notebook. I’ll assume you have a basic idea or theme for the game in mind. Hopefully you’ve also got a basic mechanic in mind. That is, during the main parts of the game, what is the player going to be doing?

If I’m designing Civilization V, then the player is managing an empire, sure, but specifically, the player is clicking on various things on the world map; units and cities and the like, and giving commands. The game is then processing those commands and the commands of AI players.

If I’m designing Bioshock Infinite, the player’s essential action is navigating the world from a first-person perspective. Sure, you shoot things and interact with the world, but at the most basic level, until you are navigating that world, there is no prototype.

If it’s Assassin’s Creed IV, it’s surprisingly similar to Bioshock, although now I have to consider that the player’s avatar is visible the whole time.

For a game like Prison Architect, the player’s essential behavior is building the prison. All the stuff that happens inside the prison is (mostly) out of the player’s direct control.

For whatever your project is, you have to first consider, what does the player directly control? What does the player do? For my current project, the best short description of the game is that it’s a turn-based tactics game. So the player’s essential action is very similar to games like X-Com: Enemy Unknown or Frozen Synapse. In fact, the target is somewhere between those two games for me. So I have to think about what my player will do, before I even start to think about how he or she is going to do it.

While there’s a lot of other game modes, the main game is the battles, so I’ll be working on that first. So I need my player to be able to navigate the battlefield, not as a soldier but as a commander with a top-down controllable world view. I need to be able to select soldiers and give commands, and I need to be able to tell the game I’ve given all the commands I’m giving this turn, and it can go ahead and process them. There’s obviously much more to the game than that but you can see already how complicated it’s getting. I filled several notebook pages to get this far, and in fact may have even described more here than is necessary to strictly get started.

So let’s forget the turn processing right now. Let’s even forget selecting and commanding soldiers. To start, I need to navigate the battlefield. If I can’t do that, I can’t do anything. For that, I’ll need a 3D engine capable of rendering the battlefield, the ability to place a camera into it, and then the ability to control that camera. We can call the camera the god’s-eye view or whatever we want, but in this type of game your player avatar is essentially this invisible camera floating above the action.

So first, figure out the very core of your game. What does the player do? Figure it out on paper, with notes and diagrams or whatever works for you. Next, we’ll figure out how to make it all happen.