DDTe3 Hour 1 Planning and the Puzzle Model

For the third episode of Dozen Days of Tiles, my series where I develop games with a particular theme in under 24 hours of development time, I decided to twist the concept of developing a game in a day and instead trying to develop as many games as I can within the 24 hours. I know that while the work is done in 24 hours, because the work is spread out over multiple days, it is not the same as if I did the work in a single day. Having done the Dozen Days of Dice series as game in a day stints, I know that after twelve hours of coding the mind starts working against you. That said, finding a solid day to work on something is increasingly more difficult and can be easily interrupted even if such a rare block of time can be found. I also want to document my experience in the form of these blog posts. I do not count the time I spend writing these posts towards the 24 hours but I am trying to write the posts shortly after I put in a programming stint so the thought process at the time is preserved.

Part of the reason for the desire to create multiple games for this episode is directly related to the return of a weekly format for Blazing Games. While the weekly format is more iterative than it has been in the past, allowing for games to evolve into more complex games over time, I still prefer having a buffer of material so that if a larger third-party project interrupts my site work, the schedule will not need to be adjusted.

Creating multiple games in a 24 hour period leaves the question what set of games are tile related, and have similar enough game mechanics that the work on one can be utilized in allowing the related games to be created. At the same time, I am looking at some of the older games on the Blazing Games site and am trying to figure out what should be done with them. The Flash games can be enhanced as Flash is going to be around for a while yet. The Java games, sadly, are in a more precarious position so consideration should be made towards porting them to HTML5. Looking at some of the Java games that I have done, I noticed my picture puzzle series of games. These are simple enough games that I don't need to port the games at all but can instead re-write them from scratch without loosing that much time. In fact, with all the knowledge that I have gained over the years, I should be able to get the core picture puzzle game functional very quickly.

With the game in mind, it is time to start on the project. While having a client-model-view architecture is probably a bit of overkill for this series, it doesn't hurt so I will start by creating the model. This class is being called BasePuzzleModel in the project.

The model creates a two-dimensional array to hold the grid. In JavaScript, 2D arrays are created by making an array of arrays. The model could have also simply created a single array the size of the width times the height of the grid and mathematically determined the position of the tile. I chose to go with the the two-dimensional approach because that way the internal structure of the grid more closely matches the problem being solved. Still, as the tiles are then assigned linear values to represent their proper position, in hindsight going with a single dimensional array would have been easier and just as logical. As I write this, I am only 6 hours into the project and could change things but as the internal structure of the model is theoretically hidden from the classes that use it there would be no point changing it.

As briefly explained in the paragraph above, each tile is assigned an index value that is linear based on the row and column. The index is equal to the row * the width of the puzzle plus the column. By having the linear sequence of tile values, it is possible to easily determine if the puzzle is correct by simply seeing if the tiles are in order. Some simple convenience functions were created for manipulating the puzzle and within an hour we have the model up and running. The functions added were getPuzzlePiece(x,y), setPuzzlePiece(x,y, n), swapPuzzlePieces(x1,y1,x2,y2), scrambleBoard() and checkWin(). These are all fairly straightforward so I won’t delve into the details of these.

The next phase is to turn the model into something visible. The obvious class for this job would be something called the BasePuzzleView, which we will look at next week.