A friend of mine sent me a message on Twitter the other day asking if I had any tips for someone looking to get started in game development. I mentioned this was quite a large question, so I asked him to narrow the scope of his question. He came back with “between idea and prototype.” That seemed like a good subject for a blog post!

So, you’ve got some programming under your belt. Maybe you’ve been building web site back ends, or accounting software, and you’d like to try your hand at games. Where do you start? If you’ve got an idea, how on earth do you approach the process of turning that idea into a prototype?

1. Consider Scope

I’m putting this right up front, because it’s the biggest and one of the most common traps a new developer can fall into: your idea is just too big. It’s very easy to bite off more than you can chew with a game idea. If you’ve never made a game before, don’t try to build a huge RPG in a massive world for your first game; you will almost certainly not finish it. What about something like tic-tac-toe instead? Or your favorite card game? Or a match-3 game (my first game, Dapple, was chosen because it had a very defined scope, and it still took nearly 6 months to make).

To put things into perspective: a triple-A Xbox 360 or PS3 game will have a team of 100-200 people working for 1-3 years on it. If you’re one person expecting to work on a game for six months, you need to make sure you’re working with an idea you can finish. You can’t build Halo by yourself. That’s ok. Pick a game idea you know you can finish; it will be challenging enough.

Also don’t forget that there are lots of parts to making a game that aren’t immediately obvious that you’ll need to build: menus, save systems, high score boards, platform specific requirements, etc, etc, etc. If you think your game is going to take you three months to make, bank on it taking six. So if you only have three months of savings to live off, maybe pick a game idea you think you can complete in a month and a half.

2. Learn About Games

This is a tough one, are you ready? You need to learn more about games. This means, yes, even playing other games for research. It’s a tough job, but someone’s got to do it. Take a look at other games in the genre that you’re targeting. Look at what they do well, and more importantly, what they don’t. What bugs you about the way they implemented things? What stands out as being done well? Are their menus clunky? Do the animations add that extra punch to really augment the gameplay? Does the music help draw you in? Take notes. Remember that you’re playing to learn, not just to have fun.

If you’re coming at this from a background other than game design, you may also need to do some reading. There are lots of great books written on the subject, and more being written every day, as the industry grows. See what expert game designers can teach you about designing games by reading their books.

One of my favourites, which is also a very quick read, is Raph Koster’s “A Theory of Fun for Game Design“. It’s great book to get you started thinking about designing games and what makes games fun. Another book I haven’t read yet, but have heard a lot of great things about, is Jesse Schell’s “The Art of Game Design: A Book of Lenses“. There are many other great ones, I’m sure. The important thing to remember is that making games is a constant learning experience, so get learning!

If you’re already a game developer reading this, what about you? What are you favourite books? What developer forums do you read? What blogs are the most useful?

3. Choose a Prototyping Technology

So you’ve got your idea and you’ve got some ideas about how to make it work as a game. Now you need to choose your technology for implementing a prototype. I gave a talk in April at the amazing 360iDev conference (their fall conference starts today in Austin) on rapid prototyping. One of the things I talked about is that when you’re prototyping, use whatever technology you are most comfortable with. This doesn’t have to be the same technology you’re going to implement the game with. If you’re targeting releasing an iOS game, but you’ve never touched Objective-C, but you’re a Flash wizard, prototype in Flash. If you’re an expert in javascript, prototype in javascript. If you’re not overly comfortable in any technology, prototype with pen and paper! Do whatever you need to do to get a working version of the game as quickly as possible. All the planning in the world won’t tell you whether or not the game is fun. Playing it will tell you that instantly.

If you’re doing iOS development, cocos2D is a fantastic platform with which to do 2D game prototyping. Flash is a great prototyping tool. If you’ve used Unity, I’m told it’s also great for prototyping. If you’ve got your own engine you’ve been building, use that, just be careful not to spend your prototyping time implementing engine features.

4. The 2-Minute Guide to Game Architecture

Ok, so what I’ve talked about is all well and good, but if you’ve never looked at game code before, you may be wondering how on earth a game works. This is obviously a HUGE topic, one that’s covered in immense detail in many books. However, I will attempt to give the extremely high level overview of how a game works. Ahem…wish me luck.

The Game Loop

At the heart of your game is a loop. This loop executes as long as the game is running. In fact, in many games, it’s a while (1) loop. In iOS development, you’ll be working with an event-driven timer instead. However it’s structured, the important thing is that you’ve got a chunk of code that’s going to execute over and over again. This chunk of code makes up one frame of execution. Most games aim for either 30 or 60 fps (frames per second). This means that your game loop needs to execute in less than 1/30 or 1/60 of a second.

At its most basic, your game loop is going to do two things every frame: update and then render.

The Update

This is where your per frame game logic resides. The update will do things like: pump the physics system (if there is one), update all the active animations, handle collision detection, etc. Basically, it updates the state of the game world in 1/30 or 1/60 second intervals. It says, 1/60 second has passed since the last time I was called, what needs to update? Oh, this character animation needs to be updated, these sprite positions needs to change, these two objects collided, etc. At the end of the update function, your game is in a new state and is ready for rendering.

The Render

Now that the world’s state has been updated, it’s time to render everything to the screen. This means going through all the renderable objects in the world and drawing them. If you’re using a graphics engine, then renderable objects (like sprites) may automatically get a draw() call made on them. If you’re using OpenGL or DirectX directly, then this is where you’ll be making calls into the graphics libraries to do the drawing yourself.

Building a rendering engine that runs quickly is an absolutely massive topic. You’ll need to pick up a book or two (and brush up on your 2D and 3D linear algebra, as well as low-level graphics hardware achitecture) if you’re going to roll your own.

Events

But let’s remember, games are interactive media. This means that at some point you need to handle user interaction with the game. This is often event-driven, in that it’s handled outside your main game loop. You’ll get calls into your code saying “this button was pressed” or “the user touched the screen here”. Some more traditional game loops would have input polling before the update was done. Many modern game frameworks (or platform APIs) rely much more heavily on event-driven code. Much more of your game logic will happen in your event handlers.

At any rate, these events are where you’re going to change game state based on what the user is doing. In a board game, the user might click a button to roll the dice, so your button click event handler is where you’ll trigger a dice roll. In a first-person shooter, you’ll be handling analog stick position updates to update the camera orientation and player’s position in the world.

You may also need to respond to system events, like an iPhone going to sleep, or the user alt-tabbing out of your full-screen game.

The Other Stuff

Those are the basics, but there is so much more that goes into a game: audio systems, user interface systems, front end menus, HUDs (heads up displays), physics systems, animation systems, game logic systems, font rendering systems, save game systems, leaderboard systems, achievement systems, and localization systems (to name but a few). But remember, not every game needs all of these things. That’s why it’s important to remember #1 and limit the scope of your first game.

The hardest thing about creating your first game is finishing it.

It will take dedication to work through the bugs and the tedious parts of building a game (yes, there are tedious parts), but in the end, it’s worth it. You’ll have a game that you made ready for the world to play and enjoy. So what are you waiting for? Start learning. Go make a game!

Owen