FM - Log 2

Old Unreal Engine 5 dev log

June 3rd, 2024
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:

1. Don't tell the players where to go, whether they're doing anything wrong, or how to play in general.

2. 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:

1. 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.

2. 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 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.

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.

P.S.

Check out this cool Python snippet I wrote.