Games Package 142 is a revision of GP142. It is built to include the basic functionality of GP142, and also include a few new events and function calls to facilitate its use as a networked game engine. This functionality includes the ability to connect a Games Package program to a larger server system to create a network game. While this may sound daunting at first, much of the more difficult "under the hood" code is hidden from the your interface so you can concentrate on programming your games.
The changes to GP142 center around the need to have multiple players interact simultaneously. This means that ultimately your game will be able to manage multiple users performing actions which seem to occur at the same time. These actions will come in the form of modified GP142 events which pass information about players exiting and entering your game area.
The bulk of the changes that most students will want to look at are located at the top of GP142.H.
In addition to the previously used mouseX, mouseY, and keyPress
parameters, the GP142_await_event function has been
augmented with 2 new variables. The new
GP412_await_event function call looks like this:
nextEvent = GP142_await_event(&mouseX, &mouseY, &keyPressed, &door, &player);
The first change is the door argument.
door is an int which will store the location
of a player's entrance into the room. It will store one of five
values, which are #defined constants in the new GP142.H.
The five values are NORTH, EAST,
SOUTH, WEST, and NO_DOOR. This
information can be used to ensure that when a player leaves a game
area to the south of yours, they will arrive in a your game area from
the southern door.
The second new argument is the player struct. player is a
player_info struct defined in GP142.H. This stores data
about players entering and exiting your room. The most important
aspect of the player_info struct is the id
variable it contains. This id is a unique identifier for
every player which should never ever be changed. The
id is also the only unique identifier in the player
struct, so all comparisons to determine which player is which should
use the id.
For mouse events, the player_info struct will be passed
in addition to the mouseX and mouseY. This
will serve to identify which player has clicked the screen.
It is likely that students will want to include more fields for
their players to add additional features to their game. As it stands
the player_info struct contains only the player's name,
their unique ID, and a field for an inventory. To add elements to
this DO NOT modify the code in GP142.H. Students should create their
own struct to store player data, and this struct should either contain
as a field the player_info struct itself, or contain all
the same fields, plus whatever they wish to add. They can then simply
copy data from the incoming player_info struct into their
own struct. Alternatively, students can create a parallel array of
structs to store their room-specific information.
Periodic events and quit events will be the only events not
containing a player_info struct. More accurately, the
player_info struct associated with those events will be a
"null" player, and should be ignored. The "null" player can be
recognized as it will always have a player id of 0. (This is
completely analogous to ignoring the mouseX and mouseY associated with
a mouse event.)
When a player enters your game area, you will receive a
GP142_PLAYER_ENTER event. This will include a
player_info struct and the door associated with the
entry. At this point the player is yours to do with as you wish, so
long as you do not change their unique id.
When you want a player to leave your game area, make a call to
GP142_RequestLeave(). The prototype is in GP142.H, and
looks like:
void GP142_RequestLeave( player_info player, int door );
Presumably you would do this when a player indicates to the game that
he or she wishes to leave. You must pass in as arguments a
player_info struct that contains the player's unique ID,
and the door from which the player left. door should be
one of NORTH, EAST, SOUTH,
WEST, or NO_DOOR. REMEMBER - Once
you have called this function, the player has NOT left your
area. This is simply a request to the games package. It may wait
quite some time to signal you that the player is to actually leave or
it may never grant your request. You are not allowed to actually get
rid of the player until you receive a GP142_PLAYER_LEAVE
event.
A GP142_PLAYER_LEAVE event means that the player
given in the player_info argument of the
GP142_await_event function call is to be immediately
removed. This will most likely come after you have already
requested that a player be removed, but it may come without warning.
This event is a signal to you that the player is no longer in your
room, and you should continue running your game area without him.
The door argument will also be filled with the door the player exits
from, though this may not be the door you had originally
requested.
Periodic events are unchanged in form; however, they will be made substantially less frequent to simulate the slower frame rate that occurs when passing data over a network. Don't count on any animation in this project. Even if it looks mildly entertaining on your home system it will probably not transfer well to being run as part of a larger game on the network. While these events will never occur on a regular frequency, we expect one frame (that is one periodic event) per second in the final product.
Key Press events have been suppressed for the games package. You will not receive GP142_KBD events from the testing system, and you should not make use of them in your game area.
In order to allow students to test their code we have provided a small test bed to simulate the functionality that our server will provide. So unlike previous efforts, students using this code will be compiling a test application before turnin, rather than dealing with their actual application.
13 new menu options have been added under the run menu. We'll start from the bottom up.
NO_DOOR direction.GP142_PLAYER_ENTER event to be issued. The Leave
menu items will cause a GP142_PLAYER_LEAVE event to be
issued for the chosen player. Note: In actual use you can assume that you will not receive any events for a user not in your room, and you will not receive an enter event for a player already in your room. In the test bed you can make selections such that these events will occur, the best thing to do in this case is to simply ignore the bad events. We are allowing this in the test bed so you can make sure that in the unlikely event that something unexpected does happen, your code can handle it with elegance and grace.
For the purposes of the test bed, any and all calls made to
GP142_RequestLeave will be honored, but this may not be
the case in actual use, so don't rely on this!
All changes to GP142 have been marked with a comment containing @dmeyer. So if you're curious and want to go hunting after all my changes, have at.
-=-Dutch Meyer dmeyer@cs.washington.edu 5/14/01