Just like the rest of aspirational game devs on the internet, months ago I got hooked on PirateSoftware's dev advice shorts and streams. I then quickly noticed that he was hosting a two week game jam in January. I already spend plenty of my spare time these days working on a variety of personal dev projects, mostly to learn but also to constantly stretch my creative muscles. So, I decided I should finally partake in one of my major regrets of missed opportunities from my time in college, hunkering down to partake and complete a jam game.
This was also hugely motivated by my recent foray in trying to learn Godot. Its name has been tossed around a lot lately, and during the big unity price debacle last year, video tutorials for it have absolutely exploded online. I was also reminiscing of the few 2D projects I worked on back during college and wanted to try to return the simplicity and accessibility I remembered with 2D prototyping. The great news was I learned quickly that Godot's structure, interface, and built-in scripting language were incredibly accessible for me to learn quickly.
Expecting I'd likely be working solo on this jam, the spare time I had to learn the engine over a month or two actually had me feeling comfortable with the idea I might actually manage to complete something within only two weeks. Ironically after inviting a handful of college friends to join, they surprised me by actually taking up the offer. THOUGH, with a team limit size of 5, and exactly 5 of them wanting to join, I ended up going solo anyway for the sake of not overcomplicating our team make-ups.
The theme was announced as "It Spreads" - immediately sparking a handful of ideas to me. Though what I settled on was an idea inspired by a nightmare I had as a kid. An infinite ever-growing black ooze chasing me and my best friend as it spread across the entire world. It fit the theme, I liked the horror, and the idea I thought was an effectively fully-formed concept out of my own memory. Most importantly, I had a decent idea of how to implement the titular mechanic of "spreading ichor", namely by utilizing a tile-based movement system for the core gameplay. I'd never done anything with tiles and Godot clearly has a ton of functionality for it so I leaned in.
Two weeks later and I had Ichor to show for it!
Though "fully-formed" is funny to think back on. In reality I had the concept for a mechanic (the tile-based ichor spreading), a nightmare tone/atmosphere, and a narrative theme? There was no core gameplay loop before I was heads down prototyping. Which I told myself was to see if the core system was even feasibly scriptable with my limited understanding of Godot before "committing" to this pitch. Which was fair, but I really didn't have too much intent to pivot, only intent to learn the scripting until my systems worked. Once it did, I would figure out gameplay from there. The bright side was my "tertiary" mechanic of "also you can push objects" happens to be a quite common one with regard to tile-based game tutorials. So despite my grab-bag of other scripted mechanics (water dissolving the ichor, light freezing it, swapping characters to act as two inventory spaces for picking up and using items like water buckets which could empty and be refilled, etc.), the last few days of "aghhhh what is the core gameplay loop besides the ichor spreads and kills you", quickly slipped into "ah fuck it, its just a sokoban". Spreading ichor and pushing blocks were comforting as my two reliably functioning mechanics as I was crunching to design levels and Paint 3D as many extra environment tiles and object assets before time was up.
Speaking of which, I think I moderately paced myself as I planned work for these two weeks.
Until the end of course. I had enough functional mechanics for a game to submit, but I was just REALLY greedy for my tertiary mechanics and a moderate number of decently paced levels (which I for sure shit the bed with regard to pacing the last two's difficult spike). I did more crunch in those last 3 days than I've literally ever done in my entire professional career (thank god really). Though in that way it also made me sadistically nostalgic for my college days all over again. Working creatively on something I'm passionate about, constantly learning and honing hard dev skills, having the camaraderie of some friends working towards a similar end, and willingly working way more on way less sleep than I ever would in exchange for money.
It was for sure the closest I've felt to being back to the feeling of working my college senior capstone. A fulfilling, if not exhaustive high I undoubtedly missed. The important differences being (thank god) it was limited to two weeks, and more sadly that I didn't have dev-friends DIRECTLY working by my side through it all. I'll certainly be continuing my own solo personal project work in the mean time, but I did have them promise that should we join another jam under Pirate Software again, I'll make sure to not force myself into solo dev that time around.
Lastly here's the ITCH page with download file to play and a PLAYLIST I made of various work-in-progress videos of my mechanics scripting. In hindsight I kind of wish I directly blogged each session of work to a new dev-log page publicly here, but my notes in the design doc and videos made to share with friends will have to be it for this time. ADD IT TO THE PILE OF LESSONS FOR NEXT TIME.
PS - big thank you to Emma for the kind favor of providing character art and Ben for allowing me to use his guitar riff audio as the base for tense nightmare background drones.
PSS - check out the other jam project Ben and other friends of mine also worked on together. Its called Germ Town and its a 3D twin stick about fighting off an infinite horde of multiplying germs.
I've fiddled around with a variety of unreal project on and off for years. Primarily for fun and minor dev experience. Naturally while trying to learn more about best practices, blueprint coding, and the engine in general. I've had plenty of aspirations while brainstorming, but ultimately know right now its all hobbyist. That said I've lamented not at least trying to document any of it. Especially since I've waffled across a few projects based off fleeting inspiration a couple of times now. (All which I tell myself I'll bounce back to when the mood strikes - we'll see about that lol). That said I know I don't have the time or focus these days to write thick paragraph blogs like when I was unemployed in 2019. So the goal is just to really document anything I've made/working on in a given moment in the barest of terms. While doing my best to avoid the waxing poetic or ramble about theory.
Beyond just making separate posts each of the unfinished prototypes I've worked, am working on, or want to work on, I want to try my attention span at a log of sorts. Since everything I do is only a few hours of free time at a time, I figure each time I call it for the night, it shouldn't be too hard to make a simple log of the date, time spent, and basic work summary. Like a repo change list description I suppose. I think I wanna do this half because its motivating to see my tangible time commitment/progress, and half because it'll be any amount of discipline for me to keep while working on anything. I have to imagine that's a step better than my scatter-brained google-design-docs or writing myself task lists as unreal blueprint comments.
ALSO, I've always wanted a legitimately well polished and presented portfolio piece. Like ya know, like a professional level designer might have. Every professional work project is vastly different, shrouded in the development process, and I suppose that makes me miss the days of "showing my work" in college a bit. An attempt to actually measure my design's quality and maybe even time investment (roughly). So the current prototype I've been fiddling with should be the subject of these first "log" blog posts. That project is an unabashed dishonored-like in UE5, first person, prioritizing stealth gameplay, and thoughtful level design. Stretch goals feature Immsim design philosophy for systemic interactions if I don't get completely lost in the sauce (I will). Genuinely though, in the spirit of discipline and posting something I'm actually proud of here, I'm gonna try to focus only on vertical slice mechanics that serve it being a level design piece over systems. Regardless of how many world building and story theme notes I've already scribbled in my google-design-doc.
Here's video of my first pass of the first priority for me for this. Climbing <3 Was genuinely proud of myself for managing to get this working as quick as I did. Only a few hours the first night sat down to work on it. To be logged here.
I've had a few ideas of what would make a "scary" encounter in a horror game, but the one that's stuck with me the most involved an entity "enemy" subtly entering the player's view and notice, and then quickly leaving. Almost as to give them a sense of doubt in whether they actually saw it. In the early design stages of developing Dissonance as a horror, I loved the idea of manipulating this entity's presentation largely based off if the player was looking at it or maybe had noticed it. In VR, what the player's focusing on was one of the major tools we had. It's somewhat less-so the case in simple first person gameplay, but this project built around 4 distinct views and shifting between them seemed to still fit it. That plus the inevitable inspiration of every other forest horror walking sim being the original Slender, I decided to prototype the enemy as an entity that only moves while you can't see it.
It is always moving towards you, halting when you see it, and when you do 'see' it, its almost entirely transparent. It registers being seen and will subtly bleed away it's transparency to be more noticeable. Ideally catching the player's eye as a subtle shock and giving them the instinct to get the hell away. Which when the player inevitably shifts perspective to look away, there is a chance the enemy instantly relocates to a random location equidistant to their previous location and the player. It disappears, but is still following you with the exact same progress as before. Though now you may not know which way to run, so sprint and hope it's further away. If you do unwittingly get closer and then shift to check your surrounding, chances are you'll be GOTTEN by the enemy. Simply put, shifting while within a close range radius of the enemy will place them directly in front of you and freeze all player control away as a "Gotten" fail-state. So the player will need to keep their eyes peeled as to ensure they don't run away towards the newly relocated enemy. I believe I'll eventually give the enemy a set time to bleed in and then out of transparency. Enough so ideally the player notices, and then relocate itself automatically. This because right now it only relocates if the player shifts perspective away from looking at it. Therefore, the easiest way to keep away is to find it, stare at it, and walk backwards. That is certainly not the intended golden path. Right now the intention is simply to have the enemy present itself in a particular manner and pursue the player while not seen, all for the sake of frighting and disorienting the player during navigation. These enemy behaviors plus future systems of visual obscuring like the shift blur and sprinting shaky head should add the proper challenge intended for the player attempting to path through the forest from point A to point B.
Along the vein of challenging the player's navigation, the enemy "GOTCHA" fail state for the player will ideally be a bit less final than something like Slender. I do value the big scare of being seized by the trailing enemy, but really resent the release of tension the moment the player "loses" and has to start all over again. It's yet to be implemented because I still don't have much of an environment to properly test it with, but this fail state shouldn't end with a hard restart. The plan is to provide the immediate shock of the GOTCHA with the enemy suddenly staring them down just a step away, and then sharply transitioning the player to relocate randomly across the map, an equidistant range from their previous location and the end-goal. Sharp spike of frightening failure, immediate transition and maintained tension into continued gameplay, significant progress setback of unfamiliar location, and the setback mitigated by not being a hard-progress restart. Ideally something bound to repeat until the goal is completed as opposed to the game kicking you away for "failing" it. There's still plenty of difficult variables that can [and probably will] change this system depending on it's implementation, but that's the current plan for the core gameplay loop.
You may notice the current enemy has a face [eye and mouth], and that's partially because its somewhat unnerving but largely so I notice it during full transparency while testing. Eventually the final visual should certainly be perturbing, but also naturally camouflage with the environment a bit. This as to only barely be seen by the average player. I also love the idea of having the enemy's face/body/visage randomly change each time it's encountered, either slightly or entirely. Ideally to add a bounty of uncertainty to the player's experience as well as variety of uncanny valley art to the project. Something that hopefully won't be too out of scope if I continue to use 2D facing art assets at the enemy. We'll see.
The next tasks will likely be some systems work to more dynamically present/increase the blur and head shake depending on frequency of shifting and length of sprinting. Some more gameplay feel before I undertake building a proper environment to play in. At least I've bought some assets so I have an idea of what it will look like when I do.
Also the project is called Gaze now.
I've been working with Blur very on and off again for months. All while planning future gameplay systems, an ideal aesthetic, and an environment for this player perspective to navigate. Though all of those ideas are still just scribbles in a word document. My work in Unreal has been mostly focused on the core movement player experience. Where I'm naturally very excited by new design/mechanics to implement, I'm also hyper aware that the finer math and blueprint work towards a better game-feel is what I should still focus on.
After each few weeks hiatus of work, I'll need to pour myself back into the blueprint and remember how it worked and what I wanted to change. Though once I'm in those weeds, I properly feel the momentum and motivation to keep working until I know I've accomplished something. Whether that be implementing a new system or fixing part of one to work/feel much better. Though something on hindsight I can tell was getting me too deep in the weeds was the fine control of the limited look perspective. I still aim to work on and tune it, but decided to compromise with myself and implement ancillary systems still designed for immersion of the first person experience. These namely being foot step sfx, head sway, and sprinting. The sprinting I've had for a while, but paid significant more attention while coding the former systems to depend on it. This so the SFX and head sway would transitions between of "Walking" and "Sprinting" versions seamlessly. The current code is based off the player velocity to make said transitions and ensure the systems won't fire while walking up against rigid pieces of the environment.
In broad strokes, it all works as I want it to right now. Though, I again feel the pangs to tweak values towards feeling more natural. Like how the head sway currently doesn't match the foot step rhythm. I'll definitely tweak that, but I think another lesson hit home while finally finishing my footstep system. I was having trouble making sure it would reset properly as every possible transition happened in the code. While I did finish and had it working just as I wanted, I decided to share my gruesome spaghetti code to a programmer friend of mind (largely to disgust him). He was disgusted, but he also offered to help me rewrite it. It took what little was left of the night, but he completely condensed it to work elegantly. Leaving me to lament not being smarter than I am, but also wonder if I should really keep myself so bogged down in pre-polishing. Now largely aware that any system I write will likely be cobbled together and inelegant, should I really bend over backwards to make it do EXACTLY what I want before a programmer can even look at it? I KNOW how important systems polish is for quality and KNOW I'm better off ensuring it's done now over forgetting until it's too late, but...
this is a p r o t o t y p e to see if my design concept even plays well. It's forever satisfying to code a system closer and closer to how I see in my head, but it is still just walking. The intended player experience is more than just this walking. So for the sake of actually determining how this "90 degree look" plays with horror game systems, I think those systems will be my next major focus.
..AND/OR an actual environment to explore..
"Blur" is a game concept I've been ticking away at in my occasional spare time. It's core idea is a first-person looking system that uses 90 degree camera shifts to view and navigate the environment. The idea has been stuck in my head since walking across a Lake dam back home, where my four 90 degree perspectives were forward, back, lake, or rocky ledge. Each was clearly defined, and I had enough peripheral vision to contextualize which was left or right of each. It made me think about every dreaded horror game moment of transition. The moment of having to peer around the sheer corner, open the door, open your eyes, etc. The brief, peaking moment of anticipating fear after making the conscious choice to confront the unknown. I've wondered how effectively that moment could be distilled in a core game loop requiring you to constantly be turning that corner.
I'd been wanting to work in Unreal Blueprints again since College ended and this seemed like a prototype I could easily wrap my head around. After getting the getting the core movement to function as 90 degree shifts, I found it desperately needed any and all usability polish. The hard camera transitions were as jarring as you might expect. A lerp transition and motion blur helped a lot, but everything was still terribly rigid and locked.
If my intention is to give the player an experience leading to tense dread and fear, there needs to be a natural and comfortable status quo to leave or retreat back to. So despite my desire to implement new mechanics or start blocking out environments to wander, I've been head down in the math continuing to polish the core "looking" feel. I worked toward this by giving the player a tight cone of limited free look. Naturally it needs to be tight to keep the core intention of only seeing 1 of the 4 perspectives at a time. I also have the free-look very intentionally slowed to discourage stretching it's boundaries and keep the "looking" to feel more natural. I do recognize "feel more natural" sounds a bit silly when the core gameplay is about harsh and dramatic 90 degree camera shifts happening constantly, but that's the point of the prototype right? How intuitive and playable can I make the mechanic feel? and is the mechanic achieving the intended player experience I had in mind from the beginning? I still don't think I can say, but I'm glad it's potential is at least visible now.
Either way I'm proud and think it's cool, so I'll keep working it for as long as I do.