Assignment Three

Assignment 3: Multi player extension

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.

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.