The Park Playground: Operational Platform

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

The Park operational platform was a project that was still actively being developed when I joined. Dashdot, the web development agency that originally built the platform gave me access to the project repositories and I collaborated with them through pull requests. The project consisted of 3 repositories:

1. A backend api written in PHP, using the Laravel
2. An operational platform frontend, built with ReactJS and Redux
3. A ticketing website frontend, built with ReactJS

The biggest challenge with this project was that both the backend (PHP) and the frontend (JS) were not statically typed. The PHP version in use was at least 7.X, which thankfully supported some type hints, but Dashdot's codebase made minimal use of them. This meant I had to rely heavily on guesswork and logging to understand the shape of most data models.

Worse still, the frontend was written in vanilla (no Typescript) JS React and used Redux middleware to transform incoming data, which made onboarding and debugging far more difficult than it should have been. This experience reinforced my belief that statically typed languages are invaluable. The small amount of extra work upfront pays off tenfold as a project grows in size. Basically: be kind to your future self and colleagues.

By the end of 2021, we, or rather I, took over full development of the projects from Dashdot and hosted them ourselves. As I worked through and refactored various parts of the backend, I gradually made the project more maintainable.

One of the major features I built was a system that allowed two gaming fields to be booked for a Nanoclash, a competitive shooter where two teams face off. Internally, these fields were divided into time slots, which had to be validated against multiple conditions to determine whether they were available and therefore bookable by the customer. I first rewrote this system with proper types (instead of using PHP associative arrays and string keys) and then optimized the performance of generating the availability time schedules. In the end, it could handle about ~88k time slot comparisons in about one second. Something I'm still pretty proud of. Through a combination of sensible design, efficient SQL queries, and decent database engineering, I delivered significant backend performance improvements. For example: fetching the booked time slots of the day, an action employees of the Park performed almost every minute, went from taking 9-10 seconds to around 800ms to complete.

By the time I left The Park, I actually enjoyed working on the backend. It now had extensive type hints and with the massive quality of life improvements introduced by PHP 8.x, it was an actual joy to work in. Unfortunately, the same could not be said for the frontend.

Was it impossible to work on the operational frontend? No. Was it fun? Also no. The lack of types and the heavy reliance on Redux middleware data transformations made it the most frustrating project to work on at The Park. It got so bad that we (the developers) would play Rock, Paper, Scissors to decide who had to fix a bug when reported. Over time, it became a Frankenstein project, with new features deliberately avoiding Redux altogether. Where possible, we improved readability by adding JSDoc type annotations, but it remained painful to work in.

The application also lacked a responsive design, much to the frustration of The Park's employees, who always had to use a laptop to access it. I would've loved to do a rewrite and -design of this application, but unfortunately, management never prioritized it.