Patton
What does
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 more freedom. Additionally,
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. How was
the system built? The 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. The 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. We created
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. How was scripting language technology leveraged to our advantage? Our team 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. We also
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
together. |
|||
| gdunham@northwestern.edu; n-trienens@northwestern.edu |
