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 we've discussed in class, you'll want to have a single code base that adapts itself to its role on each machine in the multiplayer context. This means that when the game starts, a player will need to be able to decide either to wait for other connections, or to try to connect to a specified machine. In the first instance, the program will set itself up in server mode listening on a private port (i.e. one whose number is between 49,152 and 65,535) and await connections, in the second, the program will attempt to connect to an instance of itself on that same private port.

• We will make an installed version of the sdl_net cross platform networking library available to you on the lab linux machines. Using this library, you will be able to designate a machine to connect to symbolically and use sdl_net interface calls to retrieve the translated IP address. Thus you should not need to resort to typing in a raw IP address for the target machine to make the connection. If you are familiar with a different, non-proprietary networking library that you would prefer to use instead, please clear it with me. As usual, as long as there are no proprietary issues, we'd expect to approve such a request, and, as usual, you'll have to include the library you are using with the turned in project in that case.

• It will not be necessary for your code to manage more complex networking issues like connecting through firewalls or across NAT routers. It will be sufficient that your code works properly between machines in our lab.

• Once connections are established, each instance of your code will manage the game on behalf of its local player. You must be careful to maintain a consistent view of the shared game environment across all players. There are several ways you can do this.

  • One is to designate one machine as the server and all others as clients. The server machine will receive command inputs from the players via the clients, and it will then update the game state and transmit the results back to the clients. This is a simple way to be sure that the game state is consistent for all player at all times. It has particular advantages when using a physics simulator, since objects whose motion is determined by physics simulation can tend to diverge when run on different machines within their individual rendering loops.

  • Another way is to have different game objects be managed by different peers, who then communicate with the other peers to update the state of the game objects they are managing. So, for instance, each peer could manage the player object for its local player. Shared objects like balls, scoring targets, etc. can be apportioned, but in this scenario each is managed by only one of the peers and state is communicated to the others. This also will avoid inconsistencies with multiple instances of a physics simulation producing different results for game objects these instances are updating in parallel.

  • Another possibility is to run simulations in parallel on the peers, limiting communication of state information as much as possible. A design like this will require extra care to make sure simulation results don't diverge for various players.

• Making this upgrade tractable will require a bit more consideration of the overall architecture of your code than the previous assignment did. If you haven't already, you should strongly consider abstracting your game objects and control interfaces to allow event-based messaging at a level that treats local mouse/keyboard command inputs and remote network-sourced command inputs the same way. Likewise, other message events conveying information between game objects should treat the network transparently. While we do not plan to grade you on your code structure for this project, such an approach will be important for making the entire project tractable.

• Likewise, you should consider a systematic approach to separating your code's behaviors according to the global game state or mode. For instance, if you are interacting with the user via UI screens, that's a different mode than if you're in the middle of "combat". User inputs are directed to different parts of your software in each mode, and the rendering loop is putting different stuff on the screen in each case. Since you'll certainly be in a UI screen mode at the beginning of the game when establishing connections (and possibly setting up other game parameters), you are likely to have at least these two modes now even if you didn't before.

• Since high level code architecture is likely to be your main concern on this assignment rather than just making multiple lower level libraries play nice together, you might find it helpful to consult the acclaimed book Game Engine Architecture, which has a very nice treatment of many of the issues you're likely to encounter in making these decisions.

• You may be tempted to make general upgrades to your game in addition to the basic networking requirements outlined above. Perhaps you didn't finish some things last time. Perhaps you finally figured out what you want to do, or how to do it. Such upgrades are cautiously encourage, provided you make your first priority getting the basic requirements done. Any additional upgrades will be considered for extra credit or for mitigation of points lost by not doing things you'd planned to in the previous assignment.

Milestones

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.

Grading

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 fussell@cs.utexas.edu