Sunday, October 2, 2005

Space Crack: A gift prototype

What a pleasant surprise. Michael Bayne of Puzzle Pirates fame dropped me a note that mentioned he had created a prototype of Space Crack in his spare time. You can find the Java applet here. He used his game creation system Game Garden, demonstrating once again the benefits of using established middleware in the rapid creation of a prototype.

You'll need a Game Garden user name and a friend to try out the game. The whole thing is in a gloriously raw form so feel free to apply your most creative game critiquing skills. At this stage the designer is doing almost as much designing on the fly as they are polishing. What would it take to improve this prototype and make it enjoyable to play?

Some areas of interest when doing early prototyping

  • User Interface: UI may seem like a polish level detail, but it can have a major impact on the way that the game is played. In essence your UI is concrete implementation of the verbs and feedback loop for your core game mechanic. This is important to get right, especially in games where the 'feel' of the action forms a critical aspect of the core mechanics reward.

  • Rhythm of the game: Is there an established rhythm of actions and rewards to the game?

  • Player choice: Are the core mechanics generating interesting strategies and situations that cause the player to make important choices?

  • Balance: Are the various variables that affect the game adjusted correctly to allow the other major factors a chance to be judged effectively?
The Brain Storm
At this early in the prototyping phase, I will often use a simple brainstorming technique as a means of jump starting the accelerated evolutionary design process.

  • Step 1: Jot down a list of 20 or so problems as I play. Often a simple notebook with a phrase or two per issue is enough to capture the problem areas.

  • Step 2: Go back and think up simple solutions to each one. Often new game mechanics will emerge that solve multiple problems in one go.

  • Step 3: Prioritize the list into ‘Big problems’ that represent fundamental game play issues and ‘Problems’ that are annoying details that need to be fixed.

  • Step 4: Magically implement all the things you’ve jotted down. If you don’t completely rewrite the game from scratch you are either very lucky or you’ve not been nearly critical enough with your first prototype.

Here is the list that I came up with for the Space Crack prototype. I apologize ahead of time if this is stunningly boring. Game design, like it or not, is a process of a thousand details and decisions.

UI issues
Big Problem: In the UI, you can either select the space ship or the planet. This leads to some confusing situations where you think you are clicking on the planet, but you are instead clicking on the ship.

  • Option A: Move the ship icon so that it is adjacent to the planet. This makes it far less likely that you will click on the wrong token.

  • Option B: Clicking on a planet with a ship automatically highlights the adjacent planets that it can travel to. Clicking on a highlighted world makes the ship travel to that world. Click anywhere on the map to deselect the current planet.

  • Option C: Drag a ship onto an adjacent planet. This gives you a more tactile interface and also avoids confusion.

Problem 1: Players don't know when they run out of command points

  • Make command points a much larger counter that sits at the upper middle of the screen.

Problem 2: You don’t realize that you are spending command point.

  • Create an info bar at the bottom of the screen that tells on roll over how much a particular action is going to cost. For example “Attack enemy: 1 command point.” With a little smart graphic design this could be incorporated into an on screen area that also includes the list of resources.

  • You can also have a report that says “You cannot afford this action. You are out of command points” This can be spiffed up with more interesting text at a later point.

Problem 3: You don’t know how much a ship costs

  • The info bar is again useful here. When you roll over a planet that does not have an attack stack display “Click here to build a level X ship for Y crack”

Rhythm Issues
Big Problem: The game really feels like an RTS game. I felt like I needed to move very quickly in order to get my moves in. This rushed feeling is not the joy of a turn-based strategy game. There are a couple issues here that I’ll split out in sub-problems.

Problem 1: Turns begin without you knowing. The result is that the game feels like one long drawn out RTS.


  • Put a dialog box up when a new turn begins. Tell the player specifically who is ahead, how much new cracks you have accumulated and how many command points you have left to spend. The player must click 'okay' in order to go.

Problem 2: It is difficult to tell when your turn has ended. Currently the turn ends automatically when you run out of command points. In theory this is good, but in practice you never know when your turn is over.

  • When you run out of command points, a button appears on the screen “End Turn”

  • Clicking the button ends the turn and causes an update phase to occur. We should use this opportunity to include another risk / reward cycle.

  • When the turn ends, the map highlights all the goodies that you are going to get on the next turn. Numbers appear above all the planets showing your how much crack you’ve gotten. (+3!, +1, etc) Your ships are produced.

  • In the future, this phase could be quite the extravaganza. The camera could pan from spot to spot with twinkling bonuses appearing one after another. All that potential loot just waiting to be exploited when the next turn starts!

Problem 3: Building ships is easy and not very rewarding. I was quickly clicking to build ships and then not really thinking about where I was building them.

  • Some of this is due to the pacing problem of the turns. However, the lack of anticipation in getting a new ship is most unfortunate.

  • Add a new state to ships that is the ‘building’ state. Ships are not built until your turn is ended. When you hit the end turn button, the ship is built in a lovely little sparkle. Or not (since this is a prototype.)

Problem 4: Combat is no fun. You click on an enemy and he dies. There is no anticipation and no retreat if you misjudge.

  • Combat takes multiple rounds. You can click on an enemy and attack and you both do a certain amount of damage based off the size of your ships. This provides stronger feedback to the player that their actions are having an effect.

  • The damage done to your ship is shown a little floating numbers.

  • You can spend additional command points to attack again.

Balance Issues
Problem 1: There are too many command points. The player does not value them as the precious resource that they are.

  • Reduce the number of command points

  • Create an info bar at the bottom of the screen that tells on roll over how much a particular action is going to cost. For example “Attack enemy: 1 command point.” With a little smart graphic design this could be incorporated into an on screen area that also includes the list of resources.

Problem 2: There are a large number of collisions between players trying to attack similar places at the same time. A lot of this has to do with players being able to do a huge amount in a single turn.

  • Most of this should be solved by reducing the number of command points.

Problem 3: Players accumulate too much crack. This makes ship buying trivial

  • Reduce the amount of crack that you get per turn from each ship.

Player Choice Issues
Big Problem: The map lacks structure. There are no major points of strategic interest to attack or defend. All paths between planets are open at any one time.

  • Let’s start experimenting with limiting the path ways between planets. Each planet is randomly connected to 1 to 6 other planets. All planets are connected to the whole. This should give planets a little structure.

  • Only some planets can build ships. Any planet above a class 6 planet has a different color outline and can build ships. This adds strategic points of interest.

Problem 1: It would be nice to present the player with the decision of whether to explore or defend. Currently a player can take a single ship and travel the entire galaxy.

  • Let’s take a rule from the Risk handbook. A stack must always leave behind a single defending ship. This reduces the power of the stack by one if the planet has no ships on it.

  • We end up with two types of stacks. There is an Attack stack, which is any stack with a power of 2 or higher. There is also a defense stack, which is a ship with a power of 1.

Problem 2: The game is limited to two players

  • Let’s get it working with 2 players first and then we’ll go from there.
Conclusion
Many thanks go out to Michael for the great prototype and the opportunity to tear it apart in public. If you haven’t checked out Puzzle Pirates or Game Gardens, I highly recommend that you do so. Here is a fellow who not only is profitably building independent, highly innovative MMOs, but also is opening up his source code to the world so that other developers can get a leg up on the whole situation. Where is that honorary town key when I need one?

Avast, me mateys! Haul yer landlubber arses over to the Space Crack prototype before I make ye my peg boy! Or something of the sort.

Take care,
Danc.

PS: Link to the prototype: http://www.gamegardens.com/gardens/view_game.wm?gameid=26

1 comment:

  1. Perhaps the prototype doesn't meet your original design doc in a couple of ways.

    To keep it from becoming an RTS, I think you need to make ship movement resolve simultaneously at turn end. Allow the player to queue up multiple movements with the same ship if necessary. In this way, moving earlier in the turn does not constitute an advantage. This also introduces the possibility of battles in "hyperspace" while travelling between planets.

    Named planets, fleets and (optionally) ships would be a nice touch for future versions, and would help with messaging ("Your 2nd Fleet encountered JoeBob's 4th Armada while travelling from Altair to Orion!"). In addition, this gives the player a sense of ownership.

    I also think that the ship-combination feature is a little too abstract. It introduces a restriction that people are likely to chafe under, and creates the possibility of "traffic jams" (not fun).

    A small "fleet management" panel wouldn't introduce much overhead, and would not be an obstacle to picking up the game, as it wouldn't be essential to winning the game. In this panel the player could combine ships to create larger ships (slightly more effective than the sum of their parts), or divide their fleets to different locations.

    So the game would work similarly to how it does now, except that (1) players could split fleets if necessary, and (2) players can get a bonus to their fleet effectiveness by combining ships, at the expense of tactical flexibility.

    Lest one complain of complexity, this is about the same order of complexity as Risk - i.e. not that complex at all.

    BRAINDUMP: Consider the possibility of a "counter-based" interface as follows:

    - The mouse cursor acts as a hand. The individual ships in the fleet management box are represented by counters of various sizes.

    - Dragging the mouse will "accumulate" ships, similar to scooping up a bunch of army counters in Risk. Then you can drop them onto a target planet, or into a separate box where you can give them a "fleet name" (2nd Armada, whatever).

    - Dragging the ships onto a scaffold/spacedock icon (?) combines them into a big ship.

    A turn clock would help too.

    Have you played Metal Knights, by the way?

    ReplyDelete