next »

[JobLeonard]

I was about to say: that looks sweet! But also a bit more high-kinetic than I would have expected based on the mood you are painting for the game in the rest of this devlog

[baftis]

Hi, Leonard.

Interesting piece of feedback, much appreciated. I'll experiment with toning the speed down and/or level placement for this mechanic.

The "mood" will change and evolve during the course of the game. You will have serene, quiet moments as well as some intense, possibly dark moments. Every level will have it's own vibe and since I've only posted about the first level (which is meant to be "chill" to ease in the player), it is completely understandable that you felt that disconnect between mood and mechanic. And it would also be my bad for jumping from mechanic to mechanic without giving proper context (you live and you learn).

The proper context:

At the beginning of the devlog, I had no clear idea about the "hooks" and the "Unique Selling Point" of the game. I knew I wanted them because I want this game to stand out and be good. As you've read, I've started with the mountain in the distance and had segments along a straight line (areas of gameplay in a straight canyon). That quickly went out the window because, while it stands out, it's not really that good, if at all. So I went back to the drawing board.

Over time, the hooks and USP evolved, especially after I did some research into the market I'm competing. When I did the research, I noticed interesting details about most games: movement in walking sims is sloooooow. And for various (albeit possibly financially-rooted) reasons: making the character move slowly means that you can make smaller areas feel bigger. Smaller areas means working on a small budget, though not always (see The Vanishing of Ethan Carter).

And slowly, coupled with the desire to have platforming elements, it clicked: the USP for my game should be "movement". Most walking sims have a creative approach to narrative or puzzles or visuals, but very few focus on movement. As of now, Abzu and What Remains of Edith Finch tackled this aspect to a certain degree, but I believe it can go further. With this in mind, I started developing mechanics and hazards that revolve around movement, motion and traversal. Mechanics focus on enhancing movement, while hazards focus on limiting/impeding movement

For now, strictly pertaining to movement, the mechanics are:

- Rope swing (needs fix badly)
- Grapple Hook (needs minor tweaks)
- Zipline (needs reimport from other project and adjustments in the First Person Character blueprint)

The hazards are:

- Slippery Terrain (needs reimport from other project); think walking on Ice
- Slow Terrain (needs reimport from other project); think walking in Mud

I plan to implement the following mechanics:

- Wall Running
- Wall/Rock Climbing
- Balance Beam

And the following hazards:

- Blizzard (pushes the player character in the direction it is blowing. Player will have to compensate by pushing against the blizzard; if the blizzards blows from the left to the right, the player is pushed to the right and will have to compensate by pressing forward as well as left in order to maintain his path. Will be used in conjunction with falling hazards from above or steep cliffs)

Note that all these mechanics affect the +XYZ/-XYZ axis in different ways. This allows the game to have a far more dynamic and orthogonal approach to movement, motion and traversal than traditional walking sims. This, I believe, makes this game stand out against other walking sims on the gameplay side.

While the focus is on movement, this doesn't mean that it will slouch on the narrative, graphic and exploration side of things. I'm not in the headspace where I can focus on narrative right now, I'm still iterating on a look (though cell-shaded/stylized will remain as the general art direction, whilst still looking for that special something) and the exploration side of things needs to be fleshed out a lot.

Well, I didn't expect to give this long of an answer, but I also took the opportunity to put down the things in my head in writing for my own reference.  Hope this puts things into context a bit better.

[baftis]

DAY 28

Not much going on lately. Took time off the project to focus on having some time for myself. All I did today was fix a bug regarding the Grapple Hook. When the Grapple Hook was completed, the player character would get thrown a few extra feet...or a lot of extra feet if you would be very far away.

TL;DR it was because of an extra Launch Character node with a Multiply function I've placed at the end of the Grappling sequence. It didn't need to be there.

Long version of the issue with context:

The grapple hook in default state is attached to the character. When the grapple fires, it attaches to a target placed in the game world. That target has 2 sub-targets: where the grapple attaches in the world and where the player character should land. The latter is configurable, meaning I can move it around and have total control over where the player character should land. When the player character reaches this particular component of the target, it reverts to the default state.

Now, here's the kicker: at the exact moment when the player character reaches the target, it did a jump that was implemented as a safety measure for the player character to avoid any possible 3D assets in the way (the Launch Character I mentioned above). But instead of helping out, it propelled the character much further than anticipated because I used a multiply function instead of some fixed value. The result was that in more situations than one, it catapulted the player out of the map because of that multiply/launch character function.

That particular section of the blueprint was removed and now the character drops nicely (albeit with a small hang-time duration, super-minor issue) to the ground.   

Next on my list would be to implement the wall running mechanic. Over the following weekend, I plan to investigate wth is wrong with the rope swing. There are some lessons learned from the grappling hook and with a fresh and well rested set of eyes, I can take a look at it and hopefully fix it.

That's it for today, I'll see you guys in the next post. Bye

[JobLeonard]

Taking time off is important

Game physics can be so weird. Glad you managed to "debug" the grappling hook.

[baftis]

DAY 29

So for the past 2 days I've been working on the Wall Running mechanic. Today I've finished it, but so far, the mechanic proved to elude successful functioning. The player character doesn't wall run when it's supposed to wall run... big surprise, huh?

What's funny is that for the most part of the scripting, I was worried that I've messed up the camera tilt or that the player won't attach to the wall. Well, this was indeed a big surprise but those 2 work perfectly. Camera Tilt is tilting correctly on both left and right side of the player and the character attaches both on walls on it's left and on it's right. The problem that it really never occurred that it will happen is that he simply jumps but doesn't wall run.

Wall run speed is definitely defined, I've double checked. All nodes are linked together, so there's no "oh, so it didn't worked because the blueprints were not hooked up" problem that is so often present. Everything else works except the wall run itself....

I have a suspicion is has to do with the First Person Character blueprint, but I will check that tomorrow. It's 3AM here (it's "really, really late" o'clock).

No screenshots today, hopefully tomorrow I'll make this work and give you guys a GIF or a clip. See ya in the next post, bye.

[baftis]

DAY 30

Starting the post with some GREAT news. Wall Running is now fixed and working nicely. Oh, I sense that you may wonder what caused the issue. Welp, buckle your seatbelts, because this gets very stupid, very fast.

It was a humongous doozy to figure this one out, my esteemed devs, because everything worked according to the debug (or at least of what I could tell, anyway). And in the game everything worked except moving forward while on the wall. As I did before, I had to brute-force my way by trial and error into fixing this. From the very beginning, nonetheless.

So, by re-tracing the entire process, I've reached the section of the blueprint that handles movement. In that particular section I've handled the forward movement of the character while on the wall via a Launch Character node. This particular node just so happens to handle Velocity. At this point I needed one vector: the wall run "normal" (so to speak). This wall run "normal" variable needed to have a Cross Product multiplication with the value of a vector defined as the one that moves you up (the Z axis). And that result needed to be multiplied with the sum of 2 other float variables (the wall run speed and the wall run direction), themselves multiplied.

So: (WallRunNormal * value on the Z axis) * (WallRunSpeed * WallRunDirection). OK, so drum roll, please.....

The value of the Z axis was 0. It needed to be 1. (dun..dun..DUUUUUUUUUUN)

OF COURSE the player character wasn't moving forward. How could it if the multiplied value was 0? (throws keyboard at monitor in unbridled anger and frustration)

So after what felt like days, the bug was found and fixed. And here is how wallrunning looks:

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

If it does not come off from the clip, the wall run is similar in feel to that of Titanfall with the gravity of Jedi Fallen Order (short bursts/small-ish arc trajectory of wall running). Right now it feels a little too floaty, I'll toy around with the gravity scale to see how it feels.

I think I might add some post process to the wall run, but I feel it's kind of redundant because you already have a camera tilt to it, so it's not like you don't know that you're wall running. It might look cool, but it doesn't add anything to the gameplay.   

One thing that might be very annoying is that you have to be parallel to the wall in order to perform the wall-run. It's not ideal, it's not bad either but it takes a little while to get the hang of it. Easy to learn and hard to master? Probably. This really would depend upon placement and timing in the level. If the player has time (ie. not pressured by other hazards or events) to set himself up for wall running, that would be OK.

In other words, I can rest assured this is fixed. But tomorrow I said I'll take a look at that Rope Swing thing. So that's a different kettle of fish on my plate, whoop-de-doo. I'll see y'all in the next devlog, bye. And take care.   

[JobLeonard]

Stupid bugs can be the hardest to find. Glad you found it nonetheless!

[baftis]

Hey, Thank you, Leonard. Yes indeed it was hard to track it down, especially if you don't know exactly what you're tracking. But it eventually worked out, so yay. Unlike what is coming next...

DAY 31

So I'm getting really, really frustrated with the Rope Swing throwing the player in the opposite direction he/she intends to jump. Could not get it to work today, but at least cleaned up the scripts here and there. I'm increasingly pondering whether I should re-make the entire detachment from rope section or fix it.

To take my mind off of this mechanic, I continued working on level design. It's pointless to obsess over something that I can't find a solution to at the moment, because everything else takes a back seat and I accomplish nothing.

In stark contrast to the Rope Swing fix, I find the level design to be quite relaxing and free flow. To be fair, I did not advance with building Level 2, I started to add some world-building elements to the first level.

As you might recall, a while back I stated that the levels need some further fleshing out by adding areas that are strictly for exploration purposes. Well, now there is a small, abandoned village that the player can find off the beaten (or Golden) path.







There's also a definite but not very fleshed out backstory to this area. This abandoned village was housing coal miners that worked the mine from the submerged church area*. A small but thriving community, the miners began experiencing strange, unexplainable phenomena: disappearances, abrupt illness and the like.

*for the moment there is no coal mine there, but it's on the to-do list.

Features:

Each house is enter-able, to begin with. Once furnished, the player can inspect items and can pick-up some of said items. The player can interact with drawers, cupboards, hidden items like notes, letters, documents, drawings and audio logs.

Notes, letters and documents will provide backstory pertaining to each individual area, while drawings will provide the player with an undiscovered location where collectibles are hidden and audio logs propel the main story forward.

Which reminds me, an Inventory menu should be implemented to handle all found items.

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

[baftis]

DAY 32

Today, I did some work on placing trees in the exploration areas and connected exploration areas with the Golden Path.

Here is a birds-eye-view of the area:



This interconnectedness (if that's even a word) allows the player to free-roam beyond the bounds of a "Golden Path" scenario, but at the same time keeping sequence skip issues and out of bounds issues in check.

Here is a screenshot of the area:



The yellow lines represent the optional exploration path and the red lines represent the critical path.

Notice how the critical path is significantly shorter than the optional exploration path. This was semi-deliberate. It was mainly done like this in order to clearly differentiate the types of paths.

Shorter, more often and sharper turning paths with verticality were designed to set and maintain player activity at a more urgent pace. Longer, less sharper and less vertical paths let the player breathe and set his own pace.

Also notice how exploration areas are always big and wide open, while the critical path is always narrower, which also ties in with the pace. But this design has the added (and much bigger) benefit for the player to not get lost in the level and to find his way back to the critical path, especially if a landmark is present (submerged church, village).

Going back to sequence skip and bounds issues, this is not exactly a difficult task, in spite of how much I wrote. If you:
1) keep a very, very close eye on level layouts and level bounds
2) test the living daylight out of your game.
3) fix issues immediately... and I mean immediately immediately.

...you will have a great time creating levels, as well as the player playing them.

I'm a stickler for all of the above points, but to be honest point 1 is almost like a pet peeve. I cannot state enough how many times I've played through work-in-progress levels from other devs just to find dozens upon dozens of skips and how infuriating it is to find such skips. Also being a stickler for point 1 also makes testing that more enjoyable and productive from a QA point of view. 

Speaking of testing, I've tested the wall run more and found some very very annoying issues where you can wall run on angles that are not ~90 degrees (+/- 1 degree). This is solved easily by deactivating the wall run in areas where the player is not meant to wall run, which is the current fix. This can also be solved if there would be less to no wiggle room for the player capsule collision to detect a wall that can be ran on. Meaning the wall strictly has to be at 90 degrees in order to run on it. I'll experiment with this.

Speaking of experiments (man, my segue-ways are killer today) I've ran across a function today that really tickles me in all the right places: Random Point In Bounding Box function. This is as WYSIWYG as it can get: you can essentially spawn any item at a random XYZ coordinate in a given bounding box. This is an absolutely killer way to place collectibles in a certain area.

Let me give context: Did you read the previous post? In it, I stated that there would be letters, notes, documents and drawings... and audio logs, too, but what is of interest now is the "drawings" part.
The drawings that the player finds correspond to locations in the game world, if looked at from a certain perspective. Those drawings are also an "X marks the spot" kind of thing that will lead the player to collectibles.

If the drawing with the X is specific enough to be found in the game world but vague enough for the player to actively search for it, that would lead to interesting stories from players, interesting experiences for the players and replay value.

For me as a dev, it allows me to implement something that I find thrilling, if a bit old fashioned: digging for "treasure chests". The digging part needs to be investigated, but I think it is doable and can definitely add a lot of replay value, if done right.       

Another replay value element that I've thought of today (whoo, somebody stop my segue-ways, they're on FIRE) would be to have spawned certain items at various points in the map. If you think this sounds similar to what was mentioned above, you would be kinda right.

Whereas the above said something about a bounding box, this particular mechanic will use target points (which are essentially spawners without being spawners explicitly). One item can be spawned randomly in three different target points at runtime. Essentially, in one playthrough you might find Item 1 in Target Point 3, next playthrough you might find it in Target Point 1.

Whoa, I wrote a lot today. I think that's enough. See you guys in the next post. Bye

[baftis]

DAY 33

In the previous post I've talked about experimenting with 2 particular "mechanics"/features:

1) Random spawning of an item between two or more spawning points
2) Spawning of an item at a random point in a bounding box

Well, the experiments went forward and both were a success, implementation-wise. Both of these are super-easy to implement and here is a breakdown of how the work internally. Please don't treat this as a tutorial, because I don't know how to explain it as such.

1) Target Points are placed into the world. These target points are then placed in an array. Then the array is linked with a SpawnActor at Location node. In this particular node, an item is called to be spawned. To know what spawn point should the game use to spawn the item, a Random Integer InRange function is to be used, since the target points in the array are essentially assigned to an integer. This Random Integer node is then sent, along with the array, to a Get function. This Get function is then sent into a GetActor Location, which then is sent to the SpawnActor at Location  

Ex: You have 3 Target points and in the array, they are assigned a number between 0 and 2. That random integer selects from these 3 integers and spawns the item in the game world.

What this is useful for: aside from the obvious "place collectible at two or more random points" for the player to discover, this is super useful when you want to create a puzzle that has different solutions for each playthrough.

Ex: You must open a door to the next area. The door has 3 indicators above it that tells the player what will open it: a key indicator, a switch indicator and a passcode indicator. One playthough, the player would receive the key, the next playthrough a passcode, the third one the key again, the fourth one the switch and so on. The key would be found in a location, the passcode in a different location and the switch in a different location.

2) A bounding box is created as a blueprint. In the blueprint, both the default scene root is taken and the box itself and are sent directly into the function Random Point In Bounding Box. This function is sent into a Spawn Actor Transform (i believe). For easier access to what to spawn, a variable is created to which the Class type is assigned. This variable is then sent into the Spawn Actor function.

What this is useful for: say you have a Treasure chest hunt. The player is given a specific location ( ex: "the beach at the north of the map") but not the exact location. The player has to dig to find the treasure chest. It may take him 10 seconds, it may take him 3 minutes.

Voila, 2 super-easy features that create interesting choices and situations for the player.

One other super-useful thing I have implemented is a portal card.



If you look in the background, at the cave entrance, you will notice that the cave entrance has some form of fog and lighting to it. That is the portal card. It highlights where the player should go when he/she is in dark areas. Basically, it's a material with gradient and a depth fade added to said gradient. Add it to a plane without collision and you have a portal card. Get close enough and it will disappear completely. Get far back enough and you'll see an illuminated entrance.

What is this useful for: highlighting entrances in the dark, highlighting items or simply use them as light shafts.

Once I get the chance, I will update with video to let you guys see how this portal card works in my game. That's all I've got for now. See you in the next post. Bye.

EDIT! Here is the promised video: https://drive.google.com/file/d/1TG6EHcYQG-r1dt32OTG-zpbVp5MjzORR/view?usp=sharing

[naps at midnight]

Looks very interesting! Reminds me so far of Celeste, Journey, and a bit of Firewatch. Will certainly keep an eye on this!

[baftis]

Hello, napsatmidnight. Welcome to the club and thank you for following. It means a lot to me and I hope you get a kick out of following the devlog too :D

[baftis]

DAY 34

Today I spent time testing the grappling hook, toyed around with post process effects and continue working on the second level of the game. Here's how it all went down:

1) Testing the grappling hook: I wanted to see how the mechanic behaves in different conditions and what placement works best for the Target Grapple. During testing, I've noticed a peculiar behavior.

The grapple hook is intended to pull the character towards the grapple target on the Y and Z axis, but it only pulls the character on the Y axis. Here's a visual representation: 



Unlike some issues I've encountered, this one was pretty easy to figure out and had an easy fix to it.

Initially, the character made 2 jumps 1) after the hook was fired and attached to the grapple target 2) after the character reached the target.

This second jump created a small problem where, after reaching the target, it would propel the character too much in the forward direction.

Because of this issue, I've disregarded the second jump. At the time, my thought process was "If it creates issues here, it might create issues at the first jump too". Based on this logic, I've set the launch velocity at 0,0,0. Tested and it worked great. But this proved to be a false positive.

Because it didn't launch the character anywhere, the character would remain attached to the ground, thus it would only pull the character under the grapple target position. So I added a 1 value to the Z axis in the Launch Character Node in order for the character to at least be technically off the ground. And POOF! It worked flawlessly.

I don't know why I did not disconnect the first Launch Character node as I did with the second Launch Character, but it proved to be an inspired move, because I was able to detect the issue quite rapidly.

2) Level design-wise, I've continued working on the second level by adding a few rock pillars and a few bridges here and there.



To recap a bit, this level is sort of based on the Chinese rock pillars that also inspired Avatar the movie.



To give some detail about the level design process, it's basically the Japanese 4-act structure kishotenketsu technique where:

a) you introduce a gameplay element
b) you complicate above gameplay element
c) introduce a totally different gameplay
d) combine step b and c

Right now, I'm at the first stage of the process and have an idea for the 3rd step.

3) Toying around with the post process effect: this thing looms in my brain like a plague. I want/need some visual hook for the game, something that is stylized and sets it apart from other games. As it is, the look is not bad per se. Granted it's not the best, because right now I'm focusing on gameplay and had a "good enough is good enough" attitude when choosing art assets from the marketplace to use as placeholders.

But I feel that just having stylized/cartoon-y looking assets doesn't make my game stand out. Of course there are more elements to this than just looks: feel and mood also matter.

Toyed with edge detect:



This looks really appealing to me. It has Return of the Obra Dinn vibes. What's cool about this is that even though it is reminiscent of Obra Dinn, it gives off a different vibe, mood and feel. More specifically, to me it's similar to the feeling I had as a kid when I read a book that had illustrations. That had the feeling of "oh, gosh, I wonder what it's like to be there?" and my mind would race to that place.

But unfortunately, this post process has quite a few drawbacks:

a) I can't use color or light to guide the player (problematic for game design purposes, like drawing attention to a puzzle or a platforming section)
b) shadows are white (easily fixable by inverting colors of some assets and then inverting colors for the whole level)
c) not entirely original (see Obra Dinn, The Unfinished Swan, Azteca; this might not actually be a problem)
d) has an annoying flicker whenever you move in-game. Might not be a problem when making a build, because I do not have the issue when editing the level, only when I press to play-in-editor.

Here is the inverted version of the above:



Solves the shadows being white problem, but does not give the same vibe as the one before. Not at all.

This is a colorized version of the first:



Easily the worst looking of the three. Gives me no feeling whatsoever and it annoys my eyes.

What do you guys think? I had dabbled in the recent past with post-process and had this look:



Let me know. That's all I've got for today. See ya in the next post. Bye.

[JobLeonard]

The edge-detect looks nice in still images, but I don't know how it will look in motion. It could be very jarring.

If you check out the obra dinn devlog (somewhere here on these forums!) you'll notice that Lukas Pope spent a lot of time figuring out how to make the dithering effect work in motion without nauseating the player, for example

[baftis]

Hi, Leonard.

Oh, God, when will I learn?

Here's a 30-ish second clip of the game with edge-detect postprocess black-on-white (or day-time edge detect)

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

And here's a 40-ish second clip with edge-detect postprocess white-on-black (or night-time edge detect)

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

The flickering/jarring nauseating issue I've encountered was caused by motion blur and I fixed it after I've posted the devlog yesterday. It was a stupid easy fix, like a tickbox that needed to be unticked.

Tell me anything and everything about what you saw, it will be much appreciated.

I watched the Obra Dinn devlog a while back and I do remember seeing something akin to what you mentioned. I do not use the dither effect in the way Lukas did. If I remember correctly, his use of the dither effect is probably the main ingredient of the post-process and everything else revolved around it. That is because of the 1-bit old-computer-like aesthetic.

In this game, I am using it very very subtly: it is barely noticeable (see the second clip, it's more visible there). Here, dithering does one thing and it does it good: it softens the black color so it appears to have a muted aspect to it.

I'll post comparison photos later in the day with the dither on and off.

[JobLeonard]

Thanks for the video! Looks quite alright in motion too

I wouldn't say it's a definitive look to go for just yet, but definitely worth exploring further. It has potential, I'd say

[baftis]

Yea, I keep coming back to this kind of post process, even though I'm actively opposing it in order to avoid Obra Dinn comparisons.

Oh yeah, this is most definitely not final. I can list the issues from now until the end of time:

- too much detail, especially on ground textures
- messes up water reflection
- messes with depth perception
- some other people that I've shown this said that at times you can't tell when an object starts and when an object ends
- it's very hard on the eyes....actually both are
- shadows and this post process do not mix at all.

So yeah. I'll definitely have another try down the line, but either with a different approach or with fewer assets in the scene.

[baftis]

DAY 35

Took some time off from the game to focus on some me-time AND for some Unreal Engine learning. Even though I did not write a devlog in the past 5 or so days, I did work on the game.

At this point I wanted to focus on the level design and continued working on the second level. I did some work a while back for it, but it wasn't concretely leading anywhere. Yeah yeah, I know, I still have some bugs left unfixed, but they'll eventually get fixed. Thankfully there are only a few of them.

Anyway, Level 2. To recap, I got tremendously inspired by the rock pillars from a Chinese region that I keep forgetting the name of. Looking at pictures of this region, I could see some gameplay creeping out. A grappling hook there, a zipline there, some hanging ropes over there, traditional climbing and ledge climbing over here.

With this in mind, I started rolling out some layouts. And soon discovered that this level is quite a feisty one to create. Earlier I said that I did work on the game, but did not update the devlog. Well, that's because there have been a chain of layout ideas that, when implemented, did not really gel at all. So, implement, playtest, delete. And it kept going on like this for 2 nights in a row with what feels like barely anything modified. In reality, the second level layout is about 20-25% done. There are a few things I'm not happy with, but I am very happy about the reveal of one of the objectives of this level.

So the level layout so far looks like this:









EDIT: If you see some little black/gray square thingies in the game world, those are the Grapple Points for the Grapple Hook mechanic.

And the reveal to one of the objectives looks like this:



At the moment, the objective is to reach the top of that rock pillar. Once you get there, you will use a zipline to go through the next section of the level.

This reveal certainly has a huge potential, especially if the level is properly set dressed and the composition of the scene is slightly adjusted here and there. Not an expert on scene composition, but I'm getting there slowly.

For this level to be functional I would have to implement the zipline mechanic and the climbing mechanic. Right now I'm debating what kind of climbing: wall climbing or ledge climbing?

- Ledge climbing is more thematically appropriate and can give the player a challenge, but I'm not very certain how it would work in first person. Reference: having particular spots where you can go up or down, the rest would be going left/right.
- Wall climbing is more fluid in terms of gameplay and it's been implemented successfully in other games. A reference would be Doom Eternal, but slower.

Another possibility would be to have a platform with ropes that you can hoist up or down via a pulley or a winch. This I have to give credit to JobLeonard. This user suggested something similar when I've encountered an ongoing bug in the Rope Swing mechanic. While it wasn't the solution for that issue, I kept this platform with ropes thing in my mind because I felt it had potential. So I'm going to give it a try in this particular mechanic. I don't really know how this will go, since I can't really imagine pulling this off (no pun intended) without some form of rope physics.

Well, that's all I've got for today. See you in the next post, bye.

 

[JobLeonard]

The way you write about it suggests it doesn't feel this way to you, but it looks like you've been very productive!

Also, glad a suggestion I gave indirectly lead to some inspiration!

What happens if the player falls off a cliff?

[baftis]

Hey, Leonard. Sorry for the late reply. Got caught in work stuff and such.

Yeah, funny thing about the productive part. It definitely felt like nothing was done, but sometimes looking at the output objectively places things into a different perspective. It also felt like that because two or three iterations of that particular area of the level were done, but felt satisfied by only a very small portion of what was done.

In regards to what happens when you fall off a cliff, well...the character dies and resets to the last checkpoint. Shocking, I know. )

I think I know why you are asking this, but feel free to correct me if I'm wrong. All will be detailed in the next devlog, which will be coming along in the next 30 minutes or so.