The Park Playground: Customer Highscores

The Park Playground is an entertainment company where people can play free roam VR games in group.

Highscores.. sounds simple right? It's not. At least, it wasn't at The Park Playground.

The challenge started with capturing player information during their (semi-mandatory) registration before the VR game began. Assuming that part went smoothly, the next step was to provide that data to a local auto-polling program developed by Triangle Factory, the external studio responsible for our game development. The player names then had to be loaded into the game server, which, at the end of the session, would collect the highscores for each player and send them to our API endpoint for that specific game. Finally, our backend would make this data available to the Next.js frontend you see in the screenshots above.

"That doesn't sound too difficult?" I hear you saying. And you'd be right, IF this had been the coordinated setup from the start. In reality, the first version of the highscores feature was built by an intern before my time, using an Excel sheet and Google Apps Script (it's a thing, look it up). When I took over, I quickly migrated the system to an SQL database and added a proper API in front of it.

The next major problem was the server code that was being polled by the local auto-polling program. It consisted of a collection of untyped, uncommented and outdated PHP scripts originally (and hastily) set up by Dashdot, the web agency that built The Park operational platform. It was then dropped by them and picked up by Triangle Factory, who modified the database schemas. Being game -, not web developers, the results weren't exactly elegant. Later, someone from yet another agency stepped in just to deploy the code to Microsoft Azure instead of AWS, even though that's where most of our infrastructure resided. The result was a fragile patchwork of files that no one dared to touch.

The final headache was that the game server's data format was never standardized. Each game, and even different builds of the same game, sent data with inconsistent property names, missing fields, or completely different structures. This gradually improved toward the end of my time at The Park, but it remained a persistent issue.

So in all that chaos we, the developers, were asked to provide highscores without any data loss. With a lot of sensible defaults and blocking requests that were too malformed, we managed to somewhat get a presentable solution, though there was still plenty of room for improvement when I left.

It is, without a doubt, the most fractured project I've ever worked on.