Assignment Three


Assignment 3: Multi player extension

Assigned: Tuesday, Mar 20, 2012
Due: Tuesday, Apr 10, 2012 (before 11:59pm)

Project Description

In this assignment you will take the single player game you produced in assignment 2 and extend it to a multiplayer game played between players on at least two machines connected by a local network. You will continue to work in the same teams as for assignment 2 unless special arrangements are made otherwise.

The basic requirement of this assignment is to make your game playable between multiple players connected by a network. Each player will have their own machine, controls, display, etc. The game will be played in a shared environment derived from the single player game environment you currently have. The scoring system is again up to you, you may extend the existing scoring to make it appropriately competitive among multiple players, or you can change the object of the gameplay to make a reasonable multiplayer game if a simple extension of what you already have would not be appropriate.

There are several issues to note in doing this upgrade.


As before, we're allowing three weeks for this project. You no doubt realize by now if you didn't before that there's a lot to do and you should start early. Once again, you'll have weekly milestones to meet, and once again, each of these will be turned in via the usual turnin scheme.

  1. Week 1: You will turn in a document with the following information:

    • Code architecture for your upgrade. What changes have you made to your game to make it multiplayer? How are you handling the client-server issues? Are you planning game upgrades beyond the basic networking requirements? What will they be? What is the division of labor on your team this time around, what have you done already, and what is the order you plan to tackle things over the remaining two weeks?

    • Week 2: Technology demo and status update. You should document your progress and provide a demo, as before. You should also note any changes in your plans as in the last assignment so you and we will know how much on track you are.

    • Week 3: Final game. You should turn in something like the last two assignments, a resource tree that includes a working executable built against any installed versions of the libraries you've used. Other libraries that aren't installed must be included in your tree, obviously, and we must be able to run your game as delivered. You don't need to do any fancier packaging, just make it run as delivered on the lab machines. You should also include a user manual and a final project update that details and explains places where you've managed to do better or worse than you had planned and why. Finally, each member of your team will turn in separately (not as part of the team's game package) an evaluation of the performance of your team on this project, your strengths, weaknesses, what you'd do differently if you were starting again, the main things you've learned. The evaluation must include a specific evaluation of your own performance and that of each of your team members, again both strengths and weaknesses. This will be kept confidential and will be taken into consideration in grading.

Getting started

Hopefully, you're already started since this is a continuation of an ongoing project. Keep at it and have fun.

Turning it in

As for previous assignments.


Pretty much what we said before about assignment 2. Note that if you have time for enhancements, you can use them to mitigate things you didn't get done last time, for extra credit, and generally to produce a better game. But, make sure you meet the requirements in time before doing any of that. And when considering enhancements, realize that improving the UI and epecially the gameplay is generally a better place to spend your time than adding bells and whistles (okay, rockets and bombs). If you end up showing this off to people later, you'd much rather they get involved in playing it than for you to have to hang over their shoulder showing off your special effects and apologizing that you never actually got it to a playable state.

Last modified: 03/18/12 by Don Fussell