How to Make Dapple in 6 Months

When I posted my “Numbers Post” back in March, one of the most common questions I got asked was “how did it take 6 months to make Dapple?” I found this question interesting. I’ll admit that at first I found it frustrating, and I thought “how could it not have taken 6 months?” But then I started thinking about it more and more. It occurs to me that if you’ve never built a game from start to finish, you might now know what goes into making a game.

With that in mind, I thought I’d take some time today and go over a few things about Dapple. If you haven’t read my 360iDev presentation on the creation of Dapple, you might want to do that. I consider it a companion to this article, but this will go into more depth.

Effort:

The first thing I want to do is look at some numbers, because I think it’s good to put Dapple into context. The question of “how could you spend 6 months making Dapple” is interesting to me because I come from a AAA console game background. Before I moved back to Toronto and founded Streaming Colour, I worked on a team of over 100 people who all worked on a single game for 3 years. Dapple had one person (me) working on it full time for 6 months, and 3 content creators working on it, say, half-time for one month each (call it 1.5 months total). When you put it like that, it’s hard to really put that into perspective…so let’s do it this way instead.

AAA Console Title (Xbox 360 or PS3):

  • 100 people (this is actually fairly conservative; some teams are up to 200 people now)
  • 3 years (this is pretty standard, unless you’re EA putting out a franchise every year)
  • 220 working days a year (this doesn’t include overtime, which means this will be much lower than actual effort involved)
  • 6 hours of work per day (again, not including overtime)
  • Total person-hours: 396,000

Dapple (iPhone):

  • 1 person
  • 7.5 months (this includes the contractors’ time)
  • We’ll call it 160 working days
  • 6 hours of work per day (again, not including overtime)
  • Total person-hours: 960

Let’s call it 1,000 hours for Dapple, then. In actuality, I worked quite a bit of overtime, especially on the last 1/3 of the project. But still, for that amount of effort, I think Dapple is quite impressive. Maybe I’m biased.

Lines of Code

My friend Jay posted on his blog recently about the growth of code size between Wolfenstein 3D and Quake 3. It’s a fascinating read. It also got me thinking about Dapple’s code size. With Wolfenstein 3D being released for iPhone as open source recently, I thought I’d compare the two. I used a tool called cloc to run a line of code comparison of Wolf 3D and Dapple:

  • Wolf 3D = ~28,000 lines of code
  • Dapple = ~21,000 lines of code

This means that Dapple is about 3/4 the size of Wolfenstein 3D, which I actually found quite shocking. The big difference here is that Wolf 3D’s code is mostly for the game. When I broke it down further, I discovered that over 6,000 lines of code for Dapple is for the front end and user interface. If you look at Wolf 3D, they only have a few very simple menus in the game. Dapple has dozens of screens.

I’m not sure if there are any conclusions to be had here, other than to say that it does take time to write 21K lines of bug-free code.

Timeline

Finally, this will only be of interest to only the most hard-core of the hard-core, but I took an hour or two and I went through all of my change logs during development of Dapple. What I’ve done here is give a week by week summary of what I did to create Dapple. Keep in mind that most stuff relating to the business (e.g. finding and hiring contractors, dealing with international sales contracts, etc) didn’t have any mention in my change logs, so I haven’t mentioned them here. This mostly just relates to the coding tasks involved in creating Dapple. So, without further ado, here’s how you make Dapple in 6 months:

Pre-Production

Week 1:
– Downloaded, installed and learned Playfirst’s Playground SDK (2D game engine) for Mac.

Week 2:

– First pass at prototyping original game concept.
– Game isn’t fun.

Week 3:

– Created animation system.
– Changed some gameplay mechanics to make the game more fun.
– Added some simple animations.
– Game still isn’t fun.

Week 4:
– Branched prototype and started working on new gameplay mechanic, based around same idea: mixing paint colours.
– Gameplay now based around making matches (more similar to final product)
– Game is more fun, but is too complex – new players are easily confused.
– Experimented with simple SFX and background music
– Experimented with some simple HUD elements (displaying score, for example)

Week 5:
– Ported prototype to Windows.
– First draft of game design document.
– Started designing front-end UI flow (menu screens).

Week 6:
– More gameplay mechanic changes to simplify the gameplay.
– Game is now quite fun (very similar to final game mechanic).
– Added logic to detect end-of-game condition.
– Changes to underlying board data structures to make things more flexible.
– Added hint animation.
– Added in the concept of brown paint.
– Game no longer fun with current first-pass implementation.

Week 7:
– Balanced the way brown paint works.
– Added in concept of brown paint spreading.
– Game is quite fun again (and is now almost the same as final game, in terms of mechanics)
– Decided to port to iPhone, just to see if I could.
– Prototype ported to iPhone successfully (but no UI, no ability to restart a game after it ends, etc).
– Game uses CocoaTouch and UIKit for now.

Week 8 – 10:
– Working on company website and logo design.
– Other misc business stuff.

Week 11:
– Added special items to the game (water drop + diamond).
– Game much more fun, much better balance.
– Gameplay tuning.
– Fixed major bug in the search algorithms when looking for potential matches for the hint arrow.
– Hint tuning.
– Branched from prototype branch into the main trunk.

Production

Week 12:
– Now working on the game I will eventually ship – no longer prototyping.
– Deleting all the junk code from the prototype.
– Refactoring reusable code.
– Rewriting all the classes that were deleted.

Week 13:
– More refactoring and rewriting.
– Code base is much cleaning and extensible.
– Set up developer profiles, etc, and got project running on device hardware (instead of just simulator).
– Fixed some major bugs in the game logic and UI.
– Created Front End wireframes document to provide to artist.

Week 14:
– Converting game to OpenGL.
– Got the game back up to previous state, but with rendering layer swapped out and now using OpenGL instead of CocoaTouch and UIKit. Game now completely OpenGL-based.
– Adding temporary Title Screen on launch.
– Implemented game mode loading system.
– Did some event handling to disable rendering/update while device locked and handling long update times after unlocking.
– Fixed some bugs.
– Upped number of levels that game has difficulty controls for.
– Set up ad hoc distribution builds.
– Fixed some memory release bugs.

Week 15:
– Fixed bugs in touch handling.
– Implemented audio system shutdown during device lock (was causing battery drain).
– Implemented end-of-game handling to bring up simple high scores list.
– Difficulty tuning.
– Implemented paint “falling” animation and tuned.
– Implemented support for animated textures.
– Implemented paint “match” animation with temporary texture.

Week 16:
– Changed hint logic to pick random hint instead of closest to top-left.
– Adjusting scoring system to take into account special items.
– Implemented “scoring” animation.
– Fixed some bugs related to scaling/translation in animation system.
– Animation tuning.
– Fixed a bug with alpha blending for textures that had alpha in them.
– Fixed some memory leaks.
– Started adding first art assets that arrived from artist.
– Score tuning.
– Implemented score multiplier system for combos.
– Implemented “multiplier” animation.
– Refactored rendering code to separate rendering of individual HUD elements more.
– Implemented progress bar functionality.
– Implemented bitmap font rendering system just for number values in-game.
– Started implementing a Front End framework system.
– Implemented system to load/unload front end screens (i.e. menus)
– Implemented temp main menu to test FE flow system.

Week 17:
– Implemented more of the FE framework system.
– Hooked up the Pause button to load an empty pause menu.
– Added new artwork to the game.
– Implemented tinting for the bitmap font system.
– Implemented UI Widget framework to hook into the FE framework.
– Implemented “Menu” widget.
– Implemented first pass at “Main Menu” using new Menu widget.
– Implemented “Chooser” widget.
– Implemented first pass at “New Game” screen using the Chooser.
– Implemented “Slider” widget.
– Implemented “Checkbox” widget.
– Implemented first pass at “Options” popup.
– Connected widgets in Options popup to control user settings.
– Implemented first pass at “Pause Menu”.
– Implemented first pass at “How to Play” popup.
– Implemented first pass at “Credits” screen.
– Scoring tuning.
– Implemented a user data storage class.
– Connected user data to NSUserDefaults to save out user data settings.

Week 18:
– Added first SFX assets from sound designer.
– Added first music assets from composer.
– Implemented first pass at colourblind support.
– Added high scores to saved data.
– Animation tuning.
– Difficulty tuning.
– Added SFX to animations (e.g. “squish” effect when paint falls).
– Fixed a bunch of bugs and memory leaks in SoundEngine.
– Fixed some bugs around touching the screen during animations.
– Replaced all art in the game that contained text with new art with a new font (font licensing issues).
– Added new match animation.

Week 19:
– Implemented first pass at a “Generic Popup” class.
– Implemented “Quit Confirm” popup using new Generic Popup.
– Implemented system to save the user’s game in progress.
– Art tuning.
– Implemented first pass at “High Scores” popup.
– Hooked High Scores popup into the end-of-game flow.
– Implemented the “Level Up”, “Good”, “Great”, and “Amazing” animations.
– Big bug fix to do with alpha blending to do with premultiplied textures.
– Bug fixes.
– Implemented the Mixing Guide.
– Added new colourblind mode artwork.

Week 20:

– Implemented first pass at “New High Score” popup.
– Hooked New High Score popup into end-of-game flow.
– Added new SFX assets.
– Implemented all of the “How to Play” sub-popups.
– Tuned colourblind mode settings.
– Tuned all the FE positioning values to make sure everything lined up properly.
– Difficulty tuning.
– Started adding real credits to credits screen.
– Added final art assets.

Week 21:

– Christmas holiday

Week 22:
– Created game video captures and created first trailer video.
– Wrote announcement press release.
– Started gathering contact information for PR.

Week 23:
– Added new music assets.
– Added final SFX and music assets.
– Implemented system that allows user to either listen to the game’s music, or listen to their own iPod music. Game auto-detects whether user is playing their own music or not.
– Refactored audio SFX system to allow for easier playing of SFX.
– Hooked up SFX to all FE screens and widgets.
– Added “Tips” popups when user first starts the game.
– Implemented “Reset Tips” system that allows user to reset the tips state to see them all again.
– Updated and tuned the multiplier animation.
– Refactored and removed some dead code.
– Adjusting game initialization settings.
– Adjusted the Generic Popup code to make sure things looked better.

Week 24:
– Implemented first pass at “Timed” game mode.
– Implemented changes to store separate high scores for Classic and Timed modes.
– Added descriptions to Game Modes screen.
– Update High Scores screen to display separate lists for Classic and Timed modes.
– Added new “Game Mode” How to Play popups.
– Added Game Mode tips to start of game.
– Added confirmation popup to Continue button that displays info about game in progress.
– Fixed a bunch of memory leaks (mostly textures that were alloc’ed without being released).
– Implemented “3, 2, 1, Go!” animation for Timed mode.

Week 25:
– Implemented “Game Over” animation.
– Implemented audio warnings for Timed mode.
– Implemented first pass at “Two Player” game mode.
– Refactored most major classes to support a “player” parameter.
– Fixed major bug in the end-of-game detection code.
– Updated all rendering code for Two Player mode to rotate to face the current player.
– Updated all animations for Two Player mode to animate correctly for the current player.
– Update board logic so that tiles can fall in two directions.
– Implemented “Player X Wins” popup for 2P end-of-game flow.
– Optimized board rendering to get rid of some dumb, slow code.
– Fixed bugs.
– Updated FE framework so that FE screens get rotated based on the current player.
– Changed “New Game” confirmation popup to display info about game in progress.
– Animation tuning.
– Difficulty tuning.
– Added new “Board Layout” How to Play popup for 2P mode.
– Implemented “Player X Go!” animation for 2P mode.
– Hid current brush colour while input is disabled.

Post-Production

Week 26:
– Fixed a bunch of audio bugs.
– Fixed a bunch of UI bugs.
– Gameplay tuning.
– Implemented loading screens.
– Modified the sliders so that they are easier to use (bigger touch area).
– Implemented “System Layer” popup support.
– Implemented error popup if corrupt save data is detected for any reason.
– Hooked up save points to a lot more places in the game.
– Tuning score animations to render better when they’re close to edge of the screen.
– Created final icon and iTunes artwork.
– Fixed a bunch of memory leaks.
– Modified some UI widget functionality allowing for more intuitive use of Chooser widget.
– Changed the way the in-game double-tap works to make it easier to play.

Week 27:
– Updated Credits screen to support 2 pages of credits.
– Added Special Thanks credits.
– Fixed a few memory leaks.
– Major rework to SoundEngine.
– Fixed a couple of really obscure SoundEngine crashes that happened extremely rarely.
– Fixed a bunch of memory leaks in SoundEngine on engine shutdown.
– Created a “Final” build target that disables logging and asserts.
– Submitted to App Store!

Owen