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 on my hard drive before that. It proved I could actually complete something. It was also, honestly, really boring to play.
I did not touch game development for ten months after that. Then one day at school 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 engine again, working every night. I went from doing absolutely nothing for almost a year to being unable to stop.
"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. The game renders pixel art on an 8x8 grid at 1600x900, and 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. The End is the single-level finale with the last boss encounter. 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.
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 gates real ability unlocks. 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. I did not want to abandon the project after putting months into it, but I also could not keep going at that pace. I was exhausted.
So I made a decision that ended up shaping how I think about every project since: I gave up on the game by finishing it. I cut the remaining content, built one final world to close out the story, and started preparing for release. A released game with four worlds is worth more than an unreleased game with six, and I genuinely believe more solo developers need to hear that. It is okay to cut content. It is better to ship.
"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. I was underage at the time and had to have my mother set up the Steamworks account for me. The game went live on February 24, 2022 at $6.99. I remember that feeling clearly. I was making videos about it, sharing it publicly, and for the first time in my life I had a real product that strangers could buy and play. That changed how I saw myself as a developer.
Challenges
Inheriting My Own Bad 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.
The Settings Menu
The settings menu is the best example of what went wrong architecturally. 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 time the player dragged a volume slider, it called apply_settings, which called save_settings, which meant the game was writing to disk on every single tick of the slider. The fullscreen toggle called save_settings twice. All of this shipped to production and it all worked, but looking at it now is painful.
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. That is the kind of architecture that works until it does not, and I got lucky that it never caused a real problem for players.
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.