It’s been almost a year since I last touched Project FM, aka Entropy FM, aka Forgotten Memories. For all intents and purposes, the project is dead and buried.
All of the previous FM dev logs have been tucked away in their own little folder on my blog. This is now the one-and-only source of truth. In here, I will summarize the entire trajectory of the project, some things I did well, things I learned, and things I will avoid doing in the future. That is, if I ever again decide to solo-dev a project that clearly required a studio budget and a full team.
History of the Project
This whole mess started off with an idea, as all overly-ambitious nightmares do. A comp, an engine, and a dream.
The game concept was born from me no-lifing The Binding of Isaac back in college. I had an incredible time with the Forgotten character. I loved how the attacking and movement mechanics felt compared to the other characters, which were all ranged.
Then, as a game development student, I had a thought. “I should make a game inspired by this attack mechanic. I’ll give it a story, interesting mechanics, and a unique art style.”
I started brainstorming. Threw most of these thoughts away and ended up with something quite coherent. In my head, it turned out to be this mix of the linear, fast-paced levels of Hotline Miami, inspired by the controls scheme of the Forgotten from TBoI, and a bloody, irreverent vibe that you often see from the games of Devolver Digital.
Honestly, if I had written a design doc or a pitch deck for this project — I may have just made it happen. But this isn’t a story about turning ideas into real projects. This is a story about the hubris of a solo developer with zero experience delivering games larger than two-week long game jams.
Engine Changes
The #1 most catastrophic thing for this project had been numerous engine changes. I would even put this issue above over-scoping in severity.
This project had undergone three engine changes in total.
Three.
The original prototype was made in Unity, the engine I had been using for years by the point I took on the project.
Then I decided that “Unity sucks actually. I’m going to switch to Unreal.” This shift happened even before Unity had announced their disastrous policy in late 2023, where they were going to charge developers a fee every time a game using the Unity Runtime was downloaded and installed. If you’re in the know — you know. If you’re not, I don’t think I need to explain why this policy was inevitably walked back.
I switched to Unreal Engine because that’s what the big studios seemed to favor these days. That’s it. Oh, and I enjoyed the blueprints workflow, and I also thought it looked better out of the box. I also enjoyed the shader/material nodes.
But the more I used UE, the more I wanted to run back into Unity’s warm arms. I developed a handful of gripes with this engine. It was simply too big for a solo developer. It packs some exceptionally powerful tools, sure. But there are entire departments in triple A studios which specialize in using UE’s tools specifically, rather than the engine itself. How do you handle entire departments’ workloads as a single person without vibing it out? I am sure there are now plenty of AI assistance tools that help with banging out these .uasset files, but I dropped the engine long before they came along.
So yes, I crawled back to Unity. Fired up a fresh project on version 6, imported whatever assets I had from the first prototype, installed Playmaker, and began chipping away at it. I worked on the project almost daily, after work hours. Social life be damned!
Months had passed of working on the new Unity project. I had to downgrade the version back to 2022 because something was broken. But you can’t just downgrade a Unity project. I had to fire up another fresh Unity project and re-import everything. That’s how I lost a full day of development.
More days’ worth of lost time to come. And trust me — they add up faster than you think.
Some days, I had to wrangle a third party asset that refused to behave. Other days, I had to rewrite old spaghetti code because I got a clearer picture of the project’s needs. Eventually, I even decided to rip out Playmaker entirely, as I felt like I had outgrown it.
The act of removing Playmaker alone was likely responsible for at least a week’s worth of lost time. Maybe more. Likely more.
As the project grew in complexity, I began strongly relying on vibe coding, even for features that I knew I could code by hand, as I’d done before. The main offender for this was the state machines for the player characters.
Finally, after getting frustrated with Bakery, yet another third party asset that refused to obey me, I threw a wrench into the whole system and switched to Godot.
And that’s where everything finally fell apart.
Godot
This pivot may be surprising to some of those who have followed the previous dev logs. In Log #3, I dragged Godot through the mud after my friend and I failed to deliver a game jam with it.
Honestly, it’s fine if you don’t use the C# version. Nowadays, I even prefer it to Unity for prototyping and solo projects. GDScript feels good to write, it has the best support for .glb files I have ever seen in a game engine, and it lacks the tech debt of Unity and the feature bloat of Unreal Engine. It’s quite alright these days, although not without its quirks. But at least with Godot, you know they won’t be pulling any pricing shenanigans out of the blue.
I also got fed up with Windows and wanted to try daily driving Linux. If there is one thing you find out pretty quickly if you install Linux with an Nvidia card — their drivers don’t play nice. Furthermore, they become outright mean when you try to run 3D applications that were not natively intended to be run on Linux. Unity was giving me bizarre graphical glitches and the viewport ran sluggishly. I also couldn’t just download Unreal Engine; I had to compile it from scratch.
Fuck all that.
Godot gets built natively for Linux, and runs natively on Linux, with no issues. So if you’re using Linux and you want to develop games on Linux — Godot becomes a no-brainer. At least for a GUI game engine. I was not about to learn a GUI-less framework or, God forbid, C++, just to fuel my delusions about being the next Toby Fox.
Though Toby Fox uses GameMaker. A 2D engine. I make 3D games. So really, we were operating in different dimensions entirely.
But moving from Unity to Godot wasn’t just a version port. It demanded an entire rewrite of every mechanic. To put things into perspective, I had a fully playable, but ugly, vertical slice of the demo level in Unity.
Art assets are easy to port, which was great, except I hadn’t made any. That meant 90% of my project was raw code that needed a complete rewrite from scratch, and the remaining 10% was just placeholder geometry and proxy models for character rigs.
“There is no way I am going to write all of this code from scratch again,” I thought to myself.
I didn’t have to. Not at the dawn of the new age of AI-assisted coding tools.
Just Vibes
Let’s be real — any idiot with a $20 AI subscription can build an app now. Does it run? Sure. Is it absolute dogshit under the hood? Almost guaranteed.
The Godot version of Project FM was absolute dogshit.
This is the Faustian Bargain you run every time you heavily rely on AI tools for coding projects. Yes, AI lets you prototype exceptionally quickly. Yes, AI can majorly speed up your workflow. Yes, AI can guide you towards disastrous architectural decisions. Yes, AI can generate thousands of lines of code instantly, and now you don’t understand what most of them do.
Because you didn’t fucking write them.
Yes, AI can validate your worst impulses. Yes, AI will tell you that creating three polymorphic finite state machines that all have to talk to each other is a wonderful idea, actually, and will gladly help you bruteforce that shit. It will also tell you to rewrite the codebase to better integrate multiplayer, you know, just in case you want multiplayer.
“You’re absolutely right! This project clearly needs another singleton!”
Heavily relying on AI tools made me forget how to code. It turned me into a buffoon who drools on his keyboard while staring at an empty text file. Which is strange considering I knew how to code way before AI became a widespread thing. These days, coding by hand feels like learning how to walk again, an activity that used to feel so natural, until the speeding car named Anthropic shattered my spine and left me paralyzed neck down.
Over time, my development sessions turned from solving coding problems to yelling the most abhorrent profanities at Claude Code as it insists that it had “identified the smoking gun” for the sixth fucking time, only to break the project even harder. I swear, I did not talk like that before this brutal gaslighting! Just reminiscing about these days makes my blood pressure spike all over again.
My reasoning was innocent at first. Since I already had a fully working vertical slice in Unity, I could use AI to port the Unity-style C# code into Godot-style GDScript code. The process was simple — feed the old scripts into your favorite LLM, engineer the prompt, and test the new code inside of the new engine.
But Godot does certain things differently. So differently, in fact, that 1:1 translations were impossible. The input system was different, physics, rendering, lighting, groups/layers—hell, even the event/signal system was different. They have different paradigms. Working with Godot required a Godot way of thinking, which I had not developed yet. It was like putting lipstick on a pig and calling it Princess Peach.
In a few weeks, I successfully brute-forced all of Unity’s core mechanics inside of Godot. It felt like a strange, twisted sense of progress. But honestly, calling this progress was a perversion of the word.
Lost time. That’s all it was.
Even the dialogue system from Log #3, the thing I proudly showed off, never got ported. The cutscene system I didn’t even attempt — it felt so daunting that I gave up and never opened the project again.
I left Project FM to rot. Indefinitely.
What Went Well
Despite the chaos, I pulled off some things that I previously thought to be impossible for me.
Player Characters
I’m proud of the work I’ve done for the four playable characters. If there is any work I can salvage from this disasterpiece, it’s them. I would just need to take some time to finish their models as they are currently proxies, and refine some animations. Each of them can stand on their own as individual portfolio pieces. Maybe I will write a detailed breakdown of them another time.
Mechanically and visually, they are all very distinct and they all feel great to play, in their own unique ways. They received the most development time, by far, at the cost of everything else. So it’s no wonder they turned out pretty great.
The Demo Level
I know I just spent 2000 words trashing this project, but in the loosest sense of the word, I achieved what I set out to do. I made a fully closed, fully playable, fully functional, demo level. I will put a link at the bottom of this article if you’d like to check it out. I exported it from the second Unity iteration; the Godot version never graduated from the “hot mess” phase.
The optimistic outlook is that if I scope my next project more appropriately — I have proven to myself that I can deliver an MVP in a reasonable amount of time.
Dialogue & Cutscene Systems
My golden goose. Geese? I made two systems, but they were interconnected. Dialogue drove cutscenes, and cutscenes drove dialogue.
These systems were born out of sheer necessity. They were what actually caused me to commit the second engine switch from Unreal to Unity. In search of a pre-made dialogue solution from the UE marketplace, I couldn’t find a solution that satisfied me. I could have made my own, but I didn’t feel like wrestling with its UMG and Blueprints systems, so I swapped back to Unity.
This system allowed me to let characters talk, execute events during cutscenes (walking, animations, spawning objects — anything I need to happen for storytelling purposes) while blending all of this seamlessly into gameplay.
I go deeper on how this actually works in Log #3, so I won’t rehash it here. It has pictures!
Huge Programming Level-Up
I have leveled up a lot as a programmer in general.
I already knew how to script gameplay logic. That part has been familiar to me for at least half a decade. But it has always been in the context of game jams or projects where I played a smaller role than… well, doing absolutely everything. It’s one thing to calculate the jump trajectory of a cube so it lands on another platform. It’s a whole other level to be able to hold the entire architecture of a game project in your head and seamlessly navigate it.
This experience has given me a new appreciation for technical design as a specialty. It’s impressive to make complex and robust systems, but I found it more fun to make multiple, simpler systems that all talk to each other.
Unfinished Things
Less of a “thing that went well” and more of an insight that I will forever carry forward. The win here was avoiding the sunk cost trap.
While I was mingling in the Boston/Eastern Massachusetts game development scene, I noticed an infuriating trend. A lot of people and groups have projects that have been in development for years, and haven’t been making any headway in many months. For some of them, I would say even years. Years of showing their projects at various showcases, parading around what’s essentially vaporware.
I’m convinced that most of these people will never finish these projects, nor will they ever shelve them. Because it feels so good to have a thing that you are working on, that you can talk about at social events. “What are you working on?” is a pretty standard opener, so imagine not being able to answer that question with a rehearsed elevator pitch when everyone around you has their own.
This is the real Catch-22. If you don’t have a thing — you got nothing to talk about. You’re immediately less interesting than the people who do have a thing. But once you decide that your thing is hereby finished, then you no longer have a thing you’re working on.
Finishing things is a bad idea. It hurts your social standing. Finishing is scary. Not only does it create a certain void that a lack of having a thing creates, but once your thing is out there in all its finalized glory, it is wide open to scrutiny. You can no longer hide behind excuses like “oh, this is still in early access” or “this feature still needs more polish” or “this is actually supposed to be a blablabla.” And that’s even more terrifying than not having a thing.
I don’t like that. I’d rather put the thing out of its misery once it sprouts tumors. I can always create another one. I did the same thing anyway, telling people that “I am working on a TBoI/Hotline Miami inspired hack n’ slash game” despite not changing a single line of code in months. So I mentally killed the project. I lost my dear thing, and I got depressed. So I’m not saying that having a thing is bad. It’s just that for some people, their thing is all they have going for them, and it’s tragic to realize that it’s going nowhere.
What I’d Do Differently
Here are things I would do differently if I decide to tackle another major game project.
NO MORE ENGINE HOPPING!
Godot is pretty good. If you’re daily driving Linux, I don’t see any reason to use anything else as a solo developer. But if you plan on working in a larger studio, then by all means — learn Unreal Engine. Unity is quite alright too, and it is still the best choice if you plan on being a mobile game dev. If you want to get stuck in hell, make your own engine. This is something I have attempted amidst all of this, by the way. Made a primitive little game engine with the Odin language and SDL. I learned a lot, but I won’t be shipping anything with it anytime soon. Though I have flirted with the idea of making a custom engine just for Project FM… just a glimpse of how dark and twisted my mind had gotten in the trenches of solo indie dev.
(Yes, I know I said there were three engine changes. This one doesn’t count, I never committed. Just harmless flirting.)
As of this moment, I would consider myself a hobbyist, even if it means conceding that I earned a bachelor’s degree in a hobby. My next major game projects, if there will be another one at all, will be made in Godot. Simply because I can’t stand Windows. It started off as ideological, but it’s not anymore. For some reason it keeps crashing during long sessions and overheating my laptop.
…scope?
The original idea was overscoped. Scope, scope, scope. Scope was a word drilled into me by one of my mentors over at MassDigi, like a drill sergeant. We made mobile games. Scope is important, maggot! If you think you’re operating within an accessible scope, you’re probably not. Scope lower. Scope. Then scope even lower than that. Scope. Repeat the process 3 times until your scope is a tiny speck of what you really wanted it to be, deep inside. Scope. If you’re a solo dev, you need to scope even lower than that.
There’s nothing more I can say on this topic. Scope. It’s a belabored talking point. Next.
Vibe Shift
I find that vibe coding works pretty well for simple tools and scripts that I only intend to run once, or snippets of code that work in isolation and aren’t a part of an interconnected network of objects that need to communicate with each other. I believe that vibing things out still has its place. LLMs aren’t going anywhere. But I will never let a clanker drive my architectural decisions again.
A few months ago, a tech bro told me, with a straight face, that “actually, AI has gotten really good, and you should learn to trust it with architectural decisions.” He said that to me, after everything I’d put myself through.
I asked him what his thing was. He was vibecoding a SaaS mobile app and trying to charge users $200 a year to use it.
The app was about fasting. You know — not eating, for a bit, on purpose.
He was a fucking moron.
The Stains of Time
Time is a finite resource. The older I get and the more life experience I acquire, the more I respect this fact.
Lost time didn’t just hinder this project. It buried it alive. Code rewrites are often necessary. Tech debt accumulates. If not taken care of, the codebase can become unwieldy even for the costliest of LLMs. This project went far beyond necessary refactoring. I spent many days porting engines, adding unnecessary third party assets and ripping out the old ones I’d outgrown.
If this was a project for a client with a strict deadline, I would have shipped some things dirty. Sometimes dirty code is the tax you pay to actually ship; ideological purity is a luxury not everyone can afford. “But my codebase is clean!” But did you ship? I’ve maintained this discipline during game jams because there’s always a strict deadline involved. Because I treated this as a personal playground, I assumed that I had infinite time. This mindset is fine for learning, not fine for shipping. The constant retreading was a death by a thousand cuts.
Over-conceptualization
Sometimes you get so enamored with an idea that you lose track of what’s actually in front of you.
I find that a lot of creatives in various disciplines fall into this trap. If you’ve read the previous logs, you may remember that in Log #0, I had a personal wiki for the project. It was full of storytelling ideas, worldbuilding details, and character backstories. None of them saw the light of day because the project they were supposed to be a part of didn’t get finished.
Code is simple. It either works or it doesn’t, it either performs well or it doesn’t. But games aren’t just products of code. Sure, games need to run well, as they are some of the most performance constrained applications out there. But they also require a pretty serious investment of art and design. Good taste doesn’t necessarily mean good execution. There are stories I wanted to tell with this game, but they’re going to have to take a backseat for now as I figure out another medium.
Showing off your work and collecting feedback helps, even if it’s still in progress. I get it — plenty of creatives (myself included) would rather sit on something unfinished than let it be seen half-baked. Nevertheless, I conducted multiple playtests for both the Unreal and Unity prototypes at major development milestones. The players only saw the surface-level things: enemies, character controllers, some cutscenes. Can’t blame them; that’s all it really was. The significance of these things may have been inflated by the things that were in my head or in that personal wiki, and weren’t on the screen yet. For my next projects, I would want to strongly focus on narrowing the gap between what the audience sees, and what I am actually trying to say with my work.
Conclusion
In conclusion, I would just like to say that game development is a horrible pastime and a highly volatile career path. Approach with caution.
I started this project with a thesis — I CAN finish a game solo. But this time, it was a failure. It’s a lonely, arduous road. Some people can do it. But personally, I get bored if I don’t have another programmer or artist to yell at, or anyone I can bounce ideas off. The moment I lost interest in game dev was the moment I tried to vibe code a game jam game, all on my own. This isn’t referring to Project FM; this was an entirely separate game jam I attempted in the spur of a moment. Yelling at LLMs just isn’t fun. With a fellow human, you can at least banter about discombobulating physics and Blender-to-Unity mesh scale mismatches. ChatGPT or Claude, on the other hand, prefer to apologize profusely and break things even more.
I’m not sure at this point if I still like game dev, or if I’ve grown to despise it. I’m hoping that a fresh project with zero baggage would help me decide. Project FM was initially conceptualized 5 years ago. That’s half a decade. That’s actually an absurd amount of time to be sitting with a project that has not gone anywhere. Maybe it’s a sign that it was never meant to be.
All in all, It was all worth it. I would not do it again.
I will post the latest build once I find a good one. The good ones are out of date and the latest ones are broken. I think I was in the middle of wrestling with some breaking changes when I made them.