Because of the nature of the project, things were getting a bit complicated. I had set myself a lot of goals and was moving from week to week trying to achieve them. However, when I looked back at how many milestones were incomplete I knew that it would take way longer than a single week to sort everything out.
So, I went back and looked at my priority list. I'd placed the visuals as the second most important thing but as it stood there were a lot of technical issues that needed to be addressed. This is when I decided to ditch any extra effects and spend the week on milestone completion and bug fixing.
Bug fixing wasn't as easy as I hope it would be because of the scale and structure of my program. When I first created the game in the summer, I was concentrating on techniques and how to do things technically. Unfortunately, this has resulted in the actual design and architecture of the program to be quite chaotic. With hindsight what I should of done was make several small programs to hone and refine my skills rather than jumping in at the deep end. However, it was too late to re-organise everything as there wasn't enough time ,so, I had to make do with what I had created.
As I mentioned in the previous weeks post, I had a game state system that was quite delicate, that relied on a global states and many other sub states using enums. Looking back on it, at the time, it seemed a good idea. Again, however, with new knowledge gained over the course of this project I would now do it with events, delegates and read only properties.
The main problem I had to solve was a bug in the combat mechanics. For some reason, when there were more than two players in a game players weren't registering that they were being hit. They were still be effected by the push-back of the attack but no score was being registered and no sound was being played. As you may have guessed, the problem stemmed from use of a lot of small states (using a number of boolean values that could be modified by anything, NOT good practice!) and it took me a long time to get to the root of the problem. It turns out that some innocuous method was setting a value to false on each update, but this was a painstaking long discovery.
It seems the more I learn about programming and handling a complex system the harder it becomes to diagnose problems. Although, it is a very good learning experience, seeing why things should be done in a certain way really becomes clear when your program is plagued with small errors.
No comments:
Post a Comment