DAY 42
Today I did not spend much time implementing things as much for various reasons:
1) I tried continuing work on the level design for the second level. Did not get very far because I got a mental block as to where I can continue building the level. I had three paths in mind that the player could take, and they look as follows:
Yellow Line represents path 1, orange line represents path 2 and the blue line represents path 3. Dotted line means that the path goes behind the rock pillar. The paths are numbered my order of preferrence
I am not sure yet all the advantages and disadvantages each path has, except for path 2 (orange), which would be that it would makes the most sense but is also the shortest route. All I know is that if a player sees that humongous rock pillar, there will be a certain percentage that will want to break the critical path and reach the top. And I need to facilitate that for the player. And the path that makes the most sense in implementing does not really facilitate that. I'm very sure it will dawn on me in the following days, but as I was working on it, it did not.
What I did manage to implement successfully (but not completely) is the Fall Damage component. Nothing really exciting, I promise, so I have nothing to show. What the implemented fall damage does now is simply print on the screen if the player died of fall damage. This is because I had a brain fart and implemented fall damage before I implemented a health bar/system.
The crusher hazard also got finally migrated and modified to fit this project and it works as intended. For this, I actually have a clip. The mesh is super bare bones, but it works for now.
https://drive.google.com/file/d/1_qdy-SrwbxM0IcCf0yuznJcBl5XV3bT3/view?usp=shari...
One more thing I want to fit in this project is a jump pad. It's not a complicated process, but I am very concerned that the version I have in mind might cut the player's momentum short. Let me explain why with a painfully crude Paint drawing:
This is how the jump pad should work in a way that is thematically appropriate and has a strong degree of credibility. On a plank with a pivot point, a rock is placed on one end. The player can jump on the other end. When the player jumps on his/her designated end, the rock at the other end will get thrown in the air, shifting the orientation of the plank. When the rock falls back down, the player is then thrown in the air. The plank and the rock have now reset to their original state.
The problem might arise during that short window of time when the rock is in the air. Of course, there are other problems that may occur, maybe even the idea itself. But this short window of time when the rock is in the air concerns me the most because in order for this to function properly, the player input [i]has to be disabled[/i] during that small window of time the rock is in the air.
This irks me badly because, here I am, a staunch proponent of Half-Life 2-style cinematics, that gives the player unbroken (but very diminished) control during in-game cinematics and I propose to a player a gameplay mechanic that completely cuts off the input in order to work properly?
But then again, this particular jump-pad mechanic might actually work, warts and all. It's true that there are other options, which I have to come up with. But at the moment this is how it's going to be implemented. Sure, something like a geyser might actually work, if the game properly suspends the player's disbelief. But this can only be used so many times.
Moving on, other mechanics have been migrated successfully, but not all tested, because it's late here (3 AM at the time of writing). Taking a look at their respective blueprints show that everything is in place and can work as is, but again, I haven't tested them. These are conveyer-belt like mechanics (just some simple volumes), including a portable conveyor belt that I know for sure isn't working properly. I will provide a clip once I get it up and running.
So that's all for today. See you in the next post. Bye.