Another year and another So Bad It’s Good jam has come and gone!                                                

And with it, I managed to make my second release this year (third if you count the private release of the Thesmothete expansion level)! This time I created a game really emphasizing the murder in “murder-mystery” with How to Be A Hugh Mann.

For those of you interested, here’s the stats:

I ended up in the top 10, which has really been my only aspiration in SBIG in terms of ratings since I won in 2019. There was a lot of great entries this year, so I’m honestly surprised I got even close to the top 10. I recommend playing the other top 10 games, you can find them all in the “Best Of The Worst” compilation on the jam hosts itch page.

It didn’t help I once again submitted late, which was disappointing since I intentionally tried to scope down my idea to submit on time or maybe even early. I also had my score dragged down by the modifier rating, which is frankly what I expected because I elected to largely ignore the modifier this year. The modifier was “every suggestion combined” which I thought was prone to massively overscoped entries, and having seen the other games in the jam I think I was right.

Overview

Last year, I focused solely on improving the combat mechanics and I thought I was successful enough I knew any other attempt at a shooter would pale in comparison. With that in mind, I decided to go the exact opposite direction and make a game without any combat mechanics.

After playing some dialogue heavy games in the past year, I decided I should try making a game centered around talking to characters. The idea spurred me on into totally revamping my dialogue system. This was something I had wanted to do for a couple years, but now I finally had the time and willpower to try it.

When I tried to brainstorm a game idea best suited for trying extensive dialogue trees, I concluded a detective/murder-mystery game would be the most fun. Because the investigation would require questioning multiple suspects, I could potentially work in many parameters to a conversation like the suspects opinion of the player and what evidence the player collected.

It also helped I had played several games involving some form of murder-mystery in the past couple years, so I had some concrete examples to work off. Specifically, Pentiment, Sam & Max, LA Noire, and Disco Elysium were large influences on Hugh Mann. The dialogue systems in those games I found especially interesting and varied, with a lot of fun to be found in dialogue options where the player screws up.

But I wanted some form of stupid twist on the murder-mystery to add some more fun to it. The most obvious was making the player the murderer. This was to provide not only some fun dialogue in framing other suspects but maybe some non-dialogue gameplay in eliminating the other suspects. Sorta like a mix of the Dartmoor mission in Hitman 3 and the whodunnit quest in Elder Scrolls IV: Oblivion. Some Knives Out influence probably slipped in there as well.

The other twist of course, is Hugh Mann is an alien in disguise. Why did I think of an alien disguised as a detective? I honestly don’t know, maybe it was some subconscious influence from Men In Black (which is what inspired the IRS agents), maybe it was some other game I’ve forgotten. Frankly I think I just thought it made a great tagline: “half detective, half assassin, half alien, all Mann!” And the game’s title itself was inspired by a Powerman 5000 song with a similar name. I often listen to Nu-Metal songs when working on “So Bad It’s Good” games to put myself in the proper mindset for creating something laughably bad.

Also, something I discovered while writing this postmortem is the TVTropes entry for aliens in disguise is literally “Hugh Mann”, so maybe I saw that before the jam.

Another good chunk of inspiration came from my many hours spent watching compilations of Whose Line Is It Anyway? One of my favourite games was called “Narrate”, where two performers would play out a hardboiled-film-noir scene, with each performer turning to camera to monologue.

This, combined with the ego-inflating inner monologue of the protagonist in YIIK: A Postmodern RPG, inspired Hugh Mann’s internal monologue cutaways.

Now that I had some ideas, I needed a dialogue system to handle them.

The Dialogue System

Behind the scenes I’ve been working on improving the dialogue system used for my 2021 SBIG submission Stalewater. By late 2021, I had implemented the ability to control individual blend shape values and set how long it would take to transition between the blend shape values.

But the system was still incredibly limited, and since it relied on manually editing XML files, it was time consuming to make a single dialogue tree.

I wanted a dialogue system that would allow me to make more expressive NPCs in dialogue like those seen in Vampire – The Masquerade: Bloodlines and allow for numerous dialogue options both dependent upon and affecting items, stats, faction opinion, and quest status like in Fallout: New Vegas.

In simplest terms, I wanted a dialogue system that could do more things, with a finer level of control.

I’ve spoken to some other indie devs over the years about their dialogue systems to get some ideas. Some have them in JSON files, some using Ren’py, Unity ScriptableObjects, and even a custom scripting language. I also watched several videos on the topic, and a devlog for the game Wrought Flesh introduced me to another devlog for Hyperbolica, demonstrating its dialogue system, which I found fascinating. However, I knew with all the weird conditional checks and effects I wanted to have for dialogue options, a simpler format like Hyperbolica would get messy.

I should also mention I was partly inspired by previews of Starfield’s dialogue system, and how Bethesda mentioned they dedicated time to polishing and expanding their systems capabilities. I think I was intrigued mostly because it also represented a developer who has had issues with a mechanic in the past and focused in on fixing it. And while Starfield NPCs in dialogue (at least as of August 30, 2023) still appear to have characteristic Bethesda jank, it is a noticeable improvement over their past games in my opinion.

Since I knew how time consuming all of this would be to type out manually in a text file, I decided to finally dive into something I wanted to try for a while: making a node-based GUI for the dialogue system! Fortunately, I was able to stumble across several video tutorials demonstrating how to make a node-based dialogue system GUI using Unity’s experimental GraphView package. After a couple weeks of tweaking these example projects, I had my own DialogueGraph setup.

I know several people reading this are thinking “ok, so how does all of this get into the game?”. If you press the save button at the top of the graph screen, the created graph will be converted to the various Dialogue related objects and then saved to a JSON file. Which can look like this:

You’ll notice there’s a lot of text for just two dialogue nodes. Partly because the dialogue tree files contain both dialogue and DialogueGraph data. Also, due to the number of variables at play there are some unused fields, such as “silenceLength” on nodes with audio files. But I was able to make some optimizations such as only saving the base item ID for any item referenced in a DialogueGraph, or only the filename of a voice line.

Even though the files are incredibly long (for comparison, all the main antagonist’s dialogue trees in Stalewater combined are under 400 lines of text, one of Red Herring’s trees is over 2000 lines), I get a lot out of them, and most importantly I can simply load the file into the DialogueGraph tool and look at it there.

Here’s an example picture I stitched together of all the different options on a single dialogue node:

I do recognize though how this setup may seem too clunky for some, in particular artists and writers. For my weird programmer brain, it makes about as much sense as anything else.

What Went Right

Revamped Dialogue System

As I just laid out in exhaustive detail, the dialogue system in this game is much more advanced than its predecessor seen in my past projects.

For starters, it’s much easier to manage on the backend. Most of the DialogueNode logic is now separated out into different objects like DialogueOption, DialogueOptionEffect and DialogueOptionRequirement. Which means instead of having a single monolithic structure holding all the data, it can be broken down into smaller chunks.

One of the biggest features, allowing animations and multiple facial expressions in a single dialogue node, resulted in some funny and bizarre conversations which players enjoyed. My favourite part of the new system is how it provided expanded room for physical humour. Probably the simplest (but hilarious) example is when Sir Red Herring says, “I’m a killer!”, and the camera pans back to Hugh stunned in silence at what he just heard with a look of shock on his face.

In my projects I also tend to have a subconscious goal of trying to avoid things that could’ve been done in a past game. Partly inspired by John Romero's level design rule for Doom and Quake that if a level could be made in a previous game, it wasn't good enough. For example, in my 2022 SBIG submission Thesmothete, I tried to design the levels such that they would’ve been unplayable in my previous shooters. With Hugh Mann, I tried to make dialogue trees which couldn’t have been made with my old system.

In my opinion, the pinnacle of this goal is Marvin Green, who is mute and communicates entirely through physical gestures and facial expressions. Admittedly, his tree can be a bit too basic at times but I’m just happy it was even possible to make.

Of course, basically any conversation in this game couldn’t have been made previously. In my old system, every line of dialogue had to be advanced by the player selecting a dialogue option. Which was tedious for the player, having to select “[Continue]” or something similarly insignificant to progress a conversation. And of course, now multiple characters can participate in a dialogue tree, most notably the player character and their internal monologue (which was a special case that had to be hacked in, but it wasn’t too messy honestly).

I’m really happy with how the new dialogue system turned out, and I look forward to building on it in the future.

DialogueGraph Tool

The DialogueGraph tool helped a lot in allowing me to make extensive dialogue trees quickly. Instead of typing out every key and value pair, I just had to fill in some fields and connect a few ports together to setup a dialogue tree.

Of course, there was still some iteration required where I would have to test to ensure timing of events was right and the dialogue audio and text matched. But the fact most values were filled in with type-specific fields helped minimize typos and other syntax issues. Which was a major pain in my last project with extensive dialogue trees, Ja Wizardman.

Specifically, being able to assign audio files to a dialogue node was a major relief. Typically, I like to make my voiceover filenames as verbose as possible to differentiate them. This has the downside of leading to long strings which can be annoying to parse and type out. But with the file being assigned via an object field, I can just drag-and-drop or search the project Assets folder for a file. And with the added features of a preview for the file waveform and displaying the length of an audio clip, it was much easier to judge when an event should occur during a dialogue line being played.

This was really the first time I’ve made a separate tool for developing games, aside from possibly when I first implemented my ScriptableObject based inventory. It’s not without flaws, as I’ll discuss in a later section, but for the most part it worked pretty well.                                                                                                                                                

Simple Controls, Simple Tutorial

The controls for Hugh Man ended up being the simplest of any game I’ve ever released, the player can only walk, sprint, jump, interact and click dialogue options. This made teaching the player the controls dead simple.

I decided to just place the basic controls on signs in the front yard of the house for two reasons. One, it means the controls are the first thing players see when starting the game. Two, for the player to progress, they must use those controls.

I used this method in my past two games, Thesmothete and Pits Of Goremoth, to great effect. In those games however, the controls and mechanics were far more numerous and complicated, so the little “hint boards” could get kinda overwhelming. In this case, it was just two concise signs and one internal monologue line to explain everything the player needed to know for the controls.

It’s a method I’d recommend other jam devs attempt, as it’s a quick method of ensuring players can see controls. It may not be the most immersive tutorial method in some cases, but it works.

And for the gameplay itself, just the concept of a murder-mystery setting with the player as a detective told players broadly what they would be doing. Investigating the house, and questioning suspects. Officer Wilson spells it out in a bit more detail, which perhaps could’ve been streamlined, but it was an improvement over my past attempts at tutorial dialogue.

The result though, is Hugh Mann being possibly the only game I’ve made where players didn’t struggle with controls. Which is a depressing fact for my past work, but I hope is an optimistic note for my future work.

Voice Acting

Once again, me making various terrible voices was a delight for players. It’s been a part of my games since my first SBIG game in 2019, and this year I made more of it than most of my past games combined!

I voiced a total of 5 characters in the game (6 if you count Hugh Mann’s internal monologue as a separate voice), and 2 others who were cut. It was fun getting to do the different stupid voices, though admittedly it was quite time consuming for my part.

Fortunately, I was able to offload a small portion of vocal duties to the guys at FunBaseAlpha, so I’d like to give a shoutout to them for doing the voices on fairly short notice and knocking it out of the park! Their streams are great btw and they play itch.io games a lot so go check them out.

Hugh Mann is unique in that it’s my only game to have a voiced player character in dialogue. In the past, I avoided providing a voice to player characters in dialogue. Because I rarely had the time for it, I found it limited player options (just look up the controversy over Fallout 4’s dialogue system), and frankly my old dialogue system didn’t support it. This time, I had a new and improved system that could handle it, and I had a game where it made sense to have a voiced player character.

I always find voice acting, even voice acting as unprofessional as mine, gives smaller games, especially jam games, a bump up in production value. I’m happy with how it turned out this year, though I think for next year I’d like to either get some other people to record dialogue, or just have fewer voice lines.

Exaggerated Inverse Kinematics

I’ve been using IK in Unity since late 2021, I had started researching them because I couldn’t figure out how to make enemies look up and down at the player in my game Stalewater. The way it works, is if the animator component on an NPC is enabled, the NPC’s rig has weight values set for different parts of its body to look towards a certain point. In Thesmothete, this meant enemies could properly face towards the player which made them seem more “alive” For Hugh Mann, IK was used to make the player model looks towards anything interactable. This both looks hilarious and helps indicate there’s something of interest if the player misses the text prompt.

I already knew from past projects how goofy the heavily weighted IK could look, but this idea was also partially inspired by Grim Fandango where the characters head would look towards interactable objects.

Players found it hilarious, and I found it to be a neat experiment for use in future games in a possibly more polished form.

Proper Credits Sequence

A minor point, but I always wanted to make a credits sequence which had something going on in the background.

In past projects the credits are either a simple scrolling wall of text on a blank background, or in a text file included with the game. I wanted something dumb players might actually look at for a few seconds before quitting the game. So, this time I decided to make an over-the-top scene where the player character is in the middle of a stadium with cheering crowds and fireworks.

It’s a small thing, but I like how stupid and over the top it is.

What Went Wrong

Slow Start

I got off to a surprisingly sluggish start to the jam. I was still brainstorming ideas for how I would implement the more detective-like ideas I had in mind and what the gameplay balance between detective, assassin and alien would be.

Admittedly this was partly because I was on vacation during the jam, and I didn’t want all my time off to be consumed by sitting at my computer. For the first several days of the jam development was interspersed with reading, paddle-boarding, walking, and working out. Which means this was probably the healthiest SBIG jam I’ve done, but it did lead to me having to crunch to finish the game after the deadline. Continuing the grand tradition of my SBIG entries being submitted late.

I had so many different ideas for how a detective-hitman-alien game could play but I could never figure out how to balance them all out. I had started implementing the full inventory system UI in preparation for a more in-depth game. And I had even created the skeleton of a “suspects” screen, which would have all the suspects in a list along with their opinion of the player, and all the evidence and information associated with each suspect. But the idea never got beyond a basic UI template and a barebones NPC template system.

By the end of the first weekend of the jam I knew I would have to lean more on dialogue trees than gameplay mechanics. So, I focused on polishing up the interaction mechanics to ensure there were no issues, like players being able to move while the camera is locked, and immediately switched to working mostly on content.

Any UI not related to dialogue, interaction, objective, or the pause menu, was disabled. On the FunBaseAlpha stream, one of the guys even asked why there was no inventory screen. The reasons for making it inaccessible are because all the functionality of using items occurs only in conversation, and removing the inventory screen removed the need to make inventory icons or descriptions for items. I remembered how creating the inventory screen in Stalewater ended up being a waste of time since players never used it, and they never needed to.

All this disorganized brainstorming and mental lethargy resulted in an oddly disjointed game which simultaneously feels shallow and overly complex.

No Wrong Answer, But No Explanation

A major design goal with this game was something I had wanted for a while, and I managed to achieve it with this game, but most players did not know this factor existed and thus became a problem.

I’ve had issues in all my past SBIG entries of players not making it to the end of the game. Typically, this occurred due to the combat being too difficult and dying repeatedly, but I’ve seen some players simply give up playing Thesmothete even before dying was implemented. This year I wanted to take a page from the Lucas Arts school of design and make it so the player could finish the game no matter what happened and there would be no intentional fail state. I thought this would be great because the player would then be free to kill or arrest whomever they liked and still be able to succeed.

And while it is possible to arrest any of the 4 suspects, or my favourite just kill all the suspects, and still complete the game, players did not know this. In hindsight I didn’t even really attempt to communicate this to the player, I think because I wanted it to be a surprise. Like the player would accidentally end up killing all the characters and think they screwed up, but then the objective would update saying “All suspects are dead, talk to Officer Wilson”. Instead, what seems to have happened is for some reason, Marvin Green’s conversation behaviour was still functional after he’s killed. So, players who had already killed everyone else would just talk to Marvin’s corpse and arrest him to complete the investigation. Now this is objectively hilarious, but it made it seem like the game was only beatable by dumb luck, rather than by design.

Indeed, some players noted how the game felt like it was coming apart at the seams at times and decided to stick with safer options in trying to actually solve the murder. The truth is, there was never intended to be a full explanation of who killed Doctor Cadaver and how. The answer I had in mind is Hugh Mann killed him as part of a separate hit, but Hugh had forgotten, and there would be some line at the end where he ponders “But who really killed Doctor Cadaver? Oh wait, I did!” Originally this was planned to lead into a scene where Hugh questions himself into a mirror, but sadly that didn’t have time to happen. The point is any conclusion the player makes can work. Two of the suspects kinda admit to killing the Doctor, but not outright. Hugh only cares about getting someone arrested and Officer Wilson doesn’t really care who or why is pinned as the murderer.

Though unfortunately, several of these options were never explored by most players, and I think it was largely due to the next major issue.

Content Locked behind Branching Paths

This is an issue I still have mixed feelings on, because it ties into ambitions I’ve had with my games for years, but it also ended up preventing players from having the best possible experience.

Two of the most complex, and in my opinion best, sequences in the game are hidden by the more ridiculous dialogue options. And since the options seem like they would screw the player over I don’t think many players chose them. I only know of one person who for sure saw one of them, and I’m not certain if anyone saw the ending with the agents where you try to distract them. This latter scene is arguably the most complicated cutscene I’ve ever made, even more than the ending cutscene of Stalewater.

The obvious question then, is why did I bother going to the effort of making so much content locked behind branching dialogue trees? Well, the answer goes back to me wanting to test out my fancy shmancy new dialogue system.

This was done intentionally to test out the dialogue system to see if I can achieve all these different things happening in different paths. I always liked games with branching dialogue that impacted gameplay because it feels like the player has agency and the world can react to those decisions. The last game I made with a dialogue system was Stalewater, and that basically just served as a more convenient alternative to creating a more polished cutscene system. None of the dialogue options had any effect aside from a couple dialogue lines, I was disappointed with it and wanted to try something with more depth this year.

It helped test and improve the DialogueGraph tool, but it came at the expense of the game itself. Because so much different content is locked behind exclusive dialogue options, it means players can miss out on a lot of the cool stuff unless they play the game multiple times. And frankly this may not have been such a bad thing if it wasn’t for another major issue.

Un-skippable Dialogue

The one consistent issue players mentioned, is dialogue is entirely unskippable. Now I knew this would be an issue even a couple days before I submitted to the jam. In fact, this was an issue during development as it made testing take longer. I just simply did not have the time to implement the feature. Which is a shame as it’s a feature that previously existed in the dialogue system, I think it was one of the better QOL features in Stalewater.

But the major reason I was unable to implement it, is due to the dialogue system.

There were so many different events occurring during a dialogue node that fast forwarding/skipping them could have resulted in some weird bugs I would have to focus on instead of finishing the game.

In fact, I have already started work on implementing skippable dialogue, and I’m still trying to sort out a bug where skipping a line causes the following line to also be skipped, but the line after that doesn’t start. So sadly, my suspicion this issue would be time consuming was right.

This combined with the above two major issues turned out to be a potent mix of problems. The branching dialogue trees meant players would be unable to see all content in a single playthrough. The janky feel of the game and the fact players didn’t know there was no failure state, meant players tried to stick to safer options. And the inability to skip through dialogue meant players either didn’t have time or didn’t want to play the game multiple times.

The end result is players missing out on what I think are some funny scenes, which is a real shame.

Unfinished Tool

Alongside the inability to skip dialogue, the DialogueGraph tool sadly had several other issues. Some I was able to address during the jam, and some still exist.

Some of the biggest issues were:

• The lines from dialogue options wouldn’t draw properly in the graph, which could make navigation confusing.
• Sometimes values for silence length and destination index would be changed or reset when saving a graph. Still not sure exactly why this happens, I think its related to a port not updating when trying to change a connection.
• There was no autosave, so on occasion some work could be lost. Luckily this didn’t happen more than a couple times.
• Certain fields still had to be filled out manually, like character name. Ideally this would be tied to the NPC template system I’ve used in past projects.
• I didn’t have time to implement the ability to reset the graph view, which made it annoying when trying to load a dialogue tree file.

And while I certainly benefitted from not having to manually write out 1000+ lines of text by hand for each conversation, the dialogue graphs could still get quite messy.

For example, here’s two thirds of Marvin Green’s dialogue tree:

Some space does get saved because the animation events and dialogue options can be collapsed and expanded, this is just to demonstrate. But it’s still a bit too confusing, the lack of lines generated for dialogue option connections is a real QOL failure.

Now typically in game development, whenever you’re building a tool you want to use it to build a game at the same time so you can discover all the pitfalls of the tool and what it needs. Like if you’re making a game engine, you try to make a game with it so you can test out what you need. And while I think I achieved that during the jam and it was preferable to manually writing out JSON files, it also added some frustrating overhead.

Shallow Conversation Systems

Aside from just creating the tools for a better dialogue system, I also wanted to try making conversations more active.

I had tried thinking of ways I could make the dialogue system more active, like perhaps add the ability for the player to interrupt suspects, or maybe tie in the opinion system more tightly ala Alpha Protocol. I briefly thought about trying dialogue options with a random chance of success like Fallout 3 or Disco Elysium, but I decided it would be too frustrating and abandoned the idea.

I also considered trying a clue-based system like LA Noire, where I could also copy its hilarious system of choosing to believe or doubt a suspect based on their obvious facial expressions.

Unfortunately, while some aspects of these various ideas snuck in a little bit here and there, by and large Hugh Mann doesn’t have any real in-depth conversation/interrogation mechanics for the player to interact with. At most, dialogue options can increase/decrease character opinions (for this I reused the faction system used in past projects) which will restrict certain options, or options requiring the player to have picked up certain items to become visible.

In my opinion, other murder-mystery games in the jam were more successful in setting up relationships between characters and having different suspects reveal conflicting information opening up new dialogue options. In my game, the dialogue trees never intersect. And the only times more than 2 characters are in a single dialogue tree is when a suspect is arrested, and the ending.

From player feedback it seems like what’s there is good enough, but I’m still disappointed the game ended up being the closest to a walking simulator I’ve ever made.

Dialogue Camera Placement

Another obvious issue several players noted is during dialogue its easy for cameras to have their view obscured by other characters or level geometry. In some ways this arguably enhanced the janky feeling of the game, but at the same time meant the goofy animations and facial expressions would be hidden.

One of the major reasons I made this game was to test out what the new dialogue system can do, so it’s a bit of an issue if the player can’t see it in action. This was especially a problem for the Marvin Green dialogue tree since he communicates entirely by gestures.

I tested using fixed points for the player character in dialogue, but I found it to be too tedious to implement for every character and account for characters who move locations like Violet. Now I have time to polish it a bit, I plan to address this in some fashion in the post-jam update.

Cramped Level Layout

Once again, the level design is an issue in my games. This time the issue was caused by me just grabbing a house prefab off the Unity asset store and slapping it into the game. The asset itself isn’t too bad, but the cramped quarters made the third person controller camera jump around a lot. This was exacerbated by some of the walls missing colliders in the prefab, so the camera could seemingly clip through walls on occasion (though I did use this to hide an easter egg in one section of the house).

The lesson here I think is to avoid making the levels at the last minute like I’ve done for almost all my games.

Wasted Effort on Cut Sequence

One of my regrets with this game is I never progressed enough to add in an extra sequence. It would’ve involved looking at Doctor Cadaver’s computer and noticing he had a chatroom window open in his browser. This is where it ties in with an odd dialogue option in Marvin Green’s dialogue tree where you can select the option “1-3-F?”. The player can notice one of the users has “13F” in their user info. And Hugh Mann being a clueless alien thinks this is a lead on the case. And if you’re familiar with 2000’s journalism and reality TV, you know exactly where this is going.

The player would then get to see a parody of an episode of To Catch A Predator, with the conversation the player had on the computer being read out of context as a creepy chatlog. And then the player would end up in conversation with a Chris Hanson knockoff.

I ended up recording all the dialogue for the Chris Hanson conversation, and a good chunk of the chatlog being read out. Sadly, I don’t think I’ll ever actually finish this sequence. It would be time-consuming, and I think leans a bit too heavily into reference humour, something that plagued Ja Wizardman.

Future Plans

For this game, my only real plans are to add the ability to skip dialogue lines and maybe cutscenes, add fixed player positions in dialogue, and maybe add a few more animations/facial expressions to make some dialogue trees less dull. Beyond that, there were no major complaints. And I don’t think I can really improve the game without fundamentally changing it.

For future games however, I think I got a lot of valuable lessons out of this project.

I learned the basic usage of Unity Timeline and I plan to use it in the future. I would love to do some scripted sequences where the player has full control of their character like Half-Life. And attempting something like the little first-person cutscenes transitioning to gameplay like Metro or Halo 3: ODST would be a fun experiment.

After discovering all the pitfalls of the DialogueGraph tool, I’m considering possibly rewriting it. I know where the UX pain points are so I can avoid them the next time around.

For the dialogue system itself, I think it worked quite well, and I plan to polish and expand upon it in further projects. Already it can do more than I showed off in Hugh Mann, but with some more polish I think it could be far better.

For next years SBIG jam I honestly don’t know what I’ll do. After taking combat about as far as it can go last year, and then going the exact opposite direction with only dialogue this year there’s no set major goal I’d like to improve on. I have a few ideas I haven’t used in past years. I could try to do some dumb stealth game in the vein of Metal Gear Solid, Alpha Protocol and Hitman. Possibly try another attempt at a melee combat game. I’ve considered experimenting with physics interaction like my horror project Sub Mortis. Maybe I could even get really out there and try some weird spell-casting game with a system like Arx Fatalis.

Or I could just continue with the dialogue system experimentation and try more conversations involving multiple characters. Whatever it is, I’ll likely end up landing on at least one mechanic I want to improve or experiment with and wrap the game around it.

I think the major lesson from this year would be to focus on a narrower scope, maybe closer to what Stalewater ended up being. Ideally next time around players should be able to see everything in the game in a single playthrough, and the game should be mechanically light enough that I’ll have time to add funny little details throughout the game. Of course, I’d also like to try to stick to what players have told me are the strong points of my games. There will be some dumb walk cycles, bad voice acting, absurd dialogue and hopefully at least one funny cutscene.

Whatever I do next, I hope I can apply the lessons from this year to make a more enjoyable game that hopefully is submitted on time.