next »

[JobLeonard]

Hi, Leonard.

Definitely 100% on the same page as you on this. It's something that sprung to mind on the spot and made complete sense to do. A little personal backstory:, I used to live near a mountainous area which also had a dam. Visiting the area multiple times, I'd be in awe and get the "holy crap, this thing is big" sensation along with a dizzying feel when you look down in the abyss.

Yet when playtesting it, I did not get even close to that feeling. Maybe scale of that proportion doesn't translate well at all like how I felt when seeing that in real life. Albeit an easy fix to scale it up so it exceeds the size of the real-life dam, it should at least give a small fraction of the feeling when actually looking down a dam in real life. And it kind of does, but I'm only 20% satisfied.

Anyway, speaking of looking up the dam, here's a screenshot of how it looks.



At the bottom and slightly off-center to the left of the screenshot, you can faintly see an NPC. 

Hah, cool! So you actually have some real-world experience to serve as a reference for the feeling you're going for too! I bet that will help a lot.

I get what you're saying about not having quite the same effect, if the screenshot is any indicatoin. Have you tried changing the field of view? This can greatly affect the sense of scale

[baftis]

On, nonono. Looking up to it does give off a certain feeling. Here's how it looks properly.



It's looking down while you are on the dam that is underwhelming in the project. Or at least not even hitting the 10-20% mark of what it feels like. Here's how it looks looking straight down:



And here's how it looks while looking in the distance:



It's from about this point shown below that my brain actually starts to go "whoa, danger, back up" and has a small semblance of the feeling that you get when on a top of a dam. In real life units, it's 1000 feet/300 meters.



The problem is that it kinda sorta messes with a certain perspective that I really like. Let me give you some context. This is the reveal that at one point you as a player encounters:



To get this perspective, nothing is required of the player but to reach that point. It's also along the critical path. Every possible view that you can have of the dam up until the reveal is obscured by something (most of the time, there are some spots left).

Now in the context of a higher dam: standing in the same exact spot at the approximately same exact camera angle, it will look something like this:



The player is then required simply to look up from the exact same spot and see this:



At first you have your curiosity triggered, then the player looks up and hopefully has a "holy crap this is huge" feeling.

OK, now that I think about it and write about it, the second version pulls a double-whammy on the player and in the long run you get drawn into looking at it when you get the chance. And when the player gets on top of the dam, it definitely sells the feeling a lot better, so it's actually a triple-whammy. This definitely gives the player more bang for the buck than just the pretty perspective from the prior example (a perspective that properly respects the rule of thirds, but done to the best of my abilities as a non-photographer/artist/shot compositor)

Oh and yes, I've tried the FOV thing, it doesn't do it justice but weirdly enough it makes the game as a whole feel different. My default FOV is 90. Toyed with it from 70 FOV until 120 FOV, but at 110 FOV, it just sends me down the vertigo syndrome road. 80-85 works OK, but make smaller objects feel bigger. When I'll get to it, I'll toy around with the 90-110 range to settle on a default setting for the FOV slider.   
 

[JobLeonard]

This probably just looks horrible and/or cause motion-sickness in practice, but I'm going to ask anyway: what if looking down subtly increases the FOV? Like a dolly zoom

https://en.wikipedia.org/wiki/Dolly_zoom

Then you could make down look far down, while keeping everything else "natural". Plus people are kinda used to it from films already

[baftis]

So I tried the look-down FOV thing and...it doesn't look good. Check it out:

https://drive.google.com/file/d/1hypAtBDO55ntaHOl5oKJsIL5MOks3mFy/view?usp=sharing

Not judging by the fact that it is not a smooth transition, but judging strictly by the difference in FOV, it's not giving any vibe whatsoever. It's not horrible per se, it doesn't give any motion sickness (and I should know, I do have internal ear problems, so I get vertigo from time to time) it's just wonky.

Now, the dolly zoom thing...that's a totally different thing from the FOV look-down change. That's because you need two components: 1) a moving camera 2) a zoom function. Said camera has to move forward while zooming out at the same time. So there's that... Couple this with the FirstPersonCamera which has no zoom function and there's the dead end. Although there is the Cinematic Camera in Unreal that has the zoom function, but engine documentation does not recommend using this as a gameplay camera. For what reason, I don't know. 

But thanks for the suggestion, anyway. You were definitely on to something. I'll keep this in the back of my mind, maybe something else will come out of this. 

[JobLeonard]

Ah, yeah, I forgot the part where a dolly zoom also needed extra movement . But good that we tried, right?

[oahda]

I think it might just be down to size like you said, like the area just needs to be bigger and taller but of course that'd mean a lot of work moving climbing sections around and filling the space out with more assets I keep struggling with this myself, always making things too small at first when modelling them and don't notice until I actually play. And yeah, dams IRL are mindbogglingly huge… Tricky stuff!

Either way I think the place is coming along nicely and looking real pretty with the waterfall and the dam and everything!

[baftis]

Hey, Prinsessa.

Thank you very much. I'm still working on scene compositions, though. I feel that they could be a lot better. It's a good start as it is now.

And yes, there are very few alternatives left to approach this particular area that will give off the vibe I'm looking for. At the moment, scaling it up is the only real option, along with adding a layer of fog and some other stuff to accentuate the height even more. Moving the climbing sections will definitely be a challenge since there is a lot of space to cover (300 meters/1000 feet tall, 200 meters/650 feet wide).

An equally colossal problem would be the fact that once you reach the top, you would see literally everything. Which presents the obvious problem of frame rate drop. The game, as is now, runs smoothly in the editor, between 70 FPS and 90 FPS with everything else built except the light. I don't build the light because it takes a ridiculous amount of time to build it, given that these two levels have 600+ trees. The resolution I think is 720p, but I'm not sure.

The background is non-existent at the moment but once it's filled up, frame rates will drop by half, for certain. So from now on, for these levels, I have to think in economy/optimizing mode: level streaming, billboards, maybe more efficient LODs and more in terms of numbers of LODs as well. Maybe mask the ground below with clouds. Applying all sorts of optimizing trickery, that kinda stuff.   

[vdapps]

Hi baftis!

I stumbled upon your thread for the first time, I read your very first posts and then step here to last posts to see your progress. Your devlog is very nice and you're very dedicated to this, I hope you'll finish the game well. I like the idea of the game as well as scenery setup. It reminded me playing Firewatch.

Do you plan to put just puzzles/obstacles as goal to reach the mountain or do you intent also to place some strong story behind?

[baftis]

Hi vdapps.

I'm grateful that you've stumbled upon my devlog and that you found it worthwhile to check my progress. And I hope future devlog entries will be worth your time in the future. I'm glad that you found it nice. It's my first devlog so I try to do my very best. Also, your compliments are a great reminder of what genuinely nice, warm and supportive people make up this community. Thank you very much.

The Firewatch comparison is on point. As an elevator pitch, if Firewatch and Celeste had a baby, Against The Mountain would be the baby.

I do intend on placing a strong story behind the gameplay, but at this time I only have a vague idea of the premise. It involves finding a group of missing persons: one who is a hot-shot physicist and also the main antagonist. Also, four of his associates, who are also physicists. Along the way, you as a player will discover the main antagonist's wrongdoings.

The backstory that makes the game's narrative exist is that these physicists made a breakthrough discovery, but shortly after disappeared without a trace. Decades after their disappearance, the player character comes into contact with evidence that they are in fact still alive and is dead set on finding them. 

I also plan to have an AI helper (think Alyx from Half-Life 2 in terms of gameplay and Delilah from Firewatch in terms of story) dropping in occasionally to either help the player character, propel the narrative forward or to work in tandem with the player character. 

This is as much as I can tell you because this is also as much as I know and want in a definite, concrete manner. There are some details like names of characters thrown around. But the names don't stick around too much, so they get changed a lot. Except the name of the actual mountain, which is Mt. Timor.

At the moment I'm more in the headspace of fleshing out the gameplay and the play space. I find that, while it is nice to take a break from what I'm doing on the project and daydream about the story and visualize elements from it, it's pretty difficult to juggle between working on the story and working on the gameplay. Once I'm done with gameplay, the next move would be to focus on the story and how it's delivered.

[baftis]

DAY 47

Not much done today in the project itself. Spent more time planning out the Dam area, including what mechanics to place there. One concern is that, with the height of the dam being increased, this leaves more space to cover when "escalating" the dam. I say "escalating" because it is clearly evident that simply having wall climbing and ledge climbing is both not enough and too much at the same time. It's simple, really: more variety is needed so that the section will feel dynamic instead of a slog.

So I found something in my Unreal Marketplace library and wanted to give it a shot. Namely some retractable floor spikes:

https://drive.google.com/file/d/1czjPM37WlahmSk_376HRMCd8L8AItOE_/view?usp=sharing

This is something I wanted to make for the latter levels of the game. But as I saw that it was in my library, I'd figure I'd give it a shot to see how it feels. And it's quite OK. In series, with offset time, they look like this:

https://drive.google.com/file/d/1p-JH26N3iXFcOcFyKCdkHAgQdzvv6Xcf/view?usp=sharing



Now "Baftis, you dashing and dapper designer!", I might hear you say, "You've mentioned before that you are concerned with things being thematically appropriate, and this mechanic is not thematically appropriate". Well... no, you don't find retractable spikes growing naturally in the wild, so that means they must've been placed there by someone...maybe the villain?...Hmmmmm

Anyway, making this mechanic is something very easy to do.

1) You have two separate meshes, one for the ground plate and one for the spikes. Yes, all the spikes have to be as one mesh, we're not sadistic here.
2) After the models are done, place these models in a blueprint with the ground plate at 0,0,0 and then the spikes at 0,0,0 as well.
3) Then, move the spikes down so that they are covered by the ground plate.
4) Take the Z value from the spikes as they are now and then use a float variable for the Z (where you want the spikes to go) on the set relative location node. Toy around with the height at what the spikes would be at the surface, I forgot to mention that earlier. Put these two values as the start and end location of the spikes.
5) Add a Damage Volume to the Spikes (place it so that the bottom of the volume matches the bottom of the spikes)

And you are basically done. It would take more to write the tutorial for this than it would take me to actually make the thing. But I was lazy af and procrastinating with this mechanic and I figured "Eh, why not?", so I just downloaded. Oh, and I say "basically done" because you do have to account the animation for the spikes, too. But it's a functionally sound death trap you've got there. Quite easy. But don't take this as a step-by-step tutorial, because it is definitely not. Take it as a "high-level" overview, if you will. 

I would actually tinker in the blueprint to see what's under the hood. I'd like to add different (or separate) times for the delay of the "spikes up" and "spikes down" animations.

I also did some asset replacing today. This was solely because the player character had trouble with all the old blocky rock assets.



Recall this section of the first level and observe the very angled edges these rocks have. These edges threw the player way off when jumping on them. Of course they did, they're almost a 45 degree angle. So I replaced them with the rocks from the level I was just working on previously. And now the area looks like this:



But there was a wee tiny problem. You see, those particular assets were like 100 times smaller and with their pivot way off in the distance.

So I had to do manual replacement, instead of selecting the asset and replacing the mesh in a drop-down menu. But I can't complain, it took maybe 3 minutes and it was actually very relaxing and satisfying to do.

I've gathered all my energy to attempt and finally fix the rope swing and....nothing. Still wouldn't properly work. There's something that just doesn't work properly when letting go of the rope. I still have one ace up my sleeve. If that doesn't work I'll have to scrap this version and start over....ugggghhhhh !!

Although I got it to work at one point and after all this amount of work, it dawned on me that this mechanic kills player momentum. Or at least has the potential to do so, depending on where you place it in the level and after what mechanics you place it after.

If my last ace up my sleeve still doesn't work, I'll just duplicate the Grappling Hook mechanic and make it so that the player can shoot a rope that he can swing from. Might use it as an alternate fire kinda thing. If for example the Grappling Hook is triggered by pressing Left Mouse Button, the Rope is triggered by pressing the Right Mouse Button. This on paper sounds more fun than simply finding a rope in the world. Pressing Space would detach the player from the rope.

So that's all I've got for today. See you guys in the next post, bye.

 

[JobLeonard]

I think the main issue with a spike trap is that even if it is placed by a villain, it's quite an elaborate technical contraption that requires maintenance. Having it out in the open where rain, wind, soil would very quickly make them fail would feel off.

Do you plan on having sections where you have to traverse something human-made, like a tunnel, or the inside of a building? I can imagine that scaling the dam involves climbing non-natural structures for example.

[baftis]

Hi, Leonard.

Hmmm, you do have a point, there.

I did thought about having at least one of the dam sections playable on the inside. Researching through pictures as a reference, I quickly realized that I know exactly nothing about what goes on inside a dam. But that's not an impediment, it just means I need to do more research.

And it's a certainty that I will have at least a cave level. And hopefully have it procedurally generated in the final version. But for now, it will be a classic static area, the cave(s).

Having those retractable spikes in either the dam interior or the cave(s) would make much more sense. Welp, back to the drawing board. And thank you for the heads up, an observation like yours totally eluded me. 

[baftis]

DAY 48

Been wearing quite a few small and different hats since the last update. Mostly level design, game design, project management, a tiny little bit of modeling (I'll get to that later), bug fixing... you know, everything and anything in between.

1) Level Design: I've been attempting to continue working on the Dam area, but this has proved mostly unsuccessful. Everything that I threw at it just didn't stick...well, mostly everything. I tried implementing the wall running mechanic I did a month or so ago, but I built the wallrunning mechanic into the FirstPersonCharacter blueprint (which by default is deactivated) and could not get it to activate in the Level Blueprint. There is definitely something so obvious that I can't see it. Will definitely try again later. The mechanic works as intended, for those who didn't read the post about it. Here's a video of it in action.

https://drive.google.com/file/d/1qNvoi0UCmOJZbicYhzglptBN3fXfRDXh/view?usp=sharing

There's something about this area that pulls into the "transitional area" design. It keeps wanting that, even though there is so much potential for mechanics here. I'll leave the "transitional" design for last on the list, an "if all else fails, use this" option.

I also had the idea of creating some modular blocky assets to serve as placeholders for a dungeon-like cave exploration level. L-shape, T-shape, I-shape, plus-shape, U-shape, you name it. Square rooms, rectangular rooms, round rooms and the list goes on and on. 

This would take 2 hours or so, but maaaan, it's gonna take a looooong time, with the amount of iterations I have to make in order to pull off a good cave level.

2) Game Design: So one of the new features I thought I'd add is a Hang Glider. This adds to the "movement, motion and traversal" philosophy I keep banging your head about by way of allowing 6DOF movement (something I don't have at the moment). Possibly having some upwind bits a la Zelda BOTW.

And I do have a clue or two about how I'd make this: If falling and when equipping the glider, the player character would actually have only a quarter of the gravity (or at least a lot less) than the current gravity amount and will have slightly increased air control. Should be easy peasy, this one. I mean, I hope it will. I don't know about the upwind bits (hopefully a Launch Character on the Z axis will suffice, given that I'm avoiding wind physics altogether)

3) Bug fixing: so I pulled my last ace up my sleeve with the rope swing and it just didn't work. I have no idea where the script went wrong, and I looked everywhere to the best of my (limited) ability. But I'm not giving up on the rope swing just yet. I'll just have to re-think the entire thing, starting with using the Grappling Hook base script and altering it so that it fits the rope swing description. The target would be for the new rope swing to play like the grappling hook, maybe having Left Mouse button for grappling hook and Right Mouse Button for the rope swing.

4) Modeling: Hey, remember a little bit earlier when I said something about a glider? Well, did some prototype modeling for the glider as well. Check it out:



I know I messed two things up (no tail on the glider and the handle bar is not big enough). I wasn't really paying attention to the details and was like "I just want this done, and fast". This was mostly done so I could feel that the project is moving along, even if slowly.

Because that's how it felt like, like I didn't do much to impact the project lately (albeit I did take some time off two days). But this week definitely paved the way for next week's tasks:

- make glider functionality
- wall running communicating with the level blueprint
- make placeholder modular dungeon-like cave assets
- figure out wall/vine climbing and ledge/gap climbing

For sure, when the wall climbing and ledge/gap climbing is figured out and implemented, I'll try them on the Dam area. But for now, the Dam is simply a transitional area towards the next level. And I will try having tunnels in the dam and make the player go inside the tunnels.   

 

[baftis]

DAY 49

Today was a much more productive day than yesterday (actually more than the entire week, for that matter). I got done one of the tasks I set out for this week: the modular assets for what would be the cave levels.

Here's every piece lined up nicely:

Here's something I just threw in the level using all the pieces to see how they match up:

And here is how that area looks like from the inside: https://drive.google.com/file/d/12dxP6Jm-FmGLVN1nuZACmgDcghIVk0MC/view?usp=sharing

These are not all the assets that are going to be used in the cave levels, though. I intend on having some specifically modelled rooms, when the need calls for them: some big, sprawling areas, some scenic ones as well.

Also, these assets are going to be used at the scale shown above as well as at 2 times and at 4 times their current scale. Why? Well, mostly because the designer wants it and he wants it done yesterday ). OK, but seriously now, if I don't do it, he will berate me in front of everyone. Just kidding...or am I? Yes, I am a solo dev... But the designer will kick my butt tho :D

But I digress.

The modular assets at scales other than the original scale have one big advantage: they leave room for verticality in an otherwise mostly horizontal game space. There are disadvantages, but they are minor:

- one has to be mindful about their placement so as they would line up seamlessly
- they may lead to option paralysis when it comes to where exactly they could be placed (lower left corner exit, lower right corner exit, etc. In short around 9 options to choose from)
- in the context of random generation, they may lead to inconsistent gameplay (yes, this is still minor, and I'll explain why later)
- one big disadvantage is that it involves a lot of manual labor

The practice for the cave levels would be the following

- place the modular assets in the level
- place mechanics/puzzles
- set-dress manually

Now, you would think that if I made modular assets, I would use each placeholder piece in the modelling software as reference to create an asset and then be done with it. No, we don't do that here. It's obviously a time-saving pipeline, no doubt. You could say that it is a smart thing to do it like this and I would agree 100%. But that's not what I'm after. The set dress will be done manually for 3 specific reasons:

1) More control over variety on similar modular pieces (each piece, even if it is the same, will look and feel different)
2) More control over the environmental storytelling aspect (allows making fast changes)
3) It's good risk management and time management (if I make one piece and I ultimately reach the conclusion after a few playthroughs that I don't like it, I have to make another or modify it in the modelling software, which takes time. If I do set dressing manually in the engine, I spend significantly less time modifying without altering all the other identical pieces)

I mentioned earlier the fact that random generation of said assets may lead to inconsistent gameplay and said that it was a minor issue. The amount of random generation that is going to be used in the cave levels will be relatively small, but also relatively controlled.

Say we have a cave level that has 3 places where it randomly generated rooms, all 3 in different parts of the level. These rooms would be pooled in 3 different arrays and spawned at runtime. At each "spawn" point, there will be 3 different rooms (so 9 in total). For simplicity's sake, there's an Easy Difficulty spawn point that picks one of 3 easy rooms, a medium spawn point that picks one of 3 medium rooms and a hard difficulty spawn point that spawns one of 3 hard rooms.

Having this controlled creation in place would greatly diminish difficulty inconsistencies, but will not completely eliminate them. So the reason that this is a minor issue is that there might be one combination out of 20 or so (I've forgotten my combinatorial maths knowledge completely, so there's a very high chance that the number mentioned isn't even in the same zip code as "accurate") that will invariably produce difficulty inconsistencies. So there's that.

That's all I've got for today, guys. See ya in the next post. Bye

[JobLeonard]

For a second I thought you were going to spell things with those asset, like a miniature alphabet

Controlled procgen is an artform, I'm sure you'll get it right

[baftis]

Hi, Leonard

Who, me? Naaaaah... I would never do such a thi....oh damn, I tripped over my keyboard....Right, getting back to working on the proj...what the hell???



Whooops.

Heheheheh.

[baftis]

DAY 50

Today was yet again a productive day, even though I was away from the computer most of the day. The paraglider functionality was implemented and here's how it looks in action:

https://drive.google.com/file/d/1W8X4U14MffonwQkcxd-H3dFxiNszo_mK/view?usp=sharing

It went off almost without a hitch. It worked as I thought it would. Meaning I was thinking of setting gravity scale to a quarter or so of the original value and while I was at it, tweaking with the air control a lot. The only part where it left me stumped quite a bit was the need for the velocity nodes. Of course I did not used them at first. But when I did (and after Googling some stuff) it worked like a charm.

While I was Googling the solution to my problem, I stumbled upon the idea of a wind updraft. Kind of like a jump pad for the paraglider: you go through it and it will launch the character up in the air for more air time. It seemed like a cool idea to implement, but I had zero idea on how to approach the feature. Later on a bit, I realized that more or less the same functionality can be used for the wind updraft as it was used for the paraglider. It actually turned out to use less of the functionality, mainly using the Get and Set Velocity (which is the solution I was looking for regarding the paraglider issue).

So now there is a fully working paraglider and a wind updraft mechanic that can be placed multiple times around the level. Here's how the wind updraft looks in action:

https://drive.google.com/file/d/1hmLxzyjELvko4zpLqZ7pCKta4XXLEX8P/view?usp=sharing

One thing that I was not satisfied with was the fact that when looking up or down, you don't control the direction of the paraglider. I hear an internal voice screaming "Well, DUH, that's how you broke down the problem and scripted the thing to work". And yes, I know that.

I was actually expecting to have some sort of control over the pitch of the paraglider, but there was none. Again, this is not a bug, this is how it was intended to be. But I can't help that as a player I wanted for the glider to pitch up and down and was let down that I cannot do it. Granted, you do have the updraft to make you move on the Z-axis, but I wanted it to work on my own input. I now realize that I sound like a kid who got a toy and had unrealistic expectations about it. What matters is that this mechanic does the 6 Degrees Of Freedom feature, even though you are in full control of only 2 of those 6DOF.

Actually I don't know if gliders are supposed or allowed to pitch up or down. But as a player of the game, I wanted it to be like that. I'll investigate this feature, at the moment I'm not really sure how to do it. Most likely it will either require a complete rewrite of the script (which I'm not down with) or a needlessly complicated and voluminous amount of scripts that complement the existing script (which I'm not down with either). I do hope that a more simple solution arises. But not today, I'm done for today.

Oh, quick word about the wind updraft visual.



This was in my unreal marketplace library, think it was free for the month at some point. It's a huge pack of VFX particle systems that had this particular VFX that could very well work as an updraft visual. It was a huge time-saver for me and got really lucky that the colors also matched with the current water shader. Although I do have a strange bug where if you look at the VFX from a certain angle (and if the VFX is on water) the whole thing just disappears. And also, you can see the outline through the transparency, but that's par for the course (hey, I wanted stylized, I got stylized).

I intend on making something similar but without the blue color in it. Actually without color at all, just the white outlines of the wind updraft and a transparent alpha and that's it. And that VFX will definitely won't go exactly on the body of water....but then again it might be cool.

Another thing that irks me a bit is that I do not have any sort of indication that the glider is activated. I'll definitely add a very gentle camera shake when gliding.

So that's it for today's work, I'll see you guys in the next post. Bye.   

[baftis]

DAY 51

Just a quick little update on the paraglider. I've added a camera shake when the player uses the paraglider.

https://drive.google.com/file/d/1104HJirjyQTzKfHRZGjnWSpc-LMBQu2J/view?usp=sharing

I wanted to also add a radial blur and some speed lines over the camera shake but either it's over my head or Unreal Engine sucks at having blueprint communication.

Let me explain: For those who are not familiar with Unreal Engine, there are 2 types of blueprints. These are regular blueprints (those you place in the world and either act as a script) or level blueprints (which essentially do the same thing except it is only applicable for the respective level). There is also the FirstPersonCharacter blueprint, which basically acts as the player character logic and movement blueprint. Now, neither of these do not communicate directly with one another.

As such, in this case you can affect the camera shake in the FirstPersonCharacter blueprint, but you cannot affect the Level Blueprint with the FirstPerson blueprint (duh, it's in the name). The post process, however, happens in the game world, and as such, you cannot have communication between the firstperson character blueprint and the blueprint placed in the world that affects post processing. So, I could only have radial blur/speedlines but no glider (with camera shake) or I could only have the glider (with the camera shake) but not the radial blur or the speedlines. I'll figure it out somehow.

Anyway, that is all for today, short and sweet. See ya in the next post, bye.   

[baftis]

DAY 52

So another quick little update, without screenshots or clips. I fixed the Wall Running component. Finally it only wallruns on 90 degree walls.

The way I approached it at first is to have a Get All Actors with Tag on a Blueprint that is designated as a wall-run-able asset. The player character had to check that, if jumping and near a wall, that wall is wall-run-able.

But I learned that Get All Actors with Tag (along with Get All Actors From Class with Tag) is computationally expensive. It does what it says it does: it calls ALL actors. So if I have 100 wallrunable assets and I only want to jump on one of them, it will call ALL of them to check. So that's a no-go.

So, while going through the script, I realised that the value in range for the degrees at which the player character can run on is 0.50 degrees, give or take. The natural solution was to change the value to a significantly smaller value. Iterating through values, I settled on 0.00001 degrees deviation, give or take. And it worked... just like that. Testing it, I found that 99% of the issues were solved (basically, no uninteded wallrunning), except for a small part when using the grappling hook. At the end, when the player reaches the target, for a small microsecond, the player character detects the model used as a tree stump for the grappling hook target and bounces slightly off. That issue will be fixed once the placeholder asset is replaced by a tree stump that does not have a 90 degree angle in the mesh itself.

That's all I've got for now, see ya in the next post, bye.

[JobLeonard]

Looks like you're starting to think in terms of computational complexity (how things scale with more input) without even realizing it, that's pretty cool!