Assignment 3 Design Document
For this assignment we decided to split the work into two main parts; Zach was mainly responsible for the game's new save-load functionality and Ching-Ju was mainly responsible for the game's custom layout manager. Although responsibilities were delegated, both team members took part in the design and implementation of both sections in some ways.
Save/Load game
To achieve save-load functionality for the game, we decided to use a robust XML serialization library called "XStream" to save everything involving the game. XStream, unlike Java's built in serialization classes, is able to easily serialize objects within objects. This allows us to achieve the save-load functionality without any particular overhaul or change to the code base. Additionally, if we decide to, for example, add new commands or new sprites with new commands that behave in very different ways from our current sprites, absolutely no change will need to be made to our save-load implementation. Our implementation works by saving the "GameData" object where we have all of the data from the current game, including sprites, levels, commands, etc; if we want something new to be saved, all we would have to do is add it to the GameData object. Originally we decided to design the save/load functionality to exploit our CommandSuite composite of command histories; in the end, however, we figured that simply serializing saving the GameData object would lead to a more robust solution because individual commands would not have to be made and saved for gamestate related things.
Custom Layout Manager
In the original code base, the visual Frames and Panels extended from Swing components. In this assignment , in order to separate the business logic and the display, we have changed all frames and panels to no longer simply extend swing components, allowing us to perhaps in the future extend other classes. We created custom containers, and moved all of our Swing components into these containers. In one container, all contained Swing components will only be viewed as the data kept in it. This is the Model part of the MVC Design Pattern. LayoutController, a class we created to change between layouts, plays the role of the Controller. When the change layout event is invoked, it will take any specified container as input, and update the properties(sizes, positions..etc) of those components in it to change the layout. In this part, Controller will make use of custom LayoutManagers to do layout change for the container. After layout has changed, the View is refreshed again.
We chose to directly implement Java's LayoutManager interface so we could use both Java's LayoutMangers and our own custom layout at the same time. This is a clear practice of Strategy pattern. Two basic LayoutManagers are implemented: MyBorderLayout and MyFlowLayout. We kept a list of desired layout types in the LayoutController, once the change layout button is pushed, the LayoutController will cycle through the list of layouts and call for the layout to be changed.
Add Comment