Wednesday, April 11, 2007

SpaceCute: Extending the verbs

There is one nearly idiot proof input gesture at the heart of SpaceCute. You drag and release. One would imagine that such limited input leads to limited game play. In fact, when I originally came up with the idea, I was imagining how a simple casual game mechanic might be extended to create an interaction model nearly as complex as something like NetHack.

It should be possible to build a SpaceCute prototype that extends the game mechanics with additional verbs that use the same core gesture. I've provided a few examples to spark the brain.

Elegant controls
In physics there is a concept of 'elegance', which can be loosely paraphrased "What is the simplest model possible that explains the most robust set of phenomena?" The concept of elegance can be applied to games as well. An elegant control mechanism gives the user a rich user experience with the smallest (but no smaller) set of inputs. Go, for example, has a highly elegant interface. Steel Battalion, with its gigantic uber controller, does not.

Elegant control designs often possess the following benefits:
  • They are easier for new users to pick up.
  • They can be ported to a wide variety of different platforms
You can easily extend simple gestures into a highly diverse and expressive set of verbs. Hunty's SpaceUgly is a great example of how adding just a couple more verbs such as 'collect' and 'spawn' beyond move and attack can help create a far richer play field. Kudos to him for making that conceptual leap. He's got designer blood. (Though hopefully in his veins, not a plastic jar in the cupboard)

As a demonstration of this technique, I'm going to list out a plethora of possible verbs that could be derived from our base mechanics.

We started with a rather expressive basic verb that can convey both direction and force. By itself, it is rather boring since there are few opportunities to link it into more complex systems. Here is how some common game specific verbs map onto 'move'
  • Move in a particular direction.
  • Move a short distance
  • Move a long distance
  • Cancel a move (Have a small buffer zone at the beginning of the drag that acts as a 'cancel')
With collision we introduce a simple event that lets us know that we've interacted with another object. Now the computer knows "I've got object A, object B, and a force vector" You can now write any game mechanics that takes those variables as input. This alone opens up much of the world of gameplay. Here's how some common game specific verbs map onto 'collide'
  • Bounce: You can move another token by bouncing into it.
  • Bumper: When you hit this token, it imparts a greater reactive force to your object. Think of this as the bumpers in pinball.
  • Barrier: You can block an area or create a tactical terrain obstacle with an object that just sits in the middle of the screen. With this we've introduced the beginnings of static level design. Planets work like this.
  • Damage an enemy ship: Hurt someone! Not surprisingly, most game designs go here first.
  • Heal a friendly ship: Really, we are just changing a number. You can just as easily heal someone.
  • Steal resources: If you can give, you can also take. Think vampirism.
  • Gain experience points: A unit can earn resource points simply for causing a change to occur to another unit.
  • Combo: Hitting multiple objects in a single move gives some additional reward
  • Transfer an object that is being held to another ship: If object A has a powerup or item, it can hand this off to object B when the two collide.
  • Change the state of either object. For example, one object could become 'mad' which boost hits points and make it move more quickly.
  • Collide with force: Since move implies a force, large velocity collision can cause more damage than soft collision. In fact any change of state that has a continuous key variable can map that variable onto the collision force. What happens if you linked the collision force to the radius of the object? Now you have an object that temporarily blows up like a balloon when hit hard and leaves a trail of mayhem in its path.
A subset of collide is collecting. Instead of bouncing off an object, you pass over an object and perform some action that removes an object from the board.
  • Grab a resource: The stars in Hunty's game are an example of resources. When you pass over a star it is removed from the board and added to your resource counter for use at a later date.
  • Grab a powerup: You can also grab a new ability that is applied to your individual ship
  • Grab a meta-powerup: You could grab a new ability that changes the rules of the board. For example you might collect the 'molasses' powerup that causes the next player's to be bogged down by high friction for a turn or two.
  • Collect a warp token: Once you go meta, you can never go back. It is easy to imagine a series of levels, each with collections of unique powerups, units and resources. In every level there would be a warp token or two that takes you to another level. Now you can create entire SpaceCute universes.
Area blast
Another natural outgrowth of collision are area effects. When a unit comes to a stop, it creates a blast that is wider than itself. This introduces the ability to affect multiple objects in a tactically interesting manner.
  • Collide style interactions: Many of the collision interaction work for area blasts as well. You can imagine group heal, group damage, stealing resources and changing states work quite well.
  • Group push: You can use your physics to push units caught in the blast away.
  • Group pull: You could also pull units caught in the blast inwards. This is a great setup for massive collision combos aka "pack 'em and smack 'em"
So far we've been dealing with simple properties of self contained objects. Adding features to the terrain is also interesting. A vector field pulls an object in a particular direction as it moves over the field.
  • Hills and valleys: A ring of vectors pointing towards its center does a rather convincing simulation of a hill. The reverse creates a valley.
  • Rollercoasters: You can create interesting currents the pull ships from one location to the next.
You can also implement some more advanced simulation in which an object effects another object's position at a distance.
  • Gravity: Objects attract one another. A popular feature though it adds a bit of randomness.
  • Repulsion: Objects repel one another.
  • Fear: When you apply repulsion to individual objects, you can simulate a unit fearfully running away or retreating. By setting a min velocity that triggers the fear behavior, you can enable sneaking tactics.
  • Flocking: With almost every game design I end up asking "How would I turn this into a sheep herding game?" It is a personal quirk and is only peripherally related to flocking. Units that follow a particular unit can add a dash of personality to the game. They can be companions, predators, chattering crowds of worshipful children, etc. Or perhaps even sheep. If that is your thing.
If flocking physics are too complex (or chaotic), you can create remarkably rich level design with stationary sensors that trigger state changes.
  • Word bubbles: Imagine that you have a character on the screen. As your unit zips past, the character pops up a word bubble. An entire RPG-style conversation system could be built with this technique alone.
  • Mines: If you get too close to a mine token, it goes 'boom'. Combine this with an Area effect for hours of pleasure.
Units that spawn new units adds an incredible amount of depth to the game, especially when combined with a resource model. Now the player can build the level as they play.
  • Fighter factory: A base can launch ships.
  • Mine seeder: A ship can leave mine behind as it goes on its merry way.
  • Powerup launcher: You can launch powerups or health bonuses at friendly ships
  • Missle: A missile station launches small missles that explode on impact.
An extension of spawning is the multi-spawn object. This allows you to have a single object that can perform multiple tasks. It can move by dragging on the main body. It can also perform individual actions by dragging on one of the attached nodes.
  • Mother ship: A mother ship might have the ability to launch a missle at attacker or build a new attack ship or fir
  • Self replicating missle station: A missile station might produce very low cost missle out of one bay. Out of another bay, it can launch a new missile station for a much higher resource cost.
Combining game mechanics
All these verbs can be combined to create more complex systems. For example, when you combine 'transfer' is combined with 'collection', you can readily build either a basic inventory system, the ability to purchase items, or of course, capture the flag. Word bubbles + simple combat + warp gates gives us an exploration-based RPG.

The combinatorics are quite dizzying. We've expanded the possibility space beyond the simple core mechanics into a much more complex and interesting realm.

The point
We could go on inventing verbs like this for quite some time. I suspect you can come up with quite a few more that I've missed. :-) Pick a few and prototype them. Be sure to create a complete game mechanic with a verb, system of effects and clear feedback to the player. The best mechanics will give tools to the player that help them manipulate your gamespace in order to reach their higher level goals.

The big lesson in this exercise is that that a simple input gesture in SpaceCute can lead quite naturally to massively deep game play on par with many mainstream genres. You do not need a complex control scheme to build an intricate and involving user experience. So what if some random controller has more buttons. Give a competent designer a simple control scheme and they can build up an entire world of wonderful experiences.

I find that it is easy to build up some rather fascinating toys at this stage of prototyping. If anyone feels to urge to try some of these ideas out, I'll be happy to post whatever your experiments yield.


Related links

Graphics files for prototyping
Includes PNGs and original .design vector files for use in Expression Design

The first crop of SpaceCute prototypes:

The original Spacecute Challenge

Saturday, April 7, 2007

SpaceCute: First round of prototypes and new graphics

The initial round of SpaceCute prototypes are in and results are encouraging. Both basic movement and some initial combat was prototyped. Each one of these guys is a prototyping superstar. It is educational to see all their different interpretations of the starting concept. You can download their glorious efforts here:

New graphics

I've also provided a new set of graphics that include more 'cute' faces and one new ship (inspired by Vorlons.) You can mix and match hair and and accessories to get the look you desire. Download the latest set, complete with PNG and original .design files here:

Answering the big questions
You can think of prototyping as a pseudo-scientific process of experimentation. For each prototype, you are looking for the following:
  • What is the main question the prototype is seeking to answer? Often you'll think you have a good game mechanic, but you don't actually know until you try it. Postulate a question that you hope your prototype will answer. For example "I think using mini-golf game mechanics will make movement in a strategy game more enjoyable and interesting. Is movement fun?"
  • Did the prototype succeed? Test the prototype and answer your initial question! These should be simple Yes or No answers. One of the most common problems with design is that we come up with intricate theories and then fail to test them until the very end of production. Play test early and play test often.
  • Lessons learned: In reality, prototypes goes through dozens of iterations and the designer tests out many different ideas. These lesson help you understand what to keep and what to kill.
  • Opportunities: Were there any interesting opportunities that emerge that cause you to want to make more prototypes and test addition issues? Games mechanics are almost always complex systems that operate on the fuzzy boundary of our limited human ability to predict their behavior. If an unexpected behavior of your prototyped system delights you, it will likely delight players if wrapped in a proper set of feedback and rewards.
With this framework in mind, let's look at the prototypes. Our two big questions are "Is moving fun?" and "Is combat fun?"

Is moving fun?
I think the answer is yes. I spent far too much time flinging space craft around the board despite there being little reason. This is one of our lowest level game mechanics so it is important to get it right.

Moving lessons
  • Harold added sound to the movement. This increased the pleasure of flinging ships about quite nicely. Multi-channel feedback is good for increasing the impact of feedback.
  • Short pull distances that result in long throws were more enjoyable than long pull distances with short launches. It adds a bit of unexpectedness to the actions.
  • Dragging small amounts hides the cursor under the character. Making the ship semi-opaque fixes the problem. So does setting the 0 point past some initial distance from the center of the ship.
Based off the various prototypes, it feels like movement is pretty solid. There was one interesting variation suggested:
  • Pulling back vs. pulling forward. I hear that Bonder is working on a sample to try this out. I'm looking forward to seeing it. This also would solve the hidden cursor problem. You should watch out to see if there are problems interacting with walls.
Is combat fun?
In general, combat is only mildly fun. Ships bonk into one another and slug it out, but player choices don't seem all that interesting. Combat suffers from a typical problem that strikes almost all prototypes at some point:
  • Outcomes are highly predictable
  • Player choices are limited.
  • Riad's simple AI is quite vicious. It pursues you and whacks you at full force. It is a good stub for now. Harold implemented a variation where a random ship is chosen to move each turn. This avoids some of the dogged bash fests that occur when the AI select only the closest ship.
  • Mutually assured destruction isn't fun. When both tokens are hurt in a collision, the optimal strategy is to let the other guy bash himself against the planet. :-) In Ben's model, you don't take damage if you attack. This feels better.
  • Momentum transfer: Harold has also been playing a bit with the elasticity of collision so that when an attacker rams into a ship, you stop and the defender gets most of the momentum. This has promise for creating chain reactions.
  • Planning complex collisions is also hard. You can't see exactly where pieces are likely to collide. I may need to reworks the graphics so that this is more obvious. Ben implements a nice transparent circle that could highlight on those tokens within reach of the selected ship.
  • Folks are using 100% thrust most of the time: There is no reward for using subtly
The obvious step for most of the prototypes is to make combat enjoyable. Folks are building up some lovely engines that are capable of all the basics such as collision, movement and state changes. This is where the engine programmers get seperated from the game programmers since most of the upcoming work deals with very little technology and a whole lot of tweaking of game systems.

I chose the following opportunities for combat based of these two criteria:
  • Give the players interesting choices
  • Introduce surprising complexity into the outcomes.
Add a turn button: I perhaps simplified the initial design too much. It is worth prototyping up a turn button that allows you to move all or some of your units during your turn. Does the players strategic options increase dramatically?

Collisions need a little pizazz: Currently collisions don't let you know that something interesting happened. Having the unit flash red (and fade back to normal) or having particle spit out of the collision point could help. Mordraks particle effects or Ben's floating heart are great ideas that could be extended to the collision feedback. The sound effects help immensely. Is collision feedback delightful?

Every Extend style explosions:
Let's introduce a new type of ship that explodes when it comes to a complete stop. The explosion expands in a radius and damages ships caught within. If the bomb ship hits another ship, the explosion will fizzle. If the bomb ship hits a planet or wall, the explosion does not fizzle. Are skilled placement of shots, including bank shots, useful?

For the explosion, you can use a simple expanding circle with particle effect. Be sure to make the ships give the user feedback when they are hit. Woot, unit type number 2.

Resources and Powerups: One common technique to make a mechanic interesting is to tie mastery to the acquisition of a tool or resource. Imagine that ships spit out stars when smacked. These stars are sucked up by close by attacker ships and act as resources. Get enough resources and one of your ships randomly gets a powerup for a turn or two. Simple powerups include "super mass" that sends enemy ships (and planets!) flying, or perhaps "Astroglide" that lets you zoom extra long distances.

Now we have an interesting opportunity for rewarding combos. When players do multiple points of damage, they get star multipliers. When a ship finally loses all its hearts, it bursts into an explosion of stars. That means more powerups and more interesting choices.

Other notes
  • Folks feel violent combat doesn't quite fit the SpaceCute setting. I was imagining combat in the Mario sense of the word. Stars fly out, not blood. There are some conversation and questing meta-mechanics I'd like to see, but those are or much, much later.
  • The use of a text file for storing all variables was of great use in rapidly testing different configurations. The XML based file used by Riad was particularly promising since it allowed quick and rapid iteration of map design as well. This allowed me to test a 10 enemy scenario with relative ease.
I'm sure you have other ingenious ideas. Go for it! Post them in these threads. If you haven't submitted your prototype yet, no worries. Steal the best ideas from the other guys and try your own twist on the concept. There are tons of options that haven't been tried. And above all, play the is a great opportunity to give some real critiques of games in progress.

As a side note, SpaceCute didn't exist as a search term a little while ago. Now Google has 308 references. I figure I'll just keep making graphics and pimping your prototypes as they come in. My hope is that overtime SpaceCute is only going to get bigger and more pervasive. (Isn't this is a lot of fun? :-)

take care
"Space is cute."

PS: The original challenge

Wednesday, April 4, 2007

Free game graphics: Tyrian ships and tiles

I stumbled across a personal treasure this weekend. Tyrian, the ancient vertically scrolling shooter from long ago still happens to have a fansite. While browsing through their forums, I noticed that Jason Emery, keeper of the Tyrian flame, had made the source code available and folks were actively digging through it.

My thanks go out to whoever ripped the graphics from the source code and posted them as PNGs. Somewhere in the mess of moving multiple times in the past decade, I managed to lose the original files. The freshly ripped files have some transparency errors here and the order is a tad confusing, but I am delighted to have copies again.

Hot summer, great job
I drew up the original graphics in about 4 months as my first real summer job. A friend of mine who shall go by the pseudonym "Ray" had sent around some of my artwork (without my knowledge, I might add) and I ended up getting a random email from a very young Alex Brandon asking me if I wanted to make some graphics. It was either that or another summer stocking beer in the 7-11 cooler. 19 and making games. Heck yes.

I had recently splurged on an Amiga 1200 and it managed to pay for itself that very summer. Alex sent me a short list of list of levels and said "Draw us some graphics." So I did. I turned up the radio and crunched away from 11am when I woke up to 11pm when David Letterman came on. There is some wierd stuff in there as a result, but no one ever complained. They just said "Make some more!"

Remastered and free
In hopes of contributing back to the great and eternal indie scene, I 'remastered' the graphics by removing some of the conversion dirt that had accumulated. Man, I haven't done pixel editing in years. I also took the liberty of stripping out as the various 'non-Danc' flesh-colored seahorse graphics that managed to make their way into the tile set. I may not have gotten all of them, so credit likely goes to Jason for the lovely hotdogs, etc.

I'm making the set available for using in your games, prototypes, animations, etc. Again, use and abuse them as desired. If you make something cool, let me know! Feel free to link back to this page so that others can grab the graphics and mess about. It is good to share old pixel graphics. :-)

And to think, all those hours of effort fit easily into a little more than a meg of pngs.

Download the files here
Remastered Tyrian (1.3 megs)

best wishes,

PS: I'm still missing the store graphics and the cutscene graphics. One day I'll get my hands back on the infamous 'Head on a spike' picture that caused so much consternation.