Game Design

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!

So, just today I managed to…

  • add a Main Menu and Game Over screen
  • make another kind of enemy
  • add new music and sounds
  • add sweet explosions
  • create a system of never-ending waves
  • add scoring and UI
  • solve all of the frame rate issues with the game (Unity doesn’t like drawing more than 400,000 polygons)
  • make my inner dialogue change from “this is barely a game” to “Wow, this is actually fun!”

Game jams are one of my favorite things to do as a developer, and this one was the first one I’ve done all by my self.  I’ll admit I was a little intimidated, but it came out well in the end.  I feel like this prototyped out the spirit of the idea I wanted to test, and it’s fun and even somewhat polished.

I’ve really gotta thank the guys at OUYA for making a surprisingly powerful little device, and major props to the Unity3D guys.  I swear, anything that I needed to get this game going, they’ve put in some kind of support for it.  I want to high-five everyone on that team.  Also, thank you so incredibly much for the Unity Pro trial.  That let me access the Profiler which allowed me solve almost all of the problems I was seeing with performance.

To wrap up my final OUYA Create development post, here’s my task list.  Let’s see how I did overall:

  • Bullets/Weapons (in multiple types/colors)
  • Enemies/Enemy AI
  • Collisions
  • Bullet Patterns for enemies and player ships (spread shot, etc)
  • Obstacles/Environmental Hazards
  • Level Design/Spawning Implementation
  • Explosions + sweet particle effects
  • Music/Sound effects
  • User Interface and Menu work
  • A Boss

Didn’t quite have time to do a boss, but I think given another day or two, I’d have knocked that off the list, too.  Anyway, thanks for reading, and wish me luck in the contest!

Burning the midnight oil tonight; I really do believe there’s something to programmers working late into the night.  Here are a couple of screens from tonight’s work.

GeminiScreen1_012313

That one was from earlier in the night before I’d fixed a little bug with collision.  Notice how bullets aren’t being destroyed once they collide with  the enemy ship (the white one on the right).  I just needed to go into the collision function and tell it to destroy the bullet after the collision and then we end up with something more like this (below).

GeminiScreen2_012313

Enemies will now gladly take aim at the player ships, which is a nice little improvement.  I also added some simple sound effects and music to the game today, which is a great touch.  In the future, I’m always going to push for getting something in there that drives home the intended emotions that the player should feel.  I think the audio really inspired me to get some things done.

The biggest work today was on a spawning system for enemy waves. Setting up dynamic spawn triggers was a breeze and I can now set the game to spawn any number of different kinds of waves (just need to create more enemy types and attack patterns!)   I was hoping that movement would be as simple as adding splines for the enemy ships to follow, but Unity doesn’t support it right out of the gate.  This required me to write a simple little system to bring enemies in from off-screen and move them off when time was up.

Sadly, I’ve added a new task to the list, as it appears that I’ve pretty much blown my performance on the OUYA itself.  There will be significant effort tomorrow to make sure that things run at a smooth framerate.  Anyway, here’s my updated task list!

  • Bullets/Weapons (in multiple types/colors)
  • Enemies/Enemy AI
  • Collisions
  • Bullet Patterns for enemies and player ships (spread shot, etc)
  • Obstacles/Environmental Hazards
  • Level Design/Spawning Implementation
  • Explosions + sweet particle effects
  • Music/Sound effects
  • User Interface and Menu work
  • A Boss