Restarter & RestartIssuer Created for The Bob Bullock Texas State History Museum

Briefly displayed screenshot of Restarter reloading an application.
Screenshot of Restarter reloading an application.

Briefly displayed screenshot of Restarter reloading an application.

Form

CLASSIFICATION //

flash, AIR, kiosk

Format:

Adobe AIR

Audience:

Museum attendees, especially children ages 8–15 on field trips.

Deployment:

Hosted at The Bob Bullock Texas State History Museum, as part of the Tango Alpha Charlie: Texas Aviation Celebration" exhibit. Five dedicated Windows computers encased within custom-built arcade cabinetry. Computers run all day in kiosk mode with automated daily startup/shutdown. Visual output to three plasma monitors, one projector, and a touchscreen. Custom controls were installed to simulate varying gameplay mechanics between each computer's assigned game.

Components:

  • 2 AIR applications, running in tandem
  • 1 text file
  • 1 game SWF

Language:

ActionScript 3.0

Function

CLASSIFICATION //

security

Behavior:

Fail-safe mechanism to restore operation of exited Flash Player instances on computers designed to run as kiosks.

Mechanics:

The Restarter & RestartIssuer are two separate AIR applications, installed as native Windows programs. They're in tandem behind a Flash movie (SWF or AIR), so the entire movie can be closed and reopened without the user noticing.

A text file is used to facilitate communication between RestartIssuer and Restarter.

The RestartIssuer loads the game into itself and continually writes a timestamp to the text file whenever user input is received, signaling that the game is in use and should be kept alive. If the game dispatches an ActionScript "EXIT" event, the RestartIssuer manually requests to have itself and the game restarted by writing "RESTART" to the text file.

The Restarter continually reads the text file. When the Restarter finds "RESTART" or an outdated timestamp, it restarts the RestartIssuer, which fires up a new instance of the game SWF.

Purpose:

  • Prevent general public from exiting game, whether accidentally or maliciously.
  • As fail-safe, if game is exited, restore a new instance of the game, while blocking user input in presentable fashion.
  • Circumvent potential memory leaks by restarting the game whenever not in use for a period of time.
  • Circumvent potential game-crashing bugs by restarting a crashed game.
  • Relieve museum workers of all maintenance responsibility.

Requirements:

Museum exhibit installations needed to be running at all times without fail—completely self-sustaining and bulletproof.

Constraints:

Short time frame meant a solution was needed ASAP

Creation

CLASSIFICATION //

powerhouse-animation

Completion Date:

2010-08

Duration:

1 week

Process:

Choosing Techonology

We looked into purchasing kiosk software, which would run our games inside of it and lock users out of the OS. It was too expensive. As a homebrew solution, I experimented with Flash's fscommand function to make calls that would restart the game, but found I needed to check to see if the program was even running, so decided a monitoring program was needed. Another developer in the studio made an attempt at a preliminary version of that in Java, but I was prototyping an AIR version at the same time. Integration with our Flash games proved more seamless with AIR, so we went with that and I finished this program.

Job

I was the primary point of contact from our studio for communication with the museum. I made frequent visits to the museum to fix various aspects of the games. There were 5 games in total, made by 3 developers from our studio, including myself. Each of our games had some kind of problematic bug at some point, e.g. freezing, crashing, improper resetting.

On one of my trips to the museum to update the software, I walked in to find a group of school children huddled around a touchscreen playing solitaire. That touchscreen was supposed to be running one of our games, but the children managed to navigate themselves out of our game and into a game of Windows solitaire.

Tools:

FlashDevelop, Adobe Flash Professional CS4

Challenges:

It was an unexpected struggle for us to get these games to be child-proof, locking them out, and making sure they were always running smoothly. But, it was nice to see that this solution held the test of time and made our software legitimately deployable in a real-world, heavy-use scenario.