Academic
Minoquar game app
Maze game using QR codes
I first saw Daniel Solis's Minoquar game back in 2012 while looking into board game design. It turns QR codes into pen-and-paper mazes, where you need to avoid a minotaur and open a treasure to win. It's very interesting, but I always thought it would work better on a computer or mobile phone, and now I have the perfect opportunity to do that with my current software development course.
Phase 1 of the project was focused on list storage. I had to generate mazes, add them to a list, and read mazes from the list to start games. I also had to develop a text-based UI for the game, though we were given an example project to help understand how this should work. I also decided to implement the player's hero character movement and a game win condition (get to the treasure in the bottom-right alignment pattern), in order to make the game minimally playable. The maze implementation took a long time, because I needed to generate maze layouts with all the features of a real QR code, which the game rules use extensively.
Phase 2 focused on persistence. Using the provided example project, I implemented a save file format and save system for mazes. I investigated using JSON, which might have been more efficient for storing the complex maze objects, but given the learning time required, I decided on my own format. This turned out to be very useful for testing. I stored each maze layout as a grid of characters, so I could easily generate any needed test layouts by hand. I also implemented the minotaur, complete with rule-based movement and a game fail condition (minotaur moves onto the hero character).
Phase 3 focused on GUI development. I decided to use the standard Swift GUI, due to a greater level of community support and documentation. After checking a tutorial on creating a resizeable chessboard, I built a board that could accept clicks and pass them on to handlers. The board can also be resized, but this currently doesn't keep the board squares as squares. Further development of this game will address this.
Phase 4 focused on cleanup and polish. We had many options here, and I chose to improve the robustness of the design by adding exception throwing and catching. I used runtime exceptions in many places where errors were truly exceptions; that is, the errors were not due to wrong outside inputs, but due to programming errors, and the only graceful way to deal with them was to save data and close the app. However, save file format errors used caught exceptions to attempt to archive the bad save data and warn the player.
I also redesigned the base data models to use a new GridArray class I developed after looking through the core Java ArrayList code. This new class supports ArrayList features like subviews, making it more capable and moving unneeded functionality from other classes that was reducing coherence.
(This academic project cannot be publicly released, but can be made available to view on request.)
(Header image by Daniel Solis)
Update: Course is completed! The project is currently on hold, but I intend to revisit it in the future to improve on it. Areas of improvement include cleaning up some areas of high coupling, fixing UI resizing, adding hero and minotaur trail rules, adding game items, adding QR code scan/generation functionality, and possibly turning the game into a mobile app.