Sprint 1 Thesis Project

For this first week, I will be handling some of the backend systems such as a scoring mechanism, timer and inventory system. The difficulty of these tasks is not from implementing the logic for them but figuring out the best way to create methods, the parameters associated with them as well as the amount of flexibility we want to give to designers. Usually these aren't difficult things to deal with but since I have absolutely no idea how other systems are being built and how much functionality we actually need later on, I've tried to make methods take in as many parameters as possible and only kept a minimal amount of member variables. An example of this would be the scoring system. There are several factors that contribute to a score: Time, Dodos kill count, and combos. Because I know absolutely nothing about where the rest of the systems are, a method that would calculate the score base on time would taken in the time elapsed and the maximum game time allowed to apply its algorithm appropriately. There are also several properties within the scoring system I've made available. These mostly contain multiplier values or score values that a designer can alter during play sessions that are used by the scoring methods to calculate points.

One issue I have with Derek Higgs(Engineer) is his hate for inheritance. I have no idea why but when we talked about implementing trap types, I suggested creating base classes for the three types of traps: kill traps, directional traps, environmental traps. He quickly disagreed and told me to stop using inheritance. My problem with never using inheritance is that there are basic functions that each one of these traps should implement. For example, by making an abstract kill trap class and forcing all inherited classes to implement a function called Kill, the readability of each file improve dramatically. There are about 6 kill traps in total and imagine if there are 6 differently named functions doing the exact same thing! This would make going through code so difficult especially for someone who has not touched the code and is trying to help debug something. In the worse case, there may be 6 differently named functions that actually does the same thing but the programmer has to spend an additional hour just to figure out what the traps are doing and where it is doing the "killing". But forcing all the kill traps to inherit from this base class, it standardizes things and when someone has to look at the kill code, they can go immediately into the kill method without reading through the entire code file. I think I'll will have to talk with Kameron about this some more but this can potentially be a large problem down the road especially when we try to debug things and/or we are trying to change a functionality of a trap.