(Quick) Game Design Document for the July 13th game

High Level:

Turn-based puzzle game where the player tries to collect a certain number of points before a deadline.

(some) Details

Empty spaces are arranged in a grid.

The player is presented with a goal, which will always be clearly visible: get a X number of points of type A, Y of type B, etc , in some number of turns

There are tiles for each type of point

Each turn, the player selects X tiles with the mouse, and places them in the desired places on the board.

Randomly, between turns, an event may occur which adds additional tiles to the board

After a certain number of turns, the player chooses X tiles. These tiles, and all adjacent matching tiles, are removed from the board, and the player gains points corresponding to the kinds of tiles (so tile A grants point-type A, while tile B grants point-type B)

After the defined number of turns, the player is evaluated: did they meet the goal.

Nice-to-have features (in order of priority)

To keep the scope small, these are features that, while nice to have, can be left out if necessary:

• Persistence
  • Successfully winning should not clear out points, the player should start the next game with those points (and new goals be adjusted accordingly)
• Choices in Events
  • The events should provide the player with an opportunity to make some choice, which will impact the outcome of the event.
  • Choices should be something the player feels comfortable trying to guess how they behave (ie. if you pick "give me 3 tiles", it should put 3 random tiles on 3 random spaces on the board)
• Story in Events
  • The choices in the events should be part of something of a larger story

Reflections

The game originally started out as an HTML5 game, using Photostorm's game framework "Phaser". After spending quite a bit of time just trying to get the core mechanics (grid with tiles that can be dragged onto it), I decided to abandon using this framework. Far too many of my bugs simply failed silently, somewhere deep in the bowels of the game framework. The single most important thing for me, as a developer, is a powerful debugging experience. Athough FlashDevelop's debugger does leave a lot to be desired, it at least will break execution so I can figure out what's going wrong, at the moment it fails. Phaser never did that for me.

Getting the drag and drop behavior in Flixel (the game framework I use in flash) was similarly difficult to doing so Phaser, however, I was able to see what I was doing wrong well enough that I could eventually sort it out. I am rather pleased with the implementation, and I would like to extract it into a common set of classes that allow objects to be dragged (inherit from some generic "draggable" class) and snapped onto specific objects (inherit from some generic "snappable" class). If I want to rapidly prototype card/board-style games, having an easy-to-use set of common components will be key.

Overall, the design and iteration itself was quite smooth. Early on, I made the sleep tile available at any time (instead of only the last 3 turns), and I found that the game played just fine. At that point, I decided re-engineering the sleep to behave as originally intended could be saved for last (and I eventually cut it, as I ran out of time). Similarly, the way I implemented the events varied from the original design, but I found the strategic choice between taking an event (and getting unknown results) vs playing 1 tile exactly where you want it, to be interesting. Finally, the persistence between play sessions was simply scrapped due to time; I typically put off saving until the end, and I kinda crunched (violated my usual Friday-before-release code-freeze) just to fit in the help screen and saving your best record.

One last technical note, I found the necessary information online to read a text file as JSON, and used that to streamline the event structure. I am pretty excited about the possibilities using JSON and javascript-style property access unlocks. I may even be able to rapidly mock up objects before actually implementing them, which would allow my data structure designs to fail faster (as opposed to now, where it takes so long to stand up that I just keep bandaging its failures).