next »

[JobLeonard]

Maybe using a recognizable texture/color would be the best option? Since that would give you the freedom to reuse the texture/color on different meshes instead requiring a fixed model

[baftis]

DAY 41

So first and foremost I have to address two things:

Maybe using a recognizable texture/color would be the best option? Since that would give you the freedom to reuse the texture/color on different meshes instead requiring a fixed model

Yes, that would be a great idea for prototyping, just shove a 2D plane on the attachment with a very vibrant/emissive color. If I understood your suggestion correctly.

Not choppy The hooking looks quite satisfying! Ziplines will probably look great with a little swinging from side to side

Yeah, I would've loved to have the swinging from side to side part at the prototype stage, but had no immediate solution to it at the time of prototyping the mechanic. Now, I have an idea on how to do that but I'm not really sure it will work. Like using the timeline function in blueprints to rotate the character around the Y axis of the zipline spline. Similar to what happens in the wall run mechanic. I'll have to investigate. This would also be applicable for the detaching part, like a back and forth swing thing with a forward leap just as the player character detaches from the zipline.

I also need to solve the snapping at the moment of attachment and detachment as well. It's driving me nuts. Not as nuts as the Rope Swing does (honestly never touched it for a long time, I'll need to get back to it as well...oh Lord please have mercy)

Onward to today's work..

So today I continued work on the third part of the second level. This time it's all vertical, baby! Check this out, guys:



This iteration came right off the cuff and just went with the flow. I like it when this happens, it's like a stroke of inspiration that was beamed down on me from somewhere out in the ether.

And here's a clip of the section's gameplay:

https://drive.google.com/file/d/1dYVFVUMmcLw4e-duD-dcPrBoWADjr_Ed/view?usp=sharing

Now, do not be fooled by how fast the gameplay appears in the clip, it is slightly misleading. The way this section feels is less tense but way more dynamic. No, wait, let me search my feelings....

OK, done

Right, so the previous section had high peaks of tense gameplay with a lot of space in between the peaks. This section feels more like a flattened curve. It starts out relatively intense and keeps it's momentum (as far as I've played it, because I knew where the grappling attachments were) right until the end. And even if you pause for a moment on the rocks, the feeling of sustained tension doesn't really go away because you have to calculate your next moves. I know the last bit sounded like "this has to be a pixel-perfect platforming run in order to succeed" kind of statement, but it isn't. It allows some wiggle room at times and is letting you do your own thing at your own pace at times as well.

Now, of course there's something I don't like about it, because of course it does, it wouldn't be me otherwise.

While I did feel that kinda sorta potentially maybe some more mechanics/hazards were needed in the section I showed yesterday, this section definitely needs some of those mechanics/hazards. What exactly I don't know. Right off the top of my head, something that could throw you off balance. But I need to playtest this to death to see what exactly it needs

I do have at least two problems that I need to sort out.

There is at least one collapsing platform here. The problem is that if you fall from higher than the collapsing platform was, it would be highly likely to fall on a rock below; and if you want to get back up, you can't because the platform that was there isn't there anymore. There are 2 solutions to this: a) remove all collapsing platforms altogether from this particular section; b) place them and the attachments strategically so that if you drop and fall on the long rock platforms, you can get back up and then progress as intended.   

The other problem is accidental wall running. I need to tweak the values regarding angle detection and make the character wall run only on walls that are exactly 90 degrees angle.

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

[JobLeonard]

I love how you're developing this game iteratively around the "feel" of the platforming first - it really shows in the prototype videos already. By the time you're done I bet that "feel" of hopping and slingshotting around is going to be amazing

[baftis]

Hi, Leonard.

Thank you very much for the kind words. You just made my day. I am beyond happy to hear what you said, I am beyond happy that you feel that way and I will make sure that the game as a whole will feel absolutely amazing.

[baftis]

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=sharing

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 has to be disabled 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.
   

   

[JobLeonard]

The see-saw idea is cool, but yeah, an apparently free rock following a fixed path is weird. You could fix it with guide-rails maybe?

[baftis]

Hi, Leonard.

Yes, that seems to be the only logical choice. I'll be using 2 methods for this.

1) use physics but lock the movement on the Z axis. This would mean that the jump pad might trigger depending on the height of the fall. This would also mean that the jump pad will have inconsistent performance

2) still lock the Z axis but use a timeline animation for the see saw and the boulder instead of physics. This would have consistent performance and would not depend on the height of the fall of the player's jump.

I'll then subject both to some rigurous test cases regarding performance, placement in levels abd for the feel of the jump pad.

Will report about this as soon as I have some conclusive results.

Have a great weekend

[baftis]

DAY 43

So I meant to upload a devlog yesterday, but my ISP had issues which caused a significant downtime with my internet. Now the problem is solved and I can show you guys the progress that has been made.

Work resumed on the second level, this time advancing work from part 2 to part 3. And the progress was substantial, if I do say so myself. Check it out:





And here is a clip of what it looks like in action...at least so far.

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

The way the area feels now is...a lot slower than I have anticipated. This isn't a bad thing necessarily, because I need some downtime from the relatively intense vertical platforming from before. Some excitement was lost during a playtest because of the overuse of grappling hooks. This was greatly reduced when I replaced some grappling hooks with a zipline and added the rope swing (to which I will eventually one of these days get to the bottom of and fix the damn thing).  

Even though it was substantial, it was not without it's share of obstacles. For one, I could not come up with a satisfactory "breather" area between part 2 and part 3 of the second level. I did mention in my previous devlog entry that I had three solutions. To recap, here they are again:



In the end, I chose to build something similar to the "blue" route, which was the most straightforward solution of them all. The other paths are still on the table, repurposing them for "getting to the top of that rock pillar" secret area paths. It's the most sensible approach, since there will be players who would be curious enough to attempt a climb on that until the very top. For this particular section, I haven't done anything yet. I'm planning to introduce the wall climbing mechanic here, kind of like an early tease for it. It's like when you play the first level in a game and you'd find a secret area with a weapon that you would normally find three levels later

Another obstacle was figuring out a direction for the next area. This was the least problematic but the foggiest bit of level design I've encountered so far in the project. And the solution came one drip at a time.

During playtesting, I observed that there could be a potentially scenic view right before the pillar with the first zipline on it.

So that was a start, but what next? Next, it dawned on me that some cliffs would work nicely here, like a narrower, more stylized Grand Canyon like.

OK, that would work, what now? Well, the obvious choice was to have more pillars, but in a different format. This solution was not obvious and it eluded me for quite some time.

Great, then what? Well, then put everything that was implemented until now. Grappling Hooks, Ziplines, Collapsing platforms. Wall running definitely isn't a solution here. What IS a solution, though, is the Rope Swing. Welp, this is an incentive for me to finally finish bug fixing on the rope swing. If anything until now, this has been the biggest challenge so far.

Additionally, as a byproduct of the canyon layout, I noticed an opportunity to expand the flowing river that is encountered before the first transitional area. This would be the flowing river that I mentioned



And this would be the expanded area, which ends at an enormous waterfall. This section can be approached both at the beginning of the second level as a branching path and halfway through the canyon area. The latter area is also the end of the flowing river, as seen below from a bird's-eye perspective.



The flowing river follows the outside of the canyon layout (the left hand side), ends at a big waterfall with an exit to the canyon. This facilitates the opportunity to branch out the second level and have an alternative path towards the canyon. This area would feature the same mechanics as the rock pillar area, but their usage is flipped. Meaning that mechanics that were utilized heavily in the rock pillars area are now less prominent and the mechanics that were less prominent in the rock pillars area are very prominent here.

This alternative path provides two distinct advantages:

1) leaves room for further exploration
2) adds replayability value.

This also brings 2 disadvantages:

1) more work to be done to the second level
2) the possibility of a bad experience when the player approaches the level from the canyon side and reaches back to the very beginning of the second level.

Well, that is about it for yesterday's work (today's devlog). I'll continue to work on this today and with any luck, might also post later on today.

So see you guys in the next post. Bye.

[JobLeonard]

The google drive link is protected, but the screenshots look good!

By the way, besides the graphics and the platforming, what are you plans for sound and narrative in the game?

[baftis]

The google drive link is protected, but the screenshots look good!

By the way, besides the graphics and the platforming, what are you plans for sound and narrative in the game?

Hi, Leonard.

Whoops, my bad. The link should work, now.

As for the sound and narrative....hoo boy...

For the narrative, I have a devlog post an outline of the narrative, but that might be outdated once I get to fleshing out the narrative.

At the moment I'm really not into the headspace to figure out the narrative, but I'd be lying if I'd say I didn't thought about it. Pondering of introducing an NPC to serve as an AI helper. And the NPC villain.

I want it to be gameplay first and dress the narrative to fit the gameplay. As much as this sounds weird for a FP exploration with platforming elements, I need to have the gameplay nailed first. This is because I do not want to make just another walking sim. I'm aiming for the best possible target.

As far as the sound goes... I really did not put much thought into it. But I'll elaborate later today. Busy workday.

[JobLeonard]

At the moment I'm really not into the headspace to figure out the narrative, but I'd be lying if I'd say I didn't thought about it.

Well, if it's not your current focus that's totally fine, I was just curious

If you want to budget your time you could try if a platforming/walking simulator hybrid works. Then you can get away with presenting a story in written form (like found notes) and audio.

Of course, "walking simulators" are usually the opposite of platforming action in terms of gameplay "intensity", so maybe that clashes tremendously. Or maybe it's actually fun!

[baftis]

Hi, Leonard.

Sorry about rushing my answer today, it was a really busy day.

So, about the narrative. I have worked things out only to the point of :

1) having a premise, which is a very broad "Find a Missing Person" trope. That missing person also happens to be the villain; I don't know if that is a trope or not. These two elements are 80% certain to get fleshed out like this.
2) having a backstory, which in a nutshell is "5 persons have disappeared ages ago and you stumble upon evidence that they're alive and nearby". I am only 50% sure that the backstory will remain as is.

I will for certain have some form of "notes" and "audio logs" present in the project. "Notes" as a mechanic really don't excite me as much unless it is done right. I find Skyrim's books to be the prime example to this, since they offer super-rich stories in tiny spurts or has tid-bits to tell that really draws you in or than can affect the gameplay (for those that are not familiar with Skyrim, reading certain books increase certain skill, such as "a book about theft will increase pick-pocketing skills).

And that would be the problem. Unless a note actively adds to the gameplay, it's pretty much noise in the background compared to what it can do as a mechanic. But if done right (as in "with surgical precision" right), it can enhance both the gameplay and the story.

Which is why:

1) having some sort of map or an illustration with an "X marks the spot" thing on it provides more value than just having "notes" lying around nonchalantly. This asks the player to pay attention to both the illustration and the player's immediate surroundings to figure out where the player can find the location on the illustration.

2)having a drawing that either gives a background or nuance to an already established story or outright tells a story by itself and that the player can interact in. This is a little tricky to explain, but here goes. It's very similar to the mini-games from What Remains of Edith Finch. In Edith Finch, you reach a point in the game where you get to experience the other's story from their own point of view. I have something similar in mind for this mechanic as well. Say you find a drawing in one of the abandoned houses from the first level of this project. When you interact with it by picking it up, you can then get transported into the drawing and play as the character that made those drawings.

3)having books lying around that can "teach" the player character some mechanics. Say if you read a book about climbing, your character unlocks the ability to wall climb. If you read another book about climbing, you unlock the ability to ledge climb.

4) having hieroglyphs on certain rocks that will require the player to decipher them. Certain books will offer the meaning of the hieroglyph and the player is now tasked to put two and two together to decipher what the message on the rocks means.

I could get away with having just "notes", but I'm dead set on making this project the best it can be to the best of my abilities.

And yes, walking sims are totally the opposite of platforming action. And on paper, these two clash hard. But so far, things are looking surprisingly OK inside the project itself. And as long as I keep the "movement, motion and traversal" focus in the forefront of both my mind and the project, things are looking good for this project as a whole. Until open playtesting time arrives, anyways.

As for the sound, it literally did not cross my mind almost at all. I had some musical ideas thrown around, focusing on traditional/classical music instruments (via sound libraries like East West Quantum Leap, a piece of software that has an entire orchestra distilled as a plug-in for Digital Audio Workstations).

There is a reason for this: being out in nature is one of the most natural desires any person might have. Such a natural desire requires a natural approach to the overall sound and music. Being in nature also brings harmony to the mind, body and soul. From these details, attaching the words "natural" and "harmonious" to "sound" would only result in having instruments that sound natural and harmonious. This brings us to traditional/classical music instruments. Now, HOW would these be used? This, I do not have the answer to, yet. I would have to get to that part in order to give a proper answer.

Hope this quenches your curiosity a bit, at least until I'll get to these parts of the project eventually.

[JobLeonard]

Thanks for the info, it does quench the curiosity . I'm always impressed by how big your updates are, by the way, so no need to apologize for "rushing" anything!

From the way you describe the topic of sound and what kind of immersion you have in mind, it feels like this game might be better off without any music. But ambient nature soundscapes could still fit, no?

If you need some ideas and inspiration there, this website has lots of ambient soundscapes:

https://mynoise.net/

[baftis]

Hi, Leonard.

Thank you for the compliment, it fills my heart with joy knowing that. And I am so, so glad you get a kick out of this devlog.

You are right on the money with the soundscapes thing. And I checked out the site you mentioned. It totally grabbed my attention when it mentioned that there are also soundscapes that can mask tinnitus (which I unfortunately have). Surfed around a little bit and found it absolutely amazing.

Would totally love to have something like this in Unreal, but unfortunately, the sound blueprints are an absolute nightmare to work with. Not because they're bad, not at all. I'm used to a more DAW-oriented approach to sound manipulation and the system implemented in Unreal throws me off completely.

Thank you for the help, will definitely bookmark the site.

I don't have any segue way into this, so I'll just slyly shift the discussion towards...

DAY 44

Work on the second level continued today. Worked in short bursts, with plenty of productivity and plenty more of playtesting.

Here's how the level has grown:









And here is the big waterfall area:



Oh, you see that little blob in the lower middle of the screen? That is the actual size of the player character. Thougt you'd like some size comparison.

And yes, I'm pretty aware that the character looks tiny instead of the area looking big, but that is because of the scaled assets. They are abnormally large and so are their textures. That throws you off and I know. So I'm gonna need you to get all the way off my back on this. The final assets will be proportionally scaled and everything will look normal...well, normally big. 

It's a slow but steady growth and you can thank playtesting for this. Speaking of which...

Playtesting the area revealed that verticality is needed here, so I obliged. Before playtesting, the pillars were quite level. There was variation in height, but insufficient for the dynamic approach I had in mind for the level. The pillars are still quite level if viewed from afar, but the gameplay verticality is more accentuated now.

Half of the pillar area is done. For tomorrow, I'll be continuing to work on the pillar area and my goal here is to accentuate verticality even more. I am seriously considering making the critical path more zig-zag-y, as well. So much that the player can move along the cliff on the left hand side and before he/she knows it, he/she is on the cliffs on the right hand side. This adds to the variety of the area: at the beginning, the pillars are spaced somewhat narrowly in the canyon. In the half that follows, they will be spaced more apart and as mentioned, the verticality will be even more accentuated.

One thing that I did not find a solution to is what happens when the player reaches the big waterfall.

The area is open and, as mentioned in the previous post, the player is open to explore the river that follows from the big waterfall. The problem is that when the exploring happens, the player will invariably reach the beginning of the second level. One solution to this is to have ziplines that will take him back from the beginning of the second level to the big waterfall.

I am strongly considering ending this level with a man-made dam, to be placed at the end of the canyon. And have a light puzzle in which the player must find some switches to lower the ladders so that the player can reach the top of the dam. But as a counter-weight, I do not have a lot of confidence that ending a dynamic level with a puzzle will be a great idea. But only playtesting will be the judge of that.

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

[JobLeonard]

I dunno, the environment looking huge and making the player feel tiny and insignificant might be appropriate for a mountain climb! Don't know many games that really capture that "massiveness" other than a few open world games maybe.

One thing that I did not find a solution to is what happens when the player reaches the big waterfall.

The area is open and, as mentioned in the previous post, the player is open to explore the river that follows from the big waterfall.

You know, that makes me think: it's interesting that there will be sections that will probably feel both open and "closed" at the same time, because you're out in the open air and can view the whole mountain range, but you have to hug the mountain to not fall your death. The actual "path" the player can go by will be very narrow (so "closed"). And then when you reach a plateau, like the waterfall, that will give way to openness. That in itself can be part of building and releasing tension maybe?

Will there be any narrow ledges to navigate?

[baftis]

I'll take that as a compliment, then :D

As for the tension and release thing...look at this as a natural byproduct of the choice to have two different design directions crossing paths. So far it's looking good. A bit stale for the open areas, though but that's because I did not commit to work on them fully yet. Once I finish the main path, I'll focus on the other exploration areas.

The critical path, being a fixed and deliberate component, requires the player to focus more. To hone in even more on the focus, having "narrow" paths guide the player's direction towards the objective.

Yes, there will definitely be narrow ledges implemented at some point. Which point, I don't know yet. How much fun is it gonna be, it remains to be seen. The problems I have to solve with the narrow ledges first are the precision aspect and the challenge aspect.

The precision problem: in FPP style games, platforming is usually implemented badly because of the 2D mechanics not translating well into 3D.

This is because in 2D not only can you get away with pixel-perfect jumps as a game design and level design element, but you can make an entire game that can revolve around this core concept.

In 3D, this is slightly more difficult to achieve. For one, you can't see your character, because you see from the character's perspective. When you jump, you will more often than not miss the mark, because there is almost no way to approximate your position in relation to the object you land on. If you are a really good player, this would not be that much of a problem; it might be slightly less frustrating. Instead, a casual gamer will feel very frustrated, guaranteed.

This is where the precision problem appears in this equation. Narrow ledges require precision. How much precision? Well, enough precision so that it's tense but enjoyable, removing all elements that even hint at frustration. This requires a megaton of iterations. How much is too narrow? How much is not narrow enough? How much is narrow enough so that both casuals and hardcore gamers feel roughly the same thing, which is "tense but enjoyable"?

This also becomes a problem on the design side, not only on the player experience side. In what context can I put these narrow ledges so that people with fear of heights can feel OK about this mechanic? In what context can I put these narrow ledges so that people with vertigo don't get their vertigo triggered?

These are not really THAT big of a problem as I make them sound like, because solutions are always at hand for these situations. Solutions that do not alter the overall level layouts, I mean. But there are questions that need an answer and a solution.

The challenge problem: Assuming that the precision problem is solved, the only challenge that the player will face here is having to walk slowly enough so that the player doesn't fall off the ledge. This raises a one-sided problem.

Using a keyboard, the player has to tap very quickly and fairly large intervals of time (0.5 - 1 seconds) in order to mimic moving slowly. Controllers, on the other hand, are motion sensitive, meaning that you can ever so slightly tilt the left D-Pad forward to move slowly. This becomes tedious and unchallenging for console players or PC players using a controller.

So, this becomes a issue, wildly swinging from nerve-wrackingly slow to unchallengingly slow. There has to be either a middle ground for this or another solution that delivers the same experience to both camps. Otherwise one side does not have fun, while another might really enjoy the nerve-wracking tapping of the forward button.

Wow, I totally did not expect to write this much. I'll stop and get back to working on the project, now.       

[baftis]

DAY 45

Happy happy, joy joy, guys. Today marks the following: the first iteration of the entire second level is done. Well, 95% done. I'll explain below what happened to the other 5%. Also, brace yourselves for a megaton of screenshots.

And of course no iteration is spared from the rigorous Almighty Tester. After playtesting it from start to finish for the first time, the level felt...a little underwhelming.

The good: It feels dynamic, adventurous, at times tense, almost awe-inspiring at key moments, well-paced (could be better)

The bad: I kind of zoned out a bit during the second half of the level. It felt like I played on autopilot, but in a bad way, like completing it for the sake of completing it. I did not feel as engaged at the end of the canyon as I felt at the beginning of the canyon. Some jumps are frustrating to make, partially because of the model collision, part because of some weird physics with the player character (uncontrollably bouncing off walls during some jumps). Pacing can do a lot better here.

The ugly (and the real problem): over reliance on 2 mechanics. Let me break it down for you:

1) There are 42 (yes, forty-two) grappling hook targets in this level alone. It is no exaggeration to say that this level over-relies on this mechanic alone. I can definitely do with fewer.
2) There are 26 collapsing platforms in this level alone. I'm on the fence in regards to this. Maybe I can do with fewer.
3) There are only 5 ziplines. I think those are enough.
4) There are only 2 ropes...that are still not working.

That's all great, because this iteration failed, so that means it's only going to go up from here.

And what did we learn today, kids? "Over reliance on 2 mechanics does not make a fun level". In all seriousness, I can definitely use at least 2 more mechanics. Jump pad mechanic can certainly be used here, as well as the wall climb mechanic. Jump pad mechanic is pretty much in the bag, but the wall climb mechanic is not.

Most likely, I'll playtest this level again tomorrow and Sunday as well, taking notes as I go along. This means that I won't actively work as much on the game, except to remake the dam. If I'll be rigorous enough, I'll throw multiple test cases at the level with different mindsets: "breaking the level" mindset, "quality pass/how can I improve this level" mindset, "feel pass/what and how do I feel playing it" mindset. 

Amidst this not-so-good outcome from testing, something interesting came up. Playtesting also revealed that the grappling hook is still fun to use, even after 42 times. Which is obviously great, since I've tried this level over and over again (in chunks, though), at least for the past 2 weeks or so and the mechanic still was fun to use. So this is a small (but big) win.

Some tunings are definitely needed on certain grapple targets, though, because the player lands smoother on some targets than on others. A simple adjustment of the character landing point would do the trick, nothing too fancy.

Remember when I told you guys earlier to brace yourselves because a megaton of screenshots is coming your way? Here they are:



































I've added a placeholder for a dam. This dam will serve as the transitional area between this level and the next (duh!). At first, it sprang into my mind to implement a light puzzle on the dam, something like "solve a 4 digit combination lock; the clues are spread over 4 control rooms" or something to this effect. It really didn't make sense, because who tf ends a platforming level with a puzzle??? (quietly hopes no one here points out a level in a good game which ends with a puzzle and said game is not Limbo or Inside)

The dam is also the reason why 5% of the level layout is not done: I made the dam, but I forgot to make the bridges that serve as the levels of the dam and I also forgot to cut holes in the BSP's to make rooms in the dam.

And naturally, there are no gaps in the bridges where you can put a ladder and climb through from one level to the next. And naturally there are no rooms you can enter. So yeah, brain farts galore today. It will certainly be re-made so that there will be gaps through the levels and has some rooms on each level. Probably tomorrow or Sunday.

That's enough for today, guys. See ya in the next post. Bye. Have a good one. 

 
 

[baftis]

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.       

 

[JobLeonard]

Adding a dam is an interesting choice, remember what I said earlier about making the player feel tiny in the face of nature? I think as far as single constructions go, dams are like the closest thing to a man-made structure that can have a monumental imposing size comparable to that of mountains (if you're on the valley side looking up to it).  Sky-scrapers are tall but typically not wide enough to have the same effect.

It's also such a huge, imposing wall, hiding something behind it. That will be interesting to climb over I'm sure!

[baftis]

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.