Wrangling a Prototype

Before the Weekend, I created a small little prototype of a sokoban clone. I worked reasonably fast and after some tilemap headaches, I simply implemented my own quick and dirty version of a tilemap and map utilities. I then went off to the weekend and came back yesterday to find code that was inefficient, nigh unreadable at times, incredibly coupled and almost impossible to make changes to. I suppose that is the price for trying to crank something out fast, but I would still like to get better at avoiding such a thing earlier on.

What I did was to try to find ways that I could at least decouple the whole thing a little and try to make it more manageable. A began by scrapping my cobbled together tilemap attempts - they worked but used unwieldy 2d arrays for map storage and access, without ever implementing an actual datastructure for it. And before I started reinventing the wheel, I simply adapted my code to the libgdx tilemap - turns out its relatively easy when you have a rough base to work from. All my entities are now also cells in this tilemap and I can thus easily use the tilemap features for quick access, efficient storage and easy rendering.

This allowed me to also add some quality of life changes like being able to resize the app without everything breaking and adding a rudimentary user interface to change levels and restart when you messed up. For now it’s not only not much to look at but does not even have too much functionality - but this can change quickly with the ease of creating gui with the VisUI library and its kotlin extensions.

Finally, I also finished a first version of a file importer. This allows me to pull the levels directly from a text file and recreate them dynamically, reuse them when I want and extend the game simply by adding a txt file to its directory. The parser is still very much prototype-quality code and highly coupled but if I get around to it, I could see writing a more universal importer that can also pull from the web directly (there are a lot of sokoban levels out there).

I will unfortunately not have much time to work on the program this week, but may find a few minutes here or there. When the UI is in a workable state and most of the outstanding bugs are squashed, I may finally think about adapting the user input to the command pattern (the reason for this game’s very existence) and try to see how I could for example use it to create replays or integrate an undo function. At the same time, it would be about time to integrate some tests to avoid breaking everything via regressions when refactoring. Oh well, still so much to do, so little time. Somehow this grew larger than the tiny prototype I wanted to use it as at the beginning.