Greg Dunham, Nick Trienens, Sanjay Sood, Andy Crossen, Kirk Moore
CS 395 Scripting Languages
Northwestern University
Fall 2001

The latest incarnation of the Patton system is located in the DLL modules included with FlexBot:

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