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. That code needs structure as well, and it is not always obvious how to create the architecture of your game. You'll have to decide how to actually make your game world move. Can you get away with not using a physics engine, but roll your own simple simulation code? What are the units and scale your game world is set in? How does it translate to the screen?

But there's actually another problem many beginners overlook: before you start hacking away, you actually have to have a game design first. Countless projects never see the light of day and get stuck in the tech-demo phase due to there being no 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. I will not pretend to give you the be-all, end-all solution to developing games. Instead, I'll try to illustrate how I usually approach designing 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, in code and on paper.

Was this article helpful?

0 0

Post a comment