Efficiency — Touch Race

Overview

Touch Race is an interactive Unity experience designed to engage event visitors through a futuristic race that is quick to understand and play. The user guides a spaceship along a 3D track, changes lane through touch controls, and collects boosters that temporarily increase speed, alter the track’s visual feedback, and contribute to the final session summary.

The experience turns the message “Fueling the efficiency for better outcomes” into a concrete mechanic: the vehicle moves automatically, while the player must recognize opportunities and choose the most effective lane at the right time. The challenge does not rely on complex controls, but on attention, reaction speed, and the ability to collect as many power-ups as possible.

The same installation supports either a full-screen individual session or a local challenge between two people. In multiplayer mode, the display is split vertically into two areas, each with its own camera, track, and controls. Results compare finish times and identify the winner while showing both players how many boosters they obtained and missed.

The landing and home screens use looping video to attract attention and introduce the experience. Fades, audio feedback, emissive track changes, and a final celebration effect create a continuous flow intended for autonomous use on a public device.

Speed, lane choice, and boosters turn the theme of efficiency into an immediate touch challenge for one or two players.

Project snapshot

Item	Detail
Type	Full-screen interactive 3D racing game for touch displays
Intended contexts	Events, conferences, trade shows, brand activations, and exhibition spaces
Documented release	1.1.0
Engine	Unity 6 (6000.2.8f1)
Experience format	16:9 landscape, 3840 × 2160 px UI reference
Interface language	English
Modes	Single player and local two-player split-screen
Platform	Windows — Universal Windows Platform (UWP)
Development	TopTouch

Context and goals

In a conference or trade-show setting, an experience must communicate how it works within seconds, support short sessions, and remain approachable to different visitors without training. Touch Race addresses this scenario through one essential mechanic — moving across three lanes — presented within an audiovisual identity tied to efficiency and performance.

The project addresses five main goals:

• Attract: use video, motion, light, and an animated landing screen to make the installation noticeable from a distance.
• Engage: provide a short challenge with readable rules and immediate touch controls.
• Express the message: associate booster collection with efficiency and improved outcomes.
• Encourage social interaction: allow two visitors to race simultaneously on the same display.
• Ensure continuity: restore the menu and landing state between sessions and remove runtime objects from the completed race.

The technology stays in the background: players only need to choose a mode, watch the track, and tap the controls to change lane.

User experience

The journey is organized into five moments:

• Landing / attract mode: a looping video, a “Tap to start” message, and a moving visual element invite the visitor to interact.
• Mode selection: the home screen offers “One player” and “Two players”; selecting either option starts the race directly.
• Race: the spaceship moves automatically along the track spline. Two touch buttons move it between the left, center, and right lanes.
• Boosters and feedback: collecting an item applies a temporary speed increase, displays its icon, plays a sound, and changes the track’s emissive color.
• Results: the finish screen shows time in minutes, seconds, and centiseconds and lists obtained and missed boosters for each of the four types. A two-player match also identifies the winner.

In single-player mode, the camera fills the display. In two-player mode, each participant has one half of the screen and a dedicated pair of controls. When one player finishes, their controls are disabled while the other player can continue; the summary opens only after both have reached the finish line.

Automatic forward movement reduces cognitive load and leaves lane choice as the only required decision. This design suits a fast public experience, but does not by itself constitute accessibility certification: readability, contrast, touch-target size, physical reach, and panel response must be validated on the final installation.

Experience flow

The application opens on the animated landing screen. The first touch reveals the home page; choosing one or two players then determines the layout, creates the track and spaceships at runtime, and starts the race after a short initial phase.

During the race, the system measures each participant’s time and records collected booster instances while preventing duplicate counts. The vehicle follows the track at a constant distance-based speed; lane changes are interpolated to keep movement smooth through curves.

At the finish line, the spaceship stops and its time is frozen. In multiplayer, the first participant waits for the second. Once the session is complete, times and counts are copied into a snapshot, gameplay objects are removed, and the result screen appears. A new touch or back action returns to mode selection.

Landing video / attract mode
          ↓ first touch
Home — mode selection
     ├── One player ──→ full-screen track and camera
     └── Two players ─→ two tracks and split-screen
                               ↓
                       automatic race start
                               ↓
                  lane changes + booster collection
                               ↓
                       finish and final time
                    ├── single: results
                    └── multi: wait for P1/P2
                               ↓
          time + obtained/missed boosters + winner
                               ↓
                         return to home
                               ↓ idle outside race
                         new landing loop

Value delivered

For visitors

• Provides an interaction that is understandable without a lengthy tutorial.
• Turns an abstract message about efficiency into a visible, measurable action.
• Offers a choice between a personal attempt and a shared challenge.
• Delivers an immediate outcome through time, collected boosters, and player comparison.

For the brand and event

• Creates an audiovisual attraction point suited to an exhibition environment.
• Combines message, visual identity, and game mechanic in one journey.
• Encourages participation, competition, and conversation among visitors.
• Keeps the path from invitation to interaction and result deliberately short.

For operations

• Runs as a local application without requiring visitor accounts.
• Clears the track, players, cameras, and temporary state at the end of a session.
• Automatically returns to the landing screen after 120 seconds of inactivity in the menu or results.
• Prevents an automatic idle return while a race is active.

My role

• Designed the application flow across landing, home, gameplay, and results within one main Unity scene.
• Implemented single-player and local two-player modes with independent viewports, Cinemachine cameras, and touch controls.
• Developed automatic spline movement, the three-lane system, and smooth lateral interpolation for the spaceship.
• Created a configurable ScriptableObject-based booster system covering track distribution, unique identification, collection counts, and temporary speed increases.
• Implemented collection feedback through icons, sound, emissive track-material changes, and obtained/missed result summaries.
• Developed timing, asynchronous two-player finishes, winner calculation, and dedicated single- and multiplayer result layouts.
• Integrated landing and home videos, state transitions, UI animations, and a celebratory particle effect.
• Implemented inactivity handling and runtime-object cleanup to prepare the installation reliably for the next session.
• Configured the Unity project for Windows UWP deployment and touch-display interaction.

Application architecture

The solution keeps the production experience in one scene while separating its main responsibilities into focused components:

• Orchestration: GameBootstrap maintains the Landing, Main Menu, Gameplay, and Results states; creates runtime content, coordinates the race, and handles reset and inactivity.
• Gameplay: RunnerOnSpline controls forward and lane movement; RunnerPowerupEffects applies boosters; RunnerStats records time, counts, and score.
• Track and content: TrackRoot exposes the spline and materials, while TrackPowerupSpawner distributes boosters. Prefabs and PowerupDefinition assets keep configuration outside orchestration code.
• Presentation: mode selection, player controls, results, booster icons, fades, and the landing screen translate application state into a touch interface.
• Audiovisual layer: Video Player, Cinemachine, the Universal Render Pipeline, emissive materials, one-shot audio, and particles provide presentation and feedback.

Tracks and players exist only during an active session. Multiplayer creates two independent copies of the race world; their cameras render the left and right halves of the display and use separate Cinemachine output channels. Only one AudioListener remains active to prevent duplicated audio output.

┌──────────────────────────────────────────────────────────┐
│                    Touch experience UI                    │
│       Landing · Mode selection · Controls · Results      │
└────────────────────────────┬─────────────────────────────┘
                             │ events and state
┌────────────────────────────▼─────────────────────────────┐
│                       GameBootstrap                       │
│ session · spawning · split-screen · finish · reset       │
└───────────────┬────────────────────────────┬─────────────┘
                │                            │
┌───────────────▼────────────────┐  ┌────────▼──────────────┐
│          Race domain            │  │ Configured content    │
│ spline · lanes · time · boosts  │  │ prefabs · ScriptableObj│
│ statistics · track feedback     │  │ video · audio · VFX   │
└─────────────────────────────────┘  └───────────────────────┘

Operational continuity and session lifecycle

At startup, the application sets a 60-frame-per-second target, hides the menu and results, and activates the landing screen with its looping video. The first touch is captured by a full-screen UI area and transitions to the home page through a fade that temporarily blocks input.

Selecting a mode starts a new session after removing any leftovers. The production prefab contains a spline-based 3D track; its configuration distributes fifteen instances for each of four booster definitions across the three lanes with controlled spacing. Each player receives an independent track, spaceship, camera, and statistics collection.

At the end, only the data needed by the result screen is retained in memory. Runtime spaceships, tracks, and cameras are destroyed before the summary appears, reducing the chance that state or rendering from the previous session will affect the next one.

Inactivity detection considers touch, clicks, and mouse movement. After 120 seconds without input on the home or result screens, the application performs cleanup, stops the home video, and reactivates the landing screen. The timer does not run during gameplay, so an active race is never interrupted by idle handling.

The inspected experience does not depend on remote data and does not store rankings or profiles on the device. Operational continuity therefore focuses on correctly resetting memory, dynamic GameObjects, and media between consecutive sessions.

Security and privacy

The documented gameplay contains no authentication, personal-data collection, application-level remote services, or persistent result storage. Times and booster counts belong to the active session and remain in memory only to compose the final summary; returning to the menu prepares fresh structures for the next race.

This architecture reduces the privacy surface, but a public installation still requires operational safeguards: restricted access to Windows, controlled application startup, blocked system shortcuts, device updates, physical port protection, and review of logs generated by the player.

For UWP distribution, test certificates should be replaced with production signing credentials, with private keys stored outside the repository and a renewal process defined. This document describes behavior found in the project and is not a security or regulatory compliance certification.

Design decisions and trade-offs

Decision	Benefit	Aspect to manage
Experience contained in one main production scene	Fast transitions and shared references between UI and gameplay	Hierarchy growth and initialization order
Automatic forward movement with lane-only controls	Immediate rules suited to short sessions	Deliberately limited gameplay depth
Distance-based spline movement	Uniform speed through curves and easily editable track shape	Alignment between spline, mesh, colliders, and lane width
Two independent race worlds in multiplayer	Isolation of cameras, pickups, and statistics	Higher memory and rendering cost than a shared track
ScriptableObject-defined boosters	Inspector-configurable parameters, prefabs, and identities	IDs, UI order, and associated values must remain valid
Automatic spawning on random lanes	Less predictable sessions without authoring every pickup	Balance and direct comparability between players
Result snapshot before cleanup	Final screen is independent of race objects	Data remains memory-only and is not retained historically
Automatic reset outside gameplay	Installation stays ready for consecutive visitors	Idle threshold must be calibrated for the real venue
Runtime-cloned material for emissive feedback	Each track changes independently without modifying source assets	Material-instance lifecycle and shader compatibility

Design challenges

• Making a 3D race immediately usable on a touch screen without lengthy instructions.
• Maintaining a uniform perceived speed while the spaceship travels along spline-defined curves.
• Smoothing movement across three lanes without unwanted roll or visual departure from the track.
• Coordinating two simultaneous sessions, viewports, and Cinemachine channels on one device.
• Handling players finishing at different times without interrupting the remaining racer.
• Distributing four booster families while preserving spacing and visual readability.
• Aligning speed feedback with icons, sounds, and emissive track-material changes.
• Fully clearing players, tracks, listeners, events, and controls between sessions.
• Keeping UI and rendering readable and fluid at the exhibition display’s operating resolution.

Quality and acceptance criteria

The following criteria make the experience verifiable on the final device:

• Startup on the landing screen, continuous video playback, and home-page opening on the first touch.
• Correct launch of both “One player” and “Two players” without objects left from a previous session.
• Full-screen viewport in single player and correct left/right division in multiplayer.
• Consistent touch-button response, clamping to three lanes, and smooth lateral movement.
• Constant-speed progress along the full spline and reliable finish-line detection.
• Unique booster collection, temporary speed application, and restoration of base speed.
• Consistency between the collected booster, icon, audio, track color, and result count.
• Time displayed as mm:ss:cc and winner determined by the lower finish time.
• In multiplayer, only the finished player’s controls are disabled while the summary waits for the second player.
• Runtime tracks, spaceships, and cameras are destroyed before a new session starts.
• Return to the landing screen after 120 seconds without touch or mouse input in home/results, but never during a race.
• Rendering and touch targets verified on the physical panel at its operating resolution and scale.
• Repeated sessions and long-running video/audio playback tested without abnormal memory growth.
• UWP package creation, signing, installation, and updating verified on the target device.

Tech stack

• Engine: Unity 6 (6000.2.8f1)
• Language: C#
• Rendering: Universal Render Pipeline 17.2 and Shader Graph
• Post-processing / glow: URP Volume and MK Glow
• UI and text: uGUI, TextMesh Pro, and Slate Pro fonts
• Paths: Unity Splines 2.8.2
• Cameras: Cinemachine 3.1.5 with separate split-screen channels
• Input: uGUI touch buttons, mouse, and keyboard fallback; Unity input handling configured for compatibility
• Video: Unity Video Player with Render Textures for the landing and home screens
• Audio and VFX: AudioSource, one-shot clips, and Particle System
• Gameplay configuration: prefabs, serialized components, and ScriptableObjects for boosters
• Target: full-screen Windows UWP application for landscape touch displays

Potential evolution

The following items are a proposed roadmap and are not presented as currently available features:

• Configure base speed, countdown, item totals, and result text from one source, removing duplicated or hard-coded values.
• Display a complete race countdown with synchronized feedback for both players.
• Use the same sequence or random seed for both participants to make multiplayer races directly comparable.
• Introduce additional tracks and an explicit selection or rotation strategy.
• Give the four booster types more distinct behavior beyond different speed multipliers.
• Add text localization and editorial configuration for landing, home, and result content.
• Introduce pooling for pickups, tracks, and effects if device testing reveals allocation spikes.
• Add an optional local leaderboard, result QR code, or aggregate analytics, subject to explicit privacy requirements.
• Automate tests for counts, race completion, winner selection, reset, and state transitions.
• Run an accessibility and usability audit on the physical panel, focusing on contrast, button size, and simultaneous use by two people.
• Formalize UWP build, signing, and update workflows with production certificates and rollback procedures.
• Separate legacy and sample assets from files required by the build to reduce project size and complexity.

Highlights

• A three-lane mechanic that can be understood within seconds on a public touch display.
• Single-player and local two-player competition in the same installation.
• Spline-based movement that separates track shape from movement logic.
• Configurable boosters combining speed, sound, icons, and track-color response.
• Split-screen with independent cameras and statistics for both participants.
• Immediate results with finish time, competitive comparison, and collection summary.
• Video landing and home screens that keep the installation attractive between sessions.
• Cleanup and automatic return to the initial state designed for continuous exhibition use.

Credits and rights

Project developed by TopTouch.
Trademarks, logos, audiovisual content, and proprietary assets belonging to MIXER PA, Zimmer Biomet, Totally Hip, and any other represented parties remain the property of their respective owners.