Radio Buddy (Global Game Jam 2018)

Posted on February 06, 2018

As is yearly tradition, my friends Andre and Maxime, and I made a game for the Global Game Jam.

Global Game Jam is a yearly event where participants (usually in teams) develop a game according to an announced theme in 48 hours over the week-end.

Our submission

We made a networked multiplayer game for two players. The first player assumes the role of Buddy. He needs to escape the island but can’t see very far. The second player is a radio operator who can see Buddy and the entire island from the top of his radio tower. There’s a huge beast rampaging the area, so the operator must carefully guide Buddy and prevent him from getting caught!

This is what Buddy sees on his screen (not much):

This is what the Operator sees (the entire island, and the Beast fades in and out of visibility):

There’s a day/night cycle (during which the Operator doesn’t see Buddy):

And a story with objectives (that Buddy needs to communicate to the Operator):

These mechanics force the players to communicate frequently about:

  • The current objectives
  • The Beast’s location
  • Buddy’s location at night

Main menu:


It was made using the HaxeFlixel engine.

The networking was implemented through a very basic JSON-encoded protocol acting as a layer on top of TCP sockets. There was not enough time to implement correct entity extrapolation/interpolation and other tricks to account for lag, so the networking might not be great outside of LAN conditions.

The networking model isn’t authoritive. Instead, each player has the exact same game state at startup which is then modified depending on the player’s role. According to their roles, players will take ownership of entities and begin sending physics state updates for the ones they own. This saved us from the hassle of managing entity creation/destruction.

We only needed two remote procedure calls - game won and game over. There was no time to do anything smart so it’s literally the strings “WinGame” and “RestartGame” being sent through TCP.

Perhaps the only elegant part of the rushed networking code is the user API. To make a sprite networked all that’s required is to make it extend our FlxNetSprite class instead of the usual HaxeFlixel FlxSprite class and then set the player ownership. It made it possible to develop an offline version of a sprite class first, and turn it into a networked sprite later with nearly no effort.


You find the download link on the GGJ submission page: