You can make use of any existing HTML5 game engines, if you wish, to help you with the graphics, AI, and UI. The project will mainly be evaluated based on the protocol efficiency, state consistency, and multi-playability of the game.
You will work in a team of three to four students for this project. Please form your team ASAP and email me by the end of Week 2. During Week 3, team-less students will be randomly grouped together.
Equipments and Platform
- Client: Your game should run on a modern Web browser supporting HTML5 and at least one mobile platform. You are free to pick a mobile platform (Android, iOS, Windows) on any mobile device (tablets or smart phones). On a mobile platform, your game can either run within the browser or as a standalone app.
- Server: Your game server may run on any platform.
Note that it might be easier to test and run a Web-based version of your game on the desktop first (with or without emulator) before porting it to the mobile device.
You can develop any type of game for this project, as long as it meets the following requirements:
- The game is a real-time (non turn-based) game.
- The game can support two or more players interacting directly within the game at the same time.
- The server supports multiple game sessions, game lobby, and player matchmaking (albeit a simple one suffices).
- The version of the game running on mobile platform must use at least one of the mobile sensors besides touch sensors.
- 40% of your project grade will be based on how you design and implement the networking component of the game, in particular, your design decision on:
- Which type of architecture or communication model did you use?
- How did you synchronize the states among the players?
- What strategy did you use to reduce the bandwidth / power usage of the game?
- How did you ensure fairness among the players?
Note that, if you use an existing HTML5 engine that supports the networking components, you should still be able to answer the above questions and justify your design.
- 20% of your project grade comes from your game design and implementation of the non-networking components (except asset/artwork). This part of the evaluation will be based on how creative and how polish your game is.
- 10% of your project grade comes from your asset and artwork. Note that you will score for this component if you creatively use simple graphics for your games, instead of drawing your own.
- 5% of your project grade comes from the demo and video presentation to the class during Week 13.
- 5% of your project grade comes from the quality of your project github repository (code quality, comments, documentation).
- 10% of your project grade comes from a report detailing your game design and implementation.
- 10% will come from various project checkpoints and completing various project-related action items.
Note that it is expected that every team member contributes evenly and positively to the development of the project, as will be apparent through the amount of, and the quality of, code checked into the github repository. As such, there are no individual marks. The instructor, however, reserves the right to scale the final project grade for individual team members accordingly, if it becomes obvious that the equal-contribution expectation is not met. It is therefore important that a student only checks in the code that he/she wrote and not code written by teammates.
- 31 January 2015 – An email describing what game your team is planning to implement. Note that you can still change your game design later. A cool name for your game should have been chosen by this time. (1%)
- 7 March 2015 – Project Checkpoint 1. By this time you should have a pretty good idea of how to implement your game (what library to use, the structure of the software, division of labor among team members, etc.). Some of you may have started implementing. Email me to schedule a design meeting before this date (1%)
- 4 April 2015 – Project Checkpoint 2. By now you should have a demo-able, playable prototype, although it might not be polish, efficient, fair, or synchronize properly. Email me to schedule a short demo meeting before this date (1%).
- 13 April 2015 – Final in-class video presentation and demo.
- 18 April 2015 – Final submission of source code and report.
- 22 April 2015 – Presentation at STePS
- Game source code (checked into master branch on github)
- Documentation on how to install and run the game (README.md on github)
- 2-minute video demo of the game (on YouTube)
- Report on design decisions and implementation (uploaded into IVLE Workbin)