[GAME][WIP] Against The Mountain - 1st Person Exploration/Platformer

[baftis]

Hello, I am a 35 y/o solo gamedev from Romania and I’ve been long-time lurker of the UE forums. Been using Unreal Engine 4 since the 4.5 version and UDK slightly before that.

I have worked for 8 years in the gaming industry and now I am pursuing my dream of creating a game on my own.

And I am here to present you Against The Mountain.

Genre: First Person Exploration game with Platforming elements

Engine Used: Unreal Engine 4.26.3

Unique Selling Point: If Firewatch and Celeste had a baby, Against the Mountain would be it.

Key Features:

• Explore a vast and compelling stylized mountainous area
• Make your way through dynamic platforming challenges
• Throw yourself into an edge-of-your-seat narrative
• Discover secrets and hidden pieces of the mountain’s lore
• Ascend the mountain with fresh challenges at each runtime

About the Game:

Help the protagonist ascend a dangerous and mysterious mountain in order to find a missing person in this movement-focused and dynamically charged First Person Exploration game with Parkour/Platforming elements.

Why Make This Game?

First and foremost, First Person exploration games are low-key genuinely great experiences for the player, if said games are crafted by competent devs. For a person who comes home from work, extremely tired after a stressful day and in need for some entertainment to reset or recharge from the daily routine of work, eat, sleep, or to simply escape into a virtual world in the hopes of relieving stress, First person exploration games offer a low intensity and low skill solicitation but active experience. For an avid gamer, First person exploration games offer a break from intense, loud, fast, complex or bombastic gameplay experiences and instead delivering well-crafted, deeply-moving stories, often breath-taking environments or worlds and, on rare occasions, refreshing premises that simply cannot be experienced in other types of games.

Secondly, a game like this has the potential to evolve beyond incrementally adding narrative driven mechanics and offer the player an exploration experience with consequences, variety and a degree of difficulty.

And lastly, this genre is a very accessible genre to develop for future or current developers, provided they have something good to say. This is where me as a developer and Against The Mountain as a game come in.

To be completely transparent, it’s a challenge and a goal to finish this game first and foremost. Secondly, while I’m at it, I’ll also challenge myself to make the best, most unique experience I can for the players that purposefully and deliberately flips the established conventions of the genre this game is a part of. It also addresses some (if not all) recurrent complaints about the genre:

1. Lack of a challenge for the players: First person exploration games traditionally lack any meaningful or real challenge, instead focusing on storytelling, whether narrated, NPC dialogue, exposition through note reading or environmental storytelling. Against The Mountain features challenges in the forms of platforming elements, orienteering elements, environmental puzzles and obstacle course elements.
2. Slow movement: First person exploration games are traditionally slow in terms of character movement speed and mouse sensitivity. This is done either to make a level/map feel bigger than it really is, and as a natural consequence padding out game-time. Though not necessarily a bad thing (budgetary reasons, most likely), there has to be a way in which the character feels nimble in a game like this. Against The Mountain features a speedy and agile player character, with parkour abilities.
3. Lack of replay value: First person exploration games are traditionally lacking in replay value, mostly because of the linearity of the levels and/or having no real incentive to experience the same linear story twice or more(unless you really, really like the game, of course). FP exploration games rarely have features that incentivize the player to re-play the game, such as multiple endings or alternate routes, hidden areas and so on. Once the game is finished, the player is done with the game, probably forever. Against The Mountain features hidden areas, collectibles placed in randomly designated locations, randomized Treasure Hunts, off-the-beaten-path explorable areas,
4. Lack of fail states: First person exploration games are traditionally lacking in fail states because they are more concerned in presenting the player a short story or an experience or a feeling rather than a challenge. Against The Mountain features character death.

As the developer of this game, I treat it as a movement simulator, not as a walking simulator. This means that every mechanic in the game is concerned with movement, motion and/or traversal and will tackle and challenge the player in those regards.

Below, I present to you a few select screenshots and clips from the game that is currently in development. This game has been in development since mid-August and is currently 41 days of development in.

DISCLOSURE: Virtually 90% of the assets you will see are assets from the Unreal Marketplace that I intend to use as placeholders until the game is complete in prototype form and therefore suitable for me to start modelling all the game’s final assets.

Without further ado…

And here are some mechanics already implemented in the game:

Wall Running - 2021-10-10 03-07-10.mp4 - Google Drive

Ziplining - 2021-10-27 01-14-52.mp4 - Google Drive

Grappling Hook (alongside Collapsing Platforms) - 2021-11-04 04-10-38.mp4 - Google Drive

Hope that you like what you see, even if the game is in it’s infancy dev-wise. Thank you for reading and I will see you in the next blog entry

PS: as stated above, I am 41 days into developing the game, so the next post ill read as Day 42.

Thank you and have a great journey along with me. See you in the next post, bye.

[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.

2021-11-06 03-00-30.mp4 (video)

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.

[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 ■■■■ 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.

[baftis]

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

[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.

[baftis]

DAY 47

Not much done today in the project itself. Spent more time planning out the Dam area, including what mechanics to place there. One concern is that, with the height of the dam being increased, this leaves more space to cover when “escalating” the dam. I say “escalating” because it is clearly evident that simply having wall climbing and ledge climbing is both not enough and too much at the same time. It’s simple, really: more variety is needed so that the section will feel dynamic instead of a slog.

So I found something in my Unreal Marketplace library and wanted to give it a shot. Namely some retractable floor spikes:

2021-11-19 02-20-11.mp4 (video)

This is something I wanted to make for the latter levels of the game. But as I saw that it was in my library, I’d figure I’d give it a shot to see how it feels. And it’s quite OK. In series, with offset time, they look like this:

2021-11-19 03-20-47.mp4 (video)

Now “Baftis, you dashing and dapper designer!”, I might hear you say, “You’ve mentioned before that you are concerned with things being thematically appropriate, and this mechanic is not thematically appropriate”. Well… no, you don’t find retractable spikes growing naturally in the wild, so that means they must’ve been placed there by someone…maybe the villain?..Hmmmmm

Anyway, making this mechanic is something very easy to do.

1. You have two separate meshes, one for the ground plate and one for the spikes. Yes, all the spikes have to be as one mesh, we’re not sadistic here.
2. After the models are done, place these models in a blueprint with the ground plate at 0,0,0 and then the spikes at 0,0,0 as well.
3. Then, move the spikes down so that they are covered by the ground plate.
4. Take the Z value from the spikes as they are now and then use a float variable for the Z (where you want the spikes to go) on the set relative location node. Toy around with the height at what the spikes would be at the surface, I forgot to mention that earlier. Put these two values as the start and end location of the spikes.
5. Add a Damage Volume to the Spikes (place it so that the bottom of the volume matches the bottom of the spikes)

And you are basically done. It would take more to write the tutorial for this than it would take me to actually make the thing. But I was lazy af and procrastinating with this mechanic and I figured “Eh, why not?”, so I just downloaded. Oh, and I say “basically done” because you do have to account the animation for the spikes, too. But it’s a functionally sound death trap you’ve got there. Quite easy. But don’t take this as a step-by-step tutorial, because it is definitely not. Take it as a “high-level” overview, if you will.

I would actually tinker in the blueprint to see what’s under the hood. I’d like to add different (or separate) times for the delay of the “spikes up” and “spikes down” animations.

I also did some asset replacing today. This was solely because the player character had trouble with all the old blocky rock assets.

Recall this section of the first level and observe the very angled edges these rocks have. These edges threw the player way off when jumping on them. Of course they did, they’re almost a 45 degree angle. So I replaced them with the rocks from the level I was just working on previously. And now the area looks like this:

But there was a wee tiny problem. You see, those particular assets were like 100 times smaller and with their pivot way off in the distance.

So I had to do manual replacement, instead of selecting the asset and replacing the mesh in a drop-down menu. But I can’t complain, it took maybe 3 minutes and it was actually very relaxing and satisfying to do.

I’ve gathered all my energy to attempt and finally fix the rope swing and…nothing. Still wouldn’t properly work. There’s something that just doesn’t work properly when letting go of the rope. I still have one ace up my sleeve. If that doesn’t work I’ll have to scrap this version and start over…ugggghhhhh !!

Although I got it to work at one point and after all this amount of work, it dawned on me that this mechanic kills player momentum. Or at least has the potential to do so, depending on where you place it in the level and after what mechanics you place it after.

If my last ace up my sleeve still doesn’t work, I’ll just duplicate the Grappling Hook mechanic and make it so that the player can shoot a rope that he can swing from. Might use it as an alternate fire kinda thing. If for example the Grappling Hook is triggered by pressing Left Mouse Button, the Rope is triggered by pressing the Right Mouse Button. This on paper sounds more fun than simply finding a rope in the world. Pressing Space would detach the player from the rope.

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

[baftis]

DAY 48

Been wearing quite a few small and different hats since the last update. Mostly level design, game design, project management, a tiny little bit of modeling (I’ll get to that later), bug fixing… you know, everything and anything in between.

1. Level Design: I’ve been attempting to continue working on the Dam area, but this has proved mostly unsuccessful. Everything that I threw at it just didn’t stick…well, mostly everything. I tried implementing the wall running mechanic I did a month or so ago, but I built the wallrunning mechanic into the FirstPersonCharacter blueprint (which by default is deactivated) and could not get it to activate in the Level Blueprint. There is definitely something so obvious that I can’t see it. Will definitely try again later. The mechanic works as intended, for those who didn’t read the post about it. Here’s a video of it in action.

2021-10-10 03-07-10.mp4 (video)

There’s something about this area that pulls into the “transitional area” design. It keeps wanting that, even though there is so much potential for mechanics here. I’ll leave the “transitional” design for last on the list, an “if all else fails, use this” option.

I also had the idea of creating some modular blocky assets to serve as placeholders for a dungeon-like cave exploration level. L-shape, T-shape, I-shape, plus-shape, U-shape, you name it. Square rooms, rectangular rooms, round rooms and the list goes on and on.

This would take 2 hours or so, but maaaan, it’s gonna take a looooong time, with the amount of iterations I have to make in order to pull off a good cave level.

2. Game Design: So one of the new features I thought I’d add is a Hang Glider. This adds to the “movement, motion and traversal” philosophy I keep banging your head about by way of allowing 6DOF movement (something I don’t have at the moment). Possibly having some upwind bits a la Zelda BOTW.

And I do have a clue or two about how I’d make this: If falling and when equipping the glider, the player character would actually have only a quarter of the gravity (or at least a lot less) than the current gravity amount and will have slightly increased air control. Should be easy peasy, this one. I mean, I hope it will. I don’t know about the upwind bits (hopefully a Launch Character on the Z axis will suffice, given that I’m avoiding wind physics altogether)

3. Bug fixing: so I pulled my last ace up my sleeve with the rope swing and it just didn’t work. I have no idea where the script went wrong, and I looked everywhere to the best of my (limited) ability. But I’m not giving up on the rope swing just yet. I’ll just have to re-think the entire thing, starting with using the Grappling Hook base script and altering it so that it fits the rope swing description. The target would be for the new rope swing to play like the grappling hook, maybe having Left Mouse button for grappling hook and Right Mouse Button for the rope swing.

4. Modeling: Hey, remember a little bit earlier when I said something about a glider? Well, did some prototype modeling for the glider as well. Check it out:

I know I messed two things up (no tail on the glider and the handle bar is not big enough). I wasn’t really paying attention to the details and was like “I just want this done, and fast”. This was mostly done so I could feel that the project is moving along, even if slowly.

Because that’s how it felt like, like I didn’t do much to impact the project lately (albeit I did take some time off two days). But this week definitely paved the way for next week’s tasks:

• make glider functionality
• wall running communicating with the level blueprint
• make placeholder modular dungeon-like cave assets
• figure out wall/vine climbing and ledge/gap climbing

For sure, when the wall climbing and ledge/gap climbing is figured out and implemented, I’ll try them on the Dam area. But for now, the Dam is simply a transitional area towards the next level. And I will try having tunnels in the dam and make the player go inside the tunnels.

[Zezkaii]

Hello Baftis, welcome back to UE forums! I’ve looked through this thread of your game “Against the Mountain,” and it looks fantastic! Thank you for keeping us up to date with this creation, and keep up the excellent work!

[baftis]

Thank you very much, Zezkaii. I’m glad that you got a kick out of reading the devlog as much as I had a kick out of writing it. Just in time for the next post in the devlog.

In 3…2…1…

[baftis]

DAY 49

Today was a much more productive day than yesterday (actually more than the entire week, for that matter). I got done one of the tasks I set out for this week: the modular assets for what would be the cave levels.

Here’s every piece lined up nicely:

Here’s something I just threw in the level using all the pieces to see how they match up:

And here is how that area looks like from the inside: 2021-11-24 01-28-47.mp4 - Google Drive

These are not all the assets that are going to be used in the cave levels, though. I intend on having some specifically modelled rooms, when the need calls for them: some big, sprawling areas, some scenic ones as well.

Also, these assets are going to be used at the scale shown above as well as at 2 times and at 4 times their current scale. Why? Well, mostly because the designer wants it and he wants it done yesterday :)). OK, but seriously now, if I don’t do it, he will berate me in front of everyone. Just kidding…or am I? Yes, I am a solo dev… But the designer will kick my butt tho

But I digress.

The modular assets at scales other than the original scale have one big advantage: they leave room for verticality in an otherwise mostly horizontal game space. There are disadvantages, but they are minor:

• one has to be mindful about their placement so as they would line up seamlessly
• they may lead to option paralysis when it comes to where exactly they could be placed (lower left corner exit, lower right corner exit, etc. In short around 9 options to choose from)
• in the context of random generation, they may lead to inconsistent gameplay (yes, this is still minor, and I’ll explain why later)
• one big disadvantage is that it involves a lot of manual labor

The practice for the cave levels would be the following

• place the modular assets in the level
• place mechanics/puzzles
• set-dress manually

Now, you would think that if I made modular assets, I would use each placeholder piece in the modelling software as reference to create an asset and then be done with it. No, we don’t do that here. It’s obviously a time-saving pipeline, no doubt. You could say that it is a smart thing to do it like this and I would agree 100%. But that’s not what I’m after. The set dress will be done manually for 3 specific reasons:

1. More control over variety on similar modular pieces (each piece, even if it is the same, will look and feel different)
2. More control over the environmental storytelling aspect (allows making fast changes)
3. It’s good risk management and time management (if I make one piece and I ultimately reach the conclusion after a few playthroughs that I don’t like it, I have to make another or modify it in the modelling software, which takes time. If I do set dressing manually in the engine, I spend significantly less time modifying without altering all the other identical pieces)

I mentioned earlier the fact that random generation of said assets may lead to inconsistent gameplay and said that it was a minor issue. The amount of random generation that is going to be used in the cave levels will be relatively small, but also relatively controlled.

Say we have a cave level that has 3 places where it randomly generated rooms, all 3 in different parts of the level. These rooms would be pooled in 3 different arrays and spawned at runtime. At each “spawn” point, there will be 3 different rooms (so 9 in total). For simplicity’s sake, there’s an Easy Difficulty spawn point that picks one of 3 easy rooms, a medium spawn point that picks one of 3 medium rooms and a hard difficulty spawn point that spawns one of 3 hard rooms.

Having this controlled creation in place would greatly diminish difficulty inconsistencies, but will not completely eliminate them. So the reason that this is a minor issue is that there might be one combination out of 20 or so (I’ve forgotten my combinatorial maths knowledge completely, so there’s a very high chance that the number mentioned isn’t even in the same zip code as “accurate”) that will invariably produce difficulty inconsistencies. So there’s that.

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

[baftis]

DAY 50

Today was yet again a productive day, even though I was away from the computer most of the day. The paraglider functionality was implemented and here’s how it looks in action:

2021-11-25 01-21-24.mp4 (video)

It went off almost without a hitch. It worked as I thought it would. Meaning I was thinking of setting gravity scale to a quarter or so of the original value and while I was at it, tweaking with the air control a lot. The only part where it left me stumped quite a bit was the need for the velocity nodes. Of course I did not used them at first. But when I did (and after Googling some stuff) it worked like a charm.

While I was Googling the solution to my problem, I stumbled upon the idea of a wind updraft. Kind of like a jump pad for the paraglider: you go through it and it will launch the character up in the air for more air time. It seemed like a cool idea to implement, but I had zero idea on how to approach the feature. Later on a bit, I realized that more or less the same functionality can be used for the wind updraft as it was used for the paraglider. It actually turned out to use less of the functionality, mainly using the Get and Set Velocity (which is the solution I was looking for regarding the paraglider issue).

So now there is a fully working paraglider and a wind updraft mechanic that can be placed multiple times around the level. Here’s how the wind updraft looks in action:

2021-11-25 03-42-04.mp4 (video)

One thing that I was not satisfied with was the fact that when looking up or down, you don’t control the direction of the paraglider. I hear an internal voice screaming “Well, DUH, that’s how you broke down the problem and scripted the thing to work”. And yes, I know that.

I was actually expecting to have some sort of control over the pitch of the paraglider, but there was none. Again, this is not a bug, this is how it was intended to be. But I can’t help that as a player I wanted for the glider to pitch up and down and was let down that I cannot do it. Granted, you do have the updraft to make you move on the Z-axis, but I wanted it to work on my own input. I now realize that I sound like a kid who got a toy and had unrealistic expectations about it. What matters is that this mechanic does the 6 Degrees Of Freedom feature, even though you are in full control of only 2 of those 6DOF.

Actually I don’t know if gliders are supposed or allowed to pitch up or down. But as a player of the game, I wanted it to be like that. I’ll investigate this feature, at the moment I’m not really sure how to do it. Most likely it will either require a complete rewrite of the script (which I’m not down with) or a needlessly complicated and voluminous amount of scripts that complement the existing script (which I’m not down with either). I do hope that a more simple solution arises. But not today, I’m done for today.

Oh, quick word about the wind updraft visual.

This was in my unreal marketplace library, think it was free for the month at some point. It’s a huge pack of VFX particle systems that had this particular VFX that could very well work as an updraft visual. It was a huge time-saver for me and got really lucky that the colors also matched with the current water shader. Although I do have a strange bug where if you look at the VFX from a certain angle (and if the VFX is on water) the whole thing just disappears. And also, you can see the outline through the transparency, but that’s par for the course (hey, I wanted stylized, I got stylized).

I intend on making something similar but without the blue color in it. Actually without color at all, just the white outlines of the wind updraft and a transparent alpha and that’s it. And that VFX will definitely won’t go exactly on the body of water…but then again it might be cool.

Another thing that irks me a bit is that I do not have any sort of indication that the glider is activated. I’ll definitely add a very gentle camera shake when gliding.

So that’s it for today’s work, I’ll see you guys in the next post. Bye.

[baftis]

DAY 51

Just a quick little update on the paraglider. I’ve added a camera shake when the player uses the paraglider.

2021-11-26 04-54-57.mp4 (video)

I wanted to also add a radial blur and some speed lines over the camera shake but either it’s over my head or Unreal Engine sucks at having blueprint communication.

Let me explain: For those who are not familiar with Unreal Engine, there are 2 types of blueprints. These are regular blueprints (those you place in the world and either act as a script) or level blueprints (which essentially do the same thing except it is only applicable for the respective level). There is also the FirstPersonCharacter blueprint, which basically acts as the player character logic and movement blueprint. Now, neither of these do not communicate directly with one another.

As such, in this case you can affect the camera shake in the FirstPersonCharacter blueprint, but you cannot affect the Level Blueprint with the FirstPerson blueprint (duh, it’s in the name). The post process, however, happens in the game world, and as such, you cannot have communication between the firstperson character blueprint and the blueprint placed in the world that affects post processing. So, I could only have radial blur/speedlines but no glider (with camera shake) or I could only have the glider (with the camera shake) but not the radial blur or the speedlines. I’ll figure it out somehow.

Anyway, that is all for today, short and sweet. See ya in the next post, bye.

[baftis]

So another quick little update, without screenshots or clips. I fixed the Wall Running component. Finally it only wallruns on 90 degree walls.

The way I approached it at first is to have a Get All Actors with Tag on a Blueprint that is designated as a wall-run-able asset. The player character had to check that, if jumping and near a wall, that wall is wall-run-able.

But I learned that Get All Actors with Tag (along with Get All Actors From Class with Tag) is computationally expensive. It does what it says it does: it calls ALL actors. So if I have 100 wallrunable assets and I only want to jump on one of them, it will call ALL of them to check. So that’s a no-go.

So, while going through the script, I realised that the value in range for the degrees at which the player character can run on is 0.50 degrees, give or take. The natural solution was to change the value to a significantly smaller value. Iterating through values, I settled on 0.00001 degrees deviation, give or take. And it worked… just like that. Testing it, I found that 99% of the issues were solved (basically, no uninteded wallrunning), except for a small part when using the grappling hook. At the end, when the player reaches the target, for a small microsecond, the player character detects the model used as a tree stump for the grappling hook target and bounces slightly off. That issue will be fixed once the placeholder asset is replaced by a tree stump that does not have a 90 degree angle in the mesh itself.

That’s all I’ve got for now, see ya in the next post, bye.

[baftis]

DAY 53

Did not update the devlog these past few days but I did work on the project. I’ve done the greyboxing for a cave level using the assets that I made last week and currently I’m about halfway through completion of this first cave level.

Here is how it looks now:

At face value, that doesn’t say much. But if I were to add a reference near it, then it starts to say something. Here’s how it looks with a character reference:

​

​

OK, now we’re getting somewhere with this. You get the scale of everything in relation to the character, at least.

I also did the logic for one of these sections. It applies the same logic as the collectibles: there are 4 spawn points and at runtime a switch will spawn at one of the spawn points, randomly.

Initially, I wanted to apply some controlled procgen by way of room spawning: at runtime, in certain places, a room will spawn that is different every time and will lead to different paths. But the way I’ve laid out this level does not lend to this feature, because this level was thought up as an experience from start to it’s current state. So I’ll take note of this and do the controlled procgen in the next cave/mine level.

After that, I thought of blocking some exits as a controlled procgen thing, so the experience would be “OK, this playthroguh you’re going this way, the next playthrough you’re going the other way”. And I thought “Nah, this is not adding to the experience necessarily”. And then it struck me. How about having a switch of some sort (for now*) and the player would have to find the switch. But each and every time, it will be in a different place (out of 4).

*I say “for now” because the plan is to have a bundle of dynamite that is blocking the way and the player needs to find the detonator. The placeholder switch works as the detonator, because it does exactly what it’s supposed to do: go from OFF state to ON state and possibly add a delay to the explosion so as to not detonate instantly.

So I stuck with this, but as I’m writing this devlog, it struck me that this is something very close to the switch-hunting that was in 90’s FPS games. That is not really a fun feature, so I have to be careful and steer away from switch-hunting.

You might also notice two big rooms in one of the screenshots. Those particular rooms will probably not have the same shape when this is completed. Those shapes are for reference only.

Now, you guys might be curious as to how this level will be set dressed. And to that I say: what a coincidence, I’m curious too. :)) But no, really now. I mentioned in a previous post that the set dress will NOT be “model a variant of the room in blender then import it in the engine”.

Well, now I’m not so sure that this pipeline won’t happen. Setting aside that placing small-ish individual assets around the rooms might get tedious and time consuming (I actually love doing that, it’s relaxing in a weird, twisted kinda way), the process might turn out some repetitive results. You would probably start to notice that I was using only 4-5 different meshes, even if I scale them to ungodly sizes and shapes.

So I’ll really need to think this one through. I won’t exclude a combination of both modeled rooms + individual assets placed around. But this is a problem for future me to properly solve, first on paper, then in the real world and then again in the game world.

So that is all I have for now. See ya in the next post, bye.

[Get_DOVAH_it]

Hi Baftis!

I feel like I’m reading your journal or personal diary! This is exactly what it is like to be a game dev! I can see that you’re really dedicated to this project, and I am enjoying the timeline of watching your project spring to fruition! Have you, by chance, played any of The Elder Scrolls games (Oblivion in particular)?

[baftis]

Hey, Get_DOVAH_it. Thank you for the kind words. You might not be aware of this, but words like these are what really keeps me going.

Yes, I have played both Oblivion and Morrowind a little, but I have tens or hundreds of hours in Skyrim.

[Get_DOVAH_it]

You’re most welcome, baftis!

Since you have played Oblivion, you know what it is like in those caves! You cannot tell one from the other! I encourage you to be dynamic with your caves so the players have something new to experience in each cave! Maybe inserting some kind of easter egg in your caves would be cool! (Of course I’m not trying to work you to the bone! LOL! )

You and I both have countless hours of Skyrim under our belt! You could probably tell by my username! LOL!

[BIGTIMEMASTER (Aljav)]

cool project. I had a similar idea to do some day. Cool to see a different take on similar idea. I like your art style. Keep it up!

[baftis]

Hey, BIGTIMEMASTER

Thank you so much. I hope that day comes sooner rather than later and that we get to follow you on your journey.