Posted on Nov 3, 2020 • Updated on Nov 9, 2020

Real Life Exploration Game Powered by Mulesoft

#mulesofthackathon #gamedev #24hourgame #scouts4life

Introduction
The game
How it's made
Links

Introduction

This game has a special place in my heart.
It has been around as a big event within my scouting group for over 20 years, resurfacing every few years as a 24 Hour long higly competitive game. It is fully Corona Proof and can be played with near infinte amounts of players. (this edition had 12 2 person teams)

The sheer amount of administrative work required to host this game was often a big downside, since you'd require at least three to four people to man the phone lines.

This fully mule powered application changes everyting, requiring just a laptop for GameMasters to connect to, and enables players to focus on what the game was meant to be, claiming the playing field. In this years Edition: a 15km by 15km area centered around the beautifull Dutch city of Utrecht. (weekend 30-31 nov)

This is my entry for the mulesoft hackathon, category "Everyday is an API day". I wrote all code in english, but have reserved my right to use dutch for some variables, and the front-end. As this technicaly violates one of the rules of the contest please let me know if that is an issue, and i'l change it.

Here is a small translation guide anyway:
Kwadrant = Quadrant
Kleur = Colour
Controlecode = Control code

See? dutch aint that hard...

The Game

This is an extremely compacted explanation, the actual rules span over 10 pages and are mostly in-jokes and giving the GameMasters mandate to mess with anyone trying to break the rules.

The 24HourGame is as the name suggests, a game that lasts 24 hours.
Players are provided with a map of the playing field seperated into Quadrants.

*Quadrants being used as the name of a marked area of space, not actualy the map divided into four....

In each Quadrant a dot roughly marks the location of a Sticker or QMP (Quadrant Marking Point) which has to be found and claimed using the 24HourGameQuadrantClaimer (available trough QR code on the rules or bit.ly/24HourGameSUO) . (okay, dont judge me, but Azure is expensive and the vm powering this is obviously turned off.)

These Quadrants provide points per minute as long a quadrant is in your control. And some quadrants are worth more points than others.

In previous editions a quadrant was claimed by calling the GameMasters and verifying that your team is on site (for example reciting a code found nearby ). The GameMasters and the team itself would then note it down in a logbook. and at the end of the game all logbooks would be compared to catch any inconsistencies. (yeah, our playerbase cheats... a lot.)
This method of administrating the game required a full time 3 person team on the phone lines, which were pretty much red-hot the entire day.
Not only that, but the resulting calculating work, (initialy on paper, by hand. Later using Excell) often took hours.

All of these processes have been automated by Mule.
Players can claim a Quadrant using a mule hosted front-end, which will perform the anti fraud checking by requesting an on-site security code. (It's initialy on the sticker) if the check passes it provides a new security code that is placed over the original and the Quadrant is claimed for that team. In stead of calculating the points manualy, mule simply updates an Excell Spreadsheet with all the points.(Honestly, thanks for making that a supported file type.)

How it's made

The game engine has a few separate parts, but is fully built in mule4.
The front-end is a simple html form, served by using a static resource loader listening on the game root. Could i have used Apache, IIS or any other webserver here? Of course, but this whole project is one big hack anyway, so i figured why the Bell not. (See what i did there?)

Flow: init-game

On startup the game reads a variable length csv file that imports the quadrants, and their initial values. Since a claim in real world always results in a new code being written on the QMP this csv is overwritten on each claim. This results in the game engine being DR enabled.
Any user errors (like forgetting to update the sticker) that result in calls to the GameMasters can be fixed by looking at the current value of the security code in this CSV (and while not required you could edit it during the game.)

Flow: allow-claims

While the engine is running the game does not necessarily have to be enabled. When presenting the rulebook, and explaining the game it is nice that the interface is available. During dinnertime and/or minigames (not relevant here) the gamemasters could choose to disable claiming as well.
To enable or disable claiming of Quadrants the /allow-claims endpoint has to be hit (i just had a little Postman project for this), this sets a flag in the ObjectStore which is checked against during the claim verification step.

Claiming a quadrant

Listening for post requests on the game root is where the bulk of our code resides.
First we sanitize the input:

While this is far from perfect, and i would never deploy this in any corporate production environment, this is more then enough to sanitize any and all BS that could be produced using the Form page.
Jokers that fill in weird stuff only end up harming their team, since the points are only being counted if they fill in their correct team and subteam number.

After the sanitation the fun things begin; if claims are allowed we check if the entered controll code matches the one in the Object store for the given Quadrant, if not the user gets a rude-ish error page served.
If the code is correct he sees a page telling him the claim is sucessfull and a request to write down a newly generated security code for the next team to use.

This ensures a few things, namely that only by phisicaly being at the QMP a new team can claim this quadrant, a photo taken earlier is not usefull as the new code is only available on-site. It also aids in problem resolving, as this security code is logged together with who entered the previous code. Should the organisation be contacted with problems we can quickly read the claim logs to see which team caused a problem when, and deduct/grant points accordingly.

The wrap up process for this does a few things as well.
We make certain that the initial import file is updated to reflect this new code, should the game be restarted we'd like for these new codes to still be effective.
We have a file connector that opens an Excell file, and that adds the claim to the claimed Quadrant's tab, some Excell magic later on calculates the QuadrantMinutes for us, completely negating all the required manual effort.

Someone from mule reading this?
Could you add a page to the docs on how to properly use the output --- application/xlsx datatype? this Dataweave took hours to write...