Do Not Disturb: 1 Month Later - Post-Mortem & What's Next (LONG POST)

A few weeks ago, I finally accomplished a personal goal of mine: I finished and publicly released a game. Not some groundbreaking, genre-defining piece of peak fiction, just a game. That game was Do Not Disturb, a game I developed as a submission to the Anomalous Entity Game Jam about performing housekeeping duties in a hotel while constantly being stalked by... something. Although the game's development cycle lasted for just a couple of weeks, the actual core concept for the game goes back quite a bit further, and this devlog aims to be an opportunity to take a closer look into how the game ended up the way it did, what changes had to be made from the original idea, and what did and didn't work during development, as well as presenting some ideas regarding where I plan to go next.

But first, I want to extend my sincerest gratitude to everyone who downloaded, played, rated etc. the game. Even if you didn't enjoy your time with it or found more flaws with it than points of praise, at least I know that you feel the way you do about it because you gave it a chance to begin with. And, at the risk of sounding like a broken record, this is my first ever attempt at releasing my own game publicly after having been trying to put anything out at all over the past year, so the fact that the game has gotten as much attention as it did is still really encouraging to me. 

So, thank you. All of you.

Anyway:

The Concept

The original idea for Do Not Disturb was heavily inspired by not one specific game necessarily, so much as the ever-emerging genre of short-form horror experiences that have been popping up quite a bit on itch.io, among other platforms. A particular source of inspiration for me was the various Haunted PS1 Demo Disc releases, which each contain a variety of short, playable demos for then-upcoming indie horror projects.

Do Not Disturb's initial concept would have seen the game's story progress over the course of several days/shifts. The gameplay loop would mostly have been the same as in the released version - complete a pre-determined list of tasks within the hotels various suites while the entity stalks and occasionally directly attacks you - however tension would gradually rise over time through either more/different tasks to complete, or more elaborate and less subtle scares. For instance, what would start out as small, subtle changes behind the player or just out of the corner of their vision, would eventually become entire rooms being warped or transformed in some way. Each level would also be separated with story moments such as conversations between different characters that would shed further detail on the story as it progresses, and later levels could also see the player working in different parts of the hotel altogether, such as penthouse suites, where additional hints towards the game's background lore could potentially be found.

When the game jam was first announced, I used the days leading up to the start date formulating ideas I could pursue should I decide to participate. One of the first ideas I had was about someone having a VHS delivered to their house, and putting it into the VHS player would show on the TV the POV of an entity outside your house which you would then take control of, but needless to say I didn't go very far with this one. Then I remembered I already had an idea that could potentially work in the early concept of what would become Do Not Disturb - the base idea would need to be cut down to a scope that would be reasonable to develop in such a short time frame, but with ideas for the mechanics and structure already in place, at that point all I really had to do was start actually making it. That was the moment I had fully committed to participating in the contest and releasing my first ever game.

The Good

- Going in with a 'less is more' mindset

Normally when I have a crack at developing an idea in-engine, scope/feature-creep becomes very apparent VERY quickly, and I end up hyper-fixating on what I think would be cool or fun to see regardless of how practical or feasible it might actually be. But in this case, with a mostly-complete concept and a limited timeframe to make it happen, I knew the best course of action was to scale down, not up. If DND was going to see the light of day in time I had to focus on what absolutely needed to be there and put every ounce of energy I could muster into just that and nothing else. I knew the game needed a simple, linear level and a simple, linear objective to accomplish, with different spooky things happening around the player that might be dangerous sometimes, have some UI elements to help the player get around and that's it. If it didn't need to be present for the game to function, it got cut, end of. To make things a bit easier, I gave myself the rule that, during a typical play session, the game cannot be longer than 20 minutes. This one rule ended up being the ideal reference point for what kind of content would be considered unnecessary for the game to be considered 'complete'; the idea of multiple levels, including a tutorial, was scrapped so all of my effort could be focused on a single, bite-sized experience.

 - Time management

At the time I decided I was going to participate in this contest, I had only recently started working a part-time job working roughly 25-30 hours a week, especially since the summer holidays also starting around that time meant a significant uptick in working hours. This left me with a very limited amount of time that I could actually spend working on the game within the two-week development period which I had to ration out very carefully. I ended up working out a system where every day that I could spend any amount of time would be spent on a different part of the game. For instance, the first day or so was spent designing the level layout; since I knew the level would need to be quite simple I knew I would be able to bang it out in a few hours at most even if I were at that same day. Another day was dedicated to decorating the level with some starter prop assets , then the player character and basic interaction, then a simple user interface, then sourcing sound effects, etc. Most of the game was finished a couple days before the deadline, with the only outstanding tasks being some last-minute polishing and then packaging the project for release - admittedly, packaging the game ended up almost becoming an all-nighter session just to ensure that there would be no last minute issues to resolve (thankfully there weren't, everything worked first try), which turns out to be a bad decision when you have to start getting ready for work less than eight hours later. This balancing act left me with basically no leisure time whatsoever and I'm pretty sure I would have crashed out hard if I worked on the game any longer than I did - seriously, I would never recommend this kind of crunch-culture work ethic to anybody, and I feel extremely lucky that it ended up working out for me in the end - but having the discipline to get something done every day I could meant that at the very least I was able to get the game finished and released on time at all.

- Sticking to what I know

As someone whose skills strictly lies within, a), using the Unreal Engine Blueprints system, and b), being able to make gameplay functions work without necessarily looking great, I decided not to waste time trying to learn entirely new skills and instead simply focused on what I know I can do with minimal guidance. I know how to create some basic object interaction, I know how to get some rudimentary RNG going, and I know how to create persistent variables that can be used to track the players' progress through the level; I pretty much went in already knowing everything I needed to know to get the game's primary loop working.  I also have some knowledge in using image editing programs like Photoshop, so creating some simple textures and UI assets wasn't too much of an issue either. However, I don't know many advanced techniques for sound design, creating materials or building 3D models, which basically gave me a reason not to focus on anything outside of the actual gameplay rather than trying to learn basically a whole new craft altogether. I have plenty of time ahead of me after the contest to potentially develop these skills later, and trying to do so during the contest where every second I can spend working on the game counts is futile. The game would have seriously suffered in quality, or more likely would never have been finished on time, if I attempted to teach myself how to use Blender or something on top of everything else I needed to do.

The Bad

- Art assets weren't done in time

As I already mentioned previously, I am not proficient with 3D art or modelling in any capacity (I dabbled a bit with Maya during my time at university, but that was close to a decade ago now) Any models that needed to be created I left in the hands of my brother Lewis 'Malrat' Deane, who not only is self-taught in 3D modelling and even went to study it further at college and university, but also has a LOT of prior history working on the Five Nights at Treasure Island series, among other projects. He knows far more about 3D asset creation than I do, but unfortunately due to him being preoccupied with other projects while also working a part-time job of his own, we had very little time to complete many of the models needed for the game. The one he managed to get done in time, the laundry cart, was done in just a few hours only a couple of days before the deadline hit. Most of everything else however, mainly the various bits of furniture in the various suites, simply use either basic geometric shape meshes or default Unreal starter assets, which results in a visual style that clashes with itself quite frequently and generally just doesn't look or feel very polished. Thankfully though, I did at least have some other assets which he had made for me previously for some of my other projects, namely the shelves in housekeeping and the various models used for the trash, which I was able to reuse here.

- Bugs introduced through unnecessary changes

So here's a fun fact: when, in the Unreal Engine, you create a new character blueprint, the default values for variables such as the size of the collision component are set the way they are for a reason, and messing with them is generally a bad idea. As you can imagine, I learned this one the hard way. For context, the default proportions for the character blueprint collision component are 88 units in height and 34 units in half radius, however I decided to reduce the half radius value to make it easier for players to move through doors and smaller gaps without getting stuck. However, this ended up having the unintended side effect of causing the player to sometimes get stuck in the floor and slide around, usually with no input from the player. When combined with how easy it was for the player to unintentionally climb onto objects, this became a very common and annoying bug that was experienced and reported by just about everyone who played the game, to the point that I suspect it ended up harming the game's reception in the long run, all because I decided to fiddle with the player character collision too much. When I came back to patch the game after the voting period ended, just resetting the player character collision to it's default proportions fixed the problem almost entirely. I was taught a valuable lesson that day; some things really are just better off being left alone unless you really, REALLY need to change them.

- Too much cut content

As previously discussed, major concessions and compromises had to be made to ensure the game could be finished and released in time for the submission deadline. However, whether it was due to time or just lack of the required expertise, there were a few cut features that could have feasibly been implemented, but just couldn't. A big one for me is the lack of an actual opening for the game, or any story content at all for that matter. An idea I considered for a while was recording a fully voice-acted introduction scene from the perspective of the player character that would have added some context to why they are recording themselves going about their regular job duties. Visually there wouldn't have been much going on on-screen, but the scene would have at least been subtitled as well. I ended up not going through with this due to, a), my lack of confidence with working with voice acting, and b), because the limited time I could spend working on the game means that trying to work an entire cutscene into the game would have deducted from time I could spend polishing the gameplay. Still, I do regret not having the game's context not presented anywhere in the game itself rather than part of the blurb on the game's download page where people are more likely to miss or ignore it.

As for actual gameplay, I did want to include at least a few more random scares in the game to add some variety to the gameplay loop. One that didn't make the cut would have caused the showers and/or taps in the suite bathrooms to suddenly start or stop running water on their own, as I wanted to incorporate the bathrooms into the gameplay more than just being where the player restocks the towels sometimes. However, getting even very rudimentary looking running water going turned out to be more complicated than I was prepared for, since it likely would have required working with more complicated materials and particle effects than I know anything about. Other potential scares that were considered but never implemented included objects being thrown around, drawers suddenly opening or closing on their own, room lights turning out completely (this one actually was implemented at one point, but was removed since it ended up being too dark for the player to see anything) and even physical alterations to the level itself such as writing appearing on the walls. At least one additional 'task' for the player - restock the suite's stock of refreshments - was also cut since there was nothing really differentiating it from the tasks that were already there, and it just felt redundant. Because of how many potential ideas ended up being cut, the final product ends up feeling very 'samey' and doesn't lend itself well to replays, which in my opinion is fine for a game developed specifically for a game jam but still feels like a shell of the game's potential.

The Result

Above: the number of downloads and page visits the game received between it's initial release and the end of the voting period.

Between the game's release (2nd August - the same day as the deadline for the development/submission period) and the end of the voting period (12th August, 10 days later), the game accrued a total of 538 page visits, 188 downloads, and 11 user ratings. When the voting results were revealed a few days after the end of the voting period, DND was placed #14 out of 24 entries, with a rating of 3.2 out of a possible 5.

A lot of the praise the game received was directed towards the concept of completing a mundane activity with a spooky twist; on at least one occasion the premise drew comparisons to other, more prolific horror titles such as The Mortuary Assistant. I was happy to see that the idea resonated with players at all, since one of my primary concerns was that such a simple concept would not be appealing enough to draw potential players in. After the game was initially released, I attempted to draw attention to it through various posts on Twitter/X. This was effective to a fairly limited extent, although analytics determined that the majority of the page visits were sourced from itch.io itself.

The big point of criticism with the game was just how many bugs were present at release; even with my release of a last-minute patch to fix one of the more game-breaking issues, bugs such as the 'sliding in the floor' glitch were extremely common, to the point that I believe they were one of the main factors in the game's final rating being lower than I believe it could have been. The project was indeed fairly rushed towards the end of the submission period and I did run out of time to troubleshoot everything I could have done, but perhaps the worst part of this is, as detailed above, the most common and annoying glitch in the game was entirely self-inflicted and could have been fixed in a matter of minutes, so in retrospect the fact that such an issue that could easily have been fixed tainted the game's reception to such a degree is by far my biggest regret with the game itself. Beyond this, another criticism I received was that the game is repetitive to the point of tedium which, given how straightforward the game's objectives are, was not surprising at all especially since I myself had to play through those same objectives constantly during playtesting. I did consider ways I could spice up the variety at least a little bit, but as detailed above I simply lacked the time, and in some cases skills, to make them happen. I feel that the game's reception would be a bit better if there was at least a little bit of additional content to add some more diversity to repeat playthroughs.

What Next?

So now there is only one more thing to consider: where to go from here? Well for starters, since I very well nearly hit full-on burnout while working on this project due to literally giving myself zero leisure time between working on DND and working an actual job, I have been taking a little hiatus from game dev-related work from the time being (aside from the occasional patch for DND, although I do consider this specific project 100% finished now). Not indefinitely, mind you - I plan to start gradually slipping back into the groove once the summer holidays end and work starts to slow down - I'm just kind of sick of looking at Unreal for the time being, especially thanks to another project I have been working on for almost a year now, which I'll go into detail about below. Hell, even just writing this devlog ended up being more exhausting than I expected! Once I get back into it though, I have a few ideas of what I might do next. Keep in mind, nothing I say here is definitively set in stone and it might not EVER happen, these are literally just ideas at the moment:

A full version of Do Not Disturb that fulfils the original, complete idea.

After I released DND and started talking about it with people in my personal circle, the most common question I got in response was along the lines of, "Is it just a demo? Will you do more with it later?" And even in some comments I received, a couple of players have also asked if this idea will be further developed in the future. And I can definitely say, that I am, at the very least, actively considering it. There are a LOT of ideas I thought of when writing up the initial concept for DND, and yet only a fraction of it actually made it into this released version. Now that a version of it actually exists though, and I can observe it as a tangible product rather than just a vision in my head, I can objectively see where I could make further improvements and additions in a potential full version:

• Taking place over the course of several shifts, while treating the original game jam version as a sort of 'prologue' that occurs before the main story. The game's story would take no more than an hour or so of play time to finish.
• Implementing features that couldn't make it into the game jam version such as additional random scares, story content and perhaps some more varied objectives.
• A more refined art style, with minimal reliance on pre-existing starter model and texture assets.

Since most of the mechanics are already there and would at most need some fine-tuning, I feel that if I wanted to get a more 'complete' game out there in the future, I do think adapting a concept that already has at least a small amount of pre-existing attention would be beneficial for myself and my portfolio in the long term.

'I See You!', an entirely new original game.

Above: footage of the latest version of I See You!, as of June 2024. Note that this version of the game is considered to be in the prototype stage, everything is still a work-in-progress and NOTHING in the above footage should be considered final.

About a year ago, I started work on a game called 'I See You!' with the full intention of releasing it on Steam at some point. However, the idea just gradually grew over time (as mentioned above, scope creep is a big problem that I'm still trying to figure out) and even now it not only remains in a prototype stage, but for the sake of getting DND released I've actually been taking an indefinite break from working on it as of late. I'm happy I did this, as releasing a smaller project in the meantime at least feels like I managed to accomplish something meaningful after the past few months, but seeing it in such an unfinished state even after all this time makes me want to get back into it sooner or later. 

The gameplay loop is simple: you're given a list of a few randomly generated NPC's out of an entire level full of them, take a photo of each of them to proceed. There are a few other... twists that the game would take over time, but that's the general gist of what the player would be doing most of the time. The game would include two modes of play: a 'story' mode that takes a minimum of roughly a couple hours to complete, and an 'infinite' mode that plays out as a more arcadey take on the gameplay loop where the player completes as many successive 'sets' of photos as they can until they run out of time or run out of photo film.

Future game jam games? (Maybe)

When I decided to participate in the Anomalous Entity Game Jam, I only did so because I had an idea that I thought would work within the given theme. It's an idea that I had come up with a while prior and went through various different iterations before I was happy with it, and even then a lot of it had to be cut out just so the game could be released before the deadline. If I were to participate in another jam in the future, I would have to commit to an idea I actually feel has at least some potential rather than trying to come up with something on the fly, realising halfway through that it won't work and either banishing it to the backlog indefinitely or just scrapping it entirely. 

If/when other similar game jams happen in the future, I would only want to participate if I really have faith in a particular idea. Forcing myself to go through with an idea that I don't fully believe in will ultimately result in a poor-quality game and the feeling of not having progressed my game dev skillset any further. I'd much rather take time to come up with something, and then put it to practice when a suitable opportunity eventually presents itself. How long it will take for that to happen, or what, if any, kinds of games I'll put out in the future at all, even I have no idea right now...

...that's for time to decide.