Documentation: Team 1
Project: GameMaker Assignment 5
Codebase written by: Team 1 : Lei, Suresh, Janhavi, Chintan, Dann
Codebase extended by: Team 1 : Suresh, Chin Hua, Dhanalaxmi, Vinod
Points to be appreciated on the previous codebase:
1. Code implements design pattern and oops concepts. UML diagram provided in the documentation was very useful to understand the overall functionality of the program modules.
2. Code consistently makes use of style guidelines whenever class names, method names and etc have to be mentioned. The naming conventions are helpful to understand the basic implementation. If comments would have been provided, it would have been even useful.
3. Class responsibilities are separate and isolated. Methods with few exceptions are short and clear.
4. Although one of our team members did already work on the same codebase in a4, we didn't have to make a heavy use of him to understand codebase.
5. Although it is sometimes tedious to change the Game Object properties with the numbers i.e. changing the speedx, speedy or X-Y coordinates, the code implements all the changes in the Game objects during run time, making user interface a lot friendlier.
6. Entire UI design was really good, so we didn't need to change the UI as such.
Review of the Codebase:
1. For each action, it can work only for specific event e.g. move action was not working for keyboard event. Options for Actions were not explicit.
2. Key released event option was not implemented in the keyboard event.
3. Saving game and loading game were incomplete.
4. Actions such as bounce, destroy, collision were implemented but not correctly. These are quite basic actions for any game and were not logically implemented.
5. Mouse click event was not implemented at all.
6. Naming of Game Object was not standardized. It is suggested that we should not use word "Object" for the Class name.
7. Each action also was holding data. Each action is not supposed to hold data but instead execute its job. Actions were not singlet. This is not a practical implementation.
8. All actions were new object of each class. This made implementation even complicated. Too much "new" instances had to be created. Two objects if contain same action, then each action has to be implemented twice.
9. Idea of mapping was good for a4, but not expandable and extendable. All the functionality of controller & view were depending on the map. It would have been better if the design would have been based on Command object.
10. Collision event had to be implemented twice. Since there is each action newly created for each Game Object, for both the objects the collision action was being implemented. This used to cause the freezing problem.
Modifications done for extensions in Codebase.
GUI:
1. Provisions had to be given for events list for additional events and for allocating space for additional features required for the events, such as a) list of events added for each Game Object, b) list of Game Objects needed for Collision event.
2. For actions, no provision was given to add additional actions. It was implemented with the buttons, which was difficult to modify, since modification with GUI would have affected the changes in codebase a lot.
Design:
1. Since Actions classed were single action creating new action class for each game object, we rather converted it into Singleton classes, so that each action will get one and only one instance.
2. Each Action is also made a command. Whenever any event occurs, Executor class checks for each event and executes the command for each event.
3. Changing Map was not possible, so we changed the functions associated with the Map.
4. Additional hash map required for mapping an event with the Game Object, since collision event was not implemented, the option of Game Objects list required for the collision event was not considered in the design. We had to add a list of maps i.e. List<Map<Event, GameObject>> [Ref. (GameObject. Java)] for mapping Collision event with the Game Objects added so far.
5. For cloning object: Since hash maps in Java do not support cloning utility provided by Java utilities, we had to copy the Hash maps for original object and point the copy of the hash map to the cloned object, so as to avoid the conflicts in the memory locations allocated for the hash maps.
6. For Spawning Object: Since spawn action too needs a list of Game Objects and the key/ mouse click input associated with the action, we had to use a separate hash map mentioned above.
7. In the previous design, the basic identity of the Game Object was its name. In case user wants to change the name of the object, then there was no facility provided. While creating a mapping with the Game Object and the event associated, so we decided that the use of Game Object as an object would be a better option for further extensions.
Overall Program Flow of Extended Version of Codebase:
Please refer to the UML Diagram attached to this documentation: