The holidays have impacted workload more than was expected, partially for personal reasons beyond the norm, but also because of two issues that cropped up that completely altered the scope of the project. It can be described as a failure when going by the goals set for our project, but even in failure there is much to learn, and so that shall be the focus of this blogpost.
The first issue I ran into was a mistake that almost all programmers have come across, according to both my teachers and my more experienced co-programmers: After transferring my project to a different computer to work on, suddenly all of my external header files were impossible to reach. I attempted to set configuration paths differently, I forward-declared them, and even rewrote entire segments of code, checking for errors that I knew could not be there. Testers that were sent the code could not recreate the error, nor could they understand how I had gotten it in the first place.
It turns out to have been an issue with Visual Studio itself: Once transferred, a project’s settings switch over to 64 bit if you are running a different client on a different computer, and so a simple switch of a tab resolved an issue that had taken days of asking others for help.
My second small issue that caused a few days delay stemmed from a misunderstanding of the code we had been given. A pointer error had appeared and despite debugging and locating where the program threw an exception, looking at the code everything seemed to be fine. The error supposedly happened in supplied code from our teacher, but I doubted that was the case, as many others used the same code. What turned out to be the problem was that the code my teacher had provided did something different when I tried to apply it to my own classes: There was a set of code that deleted and set as a null pointer a memory address, which I had tried to invoke.
Unfortunately because I had learned to delete and null pointers after use, and this appeared to be the case in the code supplied, I attempted to do the same thing the code from the teacher had already accomplished, leading to my trying to delete something that was not there, and hence, crash my program. Because the code looked perfectly reasonable to people who had seen the earlier project’s code, the error was overlooked or harder to spot, at the very least.
All that time lost also meant I had barely gotten the basics of my project set up, as I had no way to test what I had implemented and actual implementation was held back as I felt I did not fully understand how to resolve them. In the end, my Zelda Clone project was abandoned in favor of a Frogger Clone project, as that would take less time to create now that almost a third or more of my programming days had been lost, beyond those lost from the aforementioned personal reasons. At this rate, the game might be completed, but quite sparse in terms of features.
karlmalmgamedev 