VK Sandbox Blog

Dota 2 - A Veteran's Review

Fri, 15 May 2026 00:00:00 GMT

Dota 2 is an absolutely atrocious game. And I'm not just saying that because of the toxic community full of smurfs, account buyers, script kiddies, and absolute lowlife bottom-of-the-barrel degenerates of society. Or the time investment required to get good at it, with its massive roster of heroes, items, byzantine mechanics, absurd match length paired with the fact that there is no way to surrender (unless you're a 5 man stack). Things most people complain about.

The entire game's balancing is a house of cards that's built on the shaky foundation of an RTS engine from the year 2002. But these engine quirks have become inextricably linked with the carefully tuned balance of this game. Remove them - and you break entire categories of heroes and items. In this review, I will outline them and explain why they are calcified technical tragedies rather than elegantly designed features, proving that this game is terrible and obtuse just beyond its community and difficulty.

This review was inspired by my recent replaying of the Warcraft 3 campaign. I knew that Dota 2 was based on a popular custom game for WC3, Defense of the Ancients. But I was shocked to discover how many mechanics weren't just similar, but were exactly the same. From things that made perfect sense to be in an RTS game with base building, hero units, and neutral camps, to emergent features that were simply what we had to work with.

Creep Aggro

Starting off with my most disliked "feature". But it's more like indelible technical debt. Removing it now will destroy the game so we all just have to live with it. Understanding how creep aggro works is what separates archons from ancients, and it's a mechanic that's not explained in the game at all. You either have to figure it out yourself (lol) or have someone on YouTube explain it for you (thanks Jenkins). The way a more modern game like League of Legends does it makes intuitive sense. Expect a few more League comparisons in this article, though I think it's a terrible game too, but for different reasons. If you damage the nearby enemy champion, all nearby enemy minions will stop hitting your minions and instead target you until you get out of range. You know, logic. They are there to protect their hero. Towers work exactly the same way; the only way to drop aggro is to GTFO.

Creep aggro rules in Dota 2 could not have been designed by any rational game designer, unless they were abusing inhalants. For some reason, the creeps in Dota 2 are telepathic. By simply issuing an attack command on an enemy hero (A-clicking and right-clicking an enemy unit are synonymous with issuing an attack command), either the one in your lane, or one from across the map (you can also do this by A-clicking their portrait on the top of the HUD as long as they're currently not in the fog of war), all nearby enemy creeps will immediately turn to attack you. You don't even have to hit the enemy hero, you just need to INTEND to attack them. The range is easy to intuit because it's exactly the same as the attack range of a ranged creep - 500 units. Towers work the same way too; intent matters more than the act. Keep in mind that you can do this only every 3 seconds. There is a cooldown that's unannounced and untracked so you also just have to intuit it. You can also drop aggro by showing intent to attack YOUR OWN UNITS. So if a tower or enemy creeps are hitting you, you can just A-click your own creep or your allied hero, nearby or from across the map, and the tower & creeps will think "yeah alright this bloke is no longer a threat" and will start hitting someone else instead.

exhibit 1: live demonstration of the creep aggro mechanic

On the surface, it might make sense to rework it to just trigger on damage. But if you do so, you are fucking over all melee heroes. They rely on this mechanic to have even a slight fighting chance against ranged heroes in lanes. Melee heroes also block some creep damage by default, so they can take more beating than a ranged hero doing this strat. Heroes with attack modifiers (like Viper and Drow Ranger for example) can actually completely bypass aggroing creeps if they cast these modifiers manually rather than putting them on auto cast and A-clicking enemies. Why? Because the Warcraft 3 engine treated casting these "orbs" the same as casting a spell, which does not trigger aggro. The AI is smart enough to read your mind when you right-click, but too stupid to realize that a manual 'cast' of a Frost Arrow is exactly the same as an auto-casted one.

For most ranged heroes, the right move is to avoid aggroing creeps most of the time because they'll melt you. For melee heroes, often the play it to move past your ranged creep (so you're within aggro range), A-click an enemy hero, and run back. Melee creeps will start running to you for about 2 seconds, then stop at your ranged creep. They will then start quickly killing your ranged creep, after which they will target the next closest target. If you position yourself right, you will become that target. You may then pull them closer to your tower and farm them safely. When I was in archon, nobody was doing this, so I felt like a genius when I discovered this tech for the first time. But once I reached high legend/low ancient ranks, EVERYBODY was doing it. And it's just an engine quirk from 2002 that Valve put herculean effort into recreating in Source 2. Because if they didn't, not only would purists get upset, but they would need to find another way to rebalance melee heroes. But I guess that's too much work for a small indie company such as Valve.

Neutral Camp Spawning (blocking & stacking)

You also cannot convince me that this was a conscious design decision. It's an exploit that everyone decided to call a "feature". The way a more intuitive game like League handles camp respawns is this: once you clear a camp, it gets put on a timer. Once it expires, the camp respawns. Simple and logical. In Dota 2, the map refreshes globally every time the in-game clock hits the one minute mark. So every 1:00, 2:00, 3:00 and so on. So you could kill a camp at 1:58 and have it respawn 2 seconds later-

As long as you are not in its fuckass rectangle.

The yellow rectangle, or the spawn area, is the area which the engine checks for units. It is invisible by default (just as it was in WC3), but in Dota 2, you can hold the ALT key to visualize it temporarily. If there is ANY unit in this area: neutral creeps, heroes, summoned units, even observer or sentry wards, spawn logic doesn't run.

With the only exception being couriers, of course. Couriers don't block camp spawning.

Why?

Because fuck you, that's why.

But anyways, you can dupe this logic by attacking the camp at around the 55 second mark and running away. They will chase your hero and leave their spawn area. If there are no units in that rectangle once the clock hits 1 minute, you will trick the game into believing this camp has been cleared, and another pack of neutral creeps will spawn in their spot, and the creeps that were just chasing you will eventually return. Now there are technically 2 neutral camps occupying the same area. You can continue doing this indefinitely, but every stack becomes more difficult as units will clump up and start bumping into each other. But I've seen stacks as high as 6 or 7 (haha funny numbers).

Exhibit 2: live demonstration of the camp stacking mechanic up to 5 stacks

This is obviously just a limitation of the WC3 world editor. The DotA designers needed the neutral camps to respawn. Bounds checking was the simplest way to solve that problem, and we have to live with that decision in 2026. It also ensures that the laning phase turns into a cat and mouse game where your support is trying to stack the camp that's closer to their tower and block the camp that's closer to the opponent's tower, by either blocking it with wards, or with their own hero, or summoned units. It's annoying, it's archaic, but it is the absolute best way to squeeze as much farm out of the map as you can, as the map is colossal and you can only clear so many camps every minute. So consolidating them in the same location is just logical. And it's not like you can just not do this. In lower ranks, maybe. But if you are supporting in higher ranks and you don't stack high value camps, your carry will scream at you in a foreign language.

In order to be competitively viable, you must utilize decades-old exploits that were just… never patched out of the game.

You can also pull a neutral camp into your creep wave, causing them to abandon their assault on the opposing tower and start clearing the neutral camp instead. This is sometimes done to pull the lane back closer to your tower, and to deny the gold and experience to your opponents by having the neutral creeps kill yours. I won't go too in depth on this mechanic in this article, but just know this: like stacking and creep aggro rules, is it boring, nonsensical, feels exploitative, and is absolutely vital to high-level play.

High Ground & RNG

I actually really enjoy the high ground rules. I like the strategic depth it adds. There are several levels of elevation on the map. You can see everything on the same level and below, but you can't see the upper levels. The river that divides the radiant and dire territories is on the lowest level on the map. Encroaching on the enemy territory forces you to go uphill blind, which gives defenders an advantage. There are also hyper-elevated hotspots on the map, steep but isolated cliffs. They are designed for warding. Those spots are highly contested as wards placed there reveal absolutely everything within their radius. Another notable high ground points are the bases themselves. The tier 3 tower sits on the inner perimeter of each base, on the edge of the high ground. It is often the hardest tower to siege because to hit it, you need vision, which usually means walking up blind. This often means that sieging the tier 3 tower and the barracks that sit right behind it is the hardest milestone as the defenders have a high ground advantage on top of a very powerful tower. Your lead means effectively nothing if you can't siege the tier 3 tower, which has led to many cinematic comebacks in my time playing this game.

exhibit 3: demonstration of the power of a high-ground ward

There is another high ground interaction that I don't quite love as much. The miss chance.

All ranged attacks that connect uphill have a 25% chance to miss. This calculation happens not when the projectile is launched, but as soon as it connects. This means that you could shoot an attack while on level ground, the opponent could walk up and immediately have a 1 in 4 chance to completely evade the attack. This is another thing that the WC3 engine was hardcoded to do. Because the units in WC3 are plentiful (in regular RTS play), this was done as a way to give uphill defenders an advantage. Because when you have 10 units attacking uphill, the 25% misses average out across all units, so you can expect a roughly 25% damage reduction. But you never amass many ranged units in Dota 2, unless you're Enigma and your eidolons are going ham. Your attacks are coming from 1 unit - the hero you control. Because of that, misses are felt more viscerally. And they feel horrible. Bad luck could mean the difference between getting a crucial lasthit or even finishing off an enemy hero. Missing those kills feels like being robbed. But no, because Warcraft 3 did it, and for no other discernible reason, Dota 2 must do it too.

The RNG nightmare of Dota 2 doesn't end there. Sure, there are items that gives a random crit chance, and there are heroes that have passive abilities that have a random chance to proc on hit. There are also entire heroes whose kits are defined by randomness (looking at you, Ogre Magi and Chaos Knight). Though one thing worth noting is that Dota 2 and DotA (WC3) both use the pseudo-random RNG system, meaning that the game artificially nudges you towards having an average of a 17% chance to bash someone with Spirit Breaker, for example. For each hit you don't bash, the probability goes up, and for each hit you DO bash, the probability goes down. This helps with preventing extreme lucky or unlucky streaks.

What isn't averaged, however, is the attack damage spread.

If you're unacquainted with the WC3 engine or with how Dota 2 calculates damage, you might be wondering "the fucking WHAT spread?" But you read that correctly. The attack damage spread. The WC3/DotA HUD was kind enough to show you the entire spread of your attack damage. For example, it would show you a range of 49-59. This means that each right click attack you perform, it will hit for a random value between 49 and 59, before any other calculations (like armor % reduction) kick in. If you think this was removed in Dota 2 because it simply shows you a single damage value - then you would be a naive fool. Dota 2 lies to you. It still does this shit under the hood, you just can't glance it. It simply displays you the mean of these two values. To see the actual range, you have to mouse over your stats to get an overlay with more detailed information. No one can convince me that this is a good mechanic that should stay, because I know it's not. I can't think of a single reason. It's just more legacy WC3 bullshit that was questionable even back then. If you're an avid Dota 2 enjoyed, just know that if you ever missed a lasthit by a couple of hitpoints, or failed to kill an enemy hero that survived with 1 HP, you may have been a victim of a low roll. Your 78 damage actually hit for 71, and there was nothing you could have done about it.

Take a look at the images. Do you see how in the Dota 2 screenshot above, the numbers on Axe's portrait just show a flat number, while the popup displays the full damage range, clarifying that 59 damage is actually 57-61? While Warcraft 3 shows you the range directly on the HUD without hiding it. Still, if it was up to me, I would remove the damage spread entirely and just have it be a flat value.

NEUTRAL ITEMS; SEVEN YEARS OF LOTTERY TICKETS

Let's get into some more RNG. Neutral items were introduced in 2019, patch 7.23. They dropped randomly from neutral camps for years. They gave passive abilities, sometimes active AND passive, and sometimes just active. The loot table got stronger at game clock milestones, with the strongest tier being at 60 minutes for full-length matches and half that for turbo matches. They were completely random and ranged from being absolutely useless for your hero, to definitively game-winning. The last tier had the biggest power spread, usually winning or losing the game for your team instantly depending on how lucky your team got. This system was in the game just as I had just described it for YEARS, until 2023 where in patch 7.33 they would instead drop a token which you could exchange for a neutral item from a randomly generated pool of 5. Still random, but at least you had some agency. Then in 2025 patch 7.38, they reworked the system again so that the neutral camps began dropping a resource known as Madstone. Once you've collected enough, you could craft an item and imbue it with an enchantment, both also from a random pool of 4 at the first tier. For further levels, you had 5 options, but one of them was to keep your old item, you actually only had 4 new options now. It's funny in a way. They had recently made the map 40% bigger, but the designers were too scared to give you complete control over what items you get. That's also when they started adding way more active neutral items, where you had to use them to get their utility, otherwise they were just paperweight. Debatable decision, but it is what it is I guess.

exhibit 4: crafting a tier 1 neutral item

Then finally, in the most recent patch as of writing this in 2026, 7.41, they constrained the enchantments you could put on these items to your primary stat. So if you were playing a strength hero, you will always get to pick from 4 specific enchantments, then 5 (keep the old one). Same if you were agility, intelligence, or universal. The artifacts themselves remained completely random. This RNG circus has been going on for approximately 7 years. And I think that's tragic. The sad thing now is that there are more active neutral items than ever, and I never remember to use them during fights. I think they should just be passive man. But maybe some immortal 326 sweatlord will disagree with me and tell me to git gud. And to that I say: get a life, loser.

By the way, putting Helm of the Undying as a random drop in tier 5 was unacceptable. What the fuck were they thinking? They were abusing inhalants, I reckon.

Unit Pathing & Turn Rates

This is probably the most immediately-felt point by the newcomers. Pathing in WC3 was a 2002 RTS issue that was solved with the technology and knowledge that was available in 2002, and it is notoriously awkward. Each unit has their own collision radius which determines how close they approach buildings, trees, environmental obstacles, and other units. Unit radius is highly varied, but all heroes have the same collision radius of 32 units. Naturally, buildings are larger and units are smaller, and heroes are average-sized. The way pathfinding works is via a simple A* algorithm. It checks the position of the controller unit, compares it to the position of the movement target, and calculates the shortest route to the location. The pathfinding correctly accounts for map changes - when a tree gets cut down or a building is destroyed, subsequent movement commands will route around the new layout.

Units are not part of that navmesh. They are dynamic units that all USE the navmesh to calculate their own movement. Because units in these games can bump into each other, this presents a complicated problem on how to resolve their movement when two units want to move to the same position, but they get in each other's way. In more modern games, the units just glide along each other as they also have small collision radiuses, and when they aggregate on the same point - they get slowly pushed apart. But in Dota 2 and WC3, if you occupy a space - you fucking OCCUPY it. That little area of the map is rightfully yours by divine right. When these feeble-minded weaklings try to occupy the same space as you, they must recalculate their path on the spot to path around you, like pathetic peasants. Unless their position changing abilities or items like the Force Staff have anything to say about it.

exhibit 5: Enigma dying because he was body blocked by a treant

This means that you can actually BLOCK your opponent's movement by moving in front of their path and stopping in front of them. They will bump into you, stop moving for a fraction of a second, recalculate their path, and start moving again shortly. If you've internalized the jank and learn to react to where the enemy character is turning and how quickly, you can predict where that new path will go, and you can intercept it again, forever preventing your opponent from moving. It then becomes this little game of who can out-path-find each other on janky 2002 engine logic. This leads to scenarios where your hero's escape, a 2500 HP 150 damage gigachad, gets thwarted by a single 450 HP 43 attack damage summoned sentient broccoli unit from Nature's Prophet. In a world of cosmic deities and literal fundamental forces of the universe, a small animated sapling is an immovable object that can sentence a god to death by simply standing still. Hilarious when you're the Nature's Prophet. Infuriating if you're his victim though.

Yeah, "skill expression" and all, but it's not particularly hard to do and it's boring to watch.

Just like manipulating creep aggro.

Just like stacking creeps.

Just like getting lucky.

Bitter Conclusion

Every mechanic I've described above could theoretically be fixed. But here's the thing - they won't be, and not because Valve is lazy. It's because at this point, they can't be. Remove creep aggro and melee heroes lose their only real foothold in lane. Remove camp stacking and suddenly half the farm-dependent heroes in the game are starving. Remove unit collision and an entire category of summoner playstyles collapses overnight. These aren't bugs that survived. They're fossils that became foundations. Valve didn't just inherit a 2002 engine's worth of mechanical debt - they built a competitive ecosystem on top of it, balanced around it, and shipped it to millions of players. The jank isn't a flaw in Dota 2. The jank is Dota 2. And that means you, the player, are permanently on the hook for learning archaeology just to play the game competently in 2026.

I have about 3600 hours on this game combined with my two accounts, and less than half of them were enjoyable. I am never getting those hours back and I have already made peace with this reality. I quit playing ranked once I reached the Ancient 1 rank, around 85th percentile of all players globally. Not pro level by any means, but definitely not a noob either. After that, I began queuing turbo almost exclusively. I thought that would lead to faster matches and therefore less tilt, but I've been part of some absolute 60 minute slugfests in turbo. I have lost many matches where I played my heart out while caffeinated, just as I have won matches where I was sandbagging intentionally. Both of these things made me feel like my efforts are worthless. This shit should have stayed as a fun WC3 mod that functions as a LAN party game. Instead, Valve twisted and groomed it into becoming one of the biggest Esports in the world. And the people justifying this by saying that you need "mental fortitude" to climb to immortal, or to even enjoy the game? This is a genuine mental health hazard, and I'm not being hyperbolic when I say this. What other game requires therapy to enjoy it? I can only think of Monopoly as that almost tore my family apart, and it's funny I should mention Monopoly here as it is also an RNG-based battle of attrition. Sound familiar?

All these things make the game feel like an abusive relationship, where the good moments aren't particularly good, but they contrast so sharply with the abuse that the "good" moments feel like the relationship isn't actually that bad. And you don't want to leave that person because you've known them for so long. You've grown attached to all of their flaws, their quirks, and their patterns. The sunk cost keeps you chained. But mark my words. No matter how good you are, what rank you have, and how many hours you have, there WILL be times when you're on the receiving end of this abuse, by no fault of your own. And there is nothing you can do about it. It's why over time, wins start feeling "meh" and losses make you want to break your keyboard in half. Remember, it's a 5 versus 5 game. Your individual effort only amounts to 20% of the impact you can make on the game, as long as you're playing within your skill bracket. You think you're having a "good game" and you're "popping off", but you're not. You just got lucky. Your abusive partner was having a good today and spared you. I briefly considered solipsism. At least then the losses would be my fault.

CREDIT:

Credit where credit is due. Rapid firing some things I really enjoyed about the game.

Balancing philosophy of "if everything is broken, nothing is" is genuinely fun and somehow works. Instead of trying to make everyone equal (like League of Legends), everyone is really good at one thing, which puts a bigger emphasis on making a balanced team. Though sometimes this philosophy is better in theory than in practice, as some things will always be more broken than others.
I can't think of a better-engineered game client than Dota 2. It is smooth, looks amazing, performs well, full of well thought-out features. Too bad they're wasting this engineering talent on a psychological meat grinder.
All heroes are free. Nothing is gated behind some fake in-game currency or real money spending. All heroes have been free to play from day 1, and they will continue to be free. Riot games, take notes.
Ward warfare. Wards actually matter a lot, especially those contested hotspots. This makes playing support a real mental exercise as you're trying to out-4D chess the enemy supports by placing wards in unpredictable and predicting where theirs will be. I always have fun with it when I play support.
The spectating and replay system. Dota 2's tools for watching and analyzing your own games and pro games are genuinely class leading and tie into why the skill ceiling is so high.
Sound design is exceptional. Every spell and item has a distinct sound. There are even distinct sound effects for failing to cast a spell if you're stunned, out of mana, silenced, or if the spell is on cooldown.
The item shop is loaded. It has a massive roster of items which take a while to learn, but they're all very powerful in their own ways and can counter each other. Once you learn to itemize properly rather than following a prebuilt guide, your rank will skyrocket. Also, I love that BKB breaks League players' brains.
Still better than LoL. But barely.

FM - Log 4

Thu, 29 May 2025 00:00:00 GMT

Well, well, well…

I have excellent news. Since regaining momentum, I haven’t let up - solid hours, late nights, focused evenings. Core systems are finally clicking.

Fair warning: it’s still ugly as balls. But the systems? They're coming together better than I expected. I’m close to having a fully functional skeleton - just waiting for the visuals to catch up.

This dev log is a bit more compact than the last few. Hopefully I can keep it that way (unless Unity spontaneously combusts and I have to switch engines again - please don’t, Unity).
Last time was catch-up. This time? Pure forward momentum.

Also: the project has a new name. It’s called Entropy FM now. You’ll see why by the end of this log - but let’s just say the rebrand wasn’t cosmetic. It was narratively and logistically necessary.

I won’t mention the obsolete Unreal logs anymore, but if you're new here, I’d recommend reading the previous dev log for context - especially if you want to understand how the current prototype took shape.

FM - Log 3

Ghosts of Pipelines Past

Two nights. Gone. Swallowed by a bug so stupid, so infuriating, I questioned my entire life trajectory.

Characters were leaning back during attacks - like someone whispered “Neo” and they all dropped into bullet time. I tried everything: masks, overrides, spine rotations, blend tree sanity checks. Nothing worked.

Until, finally, I found the demon.

The idle animation.

Not just any idle - the idle from my Unreal prototype. One I had retargeted months ago, thinking I was being clever. “Let’s reuse what I've already made,” I said. “Save time,” I said.

Instead, I buried a landmine in my own pipeline. A forgotten pose, subtly broken, quietly ruining everything.

Deleted it. Replaced it with a T-pose. Problem solved.

I didn’t even end up using any of those retargeted animations. All that effort? A sunk cost. Just tech debt with a personal grudge.

Lesson learned: Old work isn’t always treasure. Sometimes it’s cursed.

你能读懂中文。可惜这并不重要。

I built a localization pipeline that currently supports six languages:

English
Russian
Chinese (Simplified)
Japanese
Spanish
Brazilian Portuguese

More will come later - for now, I’m focusing on the highest-impact languages.

The translations are… fairly faithful. I think. I’m keeping the methodology under wraps for now - trade secrets and all that. Maybe I’ll explain it in a post-mortem, once the dust settles.

Eventually, I’ll need community help to make sure the translations aren’t just accurate, but emotionally resonant.

That’s a future problem. For now, it works. It works well.

Cutscenes, Cutscenes, Cutscenes

The dialogue system got another round of polish - and it’s finally robust enough to support full-on cutscenes. I’ve already used it to build Maria’s intro, which stress-tested everything under fire. She’s now fully introduced in-game.

I’m currently working on more cutscenes, but they’re taking time. Why? Because each one forces me to build out more core systems:

Maria’s blocking needed to exist first.
Kiwi’s projectiles (plus a special homing version used just to trigger her intro).
And soon, Ebo’s cutscene - which means implementing his dodge ability.

Update: Kiwi’s intro cutscene is now complete. Next up: Ebo.

Main Menu

The old menu served its purpose. It worked.

But now? It’s smooth. It’s whooshy. It’s actually… kinda nice.

It works with a controller. Transitions are animated - menus flip into view when entering sub-menus. It just works™.

Save & Load System

This ties into the new main menu frontend. Lame, but necessary.

It’s smooth as butter. Kind of hacky, but hey - it works.

Pressing Start drops you into the intro level.
Continue resumes from the last checkpoint in the furthest level you’ve reached.
And if you finish a level with one character, it gets permanently saved - so you can switch to another character mid-story without losing progress
All unlocked levels are accessible anytime via the Level Select menu.

Clean, flexible, and future-proof-ish.

Intermission

I hit the brakes for a bit - felt the burnout goblin creeping in.

Here’s how the burnout goblin works: You start putting in more effort, but getting fewer results. Eventually, just opening the project feels like a chore.

So I took a break. Just two weeks - short, but necessary.

It coincided nicely with the Unity Asset Store sale, which helped. I grabbed two assets I’d been eyeing for a while (and which were actively blocking progress): Animancer Pro and Final IK.

That said, a bigger pause is coming. Real-life logistics mean July will probably be a survival month, not a dev month. I’m moving to another country, re-settling - the whole ordeal.

Just putting that out there for those closely following the project. I’ll try to get another dev log out by the end of June, before the chaos hits.

Sale

Asset sale wooo! I love spending $300 on Unity assets.

Not gonna lie - a few were impulse buys. But a lot of them turned out to be golden pickups that have already made my workflow smoother in meaningful ways.

Also: Gore was removed and refunded due to a "copyright infringement issue."
First time I’ve ever seen that happen. Fine, I guess. No gore then.

Final IK is now in the toolkit - opens the door for inverse kinematics. I’ve played around with it a bit, but haven’t found a solid use case yet.

Animancer Pro, though? Absolute game-changer. It completely unlocked my cutscene animation workflow. I like it so much I’m considering migrating the player character animators over to it - though I’m holding off for now.

Why? Because Unity is supposedly dropping a brand new animation system in the next major update. If it really fixes the “transition soup” issue that plagues Mecanim, I want to at least give it a shot before committing to Animancer across the board.

New Hitbox Detection System

EnemyHealth and capsule colliders are no longer doing the heavy lifting. Well - they still exist, but their roles are now more isolated:

EnemyHealth no longer handles damage detection.
The capsule collider is now just used for navmesh calculations.

Enter: HitReceiver - the new system for receiving player attacks.

These bad boys sit on enemies and detect incoming hurtboxes and projectiles from the player, then forward the damage directly to EnemyHealth. Clean separation of logic. Works like a charm.

This shift was necessary when I started working on projectiles that embed themselves into enemies and walls - namely, Kiwi’s meat cleaver.

It uses a surface-aware detection system based on a new class: ColliderHitProperties. Every physical collider is expected to have one. When the cleaver hits something, it checks the surface type:

Hits flesh or soil? → It embeds.
Hits metal or stone? → It bounces off.

Pair that with surface-dependent VFX, and you get impact visuals that actually make sense. The cleaver doesn’t just hit - it feels like it hits.

And yes - it looks sick.

Design Philosophy

Entropy FM is built around a single principle:

Fragility drives meaning.

That core idea shapes how the game plays, how it looks, and what it tries to say - even when it whispers. The systems are sharp, the visuals constrained, and the world intentionally vague. You’re not meant to feel empowered. You’re meant to feel watched.

Gameplay Design - The Fragility Simulator

This is not a power fantasy. It’s a fragility simulator.

It is surprisingly easy to die. That should come through in every encounter.

Most enemies go down in one hit. So do you - unless otherwise stated, depending on each character’s resource system.

Every fight is a coin flip, unless you’re fast, focused, or cruel enough to cheat the odds.
Bosses and special units bend the rules. But not by much. Nobody is safe.

This isn’t about fairness. It’s about tension - that tightrope feeling, like the world could collapse under your feet.

Because in this world, even your thoughts can betray you.

But failure isn’t punishment. There’s no “You Died” screen. No crawl back to the fight. You respawn instantly. You try again. And again. Until you learn.

The mechanics serve the tone. You don’t earn power by grinding. You earn it by surviving.

Aspect Ratio - The Frame Is Lying to You

Entropy FM is locked to a 4:3 aspect ratio - even on widescreen or ultrawide displays.
Yes, that means black bars. Yes, it’s intentional.

Three reasons:

Analog horror needs analog framing.
This is a game about decayed signals and dying tech. CRTs, broadcasts, magnetic noise. 4:3 isn’t a limitation - it’s an artifact.
Visual consistency and balance.
On ultrawide displays, players could see offscreen enemies and cutscene content too early. That breaks framing and cheapens tension.
Claustrophobia as a mechanic.
4:3 compresses your view. You feel boxed in. Trapped. And because it’s implemented via dynamic letterboxing, the frame can shift. Shrink. Close in. The screen itself becomes a narrative device.

The aspect ratio isn’t just a visual decision. It’s part of the world. And one day, it might betray you.

Narrative Design - The Signal Is Corrupt

This is not a story about saving the world. It’s about what’s left when saving it stops making sense.

There is a broadcast. It reaches everyone, eventually. Sometimes it gives you strength. Sometimes it erases you.

You play four characters. None of them are stable. None of them are safe.

People forget things. Places change when you're not looking. Names mean different things depending on who speaks them.

There is no codex. There is no lore dump. There is only what you see. And what you remember seeing.

So Why Is It Called Entropy FM now?

The original title - Forgotten Memories - was never going to last. Too vague. Too safe. Too nostalgic for a game that punishes nostalgia.

For a while, I considered The Fortunate Four. But with the story I’m telling, that name felt too ironic. Almost cruel.

So: Entropy FM.

Not a location. Not a faction. It’s a frequency. A parasite. A broadcast you can’t stop hearing once you’ve tuned in. Sometimes it grants clarity. Sometimes it replaces your memories with new ones.

It isn’t a metaphor. It’s a mechanic.

The name isn’t branding. It’s a broadcast. And like all broadcasts in this world - it changes you.

You’ll understand when the signal reaches you.

Polish

I’ve been sneaking in polish tasks throughout development - little things that add up:

Characters now look at nearby enemies (eye contact = violence).
Hero’s bar flashes when he’s in danger mode.
Blood VFX direction is now separate from ragdoll impact - cleaner, grosser.
Added a killbox for falling off cliffs… even though I’ve currently removed all cliffs. (Future-proofing?)
Ebo’s auto-aim got smarter - he can now target specific body parts like the dead-eyed automaton he is.

Failures & Known Issues

“Prepare to attack” pose didn’t land. I tried implementing a pre-attack animation state - an upper body override that gets more pronounced the closer you are to an enemy - but it doesn’t feel right yet. Will revisit once I have more time to tune animation timing and transitions.
Final IK still searching for a purpose. I’ve experimented with it, but haven’t found a compelling use case yet. Once limb-specific hit reactions are in, I might use IK to drive real-time flinches. The old system had baked flinch animations - IK might feel snappier and more reactive.
Environment design is currently an afterthought. Everything’s still blockouts. Ironically, it feels worse to navigate than the earlier scribble-filled greybox plane. Will need serious polish later - right now, it’s just functional enough for gameplay testing.

Demo Night

I brought the game to a demo night in Boston. Stood there with my tablet like some kind of lab-coated scientist, watching people get wrecked in real time.

Most people seemed to enjoy it. Only two bailed. A few really liked it - not sure what to make of that yet. Didn’t blow socks off. But clearly not dog shit.

Anyway, here’s what I learned:

Immediate Priorities

Hero’s Blue Bar is Confusing
Most players had no idea what it was. Currently working on a rework that clarifies its function without spelling it out like a tooltip in an MMO.
Swing VFX ≠ Hurtbox
A lot of people assumed the swing visual was the damage zone. It’s not. Needs cleanup - VFX must better align with what’s actually hitting.

Considerations

Slow Start
Game gets good once Kiwi shows up. Might need to tighten pacing before her intro so players don’t bail early.
Maria’s Mini-Boss
Boss behavior is clunky. Sometimes whiffs entirely over the player’s head. Needs refinement on attack logic and hurtbox shape.
Attack Clarity (Maria)
Some players didn’t realize Maria could attack - assumed she was a block-only character. Reinforce that right stick = universal attack.

What Worked (Double Down)

Kiwi = MVP Everyone loves her feral playstyle and chaotic intro. Especially liked how her cutscene subtly teaches you to block by wrecking you first.
Animated Dialogue Portraits Strong positive feedback here. Players consistently praised the writing and the dialogue system. This is core - will keep investing in it.
Core Controls Are Intuitive Even players unfamiliar with the setup picked up the basics quickly. One non-English-speaking kid figured out Maria’s block just from design cues. That’s a win.

Other Observations

Creative Problem-Solving
Players approached rock enemies in three ways:
1. Dodge and punish when grounded
2. Hit mid-air
3. Block and let them disintegrate
  This was unplanned - but elegant.
Singularity Bug
One rock phased through the player. Happened once. Never again.
Quantum tunneling?

Finale

Thanks for sticking around.

I know this update’s a bit less packed than the last few - not much flashy stuff to show. Most of the recent work has been structural: time-consuming, necessary, and not particularly thrilling to write about.

But we’re close. Mechanics are nearly locked in, and that means polish is finally on the horizon. With any luck, the next dev log will bring updated visuals, improved audio, and a build that feels like the real thing.

FM - Log 3

Sat, 22 Mar 2025 00:00:00 GMT

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.

UPDATE: Trello board is dead.

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.

FM - Log 2

Mon, 03 Jun 2024 00:00:00 GMT

I strongly suggest reading dev log 1 first if you haven't already. And here's a link to log 0 in case you missed that as well.

This is ~~week~~ month 2 of working on Forgotten Memories.

Expect a lot fewer tangents in this update and more actual FM-focused work, as I have effectively done everything to unblock myself from committing valuable time to this project since the last dev log. I'll still bring up procrastination, but it will be much less prevalent than last time.

Demo Night Build

If you remember from the previous dev log, I set a soft deadline of May 21st to make a playable demo.

I have a deadline on May 21st. It's a soft self-imposed deadline though. No one will fire me or murder me if I won't make it. The worst that will happen is I'll be a little disappointed in myself. There will be an open demo night, and I intend to bring a playable demo of FM there. This deadline will force me to prioritize some tasks over others. Some of them may not be as fun as others, but that's ok. As long as I can stay in a state of flow for a prolonged period of time, I have confidence that I can knock them out one by one.

I am happy to announce that I have managed to put together a demo for May 21st! And that I showed it off! And people played it!

Above is some gameplay footage from said build. You can download it and try it yourself here. The control scheme was written with a dual-stick controller in mind because I was showing off the game on my Steam Deck, but it will work fine on a keyboard too. WASD to move, arrow keys to attack, escape to exit to the main menu.

If you watched the video to the end, you may have noticed that I couldn't beat the last section. When I was showing off the demo, I only remember three people reaching the end of the level. The rest of the players got too frustrated at rooms 3 and 4 and ended up quitting.

Actually you know what, to stay consistent with the last dev logs where I posted unfiltered notes, here are the notes I took during and shortly after the demo night, so you can see my thought process. It's optional reading; I'll sum up my notes in the next few subheaders anyway.

Difficulty

Difficulty was way too overtuned. The zombies are meant to be the easy trash enemies, and right now they are formidable foes with way too many hit frames. Their difficulty and quantity is what made the demo so frustrating to go through for many people.

Nobody appreciates large difficulty spikes, so I'll be taking the steps to nerf zombies. A simple tweak to their attack animation speed and lowering the active frames on their attack collision box should be enough to make them decently balanced. I plan to introduce more difficult enemies later in the game, but for the current vertical slice that I have planned, they really shouldn't be more than cannon fodder that pose a threat only if you aren't paying attention.

Playable Characters

There are 4 unique playable characters in the demo. Admittedly, I had to crunch to get them in on time. I will describe them more in-depth later in this article.

But I will say, because of the way I designed the demo, not many people got to experience these characters. At the end of the level, there are 3 boxes that let you select a new character and replay the same level as them, but hardly anyone beat the demo. In retrospect, I should have implemented character switching at will.

Unclear Direction

There was a concerning pattern of people going in the wrong direction. I made the level pretty linear, so there shouldn't be any confusion as to where the players were supposed to go. Right?

WRONG! Above is my artistic rendition of what happened a few times. After dying and respawning at the last checkpoint, some players started going in the direction of where they just came from. That way, they were able to kill zombies from behind where they couldn't be aggroed, and they were able to re-trigger old checkpoints, undoing their progress.

I followed playtesting advice from A Playful Production Process. Two notes that stuck out to me were:

Don't tell the players where to go, whether they're doing anything wrong, or how to play in general.
Don't trust what they tell you. Simply observe how they interact with the game and draw conclusions from that.

I followed that advice to a tee. Even though it was extremely frustrating to see players going in the wrong direction repeatedly, just as it was frustrating to watch them misunderstand the blood mechanic, in accordance to the playtesting rules I borrowed from the book, all I could do was watch (and wince in pain).

This experience taught me a few things:

Different players interact with video games in wildly different, sometimes unpredictable, ways. I had one guy who used the sticks like this: Steam Deck laying on the table, and he was controlling the sticks by pinching them between his thumbs and index fingers. It's not an invalid way to interact with the game, but it's one I could have never predicted if I didn't do this playtest. It made me think of many other unconventional ways players may interact with a game.
When players engage with a new game (at least in my personal experience and what I've seen from the demo night), they tend to go into it with a sense of dismissive disinterest, unless there is something that hooks them from the first glance. Ideally, that hook leads them into an enjoyable gaming experience, and they stick around long enough to experience everything that the game has to offer. My demo lacked that clear hook, which is my theory on why many people didn't give the demo a try.

Lack of Visual Appeal

To supplement the last point, this demo had prototype graphics. I was using generic untextured cubes, grid for the landscape, and default UE mannequins for characters. The only visually cool thing about this demo were the blood splatters. Which are cool, but to see them, you had to play the game and kill zombies.

I noticed that during the demo night, many people glanced at my little Steam Deck, and walked by without any interest. My setup just paled in comparison to the setups of other people that had a lot more presence. Many of them brought laptops, some even brought their own monitors. A rare few even had custom props, and those definitely stood out the most. I think this marks a good point in development to start worrying about custom art assets and some degree of superficial appeal.

On-Screen Tutorial

It didn't do its job.

Admittedly, this was a last-minute addition as I was scrambling to put the demo together before the deadline. This tutorial text lingers for 5 seconds after reloading a checkpoint, then fades away. I tried to make it as concise as possible to increase the likelihood that people will read it. Maybe 5 seconds was still too short, but I couldn't figure out in time how to make this text only show up once when you start the game. Otherwise, I would've made it longer. So that's a mistake on my part.

I think only 2 or 3 people ever read it. One person thought that the red bar on the left was "health", and that you lose health by killing enemies and must wait for it to replenish. Either way, this experience taught me that people just don't like to read. They need to be given a reason. I'm planning to have some dialogue in the game, so I'll have to balance the volume of text with its accessibility. It also taught me to consider the introductory experience a little more than just a short prompt on screen.

This experience also taught me that crunch is bad. I know, only brave statements on this blog™️.

Conclusion

Overall, playtesting feedback was mixed. But it provided me with some valuable insights that will ensure that the next playable demo (hopefully a fully decked-out vertical slice) will be in its best possible state.

Trello Board - Thoughts

The [~~Trello board~~](https://trello.com/b/1IhacekX/forgotten-memories) ended up being a successful experiment. It allowed me to visualize my progress and keep track of tangible tasks that I could work when blocking out time for the project. It also provides another way for people who are interested in my progress of staying up to date with the project outside of these monthly dev logs. I will definitely continue keeping it up to date, as it is very cathartic to move tasks under the "Done" header.

UPDATE: the Trello board is dead.

Zombie AI Rework

One of the biggest improvements since the last update was a complete overhaul of the zombie logic.

I deleted all existing zombie-related assets and remade them from scratch. New AI controller, new behavior trees, even new model + animations. To achieve this, I followed a tutorial series by Ali Elzoheiry to get a general understanding of the tools that UE5 provides for creating smart enemy AI.

I made a schedule for myself where I would watch one episode per day for a week. However, it's a pretty long series with 23 videos with an average duration of 40 minutes. I didn't want to spend too much time watching these tutorials, so I created a cut-off point where I would stop watching after a specific episode. I think I decided to stop watching after episode 9. But at some point, I found myself procrastinating from working on the project because I really didn't want to keep watching these videos after episode 4, which was the introduction to the EQS system. Everything after the EQS system was just polish and re-visiting concepts that I was already familiar with. So I actually decided to call it quits after episode 6, because I noticed that the feeling of dread over wasting my time endlessly watching tutorials was a source of procrastination.

The tutorial series were overkill anyway. Because really, all I needed was simple logic for a very stupid zombie enemy that beelines at the player, starts attacking when it gets close enough, and keeps repeating that behavior until either it or the player is dead. Once I start adding more varied enemy types, I don't think I will need to rely purely on tutorials. I believe that my problem solving skills combined with the abundance of online resources will make whatever I want to achieve possible.

4 Playable Characters

With the zombie rework came another restructuring. This time, it was of the main character actor and its 4 children, one for each playable character.

Each character is a child of the base character blueprint, but with its own custom model, attack logic, and animation blueprint.

Above is a showcase of these 4 characters, with their own unique attack and movement styles:

Character 1 has a fairly short attack range, but high attack speed, and attacking doesn't impede movement.
Character 2 has a longer attack range and sweep radius, but lower attack speed, and the force of the swing sends them in the opposite direction of their attack.
Character 3 has very long attack range and sweep radius, but very low attack speed, and the attack animation locks their movement in the direction of the swing until it's finished.
Character 4 has a ranged attack that's fairly fast and doesn't impede movement. To compensate, their overall movement speed is slower than the other characters.

These designs are by no means final, but they show off the flexibility of the new character framework that I've built. If I ever plan on expanding the game to be able to handle, say, 8 unique playable characters (there are currently no plans for that though), it will be fairly easy to add. It will also be very easy to adjust, or even redesign, existing characters. That way, I'll be less scared to iterate and scrap ideas that aren't serving the game.

You may also remember from the previous dev log that I made an executive decision to visualize the attack hitbox. This is what it used to look like.

That executive decision is now null because I reworked the attack hitbox entirely. It now follows the weapon instead of just popping up in front of the player. Different characters have different hitbox sizes and active times. Character 4 instead shoots out a line trace in the direction of the shot.

Animation Framework

To accompany the gameplay logic, I also took the time to build 4 animation rigs, one for each character. To do this, I simply took Unreal's default mannequins (called Manny and Quinn) and adjusted their proportions to be close to how I intend these characters to look like. Then, I used the UEFY 2.0 plugin to instantly build these rigs complete with twist bones and everything else, and then I used Rigify to build controls. It took me a few days of exploration to figure out the best way to do this, but I ultimately settled on this solution.

The good thing about this setup is, it makes it very easy to iterate on animations. Also, it doesn't rely on having a complete character model to work. Later down the road, once I start getting custom assets for the characters, I can just slot them into these rigs, and with some weight painting, they'll be fully animated.

Crunch

Under the demo header, I mentioned that I had to crunch to get this framework done. Here's a a rough timeline of events:

May 1st - May 12th: watching AI tutorial series while redesigning zombies, I also made checkpoints somewhere in this timeframe May 13th - May 17th: procrastination May 18th - May 19th: exploration of the animation framework May 20th - May 21st: crunch time + demo night

My feelings on the crunch are mixed.

Pro: I was able to get a lot of work done in a very short amount of time. I was honestly dreading re-designing the character and animation frameworks. I knew how to do them, but I also knew that these are pretty labor-intensive tasks. But my caffeine-fueled crunch sessions made me knock them out in about 8 hours. If I wasn't as focused as I was during those crunch hours, those same tasks would have taken me longer to do because I wouldn't have been as focused.
However: there are actually 2 con bullet points here:
- After the demo night, I was burnt out and didn't want to touch Unreal Engine, let alone the FM project, for a couple of days.
- The crunch has led to the creation of some spaghetti code. I had to spend some time to untangle it after the demo night was over.

This leads me to believe that crunch is unsustainable long-term. I know, only brave stateme- wait, I already said that. But basically, after experiencing self-inflicted crunch and analyzing the effects this experience had on my well-being, it's no wonder that so many studios where crunch culture is prevalent release so make broken titles.

I could have made the same amount of progress if instead of procrastinating my way through this time period:

May 13th - May 17th: procrastination

I could have gotten the new animation + character framework done, while circumventing the consequences of crunch. That's my takeaway. Sure, it would have taken more hours most likely, but the turtle wins the race, or something along those lines.

Joel Strikes Again

You may remember Joel from the previous dev log. He's been helping me out with systems design for this game. The next two subheaders will delve into that.

He also fixed a really weird and obscure bug with swinging animations that's been bugging me since the initial creation of the player character framework. Thank you Joel, very cool!

Checkpoints

Checkpoints were created for the demo, but they will continue to be used moving forward as they interact with the next system I'm going to describe.

Above, you can see how the checkpoints were used in the demo level. When the player collides with them, it copies their location, passes that information to the game instance blueprint, and sets it as the respawn point for the player when the level is reloaded.

Sub-Levels

After the demo, I figured I needed to find a way to block off the way back to prevent players from backtracking. I also wanted to supplement that with a way to design large levels that are optimized.

Introducing the chunk system. Checkpoints now act as not just checkpoints, but chunk loaders. Each red cube represents a checkpoint for a chunk. Blue cubes are just triggers that send you to the next chunk.

When you collide with a new checkpoint/chunk loader, it sets you respawn location at that chunk, and unloads the previous chunks to save resources.

This system comes with another advantage: planning. There is another concept I'm borrowing from the Playful Production book called a game design macro. It's basically a spreadsheet or a flowchart (I plan to make mine a flowchart in my wiki) detailing the intended experience of each scene in the game (my terminology may be a bit off, but hopefully that gets the general idea across). This chunk system gives me even more granularity for my game design macro. For the introductory level, it currently looks something like this:

Forgotten Cliffside
	For each chunk, lighting gets progressively darker to signify passage of time between chunk transitions
	Quarter 1: Hero
		Chunk 1: easy encounter
		Chunk 2: medium encounter
		Chunk 3: hard encounter
		Chunk 4: meeting Maria, dialogue
	Quarter 2: Maria
		Chunk 5: easy encounter
		Chunk 6: medium encoutner
		Chunk 7: hard encounter
		Chunk 8: meeting Kiwi, dialogue
	Quarter 3: Kiwi
		Chunk 9: easy encounter
		Chunk 10: medium encounter
		Chunk 11: hard encounter
		Chunk 12: meeting with Ebo, dialogue
	Quarter 4: Ebo
		Chunk 13: easy encounter
		Chunk 14: medium encounter
		Chunk 15: hard encounter
		Chunk 16: meeting with the rest of the cast, dialogue
	Transition into first campfire level

This form of planning gives me a modular way of designing levels. If I want to remove or restructure certain chunks, I won't have to re-design the whole level. I can just swap things around, or completely remove things that aren't serving the game. I will try this approach for the vertical slice, and decide if this is the framework I want to go with for the rest of the game.

Dialogue Framework

This is what I am currently stuck on.

Not much to talk about here, unfortunately. This is the last puzzle piece before I can start digging into the vertical slice level, The Forgotten Cliffside. It was low priority anyway, so it's a good sign that this is currently the only system stopping me from creating a fully fleshed-out introductory level.

Like I mentioned in the previous dev log, I settled on using the Defender Dialogue Framework. I am currently having some issues integrating it into the current FM project. Hopefully by the time I begin writing the next dev log, I will have resolved that problem.

Conclusion

Overall, I feel like I made some solid progress since the last update. Despite this dev log being a bit shorter than the previous ones, it was packed with FM progress. It was also somehow the hardest one to write.

TRY THE LOG 2 BUILD HERE (link broke for now)

TRY THE MAY 21ST DEMO BUILD HERE (this one too. all demo links are broke right now. I will reupload mirrors soon-ish)

P.S.

Check out this cool Python snippet I wrote.

FM - Log 1

Mon, 29 Apr 2024 00:00:00 GMT

I strongly suggest reading dev log 0 first if you haven't already.

This is week, uhh… 1, of working on Forgotten Memories? I said I was going to try to make this a weekly thing, but it looks like I failed. I guess it will be a monthly thing.

I didn't realize before embarking on this dev log journey how many hobbies I already have that I need to juggle. I thought I could pump these out every week or every other week. What was I thinking? I don't think it's possible to make these dev logs a weekly thing, because I can't reasonably make enough progress in a week that's worth sharing. Plus, writing these logs can also take a while.

Now that I got that out of the way, let's dive into some cool things I've been doing for this past month!

Procrastination

I spent most of the time procrastinating.

I know, very anti-climactic. I could have been cooking for an entire month, but I haven't been.

But that doesn't mean I haven't been doing things. Like I said earlier on this page, it turns out that I have a lot of hobbies I need to juggle, and I can't exclusively focus on game dev-ing this game after work hours.

But honestly, that seems like a copout. There have definitely been evenings and weekends when I know I could have sat down to work on this damn game, but decided to do other things instead.

Procrastination is going to be a lingering topic throughout this entire dev log. I didn't write it like that to beat myself up though. I'm simply hoping to provide some insight for myself (and hopefully you, my dear and wonderful reader) into why we often procrastinate.

Cozy Campfire Scene

One of the core pillars of Forgotten Memories that I've been planning since I came up with the concept for the game are the campfire segments. These are supposed to be the intermediary levels between the core gameplay levels, which are meant to be difficult and stressful. The intention is to give the players a chance to wind down and prepare for the next level, while seamlessly providing exposition for the main characters as they also wind down and talk to each other.

The first thing I did for FM this month was to begin prototyping this campfire level. You can preview it above (warning before clicking: it is very cozy). The fire is a simple placeholder niagara particle effect, and the firewood is just Unreal's cylinder primitives. I'm more proud of the point light on the campfire actor. The light fluctuates in intensity, just like how fires do in real life, but I also added a little randomized offset to its position to make the shadows move around slightly. You can see that in the video. It didn't take a lot of time to make, but it was an easy and fun way to begin laying out the framework for those campfire levels.

Those orange arrows you see are indicators that these characters can be talked to. I'll get into dialogue…

Dialogue Framework

…now.

For a while, one of my biggest sources of procrastination was the Epic Marketplace. Pretty early (2 years ago, when I was just starting the Unreal Engine prototype), I knew I wanted to have a dialogue system, and I knew exactly how I wanted it to look like.

Gameplay levels: minimal dialogue that very rarely interrupts gameplay. Occasional barks coming from significant enemy characters to give them personality.

Campfire levels: interactable NPCs with some simple dialogue branches, followed by acted out cutscenes that progress as the player clicks through a mostly linear conversation.

Cool, I knew what I wanted. Now, one thing I knew for sure: I did not want to write an entire dialogue and cutscene framework from scratch. It would have been a very poor use of my time, which I've grown to value a lot more as I found myself balancing hobbies for the past few weeks.

"I'll just go to the Marketplace and buy one," Vlad said to himself, "I just have to pick one and not get stunlocked by analysis paralysis!"

You'll never guess what happened next (click to reveal spoiler)

I got stunlocked by analysis paralysis.

There are a lot of dialogue frameworks on the Unreal Marketplace, and picking one that was A) within my budget, and B) did exactly what I needed it to do, was nearly impossible. I was scared to death of buying the "wrong" dialogue system. What if the one I purchased proved to be underpowered, and I had to buy another one? I would have felt so terrible about wasting my money.

So naturally, I put off making this decision for as long as possible.

But a few weeks ago, as I set a block of time to commit working on this project, I revisited this exact problem. This time, I was going to pick a dialogue system once and for all. That was the only goal for my session that evening; anything beyond that was just bonus objectives.

And what did I pick?

TA-DA!

This one. It has all of the features I was looking for. And the best part is: it cost me absolutely nothing!

Epic likes to give away a bunch of Marketplace assets for free every month. I have been claiming those for years every month, without fail.

I am also a long-time subscriber of Humble Bundle, and I check all of their game, software, and book bundles in case I see anything interesting.

Essentially, the choice was already made for me. I must have claimed this dialogue system in one of those monthly Epic giveaways, or I had it bundled into one of those Humble Bundles. This meant that I had a risk-free way of trying to integrate a premade dialogue framework into my prototype.

However, this also meant I couldn't use the lack of a premade dialogue system in my possession as an excuse to procrastinate anymore :(

Warning: My stance on AI
I figured it was very important to mention here, as you'll see some AI generated portraits in this preview.

I've been following the AI art discourse for a while. I think in its current state, the use of generative AI models comes with some serious ethical issues that need to be addressed. As far as my use of generative AI goes, it's either to fuck around, or to get some placeholder assets into the engine. I never have, and never will, claim AI generated art as my work.

I believe it's fine to use for brainstorming or for personal projects. If this project ever becomes anything more than my pet project, I will remove all AI assets and un-taint it by replacing them with human-made assets.

Now that I got that disclaimer out of the way, you can see the dialogue system in action. I spent a few hours integrating it into the project, tweaking UI colors, and shearing a few other features that I won't need. This framework doesn't just give me the features I need: it gives me more than I need!

I'll need to dive into it deeper at some point. I need to figure out how to create branching dialogue. It's doable; I saw it in their provided demo scene. I just don't know how yet. I will also need to find a way to do a dialogue → level sequence → dialogue type of event. I don't know how I'm going to do it, but I think if I really sit down and dig into it, I'll figure it out. It's such an overpowered framework, honestly. It even allows you to trigger events through dialogue. I think I'll be able to get some use out of this in the future.

Anyways, here's a build of a conversation that will crash the game.

From this point, I decided to pop the brakes on the dialogue for a little bit, and instead focus on the main gameplay loop first, because I figured it's more essential to nail down first.

But before I did that, I went on another procrastinatory tangent.

Ludum Dare 55

Holy shit, let me just start off by saying that I do not miss doing short-term game jams. The toll they take on my mental and physical health is nothing to scoff at.

But let me follow that up by proudly announcing that during the weekend of LD55, I made one of my greatest jam games! It's called The Unsummoner.

The basic gist is that: you play as a janitor. A local necromancer went mad and committed an unhinged spree of summoning a bunch of undead in a crypt. It is your job to clean up the mess by un-summoning these summons. You do that by summoning ethereal guns. The theme for the jam was Summoning, if you couldn't already tell.

I did this jam with my programmer friend, Joel Hanson. I was responsible for game design and art. So unfortunately, I didn't code the super cool "drawing sigils to spawn guns" mechanic, but I made all of the visual things you see.

Anyways, this log isn't about The Unsummoner. If you wish to read about my experience with this jam, you can read about it The Unsummoner - My Contributions|here (if the link is gray, that means I haven't written the article yet).

This jam occupied an entire weekend, from Friday night to Sunday night, and even the evening from Monday. There was no way I was putting in any hours into FM that weekend. I'm still on the fence whether I should consider this another form of procrastination or not, but if it is a form of procrastination, then it's a form of procrastination that I'm okay with.

For me, game jams are an excellent way to put my current arsenal of skills and resources to an intensive time-limited test. Even if the final outcome doesn't come out the way I wanted it to, I still walk away with a ton of useful insights about my tools and processes.

Shortly after jams, I write down some notes in a post-mortem style to document what went well, what went not so well, and where to go from here. You can read my unfiltered notes on this jam The Unsummoner Post Mortem Notes|here.

Tip: Most valuable insight I had from this experience
• I didn't do the best job of prioritizing tasks and implementing things. I noticed that there are certain things I wanted to do from the beginning, like giving the FPS hands a black drape, but I procrastinated on that. And at some point, I had moved on to other tasks and completely lost momentum on the FPS hands, so the hands remained bare forever. I can think of a few more instances where this thinking led me to not implement things that could have been beneficial to the game. In short, sometimes it's better to execute the idea I want to do now rather than to put it off for later, in fear of missing the opportunity to do a cool thing.

The main idea is: I already do a very good job of spotting opportunities, both in real life and creative endeavors. But I need to do a better job of taking advantage of those opportunities. Sometimes I procrastinate on that because I have blind faith that another equally or more valuable opportunity will come along.

Here's the harsh truth that I had to realize: sometimes these opportunities don't come again. By procrastinating on once-in-a-lifetime opportunities, even if it's something as trivial as a tertiary detail in a throwaway game jam game, I'm ~~fucking myself big time~~ stagnating my growth because that mindset transfers to bigger once-in-a-lifetime opportunities in the real world.

Honoraball

To continue my procrastination streak, I began working on a prototype for Honoraball. I swear, I will do anything but work on FM.

The high-level idea is:

Honor: what rhymes with honor? Samurai.

Ball: what rhymes with ball? Basketball.

Essentially, the idea is about a bunch of samurai duking it out on the basketball court. The idea is to score points within the framework of a typical game of basketball, except the players are allowed to slice each other to pieces. I came up with this idea about a month ago, but procrastinated starting a prototype until about 2 weeks ago.

My first evening of working on Honoraball was quite productive! I started with the most essential mechanic for a basketball game: the ball and the hoop. The player can pick up the ball, and as they get closer to the hoop, their chance to score increases. This is the percentage you're seeing in the video. I had this mechanic solidified in my brain when I programmed it, so it was a pretty smooth ride. Beyond the 50% threshold, you're scoring 2 points. Below 50% though, you have a higher chance to miss than you do to score, but if you score, it would be a 3-pointer.

Day 2 was quite productive too. I refined some systems that I programmed on the first day to make them more modular and scalable, then juiced up the throw mechanic by making the ball actually fly at the hoop when thrown.

Things were going pretty smoothly with the prototype as I was knocking out tasks that I already knew how to handle. However, from the beginning I knew that handling teammate and enemy AI would be a monumental task. AI programming is one of my weakest areas in gameplay programming, and I didn't even know where to begin.

After a long session of weighing my options (5 minutes), I decided to put Honoraball on an indefinite hiatus. I've only worked on this project for 2 evenings, so I didn't feel like I was committing infanticide (the article is about writing, but I find that this concept applies to many other creative fields).

I still think it's a cool concept and I want to continue it some day. But even though it will remain unworked-on for a while, and it was yet another source of procrastination from working on FM, it taught me one very important thing. I got a lot better at video game programming over the past 2 years. I was knocking out tasks like it was nothing! Those 2 evenings working on Honoraball were spent in the state of uninterrupted flow. I wanted to see if I could transfer that feeling to my Forgotten Memories sessions.

More FM

Finally, we're getting back to the juicy part of this log - actually working on Forgotten Memories.

After updating the project to 5.4 version of Unreal Engine, I finally opened it up. I was excited to work on the game after all of the insights I obtained during these tumultuous weeks, when I wanted to do anything but work on FM.

It was right there and then that I understood why I didn't want to work on FM.

Refactoring

2 years ago, when I was figuring out the frameworks for the game, I was cooking! I was cooking spaghetti. Spaghetti code. The things I wrote should be considered crimes against humanity!

Turns out, my biggest source of procrastination was the overwhelming fear of confronting the shitty code I wrote years ago. And when I say it was shitty, I mean it.

Say hello to the BP_FMGameMode blueprint. If you're an experienced Unreal dev, you might be wondering, "why does your gamemode blueprint have an event graph? Isn't it supposed to be a data-only blueprint?"

It's a valid question to ask, and you are correct, it is supposed to be a data-only blueprint. Here's my justification at the time. I plan to have 4 distinct main characters. They are their own unique actor blueprints, even though there is a lot of overlap within their core behavior. It didn't occur to me at a time that I could make a BP_FMCharacterBase blueprint with the behavior that would be shared across these characters, and make these 4 characters children of that blueprint where I can detail character-specific behavior.

Instead, I decided to put all shared logic into the gamemode blueprint. If there's ever an instance of the main character taking damage, it gets cast to the gamemode blueprint. Same with any adjustments to the blood meter.

This is pure garbage. All of this logic should just be handled in the main character blueprint. I just had to commit a few hours and actually sit down and re-wire everything. The tricky thing is, I already knew what I needed to do and how I was going to do it. I passively obtained this knowledge not from coding, but from a solid year of doing game jams alongside Joel Hanson. By actively observing his coding process and asking stupid questions, I was able to pick up on a few game programming techniques.

It took me a few hours to re-write this shit, but they flew by because I was able to replicate the state of flow that I had while working on Honoraball. With the spaghetti finally untangled, I am happy to announce that I no longer dread opening the Unreal project for Forgotten Memories!

Trello Board

I made a Trello board. I've tried to set up a task tracking board for FM in the past, but I couldn't stick to it. The first one was in Notion. The second one was in Obsidian using a community plugin called Projects. Neither of those have stuck. I'm hoping that I'll have better luck with Trello.

I wanted to make a Trello board because when I was browsing the Unreal Marketplace (a tried and true method to procrastinate), I saw this plugin called Ultimate To-Do list. I noticed that it has direct integration with Trello, and other task-tracking programs like YouTrack and Asana. I haven't bought the plugin yet because I don't see a need for it for now, but it inspired me to make and maintain a Trello board in case this plugin goes on sale and I find myself wanting to integrate it into the FM project. I figure it will be pretty useful if I plan bringing other people on board.

In the meantime though, feel free to check out the board. I intend to keep it updated with the latest tasks I'm working on.

Zombies

The zombie enemy has been a long constant in this project. The logic was created by following a behavior tree tutorial I watched about 2 years ago.

Welcome to the Enemy_AI_Stuff folder. It's a hot mess. I clearly didn't go into this with a lot of foresight. The blueprint for the zombie enemy is even named BP_TestEnemy. I figured the most productive thing would be to delete this folder entirely and start from scratch. The only thing I preserved was the death logic for the zombie, where they create a blood VFX and ragdoll when they die.

Programming enemy AI is a whole can of worms. And I opened it. In order to have a vertical slice worth playing, I need to lay the groundwork by having at least one enemy type that feels balanced and fun to fight. Zombies are stupid: they beeline at the player, and strike when they get close enough. Hopefully by getting just one simple enemy type right, I will open up the pathway to creating other, more complicated enemy types that feel equally as fun and balanced. I expect that getting the zombie AI just right to be one of my main tasks in the next few coming weeks.

Other Things

The blood is red again. Yippee!

I added a red box as a visualized for the attack hitbox. I don't know, I think it will be useful for debugging and balancing. It can be toggled on and off.

I added a main menu so you can try different levels in the future builds. Each level is like a self-contained prototype.

Deadline

I have a deadline on May 21st. It's a soft self-imposed deadline though. No one will fire me or murder me if I won't make it. The worst that will happen is I'll be a little disappointed in myself. There will be an open demo night, and I intend to bring a playable demo of FM there. This deadline will force me to prioritize some tasks over others. Some of them may not be as fun as others, but that's ok. As long as I can stay in a state of flow for a prolonged period of time, I have confidence that I can knock them out one by one.

While I think my idea for Honoraball is baller (pun intended), I need to pick one project to focus on for the deadline. I think Forgotten Memories is a much better target for that. A) it's mechanically simpler. You go from point A to point B while killing some enemies in between the points. B) I have a dev log series dedicated to it, so there's another source of external pressure that makes me want to work on it.

Conclusion

This past month has been an odyssey of procrastination. I spent the majority of the month being a victim of it. I think by laying out my experience with it in this dev log, I have a better understanding of the triggers and other internal processes that lead me to procrastinate.

Procrastination is a pretty universal experience, especially in the creative field. There are many reasons why we might procrastinate, but I believe they are all rooted in fear. Irrational fear of the unknown. The fear that the outcome of your labor may not align with your vision that you've grown so attached to.

It's a very uncomfortable feeling, but if you can't push through it, you're going to spend more time daydreaming than creating. It gives you an illusion of progress because you may be inclined to count the time you're "thinking about the project" the same as the time you're actually working on the project. This is a mental trap, one I've fallen into far too many times. The only way I found to avoid this trap, is to push through that discomfort enough times until it becomes easy. It does get easier, but you have to do it enough times before it starts to get easier.

TRY THE LOG 1 BUILD HERE (link broke for now)

P.S.

If you read [dev log 0](/blog/fm-log-0), you may have noticed this "plan for next week" section at the bottom of the page. I'm not doing this again. A lot of these were game design wiki focused, and the wiki is internal. If you'd like an update on the tasks, you may check out the public [~~Trello board~~](https://trello.com/b/1IhacekX/forgotten-memories).

UPDATE: the Trello board is dead.

Also damn, I expected this log to be shorter than the first one. But it turned out to be just as long, even though I procrastinated for the majority of the month. I'm either an excellent yapper, or I did more than I thought.

FM - Log 0

Sun, 31 Mar 2024 00:00:00 GMT

This is week 0 of working on Forgotten Memories. I'm going to try to make this into a habit, with a deadline of Sunday for every week.

The idea behind Log 0 is to document everything that has already created for FM up to this point. I worked on the game about two years ago, but had to put it on a hiatus due to real life struggles. Because my current real-life situation isn't as dire at it used to be, I'm resuming development.

Initial Idea

All great things start with a simple idea. During my senior year at WPI, I remember playing a ton of The Binding of Isaac: Rebirth in my free time. I was in the middle of a vigorous achievement hunting campaign. At some point, I had to unlock a hidden character named The Forgotten.

What was special about this character is, it's the only one in the game that has a melee attack. Normally, characters shoot tears in the direction of the arrow keys (or the right stick if you play with a controller). The Forgotten, however, swings a bone in a wide arc in front of him like a sword. The attack key can also be held to charge up a bone throw.

(note to self: get better gameplay footage. preferably where I don't get hit because this makes me look like a scrub)

I found this mechanic to be incredibly satisfying. The attack felt impactful because it did a lot of damage and could hit multiple enemies at once. Fundamentally, The Forgotten was the main inspiration for Project Forgotten. It was even named after him.

Project Forgotten

Project Forgotten started with a brainstorm, as most projects do. I dug this note up from Google Keep. My collection of Keep notes is a wasteland of bad memories and psychotic ramblings. Let's just say… I'm glad it has a search function. The screenshot to your left is just a snippet of the note. Project Forgotten Brainstorm Note|Here's the full thing if you wish to read it. You don't have to read it to understand where the idea stemmed from. In fact, I'm about to sum it up in the next paragraph.

At first, the idea was to make a game about a samurai who wields a katana. The control scheme would mimic TBoI, specifically how The Forgotten character works. WASD for 8-directional movement (omnidirectional with a controller), and arrow keys for attacking (also omnidirectional for a controller). Then I expanded on that concept by adding four stances that you can switch between: Butterfly, Bull, Spider, and Hawk, each with their own benefits and drawbacks. This concept didn't last very long because I thought it was bland and short-sighted. Instead, I decided to create 4 original characters with their own strengths, weaknesses, and unique abilities.

Above is a doodle of these 4 characters that I made on a whim. It's a man, a woman, a monkey, and a robot. That's all you need to know about them for now.

Unity Prototype

I started making a prototype pretty early to figure out the movement and attack mechanics. Unfortunately, some early development gifs and videos are lost to time, but I still have some snippets showing off the prototype in its latest and most feature-complete forms.

Movement & Attacking

The first thing I figured out is movement and attacking. The video above shows those in action. It's a little choppy and the materials are broken, but hopefully it gets the point across. When the characters attacks in a certain direction, they start facing in that said direction, and their view lingers there for a few seconds. After that, the characters starts facing the direction of movement. This took a while to figure out because I had to use a lot of 3D math to make this work. I remember it being a big challenge, but one I felt very accomplished about overcoming.

Blood System

Even in the very early prototyping stage, I wanted this game to be very bloody. I grew up watching Tarantino films; I can't help it. So I got working on the blood system. In the video, you can see the blood spurting out of the enemy as it's struck by the slash attack. The blood particles land on the ground and gradually disappear. I followed a tutorial 1:1 for the blood particles shooting out, so I knew I was going to remake that eventually. The main character also gets covered in blood, which drips off them quickly. I made this effect with a combination of a shader material (the color red covering the character model) and a particle effect (blood droplets falling from the character).

I was pretty satisfied with the result, but I had another idea. What if the amount of blood coverage on the player influenced gameplay in some way? You may have noticed the red bar on the left with a yellow line a third way from the top. This is the blood coverage meter. It goes from 0% to 150%, and the yellow line indicates the 100% point. I thought it'd be interesting to make the blood coverage be equal to the chance that the player will be able to ignore an attack made at them. An important piece of context is that the character dies in one hit, like in Hotline Miami, another prevalent inspiration for this game. So for example, if the player is 20% covered in blood, they will have a 20% chance to mitigate an attack that lands on them. If the player is above the yellow line (100%), that means that they are basically impervious to all attacks until blood goes down. The idea behind this mechanic was to make a gameplay structure that incentivizes aggressive play. The more you kill, the less likely you are to die.

That's it.

This is where the history of the Unity prototype ends. I was also working on writing a dialogue system from scratch, but I abandoned that endeavor because it proved to be too difficult. And also because there's a Unity addon that does this better than I ever could.

At this point, I had a clearer vision of the game that I wanted to make, but I have been using Unity for years and have developed several grievances towards it. I wanted to move to another engine to continue development.

Unreal Prototype

This marks the beginning of the Unreal Engine 5 prototype. I've tinkered with UE 4 back in high school, and I always liked the Blueprints visual scripting system. I also liked that Unreal makes prototypes look good without any sort of settings or tinkering. There are more reasons now why I prefer Unreal Engine to Unity, but starting this prototype from scratch in this new engine gave me the motivation to finally learn Unreal in greater depth.

Recreation

After hours of coding and troubleshooting, I was able to make a 90% faithful recreation of my Unity prototype inside of Unreal Engine. You may notice a few differences in the video above, but they are all graphical; the gameplay mechanics remained the same. I will explain the visual development of the Unreal prototype in the following sections.

New Blood System

One of the first things I wanted to rework was the blood system. Mechanically, it works the same; 0% - 150% scale, invulnerability, blah blah blah. I decided to make it cyan to make it a little bit more tame and presentable for my portfolio page when I was applying for game dev jobs. I will make it red again at some point. You may also notice the new character model. This is supposed to be the woman from the earlier doodle. I will have more to say about her later.

I wanted to make the blood mechanic feel messier and gnarlier. One big change is that the bloodstains on the ground are now permanent. They are created when the blood drops collide with the floor and instantiate a plane that hovers slightly above the ground with a randomized splatter texture. This is surprisingly performant, but at some point I'll have to figure out a way to cull them when the player moves to a different area on the level. Another big change that I was very proud of is that not only does the blood drip from the player passively, it shoots off blood particles in the direction of the swing. Also, this character has a robotic arm that doesn't get covered in blood even when the meter is full. This was intentional.

Enemies

You may have noticed a few zombie-like enemies shambling around in these videos. Well, "may have noticed" is a bit of an understatement. They're pretty hard to miss. The zombie is an enemy that I've planned back in my original brainstorm for the game. It's a slow humanoid thing that stumbles at the player slowly and attacks when it gets close enough. I never programmed the attack mechanic though, so right now they just sort of… beeline towards the player endlessly.

The video above shows another type of enemy that I plan to have. They have a ranged attack that never miss the player. The particle balls firing off from the enemy are there to signify a shot being fired. For the sake of the demo, it only hits the player if they're close enough. Here, you can also see the blood mechanic nullifying some hits that would have otherwise killed the player.

The death visual effect is another thing I carried from the Unity prototype that wasn't shown. I think it looks cool, but it's very hacky. There's no easy way to change the landscape material in Unreal at runtime, so I spawned a gigantic flat plane slightly above the surface (the same way I did the blood splatters) and gave it a black unlit material. Every other element like the characters and visual effects are switching to a white unlit material. Overall, I like the way it looks, but there has to be a much better way to do it. I think a custom post process material is the way to go.

That's it… for now.

I don't have anything to show off in regards to either of the Unreal and Unity prototypes. My next step will be to begin implementing story-telling frameworks, like I tried with Unity at some point. I won't be writing my own dialogue system from scratch, though. I'll buy something pre-made from the Unreal marketplace and try to push it to its limits.

Character Designs

Shoddy prototypes aren't the only things I've been putting together! Over the summer of 2022, I teamed up with a concept artist Abigail Rauch who helped me flesh out some character designs. She sketched the designs for every character, but we ended up making the most progress on the woman and the robot.

The Robot

The robot's design was fleshed out the first. Turns out, robots are pretty easy to design. You don't have to adhere to the strict rules of human anatomy. I have a lot of experience with 3D modeling & sculpting, but I'm pretty bad at making humanoid characters. If you get one little detail off, the whole character looks wrong. There's a phenomenon called the uncanny valley that might have something to do with it (which has terrifying evolutionary implications, if you really think about it).

Therefore, the robot was a no-brainer to design and model first because it's not a human. Getting easy tasks out of the way first helps maintain momentum to tackle more complicated tasks later. I think Sun Tzu said that. Game development is a war, and I am God's strongest warrior.

3D Model

This is the robot character that I modeled doing the default Fortnite dance. The shoulders are out of place, but that's because I messed up the animation retargeting process. In reality, the rig deformed just fine. You can see the controls on the right. I take my rig organization very seriously! I was responsible for modeling, texturing, rigging, and animating it based on the concept art that Abigail provided, though with a few adjustments. I had my own vision of this character that didn't exactly line up with her rendition, but I think that's on me for not communicating that vision sufficiently enough. At this point, these characters barely had any personalities or backstories; they were merely shells that I thought would be cool to tell a story through. Not the story, mind you, a story. I still had no idea what I was doing beyond my Project Forgotten Brainstorm Note|initial brainstorm.

Here's some early footage of trying to implement the robot's model and movement animation into the Unreal prototype. If you look closely, you can see the UV seam on the top of his head. This was a texturing goof that I eventually ironed out. Power of the iterative process, baby!

And here you can see him going ham and swatting away zombies, with his signature cape that was drawn in the concept art. Yes, they're pink. Yes, they're also slowly sliding at the player menacingly with malicious intent. The robot's animations were implemented before zombie animations, and even the blood mechanic.

The Woman

The woman was a little trickier to figure out. One of my pre-requisites is that she's missing an arm. Clearly I failed to communicate that too, judging from the concepts, but I've been actively working on my communication skills. My current landlord is a horrible communicator and a perfect example of what *not* to do. I've been taking notes!

Anyways, back to the character. At this stage, it didn't really matter to me whether it was the left arm or the right arm. All I knew is that I needed a character who didn't have an arm, and it needed to be a human woman. It also needed to be a blondie with some sort of a vaguely technological-looking staff.

When summer was over, [Abigail](https://abigailrauchportfolio.com/) had to step away from the project to focus on college, so I sought out help from another concept artist and a fellow WPI graduate - [Janelle Knight](https://linktr.ee/stallout). Above is a concept that [Janelle](https://linktr.ee/stallout) refined. The model you may have been glancing at below is based on this concept. Sadly, the collaboration with [Janelle](https://linktr.ee/stallout) didn't last very long because I had to halt development at some point. She was only able to refine the concept for the woman character, and some other miscellaneous concepts that you'll see later. Alligator.

This is the furthest I got with sculpting the woman. It honestly wasn't a bad model at all! Except for the face... stuff of nightmares. Remember what I said about humans looking off when you get one small detail wrong? Here's a prime example.

Eventually, I retopologized this, textu- the same process I ran for the robot, basically. The textures were a lot more "makeshift," for the lack of a better term, but they sufficed for the prototype. By the way, if you were wondering who the character in the early Unreal prototype videos was (the one with the mechanical arm that doesn't get covered by blood), this is her. One of the videos showed this model with broken UVs. Can you figure out which one it is?

Here's a video of me stress-testing the rig. I was very proud of the mechanical arm. The model wasn't very good, and neither was the rig, but making them gave me an insight into how to blend organic elements like human bodies with inorganic ones like machinery.

If you look closely, you'll see that the robotic forearm has two metal rods. I challenged myself to replicate the way the radius twists around the ulna in a human arm, and after bashing my head against a wall for hours, I succeeded. This rig and model will be scrapped, but this knowledge will be very helpful when I begin modeling the second, and hopefully final, iteration of the woman character.

The Monkey

The monkey was one of Abigail's favorites to doodle. It's a meat cleaver-wielding menace. My only pre-requisites for this character were that she (it's a female monkey; very important detail) is wearing a mask that allows her to conceal her identity. I wanted this to be a rogue-ish character.

She also must wield an unwieldy weapon that's like twice as long as her, like a meat cleaver taped to a long stick. This is what you're seeing in the concept art.

This is a WIP screenshot of the model for the monkey character. Coincidentally, it was around this time that I needed to halt development to prioritize real-life issues. It will forever remain unfinished. Rest in peace, shitty unfinished model of a meat cleaver-wielding monkey :(

The Man

This is all I have to show for the man. Remember the original brainstorm idea of a stance-switching samurai? This is him. He is that guy. Unfortunately, at this stage of development, he was the least fleshed out. The concept art above (and my doodle from a while ago) are everything that exist of him from that time period. However, I want to emphasize that this was not [Abigail's](https://abigailrauchportfolio.com/) fault; I had no idea what I wanted to do with this character anyway, so we decided focus on the other characters first hoping that some inspiration for the man would come. The inspiration never came before I had to halt development.

Though I will say this, as a little teaser. Narrative-wise, he's currently the most fleshed out character of the four, by far (the woman is closely behind though). I'll share more when the time is right.

Zombies

Janelle also made some concept art for the zombie enemies. The animated models you saw in the demo videos earlier were based on this concept. I didn't spend too much time or effort on the sculpts and models; I simply used a human basemesh and sculpted in some malnourished details. The arms are criss-crossed because of an animation retargeting error; not the first time that's happened.

Instead, I focused more on the material. I came up with an idea of making their material procedural and slightly randomized with each instance of the zombie. Do you see the cuts on the concept above that emanate a cyan glow? I wanted those cuts to be randomized, with several layers of human parts visible below the skin that's transparent. So the surface level would be skin, and below that would be flesh, and below that would be the bones.

To this day, I still think it's a good idea and that I can pull it off if I put in time and effort. It's just that back then, it was very low on the priority list, and it will probably remain that way for a while because it's such a tertiary feature.

Environment

We had some environment concept art too! Above is Janelle's work. My direction for the building was "a steampunk dilapidated factory-looking building emanating cyan smoke." On the right you can see a refined and rendered concept.

I began modeling it, but unfortunately never got around to finishing it. I still have the .blend file, so I'll be able to pick it up without any hiccups if I ever decide to do so.

Here's a badass concept drawn by [Janelle](https://linktr.ee/stallout) portraying one area from the game, the City of Nightmares. This piece was not as detailed as the concept of the building above, but it allowed me to get a general idea of how the area would look like with finished building models. And here's another concept, equally as badass, portraying another area, the Forgotten Cliffside, in similar vein to the city concept above.

Design Wiki

My latest effort toward making Project Forgotten a reality is designing a wiki website inside of Obsidian (the same app I'm using to host this website) that details every entity of the game and the fictional world within it. It's a colossal work in progress as I'm very quickly finding out which things work well, and which things work not-so-well. The wiki is hosted online, but it's not indexed by search engines and is password-protected. It's only meant to be used internally.

The idea behind the wiki is to serve as the definitive design bible that people collaborating with me on this project can use as the true point of reference. I anticipate for this to be very useful in the long run as I won't have to explain something multiple times to different people; they'll easily be able to find all the details they need on the wiki. It's my job as a game designer to make sure that the pages are concise, but detailed enough to sufficiently get the idea across.

The progress on the wiki has stalled recently. I think I can remedy that by working on the prototype instead, which will be my focus for the next week.

And that's actually it… for now :)

Writing this dev log was very cathartic. It was a nice trip down the memory lane, even though the trip was confined to the development of a single obscure game prototype. Future dev logs probably won't be as long and detailed as this one because I won't have as many memories to recall.

I'm currently reading a book called A Playful Production Process by Richard Lemarchand. It's been giving me some great insights into the game production process, from ideation up until post-production. My history with game dev is pretty technical, and unfortunately I didn't manage to get any production experience. The book has been a pleasant read so far, and I'm hoping I can extract and apply more insights out of it as I continue getting through it.

TRY THE LOG 0 BUILD HERE (link broke for now)

Plan for next week:

Begin working on the dialogue & cutscene framework for the Unreal prototype
Keep reading the playful production book
Work on the wiki:
- Re-write Hero's backstory
- Write Sujin's backstory
- Write the campfire conversation between Maria and Kiwi