BeerDash (Working Title)

URP fits the low-poly art style well and keeps frame rates high, which is non-negotiable for a game where milliseconds matter in competitive time trials.

Overview

BeerDash is a fast-paced, first person runner designed to capture the highly competitive, "one-more-run" loop of games like Trackmania, but played entirely on foot. The concept originated from a joke game I built with friends back in high school (lukio) centered around the concept of "juoksukaljat" (a Finnish slang term for a quick beer run/snatch-and-grab). While that initial project was purely for laughs, the core mechanic of racing friends for the absolute fastest time proved incredibly engaging.

BeerDash evolves that humorous premise into a structured, mechanically tight game. (Note: The theme is intended purely for comedic effect and does not promote actual illegal activities.)

Visual Identity

To keep the gameplay readable at high speeds, the art direction utilizes a stark, lowpoly aesthetic heavily inspired by Superhot. The environment, a stylized supermarket, is rendered in clean, monochromatic whites and cool grays under bright fluorescent lighting. This deliberate lack of background color serves a distinct gameplay purpose: it immediately draws the player's eye to the objective. The item you need to grab is highlighted as a vibrant, untextured red cube, creating instant visual hierarchy.

Custom Kinematic Character Controller

The movement system doesn't use Unity's built-in Rigidbody physics at all. The Rigidbody component exists on the player purely for trigger collision detection and is set to isKinematic = true. All actual movement is handled by a custom controller that manually traces collider positions, resolves penetrations, and moves the player origin directly through vector math. This gives full control over how the character interacts with the world, which is critical when the entire game revolves around precise, repeatable movement.

The physics simulation runs on a fixed timestep at 128 ticks per second (matching modern Source engine's default tick rate). An accumulator pattern tracks leftover frame time, and the rendered position is interpolated between physics ticks to keep everything smooth on screen regardless of framerate. This separation between physics and rendering is what makes the movement feel deterministic and consistent across different hardware.

Air Strafing and Momentum

The air control system is modeled after Quake/Source engine air strafing, but implemented intentionally rather than as an engine exploit. When airborne, the player's velocity is modified through a dedicated air acceleration function. The core math uses Vector3.Dot to project the current velocity onto the player's wish direction, calculates how much speed can be added without exceeding the air speed cap, then applies that acceleration along the wish vector:

float currentSpeed = Vector3.Dot(velocity, wishDir);
float addSpeed = wishSpeed - currentSpeed;
if (addSpeed <= 0) return;
float accelSpeed = Mathf.Min(acceleration * deltaTime * wishSpeed, addSpeed);
velocity += accelSpeed * wishDir;

This is why air strafing works: when the player looks slightly off their movement direction and holds a strafe key, the dot product between velocity and the new wish direction is small, leaving room to add speed. Over successive frames this curves the trajectory and builds momentum. The SurfPhysics.Reflect function then handles collision resolution so the player slides along surfaces rather than stopping dead.

The Escape and The Antagonist

The game's twist happens the moment you pick up the item. Your objective flips: get back to the starting point to lock in your time. But grabbing the container triggers the store's security guard, an AI that chases you through the aisles using Unity's NavMesh pathfinding system.

NavMesh handles the guard's navigation through the supermarket layout, calculating paths around shelving units, through narrow aisles, and around obstacles in real time. The guard's speed and path recalculation rate are tuned so that a player moving efficiently can outrun it, but sloppy movement or bad routing gets punished. This turns the return trip from a simple sprint into a tense evasion sequence where slide timing and route choice actually matter under pressure.

Audio (Wwise)

All game audio is handled through Wwise rather than Unity's built-in audio system. Wwise gives granular control over how sounds behave contextually: footstep events change based on movement state (walking, sprinting, crouching), landing and jumping have dedicated events, and sliding triggers its own sound. Footstep timing is driven by the physics system rather than animation events, so audio stays perfectly synced with the actual movement speed. The step interval adjusts dynamically between sprint, walk, and crouch paces, and there's an immediate footstep on the first frame of movement for instant feedback.