DAY 46
I made a small whoopsie today...that set me back quite a lot, basically eating half a day.
So while I was testing during the quality pass, it just occured to me that I need to badly fix the Grappling Hook. Functionally it was doing its job as great as it can get. It was a matter of presentation. And as per the feedback of JobLeonard to have something that the player can see when grappling, I decided to do something about it, then an there. Before this, the Grapple Target was completely invisible, save for the moment when the player is in a radius of 50 feet/15 meters near the target.
So I set out to put a static mesh in the blueprint of the Grappling Target. at first I placed what was my first option for the Grappling Target, which was a small BSP that went right on the wall and right under where the player can land. The thingamabob looked something like this:
And I did some test runs. And the idea didn't work. That's because the player kept hitting the wall and bounce off it. OK, cool, no problem. I have Plan B, we good, we cool.
So then, I tried having a cylinder model with a tree bark texture. And it worked...in certain conditions. At max distance away from the target, it worked flawlessly.
The problem was when the player was at halfway or closer to the target, things started to look a little shaky. The same problems appeared: player hitting the wall or hanging in the air where the character position offset was placed. So I tinkered with the blueprint until I reached a satisfactory result. And lo and behold, it worked at most distances (except for right underneath the target)
What I did was the following:
1) Modified the blueprint so that when
2) Changed the position of the Character Offset so that when the player character reaches the target, it will land to the side of the tree trunk
3) Added launch velocity of half a unit on the X axis and on the Z axis, so that when the player character reaches the Character Offset (again, the movable gimbal-like purple thing...I keep forgetting the name, WTF) it will make a small forward and upwards jump, in order to avoid hitting walls.
And it fully worked...in the testing area.
You see, the testing area (which is an area outside the playable area, not a separate level like you're supposed to do) was set up so that you can jump *up* to the Grappling Target. Well, the level itself has moments when you jump *down* towards a Grapple Target. And that is a whole other kettle of fish.
But that was not the problem. The real problem is just around the corner. And that problem is...
I saved the blueprint file. And modifications to the Grapple Target applied instantly in the level. And it basically overwrote every Grapple Target in the level. Because of course it did, that's the very nature of the function.
And so, priority number one became to go over every single grapple target (which may I remind you, are forty-two grapple targets...sorry, *were* forty-two, but we'll get back to that) and modify the character offset manually so that the player character lands correctly...Hoo boy, what a doozy. And it still is a doozy because I'm three quarters in to fixing all of them. But that is a problem for future me...well, tomorrow me, actually.
Going off a tangent here, with a very specific purpose (unlike I usually do). For the devs who do not test their game often, playtesting has a lot of benefits, including finding the rhythm of the game, for lack of a better work. The most useful piece of info I can give you today that will benefit you greatly is to understand that placing at most 2 mechanics one after the other is the maximum amount "allowed" before you either get the "okay, give me something else, what's next?". Let me give you some context with my game:
Let's presume GH is short for grapple hook, JP means Jump Pad, CP stands for Collapsing Platforms. Having GH GH GH JP GH GH GH GH CP GH wears the player out. You need something like GH GH JP GH CP JP GH CP CP JP. Having at most 2 consecutive game mechanics is the most a player can accept as challenging/fun before things get boring.
Oh, speaking of jump pads. Jump-pads were finally placed in the level. For now 4 of them to be precise.
I know I said something like a see-saw with a boulder would be implemented, because thematically appropriate. I know. But the way it was conceived, I just couldn't have something that takes player control away. Just no. I might give it a shot for funsies, but I won't get my hopes up.
Jump-pads replaced some grapple targets in key moments of the level (see, I told you we'll get back tot this). Ziplines were also implemented more often (one or two more than the original 5). One or two collapsing platforms were replaced with said jump-pads. Now the level feels different. It also a few beats where it's a bit slower than the first iteration. That's because the gravity of the character is not quite right, it needs to be heavier. Jump pads revealed this culprit, so thank them for that. It's egregious to say the least. When falling, the character feels very floaty, so the gravity of the player needs to be adjusted to feel just right.
Also, here's a useful side note, kids. The proper hang-time for a character from pressing jump to falling back on it's legs is 0.80 seconds. Not too fast, not too floaty, it's just right. Also, the proper flow of the jump animation should be something like an upside down U. Snappy jump, a lot of hang time, then snappy fallback. It can get slightly "cartoon-y physics", but a little adjustment to taste will correct that.
OK, that's all I've got for today. See ya in the next post, bye.