|
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.
0 Comments
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.. ...no promises "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. |
b r e n blogPersonal m u s i n g s. Project LogsTimeline |