Aup Jewell

The SimDisc Ultimate Frisbee Simulation

Darrin Jewell

[email protected]

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 entertainment or analysis has been created. A model for automated control of virtual humans has been discussed.

The SimDisc Ultimate Frisbee Simulation by Darrin Jewell

[email protected]

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: c 1998 Darrin B. Jewell Copyright 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. Automatic 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 OpenInventor. 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. Currently, 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 environment to be populated with many more people than are actually interacting with the simulation. For example, someone creating an urban planning simulation can use automated 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

2.

3.

4.

5.

6.

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. 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. 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. 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 attached to the simulation as a simulation object which receives broadcast messages and updates the display. 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. 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 strategies. 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 articulated human body representation. The internal state of individual players is available to enhance understanding of the simulation as well as to aid debugging. 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 current 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 environments 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 implemented 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. 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 independent of the communication medium actually used. An mqueue object represents a queue of unread objects of type T and a handle on a set of associated queues. A write to an mqueue 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 implementations. The ptmqueue class is used to communicated among POSIX threads using shared memory. The mcmqueue class is used to communicate among dierent programs any any number of hosts using multicast networking. The simulation objects are programmed to deal only with the mqueue interface and can therefore be instantiated with either implementation.

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 presented as a rendered 3d environment. For ease of implementation, the SGI OpenInventor Toolkit was used to create a virtual environment containing a regulation dimensioned ultimate 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 othe-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 Posession

Near Front of Stack

Establish Pivot Foot

Seek Open Receiver

Attempt Throw

Catch

Score? Pull

Middle Establish Position Near Middle of Stack

Contend for Next Cut

Cut From Stack

Attempt Receive

Rear Establish Position Near Rear of Stack

Await Middle Cut

Contend For Long Cut

Advance Up Field

Make Long Cut

Attempt Receive

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 get throw

Intercept

Disc State ignore throw

Intercept

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

The Line

For Disc

To Assemble

Up

Pull

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 formulated 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 interactive "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 templated class cmsg

Templated Class The cmsg 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 templated class table

Templated Class The table templated class is a generic chaining hashtable. This represents an ecient mutable mapping of one arbitrary type to another.

A.1.3 The mqueue templated abstract base class. mqueue

Templated Abstract Base Class The mqueue templated abstract base class de nes a broadcast message passing interface. An mqueue object represents a handle on a which can have messages pushed or popped from it. A message pushed on an mqueue can be independantly popped from each copy of that mqueue which is made.

A.1.4 The mystr class. mystr

Class represents a string. This was created because existing C++ implentations didn't have a standard string class that worked.

mystr

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

ptofstream

is an iofstream with an assocated mutex lock.

Class

A.2.4 The ptmqueue templated class. ptmqueue

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 templated class. mcmqueue mqueue

communication routines which use multicast networking.

Templaed Class

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

This is an Inventor Node which renders a DI-Guy.

Class

A.5.2 The SoSFDIGuy class. SoSFDIGuy

This is an Inventor Field which holds a diguyCharacterHandle.

Class

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

This represents the frisbee.

Class

A.6.3 The soplayer class. soplayer

This represents a player.

Class

A.6.4 The soclock class. soclock

This represents a clock.

Class

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 simulation.

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

This message holds the current state of a frisbee player.

Class

A.7.3 The smdisc class. smdisc

This message holds the current state of the frisbee.

Class

A.7.4 The smgrab class. smgrab

This message signals a player grabbing for the frisbee.

Class

A.7.5 The smtime class. smtime

This message signals the current time from the clock.

Class

A.7.6 The smthrow class. smthrow

This message represents a player throwing the frisbee.

Class

A.7.7 The smrun class. smrun

This message represents a player running.

Class

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 libudsgf libudssb libudssm libudsnt libudspt libudsso libudsut

POSIX

mcmqueue mqueue pt pthreads ptmqueue pto sm so So uds udspt

Inventor Scene Object support for DI-Guy library. ultimate disc simulation graphics library ultimate disc simulation base library (This library is no longer used.) ultimate disc simulation message library ultimate disc simulation networking library ultimate disc simulation posix threads library ultimate disc simulation object library ultimate disc simulation utility library Portable Operating System Interface multicast message queue message queue posix threads posix threads posix threads message queue posix threads object simulation message simulation object scene object. This is an Open Inventor convention. ultimate disc simulation 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

C

smdisc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

bdiplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

smgrab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

cmsg
T> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

I

M

.........................................

14

smstate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 smtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 sobase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 soclock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

mcmqueue
T> . . . . . . . . . . . . . . . . . . . . . . . . . . .

T> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

mutex_lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

P

smrun

smthrow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

ivplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

mystr

smbase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

.........................................

ptmqueue
12 11 12 11

SoDIGuy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 sodisc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 soinventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 soplayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 soprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 SoSFDIGuy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

T> . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

pto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ptofstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

T

table
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 templated class . . . . . . . . . . . . 11 A.1.2 The table templated class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.1.3 The mqueue 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 templated class. . . . . . . . 12 A.3 Networking Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.3.1 The mcmqueue 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . A.6.4 The soclock class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.6.5 The soprint class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7 Simulation Message Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.1 The smbase class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.2 The smstate class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.3 The smdisc class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.4 The smgrab class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.5 The smtime class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.6 The smthrow class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.7.7 The smrun class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 13 14 14 14 14 14 14 14 14

Appendix B Example Session . . . . . . . . . . . . . . . 15 Appendix C Glossary . . . . . . . . . . . . . . . . . . . . . . . 17 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19