Parallel to the other courses in my master’s degree, there was one class that everyone was particularly excited about: Competitive Game Design. By the time we reached the halfway point of the semester and were allowed to start our project work, the excitement was really noticeable. Naturally, we were hyped to jump back into game development and build another project together as a team.

Focus

Different to our previous projects, this one came with a very different mindset. The goal was no longer to simply create a game that felt good, looked nice, or was fun in an intuitive sense. Instead, we were required to work with a clear, deliberate design intention from the very beginning.

A significant 80% of our final grade depended entirely on our gameplay mechanics and how they evolved over the course of development. This meant that iteration wasn’t optional, it was the core of the project. We had to regularly pitch our current gameplay concepts and the state of the game to our professors, explaining not only what had changed, but why. Every gameplay decision needed justification through analytical data. To support this, we were expected to build tools that allowed us to track playtests, gather meaningful metrics, and evaluate player behaviour. Design decisions could no longer be based on gut feeling alone, they had to be backed by evidence.

What is DDD?

Dino Delivery Derby (DDD) is a chaotic local multiplayer game made for shouting, laughing, and shamelessly sabotaging your friends on the couch. You play as a delivery driver in a city filled with impatient customers. Everyone wants their package delivered, but only one player can claim the job. Race through crowded streets, steal deliveries from your rivals, and outmaneuver the competition to earn that 5-star Yelp review.

But speed isn’t everything.

If a package is not delivered on time, it turns into a ticking liability. And trust us, you really don’t want to be the one still holding it when things go wrong.

Whenever a new package appears and needs to be delivered, all players race to claim it. The moment a player picks up the delivery, they become the target, every other player will try to steal the package to earn the chance to deliver it themselves. If the delivery does not arrive in time, the customer grows impatient and starts writing a bad review.

Successfully delivering a package earns you a review star, but a failed delivery costs you one. This flips the dynamic entirely. The player currently holding the package now desperately tries to pass it on to someone else, hoping they will be the one stuck with the bad review instead.

This mechanic creates a constant state of competition with a shifting objective. At any given moment, it’s either everyone for themselves or everyone against the one holding the package, and that balance can change in an instant.

While this core mechanic already establishes a strong competitive target, it wasn’t enough on its own. We identified two additional needs early on.
First, we needed more player-driven chaos elements that ensure no two rounds ever play out the same and that reduce predictability.
Second, we wanted mechanics that reward skilled and experienced players without making the game feel unfair or inaccessible to newcomers.

Environmental Chaos

The first goal was straightforward, add items, inspired by games like Mario Kart. Players can deploy exploding tires, place fake item boxes, drop oil puddles, or create temporary physical barriers. Importantly, these items never directly affect other players. Instead, they alter the environment itself, forcing everyone to react and adapt or get punished. By turning the streets into constantly shifting obstacle courses, even a familiar pursuit becomes stressful, unpredictable and chaotic.

Skill Expression Through Movement

To reward mechanical skill, we introduced a variety of movement abilities. Players can activate a powerful speed boost, perform quick side dashes, or even execute a 180-degree flip to rapidly change direction or fake a turn. However, during playtesting we quickly realized that some of these abilities were simply too strong to be available at all times. We initially tried balancing them with cooldowns, but this led to constant ability spamming and reduced their strategic value. Players used them reflexively instead of tactically.

Coins as a Strategic Resource

The solution came in the form of a single, unifying resource: coins. Coins are the backbone of the game’s economy. They are required to boost, activate movement abilities, and purchase items. On top of that, coins are dropped whenever a player gets stunned, allowing opponents to steal them and are continuously deducted while a player is holding a bad review, further incentivizing them to get rid of it as quickly as possible. To acquire coins, players most often need to take a step back from the active pursuit to collect them, giving the target some room to breathe.

This system forced players to make meaningful decisions: Is this ability worth the cost right now? Should I spend my coins to escape, or save them to catch someone?

Through extensive iteration and tuning, we noticed a significant improvement in overall balance. Skilled players gained a clear advantage through better resource management and decision-making, while newer players were never locked out of winning, creating exactly the competitive dynamic we were aiming for.

My Role

For this project, we worked as a team of three developers. While we collaborated closely across all areas of development, each of us also took on clear primary responsibilities.

My first responsibility, shared with one other developer, was gameplay implementation and in-engine work. This included implementing mechanics, iterating on feel, and ensuring that our systems worked cohesively during playtests.

My second responsibility emerged naturally from my strong interest in tool development for the Unity Engine. I took the lead on planning and building internal tools that allowed us to log, analyse, and compare analytical data from our playtests.

Our very first playtest took place surprisingly early in development. Despite the game being in a rough state, it was mandatory that we collect and analyse data from this initial session. To support this, I built a lightweight logging system capable of tracking specific player actions, such as picking up coins or using abilities, along with relevant metadata. In most cases, this metadata included player position. Player positions were already being logged at regular intervals, which meant we could later extract and correlate this data with other logged events if deeper analysis was required.

Once the system was in place, we ran the first playtest, while I silently hoped everything would work as intended and that the data would be usable afterward. Thankfully, it did.

From Raw Data to Usable Insights

After the playtest, I wrote a set of simple scripts to replay player position data by reapplying it to placeholder objects in the scene. This gave us a very rudimentary replay system for entire matches. While this was interesting, it quickly became clear that a full replay feature would be beyond the scope of this project. Instead, I shifted focus toward building dedicated analytics tools.

Using the logged position data, I created heatmaps showing where players actually drove across the map. These visualizations helped us identify high-traffic areas and dead zones, allowing us to tweak the map layout, nerfing overly dominant hotspots and making underused areas more attractive.

However, position data alone doesn’t explain why certain areas are avoided. To address this, I expanded the system to visualize additional data layers such as player collisions, item usage, coin gain and loss, ability usage, and more.

Having access to this level of detail made balancing the game genuinely enjoyable. We could confidently tweak item drop rates, round durations, mission timers, spawn locations, and coin placement, always backed by data rather than guesswork.

Once these tools were in place, they saved us countless hours of manual work. Without them, we would have had to record every playtest and manually review footage, a process that would have been significantly slower and far less precise. More importantly, I’m confident we would not have caught nearly as many balancing issues without these analytical tools.

In the end, this system became a cornerstone of our development workflow and a key contributor to the final balance and quality of the game.

Results

Due to the nature and focus of this project, we had to prioritize analytics and gameplay mechanics above all other aspects of game development. Normally, I aim to create projects that feel cohesive, visually polished, and refined in terms of game feel. This time, however, our resources were deliberately allocated elsewhere. We had very limited time and capacity for visuals, asset creation, and polishing. As a result, the game still has some rough edges. To stay within scope while maintaining a baseline level of visual clarity, we relied on third-party assets for which we had purchased licenses. This allowed us to reduce production time and still deliver something that was visually somewhat pleasing and functional.

That said, I believe the project achieved exactly what it was meant to. It significantly deepened our understanding of iterative game design, balancing competitive systems, and most importantly, how to create meaningful analytical pipelines that directly influence design decisions. Working with real data instead of intuition alone fundamentally changed how we approached iteration and evaluation.

If you would like to try the game yourself, feel free to check it out on itch.io. You’ll find a more detailed overview of the mechanics as well as the controls there. I sincerely hope the game brings you and your friends a few loud, chaotic, and fun moments and that you can forgive any remaining rough edges along the way.

Play now