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.