Archive for the ‘Sound’ Category

Game Dev: Getting Started

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.


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!


Dapple Update (pun intended)

I haven’t really been posting much this week because I’ve been working on Dapple. I thought I’d provide a little update on what I’ve been doing. I’m working on a Dapple Update. Yes, the word update is confusing in this first paragraph. Let me try that again: I’m working on version 1.1 of Dapple and Dapple Lite.

There were a couple of key things I wanted to address with Dapple’s first update:

1) Reduce app footprint to under 10MB

When an app is over 10MB, users with a cell phone connection aren’t able to download the app directly. Apps that are over 10MB require a Wi-Fi connection to download. I think this is potentially costing me quite a few downloads, mostly of the Lite version. I want the Lite version to be something that people can download on a whim. If they have to wait until they have Wi-Fi access, they might never download it.

Dapple and Dapple Lite were both about 13.1MB, so I needed to reduce them by nearly a 1/3. When I looked at the sizes of my various directories, it became clear that the music and SFX files were the ones causing the problem. Dapple has about 13-14 minutes of music that plays in the game. That amounts to significant file sizes. There are also 14 SFX files.

I’m going to get a little bit technical here, so if you don’t care for this stuff, just skip ahead a bit. The iPhone does have a hardware audio decoder. You can use it to hardware accelerate your MP3, AAC, etc decoding. However, it can only operate on one file at a time. This means if you’re ever going to play more than one sound at once, you have to use two forms of audio decoding. For Dapple, I use AAC compression for the background music, but all the SFX files need to be in a non-encoded format: Linear PCM. This means that the SFX files are huge, because they’re basically 16-bit uncompressed audio data.

For v1.0 of Dapple, all the music was encoded as AAC, 128kbps, constant bit rate, so that it sounded really good. I decided I would try to reduce the bit rate as much as possible without sacrificing the audio quality too much. By switching to a variable bit rate, I was able to compress the files much more without too much of a quality reduction. By doing this, I was able to reduce the music file sizes from 8.7MB to 6MB! Almost there already!

That was the easy part, now I needed to deal with my SFX. The iPhone documentation infers that if you’re not using a hardware decoded format you should be using Linear PCM or IMA 4:1. IMA4 (which I’ll refer to is as from now on) is a compression format for audio that results in a nearly 4:1 compression (it’s actually closer to 3.75:1). I converted all of my SFX files to IMA4 and was surprised to discover that none of them played. This is because there’s no native support for IMA4 on the iPhone. You can use it, but you have to write your own decompression code. I ended up scouring the net looking for information on the IMA4 data format, how the compression works, and how to decompress it. I found several partial resources, none of which were complete enough to just let me implement it. It took me two solid days of some pretty hardcore coding (it was really fun, actually), but I finally got IMA4 working in Dapple. The nice thing about IMA4 is that the file gets decompressed when it’s loaded into memory, and is then played as Linear PCM. This means there’s no performance hit, except on file load. (I’ll link to some of the IMA4 resources I found at the bottom of the post)

IMA4 was a huge win. My SFX files totaled about 2.2MB on disk before compression. After compression, they’re just over 600KB, with almost no loss in sound quality.

So, after rebuilding and zipping, both Dapple and Dapple Lite sit at about 9.5MB! Hooray! What’s next?

2) Fix an audio bug

This is the only bug that’s come up more than once since the game launched. If a user is playing their own iPod music while playing Dapple, then locks their device, their iPod music stops playing. This was a problem in how I was managing audio sessions in the game. This has now been fixed.

3) Add a Feedback Button

I want to make it easier for people to provide me with feedback on the game. I changed the Main Menu around so that the “Credits” button now says “Extras”. This opens a new menu which has “Feedback” and “Credits” in it. The feedback button, when clicked, launches the Mail program and lets the user send me an email. Hopefully people will use it to request features, complain about things they don’t like, etc.

4) Add a computer-controlled opponent for 2 Player Mode

This is a request I’ve had from a lot of different players, so I decided to try to put it into the first update. As of last night, I can actually play a game against a computer opponent. It’s pretty cool. However, the computer opponent is really stupid right now.

The way Dapple already works is that when a player starts their turn, the game searches the board and picks a random spot that will make a match. This is stored for when the hint arrow needs to be displayed. I figured I could make use of that code and just make a computer opponent execute a move there on its turn, instead of displaying a hint arrow.

This lead me to an interesting discovery: it works, the computer can play, but the computer opponent sucks at the game. In 10 games I played against the computer last night, I won every single game. What I found interesting about this is that this proves that making random moves in Dapple isn’t nearly as effective as thinking your plays through. I’ve had a small number of negative reviews (either on the web, or on the App Store), and the complaint is usually that they feel like playing randomly yields the same results as thinking their moves through. With a random computer opponent pitted against a player who thinks their moves through, the human player will almost always win. To me, this is proof that the game can be learned, that you can get better at it, and that strategy will win over randomness. Up until now, that’s what I believed, but I couldn’t prove it…

So today my goal is to try to encode some of the choices I make when looking for the best play to build a heuristic that the AI opponent can use. Then I’ll need to tune how much it uses that heuristic for various difficulty levels. Should be fun!

With any luck, I should be able to submit Dapple and Dapple Lite v1.1 by Monday.


IMA4 Resources:

  • – A good starting point, as this article walks through the high-level steps required to get IMA4 decompression working. However, this article leaves out a lot of steps that are necessary to get things working. It is also not very clear on the differences between mono and stereo audio streams and how that affects the packets.
  • – Contains useful optimizations that allow you to avoid doing byte->float conversions to do floating-point math.
  • – Has some useful information on byte/nibble structure of the packets
  • – Actual C code for doing the decoding. This is for quicktime IMA4, so some of the logistics of how you extract chunks of data won’t work, but the actual math for decoding each nibble into a 16-bit frame should be the same for you.

Breaking my Own Rules

Back at the end of November I posted about some new rules I had made for my work-life. Basically, I had said that I wasn’t going to do work, or read work emails after 7:00 PM each night. I had also decided that I wasn’t going to work on weekends. All of that went out the window last week.

As I get closer to submission I’m working more and more. Last week I did several nights of working late and I worked a half day on Saturday, and a few hours on Sunday. I’m already paying for it. I haven’t been sleeping well again. The problem is that when I work late, I can’t stop thinking about work, even when I’m supposed to be sleeping. I end up lying awake at night going over things in my head instead of falling asleep. So I’m not really sure what to do. On the one hand, I need to be putting in this extra time right now, but on the other hand, I do like to get some sleep.

The good news is that by working a bit on the weekend I was able to wrap up the Timed Mode for the game. I managed to put in a bunch of new animations including: a countdown animation when you start a timed game, some beeping sounds when your time’s running out (that get more frantic as you get closer to “time’s up”), and a new Game Over animation that differentiates between losing because there were no more moves and because you ran out of time.

I’m quite pleased with how the Timed Mode turned out and I’m also pleased with how long it took to implement it. It took about 3.5 full days of coding to get it all in and working, with all the new animations, UI, etc.

Yesterday I started planning out the 2-Player mode that I want to add this week. The biggest problem I’m running into is the screen layout. The screen is pretty tight in single-player modes for displaying critical information, but now I need to display info for 2 players. So yesterday I spent a few hours mucking around in image editing software playing with the layout. I think I’ve got something that should work. Now I’ve just got to build it and see.

I’ve given myself until the end of the week (i.e. Sunday) to implement this new mode. That’s about as long as I can afford to take and not risk delaying the project significantly. It feels like I should be able to do it. Here’s hoping I’m right.


Productive Day

Since I fixed my audio problems I’ve been quite productive. I’ve tackled a lot of small problems over the last day and a half. Here’s what I’ve done since yesterday at lunch:

  • Dropped the final music and sound fx into the game – the sfx have been balanced against the music levels now.
  • Created a new interface for playing sound fx so that I can play them from anywhere in the game.
  • Added sound fx to all the front-end menus and widgets.
  • Implemented a tips system for first-time players that brings up information as events trigger in the game.
  • Added an option to the Options menu that allows users to reset the tips.
  • Went through all of the textures in the game and ensured that their widths and heights were all an even number of pixels – I had noticed some blurriness in a bunch of textures, which turned out to be because of the way the UV mapping is done on textures with odd widths/heights.
  • Updated the multiplier animation to use the nice font and tuned the animation to be more smooth.
  • Removed a bunch of dead code that wasn’t being used anymore.
  • Fixed a bug in the board initialization code when launching the game at harder difficulties.

It feels good to get lots of little things done. It’s all these little things that make a real difference to the feel of the game.


Audio Woes Become Audio Woos!

Sweet merciful crap, I’ve finally got my audio working properly! It took me 3 days of trying things before finally figuring it out. Even after I simplified things (as Bemmu had suggested in the comments to an earlier post), I still ran into a bunch of problems that would have prevented me from shipping the game. I’ve finally fixed it all, and in its simplified form I think things work much more intuitively, so that’s a bonus.

Now the audio for the game works like this:

  • If the user is playing iPod music when the game launches, it plays the game’s sound fx, but uses the iPod music.
  • If the user is not playing iPod music when the game launches, it plays the custom game music along with the game’s sound fx.
  • If the user brings up the iPod music controls mid-game and starts playing their own music, the game will stop playing its music and let them play theirs instead.
  • If the user brings up the iPod music controls mid-game and stops playing their own music, the game will start playing the custom game music again.

If you have an iPhone developer account and want to see the details (including code snippets) of what happened and how I fixed it, you can see the thread on the forums here: Audio Session Problems ( – Note: You must have an iPhone developer login to access this page).

I’m very pleased with how well this works. I think it makes the game feel much more polished, as it puts control into the users’ hands and lets them play how they want to play.

Next up this afternoon: adding sfx to the front-end menus.