All posts for the month August, 2013

This is the best way to write prototype code.

This is the best way to write prototype code.


All right, it’s time for some spare-time fun, and nothing says fun like prototyping a game idea.

After taking a quick inventory of my home office, I have all the things I need.

  1. An idea worth prototyping
  2. Spare time
  3. An industrial-sized barrel of motivation
  4. Unity3D
  5. OUYA devkit
  6. A method of source control (SVN/Git/Mercurial/Perforce/etc)

Since I figure I’m not the only one that might have some or all of these things lying around, I thought I’d talk a little about what I do when I prototype a game or game mechanic.  It’s really a pretty simple process.  The first thing I do is set up a Unity Project.  Basically, all that I need is a project that compiles and an executable to deploy to my target platform (today it will be the OUYA).  Once I reach this point, I CHECK IT IN TO SOURCE CONTROL.

Source control is my best friend when I prototype.  I’ve learned to love pressing that “commit” or “push” button.   My mouse is probably wearing out faster than it needs to because I’m always hammering on that button any time I make progress on a gameplay mechanic.  I know it’s only a prototype and it might get thrown away in the end, anyway, but trust me when I say that it is a benefit to have frequent check-ins.  Just having the ability to easily roll back a prototype to a stable state is amazing.

After this I pull out a few notecards and start writing down little stories for the things I want/need to accomplish (this is sorta like a user story in Scrum/agile development.)  I try to phrase these stories as though there is an end-consumer in mind.   Usually the customer is the player, but sometimes it is a designer/artist.  As an example, I might write a story that says, “The player can move a 2D sprite-based character around on a grid using the controller.”  This sounds like a pretty big task, and I could break it down into smaller sub-tasks, but this is just about the size of the things that I want in the beginning.  It’s clearly a feature, and it’s the sort of thing that should take less than one day/evening of work to accomplish.

In the end, I might write 4 or 5 cards based on the highest priority items for the prototype.  High priority tasks do NOT include things like “Main Menu” or “Game Icon Creation” or anything that does not specifically lead to gameplay testing.  It should also be noted that I spend very little time making my own art. I tend to start with an online search to see if someone else may have already done art/music that I like.  I go to a place like OpenGameArt, for instance (there are plenty of others out there, look around.)  I find my order of importance for the overall tasks is:

  1. Gameplay/Mechanics
  2. Gameplay/Mechanics
  3. Gameplay/Mechanics
  4. Gameplay/Mechanics
  5. Gameplay/Mechanics
  6. Thematic Elements (Art/Music)
  7. Menus and other low-hanging fruit

Now that I have some placeholder art/music, it’s simply a matter of trying out new ideas (and not being afraid to throw out ideas that just aren’t working) and completing the stories that have been written.  I always feel free to write messy code if it’ll let me get to the core of the gameplay faster.  Sometimes I’ll end up writing a new card to explore an interesting aspect I’ve stumbled upon while completing another task or I’ll throw out a card if it no longer fits with what I want to accomplish.  It’s a lot of rinsing and repeating at that point.

If it’s a successful prototype after enough work or a given amount of time,  I’ll restart the whole process in a clean project as though I’m doing real development.  I rarely, if ever, re-use any of the prototype code or assets in my new project; it was just for learning purposes, after all.

So I guess that pretty much wraps up my description of how I prototype and it appears the first major check-in for today’s prototype has uploaded to source control.  Time to get on with the fun!