Next week will mark the one year anniversary of when EARL’s Warehouse was born as a concept and the prototype was started. As you can see from the picture, EARL’s Warehouse came quite a long way from its early builds to its latest test build.
Today, I thought it would seem fitting to discuss and evangelize a bit about the prototyping and iterative development that went on in EARL’s Warehouse on the eve of this development anniversary.
For the first prototype, EARL was nothing more than a cube floating on top of a box, and his warehouse just a grid of grey cubes. He didn’t even have a name at that point; the entire project had a placeholder name of Bloxxel. When he picked up boxes, they simply disappeared, only to reappear when placed. The physics sucked, and often EARL would suddenly jump to the roof. Beneath this rough implementation, though, my First Impressions team found a gold nugget of fun that came from moving boxes around a voxel-based world to solve puzzles.
Slowly, over time, features emerged from the prototype design. Just enough work was given to each area of the game each time it was touched to take it to the next level. Boxes gained powers. One map turned into four maps. Some sound effects and a couple of cool music tracks were added. Crude physics gave way to more refined physics with less roof-jumping glitches. Placeholder graphics were replaced with flat textures. New robots were introduced. Four maps turned into ten maps. More sounds and music were added. Physics calculations were optimized. Bumpmaps were added to the graphics. Robots and powers were balanced and tuned. Ten maps turned into 24 maps, and so on.
Prototyping and iterative development as exemplified above are both very important to independent game development. Both are crucial techniques for preventing wasted work.
An early, rough-looking prototype like the one inset in the picture allows rapid experimentation to see if an idea will work or is total garbage. For every prototype like Bloxxel that gets made into a game like EARL’s Warehouse, I have 3 or 4 prototypes I will never touch again, because the concept could not be made to work in practice. The sooner a project is runnable the better, because that is all the sooner you can determine if the project is gold or garbage.
Iterative development allows you to quickly gather feedback on whether a project is heading in the right direction. By adding a few working features at a time to a runnable project, you can spot wrong turns quickly and make corrections. If you do too much work without pausing to gather feedback, you run the risk of wasting a lot of work that can be expensive to undo.
When doing iterative development, it is also important to address the highest-risk elements of the project first, so that you can quickly identify and address any project-crushing issues that may arise. It is important to iterate across your project, touching all areas, and not get too bogged down in seeking perfection in any given area. When all relevant aspects of the project have had some work, then it is time to restart with the oldest aspects of the project, and apply insight gained from other areas of the project.
There are many ways to apply these techniques. One of the easiest is to use an established game engine like Unity 3D, GameMaker, or any of the other offerings that are out there. Nowadays, most of them are cheap, if not free. And if it’s not cheap or better, it doesn’t fit with the philosophy of inexpensive prototyping and iteration. A mature, well designed game engine lets you easily play around with and re-arrange elements to explore game concepts. Interactions can be mocked up and refined quickly and easily.
Another way to incorporate iterative development is to commit yourself to delivering a playable build of your project at the end of every work session. I do this, and it keeps me honest about making sure I am leaving things in working order as I iterate, and has other advantages as well: I am always ready to give a demo of all of my latest projects, if needed. If done right, it takes no more than 5-10 minutes to perform the build and do a quick smoke test. (Note: Always keep your old builds for a while in case you discover a showstopping issue deeper than a smoke test can penetrate, especially if you demo often.)
I find that keeping a prioritized backlog of small-to-medium sized tasks serves to both keep me productive, and to promote iterative development. Each work session I will look over this list, pick out a few items I would like to deliver, and then focus on delivering only those items, getting sidetracked only if some other task blocks me from completing those items.
Some of these techniques I discuss from a solo developer point-of-view, but many have team-based analogues that they were distilled from. Nightly builds for team projects are common, as are Scrum-style product backlogs containing stories broken into tasks that are then assigned to individuals or teams. The basic concepts of delivering early and often are still there, and are at the heart of any prototyping or iterative development effort.
Iteration. It’s one of my keys to getting things done.
So while I climb down off this soapbox here, I’ll just dust off and say that testing continues to progress well for EARL’s Warehouse, and I am still on-target for release on September 14 at the Ohio Game Dev Expo. I hope anyone near Columbus who is reading this blog will be able to stop by and see all of us Ohio game developers there. As game development winds down, my preparations for the expo will be heating up.