NOTE! OBSOLETE PAGE! A new page has been created to replace this! This page is no longer updated!


Material for the Networked Pacman scenario.

by Ingemar Ragnemalm, Information Coding, ISY

News 2016-11-20:

Added information about libraries required for Linux (already installed in the lab).

News 2016-11-11:

A new version, tested under Linux Mint, is uploaded!

News 2015-11-27:

The support has now investigated, and the problem appears to be a firewall problem. Port 32000, which is what I used in my demos, should now be open so it should work as intended. (I can't test it right now though.)

News 2015-11-26:

There seems to be a problem with connecting between lab computers with my example code. This is unexpected, the code worked fine last year. Unfortunately I only tested it locally now. I am investigating the problem. In the mean time, in case anyone who knows the workaround that I am looking for, please tell me and save me a day's work or two. :) (It does happen sometimes, that students find unexpected solutions. And I like good students like that, and I don't mind being corrected if I am wrong.)

News 2015-11-09:

New version of the game code (v3)! This comes with a makefile for Linux.

News 2015-11-02:

The information below will be updated shortly. Please notice that the game code/animation package will be updated! Please do not use the old one, update to the new as soon as it is available!

The Networked Pacman scenario involves some experimental TCL/UDP coding.

You are not expected to implement the game itself! This has been done for you. Your task is limited to the networking.

The game code is fairly new, part of recent year's pretty major revision of the course. The current version has been tested on Mac OSX and Linux. It will not compile on computers without OpenAL (i.e. at IDA) but you can easily map out the sound calls. They are not vital, just included in order to make the game feel more complete.

There is also a network simulation layer. It will work just like the normal API to TCP and UDP but has some user controlled parameters that are important for your testing. You should apply this when you have a working network solution. (See below for details and download.)

This is what the game looks at on OSX:


Here is the current base game (tested on CentOS 6 and MacOSX 10.9):


Here is a preliminary version that supports Windows (Visual Studio). It compiles and runs, but not satisfactory (severe graphics glitches), and some project files have the wrong name. I havn't managed to make Visual Studio rename projects properly. Also tested on MacOSX with no problems. So this is no "official release" but a preview for the daring.


Older versions (tested on CentOS 6 and MacOSX 10.7):


The code has been tested on Linux, and should work on Mac with no changes. It was developed on a Mac but has been edited on Linux since then. OpenAL must be installed for Linux, but feel free to comment out the sound code if you like. Most of the code has also been tested under Windows, but not all so it will most likely require some editing to support Windows.

If you are using Linux on your own computer, you will need to install the following packages:

libxt-dev (the Xt library)
libgl1-mesa-dev (OpenGL, the open graphics library)
libopenal-dev (OpenAL, the open audio library)

Your problem is to make this run over a network, trying to give the two players have the same experience. This poses some challenges, which is what this is all about.

Here are some fundamental network code examples: network%20demos.tar.gz

Finally, here is the "bad network simulator":


This is a layer between your network code and the sockets API. Its main function is to intercept the recvfrom() call in order to buffer data, delay, reorder and skip packages to simulate a "bad" network. By also intercepting socket(), it keeps track of whether you are using a TCP or UDP connection.

You should plug this in into the game (so it affects your already working network solution), and using the calls BADsetUDPerrorrate(), BADsetUDPdelay() and BADsetTCPdelay(), you should experiment with different delays and (for UDP) packet losses in order to see how bad problems your solution can manage.

You are not expected to make wonders in terms of fault tolerance, but rather analyze what your existing solution can do, and why.

Upcoming downloads:

Planned downloads later during the course:

Report and source-code required

You are required to hand in both your source code (for the networking part) as well as a report. The requirements for the report will be noticably lower for this scenario than for the other, since you will spend much of your time creating your solution.

We have modest expectations; this is a course project, not a thesis. We don't expect you to come up with perfect solutions, but rather to come up with something that works at all, and evaluate what you did.