Thanks for playing!
Original design document
Turn-based puzzle game where the player tries to collect a certain number of points before a deadline.
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.
To keep the scope small, these are features that, while nice to have, can be left out if necessary:
Original writeup- immediately after completing the project
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.