A year of gamedev experiments.

Day 81 - GGJ2017 Postmortem

Solo and Scoped Down

As is my tradition, traveled to Cleveland Ohio to take part in their game jam gathering. It’s a
great group; a little larger each year, which is good, but still very friendly and helpful.

Since I was acting as an organizer this time, I was unsure if I’d actually be able to contribute at
all, so I turned down any invitations to join a team. Knowing that I’d be working by myself, I also
kept the scope incredibly small.

One way to keep it simple was to eject graphics and sound entirely. One way to keep it interesting
was to make it a multiplayer game. One of the
GGJ 2017 Diversifiers,
“Crowd Control”, called for an eight-player game; this piqued my interest, so I committed to that.

SMS?

In the interest of being able to play around with some relatively unfamiliar tech, I decided to do
a play-by-SMS game. Players would send text messages with their commands to a common phone number,
and get responses the same way to let them know their current state.

The day job had led me to be familiar with a service called Twilio,
which allows you to set up a phone number and have the messages sent to an HTTP endpoint, which
can then be responded to via their API. They have many other services as well, but simple SMS
response stuff is all I needed for this game.

A free account at Twilio would do most of what I needed, but would take up some of the text space
with “Sent from a Twilio trial account”; so I made a paid account and threw $50 into it, hoping
that would last long enough for the Jam.

Fight The Tide

After the theme (“Waves”) was announced, I pretty quickly came up with the premise: an eight-player
brawl on the beach, with players chasing and kicking each other. As the waves recede, the players'
feet are freed up to do more damage, but when the waves come crashing in they’ll knock over players
who aren’t prepared for it.

Why are they just kicking? Maybe they’re in handcuffs; maybe it’s a prison break and there’s only
room on the boat for one. Without needing art assets, the premise can be very flexible.

Running in the Cloud

I definitely didn’t want the game server running on my laptop; I couldn’t guarantee that it would
be online all the time, let alone accessible from Twilio’s servers. So I spun up a free t2.micro
instance on AWS to host the server. It had a clone of the GitLab repo, so I could do development
either directly on the instance or on my laptop.

Interesting trade-offs always arise from cloud security. In the case of this game server, I opted
for:

SSH access from the IPs at the local GGJ site (and therefore me).

Webserver running on a nonstandard port open to the world (and therefore Twilio and me).

Following some of Twilio’s examples, I set up Sinatra to handle the
web requests, and pointed Twilio at the server.

In order to send messages, I would need to utilize my Twilio API keys, which needed to be kept
secret (because they would give someone the ability to cost me money). In the code (which is in a
public repository) I just call out to OS environment variables, which I set with a separate
script that wasn’t in source control.

The Code

Beware. Ugly Ruby code ahead.

Phase One: One-player RPS

As a first step to prove out my integration with Twilio, I implemented a quick-and-dirty rock,
paper, scissors game:

Phase Four: Map and Status Screens

I was playing with two phones most of the time to check my work, but it became clear that I needed a
better way to see what was going on with all of the players. So I implemented a quick map using
code I’m definitely not proud of: