Reflection: Week 1 was an introductory week for the most part since it is the first week of the semester. Our lecturer did hesitate to start as soon as he could, however. We started the week with the SOLID principle. This is an acronym that represents “the first 5 principles of Object-oriented Design,” (Oloruntoba, S., 2019). I will not be diving too deep into each of them, rather, I’ll explain what each of them mean in a brief description. Another thing we discussed this week was A-Star pathfinding which covered the formula behind it and its implementation, as well as a short lesson on making an API. Week 2 completely covered the SOLID principles and A-Star, it was also in that week that we were able to decide on how the studio team would be formed. The ‘S,’ in SOLID stands for Single-responsibility principle. This means that a class should only have one job, ever. It should not have to do any other jobs other than what it was meant to do. Oloruntoba (2019) gave a good analogy of this. The basic rundown of this is say you have a class called AreaCalculator that will calculate the sum of any number of shapes it is given. This class will contain all the necessary variables and functions to do just that, then give the output at the end. The problem with this is that it is the class handling the output data. This breaks the principle as it should only calculate and do only that. To fix that, you can make a class that will handle the output data itself (Oloruntoba, S., 2019). The ‘O,’ in SOLID stands for Open-Closed principle. This means that a class should be extendable without the need for any modifications. In other words, you should be able to add functionality to the code without having to modify the existing code (Thorben, J., 2019). The ‘L,’ in SOLID stands for Liskov Substitution Principle, introduced by Barbara Liskov in 1987 (Thorben, J., 2018). This principle states that the objects of a parent class should be replaceable with objects from its subclasses without breaking application. The objects of the subclass should behave in the same way as the objects in the parent class (Thorben, J., 2018). Or how my lecturer’s slide put it, “If it looks like a duck, quacks like a duck, but needs batteries, you probably have the wrong abstraction.” The ‘I,’ in SOLID stands for Interface Segregation Principle. As stated by Oloruntoba (2019), “A client should never be forced to implement an interface that it doesn't use, or clients shouldn't be forced to depend on methods they do not use.” Pretty straight forward and it sounds easy enough to avoid, but this becomes an issue when you’re adding more and more features to your software over the years. A simple solution to this is by creating another class that can be implemented on multiple objects. Oloruntoba (2019) gave an example in shapes where he’s trying to find the area and volume of shapes since he’s dealing with both 2D and 3D shapes. The problem is that the interface that the square is using would have to implement a method to find its volume, which is useless. To fix it, he made an interface and implemented it on both 2D and 3D objects and said, “you can easily see that it has a single API for managing the shapes.” The ‘D,’ in SOLID stands for Dependency Inversion. “High-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features,” (Thorben, J., 2019). Basically, high-level modules shouldn’t depend on low-level modules. They should both depend on abstractions, but abstractions shouldn’t depend on details. Details, however, depend on abstractions (Thorben, J., 2019). The next topic that we discussed was the A-Star method for pathfinding. The formula that defines the method is F = G + H; where F is the total cost to go to the final node, G is the cost from the starting node and the current node that the algorithm is calculating on in that frame, and H, also known as the Heuristic/Manhattan cost, is the cost between the current node and the end node. The H cost actually has a formula to it – absolute value * (current_cell.x - goal.x) + (current_cell.y - goal.y) – which is actually the equation of a line on a graph. How A-star essentially works is that the algorithm will go through an open list of nodes (optional) and find the lowest F cost between the starting node to the end node. During runtime, the algorithm will store all nodes that are possible low costs until and unless a lower cost node is found. These low-cost nodes are stored in a closed list of nodes. Once the path is found, the algorithm will return the total F cost and the path has been found. Studio Team: The studio team was finalized in week 2 as we were in conflict during week 1 since the class was only comprised of 3 programmers and 2 game designers, one of which, left halfway through the semester. We did manage to start coming up with ideas for genres and game play during week 1, and eventually settled on making a VR, god simulator. Reference(s): |
Categories |