FM - Log 3
March 22nd, 2025
My god - it’s already March? What happened to January? What happened to 2024?
Anyway. Welcome back. Or just welcome if you're a first time reader.
Normally I’d say, “Hey, read the previous dev logs first.” But this time? Not necessary. I started over. Clean slate. New engine, new systems, same vision - rebuilt from the ground up.
Still, if you're curious about the journey so far, here’s the backlog:
FM - Log 0 FM - Log 1 FM - Log 2
Wait, you started over?
Yes.
Long story short: Unreal Engine started getting in the way more than it was helping. I hit a few walls. Not catastrophic, but annoying enough that I knew I wouldn’t be dealing with them in another engine. So I made the call to jump ship.
Just to recap, this was the final Unreal prototype. It had two major strengths:
First, it felt great. Movement and attacks were punchy, responsive, and satisfying. Even dying looked cool, which is good because you'll be doing a lot of that in this game. Despite the placeholder graphics, it nailed the vibe I was going for.
Second, it clearly communicated the core gameplay loop: quick, brutal action with tight checkpoints and zero downtime on death. Think Hotline Miami, but angrier. And slightly weirder.
So, what went wrong?
At some point, I realized that continuing development in Unreal Engine would have led to an inferior product in the end.
UE is an awesome engine. It has some extremely powerful and in-depth tools. But that’s also its biggest downfall - it’s too big. This engine is made for teams of specialists, not solo devs. It’s easier to be a specialist in UE, but way harder to be a generalist - and for a solo project like FM, I have no choice but to be a generalist.
Unreal wants to do things its way. In the game dev community, I’ve heard the term “unrealisms” tossed around. There’s a reason for them. Unreal mirrors decades of AAA development conventions, which means you’re far less likely to make rookie engineering mistakes, because the engine literally won’t let you. It enforces structure. Which is great - unless you need to move fast, prototype dirty, and change your mind without first filing paperwork in triplicate.
By contrast, engines like Unity and Godot let you bend the rules. They won’t stop you from writing jank, but that’s the tradeoff: flexibility for guardrails. Unity’s simplicity becomes a blessing when you’re juggling systems, wearing five hats, and duct-taping a game together with caffeine and ambition. You can live inside C# and avoid half of Unity’s nonsense. Unreal? Unreal hands you a toolkit the size of a refrigerator and asks you to build a birdhouse.
The final straw came when I was designing the intro level - the one where the player is supposed to control four main characters in sequence. I realized there wasn’t a clean way to change the player pawn at runtime.
That was it. That one tiny roadblock was the tipping point. Despite everything I had built with the Unreal prototype - all the momentum, all the systems - I decided to cut my losses and start over.
In retrospect, that issue wasn’t even unsolvable. I could’ve written a unified fifth controller and hot-swapped between the characters with a function call. Hell, that’s exactly what I ended up doing anyway in the new engine. But by the time I realized that, it didn’t matter.
Because it wasn’t just about the pawn. Or Unreal as a whole. It was about momentum. And I was losing it.
So I started over - not out of failure, but because I wanted to make something that could actually be finished. Preferably without needing a GDC badge, a AAA-sized dev team, and an emotional support dog.
Really? You restarted over that one issue?
Not exactly. The pawn thing was just the first crack. What really broke me was the dialogue system.
If you read one of the older dev logs, you might remember I had plans to implement a proper dialogue system. Not optional - mandatory. So I dug through my Unreal Marketplace purchases and found one I already owned: the Defender Dialogue System. Perfect, I thought. Let’s save some time.
I imported it, cracked open the blueprints… and immediately regretted every decision that brought me to that moment.
It wasn’t unusable, per se - just bloated, convoluted, and packed with features I didn’t want or need. I figured I could trim it down, customize the parts I cared about, and ditch the rest. But the more I poked at it, the more I realized: trying to retrofit this into something usable was going to be more painful than just building my own from scratch.
And then there was UMG - Unreal’s UI system. Incredibly powerful. Also incredibly overbearing. Every minor change felt like filling out tax forms with a soldering iron. It’s great if you're working on a ten-year-old legacy system with strict naming conventions. Not so much if you're just trying to display a line of dialogue without wanting to scream.
At that point, my Unreal project had turned into a perfect storm: overengineered third-party systems, a UI toolkit trying to LARP as enterprise software, and a growing sense that I was fighting the engine instead of building a game.
So no - it wasn’t just the pawn.
It was everything.
And the second I started seriously considering writing my own dialogue system inside of Unreal - that’s when I knew. It was time to leave.
The Engine Switch
So at this point, I knew that to make FM a reality, I would need to switch to a different engine. I'm glad I made that choice before I got too deep into development. So instinctively, I have set my sights back on Unity.
But What About Godot?
To answer the question before it gets asked: yes, I considered Godot. In fact, I even tried it. Read up on the documentation and gave it a genuine shot during a week-long game jam earlier this month. I figured hey, Unity’s had its PR disasters, Unreal’s too bloated for solo development, and Godot is the open-source underdog everyone’s raving about. Let’s try it.
Spoiler: I hated it.
It didn’t start that way. The engine's vibe was cool. The documentation was decent. The “new engine smell” was refreshing. But once I started working with it seriously - like, building actual systems - the cracks began to show. And not little ones.
Godot’s 3D tooling is, generously, mid. The moment I knew I was done was when I tried selecting an object in the 3D viewport and just… couldn’t. It was selecting everything BUT the object I was actively clicking on. I recorded the whole thing too so you can witness the pain for yourself.
Now let’s talk code. I like GDScript - as a Python enjoyer, no complaints there. Godot technically supports C#, too. But the implementation is janky, the tooling is undercooked, and if you’re working with another dev who prefers to use C# (like mine did), good luck. The languages don’t play nice together, which forced me to either write singleton glue code in GDScript or wrestle with Godot’s fragile C# layer. Neither was viable.
On top of that, the values set in the inspector weren’t syncing properly through Git. So every time my teammate pushed new systems that relied on inspector-assigned values, I’d pull broken code with no idea what was missing. At first, I just thought he kept pushing half-finished commits - turns out, Godot was just eating our pipeline alive. That’s not a minor annoyance. That’s a full-stop red flag for any kind of team production.
At some point I realized: I’m not making a toy. I’m not making a short story about a little blob who finds himself. I’m making FM. That means systems, pipelines, data structures, complexity. And Godot just wasn’t built for that yet. Not in 3D. Not for a game of this scope.
So I walked away.
Let’s wrap this up with a little dating metaphor, because why not:
Godot: The artsy indie fling who had a lot of personality but couldn’t handle commitment. Quirky, fun, but ultimately unreliable.
Unreal: The rich, high-maintenance one. Great for flashy dates (AAA projects), but way too much for everyday life.
Custom Engines: The toxic DIY relationship where you think, “I can fix them,” but really, you just end up exhausted.
Unity: The one who’s been holding you down all along, despite their flaws. You just needed to see the world to realize it.
So here I am. Back in Unity. A little bruised, but wiser. And honestly? It’s been good. Real good.
Funny thing - the very first FM prototype was actually made in Unity, way back when the idea first struck. I didn’t know much, but I was figuring it out. After detouring through Unreal, spiraling, rebuilding, and unlearning bad habits, I’ve basically circled right back to where I started.
Only now? I know what I’m doing.
The Basics
After dropping Unreal, I fired up Unity, made a fresh project, and started rebuilding FM from scratch.
It felt like walking back into an old apartment - familiar, slightly cramped, but at least the sink worked. The tools made sense. The pipeline was predictable. And more importantly, I was building again.
The core gameplay loop from the Unreal prototype is still intact: kill shit, move forward, kill more shit. The blood mechanic - the one that gives you a chance to survive a fatal hit - also made it over, though it’s been tweaked for this version.
Rewriting everything wasn’t fun, but I hit flow faster than expected. Within days, I had characters moving, enemies dying, and blood splashing exactly where it needed to.
The Fortunate Four
All four main characters made the jump into the Unity prototype. Their movement styles, attack behaviors, and gameplay quirks have been faithfully recreated - not pixel-perfect, but close enough to hit the same feel.
This time, though, you can actually swap between them at runtime. Character switching is now a core mechanic - both player-controlled and level-triggered. Swaps happen at specific checkpoints, and I also built a debug-friendly hot-swap system for testing purposes.
This is what finally unlocked the MVP - the ability to play as all four characters, in sequence, across one continuous level. That’s the spine of FM, and now it’s real.
On top of that, I’ve begun blocking out the new character models. These are early sculpts based on concept art by Janelle Knight, and they’ll evolve as the art direction gets locked in.
Right now, the models are functional, readable, and expressive enough to support the top-down gameplay. They’re still rough blockouts, but already capturing the spirit of the characters. I’m building them myself for one simple reason: these aren’t generic protagonists - they’re my characters. They need to look and feel like they belong in this world, because they’re the heart of it.
The New Stuff
Let’s talk new features. This section covers everything that came out of the October development push - the first real content sprint since rebuilding FM in Unity.
Chunks n Checkpoints
To test the new systems, I roughed out a prototype level layout in Krita:
The goal wasn’t perfection - it was momentum. I didn’t overthink it. I just threw down some walls, checkpoint triggers, and enemy placements to start feeling out gameplay flow.
Black lines = walls
Yellow lines = checkpoints
Green lines = temporary barriers
Cyan lines = transitions between level chunks
Pink dots = enemy spawn points
Red dots = player spawn
This layout became the foundation for the intro level - a modular, checkpoint-driven structure that plays well with the character-switching system. It's all placeholder for now, but it works. And more importantly, it gets the game moving.
Enemy Varieties
The zombie from the Unreal prototype is back - but now he’s brought friends. All enemies are built using Playmaker’s finite state machines, which makes it easy to prototype and iterate. Though I’ll definitely move to behavior trees for boss fights and more complex encounters, but we’re not there yet.
Here’s who’s joined the roster:
Sprinter Zombies – Just like regular zombies, but fast. (innovation 🌈)
Shriekers – Harmless by themselves, but they scream to alert nearby enemies.
Sentient Rocks – Launch themselves at you if you get too close.
Unhinged Automatons – Big, heavy, and not easy to take down. They don't bleed either.
Abyssal Lurkers – Pop in and out of pools, whack-a-mole style, and shoot deadly lasers. Fun to design. Might cut them from the demo because they absolutely kill the pacing of the chunks they’re in.
Unity Update
I upgraded the project to Unity 6, from the 2022 LTS version I was using at the time. It wasn’t planned - more like a cascade of small headaches that made it the right move.
First, the Playmaker ecosystem browser (used to download community-made actions) just stopped working. No clue why. Tried debugging it, failed, gave up, started a new project. Fixed.
Second, Unity 6 introduced a sleek new behavior tree system that looked miles better than the one I was using before (Behavior Designer). Of course, the team behind it got laid off shortly after. So... great. Guess I'll be crawling back to BD pretty soon then.
Third, Unity completely walked back the infamous runtime fee from late 2023. You know - the one that set the whole internet on fire, made thousands of devs question their life choices, and torched a decade of goodwill in a single afternoon.
So I figured, screw it - might as well make the jump while morale’s high and the suits are still licking their wounds. Total PR faceplant. Completely avoidable. At least the CEO responsible got shown the door, and someone remembered where the undo button was.
Migrating the project wasn’t painless. I had to re-import everything, refactor some setup, and deal with a few hiccups. But once it was done, it felt like clearing a mental blockade. Progress picked up fast after that.
The Impact System
This system wasn’t planned - it just kind of happened. One minute I was fiddling with ragdolls, the next I was designing an entire physics-driven damage model. Game dev, baby!
At its core, the impact system does two things:
It adds directional force to enemies when they die, making ragdolls fly based on where and how you hit them. It makes kills feel good.
It adds a new layer of gameplay on top of raw hitpoints. Instead of just ticking down health bars, attacks are measured by how much impact they deal - and enemies have different impact thresholds.
Here’s how it works:
Below the damage threshold? The enemy shrugs it off.
Between damage and stagger? They flinch and take damage.
Between stagger and death? They get staggered - interrupting whatever they were doing.
Above the death threshold? Instant kill. Folded like lawn chairs.
This is why zombies go down in one satisfying hit, while that big unhinged automaton can tank a few hits before throwing in the towel. And since the thresholds can change at runtime, it opens up a lot of design possibilities - enemies with temporary super armor, boss phases with vulnerability windows, that sort of thing.
It’s one of those systems that started as “eh, let’s try this” and ended with “wait… this actually rules.”
In fact, it works so well that it’s no longer just an experiment - it’s foundational. This impact system is now the backbone of FM’s combat. Every swing, slam, and shot feeds into it. If you want to kill something in this game, you’re not just chipping away at health - you’re trying to break through.
Intermission
Before the second rush, I commissioned updated concept art for the main cast - drawn by Janelle Knight, who’s been helping shape some aspects of the visual identity of this project from early on. The new models you saw earlier? Built directly from her designs.
The brief was simple: take inspiration from a particular animated music video (which I won’t name yet - spoilers) and keep the forms clean, stylized, and readable from a top-down perspective. Something I could feasibly model myself without losing my mind, but still expressive enough to carry the game’s tone.
The results? Exactly what I needed.
But no full reveals just yet. This dev log’s all about systems. Art and narrative can have their own spotlight later - when the time is right.
During this time, I was busy moving to another house after receiving a sudden notice to vacate from my landlord due to “renovations.” Long story short: she was terrible, and I’m currently taking her to small claims court over a blatant security deposit violation.
Massachusetts doesn’t play around when it comes to tenant rights - and if all goes well, I’ll be walking away with around $2,000.
That money? It’s going straight into FM’s development. No outside backing, no donations - this project is 100% self-funded, and also, let’s be honest, a little vengeance-funded. Just me, my weekends, and (hopefully) a court ruling with my name on the check.
Trial’s in a couple weeks. Fingers crossed.
The Second Rush
After a month-long game jam in January that slowly drained my soul, we pulled the plug on day 27. No delivery, no glory - just burnout.
But near the end, something clicked. I kept thinking, “I could be working on FM right now.”
So when the jam ended, I did exactly that. Momentum hit hard, and suddenly I was back in the zone - not out of nowhere, but out of frustration. The good kind.
Refactors
I refactored a bunch of shit. There’s really not much to show off - it’s all behind-the-scenes stuff. But trust me, it was hard, it took a lot of time, and further development would’ve been impossible without it.
It’s kind of funny - some of the most tedious work, the kind that drains your time and energy the most, ends up being the least interesting to talk about. Nothing flashy, nothing visual. Just pure, thankless code wrangling. But hey, someone’s gotta do it.
Level Edits
Some chunks of the level just felt bad to play through - and I finally figured out why. It’s the camera.
Specifically, it’s the limited field of view when moving south. You can’t see what’s ahead, and that kills the flow. So I reworked the chunks that forced southward movement and redesigned them to push players north instead. North-facing chunks feel better, play better, and make more sense thematically. Moving south is only acceptable when there’s nothing trying to kill you.
From here on out, I’ll be designing levels that lean northeast as a general rule, with southwest routes kept to a minimum. That direction combo limits visibility and breaks narrative consistency - like, why are we suddenly backtracking southwest when the whole mission has been pushing forward?
Resource Systems
Each of the four characters comes with a unique resource system that reflects their personality and playstyle. These aren’t just flavor - they’re baked into the mechanics.
Pain
Pain is the only resource that rewards you for getting hit. It fills when you take non-lethal damage or dish out pain to the enemies that are capable of feeling it. You can spend it on abilities - but take a hit while above the lethal threshold (1.0), and you’re done. It caps at 1.25, so tread carefully.
Drive
Your classic energy bar. Spend it on abilities (defensive, for now), and if it hits zero, you’re locked out for a bit. The bar sits at 0% briefly before refilling quickly back to full. Use it wisely - or learn the hard way what running on empty feels like.
Rage
Rage is a rework of the old blood mechanic from the Unreal prototype - now tailored to a single character. It builds by killing enemies and passively gives you a chance to survive non-lethal attacks. 50% bar = 50% chance. Higher values decay faster, while lower values linger longer - meaning you might just scrape by with a sliver of rage and pure luck.
Stability
Stability fluctuates every second, gravitating toward 50%. If it ever hits 0% or 100%, the character - Ebo - dies. The eventual goal is to have the player manage this meter to avoid extremes, balancing chaos and control. Right now, though, it’s a prototype - unstable, just like him, and serves absolutely no purpose.
Behind all of this is a modular ability framework that ties each resource system into the rest of the game. It’s flexible, clean, and ready to plug into whatever mechanics come next. Massive thanks to Joel for the assist on getting it stood up.
No abilities are programmed yet - but the foundation is there. When they land, they’ll be tuned to hit hard and feed directly into how each character fights, survives, and expresses who they are.
Lethal Attacks
Some enemy attacks are marked lethal - and they mean it. These strikes ignore every defensive mechanic in the game. No blocking with Drive. No tanking with Pain. No lucky survivals with Rage. If it connects, you die. Period.
That’s the whole point. This system isn’t here to be cruel - it’s here to set boundaries. For example, the Pain character might thrive on taking calculated hits… but if he gets stabbed in the heart, that’s it. Doesn’t matter how much pain he can handle. A lethal hit is a lethal hit - end of story.
These attacks are rare, heavily telegraphed, and completely avoidable. But when they show up, they demand your respect.
Blood & Feel
I brought back the blood VFX from the Unreal prototype - but this time, it’s nastier, stickier, and way more satisfying.
The old system used flat planes hovering above the ground with alpha textures. It looked fine, but felt a little… stiff. In the Unity version, blood is handled via surface-aligned decals, which means it sticks to walls, smears on floors, and even slides down vertical surfaces over time. It’s subtle, but it makes everything feel more grounded - like the aftermath of a real, brutal fight.
On top of that, I integrated a third-party asset called Feel. It’s basically a cheat code for juice - adding screenshake, hitstop, and impact feedback without reinventing the wheel. I used it to make kills feel heavier, deaths feel cleaner, and every moment of violence snap with purpose.
It’s the kind of polish you don’t consciously notice - but you’d absolutely feel its absence.
Dialogue System
At first, I tried using a third-party tool literally called Dialogue System.
What drew me in? It was used in Disco Elysium, one of my all-time favorite games. So I figured, “If DE used it, how bad could it be?”
Well... turns out I’m not Disco enough.
The editor felt clunky and dated. It came with an absolute mountain of features I didn’t need - quest systems, variables, branching logic, UI frameworks, save/load integration, and probably a kitchen sink. And a grill. And a .json file full of misnamed “cork” objects. And a VR-ready espresso machine. And a lifetime membership to Costco (which, honestly, would’ve been more useful).
It’s that classic Unreal-feeling bloat: powerful, overbuilt, and trying to solve problems I don’t even have. I wanted a clean, lightweight system - not a goddamn Home Depot aisle.
So... dialogue?
With Dialogue System out of the picture, I picked up Text Animator. It made the text wobbly. That was enough.
Plus, it had a built-in typewriter effect - letters appear one by one. Very juicy. Very cool. But no actual dialogue backend.
I spent some more time browsing the asset store for the perfect dialogue system. At this point, I realized no premade solution was going to cut it. I was way too picky, and nothing out there matched the vibe I needed. So I did what any deranged solo dev would do: I had a Homelander moment.
THE DIALOGUE SYSTEM!!!
This beast honestly deserves a dev log of its own. But I’ll try to summarize without spiraling.
Chapter One: Initial Test
It all started with barks. I built a quick component that let NPCs occasionally spew random lines of dialogue, pre-written in the inspector.
The system had a few toggles: delay between lines, linger duration, loop mode (sequential or randomized). Nothing fancy - but it worked. It gave the world a pulse.
Chapter Two: Megalodon
Next came actual conversations. I upgraded the bark script to handle direct addresses to the player. Ambient chatter paused when the convo started, then picked up where it left off. Surprisingly elegant for what was still, deep down, a duct-tape system.
Eventually, I moved the dialogue data out of the component and into scriptable objects - DialogueData files that held all the juicy bits: lines, portraits, camera settings, audio clips. I thought I was being clever avoiding external data files. I was wrong. That experience humbled me. There's a reason everyone's using them.
But even with the new structure, I hit walls. I needed deeper control - precise camera transitions, timed events, multiple actors speaking at the same time or in sequence, including the player. I didn’t want some glorified floating letters. I wanted cutscenes. Cinematics. Real-time narrative beats.
At some point, the mega-script became a monster. It had to go.
Chapter Three: The Big Refactor of 2025
So I nuked the old system and rebuilt from scratch. Split everything into modular dialogue scripts - one for line progression, one for actor timing, one for camera control, and so on. Each script handles a clean, defined job. Now they’re flexible, readable, and easy to jam into any scene.
The result? A custom-built dialogue system that does exactly what I need - no bloated quest editors, no external graph spaghetti. Clean. Lightweight. Mine.
Actors now use a dedicated DialogueActor component that handles all the cutscene logic, powered by Animancer. That framework sidesteps most of the headache that comes with Unity’s built-in Mecanim system - smoother to work with, and frankly, just better for my brain.
The system’s still evolving, but even at this early stage, I can already tell it’s going to carry some serious narrative weight.
Also… somewhere along the way, I lost barks.
I should bring them back. :(
Five Big Booms
To stress test the new dialogue system, I built this scripted cutscene.
It’s got timing, camera work, multiple actors - and, well… five big booms.
Enjoy. (volume warning) 🔊
If this system can survive this, it can survive anything.
Wrap-Up
That’s everything for now.
Forgotten Memories is still deep in development, but the foundation is solid, the systems are clicking, and the vision is sharper than ever.
This project remains 100% self-funded (and maybe just a little vengeance-funded), developed solo on weekends with a healthy mix of grit, spite, and love.
If you made it this far - thanks for reading.
If you want to keep up with ongoing progress, the Trello board is always up to date with the latest features, fixes, and upcoming plans.
Unlike the first three dev logs, I won’t be providing public builds anymore. Playtesting will be handled internally moving forward.
More updates to come. Until then, back to the grind.
P.S.
✨ If You’re Not Crying in the Office Bathroom Over a Life-Changing Slack Message From Your Manager, Are You Even a Real Professional? ✨
3 PM. Tuesday. The glow of my monitor flickering against my caffeine-dead eyes. A Slack notification popped up.
“Hey, just wanted to say - great work lately. Really appreciate having you on the team.”
I broke down instantly.
Tears. Sink. Mirror. “They see me,” I whispered.
🔹 Validation? Unlocked.
🔹 Imposter syndrome? Briefly annihilated.
🔹 Peak corporate euphoria? Achieved.
By the time I returned to my desk, I had already written my two weeks' notice. I had peaked. It was time to vanish.
This is the shape of professionalism in 2025.
💼 “Work isn’t just about KPIs - it’s about feelings.”
💖 “Your career isn’t a ladder - it’s a mirror.”
🔥 “Burnout is temporary. LinkedIn clout is eternal.”
#CorporateGrowth #SlackTears #EmotionalROI #AgileCrying #FMDevlog3
灵可顶