StatusCompleted playable demo / public release

PeriodJanuary 2026 - April 2026, 5 month in total

TeamLead developer (me), core programmer, composer

RoleGame Designer, Lead Developer, UE5 Prototyper

ToolsUnreal Engine 5, Blender, Figma, DaVinci Resolve, Substance Designer

Key challengesPlaytest-driven gameplay iteration, VFX-heavy world optimization, and Steam release preparation.

Overview

A small experiment that became a finished demo.

Cold Engine started as a short capability check and grew into a complete demo. The project tested whether a small team could build, present and release a playable first-person survival-management experience in Unreal Engine.

The player manages a train in an industrial frozen world, balancing deliveries, energy, temperature, cargo pressure and corporate quotas while moving between stations.

Gameplay context boardWorld, train, delivery pressure and resource constraints in one visual.Gameplay context board

Production story

From one-week capability test to a public playable demo.

A production timeline showing how a one-week prototype grew into a public Steam playtest through system development, optimization, player feedback and release preparation.

01 / Prototype

Find the playable promise first.

The project began as a compact test around train pressure, delivery goals and first-person resource management.

Prototype captureEarly layout, train cabin and delivery readability.

02 / Route loop

Make the contract loop readable.

Contract choice, route danger and delivery stakes were shaped into a short loop a player can understand quickly.

Route choice loopContract selection, route risk and delivery pressure.

03 / Cabin systems

Turn pressure into moment-to-moment play.

The cabin, cargo and train state became the player-facing layer for energy, resources and cold-world survival.

Cabin systems passEnergy, cargo and train state readability.

04 / Optimization

Stop the main technical bottleneck.

The movement setup was reworked so the team could finish the demo instead of repeatedly fighting scene cost.

Optimization diagramOld architecture, blocker, rework and result.

05 / Visual and UI pass

Shape the demo for outside viewers.

Materials, props, snow mood, CRT-style interface pieces and video capture were brought together for public presentation.

Visual presentation frameLighting, UI, atmosphere and train readability.

06 / Public output

Finish the slice as something people can inspect.

The work ended as a complete Steam-facing demo with systems, visuals, audio, presentation material and a clear role split.

Final demo captureGameplay, trailer and page presentation.

Gameplay Design Breakdown

Designing the pressure loop

Cold Engine was designed as a short, readable pressure-based demo where the train, cold and resources work as one connected gameplay system. The goal was to give players meaningful priorities inside a compact playable experience: manage resources, react to train problems, move toward the route goal, choose upgrades and decide how much risk to take.

Cold Engine was designed as a short, readable pressure-based demo where the train, cold and resources work as one connected gameplay system.

The goal was to give players meaningful priorities inside a compact playable experience: manage resources, react to train problems, move toward the route goal, choose upgrades and decide how much risk to take.

My Design Ownership

Core Loop & Progression

Designed the main player loop, route goals, player progression and the relationship between train systems, resources and pressure over time.

UI/UX & Tutorial Flow

Designed the onboarding flow, player-facing information, interaction readability and UI/UX logic so players could understand what was happening without long explanations.

Resource & Interaction Logic

Worked on resource behavior, system dependencies, interaction priorities and player decisions around maintaining the train, reacting to problems and preparing for harder routes.

Playtests & Iteration

Prepared playable builds, organized playtests, checked player behavior and documented changes for the next iteration of the demo.

Main Design Challenge

Make cold, train systems and resources feel like one pressure loop.

The main design challenge was to make the train, cold and resources feel like one connected pressure system, not separate mechanics or atmospheric elements. The demo had to be short enough for quick playtesting, but complete enough to communicate the intended experience: a player managing a corporate train under environmental pressure, limited resources and route-based risk.

The key design question was: how can a small demo create meaningful tension without overwhelming the player with too many systems?

Pressure system diagramCore loop dependencies and player pressure flow.Pressure system diagram

Player Decisions

The experience was built around prioritization. The player needed to constantly decide what deserved attention first.

Maintain Resources

Players had to manage resources and react to changing train conditions instead of passively moving through the environment.

Choose Priorities

The player could focus on route progress, train maintenance, additional actions or system upgrades depending on their situation and playstyle.

Risk vs Reward Routes

Route choice created a strategic layer: safer routes could be shorter and less valuable, while more challenging routes rewarded better preparation and stronger train systems.

Design Process

From core loop to playable system.

My process started from the core loop and the dependencies between systems. After defining the player loop, I mapped how resources affected each other and how train failures could change the player’s situation. For example, a broken or open door could increase heat loss and create a stronger resource problem for the player.

For UI/UX and visual direction, I worked from reference boards, reduced the scope step by step, prototyped systems and shaped the final in-world presentation around readability. The goal was not to add more mechanics, but to make the existing pressure loop understandable and playable.

Process reference boardUI/UX studies, reference boards and prototyping iterations.Process reference board

Scope Control

Limit systems to protect the finished demo.

To keep the demo focused, we limited the number of available route types, obstacles and train upgrades. Customization options and additional quality-of-life features were left outside the demo scope so the me and the team could focus on the cleanest version of the intended gameplay experience.

This helped the project stay centered on a finished playable demo instead of expanding into systems the small team could not complete in time.

Scope diagramSystem map showing what was included vs deferred.Scope diagram

Playtesting & Iteration

Test early, learn from real players.

A major goal was to reach a playable build early enough to test the real player experience. I prepared builds, organized playtests, checked how players reacted to the pressure points and documented what needed to change for the next iteration.

The most important validation was whether players engaged with the intended decisions: prioritizing problems, reacting to resource changes, understanding train systems and making route-related choices.

Playtest session notesPlaytest feedback, behavior observations and iteration changes.Playtest session notes

Technical Challenge

Optimization became the main production blocker.

The scene cost was blocking progress, so the movement architecture had to change.

Problem

The original setup kept the train and player static while the world simulated movement, making the scene heavy, difficult to scale and risky for a small-team demo.

Decision

The movement approach was reworked so the team could stop fighting the same performance blocker and focus on finishing the playable experience.

Result

The main bottleneck was removed, making the demo stable enough to finish, test and present publicly.

Optimization before-after diagramOld architecture, problem, solution and result.Optimization before-after diagram

Project takeaways

Project Takeaways

What the project demonstrates through the work itself.

Game Design

I designed the core loop, player progression, resource pressure, tutorial flow, UI/UX and interaction logic for a compact playable demo.

Technical Design / UE5

I assembled the environment in UE5, worked with materials, lighting, visual feedback, Niagara VFX, optimization and final demo presentation.

Production Ownership

I planned tasks, wrote tickets and documentation, checked mechanics, prepared builds, organized playtests and helped bring the demo to Steam-facing quality.

Collaboration

The project had a clear role split: programming support handled complex train systems and world reactions, music was created by the composer, while I coordinated feedback, revisions and final integration.

Next step

Want the full breakdown?

If your team needs someone who can connect design goals, technical constraints and in-engine execution, I can bring this experience into your project and help turn complex production tasks into structured, playable results.

Contact Me! Back to projects Open gallery