Final project and class wrap up

Comp194-MA Final projectand class wrap up

The Idea – Assassins • The popular game Assassins should be on the cell phone • Take the game, make it so that users can create or join games • Record user stats and let users become the best or worst assassins!

The Parts of the Project • Android Application • Handles all the user interactions • Contains several views( create game, join game, maps, kills, death!) • Web Server API and Site • Handles all the assignments of targets and games • Also can output stats of different players

Andriod Application • The Android application is organized into two primary segments – the UI and the AssassinsClient • The UI facilitates interactions between the user and the server (login, sign up, ect) and communicates exclusively through the AssassinsClient class. • The UI is not portable since it was specifically designed for the Android platform.

Assassins UI • The UI is composed of four primary screens: • A welcome screen that allows the user to login or sign up • A signup/login screen • A main game screen where the majority of the game interactions take place. • A create game screen where the user can create a new game.

Android UI screen shots Initial screen Login

Android UI screen shots Logged in. No game. In game and in range.

Android UI screen shots Game in the phone’s menu. Kill successful. Game over.

AssassinsClient • The AssassinsClient class provides the business logic that allows the client to communicate with the server. • The class is entirely decoupled from Android and would be portable to any Java5 platform. • The only glue between the UI and the AssassinsClient is a location update interface exposed by the client to allow the phone to broadcast its location.

AssassinsClient • The class is designed using the Singleton pattern since concurrency is not supported by the application server. • Additionally, the class uses polling threads to query the server for updates about the player’s state. • Communication between the client and the server is achieved exclusively using JSON.

The Web Application • What it needs to be able to do • Manage users • Creation • Login • Statistics • Location • Manage games • Creation • Joining • Completion • Manage targets and kills • API

Managing the Users • Creation • Users need to be able to register extremely easily • Accepts a username and password, makes sure the username is unique • Login • User login is extremely simple, it just verifies the login name matches the password • Location • The server needs to be aware of the location of all users in a game at all times and their relative proximity to other users • Statistics • Statistics are fairly simple to manage • Wins and losses are updated at the end of game or when you are killed • Kills and deaths are updated as soon as you are killed or you kill someone else

Managing the Games • A bit more complicated. • Need to keep track of active games (not everyone is dead) • Allow for creation of games • Allow for unlimited number of players to join a game • Allow a player only join the same game one time, to prevent people from getting killed and just rejoining • Need to know when to mark a game as completed (the last person has been killed, someone has won)

Managing the Targets • The server must automatically assign a target to every user. • When a user first creates a game they do not have a target as no one else is in game. • Need to make sure that certain people are not assigned twice to two different people • That once a person is killed, they are removed from the game, a new target is assigned, and the person who was killed their target is release so it can be reassigned

Managing Targets (cont) • The system only can talk to the Andriod application when it pings the server • It must see if the person has a target • If they do, are they close enough to kill the target? If so tell them • If they do not have a target, try to assign them one • If the person is putting a kill command through, it must make sure they are within the proper distance and then kill the target • Requires removal of the player from the game and target list • Requires that the killed player’s target is released to the open target list • Requires that the current player is assigned the next target, if none are left must notify the player they have wont he game • Requires update of both players statistics of recent action

The API • In order to allow the game to be played on as many devices as possible, the server implements API calls that can be made from any device • The standardized API calls allow you to write your own custom frontend that will still tie into the backend server allowing the players to all play together • The API is documented so other developers can use it

The Site • The site functionality is fairly straight forward • It must display statistic in real time of all players in the site. • The statistics include the following: • Number of wins and losses over all time • Number of kills and deaths over all time • The current game they are playing • This will allow people to possibly join a game to kill a person they want to try to beat (such as the top ranked individuals)

The site screen shot Assassins website. Stats view.

Project Conclusion • The Assassins project was a great success. It is fully functional and if you had a ton of friends with the application could be a lot of fun • We learned that using an API will allow more to use the application and thus will have more users • Since the API uses JSON, any device could bind to it – allowing for a large userbase • Try out the application!

Class Conclusions • The Andriod SDK is very nice and based on Java • It however is not too well documented, slightly due to its young nature. • It needs many more tutorials in a central well known location • These are crucial to having more developers adopt the platform, as it is difficult to develop solely on javadoc documentation • Additionally, newer versions of the SDK have broken code from older tutorials.

Class Conclusions (cont) • Andriod development is much different than other platforms • It requires an entire emulator run on the developing machine to emulate the cell phone • While it is close to Java, it is not exactly the same, debugging is done very differently • It is hard to test programs that require multiple users as your system may not be able to handle several concurrent emulators • Debugging can be often done via long convoluted error messages from the SDK

Class Conclusions (cont) • The IDE integration with Eclipse for Android Development is fairly nice • Has a nice designing interface • The emulator can receive numerous information that a real phone would such as GPS coordinates, text messages, calls, etc. • It has a fairly well built debugging interface that will hook into the emulator to help pinpoint where problems are occurring • A big issue is that stack traces will trace back into the Android JAR which links to unreadable class files.

Class Conclusions (cont) • The future of Andriod • We believe Andriod will begin to pick up popularity in the coming years as more phones and laptops begin to implement it • It will need to gain a much larger community and knowledge base to be useful • With more knowledge base articles and tutorials it will be much easier and quicker to develop for the Andriod platform • This information needs to be in a central location and easily searchable

Final project and class wrap up