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


  1. dammit, Dan, I thought I was done with SpaceCute and could move on to other projects. Now you've given me dozens of additional ideas to incorporate into it, and a lot of them are really good!

    Today's captcha word is "oinqzsc", which is what pigs say in the Czech Republic.

  2. Hi there,

    I'm done with my second prototype. First of all let me say, that I that my prototype isn't the most polished one. That's actually on purpose though. In my humble opinion early game prototypes should be mainly used for testing gameplay ideas. Implementing fancy particles effects or other purely visual effects at this stage, will only slow us down and hinder us from experimenting. So far I like Huntys prototype best.

    There are two main observations that I've made from my last prototype:

    1) The ships will probably have to be scaled down considerable to make the playing field interesting enough.

    2) Bumping into other ships just for the sake of destroying them wasn't really fun to me..

    I tried to incorporate these observations into the new prototype. You can download it from here:

    I've also included the python source code this time.

    Here's the README:


    --==SpaceCute Prototype 0.2==--
    created for the prototype challenge


    Code: Riad Djemili (
    Graphics: Danc (
    Background song: "gnome ballad" by Brioskj (
    Sound effects are from


    Run the game by clicking on "spacecute.exe"


    Your goal is to collect as many stars as possible. Once you've collected a
    number of stars trade them in by bumping into the planet. Yellow numbers show
    the number of rounds that are left until a new star will appear at that
    position. The stars are worth 1-3 points depending on their size. With every
    star that you collect a internal multiplier raises and your cargo becomes
    even more precious. So try to grab as much stars as possible before
    delivering your load to the planet.

    Watch out though! Every ship is guarded by a shield that faces to the front.
    If you're hit from behind you'll lose all your current cargo.


    You can change levels by pressing the numbers keys 1-4 and reset a level by
    pressing 'r'.

    You can customize the game by editting the game.xml . Every level-elements
    represents one level. The stun-attribute corresponds to the number of rounds a
    ship will be stunned when being hit from behind. The moves-attribute
    represents the number of ships that are allowed to move per round. The
    starSpawn-attribute can be used to designate a special area for spawning of
    new stars.



  3. I like this, Riad! It turns it into a mining/farming game rather than a combat game, like a cross between M.U.L.E. and bumper cars.

    Today's captcha word is "kbzjgo", the title of a little-known Stephen King novel about a rabid banjo.

  4. oops! That was me! I need to change my blogger profile.


    So this is the latest version. It's less complete than the last in a bunch of ways, but I'm really slow at this. There's important info in the readme file. Hopefully this works for most of you, since I switched to an external library for the physics. Gamemaker can be funky.

    From here on out I think I'll be focusing on my “Map2” version of the game, where the goal is to guide your Princess to a flag without her being destroyed. On both maps, you're the beetle units. Hunty had the right idea by making the game two player (w/o AI). I may try something similar since Gamemaker has some basic networking functionality built in. I was also going to do a “Hot Potato” bomb mode, but without decent AI it's kind of pointless.

    NWN2 is having a module making contest, so I'll be busy with that the next two weeks. After that, I'll be back on SpaceCute. I may give up Gamemaker. Any suggestions on what language or libraries I should pick up if I start from scratch (ughhh) again? It's been a long awhile, but I have experience in C, C++, and assembly. However, it was in a text based environment. I don't have any experience in Windows programming. Can any of the smart programming types point me toward some beginner AI info? I'm not sure how helpful it will be (since AI seems highly specific to each game), but it's worth a shot. Most of the stuff I've found hasn't been very accessible. I was thinking of using an adjacency list of objects on the map, since that would not only let each unit know what's around it, but also allow the unit to more easily determine “combos”, etc. Populating and maintaining that using Gamemaker though isn't that easy.

    Danc: I had a quick art question. How would you suggest maintaining perspective and scale when creating ¾ view perspective tile based graphics? I was thinking of using a grid layer with a bounding box, divided up into height segments, to act as a guide. I'm not sure if that made any sense.

  6. mordrak: I recommend using XNA for Windows game programming because it's very nice and simple and straightforward. It's what I've been using lately for Windows games. The only downside is that you have to learn C#, which is kind of funky, but not too bad if you already know C++ and/or actionscript.

  7. Riad, nice update on the prototype. :) The I liked how the shield changed orientation based on the direction.

    Hunty, thanks for the advice. Unfortunately XNA is XP only and I recently switched to Vista. Arg. First my tablet stops working and now this. I'll probably stick with GM then, though reinstalling XP might not be a bad idea.

    Hopefully MS will add Vista support soon.

  8. Hello Danc

    This is completely unrelated to your current post.

    I love your article on the Wii Help Cat and I would like to quote you in my thesis on videogame secrets. While I currently have you cited as "videogame designer Danc". I would like to give you proper credit if you would like it (if you would like to remain "Danc" that is fine as well)

    My email is


  9. It would be interesting to see if "chaining" might be implemented - like how in bejeweled you can get multiple matches in one move.

  10. A few more ideas:

    1) warps - wormholes in space that warp you from one area to another
    2) boosts - when you collect this type of star it immediately boosts your velocity once again - can be chained.
    3) mines - explode upon collecting - do no damage but kick the ship backward - neutral in that they would explode for either team
    4) seekers - small bots that attach to enemy ships and increase the 'drag' - meaning limit the distance one can fly in a turn. Must be bounced off or knocked off via a mine.
    5) gravity wells - if used correctly can slingshot player further. Otherwise can be caught in well and "stuck" until next turn.

    6) tractor beam - can drag along another player or same team in an elastic way (think the player and girl in Ico)

    7)time warp - upon hitting would reset all events that that player's actions just conducted.

    8) freeze beam - temporary freeze another ship for 1 turn. Bumping it knocks off the ice.

  11. Mordrak, I'm using XNA Game Studio Express on my Vista laptop and haven't had any issues. It's not "officially" supported yet, though. And I think you have to be running with Admin privileges. But still, been running it for over a month with no issues. I followed the following link to get it working:

    I hope this works for you.

  12. My initial prototype:

    Does have:
    o) Moving & colliding ships & planets.
    o) Gravity (ships & planets orbit planets and stars)
    o) Ship health

    Does not have (planned):
    o) Sound
    o) AI
    o) Heart pickups to replenish health
    o) Explosion on ship death

    To run:
    Make sure DirectX 9c is installed, extract the ZIP, double click the EXE.

  13. Another addition of an idea.

    During a game-play round or movement turn there are little options to make for choosing which ships to move and how much force a ship can move each round or movement turn. This gives the players very few strategies to make and once one has come up with a winning approach the idea of strategy is eliminated for the covenant solution to winning.

    The idea is to give each ship a simple mechanic to regulate the movement of each ship and how much the ship can move in a given turn. Now the idea is just that an idea.

    First give each ship a new variable. For the sake of this we will call it power.

    Now that each ship has power we can say that it has 100% power.

    So now to move your ship you are required to use power. I.e. to move at maximum velocity you must use 100% power.

    Now to regulate power, at the beginning of each turn, each ship will gain x amount of power back.

    This will make choosing which ship to move and at what velocity more of a careful choice rather then which ship can I move there first or fastest.

    This could be used in two more extended concepts.

    The first extended idea would be that the amount of velocity would equal the amount of damage. So a ship traveling at 100% power would deliver 100% damage and a ship traveling at 40% power would deliver 40% damage.

    This would introduce a dynamic way of dealing damage to another ship.

    Would you rather spend a ships power dealing all damage or would you rather deal half damage with enough power left to move to another object or goal.

    You would also see patterns of movement where players would use half of each ships movement to deal damage overtime and then leave enough to move or attack again.

    At the same time, Hope I am not going out of bounds, but again just an idea. The power level of a ship can be its defensive level. I.e. 100% power would mean 100% defensive bonus.

    You could then make ships with different power levels allowing for heavy hitters, fast movers, and defensive units. Creating a more rock, paper, scissors game.

    Just an Idea. From a bored designer.


    Feedback and creative criticism can be sent to

  14. Prototype 0.2 -
    Adds some of the power ideas, along with config files.

  15. Corsix I am getting a runtime error on your current build.

  16. 0.3b -

    Fixes runtime error, things happen faster, collisions = points

    (Source code for anyone mad enough to look - )

  17. Hi, Dan!
    I've implemented the SpaceCute prototype, get it here:

    I've changed some rules and exported lots of tuning values into INI file so you could play with them. Check the readme.txt for complete description.

    Looks pretty much close to a small finished game. It would be fun to finish it, so call me :)


  18. Thanks Bigweather. I'll check it out once I'm back on SpaceCute.

  19. A few random thoughts/ideas:

    I actually tried prototyping this in Game Maker. Several times. Great tool for MOST simple things like this, and it handles collisions between a moving object and a stationary object well enough... but billiard-ball collisions aren't handled at all, and I can't seem to find the physics equations in my Phys 101 textbook to do it manually. (The C++ code didn't help either, unfortunately.)

    Two ideas for those making their own prototypes:

    1) Black holes that swallow ships whole. This makes the game slightly more Billiards-like -- think "pockets".

    2) Planets that can be "captured" by having your own ship land within a certain nearby distance of the planet, checked at the end of your turn. Planets that you control can give you resources. This gives players an incentive to not use maximum velocity on every move.

    2a) You could implement pickups in the same way: you only get the powerup if you land on/near it, not just if you pass over it.

    Amazing project so far, by the way!

  20. Wonderful new prototypes, folks!

    Very professional, haaf! BTW, I wasn't familiar with your engine work...looks nice.

    Corsix, good progress! With the power idea implemented, it starts feeling close to a RTS, where power acts as a timer for when ships can move. Very interesting...keep pursuing the path you are on.

    Mordrak: The 'save the princess' is interesting! I have an update of the graphics shortly that should make it move obvious where collision occurs. You might want to play around with tightening up the core movement mechanic.

    Nice work and good ideas as well,

    take care

  21. Hi folks! Long time reader (came with the Great Penny Arcade Influx), first time writer. Great to be here.

    I've played just about all of the prototypes, and one thing keeps coming to mind: the graphics for SpaceCute really don't match the game. Think about it. The basic gameplay is really Space Billiards (or Minigolf), but none of the player tokens are even close to being circular (or elliptic, never mind the perspective now)! I know there are rings around the ships, but I say that's a crutch. In the current version of SpaceCute, the pretty bugs and rockets don't mean anything. The thing that really matters is the collision rings beneath/around/inside them. Those are, for all intents and purposes, the actual ships. So why not make the game far more intuitive and design the ships to be circular from the start? Cute little old-school UFOs come to mind, but the details aren't important.

    The players will (and should) expect their ships to bump with their bumpers, not at some arbitrary point. I shouldn't have to mention how much easier it would be to plan for trick shots or tight passages when the spatial relations are obvious. (Ironically, the biggest tokens in the game are circular and aren't under player control :-)

    I know at this point you're already a bit far in development, but I want this game to be the best it can be, and I believe proper circular ships would be a big step in getting it there.

  22. @mordrak:
    Even better news! A new version of XNA has dropped and it now officially supports all versions of Vista. I got a link to it from, I'll dig it up when I get a second, but you probably already know where to get it from.

  23. Totally unrelated, but look what I found :)

  24. I think it would be more challenging and less of a point and launch hit after hit thing if you pulled in the opposite direction. That would make aiming much more difficult and there would be a chance of missing. Just a though after playing some prototypes.

  25. @bigweather:

    Thanks for the update, I'll check it out, but this will probably be the end of the game design road for me. Hehe. I'm going to try imitating something more within the bounds of Gamemaker's abilities before I try to create something new. This also means I'll have to abandon these wonderful graphics for my chicken scratch.

    @Ian Schreiber:

    I'm surprised I was able get such an atypical mechanic to work, but 95% time I used GML, Gamemaker's scripting/programing language rather than its Drag and Drop mechanisms. If you want, I can email you my Gamemaker files so you can see what I did.

    mr DOT mordrak AT NOSPAMgmail DOT com

    Remove NOSPAM of course.


    Thanks for the feedback, articles, and the challenge to begin with. At least it got me off my ass to actually try and do something.

    Great prototypes everyone, can't wait to see the future versions.

    Signing out,

  26. A while ago I came across this game using similar mechanics - giving planets gravity and such could open up some very interesting physics to play around with!