Stories/Use Cases

Menu

The menu should include options like: audio on/off, a visual representation of the levels (including, for each, a high score/number of stars), and a way to initiate the game from any given level. This visual representation of the levels could be seen as something akin to a Super Mario Bros.-like map. The user can pan across it and see which levels are available for her to play, and which she has yet to unlock, all from that one main screen. The idea here is to have little chrome on the game itself--any level can be opened and played from the main screen.

Level-Based Puzzle

The game should consist of a series of states, represented in our game as stars, planets, or other intergalactic objects. The user has a limited number of fuel cells to choose from, and has to choose spaceships of different types/colors to navigate the state space and reach the goal. The states are an abstracted-away finite state machine, with colored arcs from that state to others representing the movements along the state machine. That is, a fuel cell of one color may only follow arcs of that color. Some states contain stars or other objects required to complete the level. The game consists of a series of levels of increasing difficulty, with some levels having multiple goal states (and thus causing the user to branch off into different levels).

The user must be given a visual indication of the movements of the spaceships along the states, as well as the “loss” of a spaceship at each state. Instead of explicitly representing all possible state transitions, we will make it clear that the absence of an arc of some color from a state means that a fuel cell of that color will then be marooned, or otherwise stuck at that space and be forced to start over.

The user will be given the opportunity to discover objects that add excitement to the game. As the difficulty of the levels increases, the user may have to collect all the stars in the level (or some other object) prior to reaching the goal state. Additionally, we can add other items to represent point bonuses and powerups. Users can compete for the highest score on a given state by the amount of points they get--which will be a function of the number of states traversed to get to the goal state, plus any bonuses found along the way. There will not be a time aspect to this, as the user does not necessarily have to interact with the board while the spaceships move across the states. There may be multiple types of powerups, ranging from allowing the user to choose another spaceship to the ability to “destroy” a state in their path (i.e. skip over it), perhaps some sort of teleportation device that allows them to move to any state incident on their current one, or the ability to remove a spaceship from their input.

The most important use case to consider is that related to the core concept of the puzzle. The end user must be interacting with an abstracted finite state machine of some form, in a series of levels. The other use cases are juice on top of this that, while needed to make the game fun, are subservient to nailing the actual gameplay. The menu is important to design properly, because it can be the difference between the game appearing intimidatingly complex and seeming like something that’s fun to play.

Open Map Puzzle

The open map puzzle is a stretch goal, and thus a very low priority-high complexity use case. This open map translates our conception of the game from a series of levels to a series of places on a map. The user starts at a given state, and can see only so far outwards from there. States beyond this frontier are covered in a “fog of war”, in a way similar to a strategy game like Civilization. Somewhere in this fog of war are one or more goal states, which transport the user to another map of increasing difficulty. This allows the game to be much more dynamic. For example, we can experiment with things like “docking stations”, states where the user can re-equip their spaceships and make another foray outwards. The user may then move multiple times within a given map, as they explore outwards. This does a better job of hiding the underlying finite state machine while still teaching its mechanics, as well as making the game appear more like an adventure game, which would probably be more exciting for our demographic.

Smaller Stories / Use Cases

Fuel Bar/ Choosing Fuel

The user must be given a visual representation of their input to the Finite State Machine. This will be represented by a fuel bar, a bar consisting of multiple segments. Above this bar are buttons colored to represent all possible inputs. The user taps this button to fill up the latest open spot in the fuel bar (a “fuel cell”) with that color. As the spaceship travels, fuel is depleted, which will be visually represented by a “graying out” of the latest fuel cell, as well as the color of the flames emitted by the spaceship.

Fuel Bar Input

The user must be able to select, reorder, and remove fuel cells from the fuel bar. We will do this as follows. Consider the prototype interface for this fuel bar:

The arrows represent the three allowed gestures. 1. Allows the user to remove the first fuel cell by dragging it off the bar. It will then fall away off screen, giving the user some feedback that it was dropped. 2. Allows the user to remove an arbitrary fuel cell by dragging it off the bar, (in the same way as 1.) 3. Allows the user to reorder cells within the bar by dragging it off the bar, and then dragging it in place somewhere else in the cell.

All of these gestures have the same basic workflow: The user drags the cell from the bar. The cells to the right will move over to fill the empty space. The dragged cell floats under the user’s finger. If the user releases, the cell drops off screen. If the user drags the cell back into a place in the bar, the cell snaps in place in this new position. The cells to the right move to accommodate it, and the bar is reordered.

Control Buttons

The user needs a way of controlling when to start and stop the game. We can do this with one button that controls both GO! and STOP actions. Tapping GO! tells the spaceship to run with the given input. STOP allows the user to terminate the run of the puzzle early, if they have perhaps noticed an error in their chosen input.  In this case, the spaceship will return to the start, and the user can choose another input.

As these buttons will never appear at the same time, (you can only press STOP after already pressing GO!, and vice versa) we can represent them by a single button that flips depending on the state of the game. The button starts as a green rounded rectangle with the text GO!; when pressed, the button “flips” to reveal a red rounded rectangle with the text “X” on the other side.

Alpha Implementation--Menu, Loading/Saving

The alpha game must have the basics of a menu that can then be improved upon. Our alpha will have one level, so the menu must simply allow the user to choose this level, and then transition into that level.

The game will be designed for a single user per device. The user must be able to exit the app and have it reload at the same level, with history of levels completed preserved.