Saturday, March 31, 2007

SpaceCute: Prototyping challenge

The weekend is here and it is time for a short prototyping challenge! Over and over again, I've heard the sad tale that there are talented programmers lacking sexy graphics. I, on the other hand, can't program a lick. So here's a thought: I'll provide some quality graphics and a seed of a design idea. All you need to provide is a working prototype of the core game mechanic. :-)

For each prototype I receive, I'll post it up on the website and the learned folks who lurk here can discuss its pros, cons and opportunities for improvement. It should be a good learning experience all around. As we go, I'll add more graphics and we'll see where it all leads. Continue reading to grab the graphics and read the seed idea.

Core mechanic
The core mechanic of SpaceCute is a single player casual turn based strategy game. It borrows the control mechanism from the familiar mini golf games that have been around since the early 90's. The goal is to add a low burnout skill-based mechanic to the shortest interaction cycle in the game. Is the act of just moving units fun?
  • To move a ship, you drag a line out from the ship.
  • The ship is launch in the direction of line.
  • The ship's velocity is dependent on the length of the line. The line has a max length.
Physics, baby!
Objects in the game are modeled as circles. They can bounce into one another like simple billiard balls. The goal is to add a bit of juiciness and nuance to the often mechanical act of attacking another unit. Does the act of attacking a unit feel satisfying?
  • The ship does damage to opponents when it smacks into them during the player's turn. The feedback to the player when two ships collide is a great area to invest some time in getting the 'feel' correct. If we make this interaction visceral through sound, explosions and flying bits, we can enthrall players from their earliest interactions.
  • Friction is relatively high compared to a billiards game so most pieces only travel a short distance when flung. This is still a strategy game and we don't want chaos to reign after a single turn.
  • Are there any interesting combination collisions that occur that we could accentuate with future layers of mechanics? I'd love to build a combo-hit system into the combat.
Turn structure
During each turn, the player can move one ship. The results of the various collisions are displayed. The turn ends immediately and the computer moves. This is very similar to the turn structure of chess or checkers. The goal is to create a fast paced game that eliminates the need for the typical 'end turn' button found in many turn-based strategy games.

The board is a single screen with 5 or 6 units from each team.
  • What distances between players result in immediately interesting combat?
  • Are there any initial configurations that cause the players to think deeply about their moves?
As the game grows, we'll be adding lots of interesting ships with special abilities. For now, we just need some basic ones to experiment on.
  • Basic attack ship: This is the basic ship used by both the player and the enemy. Balancing max velocity, friction, hull radius, damage and health for this unit are all interesting areas for rapid iteration and play testing.
  • Planet: Heavy obstacle that is used to define space on the map.
Enemy AI
A randomly selected enemy units moves towards the closest player at full speed. This is a simple stub algorithm that will be replaced if more interesting behavior is required.
  • AI should execute rapidly (less than .5 second) This is a casual game and waiting for the AI doesn't add much to the experience.
Winning conditions
Let's add a simple stub winning condition that the player wins when all the enemies are destroyed. Pop up a little text screen to let the player know they've completed the game and give them the option to play again.

Prototyping basics
Unit stats and level design is handled with a single text file (perhaps XML). Changing various variable in the world physics, unit stats or initial token positions should be a simple matter of editing the text file and running the game again.

Important questions to consider
Here are some common questions that any one should ask of their initial prototype.
  • Is any portion of the play fun? There is roughly a 95% chance that your first stabs at this design won't be all that enjoyable. Finding the fun and magnifying it over several iteration of experimentation is critical.
  • What is the pacing of the game? Is the player receiving interesting feedback at steady intervals? Do they have interesting choices at the beginning, middle and end of the game?
  • What actions could use better feedback? Often an interaction fails not because it isn't interesting, but because we fail to properly help the player build mental models of what is happening.
  • How do other players react to the game? We, of course, can post the prototype here and get comments, but it is worth while watching someone in person play the game. Grab your roomie or sister. What does she think? Where does she stumble?
You'll notice that there are almost as many questions as there are specs to this challenge. Such is the way of prototyping. In these initial stages of development, expect rapid iteration and rapid learning.

There are naturally dozens of ideas stored away for various ships types and more complex interactions between objects. Ice zones with low friction, units that explode Every Extend-style when they reach their destination, factories, resources, powerups...SpaceCute, the massively single player SRPG! Woot. Any designer worth his salt can generate webs upon webs of dreamy meta-game mechanics. However, unless the core mechanic is solid and enjoyable, these really aren't worth wasting time on at the moment. More importantly, they will evolve substantially once we start figuring out the fun in the core mechanics.

So who is up for some quick prototyping fun?

take care


Here are the source graphics for the prototype. Use and abuse as desired. Again, if you come up with something interesting, drop me a note at danc [at] lostgarden [dot] com. For this challenge I'm happy to post both wacky failures and successes. It is the learning that matters.
2D collision
If you are interested in simple 2D collision and don't have such code lying about already, here are some articles:
  • Stub: A simple system that will typically become replaced by a more complex system in future versions. Most prototypes have a few stubs since your goal is not to build a complete game, but to test a theory.