Overview
Everplast is a 2D pixel-art platformer I built solo in Godot 3 and shipped to Steam when I was 16. I wrote every system in the game over about eight months: the player state machine, the rank-based progression, five ranged weapons, a full tabbed inventory, three boss fights with custom AI, controller support, English and Spanish localization, and a five-slot save system that persists to JSON. I also handled the entire Steam publishing pipeline, from store page copywriting to build packaging to the Steamworks review process.
How It Started
Before Everplast there was a game called Fields of Elysium. I built it while first learning pixel art and Godot, and finishing it was genuinely a big deal for me because I had four or five abandoned projects sitting before. It proved I could actually complete something. It was also, honestly, not too fun to play.
The game was originally going to be called The Green Everplast, tied to a story I wrote in 5th grade.
I built off of this initial cloudy prototype into a fully playable game, and I eventually renamed it to Fields of Elysium. This screenshot shows the demo with health and coins as well as multiple levels and a final boss fight.
After beginning work of the new game,I went back to the original idea and shortened it to Everplast. That is where the name comes from, this screenshot showing the comparison with the final version of the game.
I did not touch game development for ten months after that. Then one day at school I was sitting in the back of my English Grade 11 class and I randomly decided to download the old project, and playing it gave me this massive wave of nostalgia. Something clicked that I still cannot fully explain. I pulled up Trello, started writing down world ideas and mechanics, and within a few days I was deep into the game again. I went from doing absolutely nothing for months to being unable to stop working on it.
"I have no idea how after 10 months of doing nothing I was all of a sudden able to open up the game engine and just start going at it."
The first thing I did was tear out the old UI and redesign everything: new menus, new background art, new layout. Once that felt right, the rest started flowing. I was checking off features on my Trello board faster than I expected, recording dev vlogs about the process, and sharing early builds with playtesters on Discord. For a while the momentum was incredible, and I was genuinely excited about what this game was becoming.
The Game
Movement and Worlds
I built the player character as a KinematicBody2D driven by a finite state machine with states for idle, walk, sprint, jump, fall, dash, wall slide, wall jump, and water movement. Getting the movement to feel right took a lot of iteration and fighting bugs. I filled the levels with drop-through platforms, spike hazards that deal variable damage, ice tiles that change your friction and acceleration, water zones with their own distinct physics, wind modifiers, and a checkpoint system.
I designed four worlds, each with its own tileset, music track, and environmental mechanics. Foggy Overlands is the introductory world with open layouts and basic enemies. Drowsy Lands introduces tighter platforming and new enemy types in a warm desert setting. Snow Fall adds ice physics and the adrenaline resource. I also built subsections within levels where the player teleports into interior areas (like the cave below) with completely different lighting through CanvasModulate, so a single level could have multiple distinct environments. "The End" is the single-level finale after the last boss encounter, giving the player the most overpowered weapon in the game.
Progression and Combat
One of the systems I am most proud of is the rank system. Players progress through four ranks (Silver, Gold, Diamond, Glitch), and each one gives the player new movement and combat abilities. Silver gives you double jump, wall slide, and wall jump. Gold unlocks the air dash and introduces adrenaline, a resource that regenerates over time and fuels the ice gun. You earn ranks by defeating three story bosses: Fernand, Ostrich, and Cora. I wrote each boss with its own state machine and distinct attack patterns. Fernand cycles through fly, chase, and shoot states, and during the final encounter he switches weapons contextually based on the player's position.
I built five equippable guns (water, nail, laser, snow, and ice), each consuming a different ammo type. The ice gun is the interesting one because it draws from the adrenaline pool instead of regular ammo, which creates a tension between using your resource for combat power or saving it for movement abilities. I also built an orb-based economy where players level up health and adrenaline stats at scaling costs, while coins fund shop purchases for powerups, weapons, and consumables. One of the consumables, the glitch orb, slows game time to 75%. On the enemy side, I used a modular component system with interchangeable AI behaviors (patrol, raycast-based chase, flying patrol, water movement, and different damage responses), which let me create variety without writing unique code for every enemy.
UI and Save System
The UI was a project within the project and I did not expect it to take as long as it did. The HUD alone tracks health, coins, orbs, an adrenaline bar, weapon ammo, gem collection slots, a powerup timer, and a low-health screen overlay. Beyond that I built a tabbed inventory system (powerups, collectables and equippables, rank descriptions, stat upgrades), an in-game shop, a dialogue system for NPC interactions, a full settings screen with audio sliders, graphic options, and control remapping, and gamepad support that works throughout all of it.
The save system writes five profiles to JSON, storing everything: stats, full inventory, equipped items, current rank, collected gems per level, and world progress. Saves trigger on checkpoints, level completion, deaths, and quitting. I organized the physics across nine collision layers (Ground, Static, Player, Entity, Liquid, Projectile, Enemy, Vase, Block) and set up a three-bus audio layout (Master, Music, Audio) with per-level and per-subsection music switching.
Scope and Shipping
I originally planned six worlds. Midway through development I cut two of them because I could feel the scope starting to bury me. By the time I finished World 3, I was working on Everplast every single day and the motivation was completely gone.
So I made a decision that ended up shaping how I think about every project since. I cut the remaining content, built one final world to close out the story, and started preparing for release.
"I'm basically gonna give up on the game but I'm also going to finish it."
Shipping meant creating the Steam store page, packaging builds through Steamworks, writing the store description, recording screenshots and trailer footage, and dealing with the review process. Because I was underage at the time, I had my mother set up the Steamworks account for me. The game went live on February 24, 2022. I had felt relieved, I finally finished and published my first game.
Challenges
Inheriting My Own Rough Code
The hardest part of the project was not building new features. It was going back into the Fields of Elysium codebase and trying to understand what I had written months earlier. I did not comment my code, I did not name things clearly, and I did not organize files in a way that made any sense looking back. A lot of what I tried to build on top of the old code came out buggy, and I ended up rewriting entire systems from scratch because it was faster than trying to extend code I could not follow. However, the code problem is still true to this day. Many segments of the code are still hacky or unreadable.
The Settings Menu
The settings menu is the best example of what went wrong architecturally and pure overengineering. It grew to over 1,100 lines because it was actually six completely different systems crammed into one file: a UI menu, an input handler, a save system, a graphics settings manager, an audio mixer, and a focus navigation state machine. I did not realize how bad it was until I went back to add a feature and had to trace through the entire file to understand the control flow. Every percent the player dragged a volume slider, it wrote to disk. The fullscreen toggle called save_settings twice. All of this shipped to production and it all worked, but looking at it now is pretty painful.
The UI Gets Worse: The Global Signal Bus
All of the menus were connected through a global signal bus where every UI button in the game emitted a global signal. If I wanted to add a new menu, I had to go to the central file and register more signals. The naming was unclear enough that emitting the wrong signal could wipe a player's save data, and it was not obvious from reading the code that this was even possible. This is an architecture that seems to work, but it caused rare situations where the menu soft-locked the game.
What I Learned
Everplast made me more careful about two things: scope and code quality.
I used to design games based on what I wanted the final product to be. This project taught me to design around the skills I actually have and the time I can realistically commit. Cutting from six worlds to four was not a failure. It was the reason the game shipped at all. I think about that every time I start a new project now.
The code quality lesson cost me weeks of debugging that could have been avoided. I did not comment my work, I did not separate concerns, and I paid for it every time I had to revisit an old system. The settings menu alone probably set me back days. Every project I have built since has been better organized specifically because of the time I wasted trying to read my own code and failing.
On a more personal level, Everplast was the first time I made something and put it in front of people who did not know me. I recorded dev vlogs, shared builds with strangers on Discord, created a real Steam store page, and published a product that anyone could buy. That full loop, from an idea to a public release, is the experience that changed how I approach building things. I know what it takes to ship now, and I also know what it feels like to almost not finish.