Artscape 2017

On the hottest summer weekend each year, Baltimore plays host to Artscape, the largest free arts festival in the country.  The epicenter of this event, which draws an average of 350,000 people, is my apartment building.  The whole thing is very cool, and rather hard to ignore, even if I thought otherwise.

Code in the Schools, a non-profit organization I help found in 2013, participates in the festival each year, and this year I partnered up with three very talented students from the CitS Prodigy program and a few of my professional game developer friends to create a game that could be played during the festival on a giant LED billboard.

About Code in the Schools

Code in the Schools, or CitS for short, was founded by Mike and Gretchen LeGrand, Dan Halka, Jason Coleman and myself after the collapse of 38 Studios/Big Huge Games in 2013.  Inspired by organizations like Code.org, our mission is to bring computer science education to under-represented groups in Baltimore and to make the future of Baltimore’s tech community reflect the strength, culture and demographics of the city.  Since the organization’s founding, Code in the Schools has become a fixture of the Baltimore tech community, and through our in-school programs, summer camps, mentorships and game jams, we bring high-quality computer science education to thousands of kids each year.

Code in the Schools

Game development has always been part of the Code in the Schools DNA.  The founding members of the organization are all 10-year-plus veterans of the industry, and believe that making games is one of the best ways to teach computer programming.  The opportunity for our students to make a game for Artscape this year was one we couldn’t pass up.

Escape from Camp Artscape

Each year, Artscape has a theme around which all of the art at the festival is (sometimes rather loosely) created.  This year’s theme was “Camp Artscape,” which was very fertile ground for designing a game.  There were several other constraints that were identified early, and impacted the design of the game:

  • The game would be played on a huge LED billboard near our booth.  The game’s visuals must be easily readable from a distance.
  • Gameplay must be self-teaching and easy to understand at a glance.  Players will drop in and out of the game as they wonder by.
  • Play length should be relatively short – beatable by someone who takes the time to stop and play, but not long enough that we lose more casual visitors.
  • The game should heavily feature our branding, as it is at the end of the day an advertising tool for the organization.
  • Even when no one is playing, the game should look great, move and attract attention.
Screenshot
Close to final screenshot

After a weekend of prototyping, I had a direction: a rogue-lite called Escape from Camp Artscape.  The premise is simple:  alien invaders have arrived at Camp Artscape.  You (the Code in the Schools school bus mascot) must find your way out of the forest while collecting treasure and battling aliens.

The rogue-like format satisfied many of the requirements listed above.  In a rogue-like, the game state doesn’t update until the player makes a move, and all moves are tile-based.  This was a perfect match for the drop-in-drop-out gameplay I was after.  It also provided a platform on which to build simple, self-teaching mechanics.  The player has three hearts of health which they lose when fighting aliens, can carry a single one-time-use item to solve puzzles or provide an advantage in combat, and can collect keys to unlock treasure chests.

Two modes of input were designed: a novel Makey Makey device which sat on a table in front of a TV at the booth, and a Twitter interface that let people send Tweets with specific hashtags corresponding to movement directions.

Tools

UE4 screenshot
UE4 editor

Picking the right tools was critical to our success.  I wanted to work as closely as possible to the way I do professionally, both for my benefit and for the edification of the student designers who joined me at the end of the project.

  • Engine: Unreal Engine 4.
  • C++ IDE: Visual Studio 2017.  Accept no substitutes.
  • Source Control: Subversion.  My preference is always Perforce when it comes to source control, but Perforce is expensive and requires a non-trivial setup.  Git is also currently not viable, as it doesn’t easily support versioning large binary files, and doesn’t support file locking.  Subversion was easy to install on my Dreamhost server, and the TortoiseSVN client was similarly easy to setup and use.
  • 3D Modeling and Animation: Maya LTE 2017.
  • Communication: Slack.

Development

I wrote most of the game in C++, with a few mechanical variations made in Blueprint.  Here are a few interesting details:

Commands and Playback

Rogue-likes are turn-based games, and at first glance, one may think that it would be easier to make one of these than a real-time game.  In many respects, this is true.  However, it is crucial that each player may only make a move when the other player isn’t moving, and that a player can’t cheat by making an invalid move during the playback of a previous move.  This may seem like a simple constraint, but a naive approach to this problem can sink a turn-based game of even modest complexity.

The most common approach to this problem, and the one I used for this game, is to decouple the game’s logic from its visuals.  Mutations to the game’s state are made immediately (or immediately-ish, if server validation is involved), while the visual updates are cued and played back over time.  In Artscape, each game state change is packaged into a command object which handles both the state change and visualization playback logic.  When a command is submitted, it immediately applies any state modifications.  The command is then placed into a queue of commands to be visualized.

Twitter Client

The game had a mode where players could control the game’s character by Tweeting directions to the Code in the Schools Twitter feed.  To accomplish this, I wrote a C# app which watched our Twitter feed for specific strings and sent JSON messages to the UE4 client via a TCP/IP socket.  I put quite a bit of work into this, only to find out that our internet connection at the festival wasn’t reliable enough to maintain a consistent connection.  Interesting stuff to learn, though!

“Signals”

Understanding how object instances communicate with each other in an engine like Unreal can be daunting for new designers.  I wanted my students to be able to build novel gameplay from simple parts without having to learn UE4’s event model to make those parts talk to each other.  To solve this, I wrote a system inspired by the QT framework’s Singals and Slots concept.  Any actor can emit “signals” via a special component.  Each signal is a true/false/toggle payload which can be received by any actor which implements the signal receiver interface.  To hook up a signaling object to any number of receivers was as simple as adding an entry to an array in the signal component.

Each signal component on an actor acted as an implicit interface.  For example, a treasure chest actor would have an OpenedSignals component.  A powerup would have a PickedUpSignals component.  Some actors had more than one signals component.  Actors like enemy spawners, loot spawners, hidden doors and traps were all signal receivers.  Over time, I build a rich library of signal senders and receivers, and the rigidly-defined way they communicated made them easy for students to use.

Reception

The game was received very well, and showed great on the big screen.  The photos don’t really do it justice.  The game was easy to pick up and play, and the levels that my students created did a great job of teaching the game without using a tutorial, ramping the challenge and complexity gradually.  At several points during the show, we saw long lines to play the game, and several kids came back multiple times to give it another try.

At the show.
At the show. The photo doesn’t do it justice.