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.

sprint 0!

So for this pre sprint, I've been looking at other ai pathing engines. Specifically, I looked at Angry Ants, Simple path, and Rain one. Because the ai pathing is the most important component of the game, we wanted to explore and see if other engines might be more advantageous. In the end, there are pros and cons to all of them.

First, besides Angry Ants, the other engines have no trial versions(was not able to find it) and will cost us money to just test it. Second, Angry Ants and Rain one does not provide the source code to their engine and gives us a dll instead. This makes these two engines not worth looking into because we want the capability to alter their code to make our game work. Third, we have already figured out how to access and edit node costs in the current engine to affect the behavior of the Dodos. This pretty much means we know our current engine can handle what we want it to do.

Even though we haven't given a 100% approval stamp to the current engine, I think once our entire group meets again in a couple weeks, we'll be starting the game using what the prototype used.