Readable in seconds
A hyper-casual loop with no tutorial. Obstacles, coins, and power-ups have to communicate themselves before the player gets bored.
UNITY / 2D HYPER-CASUAL RUNNER
Charles
On Chain.
A 2D WebGL endless runner built at Mindravel Interactive. I worked on gameplay mechanics and the systems around them.
- Role
- Game Developer
- Studio
- Mindravel Interactive
- Platform
- WebGL
- Dates
- Dec 2022 – May 2023
My contribution
What I worked
What I worked
on.
I joined Mindravel as a Game Developer in December 2022. Charles On Chain was already in production, and I worked on the Unity side of the game.
My work covered gameplay mechanics and the systems around them: the runner loop, obstacle and collectible behaviour, power-ups, and enemy encounters.
The art and audio were team efforts; my work was on the Unity and gameplay side. The version on this page is the WebGL build that shipped.
Playable build
Play it here.
The original Unity WebGL build, running inside this page. It is about 50 MB, so it only loads when you ask it to, and then it is cached.
Runs in your browser. Nothing to install.
Loading… 0%
The build could not load.
The standalone version is still available: open it in a new tab.
Sent to the running build with
SendMessage()
Screenshots
From menu to mayhem.
A look at the game's menu flow, enemy mode, and obstacle encounters.
The project
What the game needed.
The constraints that shaped the work, not a feature list.
A small WebGL footprint
The build is about 50 MB. That is fine on a desktop connection and unforgiving on a weak laptop, so the page only loads it on request.
Several states, one build
Runner, enemy encounters, menus, and equipment screens share the same scene and UI. Keeping those transitions predictable mattered.
Content that can grow
Environments, collectibles, and costumes were built to be extended without rewriting the core loop.
Looking back
What I'd do
What I'd do
differently.
I have more distance from the project now than I did while building it. Three things I would change:
- Profile the WebGL build earlier. A 50 MB build is acceptable on desktop and painful on a low-memory laptop; I would measure memory before adding more content.
- Keep runner mode and enemy mode in separate state machines. It would have made the transitions easier to reason about and test.
- Write down the build steps. The Unity WebGL pipeline has enough moving parts that a short checklist saves time on every rebuild.
Contact
Building something like this?
I'm open to Unity roles and freelance work. Email is the fastest way to reach me, and the contact form on the homepage works too.