Dunham, Nick Trienens, Sanjay Sood, Andy Crossen, Kirk Moore
CS 395 Scripting Languages
incarnation of the Patton system is located in the DLL modules included
the system do?
Our goal was
to create methods for remote game control and monitoring in FlexBot.
Because the player's focus has changed from controlling an individual
character to managing a team of bots, there is no reason that the player
should still be tied to the desk to manage the game. By taking these
controls from the desktop to mobile wireless devices, players have much
it is important to note that these controls are not necessarily just
good for managing a game of bots. If a player is engaged in a
multiplayer game with other humans, the ability to have game statistics
on a mobile device while actively playing the game is also valuable. It
is easy to imagine a player using his desktop monitor to actually play
the game, while monitoring the positions of all the other players on his
tablet PC as well as peeking at his handheld device for the latest stat
updates. Organizing and increasing screen real estate through the use of
these devices, our system provides a high level view of any game. This
is different from the traditional notion of a “Heads-up display”
since it provides a macro view of the entire game, while facilitating
improved team management and control.
the system built?
FlexBot architecture is written in C++. Because it is based on an
interactive gaming engine, maintaining a high level of performance was
crucial. To this end, we avoided modifying FlexBot itself in favor of
out-sourcing most of our tasks to Perl scripts. Also essential to
maintaining system performance was eliminating as much synchronicity as
possible between FlexBot and our applications. The MySQL server serves
as an essential piece of asynchronicity in our system by allowing
components to access information about the game without forcing all
requests to be handled in a concurrent, blocking manner by FlexBot.
architecture diagram shows the modularization of our system from a
visual perspective. We created as many logical units as possible. This
not only helps with future abstraction and overall flexibility, but it
also helps load balance the system. It would have been disastrous if one
portion of the system was overloaded and either created lag in the game
or lag between the individual components. We wanted to keep everything
as lightweight as possible, keeping low-latency as the first rule at all
times so as not to impede game play.
this client-server system with Perl. There are three servers written in
Perl, each handling a portion of the input and output necessary in this
system. The first server sends out statistical information to a MySQL
database that stores the game state information. A Perl-based CGI script
can then dynamically retrieve and represent all the statistical
information from the database in a logical and relevant manner, suited
for display on a palm-sized device. A second server listens for incoming
commands from a client, allowing control of the game and bots within it
from a web interface. This client is another piece of Perl code
operating as a CGI script to open control of the game. The third server
sends player positions to a radar monitor. This visual game state
monitor is developed in Macromedia Flash. It takes in coordinate and
statistical information via native Flash sockets reading XML to provide
real-time monitoring of player state and position.
scripting language technology leveraged to our advantage?
leveraged the quick prototyping and development afforded by Perl. We
generated several early designs that served as proof-of-concept models
before we focused on second-pass tasks such as improving the interface.
We were able to quickly create a Perl script that populated the database
with important statistical data about a FlexBot game. Getting this done
in such an immediate fashion was crucial to the success of nearly every
other piece of the project because of the components’ dependence on
live, real-time information about a game in progress.
We used Perl
in a scripting capacity when developing the web interfaces for the
project. One example is the command interface web page that takes user
selections from a form and constructs a FlexBot command string that is
passed to the FlexBot command interpreter itself. Similarly, the direct
control “joystick” interface processes user input on a web page and
picks an appropriate command to pass along, resulting in the direct
control of an individual FlexBot behavior. The statistics server uses
scripting to analyze the contents of the database and generate a
representative web interface.
Perl was used
to perform all of the gluing for the project. With several pieces
needing to be written in other languages or on other platforms, Perl
provided an ideal way for these pieces to communicate with one another.
The statistics population server listens for statistical data coming
from FlexBot (which runs on Windows), and populates a MySQL database,
running under Linux on another machine. The position server gathers data
both from FlexBot and from the database and provides this merged data to
the Flash game viewer as XML data. The direct control script provides a
way for the web page to interact with the joystick FlexBot behavior DLL.
The command interface and statistics server perform similar gluing
operations with the database and with FlexBot.
relied on existing Perl modules for sockets and database access. Most
all of our system relied on the basic IO::Socket library, and the
database access was relatively straightforward thanks to the DBI
library. With this leverage, Perl could be used to glue all the parts