Of Source Code, more pathfinding, stamina and more!
It all started with a simple checklist, which I put together for the next update:
- Fix glitching cursor; and disable input while minigame is active
- Add 3D movement
- Fix wall pathfinding/glitching
- Add dash/roll option to mouse (ctrl+mouse movement)
- Re-implement the stamina system
- (Add new Screen Projection)
- (Wall fade-in-and-fade-out)
The last two are in brackets because they were added after the fact that this list was created (it'll make all sense in just a bit). Little did I know that I was about to go on a (massive) side trip, just because of some foolish ideas . . . Well not entirely, but definitely on the more controversial side. And of course for some unforeseen bumps along the way. So strap in, because this will be a story and a half!
Hey, there's something wrong with the mouse!
This project is starting to run into the issue of being senile, as more often months pass between each new added function, and by the time they are let go, they inadvertently cause trouble elsewhere. This was the case when the "mysterious" mouse issues started to crop up. For some reason, 8/10 times the game didn't register any mouse clicks, which resulted in the fact that the player character simply fell into the void (because their movement coordinates were suddenly aimed towards 0-0-0, which was below ground).
That really bugged the living hell out of me, and because of the vastness of Unreal, it took me days to go through every aspect of the controls/settings/etc. Unfortunately, couldn't solve it at all. Thus I spent more browsing the web than coding, whilst tried to ask around if someone else had the same issue. In parallel to this, had the idea of making my own screen-to-world projection, with the intent of having more control over what the curser hit: By default, there's no option to have multi-traces for your cursor in Unreal (or affect how the projection is made/transformed), which can severely limit customization. The latter is extremely important, as this is a Top-Down game, where there's an immense amount of responsibility placed on the usage of said mouse. Having that extra dimension of freedom, would enable me to (probably) create new mechanics, or at the very least help me customize its usage for a game, such as this. A good example would be if there were a house, in which the character could walk in, and the walls and the roof of said house would not be removed from the world, just be hidden from plain sight, then there would be a high chance that the simple tracing would not work; as it would catch the outer elements first, rather than what was inside. Of course, there's the possibility to counter this by altering each and every object's trace attributes (enabling and/or changing how object or ray traces affect them), or modify how or which channels the mouse uses, but if I can help it, I always try to settle for something that (mostly) works in all scenarios; something that is more fool proof so to speak. Suffice to say, this way of thinking also has its own downfalls and merits. But that's for another day.
At first I thought that there's a chance that I can implement this "cursor projection" idea. Heck, even had some semi-promising successes with my quirky blueprint coding. That being said, there were some definite walls that stopped me from progressing forward. The theories, the coding that I saw online (for all sorts of engines, and languages, etc.) only helped me so much. And this whole thing already took almost two weeks at that point. Couldn't get the right coordinates, and couldn't find any useful information on the topic (that could help me in this case). Thus I had to discover/realize that the notion of creating your own cursor-to-world projection is such a low level coding problem, that A) Not many care about it, and B) Not many know about it (especially when it comes to blueprints/visual scripting). And as it required some higher level of expertise, there was only one way to progress: opening up the source code myself!
Luckily, this wasn't my first time seeing code, but still struggled to find something useful (as the source code is gigantic). However, was soon pointed at the fact that there's something in the sceneview.cpp, which would help me out greatly (despite the fact that people didn't understand what I was trying to achieve). So more days passed after this discovery, as translating the code into visual script turned out to be another level of adventure. Note that I'm using "adventure" extremely-lightly. :) Won't go into details, but eventually I got it to work. Sort of. The only catch is that I couldn't really figure out how to solve the problem with scaling, as for some reason Unreal is tuned to have a fixed ratio when it comes to screen projection: it uses a 1440p resolution for reference, if I remember correctly. But couldn't figure out how it was calculated, to come up with a scale variable for every screen resolution. So the code 100% works, if it is in full screen mode. Which is a bit of a problem, when you work in windowed mode; thus had to resort using the default projection nodes, found in the engine, for rapid iterations.
Did this finally solve everything? Not quite, as there was still the issue of it working 8/10. After some more troubleshooting, I almost thought of leaving it for the time being. Luckily, I remembered that I forgot to check the very first thing I should've checked: to see if there's a collision issue with a player component. Turns out that was the culprit, and gave me the much needed rest . . .
The battle at Crossroads
Was overly-smug about my quick and easy pathfinder, so I felt confident that implementing it into the realm of 3D would go relatively smoothly. Well, that didn't happen; not exactly. For one, the limitations of coding entirely in visual script started to show. Was faced with the same issue that I had before (which in turn morphed the code into its current form): performance. The more logic I added, the more problems started to arise. The code started to look more and more jumbled, with bits and pieces all over the place. Technically, I tried to patch it as I went, which didn't always quite work. Like scaling up the grid system, or making sure the player didn't clip through walls, or fall into voids (or just simply bypass everything to get to its desired location). This was the time when I started to use the "throw some trigonometry at it, to fix it" approach. And it worked up to a certain level. But I often encountered the fact that the character tried to climb walls that it wasn't supposed to. Which again was tough to figure out, as it required an entirely different approach (especially from 2D). Started using all sorts of methods to distinguish certain scenarios, which sort of worked. Unfortunately, I only have some crummy Twitter videos of this; not a big loss at all. A big turnaround occurred, when I started to implement a basic see-through wall mechanic: had to finally-realize how utterly broken and convoluted my pathfinding has become, and had to start from scratch. The video below took me a solid week to accomplish, and abolished weeks of progress. Albeit, it worked better than before! Of course, had to make some sacrifices along to way, as even the new code started to lag the game: some safety check were left out in the end as a result. My biggest dream of implementing an optimal route finder will remain forever dormant.
https://youtu.be/3qSdqxz-59E
ps.: for those who are curious, these were some of the things that had to be solved:
- Gets stuck on walking up the stairs
- Tries to climb/hug close walls
- Can glitch through walls, voids
- Add memory save for proximity (fade-in); changed wall angle check
- Angle based wall scan (avoid clipping through)
- Add outline to bottom
- Gets stuck moving too close to a wall
- Rotating object breaks fade-in, big time
Taking a short art break
All this heavy weightlifting encouraged me to take it "easy" for a bit, and decided to make some placeholder art for the level (spent a day or two on this). Nothing fancy, but got really-tired of looking at those white boxes!
Other fixes and the reintroduced stamina system, with dash/roll
Meanwhile, was still working on fixing and correcting the new pathfinding solution, up until the point where I just had to call it quits (for now). It's not bad, especially for a prototype, but there are cases when it could work better, if I wasn't forced to cut back on said lists of features. Bit sad of this situation, but it is what it is.
What's more interesting is the fact that I reintroduced the stamina system, with some smaller twists. Have separated the stamina bar into three distinctive "layers", each with its own color, to better represent the urgency of it running out. The biggest change is that when you eventually run out of stamina, you essentially exhaust yourself, which in turn means that you cannot regenerate whilst walking; thus have to be stationary until it reaches 100% again. Another addition (alongside with some overlays) was the dash/roll function, which also takes stamina to use (which was originally presented here; gosh this was three months ago!). As you may find in the following, there hasn't been any updates to the animation (just yet). That might be the plan for the next big update!
