Another year of the So Bad Its Good game jam has come and gone! Time flies when you're having fun I guess. I admit I'm still kinda in disbelief that I actually managed to submit this year, I worried that even with my intention of a smaller scoped game I'd still end up screwing myself. But I managed to pull through and even ended up in the top 5 (!). Here's the exact ratings and their distribution for those curious:

 I'm honestly more happy with the fact that I actually submitted than I am with the ranking. 2021 is officially my most productive year for game development, I've now released two projects in a little over half a year. Sub Mortis, my continuing attempt at a serious horror game had its first demo released in January, and of course Stalewater was released on June 6th.

Addendum: This number is actually now three with Mons Badonicus, but my point stands even more now.

Now that I've received a wealth of feedback and I've had time to reflect on it, I decided to write up another post mortem. Much like with the one I made for Ja Wizardman I'll be discussing the ideas I had for Stalewater, what influenced it, what worked well and what didn't. I'll also talk a bit about ideas that were left on the cutting room floor, what lessons I learned from Stalewater, and what I plan to improve upon in the future.

The Concept

The idea for Stalewater originated from an educational game concept I came up with before the jam started. It was supposed to focus on a small town where the player would walk around and be given inaccurate or humorous info about life in the old west by a popup info window with a little character and some crappy voiceover. The theme of "One Button" ended up not really fitting this concept, and I figured that since education wasn't the modifier I should probably experiment with other ideas. I found myself unable to shake the western theme though, so I decided on making a crappy western FPS. First-person games are the ones I have the most experience with, and I didn't wanna rock the boat too much lest I have a repeat of Ja Wizardman's development.

The idea of keeping it set in a small town also stuck. I didn't want to repeat the mistake of trying to make a large game, so I decided at the outset to focus only on the town of Stalewater with the addition of the final boss' fort. I wanted the game to be small so I could focus on quality over quantity, and I didn't want the player to be running around a huge map hunting down objectives. Since Stalewater was supposed to be basically a ghost town with no one but criminals around, I decided to strip it down even further and have just the absolutely necessary buildings. Those being the marshals office/jail, the range, and the saloon, because what Western doesn't have a saloon in it somewhere? This small scale meant it was quick to model, script sequences, and traverse. It also made a much lower impact on performance compared to the open valley of Ja Wizardman and the city blocks of Out Of Order.

The game came from a mix of influences. The most prominent are Oblivion, Fallout,  and Red Dead Redemption. I had the idea for making talking NPCs similar to Oblivion for a while, the stilted, creepy facial expressions always struck me as "so bad its good" that I had to put them in a game of my own. The Fallout influence is obvious from the opening cutscene with the ominous music and narration over still images and short animations. It also appeared in the shape of the combat system, where you have to manually reload and can holster/draw weapons on command, some of the weapon draw animations even look like something out of Fallout 3. The Red Dead influence is obvious from the fact that Stalewater is a western, but also the fort is based off the fort encounter from Red Dead 1 and some of the vocal intonations for the final boss are based off the main character of Red Dead 2.

The less obvious influences come from some more obscure games like Gun and Call of Juarez, the Looney Tunes cartoons, and one of my favourite childhood shows: Reboot! Gun was a western shooter I played in my childhood, it provided the idea of using whiskey as a health item and some other cut features I'll talk about later. Call of Juarez was a janky western FPS that had some interesting mechanics, like the ability to equip a bible and shout scripture, or awkward dueling encounters where characters who say they're going to kill you suddenly teleport to the opposite end of the room so that you can duel them. Call of Juarez also had many first person cutscenes where black bars would pop up and your character would look in certain directions with your camera tracking an NPC's movement. I liked this rather simple system for scripted scenes and figured it could work much better than trying to place another camera in the world or making an animated cutscene for them. Call of Juarez was also a late 2000's game, which meant it had ridiculous ragdoll effects. Sadly, the ragdoll effects in Stalewater are rather tame in comparison. Looney Tunes was an influence through the sound of the feet when running being all wacky and the general absurdity of the game, and there's definitely more than a little Yosemite Sam DNA in Moustachio.

The Reboot influence is perhaps the strangest part, it was a Canadian fully 3D animated cartoon from the 1990's and early 2000's. And man, it was one hell of a show, just check out the intro.

As you can see it had some amazing animation and facial expressions, and it was all about fighting the antagonists and the player themselves in a variety of different video games. At the end of Stalewater you of course get VoteBot (a reference to the very sassy and uncooperative bot Ned used to count votes for the modifier in the So Bad Its Good jam discord) zapping into the game and addressing the player as the player instead of Marshall McGraw. The other characters are actually all throwbacks to my other games, the knight is the same model used for Lord Zog from Ja Wizardman, the dragon is a reference to "Slay The Dragon" a game my friends and I made with Scratch back in high school, the sprite character is the Drug Lord final boss from Out Of Order, and the weird demon looking thing is the free asset I used as the monster in my final project for university (the project was an updated version of Sub Mortis that had AI, stealth and objectives, I'll be getting back to that project soon hopefully).

But the main idea was that this was just one game in which VoteBot was traversing through and manipulating, and the cameo appearance by everyone's favourite (or at least 3 or 4 peoples favourite) cyber cop was to suggest that he was chasing VoteBot through various worlds. I've wanted to make an Out Of Order sequel for 2 years now but never got around to it. I had the idea of Mallone fighting a sort of hacker or evil AI type boss through multiple game settings with different enemies, but never got around to making it. So I decided to tie that idea into Stalewater, with VoteBot being the evil AI whom Mallone was attempting to defeat. In fact there was supposed to be a section where you play as Mallone, I even had some models laying around before the jam started to practice my weapon modelling skills. I won't say too much about what that section was since I plan to make it as a standalone game, but I will say that I was listening to this video a lot while working on Stalewater.

What Went Wrong

Combat

By far the biggest problem with the game is the combat. A large number of the comments on the jam submission page basically said the same thing: "Wow this is great! I loved the voice acting and animation, it was hilarious! But the combat was boring and difficult". This was a depressing discovery at first since that was the worst possible combination of issues for a combat system in a game where a fair amount of the gameplay is combat. If the combat is difficult but fun, well then you can have an engaging if challenging game. If the combat was easy but boring, then at least you can be reasonably sure that everyone should be able to finish the game, which I think is key for game jams. So what made the combat so lackluster?

The most common complaint was that there was no feedback when shooting enemies. There are no hit animations or pain sounds when an enemy is shot, so it felt like you were just clicking until they died. I should note that there is a little crappy blood sprite that is spawned on the enemy when they are shot. But depending on where the raycast hits, the sprite may not even be visible due to clipping into the enemies body. And though the enemies do ragdoll on death, they just sort of slump over, it would have been far more impactful and funny if they flipped out wildly.  The reason for the lack of ragdoll reaction is that the ragdoll effect is supposed to be toggled when the player lands the killing shot, but in reality its triggered just after. I did eventually manage to fix it post-jam, but that update has not been released yet.

And the guns themselves didn't feel all that satisfying to use either, there were no muzzle flashes or wacky reload animations, and the firing animations were pretty bland. Now some of this was fully intentional, the revolver literally uses a toy cap gun being fired for its gunshot sound and is meant to be that kind of starting pistol that feels like a peashooter. But the rifle could've had a bit more punch, though I didn't have time to really go back and re-edit the sound effect. The way I made the gun sounds for this game was by mixing together several sound effects in audacity so you get the gunshot sound and two different sounds for the "click-clack" sound. And for the reloading sound effects I had to loop several round loading sounds and then add a barrel spin and cocking sound for the revolver, and the click-clack for the rifle. It's probably not the most ideal way of editing sounds but its the most efficient I've found so far. That being said I do think I was able to get the timing mostly right with the sound and animation, with the exception of the rifle reload animation which I intentionally left with the animation shorter than the reload sound. It may be confusing for the player but I think it was also humorous just having to listen to so many rounds being loaded. If you listen carefully it should work out to 15 shell load sounds being played.

Some of the blandness and lack of detail on the animations comes from the fact that I ended up reusing the NPC animations for the player, and of course people don't pay as much attention if NPC weapon animations aren't as detailed. Under the hood, the players arms are basically an NPC body with every other part of the body deleted and with an invisible skeleton. And a weapon sway script is added on top of that, which is basically just a short script which lerps an objects rotation towards the cameras rotation. It worked better than I thought it would, and it removed  a lot of doubled effort by making separate arms specifically for the player. Unfortunately it made the animations fairly uninteresting and it made it hard to see the dynamite when being held in the players hand. And after watching others play the game, I think the speed of some actions are too slow. Switching between the rifle and revolver is a bit too slow, and the delay between throwing dynamite sticks is too long.

As for why these things existed in the first place, I think it comes down to time constraints and my wanting to ensure a stable weapon system. I started work on Stalewater as soon as the jam started and continued to work up until the very last minute. Unfortunately I had work throughout the week so I only had evenings and the two weekends to develop the game. This was the same situation as last years jam, and of course as mentioned previously that went horribly wrong.

I didn't want to repeat the mistake of building another complicated combat system like Ja Wizardman, because that just adds the possibility for more things to go wrong. I also wanted to avoid the dreaded weapon switching bug from Out Of Order. If you switched weapons while a shooting animation was playing, then the gun you switched from would be stuck in the middle of the shooting state and was unable to be fired again. This bug actually resulted in the host of the jam attempting to replay the game multiple times because he kept running out of weapons to fire with. My attempts to make less buggy games really came in with Sub Mortis, where I went through multiple rounds of playtesting to try and get something smooth. Sub Mortis was far more ambitious than Stalewater so it had a lot more bugs, but it made me think more about the user experience. I didn't want peoples experience with the game to be coloured by bugs and poor performance like Ja Wizardman, Sub Mortis and Out Of Order. Even with this focus on stability, there were still issues when switching weapons. I even saw on one stream where the player switched from dynamite to the rifle, but the dynamite was still being held, except now it was using the ammo count of the rifle. As fun as being able to throw 45 dynamite sticks in a row would be, its still a pretty noticeable bug (even if the streamers didn't notice it), though at least that bug could be remedied before a patch by simply switching  weapons again.

The lackluster gun animation was partially due to a lack of time and partially due to a desire to make the player and AI function off of the same logic and assets in my games, similar to how the AI can play by the same rules in Bethesda games or the STALKER series. Also, after having done all the work of setting up the weapon controller and the animation transitions I didn't want to risk breaking it with new animations. While this was cool to me from the backend perspective, its pretty unimpressive on the frontend.

While the boring gunplay could have been fine, the difficulty was the real deal breaker with the combat. Some people who liked the game overall, didn't even make it to the end of the game because of the difficulty. A couple died in the first combat encounter, some died to the final boss, but most seemed to end up getting killed by the rifle enemies in the second or third round of the final battle.

The major source of the difficulty is the fact that the enemies use hit-scan attacks, if they have line of sight of the player they will hit every time. This made the player incredibly vulnerable when in the open, and made cover effectively binary, either you're covered and enemies can't hit you or everyone and their mother can unload bullets into your face. This combined with the AI being programmed to continuously fire while they are within range and line of sight with the player, and to immediately try and look for them once the player is not within line of sight, makes for rather lethal enemies. I actually thought the enemies were good before release, because I thought "Oh the enemies are actually a threat to even me and don't just wait to die or break completely anymore, awesome!". In hindsight that seems to have been the equivalent of the scientists at Jurassic Park marveling at how ferocious the dinosaurs could be.

The relentless AI was magnified with a noticeable increase in enemy health and damage in the final battle. The revolver enemies can be killed in one rifle shot, two revolver shots, or one revolver head shot. The rifle enemies on the other hand can take two rifle shots, three revolver shots, one rifle head shot and two revolver head shots. This is on top of the fact that rifle bullets do 3 times the damage of revolver bullets. There's a few reasons these stats are kinda strange, the first being that the AI weapons operate off the exact same weapon objects as the player. This design was part of my overarching goal of getting the player and AI to play by the same rules, and eventually theoretically allow the AI to do what the player can do. The consequence of this however is that nerfing enemy damage would nerf player damage just as much. And yes this specific issue can be fixed by just lowering the enemy health accordingly, but at a certain point it started to mess with the difficulty progression I had originally intended. The rifle enemies were meant to be a clear step up from the revolver enemies, being tougher dealing more damage and wearing a hat. The broken AI patrols of Out Of Order made any stat difference between the pistol and shotgun enemies in that game basically meaningless, and in Ja Wizardman the difficulty curve was derailed by the AI being so poor. I wanted at least one game where there was some sort of clear progression in difficulty. As part of this idea, I even had plans to make Moustachio throw dynamite to add an extra layer of strategy and difficulty, though thankfully I didn't have time to implement an NPC throwing behavior.

Level Design

Another big part of the combat difficulty problem I believe was the level design of the combat encounters. Both of the combat sequences are triggered by the player walking into an area: walking into the saloon door for the first, and walking out of the fort gateway for the second.  This design made sense at the time because it ensured that the player would trigger the sequences, and it was much easier to put a trigger over the entrances than design something more smooth/complex. And my thinking was that since you start right in an open area with no real cover, the player would be forced to move elsewhere to find cover and item pickups. Whenever I playtested the game in the saloon encounter, I would either take out the enemies quickly enough I didn't need to take cover, or I would duck behind the tables to reload and then pop off headshots when the enemy circled around the stairs. Before release I honestly thought the saloon sequence might have been too easy for a first encounter.

What a lot of people did however, since they were in the doorway when enemies started spawning, is just run right back outside and take cover behind the doorway. Unless you're able to easily land headshots and heal yourself, which understandably several of those I saw playing were not, this can be a BAD idea. Outside there is little to no cover and almost no pickups. So most of the players I saw ended up moving away from health and ammo, and away from cover. But since the fight is setup such that you're standing in a large doorway, enemies are damaging you from multiple directions, the tables flipped over are a little too far away (and frankly don't help too much unless you really hug them), and general gamer instinct is to run away from enemies when being shot rather than run towards them (unless its DOOM).

When I watched my brother play through the Saloon scene, he ended up running around the entirety of the town because he ran out of whiskey and forgot how to reload. Another issue I saw from that particular encounter, was if the player moved far enough from the enemy spawns then the AI can eventually lose track of the player and get stuck in a corner trying to find random points to look for the player. I actually saw this happen numerous times in the final battle where one last rifle enemy ends up getting stuck in the gateway. And though I never saw or heard of it happening, it is also technically possible for an enemy in the first encounter to wander outside the walls of the town and thus become unreachable and un-killable, blocking the player from progressing. This searching behavior is intentional, the AI can't see the players position but they keep track of the last position where they had line of sight of the player and move towards it. Since enemies move just as fast or slightly faster than the players walking speed they can quickly catch up, and the levels are pretty open so they can catch sight of the player easily. The problem is that when the AI moves based on random points within range it can move enemies away from the player or into strange corners. Because progression is based on every enemy being killed this can delay player progress a fair bit.

The issues with the level design and the players starting location are magnified even further in the final battle at the fort. The combat trigger in the fort places the player away from most everything, except for a table with whiskey and dynamite pickups, and the gateway. Once again, numerous players decided to stay hidden in the gateway rather than run out elsewhere. You start far away from cover outside the gateway, and there was no obvious way to tell how many enemies were attacking, so it seems like a good plan. In reality, it's a worse idea than staying in the doorway of the Saloon. The gate door closes behind the player as soon as the combat sequence is triggered, so there's no way to escape like there was at the Saloon. This leaves the player trapped in a confined space, with no access to further health and ammo pickups. It is possible to still survive after reaching this point as I've seen it done a few times, but you need to be quick about shooting the enemies who pile into the gateway. Those who did survive after using this strategy, left the gateway after the first wave of enemies, either because they couldn't see any more enemies or needed more health and ammo.

The fact that these near-fatal strategies are not discouraged by the map layouts was a real failure in the level design. I believe the major reason the level design was so poor is that it was put off to the very end. I mentioned to one fellow jam entrant that the layout of the fort was done in about 15 minutes, and that's really not too far off. I started with the scripted sequences and then built combat encounters around them, and I think it shows in the final product. The fort itself was a free asset I took from the Unity store and simply removed the stairs within the prefab so that the player and AI couldn't climb up and over of the wall. The interior only consists of a few tables spaced out across the map containing health and ammo pickups, and a bunch of brown cubes which I think are meant to be crates. Since I was pressed for time, the level design of the fort effectively consisted of me haphazardly placing cubes of varying sizes within the walls. The main focus I had was to make sure nothing broke, and that the objects in the fort didn't block off anything in the scripted end sequence. I did playtest it a few times before the deadline, but as previously discussed I'm not the greatest barometer for testing how easy my games are.

Control and Direction confusion

Something that wasn't often complained about but I noticed whenever I watched others play the game is how certain features and objectives were ignored or misunderstood.

The most common issue was in the first objective after the player exits the jail cell. The Deputy tells the player they can practice at the range right next to the Marshals office, and the player is given the objective "Practice shooting at range". The range is literally right next to the office but its a ways back from the exit. Many people seemed to wander around the rest of the town, including attempting to leave through the invisible wall which I had to leave due to running out of time, and only found it after looking everywhere else. Now the town is small so that isn't too big of an issue, but making the range not easily visible from the doorway added some unnecessary confusion. But what I saw generally happen after that, I believe was a genuine UX flaw. The objective simply said "Practice shooting at range", but the conditions for that objectives success is actually to kill the target dummies at the range. A number of people were understandably confused when after shooting at the dummies (but not killing all of them) the objective still told them to practice. Some players tried to look around for other things to do, but eventually all were able to figure out that they had to kill all the dummies. The objective should have simply said "Destroy all targets at the range", and that would have been far less confusing.

On the controls/feature side of things, I only realized after watching others play the game that the game never tells you that whiskey is a health item, or that you have to press F1 to use it. I saw one streamer drink the whiskey as soon as they picked it up, and then at the shooting range they damaged themselves by standing just within range of a dynamite blast. This meant that they were going into the first combat encounter at half health and no health items. This, combined with the level design issues mentioned before, lead to the streamer dying to the first couple enemies in the game. To remedy this I would have added another little text popup saying "[F1] Drink Whiskey to restore health" or something along those lines.

There is actually one place in-game that gives you all the information you could really ask for concerning weapons and items. And this was really a depressing experience to see how easily glossed over it was. This might surprise some people, but there's an inventory screen in Stalewater, its actually even shown on the games page.

In fact, the first tutorial prompt you see after picking up an item for the first time is that you can access the inventory by pressing TAB. The inventory has all the items the player has picked up, you can see a nice pre-rendered icon of each item, the quantity of an item currently held, and you can read their description for info and some occasionally funny text. Between the code logic, the UI design, the icon creation, and item description creation I probably spent almost a day and a half on the inventory screen. But for all of that, I saw only one instance of anyone who recorded themselves looking at it, and no one in the jam commented to say they liked or disliked it. The only confirmed in-depth usage I have of the inventory screen is when I watched my brother play the game, and I can't remember now if I told him about it or not. So that leaves me with the impression that the inventory was effectively a hidden feature, similar to the city viewer in Rome: Total War. But beyond that it shows how its also a useless feature, as its not required in any way to finish the game. For next years jam, if I'm doing a shooter I don't plan on adding any form of inventory screen at all since it takes up time and doesn't seem to add much.

My assumption with the inventory was that people would see that control hint first, look at it, notice that they can look at the info for items they picked up, and then try to see the info for any item they could find. And I thought this is where they would notice that the whiskey is used to restore health, and that you had to press F1 to use it. Speaking of F1, I only realized after watching my brother play the game that F1 is a bad hotkey for a quick heal. I had set F1 as the hotkey because I was used to hitting the F keys from playing many hours of STALKER, but my brother kept accidentally hitting the number keys which caused him to swap or holster weapons in the middle of a firefight. Ideally the hotkey should have been something easier to reach, possibly Q or V, or maybe even F if I had set E to be the interact key. Actually the real ideal would be to allow the player to rebind keys, but I only had a week to make the game. Long term however that would be my preferred solution in future projects.

Poor Modifier Implementation

Aside from the poor combat, what really seemed to drive Stalewater down in the ratings was the modifier score. The modifier for this year was "One button", and I frankly had no real plan for that one. It was pretty far down in the list of possible modifiers, and it was already a hidden modifier in last years jam (hence why in Ja Wizardman you can nuke the valley with the press of a button by speaking to the Specter in the middle of the map). The only idea I had of implementing it was to drag out an idea I had for an Out Of Order sequel, where the player must chase a hacker type character through various levels where the world and enemies are based off different video games. This is also where the Reboot influence comes in.

My pithy implementation of the modifier became that a button is used to change which game the world is set in. At the end of Stalewater we see that when the player presses this button, characters from other games begin spawning in. The reaction this seemed to get out of people was great, you had people who understood most of the references laughing because they got the reference. And you had complete strangers to my games watch in a mix of awe and confusion, which is what the ending was going for whether you understood the references or not. So everyone had a good time and the ending was fun if only tangentially related to the theme, what's the problem?

As has been previously established, a few people never made it to the end. And if someone never finished Stalewater, they would never even know I implemented the modifier. The shallow inclusion of the modifier combined with the fact that a few people who rated my game did not reach the end makes it less of a surprise that Stalewater ended up being ranked 34th in the modifier category.

Next year, I should try to include the modifier in a more prominent role whether through gameplay, story or presentation. I'm more happy with the fact that people broadly liked Stalewater more than I am concerned with its ranking, but sticking to the modifier more closely would likely force me to be more creative and possibly make the jam more fun. At the very least, the modifier implementation should be obvious from the outset rather than the ending.

What Went Right

Planning

Before the jam had begun I started making up a list of all the possible ideas I could use for the modifiers that were listed on the jam discord.  The original educational game idea for Stalewater still had the Oblivion-like dialogue and bad voice acting. In fact, the dialogue, voice acting and western setting were part of a few different modifier ideas. This consistent vision in my head made it very easy to replicate parts of it in-game.

For SBIG 2022 I plan to draw up a similar list of ideas for each modifier, and see if there are any that can be crossed over with other ideas. And frankly I think if an idea can cover multiple possible modifiers it means the idea is rich territory for so bad it's good potential. I actually have a couple ideas from previous years that I would like to explore, but we'll see what VoteBot decides next year.

Early Content Creation

Something that really crippled me in making Ja Wizardman is that I waited until the last 48 hours of the jam to start making models and textures. This meant that all the cutscenes, item icons, and placing characters in the world were left until the end. Not wanting to repeat that I spent the first weekend making animations for a single skeleton and began modelling characters early in the week. The base human mesh is from the UMA projects GitHub page, and the clothes for different NPC's are basically just extrusions from that base mesh. I used UMA's characters for Ja Wizardman, but I extracted it from the UMA asset rather than just downloading direct from their content site. The reason for the change in method is because the old extracted skeleton was unable to copy and paste x-flipped poses, which was something required so that I could make animations more efficiently. It effectively meant I had to make only half the frames of a walk cycle, and could just copy and paste the x-flipped poses to create the other half of the animation.

For the next SBIG jam I want to get the main character designs out of the way early on, that way I can either get some cutscene or art content done early or that I can rapidly work on animations and sequences at the end of the jam and not have to worry about making models at the last minute.

Voice Acting

By far one of the most popular parts of Stalewater, and one of the most fun parts to work on, was the terrible cheesy voice acting. I did voice acting for only two characters in Out Of Order, three in Ja Wizardman (technically four but one didn't make it into the game), and none for Sub Mortis (since I want that one to be actually good). I really enjoyed doing the different voices each time and I think it always adds a big boost to production value. It did require a fair bit of time to record and edit the voice lines, especially for VoteBot, but it was definitely worth the effort. The voice acting was praised as one of the best/worst parts of the game and lead to Stalewater ranking #1 in sound (though 1 Press Button technically had a higher raw score and better quality voice acting and writing).

The addition of voice acting worked well in my preceding games, and it worked very well for Stalewater. With this kind of track record I think its fair to say that voice acting of some sort is a certainty for So Bad Its Good 2022.

Cutscenes

Yet another popular segment (which really is just the feature of combining both of the two previous popular aspects) was the cutscenes. The opening cutscene will seem familiar to fans of Fallout and anyone who has played my previous games. I took the lessons learned from making the slides in Ja Wizardman and refactored, polished and expanded on the system. Instead of simply showing images and changing text for as long as a related voiceover line lasts, the new slides can fade into each other, play videos, or be set to last for as long as specified and simply display text or nothing at all. I like the slide system as they allow me to reuse character animations or not even use any animation at all, it sets up the world of the game, and frankly I just like having lofty dialogue play over stupid images. I did put some effort into adding some cinematic elements into the opening though, the bandits riding horses silhouetted against the setting sun looks like something out of a Neil Breen film, and the shot of the train going over the camera in the middle of the voiceover I honestly think was just a cool shot. And the "choo choo" at the end of that scene was a nice little comedic end. Though if I were to do the intro over again, I would make it shorter than 3 minutes.

In-game cutscenes are something I wanted to put in my games for a while, and I'm really happy with how they turned out. They're pretty simple, they don't require a second camera, and with the exception of the final VoteBot sequence the player doesn't need to be moved at all. I was able to reuse the black bars of the dialogue UI which was nice, though I did have to make additions to the dialogue system to allow the conversations to end without allowing the player to move and look around.  Though I already had to make many refactors and additions already to account for the facial expressions, and cleaning up the absolute mess that was Ja Wizardman's conditional dialogue options display logic. A big bonus to having these in-game cutscenes is that I could script specific animations or sounds to play, rather than having to wrangle with making new nodes for the AI.

Speaking of AI, I didn't have to have to work around the AI with this cutscene system. There is technically no friendly AI in Stalewater. Deputy Wilson has no AI, just a collider, an animator, the Oculus Lip Sync components, and the Conversation component which defines what XML file an NPC uses for dialogue. This not only eliminated the headache of adding more conditions to AI behavior but it increased performance because the game didn't have to constantly check if an AI was locked, or evaluate behavior tree nodes.

Plus me being lazy, I created the sequence scripts in such a way that I could copy and paste the majority of the jail cell scene code and reuse it for the saloon, fort gate, and VoteBot scenes. This was an admittedly hacky way of implementing it but it was quick and largely worked without issue. The only issue encountered with this system is that for some reason if the player is standing on a cutscene trigger when it spawns, the transform translation wouldn't complete properly. Thankfully this only happened to one person and I was able to figure it out pretty quickly, but it was incredibly strange because somehow a while loop was still running after its looping conditions were no longer true. But once that issue was patched, the only thing stopping the player from completing the game was their patience and the grueling combat.

As mentioned previously the idea for the system largely came from Call Of Juarez, but upon reflection I think Dishonored was a bigger influence for specifically the final cutscene. The way VoteBot and the other characters zap into the scene are more reminiscent of how The Outsider and The Whalers can warp into view.

The in-game cutscenes were a reasonably straightforward feature to implement, and I think they added quite a lot of humour and production value to the game. I was a bit iffy on the idea beforehand because I thought it would be too time consuming, but the final product was definitely worth it. I would like to have scripted sequences in the future that don't lock the player, similar to Half-Life. But since I'd rather not get too ambitious with these games I'll likely stick to cutscenes that either lock the player, or are more in line with the intro cutscenes where the player controller is not present at all.

Animation

Another feature that was praised by comments in the jam and from streamers who played the game was the wacky character animations. My animation skills (at least in terms of working quickly) improved quite a bit since Ja Wizardman. Doing the monster animations for Sub Mortis taught me how to copy and paste x-flipped poses. This allowed me to create a basic walk cycle quickly, resulting in that beautiful bow-legged gunslinger swagger.

Another huge lesson was learning how to implement lip syncing using the Lip Sync Plugin provided for free by Oculus. I simply had to create 15 mouth shapes, or "visemes", using shape keys in Blender and then assign the index of those shape keys to the index of the visemes in the Oculus component. Once that was done I simply had to assign an audio source to be used as input to the Lip Sync Plugin, and voila! I had semi-accurate lip syncing in a few hours!

But I went a step beyond that, I also added shape keys for a select number of facial expressions. Specifically: happy, sad, angry, and smirking. The goal was to replicate the uncanny valley and over-expressive facial expressions seen in Elder Scrolls IV: Oblivion, and how characters would suddenly change emotions between dialogue lines. The Bethesda-tier dialogue system was another crowd favourite, being hilarious and almost creepy at points it definitely fit the "so bad its good" label.

I definitely hope to continue working on my animation skills, to make movements either wacky or polished. I'd especially like to sort out having multiple animations running at a time so I can have NPC's aiming their weapons and walking at the same time. The Oculus plugin I'd love to use more in future projects, because it's really easy to implement and work with, and it could be used to make both realistic and ridiculous lip syncing. They even have an option for using different textures for mouth shapes, so hypothetically I could even make lip syncing for VoteBot, though I think it's much creepier with just a still image.

Performance Optimization

Something that likely wasn't obvious to players is that Stalewater ran exceptionally smooth most of the time, with the only hiccups being enemy spawns. The reasons for this is that unlike my previous games, the enemies don't already exist in the gameworld wandering around and taking up computational resources. And unlike Ja Wizardman there are no friendly AI that constantly have to check if the player is attacking them or if an enemy wanders into sight. Another big polish change is that the AI related code is completely disabled after an enemy dies, which was a funny bug in Out Of Order, where sometimes dead enemies corpses would continue moving. In editor I was regularly getting >200 FPS, and it never dipped below 60 FPS in the build version. There was one big performance hit that I managed to fix in a patch though, at release I had left a few debug statements in the behavior tree code, so print statements were being created thousands of times. Once this was removed, no other performance issues popped up.

I also carried over the game setting code from Sub Mortis, so players could change the games resolution to fit their screen better. The reason this resolution selection exists is because one of my friends complained about the phone in Sub Mortis being half off-screen since his laptop screen had a 3:2 aspect ratio. The resolution options may not have helped too many people, but I'm happy they were there. And I'm happy that performance was not a major issue for people playing the game, as that was an issue with Ja Wizardman at points, and was a big issue with only a single room in Sub Mortis for some players.

Future Work

In the immediate future I have a few more features and fixes I want to add to the game.

I already have an almost working dismemberment system similar to Fallout 3 and New Vegas, something I planned in the original design. And I think it fits the "so bad its good" bill because I left out a conditional check, so if an NPC is hit with dynamite they can actually spawn additional limbs. I knew I stumbled upon some janky goodness when the first test dummy I tried somehow gained two extra left feet after being blown up.

I also started work on making the player drunk if they drink too many whiskeys in a row, similar to how potions can make you drunk in Kingdom Come: Deliverance. I had this idea written down in my notes before the jam started but withdrew it because I thought it would be out of scope. But a fellow dev suggested on multiple occasions that I should add such a system, so now since I have time I feel almost obligated to make it.

To make combat feel more responsive I also have a few ideas for new features and content. The most simple idea I can think of is to add the ability to shoot enemies hats off if the player lands a headshot. This would both give the player some more visual evidence that they landed a headshot on an enemy, and it would look funny. I would also like to add hit reaction animations for multiple damage locations on an NPC's body.  NPC would jolt to the left/right if hit on the left/right arm, grab their stomach if hit in the gut, and nearly keel over to their left/right if hit in the left/right leg. But that might end up having to be saved for the follow-up.

A more minor feature but something I think may be appreciated is to give NPC's a list of possible pain/death sounds to choose from when hit/killed. Another dev pointed out how annoying hearing the same death line 30 times in a span of a few minutes was annoying

The level design issues I would like to address, certainly the issues with the fort battle. The Saloon encounter I probably won't change that much, since I think it could be mostly remedied with other fixes to combat.

Something I haven't started but will be a priority in the near future is an actual save system. I neglected to make one before simply because I couldn't be bothered to go back through all my code and figure out how to serialize and de-serialize it. But multiple people said a save system would be a welcome change, and I know I will need it for Sub Mortis and other future projects. So I want to get a first attempt out of the way as soon as possible just to get it over with.

For future projects I definitely want to improve the combat, as it has always been a sticking point in my projects. The combat in Out Of Order was basically simply functional and only became halfway decent after a large update almost a month later. The melee combat in Ja Wizardman was largely broken, and any real strategic possibilities are quickly deterred by the wonky AI. And of course Sub Mortis has no combat, partially because I knew a far more polished combat system would be required. I think this trend of poor combat continues in Mons Badonicus, since so much effort went into getting mechanics to work there was no time to really add weight to units. I'd really like to try a SBIG version of Doom: Eternal or Necromunda: Hired Gun (though considering its made by Streum On, Necromunda might already be SBIG), but that might raise the skill floor too high if done poorly.

For SBIG 2022 I think my main focus will be on the gameplay, preferably that would be combat related but we'll see what the theme is.  Whatever I end up doing I plan on building on the strengths of Stalewater, so probably more cutscenes of some sort and definitely more voice acting. Working on making animations reusable in Stalewater ended up paying dividends for Mons Badonicus, so I certainly plan on honing my animation skills and hopefully figure out a way to combine animations neatly. More thought will also need to be put into the level design, as much as it fits the theme I think I should strive for something more than random cubes scattered around an empty level.

As for the cliffhanger ending of Stalewater, well that will hopefully see a resolution within the next two years...

Final Thoughts

Working on Stalewater has been some of the most fun I've had so far in game dev. The development cycle was surprisingly smooth, I was able to get really dumb for a change after working on Sub Mortis for several months straight, and frankly seeing the positive reception to most of it was awesome! In less than a month it blew away my previous projects in terms of engagement and popularity. For the first time in my life I witnessed in real time as strangers on the internet lost their minds at a game I made. Several people added the game to their collection (which may or may not be that big a deal but it was a huge step up in comparison to my other projects), I gained more followers on itch and gamejolt, and someone even uploaded their any % speedrun of the game.

Despite its flaws (well, at least despite the unintentional ones), numerous people found something to like about the game, and seeing that response even on a fairly small scale is one of the greatest feelings I've experienced. Now all I have to do is figure out how exceed expectations next year.

I would like to thank Ned Reid for hosting the jam, my fellow jammers for submitting fun games and giving me great feedback, and FunBaseAlpha, darzingtonand pegashush for streaming Stalewater and several other games from the jam.