Chapter 3

Game Development 101

Game development is hard—not so much because it's rocket science, but because there's a huge amount of information to digest before you can actually start writing the game of your dreams. On the programming side, you have to worry about such mundane things as file input/output (I/O), input handling, audio and graphics programming, and networking code. And those are only the basics! On top of that, you will want to build your actual game mechanics. The code for that needs structure as well, and it is not always obvious how to create the architecture of your game. You'll actually have to decide how to make your game world move. Can you get away with not using a physics engine and instead roll your own simple simulation code? What are the units and scale within which your game world is set? How does it translate to the screen?

There's actually another problem many beginners overlook, which is that, before you start hacking away, you'll actually have to design your game first. Countless projects never see the light of day and get stuck in the tech-demo phase because there was never any clear idea of how the game should actually behave. And I'm not talking about the basic game mechanics of your average first-person shooter. That's the easy part: WASD plus mouse, and you're done. You should ask yourself questions like: Is there a splash screen? What does it transition to? What's on the main menu screen? What head-up display elements are available on the actual game screen? What happens if I press the pause button? What options should be offered on the settings screen? How will my UI design work out on different screen sizes and aspect ratios?

The fun part is that there's no silver bullet; there's no standard way to approach all these questions. We will not pretend to give you the be-all and end-all solution to developing games. Instead, we'll try to illustrate how we usually approach the design of a game. You may decide to adapt it completely or modify it to better fit your needs. There are no rules—whatever works for you is OK. You should, however, always strive for an easy solution, both in code and on paper.