I am wrapping up my project now. I just have to take some screenshots and submit it to the App Store. For nostalgia’s sake I have been looking back at the screenshots I took while debugging.
Here is the first prototype from over a year ago. To get the animations to work was a real chore, but I figured out how to time them in the future and sync them up seamlessly using multi-threading.
When I got the game to be multiplayer online, I switched to a framework called Sprite Kit that is used specifically for games that makes animation much easier, like storyboarding a movie. But it meant that the board and layout of images had to be done all in code, versus in the drag-and-drop Interface Builder, a tool provided by Xcode. So I had to create it by trial and error. What you see below is a major step in that progress, but it is obviously wrong:
Saving the data was crucial, especially for Online play. The first method I used was the one that I was taught in college when I took an iPhone development class. It led to runtime errors like the one you see below because I was trying to archive data structures that I made which were generic and the system didn’t know how to describe them when writing the data to disk. Eventually I got it to work, but I ended up going in a different direction and choosing to save less data.
It didn’t help that I was trying to save a data structure I made to represent the entire game board, and that this data structure was made up of other structures I made that were designed to be generic, not specific to my application, so that they could be reusable.
These structures also allowed for instances to be linked to each other, which caused another complication. Those links / references cannot be saved when they refer back to each other. This creates a “chicken-or-the-egg” dilemma.
The Mancala game board is based on my CircularLinkedList class, meaning each node links forward to the next node, and the last node links to the first. So you can see why it causes a dilemma. The advantage of the CircularLinkedList is that it makes updating the pits on the board very simple, since Mancala is played circularly!
Because I have to add images in code, I have to use trial and error to get the size and placement correct for each button, which can lead to amusing results:
The last major bug I had to squash was a memory leak problem. I don’t use this tool often enough, but the View Hierarchy Debugger shows the effect of this problem, that multiple scenes were being created and not destroyed which is what a memory leak is, in effect:
Here are a few more shots of the View Hierarchy Debugger in action. This one shows the app from the normal, head-on view that the user will see.
The View Hierarchy Debugger lets the developer rotate and “blow up” the views in three-dimensions, to give them a new perspective on the layout. I have yet to figure out why the pits and board node connecting-lines are on different levels, when I was expecting all the pits to be an equal height and lines to be on a separate level below the pits. Well, it’s not affecting gameplay so… : )
Another great tool that I recently learned to use is the Memory Graph, which is also built into Xcode. It helped me spot the objects that were causing the memory leaks, and which objects still had references to them that kept them from being deallocated:
These screenshots only make up a fraction of the challenges I have overcome while developing this app. If you count the month of December 2018 when I made the prototype for this app as a Windows Win32 API desktop program with a GUI, this project is 1.5 years old. And the gameplay algorithms are based on my original design from my first full-fledged C++ command-line program I wrote in 2014, which took a month or so. I had the idea for a GUI based version ever since then!
‹ ›