The SimDisc Ultimate Frisbee Simulation

Darrin Jewell
jewell@mit.edu

Abstract:
The SimDisc project is a computer simulation of the sport of ultimate frisbee. So far,
a broadcast simulation communication model has been implemented using either POSIX
threads or multicast networking. A graphical presentation environment for either entertain-
ment or analysis has been created. A model for automated control of virtual humans has
been discussed.
The SimDisc Ultimate Frisbee Simulation

by Darrin Jewell
jewell@mit.edu

DRAFT Edition
$Id: simdisc.texi,v 1.10 1998/02/02 05:34:28 jewell Exp $
Printed 2 February 1998

This document and the software described herein are:

Copyright c 1998 Darrin B. Jewell
All rights reserved.

Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by Darrin B. Jewell
4. The name of the author may not be used to endorse or promote products
derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Chapter 1: Introduction 1

1 Introduction
The SimDisc project aims to simulate the sport of ultimate frisbee in a computer. Auto-
matic independently controlled players will interact, demonstrate collective behaviors, and
compete in a virtual environment. So far, the communication and graphical presentation
aspects of this project have been completed.
The simulation can be viewed using as a 3D rendered animation using SGI OpenIn-
ventor. Players are represented on screen as both icons and as articulated human models.
Player compute actions as independent processes or independent process threads and may
be on running on separate computers. The simulations communicate by passing broadcast
messages using shared memory when using POSIX threads or with multicast networking
when on separate computers.

Background
Virtual computer environments are now being used for entertainment, engineering and
training. Many of these environments present humans interacting with each other. Cur-
rently, most of these humans are being controlled by real people at computer stations in a
distributed environment. In order to further populate the virtual world, automated control
of humans can be employed as extras to further enhance the simulation. These humans will
be able to interact with other objects the environment by using simple behavioral control.
This project is to simulate a game of ultimate frisbee. Normally this is a game played on
an outdoor eld with two teams of seven players and a frisbee. In this simulation, currently
called \SimDisc", player's high level actions such as running, catching and throwing will be
controlled by a simple state machine. Pre-recorded motion data recorded from real humans
can then be edited together to present a realistic character onscreen.
The SimDisc project will focus on realistic interaction among players. Each player will
be represented by an individual computer thread which reacts to event messages broadcast
to other computer threads in the simulation. Although each computer player maintains
their own state regarding their actions and the game, information from the messages can
be collectively viewed as a game of ultimate frisbee.
Automated characters have many uses in virtual environments. They allow the envi-
ronment to be populated with many more people than are actually interacting with the
simulation. For example, someone creating an urban planning simulation can use auto-
mated characters to determine how pedestrian trac will ow and to present an exciting
populated visual presentation of how a design will look. For games, such as ultimate frisbee,
players and coaches may eventually be able to try out new plays and see what might happen
if they had done something dierent during the course of a game. The SimDisc project will
provide a sample application and a testbed for automated control of virtual humans.

Initial Plan
This was the original work plan for SimDisc.
1. Design and build the simulation base classes. Each simulation object runs in its own
thread and uses a message passing interface to communicate with other simulation
2 The SimDisc Ultimate Frisbee Simulation

objects. Simulation objects are used to represent things such as players, the frisbee,
the clock, and the display front end. A base simulation class handles thread scheduling
and communication and is used for each simulation object.
2. Design some low level event driven simulation objects which accept, handle and generate
messages to be broadcast. The message interface for a frisbee player is assumed to
mimic a simple "remote control" type input. For example, player position and velocity,
as well as simple actions such as throwing a frisbee with an intended throw type and
target. These messages are expected to be updated at the rate of a few hertz and as
simulation states change.
3. Design a high level simulation state machine which can simulate a simple game of
frisbee catch. For example, a player will have states representing actions such as \get
open", \catch frisbee", \nd receiver", \throw frisbee" and will be able to query the
lower level about where the frisbee and the other players are. This interface will be
modeled around the idea of a continuous presentation of short term scenarios requiring
immediate action.
4. Incorporate a graphical interface which can be used to view a representation of players
onscreen. This will involve a simple scene, with either an iconic representations of
players, or an incorporation of existing jointed human animation models. Prerecorded
sounds will be used to represent certain simulation events. This interface will be at-
tached to the simulation as a simulation object which receives broadcast messages and
updates the display.
5. Create a "perception lter" which will restrict the information available to the upper
level state machine. This level will ensure that the simulation state machine does not
have global information about the state of the other players or the frisbee. Gaussian
based errors in received information as well as desired actions will be introduced. These
parameters will help represent playing ability and physical character traits.
6. Expand the high level simulation with states that are useful for representing a game of
ultimate frisbee. Build a state machine which can follow the rules of the game.
Chapter 2: Design 3

2 Design
2.1 Design Considerations
Limited time frame
This project had a six month development schedule starting in August of 1997
and nishing in December of 1997. The work was completed by a single author
working on this project part time during a one undergraduate semester.
Extensible Design
It is intended that the SimDisc project can provide the basis for continuing
work, including:
 Extend the graphical front end with better characters and motions more
suitable to the game of ultimate frisbee.
 Develop a representation for and begin library of plays and playing strate-
gies. Think about how to model a "playbook" or converstation with the
coach about entire game level situations.
 An interactive game where a person can control the actions of some or all
of the players.
 Explore computer learning models for playing frisbee. This could easily be
a framework for researching memory based learning.
 Expand this simulation framework for other contexts, such as other sports
or simple automated behavior in virtual environments.
 There are a lot of aspects of the game and player interaction that are not
captured by the scope of this project. Frustration, anger, fun and "the
spirit of the game", are among the details that are dicult to capture in a
computer program.
Graphical Interaction
The game of ultimate frisbee is presented as a rendered 3D graphics virtual
environment. This interface serves to inform and entertain. A minimal iconic
representation of ultimate frisbee players is provided as well as a fully articu-
lated human body representation. The internal state of individual players is
available to enhance understanding of the simulation as well as to aid debug-
ging.
Real Time Simulation
Simulated games and player actions occur on screen at approximately the same
pace as an actual game of ultimate. The visual representation is a continuous
ow of game play.
Independant player control
Each simulated ultimate player keeps independant information about the cur-
rent game. Game state transferred among players represents visible, tactical or
audible communication similar to that observable in an actual game of ultimate.
4 The SimDisc Ultimate Frisbee Simulation

Simple Behaviorally based rules

The rules governing each player should result in simple individual actions. The
actions of multiple players should be able to be interpreted together as a game.
Variable character trait parameters
Although each player has a similar set of action rules, dierent players have
diering traits which can be changed by the person running the simulation.
Increased understanding of the game.
This project is also intended to increase the author's understanding of the
nature and strategy of the sport of ultimate frisbee. It is also hoped that the
resulting simulation program is a useful tool to facilitate understanding of the
game.
2.2 Design Features
The Development Environment
Since SimDisc was intended from the start to have a graphical user interface capable of
rendering a 3d representation in real time, it was initially targeted for SGI workstations
with graphics rendering hardware. A signicant attempt was made to provide portability.
The core functionailty without the graphics interface will also compile and run in other
environments. It has compiled and run under Irix, Solaris, Linux, NetBSD, and NextStep.
This project was developed in C++, with grand dreams of decreased develpment time and
increased code reusability. Unfortunately, the current state of C++ development environ-
ments leave much to be desired. Diculties with the available tools caused a lot of wasted
development time and eort, without obtaining the benets. Although in the proposed C++
language standard, many features are not available, cause the compiler to fail, or are imple-
mented to an older version of the standard. These features include nested classes, template
instantiations, the Standard Template Library, exceptions, const cast or mutable and many
of the standard builtin classes such as strings and stdio. In addition, many debuggers do
not deal well with C++ symbol demangling and inlined functions.
Since each simulated player is represented by an individual computation, a multithreaded
programming model was utilized. The initial programming model was based on the POSIX
thread standard. Unfortunately, the POSIX threads are only implemented on the most
recent versions of the operating systems used in this project. In addition, the available
debuggers, gdb and dbx, are currently unsuitable for debugging multithreaded programs.
To work around these shortcomings, another process model was additionally developed
which used independant processes and multicast networking for communication. Although
this added additional programming work, it enhanced exibility by allowing the simulation
to run on multiple computers connected via a local network or a wide area network that
enables multicast routing.
The Communication Model
To allow exibility in communication among simulation processes, a broadcast message
passing communication model was developed. This is similar to the distributed simulation
Chapter 2: Design 5

model known as Distributed Interactive Simulation (DIS). DIS is currently used for existing
large scale interactive simulations, such as military training scenarios, but is not apropriate
for this project due to its complexity.
The communication model for SimDisc is centered around a templated abstract base
class mqueue<class T >. See Section A.1.3 [mqueue], page 11, for the class specication.
This class species a programming interface that allows simulation development to be in-
dependent of the communication medium actually used. An mqueue<T > object represents
a queue of unread objects of type T and a handle on a set of associated queues. A write to
an mqueue<T > will place an object in all queues, but a read will only read from the queue
associated with the local process. Therefore, a message written by any process will be read
independently by all processes.
There are currently two dierent mqueue<T > implementations. The ptmqueue<class
T > class is used to communicated among POSIX threads using shared memory. The
mcmqueue<class T > class is used to communicate among dierent programs any any num-
ber of hosts using multicast networking. The simulation objects are programmed to deal
only with the mqueue<T > interface and can therefore be instantiated with either implemen-
tation.
The Graphical User Interface
The simdisc simulation has a graphical user interface which reads simulation broadcast
messages and presents a representation of the ongoing game to the user. The game is pre-
sented as a rendered 3d environment. For ease of implementation, the SGI OpenInventor
Toolkit was used to create a virtual environment containing a regulation dimensioned ul-
timate frisbee eld. This allows the simulation user to examine the game from any angle.
Objects in the scene can be selected with the mouse to request more detailed information
about the ongoing game. In addition to the visual representation, audio sounds can be
replayed to enhance the environment.
The graphical user interface presents two major representations of the ultimate frisbee
game. One is primarily intended for entertainment and the other for analysis. They can
be independently turned on and o depending on the hardware available and the type of
information desired.
One representation presents a schematic of the ongoing game in the playing eld, similar
to a coach writing on a chalkboard. "X's" are used to represent oense players, "/'s" are
used to represent defense players, and an "O" is used to represent the disc. Frisbee paths
are drawn as curves on the eld. Colors are used to dierentiate the two teams since oense
and defense can quickly swap during the game. These icons do not update smoothly, but
rather move in discrete increments as messages are received from the broadcast network.
The mouse can be used to select an icon to display the most recent state information for that
simulation object. This interface is most useful for game analysis and simulation debugging.
The other representation presents smooth animation of human gures. To implement
this, third party software called DI-Guy donated by Boston Dyamics Inc., was used as an o-
the-shelf component. DI-Guy is a library which provides animation of human characters for
virtual environments. These characters only need to be updated with high level commands
such as "walk", "jog", or "run" and a direction of travel. The DI-Guy software takes care
of the visual model and the angles and position of body parts in each rendered image.
6 The SimDisc Ultimate Frisbee Simulation

The DI-Guy software can render using the OpenGL 3d graphics application interface.
To allow the use of DI-Guy in OpenInventor, the OpenInventor library was extended by
wrapping a new node around the DI-Guy library. This is the SoDIGuy shape node and the
supporting routines in the libSoDIGuy library. Using this node, diguy can be easily inserted
in an OpenInventor scene graph and rendered without any further special consideration.

2.3 Automated Players

Some design work was done towards support for automated ultimate players, although
it did not get successfully implemented. We discussed a couple of models for player control,
and came up with several states that a player goes through in the course of play. Ideally,
this state diagram would directly correspond to an easily modiable set of behaviors for a
player.
Chapter 2: Design 7

2.3.1 Oense Player States

This diagram represents a set of states used by players carrying out a simple oense
stack strategy. Each player would play one of three oense roles: handler, middle stack and
rear stack.:

Offense Player States

Handler:
Establish Position Establish Establish Seek Open Attempt
Near Front of Stack Posession Pivot Foot Receiver Throw

Score? Catch
Pull

Middle
Establish Position Contend for Next Cut Cut From Stack Attempt Receive
Near Middle of Stack

Rear

Establish Position Await Middle Cut Contend For Make Long Cut Attempt
Near Rear of Stack Long Cut Receive

Advance Up Field
8 The SimDisc Ultimate Frisbee Simulation

2.3.2 Defense Player States

The defense strategy is a simple man-on strategy:

Defense States

Identify Establish Begin Attempt

Mark Mark Count Block

no throw

Dispatch on Intercept
get throw
Disc State
ignore
Intercept
throw

We also wanted to make sure that this state framework was easily extensible. This is an
example of adding the states necessary to begin a game round with a pull:

Defense Pull States

Disc On Contend Await Receivers Mark Pull

The Line For Disc To Assemble Up
Chapter 3: Conclusion 9

3 Conclusion
Although an interesting project, the original goals were never attained. I do have some
recommendations on how to do things dierently in the future.
Keep it simple, stupid
It is far too easy to expand the project before even simple goals are attained.
Get something working before expanding on it.
Avoid new fangled features
The C++ language contains a number of nifty features that are too new to be
useful. They are not very portable and will cause you headaches. In addition,
features such as POSIX threads are only available on recent platforms. I also
used multicast networking, which is very stable but not routed to much of the
internet.
Divide this project up into distinct sub-tasks
A computer representation of the game of ultimate frisbee needs to be for-
mulated independently of automated frisbee players and play strategies. This
could be in the form of an interactive online game. Adding an automated
player model before this is solidied creates confusion about what the interac-
tive "world" really is.
I also recommend separating the visual representation of the game from the
rules of the game. This is less critical, but has some advantages. An automated
player probably cannot understand the game from the visual representation.
10 The SimDisc Ultimate Frisbee Simulation
Appendix A: Library Reference 11

Appendix A Library Reference

This is an introduction to the SimDisc libraries. This should be a starting place for
putting the names to what they do. For the gross details, use the source luke.
A.1 Utility Library
This library contains miscellaneous things that are useful to SimDisc.
A.1.1 The cmsg<class T > templated class
cmsg<class T > Templated Class
The cmsg<class T > templated class is an automatically managed pointer to a
data object. Reference counting is used to automatically delete the pointed-to
object when the last pointer to that object is deleted.
A.1.2 The table<class K, class V > templated class
table<class K,class V > Templated Class
The table<class K,class V > templated class is a generic chaining hashtable.
This represents an ecient mutable mapping of one arbitrary type to another.
A.1.3 The mqueue<class T > templated abstract base class.
mqueue<class T > Templated Abstract Base Class
The mqueue<class T > templated abstract base class denes a broadcast mes-
sage passing interface. An mqueue<class T > object represents a handle on a
which can have messages pushed or popped from it. A message pushed on
an mqueue<class T > can be independantly popped from each copy of that
mqueue<class T > which is made.

A.1.4 The mystr class.

mystr Class
mystr represents a string. This was created because existing C++ implentations
didn't have a standard string class that worked.
A.2 Pthreads Library
This library contains support code for using POSIX threads, also known as pthreads.
A.2.1 The pto class.
pto Class
A pto object represents a posix thread. This presents a C++ base object which
very closely matches the C POSIX thread library.
12 The SimDisc Ultimate Frisbee Simulation

A.2.2 The mutex_lock class.

mutex lock Class
A mutex_lock on a pto::mutex object is automatically released when the local
scope is exited.
A.2.3 The ptofstream class.
ptofstream Class
ptofstream is an iofstream with an assocated mutex lock.
A.2.4 The ptmqueue<class T > templated class.
ptmqueue<class T > Templaed Class
mqueue communication routines using shared memory and POSIX threads to
transfer messages eciently.
A.3 Networking Library
This library contains support for networking simulations.
A.3.1 The mcmqueue<class T > templated class.
mcmqueue<class T > Templaed Class
mqueue communication routines which use multicast networking.
A.4 Graphics Library
This library contains code for the graphical front end to the simdisc simulation.
A.4.1 The soinventor class.
soinventor Class
This class is a simulation object which only monitors simulation messages. It
then uses inventor to display a rendered animation of the game in progress.
A.4.2 The bdiplayer class.
bdiplayer Class
This class contains the support for rendering the simulation character as a BDI
DI-Guy character.
A.4.3 The ivplayer class.
ivplayer Class
This class contains the support for rendering a player as a simple inventor
object.
Appendix A: Library Reference 13

A.5 Inventor DI-Guy Library

This library contains support for integrating a DI-Guy into an Inventor system.
A.5.1 The SoDIGuy class.
SoDIGuy Class
This is an Inventor Node which renders a DI-Guy.
A.5.2 The SoSFDIGuy class.
SoSFDIGuy Class
This is an Inventor Field which holds a diguyCharacterHandle.
A.6 Simulation Object Library
Each entity in a frisbee game runs in its own thread and is encapsultated in a simulation
object. This library contains most of the simulation objects which play frisbee.
A.6.1 The sobase class.
sobase Class
This is the base simulation object class. It provides support for reading and
sending messages on the network. All simulation object inherit this as a base
class.
A.6.2 The sodisc class.
sodisc Class
This represents the frisbee.
A.6.3 The soplayer class.
soplayer Class
This represents a player.
A.6.4 The soclock class.
soclock Class
This represents a clock.
A.6.5 The soprint class.
soprint Class
This is a diagnostic simulation object which monitors the network for simulation
messages and prints them out.
14 The SimDisc Ultimate Frisbee Simulation

A.7 Simulation Message Library

Simulation messages represent the types of actions that could be used in a frisbee sim-
ulation.
A.7.1 The smbase class.
smbase Class
This is the base class for simulation messages which get passed to and from
simulation objects. It provides interfaces for run time type identication and
converting simulation messages to and from a machine independant format.
A.7.2 The smstate class.
smstate Class
This message holds the current state of a frisbee player.
A.7.3 The smdisc class.
smdisc Class
This message holds the current state of the frisbee.
A.7.4 The smgrab class.
smgrab Class
This message signals a player grabbing for the frisbee.
A.7.5 The smtime class.
smtime Class
This message signals the current time from the clock.
A.7.6 The smthrow class.
smthrow Class
This message represents a player throwing the frisbee.
A.7.7 The smrun class.
smrun Class
This message represents a player running.
Appendix B: Example Session 15

Appendix B Example Session

SimDisc is currently kept in a cvs repository on `graphics.lcs.mit.edu' in the directory
`/home/jewell/cvsroot'. I used cvs version 1.9 to create and operate that cvs repository.
There is a working recent version of cvs for irix installed in `/home/jewell/bin'.
The following is a sample checkout, compile and run session. It assumes you are on an
lcs graphics machine running irix.
This sets the path to pick up recent versions of some useful utilities, such as cvs, gnu make
and autoconf.
From a bourne (i.e. `/bin/sh' or `bash') shell:
$ PATH=/home/jewell/bin:$PATH
$ export PATH
or from `csh' or `tcsh':
% set path = (/home/jewell/bin $path)
This checks out a copy of the simdisc source code module from cvs:
$ cvs -d :local:/home/jewell/cvsroot export -r RELEASE_01 simdisc
$ cd simdisc/src
This project uses GNU autoconf to determine the capabilities of the system you are building
it on. To generate a new congure script, you need to run autoconf. Once generated, the
congure script can be copied and packaged with a system distribution. However, the
current congure script is not kept in the cvs repository and thus must be regenerated.
$ autoheader
$ autoconf
The congure script just generated now needs to be executed to create makeles. If you are
using the sunpro compiler on a sun, you might want to add --with-sunpro-templates.
If you have the BDI DI-Guy library installed, make sure you have the BDI environment
variable set as per DI-Guy documentation and then use the --with-diguy option. This
example also species to use the SGI C++ compiler.
From a bourne (i.e. `/bin/sh' or `bash') shell:
$ (CC=cc; export CC; CXX=CC; export CXX; ./configure)
or from `csh' or `tcsh':
% env CC=cc CXX=CC ./configure
Now build it, using GNU make:
$ make
There is a shell script named runme which will run a sample session with a couple of players
and a graphical front end.
$ ./runme
If you type Ctrl-C at the runme script, it should clean up and exit.
16 The SimDisc Ultimate Frisbee Simulation
Appendix C: Glossary 17

Appendix C Glossary
I use many abbreviations. Here's a guide to some of them.
BDI Boston Dynamics Inc.
cmsg This is the name of a class which is an automatic garbage collecting pointer.
iv SGI Open Inventor.
libSoDIGuy
Inventor Scene Object support for DI-Guy library.
libudsgf ultimate disc simulation graphics library
libudssb ultimate disc simulation base library (This library is no longer used.)
libudssm ultimate disc simulation message library
libudsnt ultimate disc simulation networking library
libudspt ultimate disc simulation posix threads library
libudsso ultimate disc simulation object library
libudsut ultimate disc simulation utility library
POSIX Portable Operating System Interface
mcmqueue multicast message queue
mqueue message queue
pt posix threads
pthreads posix threads
ptmqueue posix threads message queue
pto posix threads object
sm simulation message
so simulation object
So scene object. This is an Open Inventor convention.
uds ultimate disc simulation
udspt This was originally the test program for the pthreads interface. It stood for
ultimate disc simulation POSIX threads. Since then, it has become a hacked
front end for all of the various simulation objects.
18 The SimDisc Ultimate Frisbee Simulation
Index 19

Index
B S
bdiplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 smbase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
smdisc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
C smgrab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
smrun 14
cmsg<class T> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 .........................................

smstate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
I smthrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
smtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
ivplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
sobase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

M soclock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
SoDIGuy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
mcmqueue<class T> . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 sodisc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
mqueue<class T> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 soinventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
mutex_lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 soplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
mystr ......................................... 11 soprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

P SoSFDIGuy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ptmqueue<class T> . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
pto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 T
ptofstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 table<class K,class V > . . . . . . . . . . . . . . . . . . . . . 11
20 The SimDisc Ultimate Frisbee Simulation
 i

Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Initial Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Design Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
The Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . 4
The Communication Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
The Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Automated Players . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Oense Player States . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Defense Player States . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A Library Reference . . . . . . . . . . . . . . 11
A.1 Utility Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.1.1 The cmsg<class T > templated class . . . . . . . . . . . . 11
A.1.2 The table<class K, class V > templated class
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.1.3 The mqueue<class T > templated abstract base
class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.1.4 The mystr class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2 Pthreads Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2.1 The pto class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A.2.2 The mutex_lock class. . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2.3 The ptofstream class. . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2.4 The ptmqueue<class T > templated class. . . . . . . . 12
A.3 Networking Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3.1 The mcmqueue<class T > templated class. . . . . . . . 12
A.4 Graphics Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.4.1 The soinventor class. . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.4.2 The bdiplayer class. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.4.3 The ivplayer class. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.5 Inventor DI-Guy Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.5.1 The SoDIGuy class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.5.2 The SoSFDIGuy class. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.6 Simulation Object Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.6.1 The sobase class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.6.2 The sodisc class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ii The SimDisc Ultimate Frisbee Simulation
A.6.3 The soplayer class. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.6.4 The soclock class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.6.5 The soprint class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.7 Simulation Message Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.1 The smbase class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.2 The smstate class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.3 The smdisc class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.4 The smgrab class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.5 The smtime class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.6 The smthrow class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A.7.7 The smrun class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B Example Session . . . . . . . . . . . . . . . 15
Appendix C Glossary . . . . . . . . . . . . . . . . . . . . . . . 17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19