During this iteration, we finished coding the front-end of the project using JSP, CSS, html, and Java (for the controllers). Users are able to perform a variety of actions on our web client, including : signing up, creating games, sending/accepting/denying friend requests, blocking users, changing account information, and of course, playing Assassins. Within the game, users are only provided with user actions and administrators are only provided with administrator actions (if they are not playing the game). Players can request to kick a player or dispute the fact that they have been killed by sending an arbitration request to the admin. Admins can add or remove players from the game and respond to arbitration requests (regarding kills) and kick requests.
Additionally, Games.java was refactored to implement the State design pattern. Instead of using ENUMs and if statements, our code now uses states to determine the proper action to carry out. A game can be in one of four states : over, playing, setup, and stopped. This tremendously cleaned up our code in Game.java. For example, we have determined that players can only be added if the game has not yet begun (is in setup state), so now instead of saying if the game's state is in set-up add player, else do not add player, we simply call state.addPlayer(account).
We have added the proper code for interfacing and wiring to a PostgreSQL database through Hibernate. Some portions of the model were re-written to better interface with the database. Among these changes, we removed or refactored two types of listeners, one of which now functions more like a Command Pattern, and thus makes more sense. This enabled us to write a lot more to the database, and persist many different types of objects. To streamline this code, we created an interface called Persistable that exposed certain methods necessary to store objects via Hibernate's O/R mapping. Then we had each thing we needed to persist implement this interface and wrote the case-specific code for them.
All features of a standard game of Assassins are now present and accessible from our front end. Some of the more complex functionality, including kick requesting and rolling back to previous saves of the game are also implemented and accessible. See the README.md file in our repository for an explanation of what has changed since our presentation, as well as instructions to build and run the project. Additionally, a live version of our project is now available here.
We should note that the code we submitted for iteration6-v2 was experimental and not fully tested, as much of the database persistance stuff was done after our presentation. The code we demo'd has been submitted as iteration6-v1. We know some things are broken in iteration6-v2 (and treated that branch of the project as "experimental" as opposed to the "stable" v1), but opted to make sure all of our new code got submitted anyway.
If a hypothetical iteration 7 were to occur, one of our major changes would be to properly implement the Transactional handling of the database from our front end. This would resolve the problem with Games occasionally becoming "stale" in the front end but we were unable to successfully complete it in time.
We have a pretty clear idea of the extended features we would like to implement. These would primarily be addition of various rule configurations, including:
* A predetermined stop time, at which the game ends and the player with the
most kills wins. This would be accomplished by tracking kills inside of
Player objects.
* The option for a target to be able to defend itself by killing its attackers.
This would be done by modifying KillGraph to allow kills to occur in either
direction, or more likely, by extending KillGraph.
* Alternative kill graph layouts including a "free for all"/"battle royale"
mode where everyone can kill everyone. This would require more restructuring
but in the end would involve extensions of KillGraph. If we were to implement
this feature, it would be likely that we would refactor KillGraph into an
interface, and change Game to take a generic type that implements that
interface.
* Establishment of "safe hours" and "safe zones" during which and where no
kills can occur. This would be a further modification to Game that would
check if the time of the kill was valid. We would
most likely create a GameConfigurations object to give to Game, or perhaps
even create a GameFactory that could produce Games with different sets of
rules.
* A maximum time limit for kills, where violating this time limit will put
you on a 'wanted' list, where all players could now kill you. This would
require a restructuring of the model.We would also like to add some features that are more specific to the front end. These would be much simpler because of the MVC structure and our use of Spring, and would simply require making more JSP pages and Controller classes. These would be primarily cosmetic changes, such as the ability for a user to upload a profile picture to be linked with their Account and displayed as an avatar. Tracking statistics to a player's account and displaying their history of kills and deaths on their player profiles is another feature we would like to add, most likely by including an object containing this information in Account and writing it to the database alonside Account.
We would have ideally liked to create a fully featured mobile client on the Android platform that would allow users to log in on their mobile devices and use the full functionality of the web application. Currently, the website is accessible from mobile devices and should be completely usable, but this app would primarily serve to make it more accesible and user-friendly for touch screen devices.
Finally, one of our biggest goals for an iteration 7 would be a cleaner codebase. We would do a lot of refactoring, primarily in the front end, to move similar controller functionality up to superclasses of Controllers. We have done a little bit of this with our AbstractTerminatorController, so as to avoid repeating some Spring Security hooks, but we think we would be able to find more similar methods to pull up if we had the time to consider the structure of our controller.