In 2018, the St. Louis game-development community was invited to make games for a real museum arcade cabinet. I helped build the software that ran the cabinets, then joined the BunnyGun team to make one of the games that went into them.

The cabinet came before the game

The local game-development group needed more than a wooden cabinet and a collection of executables. It needed software that could present games from different teams as one public experience and keep the cabinet usable without asking museum visitors to understand the machinery underneath it. I wrote software for that cabinet system.

The 2018 Saint Louis Arcade Jam ran from September 28 through 30. The public brief was unusually concrete: make arcade games over the weekend, then prepare qualifying projects for a cabinet in the Science Center’s upcoming GameXPloration exhibit. About 100 people made 22 games. The exhibit opened October 13.

That changed the feeling of the jam. We weren’t only making something to show the other teams on Sunday. We were building for families, school groups, and anybody else who might walk up to an unfamiliar arcade machine months later.

Then we made FrogBug

My BunnyGun team built FrogBug, a one- or two-player arcade game inspired by the Science Center’s Life Science Lab. You control a frog, eat as many bugs as possible before the round ends, go after the more valuable butterflies and dragonflies, and try not to eat the wasps.

The scope was intentionally small. A museum game needs to make sense quickly, work with cabinet controls, and hand itself cleanly to the next visitor. There is no onboarding call and nobody standing nearby to explain a complicated ruleset. The game has to teach itself through play.

Ink sketch of a frog catching a bug with its tongue
Early ink sketch — frog, bug, done.
Pencil sketch of a crowned frog by Allison Haskins
Allison Haskins’s crowned-frog sketch from the jam weekend.

FrogBug made it into GameXPloration along with the other selected jam projects. That was when our weekend prototype met its real test environment.

Players gathered around the FrogBug arcade cabinet at the Science Center
FrogBug on the museum cabinet — solo or co-op, press to play.
Nathan Haskins pointing at the FrogBug arcade cabinet at the Saint Louis Science Center
Game 12 of 22 on the Saint Louis Arcade Jam cabinet at the Science Center.
FrogBug title screen on the Saint Louis Arcade Jam cabinet menu showing over 6,000 plays
Game 12 of 22 on the cabinet menu — and thousands of plays logged.

The museum found what we missed

At a desk, you test the paths you expect. In a public exhibit, hundreds of kids bring rapid inputs, interrupted sessions, repeated restarts, and combinations of behavior nobody on the team thought to try. The software broke more than once.

We treated each failure as information. We found the rough edges, fixed them, redeployed, and watched what happened next. Over time the installation became stable enough to do what museum software is supposed to do: disappear behind the experience and keep working.

That was a useful lesson in the distance between a successful demo and a durable product. The game jam got us to a playable idea. The public installation taught us what production really required.

I also became part of the exhibit

My contribution wasn’t limited to the cabinets. The Science Center interviewed me, James Kane , and another local contributor about where augmented and virtual reality were headed. That conversation became a video inside GameXPloration near the VR section.

The exhibit was designed around the past, present, and future of digital games, including VR and AR. The cabinets let visitors play work made by the local development community; the interview gave us a chance to explain where we thought the medium was going.

Still there

As I write this in 2026, the cabinet work and the interview are still part of the exhibit. I didn’t expect a weekend project and a recorded conversation to remain in a public science museum for this long.

Looking back, the interesting part is the combination. I helped make infrastructure for other developers’ games, built a game with my own team, supported it after real visitors started using it, and helped explain an emerging technology to the general public. None of those pieces was a grand standalone achievement. Together, they document the kind of work I’ve kept returning to: make the technology usable, put it in front of people, pay attention to where they get stuck, and improve it.

Play FrogBug

The downloadable version and original description are still available on FrogBug’s itch.io page .

Sources and exhibit records

Community infrastructure · Game development · Public education More DevRel work →