next »

[baftis]

DAY 36

Did not have much time to work on the project today, but had some mild inspiration bursts.

I continued work on the second level, on the first area from a total of four. When playtesting it, I noticed that the area is very busy in rock pillars and their placements. It kind of made sense, but it didn't feel nor looked right. It felt like the level had a transitional area after the already established transitional area. Also, the placement of the rock pillars was all over the place, so I decided to trim the fat quite a bit.

But before I show you guys how it looks now, I have promised an explanation in the previous post for JobLeonard. So, I'm answering to everybody but this is specially addressed to Leonard first:

In my very early posts, I've showed certain areas of the first level that contained bodies of water. Those bodies of water (at that time) contained game design decisions that were, put simply and honestly, bad.

In one particular body of water, you could swim. Two areas later, you had a body of water in which the character would've died if the character just fell in it. Visually there were no distinctions of "OK, this water I can swim in and this water I could die in if I fell".

You might give me the benefit of the doubt by going "hey, these are placeholders, man, I'm sure you had something down the line that would made these bodies of water distinct". Well, no, I had no intentions. Not because I didn't want to, but because it didn't cross my mind. But I digress.

Anyway, I'm bringing up this because I've showed off the second level this week (what's been done to it, anyway). The screenshots show that there are bodies of water in the level, and a pretty shallow water body at that:



JobLeonard asked a pertinent question: "what happens if you fall off a cliff?", a question which was answered in the previous post (you die).

But I might hear you say "wtf, dude, you just went on rambling about water that you can swim in or that you can die in and how that's sh*t and now you tell me that you die from falling off a cliff with a body of water at the bottom"?   

Well, no, I'm not telling you that, because there's no body of water there anymore. Instead, there are lots of tree canopies:



Now I feel it looks more appropriate to the setting. The body of water was somewhat between intended and placeholder, I just went with the flow at that time. Plus, the area looked more like it was flooded rather than something that grew naturally there. While not necessarily a bad thing, the flooded vibe didn't worked for me eventually. However, I do intend on giving this area like it's own little history in the form of an audio log.

It also felt like the beginning area of the level was sort of a transitional area, and that did not really stick with me. That's because I already established an area that would function as a transitional area between levels. So I got rid of that beginning part, eventually, and the area looks something like this now:



There's still a lot to do here and I'm beginning to ponder a different approach to this area. I think I'll use either the engine's own BSP's or some cubes to prototype this area. This is because the shape of the current rock pillars are distracting as hell to prototype with: the small, protruding rock pieces with grass patches along the bigger rock piece paths really get in the way of prototyping most of the time. Sometimes they create interesting choices and serendipitous situations, but most of the time they get in the way really bad. Because of the serendipitous value, I'd like to keep working with them, but it'll take much longer to get something done.

Oh, I almost forgot. Changes to the second transitional area were done. And now I had a sudden realization that I did not took screenshots of the original transitional area. Whoops, sorry...but then again you didn't lose anything. Anyway, this is how it looks now: 



These changes were made to make way for a grappling hook invisible tutorial there. Before that, the grappling hook tutorial was planned to be quite far away from the beginning of the second level. I changed this in order to let the player use the grappling hook sooner than originally planned. This way I can create more intricate situation with the grappling hook later on.

So that's it for today guys. See ya in the next post, bye.

P.S. To settle this with you and with myself once and for all: Still water is swimmable and you never die when you fall in water, but you can drown in it if it's deep enough and if you stay underwater too long. Running water will never kill you, nor can you drown in it because it's only "lower torso"-level depth, but will move your position in the direction that it is flowing.

[JobLeonard]

You guessed right, I was wondering if you were expected to swim back!

But yeah, it's important that you're consistent with the world-rules to the player. Looks like you found a good solution here

[baftis]

Yeah, at first look it's a good solution. Had it in my head for about a week now, but was deprioritized in order to either fix or implement stuff that were urgent.

I say at first look, because after some tinkering and playtesting, this solution turns out to be a great one, but with a big caveat: light building.

It was to be expected that building the lighting would take up much more time, especially after adding a lot of assets. Before this solution was implemented, light build time took about 5-10 minutes (I wouldn't really know actually, I'd just hit Build Lighting, go do something else and then come back to the finished product).

But this time....whoa, this time it's really really bad. I would've reasonably expected the light build to take triple the time it did before this, but nope. It took 45 minutes to reach 75%.

One would assume that since the build time takes this much of a hit, one would start over with a different solution. But something happened, thanks to random playtesting. Out of the blue, I decided to reach the bottom of the canopy to see how it looks, and, well... see for yourself.



This kinda tickled me in the right way. It's slightly creepy, but also quite a bit intriguing. It's just enough creepy to fall on the uneasy side a bit without feeling like it's a horror game or that it has a horror element. 

As a quick recap, for each level there will be two different types of paths: the intended path of experiencing the game and the exploration path, which is a designated area with things to interact, explore and so on. Well, what you see in the screenshot above is as of a few hours ago the exploration area for this level.

With proper decoration and proper landscaping and layout, this might turn out to be one of the more memorable exploration areas from the game.

With this in mind, even though the build times have significantly increase even above an exaggerated estimate, it might be well worth it to keep this area and solution and expand on it.     

[baftis]

DAY 37

Just a quick little update, without screenshots. Started work on the zipline mechanic and I think I'm about 3/4 of the way done with it.

Yes, I'm aware I said "started". You might recall that at one point I mentioned bringing older mechanics from other projects into this project. And yes, one of those mechanics was the zipline. And yes, other mechanics were brought successfully from older projects, but don't exactly remember if I actually mentioned migrating them: slippery surface, sticky surface, conveyor belt (to be used as the river that pushes the player back) and a bunch of other stuff that I forgot.

The reason I chose to redo the zipline is because I wanted a cleaner blueprint and a more flexible approach to zipline placement in the current project. While it isn't very different from the new zipline, the original one came with some limitations, some unintended features and, of course, some bugs.

Limitations of old zipline:

The original zipline had a capsule component encompassing the length of the zipline spline. This was placed in order for the game to detect if the player collides from above or below, so the player character can attach to the zipline. Nothing bad so far.

The problem starts when I add extra spline points and then arrange those points in a zig-zag-y manner. Then, the capsule enlarges uniformly, trying to encompass every spline point. This would create all sorts of problems, mostly the likes of "getting on the zipline, even though I'm nowhere near it, but I touched the capsule, so I guess I'm on the zipline, now."

This meant that I could only use the zipline in a straight direction, no zig-zag. So that's one reason the capsule had to go and then re-think the whole thing.

Not so intended features:

On the cool side of things, the original zipline could actually take the player from the bottom to the top. This, I believe, was because the were no start points and no end points per se.

This had to go, because for this project I really do want a unidirectional zipline with a proper start and proper end.

Bugs:

The bugs were baffling at the time I made the zipline. If you would've come at the zipline perpendicularly,  you would randomly go either down or up the zipline. This was because the code didn't really understand which is the right way to go, so it made up it's own mind about which direction it should go. It didn't work as "this is point A and this is point B, go from A to B", but more along the lines of "this is Point A and this is point B, either point is fine"

Granted, this could be fixed, but I asked around and as far as I understood, the fix would get really complex really quick, needing nodes and methods I wasn't familiar with at all.

And so, I came to the conclusion that it was better if I would re-do the thing from the ground up with all the features I wanted, more cleanly and less buggy.

One more thing, I've been considering adding an interact button to the zipline. As in the player would not attach automatically to the zipline and zip along when it enters a trigger, but rather "Press E to Interact" kind of stuff. This is because I want the interaction to be 100% intentional on the player's part and not have the player be automatically thrown by accident into something that he doesn't necessarily wants to do. But the verdict will come after A/B testing the mechanic along the automatic version (yeah, I'll have 2 new zipline variants to choose from).

Guess it wasn't just a little quick update after all.

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

[JobLeonard]

So uh, how good are your linear algebra skills? Mine is terrible, to be honest, but all this stuff about angles and vectors makes me think that maybe looking into that would help you with reasoning about these problems.

[baftis]

Hey, Leonard

Oh, my linear algebra skills are absolutely abysmal, I can tell you that. This is definitely the main reason I mentioned that the solution required to solve the problems on the original zipline were complex. Other reasons included lack of knowledge of some functions in Unreal Engine blueprints and just plain old demotivation. So there's that.

But there's more than one way to zip a line. If there's one thing I'm good at is solving a problem by means of getting around it. And let me tell you how:

DAY 38

So yesterday I talked about being almost done with the zipline. And I also mentioned that I needed to re-work the original zipline in order to suit the needs of the project, which are as follows:

A. Be unidirectional
B. Have a proper start and proper end
C. Clean and simple code

Starting from the ground up:
1) a spline mesh component was needed in order to pull this off.
2) to "dress up" the actual spline component so that the player can see the zipline, a cable component was added over the spline component.
3) adding 2 collision boxes and 2 zipline poles: one of each to the start pole and one of each to the end pole
4) attach cable component to the end pole
5) match each spline point to the start pole and the end pole and attach the spline points to the meshes

And so, a properly set-up, fully customizable zipline...in physical form, nothing functional except for the moving poles with the cable. This solved problem B

Now, things got slightly tricky here. Avoiding math (almost) completely, the following (oversimplified) recipe was used:

1) add 2 overlap triggers, one for each pole. One pole will trigger attaching to the zipline, the other the detaching.
2) When attached, pull information from the spline's current length (get it's length and then the location and distance along the spline)
3) Simply set the new actor location (it literally is a function)
4) When at the end pole, overlapping the end pole trigger, launch the character just low enough in the air (yes, you launch it with a negative value) to detach from the zipline.

And now, we have a working zipline. This solves both problem A and problem C. The final result looks something like this:

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

See, guys? The simpler, the better. And with no math.

Please don't take this as a tutorial, it is most definitely not such a thing. It's an oversimplified, high-level overview of a mechanic. Or a template, if you will. Hell, maybe this is how ziplines are actually done.

Oh, did I mention about the bugs? No? Well, let's begin:

How about being ziplined to the right instead of forward? That one was fun (took a long time to figure out, but once found, was a super easy fix...a matter of changing a drop-down menu item from Relative to World...can't remember which function tho)

How about the cable component stretching to the width of the pole? This one was just dumb, like how tf? It was like "nah, imma give you a long sheet of plexiglass instead of a cable". 

How about having the controller completely disabled after getting through the start trigger? That one was on me, I was suffering from the dumb. Had a disable function active on the end trigger, in the hopes that it will disable the designated key to use the zipline. Of course, it disabled the entire keyboard.

Kind of a minor inconvenience, but the character snaps to and from the zipline. This I don't like, I would want for it to be smooth, both in and out of the zipline mechanic, but that's a job for future me. The important thing is that it works just how I wanted.

That's about it for today, see ya in the next post, bye.
   

[JobLeonard]

Oof, sounds like a proper debugging struggle. But think of all the things you're learning along the way!

[baftis]

Hey, Leonard.

Sometimes, it is a full-on struggle because of: 1) trying new things I'm not familiar with; 2) full-on hubris, like "nah, the problem is definitely not in this particular section of the mechanic logic, not in a million years", when in fact it is in that particular section of the mechanic logic. 3) brute-force my way into finding a solution, usually manually (a.k.a. trial and error) instead of taking a step back and work out the issue logically.

To be fair, I'm not a programmer, not even close. In fact, aside from rigging and animation where I have absolutely zero experience, programming is the second weakest skill from my gamedev arsenal at the moment. Texturing, modeling, designing (both level design and game design), testing, in all of these areas I have quite a degree of expertise (some more, some less) and with varying degrees of success.

And also, you are 100% right, I do get excited (along with scared and intimidated) of the new things I'll learn along the way, and it looks like it's starting pay off in more ways than one. Even the smallest win matters.
 

[JobLeonard]

I honestly wouldn't have guessed you weren't a programmer, the struggles you describe don't any different from experience programmers (provided that we're talking about programmers working with a new environment they're not too familiar with). So that's probably a good sign

[baftis]

DAY 39

Hey, all. Back from a little break from the project. Well, back to actually working on the game, because I did some behind the scenes research and project management (just a tiny little bit). And then took two-three days off.

So, today I continued working on the first part of the second level. And this time, things started to gel nicely. A little recap, the level design for this particular area was finnicky to work on: the layout did not translate well into actual gameplay, no matter what pattern I'd use and it did not keep the player active enough.

And the whole "implement-test-delete" went on for quite a while. I think there were at least 3-4 different versions, on top of the number of versions before today. True, some versions had minute changes and 2 of them were drastically different.

But all in all, today marked a breakthrough, in the sense that now, the area is reaching a satisfactory level of quality. Still not there, though, but it's definitely something more dynamic, active and scenic at times.

Here's how it looks now:





So in this first part of four, we're going to have Grappling Hooks, some platforming, one zipline and one wall climbing mechanic.

I've never talked about wall climbing so here goes. There are going to be 2 types of climbing in the project:

- one more akin to rock climbing in real life, with fixed points where you can place your hand (think ledge climbing in Rime or Assassin's Creed games)
- one more akin to the traditional wall climbing in games, with a designated surface on which to climb (think wall climbing in Doom Eternal)

This would be my focus this week, alternating between finishing the second part of the second level and attempting to implement the wall climbing.

For the second part of the second level, I feel that now is the proper time to place something challenging. So I'll consider marrying the collapsing platforms from the previous level with the grappling hook.

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

   

[JobLeonard]

Just curious, why do you plan on two types of climbing? What does each mechanic add to the gameplay for the player? Also, aren't you worried about confusing the player with having multiple options?

[oahda]

Hello again, progress is looking good, fun to see the graphics experiments too!

Sounds like both climbing methods could be intuitive if presented well, like it just makes sense you can climb on cracks in a rock face (method 1) but also on something like vines that completely cover a surface (method 2). Is that the sort of thing you had in mind?

[baftis]

Hey, Prinsessa and Leonard.

Prinsessa, thank you for the kind words. And you are right on the money with the climbing. This is what I had in mind and exactly what I wanted to reply to Leonard, albeit with a few more details on how this works.

If presented very distinctly and very intuitively, the player will understand right off the bat what he/she can do and can't do with either climbing mechanic.

Method 1, as Prinsessa mentioned, would have cracks in the rock as well as small rocks protruding from the rock face. And you would have a specific path to follow.

When the player interacts with the cracks in the rock, he/she can hang on them indefinitely. But when the player interacts with the small rocks, he/she has 3 seconds to move from said rock before it will collapse. If the player is hanging from the rock when it collapses, he/she will fall and die. These collapsing rocks will always be placed at least 50 unreal units above the KillZ threshold.

As a hypothetical example, If the player falls more than say 1000 units (10 meters) the player dies. Therefore, Collapsing Rocks will always be placed at at least 1050 units in height. This adds a layer of challenge to the mechanic and, if I do my level design job very well, will facilitate some risk/reward situations for the player, like jumping off from a crack or rock to another crack that wasn't on the critical path.

Method 2 would be as Prinsessa mentioned, a surface completely covered with a material that you can move anywhere on the XZ axis. Having a rock avalanche/falling boulders would create a challenge for the player. If you got hit by a boulder, you would die.

Although vines would be the way I thought of presenting this mechanic at first, I would toy around with having a metal mesh that prevents rockfall on roads. Something like this:



This is because I'm concerned about portraying mechanics in a thematically appropriate and believable way without being stale or having the mindset of "hey, this is what games do in this situation". But anyway, this is just a matter of visually packaging the mechanic, the content of the mechanic is what's important and it is identical to what Prinsessa mentioned. 

Also, why two types of climbing? Good question: I've mentioned in my earlier posts that in this project, mechanics would be orthogonal in relation to movement, motion and traversal.

For context:

- Ziplines provide traversal in one direction defined by the blueprint on the X and Y axes in the game world with a very slight drop on the Z axis as a byproduct of the nature of the zipline.
- Grappling Hooks provide traversal in one direction defined by the blueprint on any combination of the X, Y and Z axes.

Both of the above do not allow for player movement during use. Zipline allows looking around, Grappling hook does not (too fast).

- Rope swing allows for player movement on all axes, though not simultaneously. Player has complete control over the movement on the +-XY axis at one time and has complete control over the movement on the +-Z axis at another time. This movement is limited by the length of the rope on all axes.
- Wall running provides traversal in two directions defined by the blueprint. You can run on the wall in a direction, then come back and run the same wall in the opposite direction. The +-X axis is out of the equation, while you move on the +-Y axis. The blueprint is in charge of the Z axis, since it modifies the gravity in order to allow for an arc of sorts (ie. not wallrunning forever without dropping off the wall).

Following along this logic, we now have rock climbing and wall climbing:

- rock climbing has a defined path on the +-XZ axis, meaning you can rock-climb only on the designated path, with some risk/reward types of situations.
- wall climbing has a defined surface +-XZ axis, meaning you can wall climb anywhere on that particular surface with the only limits being the bounds of the surface.

Sure, you can have the reverse for both of them: having so many cracks and small rocks to hang on to that you can create your own path or a narrow enough surface that you can climb on a specific path. I would actually stay away from this as much as possible, since it's breeding ground for unwanted issues at best and wildly swinging from option paralysis to unchallenging for the player at worst.

Or even a combination of the two: have a portion with wall climb and a portion with rock climb and alternate between the two. This I would actually experiment with. 

So that's kind of it. I'll happily answer any further questions that would arise.   

[JobLeonard]

Thanks for the elaborate explanation, that does sound like they have clearly different game scenarios they apply to!

[baftis]

DAY 40

Work on the second part of the second level has started and it proved to be a fluid, smooth going endeavor. In this portion of the level I've reintroduced the collapsing platforms and paired them with the grappling hook mechanic. These two, along with some solid rocks and solid ground, seem to make a good pair.

Here's how the second part looks like so far:







And here is an aerial view of the entire area done until now (with a zipline in the lower left corner)



After extensive playtesting it, this new section has shown a few moments where it feels tense and "in-the-nick-of-time" and a moment where you feel like you need to be extra cautious about how you prepare your jump. And believe me, it was a lot of testing: I placed a prop, tested it. I placed another prop, tested it. And so on until the end of what was done.

So far, about half of this second part is implemented. And I feel that this section is where the real challenges start to appear. But then again, if it's slightly tense for me, I think it would be far more difficult for the player who plays the game for the first time. But no need to be talking out of my butt, this will need to be playtested with other people.

You might notice an untextured rock-like thing. I did make a quick and dirty attempt to make my own rock assets for this section with Blender. This was done by applying a Voronoi modifier to a cube and toying around with the shape until it resembled a rock. To those who use Blender, yes I did use the default cube and did not delete it. Shocking, I know.

This quick-and-dirty exercise opened the way to making my own pipeline in regards to rock assets. I did not came up with this method, I watched a tutorial and I believe it's something "standard" when using Blender. From Blender, I'll import into zBrush to whip it into shape and then import it into Unreal to be used in my project. Yay.

For the record, I do have a background in modeling with 3ds max, but it's way too expensive to use on a commercial project if I'm a solo gamedev with basically no budget. So I've started working with Blender, because free and open source and because why not torture myself while I'm at it? What could go wrong?

Anyway, back to the level.

I feel it could be better...a lot better actually, but I can't really put my finger on it. Sure, at first play seemed OK, as I mentioned above. It felt tense, but it doesn't look tense. I feel that there is a disconnect between how the level looks versus how the level plays.

I mean it plays nice (could be nicer... a lot nicer) and you actually feel the tension but when you look at the level, it really doesn't inspire anything. It looks cheap (dare I say clumsy) but it definitely does not play cheap or clumsy, at times it's pretty unforgiving. It feels like an understated level, if that makes any sense, like it plays a lot better than it looks. Well, the only thing to get to the bottom of this is to playtest the hell out of it and see what's missing.

Also, I keep coming back to the idea that more mechanics should be used here. Or environmental hazards. Hmmm, maybe this one too. Or it could just be all in my head, I'm tired.

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

[oahda]

Would love to see it in motion And good luck getting into Blender!

[baftis]

Hey, Prinsessa.

Coming right up: https://drive.google.com/file/d/1d9S_ienKV12b4PmeVC-EMWufcsgpOSFh/view?usp=sharing

Note: The game currently runs at 120 FPS and the recorded footage runs at around 60 FPS (at least on my computer). I've had issues with google drive where the footage looks choppy and runs at a very low framerate, but that might be because of video codecs. Let me know if the footage runs choppy, I'll reupload somewhere else. 

Looking at the footage, some verticality might be good. And some collapsing platforms are definitely not needed.

[oahda]

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

[JobLeonard]

Yeah, I like how it looks in motion too, looks like fun and satisfying platforming action!

I'm a bit concerned with the grappling hook attachment points don't appear to have any visual cues before the "F" is visible. For example, in the beginning you have to jump to get close enough to use your grappling hook.

Or is it specific to the type of boulder and will the player know this by that point?

[baftis]

Hi, Leonard.

At the moment, the grappling attachments do not have any model, and honestly I'm at a loss for what exactly I can put there. To be fair, I gave it only a few moments of thought and then I got sucked in by other things.

I have the option to put something that super-duper-vaguely resembles a gargoyle head for prototyping purposes and have said model without collisions so it doesn't mess with gameplay.

But for the final version, I have only a few vague ideas on what to put on the grappling attachments.

One option would be like a moss-type of patch on the wall and make the player land above the moss. Oh, yeah, this didn't come up when I posted about the grappling hook mechanic. The attachment has the "under-the-hood" functionality to place the player wherever you want him to fall. As illustrated here:



So the purple...uhh...thingy (I genuinely forgot what the purple thingy's called, so deal with it ) acts as an actor transform location, which in layman's terms, I can move that purple thingy anywhere and it tells the player character "hey, when you hit this attachment, you land here".

Anyway, so back to the 3D asset. As I've said, one option (and the first option that came to mind when designing the grappling hook) was to have a moss-type thing on the lower half of a boulder/rock face. This provides all the space the player needs to grapple uninhibited. The problem is that it may not be very intuitive at first or very visible later on. The latter would be the bigger problem here.

Another option would be to have something of a triangularly shaped rock protruding from a rock face. This option right off the bat might have the issue of visually getting lost in areas where there are tons of rocks (which mind you, we're talking about going up a mountain, here). 

To wrap it up: while I do understand your concern, rest assured that those grappling attachments will not be left without prototype models for long. I've just being half-lazy about it and half-"oh, here's that other thing that you need to do".