Hello, all. First time posting here. I am a game designer/level designer and I've wanted to do my own game by myself for quite awhile. I've tried multiple times, but every time I've started a project, I got too ambitious and along the way I've abandoned all projects because of sheer scope.  But no more. This project I am determined to finish.

DAY 1

Today I present you Against The Mountain: a first person adventure/platformer. Or keeping it real, a walking simulator with a platformer component...and maybe a dungeon.

You start the game in a valley and your goal is to reach a mountain top. While traversing the valley and climbing the mountain, you will encounter various obstacle courses ("areas") that puts your orientation skills and your timing skills to the test.

Since I've just started the project, I do not have very "interesting" stuff to show, but I do have some screenshots. Here is one.

                                                          "See that big object in the distance? That's where you need to go": The Game

Do not be fooled by the perspective of the above screenshot, it is a long way to the mountain. An early test showed that from the spawn point to the base of the mountain will take you about 10min:30sec.

As said before, you start the game in a valley, roughly from where this screenshot has been taken. The valley, as you can see, is a straight line. Along this straight line, the player encounters distinct areas of increasing difficulty. And these areas are definitely not straight lines. And also, they're definitely not few. 

There are 16 planned areas for the game: 14 in the valley, one from the base of the mountain to about halfway and one inside the mountain (this is where the aforementioned dungeon will be)

Speaking of areas, I do have a screenshot of one area. It's very, very work-in-progress, so bear with me.

This is the very first area the player will encounter. It will also serve as the tutorial for the game. As you can see, it's nothing fancy at all: a simple short maze, designed to teach the player the controls and a few mechanics of the game.

By the way, that little red dot on the light gray square? That's the player character capsule.

Here's an extra screenshot from the first area:

That's all I have for today. See you guys tomorrow.

DAY 2

So today was a slow day. Productive nonetheless, but slow. I started working on the project by testing what was done last night and wasn't pleased with the result. It did not make any sense to have that kind of maze at the beginning. Because I did not test last night, I've come to the realization that the trees were scaled far too much and the player could very well waltz through the maze, avoiding the intended path. 

It was immediately clear that a different design is needed there; a simpler, more familiar and less complicated one. And so a different design reared it's head quite fast.

In place of the trees, now this section contains two small interconnected patches of land (that's the best way I can put it, English is not my native language). The "below" levels will be filled with water and buildings on the patches of land. For the building *style*, an Ancient Greek or Ancient Roman style of building would be cool. 

And the choice of these buildings might have decided what the Art direction would be for this project. I was torn between having a stylized look versus realistic look with post process effects. I'm leaning more and more towards a "dream-like state" art direction: deep colors, oil painting post process but with realistic looking assets. 

Since it doesn't realistically make sense to have Ancient Greek or Ancient Roman buildings in this manner (isolated, smack dab in the middle of the road, so to speak) it would make sense to have them there as a metaphor for "ancient knowledge". Like "in order to reach the top of the mountain, first you must have this ancient knowledge into possession" kind of thing.  

Officially I've spent more time writing this than I did working on the project, so I'll stop for now. Will be back tomorrow, with more progress, hopefully.

DAY 3

So yesterday I had some vague inspiration about having some Ancient Greek or Ancient Roman buildings in the first level area of the game. So I went out for a hunt on 3d models that would serve as a placeholder. Lo and behold, I did stumble across something that I can use and that also is thematically aligned with what I want. 

Works nice, if I do say so myself. Had to make some modifications to the collisions first, though. While it looks really nice, the model's collisions were nonsensical. The columns, for example were all under 3 separate block-like collisions. While OK for the purpose of blocking the level out and using these as reference until I make some final models, when using a third party model (this one came from kitbash3d.com) you do run the risk of having to do some of the work yourself. Luckily it was only a matter of removing the original collision and applying one from inside UE4, so it was merely a small inconvenience.

So I know two of these buildings are going to be used and I also know that I need a water plane. So I added them. And the result:

The area is coming along quite nicely. I'll bring back the trees, since I want to decorate the area like an Ancient Roman villa, with bushes and thin but long trees. This is to create an idyllic sort of area that the player would feel a sense of awe and serenity during what is essentially the game's tutorial section. Pretty fitting, don't you think?  

The bad thing about this is that it looks really rough, even for block-out standards. But since I really don't have much time to work on it like I've wanted, this will have to do for now. At this stage I'm not concerned with the area "looking" good. I'm concerned strictly about the gameplay, the logic and player navigation. And since I'm going to iterate a lot, it doesn't make much sense to spend more time than needed to make this area "look" good now. Iterate until I find the fun. Form always follows function, as the Elder Gaming Gods always say. 

Speaking of logic, this would be the next thing to implement. Since I do have basically all I need to have in this area to make it functional, it's time to get to the nitty gritty of creating the logic. This would mean the puzzle, the doors, triggers for text and dialogue inspired by What Remains of Edith Finch and maybe some in-game events unrelated to the puzzle logic.   

That's about it for today. Tomorrow, I'll take a crack at doing the puzzle. I have the doors working from other projects, so that's a time saver.

See ya tomorrow. Bye.

DAY 4

I was really tired today. Overslept and missed 2 hours of work (yikes!).  I wanted to do the entire logic for the first area today, but only managed to make the logic for the buttons. It took longer than expected, with testing and bug fixing. But I did manage to make the buttons, so at least there's that. 

Had some ideas about placing an outline on the buttons when the player puts the mouse cursor/crosshair but don't know how to make that one yet. I'll document myself about how I will do that.

A button looks like this:

Again, placeholder content, but it does the job: press the button, the button lowers. And when you are near the pillar/support, a text render appears above the support. So far everything works as intended, but I'm not satisfied with the speed at which the button lowers: it just teleports instead of moving smoothly, but I'll fix it. Some bugs occurred with the text render, but I managed to fix them. 

After the button was done, I managed to swap out the Roman building model with another, more sleek and "utilitarian" one (at least for the purpose of the area):

  Simple, sleek, does the job. What more can one ask?

Again, had to rework the collisions because as it was, the player could not enter the building. Using complex collision as simple on all parts minus the brazier. That would've killed performance in the long run, so instead I used an Auto Convex collision. Tweaked around until I got a nice, hollow cylinder shape collision that allowed players to enter and that encompasses the entire model without killing performance. Sweet. 

So that's all I've got for today. See ya tomorrow.

DAY 5

Did not have much time for myself today, had to make preparations for a much needed get-away. I did manage to continue where I left off the other night for a bit.

So I had to rework some logic for the button switch in order to make hooking up future doors (or puzzles) easier for my future self. More specifically, I made the blueprint to automatically change the materials on the button when it is in an active state and an inactive state.  Previously, I did not call the material change (it had only one material). More importantly, I made the active/inactive component public, so I can tick and untick in the editor as default when needed. This also means making the logic for future puzzles easier (hopefully) just by calling a Boolean function from that particular instance of the blueprint instead of copy-pasting some things in the Level Blueprint. Makes for a cleaner, lighter implementation, I think. I'm not a programmer, I have no idea how much some functions cost in the long run.  

 I did not fix the "button teleports" instead of moving smoothly along a spline because for now it works just as it is. There is no functional issue, only a visual one, so there is no real urgency. After everything else is set up and working properly, I'll fix this issue as well.

I do have three more features/functionalities I'd like to add to the button, because why not: 

1) once you hover over it with the crosshair while it is in an inactive state, the button will have a bright outline. 

2) Also while hovering over it, the info needed for the player to interact with it will appear above the button in the game world. 

3) And while it transitions from inactive to active, the material will transition smoothly from red to green.

No screenshots today. I'll be off until Monday and will come back then. See ya.

DAY 6

OK, fun over, time to get back to the project.

I got side-tracked from the nice-to-have tasks that I've talked about earlier and started working on a stylized water shader. Hey, it's not like the concept of "being organized" has been invented or anything, right? 

So the shader came out...well, it did not exactly came out what I wanted, but it's a start.

Kind of like the stylized lines. But they're buggy: on landscapes meshes, they tend to skip a polygon or two. Why? Not sure yet.

What I do not like is the water itself. It looks cheap and not interesting at all. Thought I had it nailed down but results speak for themselves.

Overall, there's something I can work with here, but most likely I'll have to re-work the water shader, if not re-do it entirely. I ended up spending a lot of time on it (about 2 hours or so) and wanted to bridge a stylized version with a realistic version of water, but did not get anywhere with it. You live and you learn. I'll try 2 different versions: a completely realistic one and a completely stylized one and see who wins out. Hoping the stylized wins, since that's what I'm going for.

Also tried my hand at sketching some levels on paper. Sketched 2 levels, but went blank at the third one.

Tomorrow I'll migrate some old assets from previously unfinished (as of yet) projects that have to do with platforming. That will most definitely kick me into gear about the progress with the game.

Hopefully tomorrow I'll also finish the doors and switches thing (and fix bugs). 

That is all for now, see ya tomorrow. Bye.

DAY 7

Today's work was a hodge-podge of things that I've set out to do. Got distracted and started making some stylized rocks in Blender and trying to make them prettier in ZBrush, but I forgot how perversely complicated ZBrush's UI is. Had a hard time getting back into it and, of course, spent an enormous amount of time. Not very smart, eh? But I made some rocks, didn't I? Not final, but it's getting there.

Managed to import the assets from previous unfinished projects, but hoo boy, what a can of worms I've opened up. Of course each and every one of them did not work at all, so had to also spend time adapting it for this project. After adjusting them to this project, I came to the realization that I only actually need 3 or so of those mechanics out of...I dunno, 10-15? Fun times indeed.   

The opening doors blueprint gave me headaches. And a laugh: one door swung rapidly, continuously and completely out of control. Managed to fix that particular issue, but am still left with making the opening doors work as intended, meaning swinging wide open to the sides. I'll try a different approach tomorrow.

On the button switch blueprint, I still have issues where the material on the pressed button does not update and remains red instead of turning green, ergo the button remains inactive and cannot open the above-mentioned door. I know what the issue is, so this shouldn't be a problem.

But I did manage to actually fix the visual bug where the button teleports instead of moving slowly downwards, so there's a small win.

On the design part of things, I'm kind of in the dark at the moment. q1, a member on this forum mentioned some games that are similar to my concept (climbing a mountain, sort of). Had a quick look at them and realized it made much more sense to spend the time reaching the top of the mountain from the actual foot of the mountain instead of spending 80% of the time reaching it. And the levels would be spread on the mountain from bottom to top in a twirly-wirly, spiral-y way. This change alone in the design department shifted the whole story on it's head.

What I'm in the dark now is about the setting and the context of the story. Why would the player character be there in the first place? Why would he climb that mountain? To save someone? For selfish reasons? To get away from something? He's doing it just to prove a point?

No screenshots today, surely tomorrow. That's all, guys. See ya.

DAY 8

Finally fixed the buttons, the materials and the doors. Everything is working properly. Now I'm investigating a simple way to put them all together. I'm thinking the AND node, but cannot find proper documentation on what it does.

Started working on level design for the first level. It will be Firewatch-y in nature, but more in-game. With lots of nature around guiding the player: trees, cliffs and the first puzzle of the game (the one in the roman architecture, which I'm pretty convinced they will go away). Speaking of trees, I've spent a stupid amount of time fixing a scaling issue with the placeholder trees I have. They were 100 times smaller than intended. Even for placeholder standards, working with someone else's assets is a lottery, in the sense that you never know which ones work properly. Pivots all over the place, unusable sizes, that kind of thing. But I did reach out to the marketplace to find something suitable and I did.

I'll post screenshots tomorrow, I'm dead tired. See ya.

EDIT: As promised, here are the screenshots from yesterday's work









Back to work, now.

DAY 9

Nothing much happened today. I did manage to expand on the level I'm currently working on, which would be the very beginning of the game. Only sculpted the landscape for it, so I have nothing really interesting to show. But here it is anyway.



Had some ideas about what's going to happen in the game mechanic-wise. Text pop-ups, letter reading, audio logs, that kind of stuff. But nothing really original or hook-y. And I keep thinking about something original story-wise or premise-wise that I can also do, just one gameplay thing.

Tinkered around with some post process effects, but settled on having a cartoon-ish outline in the game world. I like how assets have that "pop" to them now.



That is all for today. See ya tomorrow. 

DAY 10

Took a break from development, but back at it again.

Spent some time to iron out the gameplay loop and the core pillars of the game. While having a general, if not vague idea, the game design itself lacked a proper direction. For an exploration game, one might think that there isn't too much to work on, right?

Turns out that, as simple as it may seem, (good) games like this are understatedly specific in their inner workings. Exploration should be fun and rewarding. How do you make exploration fun and rewarding?

- Beautiful sights contribute to the fun (arguably greatly), but it's not the be-all-end-all of the exploration pillar.
- Having collectibles alongside beautiful sights makes exploration rewarding, but is this enough? Only for a short while and only if done right (i.e. having different types of collectibles carefully placed around the game world).
- Giving enough of a challenge for the player to navigate around the beautiful areas and getting to collectibles? Ok, now this is going somewhere.
- Build a gripping story around the game world? OK, keep going...
- Having enough variety in the levels to mix things up? Almost there..
- Having a new twist on an old mechanic or some novel mechanic that is also interesting for the player to use? That's it!


All these ingredients make for an interesting experience for the player, I believe.Hopefully I did not miss anything before it's too late.


Today I've spent some time on the level design as well.








That's all I've got for today. See ya.

DAY 12

Had a breakthrough in the story department today. So here's the premise of the game:

After decades of research, a group of five scientists specializing in superconductors have discovered a way in which antigravity can be harnessed. This discovery, the scientists reckoned, will lead to a new era for mankind, a paradigm shift as big if not bigger than the industrial revolution. Of course, such a discovery attracts both supporters and detractors alike. But it also attracts government interest.

You were hiking near Mount Timor, a mountain infamous for it's dangerous ascent, minding your vacation. During the hike, you stumble upon an old portable reel tape recorder barely hidden in the bushes. Out of sheer curiosity, you play the tape and hear an Audio Log of Adam DeVata himself made the day before. In that recording, he alluded to being hidden somewhere at the peak of Mount Timor. Knowing about DeVata and the whole story, you set out to find him.

So that's it for today, no screenshots. See ya.

DAY 13

Somehow, out of nowhere, inspiration struck today level design wise. Managed to create a platforming section for the first level.









What's peculiar is that this was not really planned to come out like this. In fact it's nothing like planned. What was planned to be there was a down-sized version of the area with the Ancient Roman buildings. This down-sized version is still in the books to be in this first level, but for the moment I don't know where.

Why is this peculiar? Because I usually have a layout for sections to work with or at the very least a rough idea. Instead this section was built just by going with the flow. It was a little liberating and quite breezy to work on. Tested this section so that it does not have any sequence skips and fixed where that happened (whoops, scratch that, found one more, will fix after I finish writing this).

What I do not like is that I used the same placeholder rock asset all over the place and that kind of leaves the impression that the section is same-y. Gameplay-wise, it does not feel same-y, but it feels slightly tiresome. And this is a problem. Why?

One thing I know about testing games is this: when you test a game (especially one particular section) over and over and over again, the good mechanics tend to not stand out as "good" anymore and the bad mechanics tend to stand out like a sore thumb. In other words, they "degrade" over time: what's good becomes meh, but what is already meh from the get-go becomes frustrating or annoying.

This is why what I said before about the section feeling slightly tiresome is a problem.

That's all for today, see ya tomorrow. Bye   

DAY 14

I'll be short and sweet today. Worked on level design a bit. Managed to replace the greybox platforming area with some landscape. Worked nicely, although there will certainly be a problem with sequence skipping or going outside the intended play area in the future. This might not be a BIG problem though: as long as the player doesn't get out of bounds, he's free to go wherever he/she wants. That issue and the issue of a complete area skipping. These two issues are the most important to test.

Also started working on the next area, only managed to sculpt the landscape and place some water. Tomorrow I'll add the mechanics to it. 

This area will have collapsing platforms and one more mechanic. Probably rope climbing or ziplining, but it's best to settle upon which mechanic after I'll test the area. 

It didn't really took me a lot of time to put the above mentioned together, but I do need to set a limit to how much I work on the project. It's really taking a toll on me and I want to finish the project in one piece and with some down-time to gather my energy for the next day. So I shall impose myself working at least 30 minutes but at the very very most 2 hours at a time.

That's all for today. See ya tomorrow. 

DAY 15

Continued work on level design today. Placed collapsing platforms around the area and tested it to see how it plays and feels. Like it is now, it is unexpectedly challenging without being annoying or frustrating. 

You start from here:

And end up here, where the grey button is:

But some ugly problems reared their ugly little heads.

1) The very first platform and one specific platform near the middle of the area are very tricky to get on to, because the player cannot properly asses the distance and leverage character movement, more specifically Air Control. On one hand, this can be filed under "things that the player can master", perfectly setting up the difficulty of the game. On the other hand, how this area plays and feels now is too much of a challenge so early in the game.

2) Another ugly thing that occurred to me is that is a bit too similar to the previous areas. Theoretically, you would be like 5 minutes into the game when reaching this area (2 min if you know what you are doing) and all you did now, besides some exploration and interaction with notes and tame machines, is a lot of jumping on "platforms" (technically some are rocks, but I'll go with the generic term). This needs some variety, some "mix'em-up" even if you're just 5 minutes in. I can't let the player with just jumping around on platforms. 

I did state yesterday that I'll put in another mechanic. After testing, Rope swinging would be good here, but the rope I made is not really functioning properly (doesn't get the velocity of the jump when the player jumps on it) but it does swing. Would have to take a peek in that blueprint to see what's happening.

And to give the player a break from all the jumping, I'll add a tall and wide rock in the middle of that little lake and test it to see how it feels and plays. I'll add multiple levels to it for variety and possibly scenic purposes. I say scenic, because I'd like to add a spectacular waterfall there somewhere.

All in all, what I did today had surprisingly good results and I'm pleased with the challenging aspect, but needs more variety. 

That's all for today. See ya in the next post.   

DAY 16

Did not do much today...well actually yesterday. I felt so sick and pretty much devoid of energy, I just couldn't bring myself to write a devlog last night, so I'm doing it now. I'm much better today.

OK, so I've tested what was last implemented a few days ago and came to the conclusion that the collapsing platforms area needs to be grossly modified. It was too difficult to complete it. For context, I've tried to complete it about 10 times, but could not. Since this is an exploration game first and foremost, it shouldn't be this hard to finish an area. Especially considering it's at the very beginning of the game. I will make a note to have something similar and something as difficult much much later in the game.

I've tried placing a tall rocky formation in the middle of the body of water and make it so that it has a specific path the player has to follow. It did not work. It felt very contrived and cheap, but it did allow the placement of a zipline. As tempting as that sounds, I ultimately decided against both zipline and tall rock, because those did not bring much to the gameplay in this area. 

What I did manage to do is replace some collapsing platforms with standing platforms (rocks). This gives the player a small breather after having to jump collapsing platforms. While having only collapsing platforms there was indeed intense without being frustrating or annoying, me not being able to complete the objective after almost 10 attempts says it all. It's too much. If one cannot finish a level in a maximum of 3 attempts, it's a no-go.

Here are some screenshots of how the area looks now:

That's all for now. See ya later, bye.

DAY 17

It took me awhile to figure out where this level is going to end, but I'm on my way there. I've figured it out in my head nearly 100%, now I just need to implement it in the game, which I'm at 50% or so.

I say nearly 100% because there is one thing that is bothering me: the water. 

So far there are three sections where there is water and each section deals water differently. 

In the first section where we have water, the player will simply swim in it if he falls. If the player falls in the water, he/she can swim until he/she is near the rocks and can get up on them. 

In the next section, the water is basically a death trigger. You fall from the platforms, you die and reset at the last checkpoint.

The last section (the one I'm working on now) is a flowing river that will have the power to physically move the player. If he's not fast enough, the river will push him/her into the previous section, in which the water is a death trigger.

See, this is bad and confusing for the player. Three different bodies of water, three different rules in the space of 5 minutes or less. Not good.

My best bet is to lower the the second area water to near-ground level and add fall damage. And maybe add some stone spikes for decoration. That should do it.

At the moment I have not decided if there will be more areas in which the player can swim. If he/she does have more areas to swim in, that will be extra scripting on my part to do the oxygen bar. Which will prompt me to create a health bar. Yikes!

Speaking of new things, here is the (incomplete) new area:

I also started research regarding various exploration games to see where I stand and where I can stand.

I'm also researching other types of plots and premises for the game. I'm not 100% certain and/or positive that the current premise is the best premise for the game. If it turns out that "5 persons missing, go find them" premise works best, then this one it is.

Other than that, nothing much happened. So that's it for this post, see you in the next one. Bye

I tinkered with some post process shaders over the weekend. While I did state that I wanted something stylized, the only real direction I had was Firewatch combined with anime-style visuals. While what I'm about to show you isn't along those lines, I think I might've stumbled over something potentially great and unique. Here are some screenshots, three versions of the same scene:

Version 1

Version 2

Version 3

DAY 18

A big milestone was achieved today. The layout for the "first level" is functionally complete. Next up on the list for this level is to hook up the logic for it and then to set dress it. So the first level is technically 1/3 complete, but still a long way until I'll start set dressing it.

Here is a screenshot of the last area of the level:

And here is a bird's eye view for the entire first level.

Before you laugh your ass off at the gigantic door in the first screenshot, that thing came with the engine and is a big time saver, because it has the pivot exactly where it's supposed to be: at the bottom of the asset at the hinges and (most importantly) I can flip it on the Y axis like a draw bridge as I intend to. With that out of the way...

Next up on my list is to test the level front to back and to time it. After these two are done, I'll have to review the level for improvements gameplay wise and make adjustments accordingly. After that, I'll make a document for it and detail the level beat by beat. Somewhere in between all this, I'll make the logic for the level.

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

DAY 19

Did a pass through the level and tested it for playability and time. Some sections were very difficult to clear, so I've made them easier. Luckily, no major changes were made so far.

1) Extended one of the platforms at the beginning of the second section. This was done in order to not punish the player for a mis-step while platforming near the very end of this section. Tested, the setback is now at an acceptable level.



2) Slightly enlarged one platform at the last section of the level. This platform was particularly difficult to climb on, so it had to be re-adjusted. Tested, now it's much, much easier to jump on that particular platform. No before pic, only after.



3) Added climb-down aids at the last section again, this time the left hand side section. This was done in order to facilitate climbing down from the end of the left-hand side section without taking fall damage. No before pic, only after

 

Also, after testing, I realized that three things need to be done:

1) Platforms must strictly have a steep angle (80-90 degrees angle). If an edge has a 45 degree angle, it will bounce the player off. And that really feels annoying.

2) The big "door" does not need to fall on the Y axis to open, as originally intended, because it does not make any sense. I really did not think this one through. On either side of the Y axis, it falls onto the river, which feels really weird. Pulling it upwards is more believable, so I'll go with that.

3) At the "collapsing platforms" section (the U shaped area), I need to have an alternate route towards the end-goal. At the moment, when you fall, you do not have any way to get back up.

Also, I've mentioned before that I've imported some blueprints from  previous projects. Well, two of those are a swinging rope and a zipline. Right now, I'm working on making the rope function, because now it does not function at all.



At the moment, the capsule (highlighted in yellow) does not recognize the player. Even if it would've recognized the player, it would not inherit the velocity force that the player has when. So when a player jumps towards the rope and hangs on to it, the player comes at a standstill. But the good part is that the player can properly swing on the rope.

I'd also want to make the rope climbable, but that is a completely different kettle of fish. Not only that, but it might not be do-able. Right now, the player swings with the WASD keys (yes, it swings sideways). Climbing up or down the rope would require the use of those particular keys. Maybe by pressing the E key while on the rope will cycle through swinging and climbing??? That might just work. If it's at all possible.

That's about it for this post, see ya on the next one. Bye 

DAY 20

So guess what? Remember when I said that the doors are fixed? NOPE!!!! They are not fixed. In the sense that the doors do not communicate with the switches. Or the other way around, I don't know. The thing is I might need to re-make the doors-switches system. As they are they do not work, even if they previously kinda-sorta worked, so the system is not robust. 

Back to the drawing board with this. And I did hoped I had this fixed....oh well....It's frustrating because It feels like I almost completely forgot how to properly use Blueprints. Plot twist: I never knew to begin with. Take THAT! HAHA! (proceeds to cry in the corner of the living room)

Goofy time over...

I made further alterations to certain sections of the level. Added 2 more platforms to the first platforming area and moved the button so that when you face the intended exit, you can see what is happening.

I added stair-like platforms to the collapsing platform section because of a design decision: you cannot die just by falling in water. Therefore you need an alternate route. I might alter it further, because I have some ideas.

Added some foliage and trees at the last section, just to see how it would look.

Had a surprise tester play my game and had very good feedback to give. Navigation worked as I intended and hoped it would work, but: 

- A tutorial of sorts needs to be implemented, because the tester had difficulty when trying to platform not because it was difficult but because the tester was "inept at run-jumping" (tester's own words, mind you) 

- Need to have a crack at character movement, especially jumping.

- Maybe give a quest for each audio log interacted with? (Tester expected this, for some reason)

- Definitely seek out potentially beautiful vistas and make them way way more attractive. 

So that's about it for this post. See ya on the next one, bye.    

DAY 21

Had some down time today so I managed to tinker around some stuff I had laying around from the UE marketplace. Stuff I had that was useful but didn't know I had. I'm a hoarder like that :))

Be advised that these assets are all still placeholder assets. With this out of the way, here are some stills from the first platforming area:

Found a great waterfall asset that I want to reverse engineer. Once I figure out how to do it, I would like to add some stylized caustics to all the bodies of water as well. At first glance, it doesn't seem to be difficult: Make a plane that is bent 80-90 degrees or so at roughly one tenth of the length. The materials needed for this look like some strokes painted horizontally on a transparent-ish blue color, with a Panner added to fake movement. Seems easy enough.

As you can see, I've replaced the checkerboard pattern material with some stylized landscape material. I did not spent enough time tinkering on this, so it doesn't look pretty at all, but it's there. I have zero experience with landscape materials, so my guess is that it'll take a while until something noteworthy results from tinkering.

Regarding level design, I've spent some time considering adding areas that are strictly for exploration purposes and so I've started adding these areas.

This is a very rough idea of what I'm going to do, but it's a start. What's also a rough idea is whether or not I would leave the player wandering and find his own path as well as the intended path in and out of the exploration area. This would present the risks of skipping certain sections of the map and/or spending less time than the intended path would be. 

One idea is to have the pure exploration areas interconnected with the intended level design path without being really able to progress further unless the player uses the "golden path". Either this or have a secondary "hidden" golden path towards the intended play area. These could both work, but surely this would come at a cost. I'll have to test which one would work best.

That's it for now, see you in the next post. Bye

DAY 22

So after a few days away to recharge my batteries, I'm coming back to the project in full force. So much force that I forgot to give an update on what I was working yesterday. 

SO...one of the things I've worked on yesterday and today expanding the first level with zones that are solely created for exploration purposes. 

"But Baftis", I hear you say, "isn't your entire game based on exploration and walking?" Yes, it is, BUT.... the Golden Path (a.k.a. the path that the designer intends for the player to play in) also has some puzzle elements, some platforming elements, some hazards and so on. These exploration areas do not and will not have such things. Sure, they'll have the occasional fail states (dying by fall damage and/or drowning), but that's about it. Allow me to exemplify, fellow indie game dev.

This is the second iteration of the exploration area I've shown you (Day 21 post). This second iteration consists of an enlarged lake with a church partially submerged in the lake. 

I am painfully aware that the underwater post-process is non-existent but it is on the way. What I am also painfully aware is of a post process bug in which meshes that are under water show their outline, but shouldn't. Luckily enough, I have a solution for this.

Strap your seat belts, technical-reading inclined devs, you are about to enter the domain of "if it works it ain't stupid" hacks.  

So, as you can see in this picture...

The church is partially submerged underwater, but the outlines underneath the water are still showing. At first I thought "It's the Toon Shader who is causing the problem". That would be a big nope, because the entirety of the blueprint is plugged into the emissive component of the master node. 

Then I thought "surely, it's a water material issue". And after closer inspection, I've discovered that it... isn't a water material issue. The material is refractive and 100% opaque. So the only conclusion I came to is that, separately, the Toon Shader (applied as a post process effect) works properly and the water material (applied on the mesh) works as it should. But together do no work properly.  OK, at this point I was stumped and had no idea how to fix any of the blueprints.

BUT...a solution presented itself out of nowhere. 

We know this: the Toon Shader draws the object outline underwater but the water is completely opaque. That obviously means that any object placed under water would have it's outline drawn, or at least part of it. But I also noticed that some overlapped meshes do not have their entire outline drawn. And then this idea struck: I would figure that if I'd put a horizontal plane mesh as big as the body of water just a tiny bit under the water mesh, it would obstruct other meshes and force the toon shader to stop drawing outlines. And oddly enough, it worked. And here are the before and after screenshots:

(I would've made a GIF that showed how it worked, but I have no idea how to make one and at this point in the night I'm honestly too lazy to learn how to do it)

Well, that about does it for the exploration areas in Level 1, time to move on to what I've worked on for Level 2.

This is the very start of level 2. After you would have solved the puzzle with the big door, you would eventually have reached this area, which is traditionally called "the transitional area", but I like to call this "the breather area", because it is the least intense part of the level. These walkways would be made out of wood and are (or will be) be suspended from above by wires. 

This is the same area, from another angle.

This would be a tiny canyon that the player can traverse on foot. It's around this area that I'd like to implement the first use of rope swinging (if I can get it to work). 

This would be the end of the breather area, slowly revealing the meat-y section of this level as the player moves up towards the edge.

For the section that follows, I have in mind something akin to the rock pillars from the movie Avatar. Because of the nature of those rock pillars, I also plan to implement these mechanics: rope swinging, ziplining and grapple hook. Of these three, as I've mentioned before, I only have rope swinging (which doesn't work) and ziplines (which do work). I do not have the grappling hook mechanic made at all. One other idea would be to also implement wall running, but I'm not entirely sure about that. 

And that would be about it for this post. I'll see you in the next one. Bye.

DAY 23

Just popping in to note that today I've done some work on the Rope Swinging mechanic. Although I did have the rope swing mechanic imported from another project, I had to re-do it completely. This is because the mechanic in the previous project was linked directly to [i]that[/i] player character and had some blueprint interfaces specifically made for [i]that[/i] character (which wasn't a first person character). And I think I'm a quarter of the way into making it work for this project.

That's it for today. No screenshots. Hopefully I can come back tomorrow and give a more meaty update. See ya, have a good one.

DAY 24

Another small update in which I call PARTIAL SUCCESS!!! I got the rope to a "barely working" status again. And here is a GIF of it in action:

https://giphy.com/embed/0m0T5a1YvSmBt2n0Qc (note to self: learn how to add GIFs in a forum post)

Of course, this isn't it's final form, I'm barely halfway in to fixing it and bring it into a fun state. It was a lot more of a hassle than I thought it would be, because it's more interconnected than I thought: there's a lot of stuff to add in the first person character blueprint that needs to communicate with the rope blueprint placed in the world. Had some small hiccups here and there: I knew I had everything hooked up in the first person character's movement blueprints, but the character wasn't swinging. Turns out there was a boolean variable missing that I forgot to add (an IsHanging? bool).

Small update in devlog content, but I spent a lot of time on this. Will probably update when I get this in a state as close to the final as possible. See ya in the next post, bye.

DAY 25

My brain is completely fried from working on the Rope Swing. Where do I even begin?

Did you, dear dev, had a day where everything went wrong no matter what you did? Oh, you did??? That's great. Because, guess what? This was one of those days for me. 

OK, so today I really wanted to completely finish with the Rope Swing system, but it has driven me completely bonkers. Bug after bug after bug after bug, one uglier/stupider than the other.

Of the many issues encountered today, the following issues got me doing a loud WTF:

1) When I attached the character to the rope and then detach from it, the character would get 0.1 in scale. Luckily this was an easy fix. I don't know how or why this was an easy fix, but it was and I'm grateful. It was a matter of changing the scale of the player when detaching from Keep Relative to Keep World.

2) When the player character detached from the rope, the player lost all control of the player character when it reached the ground...it just sat there. This left me stumped and moved on to the next issue because I could not fix it.

3) When successfully jumping from the rope to the ground, you could basically re-attach again. Luckily this was an easy fix too. I have no idea how, I have no idea why, I have no idea what could possibly have gone right, but issue number 2 got fixed at the same time as this fix. And it works 100%.

The ugly issues still remain as of now

- Snappy drop to the ground after detaching from the rope

- Copious amounts of swing force are applied when detaching from the rope, even at a standstill

- Sometimes the character gets launched into digital oblivion when detaching from the rope

But at least I got the Velocity working right :D

Kids, if you are at any point in time reading this devlog for inspiration or curiosity in how a solo gamedev life is like, please know this. Gamedev is 98% hard and 2% glamorous. Not in the sense that it's hard labor (it is that too sometimes) but in the sense that you get completely baffled, bewildered, stupefied, frustrated and confused by what the actual hell your code or script spits out when you play it. The only moments gamedev is glamorous is 1) when your code actually works 2) when your code finally works and 3) when players play your game and love it.

Anyway, that's all I could do for today. I'm fried as a MF.

DAY 26

Took a break from the Rope Swing mechanic and focused on something else I've been trying to implement: Grappling Hook. So far, it has been going rather smooth.

To give a small taste, the Grappling Hook I'm trying to implement is based on a similar mechanic found in one of my recent favorite games, Journey To The Savage Planet. In this game, you have a pistol-like weapon that can also be used in an utilitarian way, such as a grappling hook: you shoot at a certain point in the world, which is indicated via a UI button. When you do that, that pistol fires a grappling beam of sorts and pulls you towards the grappling point. This is how I plan to implement it in my game as well.

If you do not know this game but the described mechanic sounds familiar to you, think of it as the Batman Arkham series Grappling mechanic in first person.

Now, for the reason why this mechanic came into existence is because I wanted a very dynamic and exciting traversal method. An additional layer of raeson would be that the Rope Swing is causing a lot of problems both from a design POV and from a technical POV. Let me break it down for you:

From a design perspective, there were a few but very easily reproductible test cases where the player would swing so much that, after detaching from the rope, he/she could basically swing the rope onto a cliff and lock himself/herself out of progressing through the game. I wish I would've filmed the test cases and show a GIF to you guys, but I didn't film them. I'll keep this as a mental note and film my test cases in the future.

Furthermore, based on the test cases above, I concluded that there has to be a certain layout for the rope swing to work and for the player to not block himself/herself out of the game progression: wide open spaces with a death trigger below. As I was typing the previous, it suddenly dawned on me that most of the sections, if not all, from Jedi Fallen Order where Rope Swing was present, were more or less coincidentally fairly wide open spaces with a bottomless pit. OK, so there's another idea for a level.

For the moment I'm putting the rope swing on hold. I don't intend to shelf the mechanic, because it has potential. But I do need to investigate a solution thoroughly to make it work properly. Between the Rope Swing and the Grapple Hook, I wanted to make the Rope Swing more prominent than the Grapple Hook. But alas, it was not meant to be like that...  

And so, the Grapple Hook came into being. Well, at least into being worked on. This mechanic also solves some design problems, like not being dependent on a certain layout to work. It can work, horizontally, vertically, diagonally, upwards or downwards. It has a lot of wiggle room and a lot of options for the player and for me as well. It also solves a level clutter problem: if you had 10 ropes in the level, that level would seem very very busy and confusing. Maybe cool, I don't know, but certainly confusing. The grapple hook, on the other hand, only needs grappling points and those blend in naturally with the environment.

Onto non-technical related stuff. Remember the bridge at the beginning of the first level? Here's a refresher:

Now, the bridge has been replaced with something more appropriate for the setting:

To be fair, it's a marketplace asset, but it does the job better as a placeholder than that blocky version. This will be the template I will build bridges in the game.

Also, some advancements in the level design department were made. Worked on the Rock Pillars level that will hopefully showcase the Grappling hook.

I don't know if you can see it, but in one of the screenshots, you can see the UI widgets for the grappling hook points. Let me zoom in.

OK, so that's it for today. This day was much more productive than yesterday...well at least less hassle-y. See ya in the next post. Bye.

DAY 27

Today was a smashing success. I managed to fully implement the Grapple Hook and it feels splendid. Of course there were some bugs and still are bugs left unsolved but it is working.

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

Will update with GIF once it's done

As you may have noticed, the character reaches the end location of the grapple, then proceeds to get launched a considerable distance afterwards. Yes, it's a bug, but it is very easily fixed (a matter of tweaking a few values here and there). Another bug would be that no matter in which direction you look, if you press the Grapple key while you are in range of the End location, you can grapple. Again, this one easily fixable with some stupid hacking (a matter of scripting a trigger with a Begin Cursor Over function to allow or disallow grappling).

Short but sweet, impacting post, I know. See ya in the next post. Bye y'all

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 

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. 

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 [i]except[/i] 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=shari...

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. 

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.

[b]Features:[/b]

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.

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, [b]very[/b] 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 [i]drawings[/i]... 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

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=shari...

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.

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:

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 over on TIG forums. 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.

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.

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.

 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

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.  

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=shari...

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? Unreal engine 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.

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.

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. 

DAY 41

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

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

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

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

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

OK, done

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

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

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

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

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

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

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

DAY 42

Today I did not spend much time implementing things as much for various reasons:

1) I tried continuing work on the level design for the second level. Did not get very far because I got a mental block as to where I can continue building the level. I had three paths in mind that the player could take, and they look as follows:

Yellow Line represents path 1, orange line represents path 2 and the blue line represents path 3. Dotted line means that the path goes behind the rock pillar. The paths are numbered my order of preferrence

I am not sure yet all the advantages and disadvantages each path has, except for path 2 (orange), which would be that it would makes the most sense but is also the shortest route. All I know is that if a player sees that humongous rock pillar, there will be a certain percentage that will want to break the critical path and reach the top. And I need to facilitate that for the player. And the path that makes the most sense in implementing does not really facilitate that. I'm very sure it will dawn on me in the following days, but as I was working on it, it did not.

What I did manage to implement successfully (but not completely) is the Fall Damage component. Nothing really exciting, I promise, so I have nothing to show. What the implemented fall damage does now is simply print on the screen if the player died of fall damage. This is because I had a brain fart and implemented fall damage before I implemented a health bar/system.

The crusher hazard also got finally migrated and modified to fit this project and it works as intended. For this, I actually have a clip. The mesh is super bare bones, but it works for now.

https://drive.google.com/file/d/1_qdy-SrwbxM0IcCf0yuznJcBl5XV3bT3/view?usp=shari...

One more thing I want to fit in this project is a jump pad. It's not a complicated process, but I am very concerned that the version I have in mind might cut the player's momentum short.  Let me explain why with a painfully crude Paint drawing:

This is how the jump pad should work in a way that is thematically appropriate and has a strong degree of credibility. On a plank with a pivot point, a rock is placed on one end. The player can jump on the other end. When the player jumps on his/her designated end, the rock at the other end will get thrown in the air, shifting the orientation of the plank. When the rock falls back down, the player is then thrown in the air. The plank and the rock have now reset to their original state.

The problem might arise during that short window of time when the rock is in the air. Of course, there are other problems that may occur, maybe even the idea itself. But this short window of time when the rock is in the air concerns me the most because in order for this to function properly, the player input [i]has to be disabled[/i] during that small window of time the rock is in the air. 

This irks me badly because, here I am, a staunch proponent of Half-Life 2-style cinematics, that gives the player unbroken (but very diminished) control during in-game cinematics and I propose to a player a gameplay mechanic that completely cuts off the input in order to work properly?

But then again, this particular jump-pad mechanic might actually work, warts and all. It's true that there are other options, which I have to come up with. But at the moment this is how it's going to be implemented. Sure, something like a geyser might actually work, if the game properly suspends the player's disbelief. But this can only be used so many times.   

Moving on, other mechanics have been migrated successfully, but not all tested, because it's late here (3 AM at the time of writing). Taking a look at their respective blueprints show that everything is in place and can work as is, but again, I haven't tested them. These are conveyer-belt like mechanics (just some simple volumes), including a portable conveyor belt that I know for sure isn't working properly. I will provide a clip once I get it up and running.

So that's all for today. See you in the next post. Bye.

DAY 43

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This alternative path provides two distinct advantages:

1) leaves room for further exploration

2) adds replayability value.

This also brings 2 disadvantages:

1) more work to be done to the second level

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

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

So see you guys in the next post. Bye. 

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 

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.

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.  

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: 

https://drive.google.com/file/d/1czjPM37WlahmSk_376HRMCd8L8AItOE_/view?usp=shari...

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:

https://drive.google.com/file/d/1p-JH26N3iXFcOcFyKCdkHAgQdzvv6Xcf/view?usp=shari...

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. 

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.

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

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.  

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.

And here is how that area looks like from the inside: https://drive.google.com/file/d/12dxP6Jm-FmGLVN1nuZACmgDcghIVk0MC/view?usp=shari...

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 :D

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

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:

https://drive.google.com/file/d/1W8X4U14MffonwQkcxd-H3dFxiNszo_mK/view?usp=shari...

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:

https://drive.google.com/file/d/1hmLxzyjELvko4zpLqZ7pCKta4XXLEX8P/view?usp=shari...

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.   

DAY 51

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

https://drive.google.com/file/d/1104HJirjyQTzKfHRZGjnWSpc-LMBQu2J/view?usp=shari...

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.    

DAY 52

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.

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]*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.[/i]

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.

DAY 54

Finished the layout for the first cave level today. And it. Is. A. Monstrosity of a level. Check it out:

To give you guys a sense of scale, the player character is actually in this screenshot at the very entrance of the cave. I genuinely had to double check if it is there in the screenshot before I uploaded it, because the resolution of the screenshot it small and I could not see the character clearly. But it is there.

Here is the player character in the biggest room there is in this level:

And here is the character in the same room, but from another angle this time:

Sorry about the missing walls, it's late here and I just noticed I missed this spot. I'll do it tomorrow. 

Now this layout will certainly present issues regarding what mechanics and how many mechanics and hazards should be placed here, because of the sheer size of some rooms. Certainly it leaves a lot of elbow room for the pacing of the level, but I'm more concerned with how many hazards, obstacles and so on are placed there because of fatigue issues (how many mechannics are too many for this level). This level should be a lot of fun to populate.

The colossal rooms are left empty on purpose because I need to have a lot of space for the path and a lot of space for the eye candy. I'm really excited to populate it, seriously.

One small fun fact: the entire cave is exactly as tall as the dam. Look:

Holy crap. Even if I would've planned this out, it wouldn't have been this exact.

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

DAY 55

So I've started working on the ledge climbing  mechanic. I'll be honest I had no idea where to start, so I had to look up a tutorial to give me a head start. As soon as I found a tutorial that was close to my vision, I watched it and, in the first 2 minutes, a real mind-blow occurred. 

I learned that you could actually add trace channels to an object. This means that you can apply a tick box to an object to detect if the object itself has a certain collision property. In this context, it means that you can have a hundred cubes scaled as plain walls, but you can add a channel to the collision that is specific to ledge climbing and tick the channel on only one object. This results in one out of the hundred items is technically climb-able. 

The revelation also hit me that I approached wall running wrong. If you remember, I had an issue where the player character does wall running if an object is at a certain angle, but it would do some accidental wall running most of the time. The way I approached it was that I controlled the angle to be obnixiously precise and it worked, but still had rare and minor issues with accidental wall running. With this new nugget of wisdom, I can apply the same technique to wall running. The more you know...

Anyway, the implementation did not go smoothly: 

1) there was a wrong if statement in the blueprint, it was set to true instead of false when jumping to grab the wall. Glossed over that section multiple times when debugging, because I figured that the player must be jumping when grabbing the wall, but eventually caught it. The player is not grabbing the wall while jumping, it grabs the wall when falling. 

2) I placed three functions at the event tick: the ForwardVector LineTrace, the height vector LineTrace and grabbing the wall. This one was very quickly fixed by removing the Wall Grab function from the Event Tick. It caused the player to go in 0,0,0 position and grab... ugh, something...I have no idea what it grabbed....the ground???

3) This one was particularly tricky. At this point, everything should technically work, but the character did not grab the wall. I tinkered around, but got nothing, for about an hour or so. Got a very intense flashback of the Rope Swing debacle. But I figured it out: I had an InRange Float node that was bound to one of the character bones (pelvis), but the heigh of the pelvis did not match the InRange Float node values, which were less than the pelvis height. Doubled the minimum values detecting the pelvis in the InRange Float node (from -50 to -100) and now it worked as intended.

So that's it for today, I'll upload a video tomorrow. See you guys in the next post. Bye.

DAY 56

Work continued on the Ledge Climbing mechanic today. It was slow and with issues. And it was definitely one of those days that felt like nothing works, even though I've clearly made progress. Soul draining, isn't it? So much fun...

What have I achieved so far:

- The character hangs on a designated model.

- The character can move left and right while on the ledge (animations implemented but not wired because of a little issue written below)

- The character can drop from the ledge at the press of a key

- Clamp the yaw rotation of the player camera while ledge climbing (look 90 degrees to the left or to the right)

What I am planning to do:

- Make the player jump up on the ledge above (+animations)

- Make the player jump to the left and to the right (+animations)

- Make the player move on corner ledges (+animations)

- Make the player climb on top at the end (+animations)

Here's what the progress looks like:

https://drive.google.com/file/d/1bQZsSLex65qlTmBjlZpDZmUyO9v_VnEE/view?usp=shari...

So far things are actually going OK-ish. I mean, the basic functionality is there, I can build something with what I've got, even if it is simple and crude and one dimensional. There are a number of issues that occurred, though:

1) When hanging on the ledge, the player character rotates with the camera. And this one is going to be either the easiest or the hardest issues to solve, for one simple but big reason: The camera attaches to the capsule component of the player. This means that whenever I rotate the camera, I rotate the capsule (DUH!). Also, as a consequence, whenever the capsule is rotated, the player gets rotated. And herein lies the problem: the camera needs to be separated from the capsule component, which UE4 does not allow to do. It has to be linked with the capsule. I did thought of a solution, but it felt flat on it's face: adding a second camera. This is when I discovered that UE4 does not allow you to attach a camera outside the capsule component of the character. So that went out the window.

2) I managed to restrict the camera yaw movement while the character is hanging on the ledge and it works just fine. The problem is that when the character exits the hanging state, the camera either: a) retains it's 180 degree yaw movement or b) is stuck at the 0 degree angle and you cannot move the camera left nor right, only up and down. An absolutely stupid fix solved the problem: In the Set View Yaw Min and Max (minimum and maximum angle at which the camera can turn on the Z-axis) the values were -359.9 for min and 359.9 for max. 

Yeah, THIS works.... Because if they are exactly 360 max and -360 min, it will remain stuck in a 0 degree angle and you can only look up and down, but if its 359.9, you can do 360 movement dozens of times....THIS works...jeez  

3) I may have fudged this one up quite a bit, but here goes: I've used the ThirdPersonAnimBP onto the FirstPersonCharacter BP. When going into the Event Graph of the blueprint to create some logic for the animations, I've encountered a stupid problem. The boolean variables do not interact with the Cast to First Person Character node, only with the Cast To Third Person Character node. So either I have to rename the ThirdPersonAnimBP or I have to re-make the First Person Anim Blueprint with the Third Person Anim logic. 

4) The player character doesn't stop at the end of the ledge, but goes a bit more further. This might be solved easily by tweaking some of the tracer capsules' values. Hopefully...

Taking off my visual scripting hat and putting on my designer hat, the way the ledge climbing feels now is... just slightly out of place for a first person game. I dunno... it feels kinda off. It feels like this mechanic should belong in a third person game. But I've seen wall climbing in first person shooters before and they worked. But they did feel like it feels in my game. I have a suspicion that it's a camera thing that holds this mechanic back.

As I write this, I've remembered that I had a talk with a user from another forum about a particular feature for when the player is looking down the dam. He suggested using an FOV kind of thing (which ultimately turned out that he was reffering to a Dolly shot like in the movies). I tested this feature at a different field of view for when the player is grabbing the ledge and it sort of works. It feels different at 110 FOV than at 90 FOV. This time, it also gives an actual sense of height, which is cool. It actually is an improvement. We're getting there guys!!!

Nice view, though.

What also really feels satisfying is the drop from the ledge. It's a small thing to be satisfied of, but it really matters. The drop has a nice bounce to it, not in the cartoony sense, but in the dynamic, interactive sense. You feel that when you drop, it's not just a simple drop, it has a weight to it, a throw to it, a certain force to it. It feels like the character put some effort into the drop (if that makes sense). 

I can add things that might work. I remember mentioning this a while back (don't remember in which post) but if the ledge climbing or wall climbing is paired with some boulders or rocks falling, that would make a lot of sense and would add a challenge. Also, if I pair the wall and ledge climb with a stamina meter, then things will get really interesting. 

When I'm done with this mechanic, I'll implement 2 more mechanics to see how they feel. A dash mechanic (though right off the bat it seems a little bit on the nose) and a ground pound mechanic. The latter felt a lot of fun in another project, and I found myself using it out of the blue.

That's all I've got for today, ladies and gents. See you in the next post. Bye.

Day 57

Very very quick little update: the character rotation while on the ledge is fixed. Here's how it looks now:

https://drive.google.com/file/d/1ROx3v3VsOmVGeErvtExlMlKQQjcIFScA/view?usp=shari...

I went in the wrong direction about solving this problem, at first. I thought that the camera and the capsule are the only two components that are directly involved in this issue. Turns out I overlooked a tiny little detail: the player controller. 

The player controller acts as a thread tying the two components. That's obvious. What wasn't obvious (at least to me) was that you [b]can[/b] snip this thread and tie it back again, contrary to what I believed before, like the "camera has to get bound to the capsule component" thing....it's still valid. But you can tinker with all variables in the FirstPersonCharacter panel. As such, I found out that there is a tick box for the Use Controller Pitch Yaw. Untick it and the camera moves independent from the player character. It was as simple as that.

Lesson: When you think you have all the variables you need to solve a problem, think again. And then again, and again until the solution clicks.

DAY 59

Today I have finished scripting the ledge climbing mechanic. This has definitely been way more complex than I have anticipated and it was riddled with bugs. But it is functional, now. I have showed you the left and right movement, the jump on ledge, can't remember right now if I showed you the climb up ledge, but now I'm showing you the corner ledge movement. Here's how the last part looks:

https://drive.google.com/file/d/1y5AFX2KuCmygc9xm9XTIq_qGMBOwz1M1/view?usp=shari...

There was a lot (and I mean *a lot*) of work to do on this, but once the hard part was done, parts of the script would get recycled. 

What follows is a pseudo-breakdown of the mechanic. It's not in the order I implemented it and it certainly doesn't have all the nuts and bolts mentioned because I'm brain dead right now and can't think straight:

TRACING THE WALLS AND LEDGES: I had to have the character detect a wall in front of him, how high the wall is, if there was a ledge that could be walk-able left or right, where the player can jump up the ledge and corners that the player can turn on (well, that sounded x-rated and grammatically wrong at the same time). This was fairly easily done with tracer channels. This was the repetitive task. Tracing forward, tracing up, tracing left/right, tracing the jump up and tracing the corners, all of then worked almost exactly the same.

LEDGE MOVEMENT I genuinely thought I could get away with the bare minimum of Set Movement Mode to "Flying" and the adjust the direction of the flight, but sadly that wasn't the case. I tried to cheat my way out of this one, but of course the scripting gods would not allow it, so I had to do the work. And of course I only had a vague idea on how to do it. So after pouring through blogs, tutorials and some UE documentation, I made it work. Minus the animations, those do not work now. And the tracers don't properly work either: they don't detect the edge very well and the player remains stuck when reaching either end of the ledge. This was my first experience with the Animation side of Unreal Engine and there is a whole lot to learn here. This is where things got overwhelming to me and start making a ton of mistakes and lost motivation. But I ploughed through and I got through with it.

LEDGE CLIMB ENTER and DROP: This one was straight forward to do, especially the drop. This is where I used the Set Movement Mode to FLYING in a successful way, with a lot of booleans. The actual ledge climb was a ton of work and had to research extensively, because I had no prior know-how. The way I managed to get it to work is with a lot of vector nodes involving the Wall Normal, the Wall Height and the Wall Location. 

CORNER LEDGE MOVE:  This was surprisingly not a lot of work and involved a lot less movement nodes than I thought I will implement. Basically lots of boolean variables and if statements, with enabling and disabling the player controller and an anim montage. That particular anim montage did the gruntwork for me 

There are some other elements, like the FOV change during the ledge climb and movement and the Camera Clamp, but I got these two working almost instantly. Some bugs regarding the camera clamp: the camera clamp works relative to the world, not to the player. If you want to grab a ledge facing north, the camera clamp works perfectly, but if you want to climb a ledge that is facing east, you would encounter the hilarious glitch of being able to look at the character's face. I'll get on it as soon as I get some proper rest. 

All in all, 90% of the ledge climbing mechanic was new ground for me and got intimidating as hell the more I worked on it. What ended up was a monster of a blueprint script that I can barely fathom how I got it to work. But it works, at least partially.   

To pick myself up from the rut that was the loss of motivation a few days ago, I also implemented the ground pound mechanic. This is an easy mechanic that is quite fun to play around with. Here's how it looks:

https://drive.google.com/file/d/1xLz4nfhVGcPfT9i3Es2J5tBbwFUNcEJ0/view?usp=shari...

Finally taking my scripting hat off and putting my designer hat on, the ledge climbing feels rather responsive, quite robust and smooth (most of the time, anyway). It's still glitchy as all hell, but it lends itself to a good feel. It's far from perfect (hell, it's far from fully working, what am I talking about?) but it does give you a greater sense of exploration as is. At it's best, it gives the feeling that you can go anywhere, the feeling that somehow (dare I say) you've outsmarted the environment.   

The Ground Pound mechanic is a lot of fun and I feel that it can be used in a lot of creative ways. The problem with this is that the mechanic can get old really fast and I must keep this in the front of my head. It does run the risk of the player using the mechanic even when he is not supposed to and that is what might cause the problem of it getting old fast. Spacing it out is not necessarily a solution, because the player can still ground pound even without anything in front of him/her to get out of the way.

I think I'll be taking a break from scripting mechanics for now. The ledge climbing really took a toll on my endurance and stretched my knowledge limits a whole lot. In retrospect, I shouldn't have done it now, but I did. It would've been better if I'd either done it at the very beginning of the project and get the complex stuff out of the way fast or some time later down the line, maybe after I had done all the other mechanics. I'll be focusing on some level design until after the holidays. Maybe I'll add something light like a double jump mechanic, a dash mechanic, something very light script wise. But I certainly won't do anything complex until after the new year. I'll also do the bug fixing after the holidays as well for the ledge climbing mechanic.

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

DAY 60

So since I've recently stated that I'll be taking a break from the scripting side of things, I've been focused on the level design aspect and started a new cave level, because I already had the placeholder modular assets and I did want to make four levels in this particular vein. At the moment this is WIP (like everything else) and not finished (layout wise) so here's a glimpse of how it looks now:

The intention and direction is to make this level loop on itself, or more precisely have elements akin to a Mobius strip. To be honest, that was the goal for the first cave level, but ultimately went with a different flow, because that's what the level wanted to go.

It's an interesting challenge, this whole looping on itself thing. I first encountered it in AER Memories of Old and was quite intrigued by it because it offered a little bit of spatial awareness challenges, a little bit of orientation challenges and a little bit of freedom by way of choosing your own route to progress through the level.

Though I have not played much of AER, I believe this kind of level can have slightly more looping. So, I've started having a loop that has a Mobius strip-like path. After testing it, it seems like a good start. It gives the sense of progression without the feeling of walking in circles, accomplishing nothing. There are no mechanics or hazards here yet, as is the case with the other cave level. This is because I want the feel of exploring to be as top notch as possible before continuing placing gameplay elements. If the exploring part fails, then the other gameplay elements are nearly worthless ("polish a turd and it's still a turd" kind of thing). So, nail the exploration first, add mechanics and hazards later.

The Mobius thing starts when the player reaches the octagonal-like module. For now, only the left-hand side of the level is done and I'll continue working on it today. All this was implemented yesterday, but it was getting too late to write a devlog at that time.

I'm really curious if a Mobius Strip can be placed within a Mobius Strip. That's a real challenge right there. :))

I'm fairly excited about how this level is going to turn out. I say "fairly" because I'm also concerned about it's quality. Yes, it's an interesting element to add, but is it good? Will it be fun? Will it be challenging but not frustrating? Will the mechanics be the cherry on top of the cake? These questions add to the excitement, but also to the concern. Must treat this with care. Like I said, testing it did give good impressions, but let's see where it goes from here.

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

DAY 61

I've continued work on the second cave level and I have to say, I'm liking where this is going. Like I've mentioned before, the intent was to make some sort of a looping on itself level and it was a success.

The Mobius strip like loop works OK as is. Here is a picture of how it looks from a gameplay perspecive. Assets are highlighted strictly for better visibility of the space (it's a dark area).

The green arrows indicate the direction that the player can take. The red arrow with an X indicates that the player will hit a dead end and cannot progress, therefore no go.

Notice that you can only get on the bridge if you complete the left-side part of the level first.

The large opening in the middle of the room will become accessible once the player completes both the left hand side of the level and the right hand side. There is going to be a puzzle of some sort, this part I have not figured out yet.

There is still work to do: I have to cap the open gaps with walls and test the level to see how it feels like it is.

I have to toy around with the large straight strip of rooms that follows the mobius strip section. The intention with this section is to be in complete antithesis with what the first section of the level is. Whereas the mobius strip section is full of ups and downs, left and right, this straight section would be one (almost) continuous line of hazards. I had to break up the continuous line strictly for the player to have a sense of surprise when entering the next room.

This entire section would have tons of hazards for the player to deal with. What hazards, I don't fully know yet.

Also, I'll toy around with the sizes of the 4 big rooms in the straight strip. There may yet be some value in diversifying the size, to allow for more complex gameplay. But this also remains to be seen when I will reach the documentation phase.

I didn't notice when I made this level, but from a top-down perspective, the entire level looks like a key. Very neat and totally not intended. Maybe I'll do something cool with this info. Maybe have a treasure hunt here, or a collectible. Look:

The plan for this level is for it to be the first cave level the player encounters, right after the player climbs up the dam. This will look something like this:

The green arrow represents the entrance to the cave and the purple arrow represents the exit. At the exit, there will be something that the player can see from the position shown in the screenshot. Something like a big landline with a light on top of it.

It may not be visible, but the cave is on the left side of the dam. On the right side, I do have in plan to implement an exploration area with some sort of a tourist attraction thing going on, with a big statue and a tower of some sort. It's still vague in gameplay and in a layout, the exploration area, but the visuals and elements to be placed are pretty much set in stone.

On the other side of the dam there will be a lake. Surrounding the lake will be peaks and valleys and forest with the peak of the mountain visible in the distance.

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

DAY 62

Hey, all. I wanted to start off this post by wishing you a Happy New Year and may all your endeavors come to fruition. And I also hope you guys had a great holiday.

I know I did, but sadly, the holiday season is over. Which means that  now it's time to get back into the thick of things. And back into the thick of things I went. 

Today I continued work on level design. Since I did enjoy my holidays and don't want to get back to working on the game aggressively, I felt that I should be continuing what I had done prior the break. Ease your way back in to work, guys, don't go full gung-ho on it.

Here's how the level looks now:

NOTE: The arrow shows the entrance to the level. The screenshots where the player character is present show the entrance.

So up until now, I've made 2 levels with modular pieces that serve as "cave" levels. For the player, it provides a break in pace, mood and feel. It also provides contrast: up until now, you had big, lush and wide open spaces and now you have tight, but expansive passageways. For me as the developer, it provides a showcase for level design and (hopefully) in 3D modelling. But what's more important, for the project It means a breather when it comes to assets population. This would allow the project to "throw out" any previous areas. 

So I figured it's time to both "do the same old song and dance" (doing a cave level) and mix things up just a tiny bit (it's not actually a cave level). And I present to you... the mines.

What you see before you is (hopefully) a showcase of "restricted use of modules". I only used 4 different modules out of a total of 9 in the construction of this level: the L shape, the T shape, the square shape and the + shape. There are one-offs of the octagon shape and of the C-shape because of necessity, but that is pretty much it.

What is not "pretty much it" is the level itself. What you see here is about half of the level. And I'm beginning to think these levels are getting out of control, dimension-wise. For the 4th and final cave level, I'll have to restrain myself and not make the level so big. Big does not always mean good, design-wise.

Speaking of "design wise", the mines feel pretty disorienting, which is both a good thing and a bad thing. It's a good thing because it challenges your sense of space and orientation and it's bad because if you (as a player) generally lack a sense of space and orientation, it has a lot of potential to be a frustrating experience. Then again, it's just the empty layout with no gameplay to speak of...that comes later. Even so, precautions must be taken when set dressing and making the puzzles for this level. I'll simply have stripe decals of varying colors on the walls to guide the player, for now. Maybe these will evolve into something different, but having decals...it's a start.

All in all, 2022 started great for the project. Tomorrow I'll tackle some cloud materials and a monkey bar mechanic.

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

DAY 63

Hey, guys. How's it going? Today I have finished up the greyboxing for the mine level and let me tell ya, it's another monstrosity of a level. Here's how it looks now:

This is the view from the entrance of the level (south is towards the bottom of the SS)

This view is from the left side of the level

This view is from the right side of the level

This view is from the east wing

This view is from the west wing (I'll explain what's with the enormous looping shaft later)

This view is from the level exit (north is towards the bottom of the SS)

This view is from the bottom of the exit area

As I've continued to work on it, I realized that I might have gone a bit overboard on the whole twisting-turning layout of the level. I made a conscious decision to simplify the exit area as much as possible, so instead of going intricate, I went bigger shaft size. So the shafts at the exit area are double in size compared to the entrance of the level. The exit area will feature 2-3 blockades (I don't know if I used the word correctly) where the straightforward path is blocked (obviously!) so the player must resort to using the side shafts. 

It goes without saying that the whole vibe to this particular level is "disorientation". I mean just look at it, how could you not be disoriented? :D So far, it felt like "good" disorientation (if such a thing ever exists) but I'm very reserved about this feeling. A very accurate representation would be made by the people who will playtest it.

OK, so in the screenshot with the west wing, you might have noticed a ridiculously long shaft that starts from the bottom and ends at the top. Well, that would be the shaft to the elevator that will send the player near the octogonal shape room (which is near the beginning of the level and "coincidentally" is also where the west wing part of the level begins. This was made to avoid making the player backtrack the entire way up. Instead, the player will have a feeling of progression and he/she will be sent near the beginning of the level without the need to backtrack. I just remembered that the east wing does not have this feature, so I'll update it as soon as possible.

Speaking of updates, I promised you guys an update on the cloud material and the monkey bar mechanic.

Cloud Material: Scouring Youtube for tutorials for me to learn about Arrays and whatnot, I came across a tutorial that taught Cloud materials. It looked super-awesome in the thumbnail and said to myself "I've gotta do this". And so I did. Luckily, it was an easy tutorial that yielded great results. See for yourself:  

https://drive.google.com/file/d/1QMcL9tG2WRS8iSe143TX4frd0l37rVtD/view?usp=shari...

Pretty cool, right? There's one tiny little problem, though. It's a little bit on the expensive side. The base shader has about 150 instructions, but other parts of the shader (2 other parts, if I remember correctly) have almost the same amount of instructions. Having a big number of clouds like this might get super expensive on the GPU, so there's room for optimization to reduce the amount of instructions. Otherwise, it's damn cool and has a lot of detail due to the post-process that is in the project.

Monkey Bar: This one was sort of made on a whim some time ago. I figured "If I can make the player character jump slightly up as well as jump forward a lot, I could replicate the Monkey Bar thing from Doom Eternal and the branch jump from the recent Tomb Raider series". And so I did. Check it out:  

https://drive.google.com/file/d/1b1OqHMsPtkkOBUff-gubaGdFu8RZLRs3/view?usp=shari...

It's slightly exaggerated but it feels OK. I exaggerated the intensity of the jump because it felt too much like the jump pad (which is what the monkey bar script is based off of, like an extra connection from the character movement, but to the X axis AND the Z axis....seriously, that simple). What it does great is that it contributes greatly to player momentum. And since it's rather small in size, it can fit in all kinds of tight places.

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

DAY 64

Hey, guys and gals. How's it going? Hope y'all having a great time. As for me and Against The Mountain...well, more work has been done on the level design department. And surprise surprise, I've been dabbling into the story a bit. Well, more specifically the main villain. And even more specific, the main villain's motivation. Let me tell you about this first

Now, I've written dialogue in the past for a previous project, so this is not new territory for me. What is new territory is the complete freedom I have to take the story wherever I can fall in love with. And what's also new is that I have the opportunity to create a villain. As a bonus I do not have a time-frame for completing it, which is amazing. In the previous project that I did, I did not have the luxury of time nor having villain. Imagine having one week to work on dialogue for about 10-15 missions and you can figure how that turned out (spoiler alert: bad). But not here!

What I did accomplish was to crystallize the main villain's motivation for doing the things that he did. Because I do not want to give you any kind of spoiler, I'll keep it both specific enough and vague enough. I hate vagueness with all my being and I don't like telling you guys anything remotely vague, but it's the story we're talking about here and I need to keep as closed of a lid as possible.

Anyway, so the villain's gripe is that he essentially despises people who destroy things others have built and will go out of his way to get rid of people like this. In his main motivation monologue, he will reference an event that happened in his youth about how people enjoy destroying things and how people generally revel in any sort of destruction. This, coupled with the fact that he considers himself a builder and anyone who interferes with his work is automatically labeled a destroyer makes for a grounded, believable and dare I say relatable villain.  

This is as much as I can say without spoiling anything. Told you guys it's going to be vague.

Anyway, moving on to the level design progress. To give you some context, I am in awe with sequoia trees. I've never seen one in real life and it's on my bucket list to see one with my own eyes. They also make a great subject for any artistic medium, whether it be film or photography. But I haven't seen many games that have sequoia trees. Maybe there are some out there, but haven't really seen them. So with this in mind, I've started to build a level based on a sequoia tree. More specifically, inside the tree and outside/around it. Here's the scale of things:

Now, I've done my research and found out that the tallest tree is about 95 meters / ~310 feet tall. There were bigger trees, but this one would be the tallest tree still standing. Well, the tree in the game (which actually has a name, "Father of the Forest") is 200 meters / ~650 feet tall. The tree's bark thickness is 4 meters / ~13 feet thick and I did not calculate the circumference/girth, all I know that the radius is 20 m/65 feet. I intend to give it a backstory as well, when the time comes.

Anyway, so the gameplay implemented is inside the tree and here's how it looks like:

While testing it, I found that it's both very fun and absolutely infuriating at the same time. There are a lot of places where you can near miss the jump and (because of the wall-run mechanic) accidentally start to wall run again. Now this is technically an issue, but as you might remember, the wall run will always work on exactly 90 degree angles, which is what the cylinder placeholder currently has. Now it occured to me that I could've used a cone BPS, chop it's top and make it so that the base and the top are not equal in size (top must be slightly smaller).

With the restrained space, I found that I can vary the mechanics a lot and it would create a desire in the player to chain these traversal mechanics. Evidently, this is something I want to explore further. Also evident is that I should keep this in mind for all levels, like DUH!

Though I haven't spent that much time on it, I did have a blast figuring out the gameplay. If it's as fun to play this level as it was working on it (even though I barely started) then by all means, Gods Of Computer Games, bless this level.

Here's some more shots:

Anyway, that's all I have for today. See ya in the next post, bye! 

DAY 65

Hey, guys and gals, how's it going? Here, things are going well. Continued work on the tree level and here's how it looks:

It went the same as yesterday: quite fun to make and fun to try out different paths and scenarios. In my testing, I have also timed how much gameplay is here as well. So far, with all that you see in this level, there is exactly one minute of gameplay if you know what you are doing. 

Now, I'll have to give you guys some context for this level. This tree serves as one of the villain's "well hidden" makeshift facility. And quite possibly the first that the player will encounter. There will be some desks, some laptops, some desktop computers, some desks, some beat-up sci-fi looking, some  machineries and stationery and so on. Also, there will be items that can be inspected as well as notes, documents and letters as well.

While playtesting, I've discovered a bug with the monkeybar in that it only throws you on the positive X axis, no matter where you approach it from. It's supposed to throw you in the direction that you are walking. I'll look into this, it should be a quick fix (though it usually never is). 

Well, that's it for today. See you guys and gals in the next post, buh-bye! 

DAY 66

Eyooo, what's up guys and gals? Hope you are having a great day.

As you have noticed, I took a break from updating the devlog because of a lot of various IRL stuff I had to tend to. Nothing serious, tho. But I'm back with a small update. 

I left things off in the tree level, so naturally I went back to it and added more stuff to it. Here's how it looks:

It wasn't necessarily a deliberate thought, but the first thing I went for was mixing things up in this level. At the beginning of it, platforms and mechanics were pretty tightly place in relation to one another. Keeping things is fine for a period of time. But keeping them tight for the duration of the entire level is not good for level pacing. 

So to mix it up, platforms and mechanics are now more "loose" and far apart. And to be honest, it feels slightly better. Just slightly. What this allows me is to chain certain mechanics together to create some momentum. What also kind of holds me back is the relatively tiny space for chaining these mechanics. Or it might be a challenge, not a hold-back. We'll see.

If you guys see some empty space in between some platforms that is unreasonable to reach to, that's where the wall running mechanics comes in. Also, thhose white meshes? those are for ledge climbing. Random purple circle? That's a jump pad.

So with the work I did today, I'd say we're about halfway done with the first iteration of the tree level. That's all for now, guys. See ya in the next post. Bye.

DAY 67

Eyo, guys and gals. Hope you've having a great day. So, work continued yet again on the tree level. And I've gotta be honest, I had no idea where to go with the level when I started today. Tried some things that didn't work out and was slightly puzzled. But then, out of nowhere, a thought came to me. How about letting the player go outside for a bit? And I did just that. Take a look:

I'm starting to feel particularly good about this level in particular. When working on it, it's like the brain is on the lookout for ideas and then grabs one in mid air, just like a frog catches a fly. Good stuff.

BUT...there is a big "but" (noice)

I tried the wall run mechanic on the exterior of the tree trunk. And I've gotta say it bumps up the difficulty by a lot. Doing a wall run on a curbed is a challenge on the inside of the trunk. On the outside....hooo BOY what a nightmare. This one dangerously borders on the bad kind of frustrating. And I'm seriously thinking of removing it. But after I playtest it with other people. It definitely is something to master (I needed about 3-4 tries to get one run right) but I think it's too much. It really spikes the difficulty quite a bit.

What I also tried is a NEW mechanic, the crusher. Right now it's garbage, but it has a lot of potential. Some adjustments are needed: the crusher doesn't detect the player all the time, therefore it passes through him/her instead of pushing the player over. Should be an easy fix, the crusher moves too fast for it's collision to detect the player capsule (I've seen this before, it really is a quick and easy fix). While I'm at it, I should work on the crusher's timeline curve for it's movement.

This area is pretty consistent, feel wise. It's 80% a walk in the park and 20% a complete nightmare (because of the wall run).

Other than that, I have nothing to add. So that's it for today, guys and gals. See ya in the next post. Bye!

DAY 68

Howdy, guys, and gals. Hope y'all are having a great day. Here's me with another update on the development of this game.

This tree level is taking much longer than anticipated, but it takes shape pretty nicely. I'm a little unsatisfied at the moment on how things are shaping up to be for the latter half of this level. Let me show you.

So what I am trying to do at this articular moment in time is mix everything that has been thrown around in this level. At first, the player is presented with a few mechanics: wall run, some grappling hooks and some platforming. In the second stage I've added the jump pad, the monkey bar and the ledge climb. In the third part of the level, I tried "going out of the box" so to speak, by introducing the player with mostly familiar mechanics in a different setting, with one key addition, the crushers. 

In this last section, the player is going to experience all of the above combined: You go in and out of the tree trunk and all previously presented mechanics will be encountered in this level. I haven't gotten that far down this particular road, but what I have keeps momentum.

Speaking of which, After I've expertly played through the level, I've noticed that the first outside area breaks momentum in a noticeable manner. 

It's kind of difficult to explain with words, so bear with me. 

What I mean by this is that up until now, the player was presented with various mechanics, only to have a halt to them. Maybe it's a placement mistake, maybe I paced the level wrong at one very specific point (don't know which one), but throughout the first half, there's an anticipation for something more difficult that the player experiences or the player reaches and maintains momentum, only to have it lost when reaching the latter half of the level. It feels "out of left field" but in a good way. BUT after this specific point, the experience dips a bit because of lack of challenge.

When the player reaches the area that I've shown you in this post above, at the moment it feels not as challenging or exciting or at the very least defies an expectation. In a bad way. So I'll keep a mental note of this and work on it tomorrow.

Other than that, not much to add. So that's it for today, I'll see you guys and gals in the next post. Bye!

DAY 69 (noice)

Hello, guys and gals. Hope you are having a great day. Here's me, providing you with an update on the state of the game.

Today I have managed to finish the tree level. Well at least the first iteration of it, anyway. I'm too tired to test it now from start to end, but I will do so tomorrow.

It's been quite a ride with this level. Mostly smooth, surprising more than occasionally and inspired most of the time. I'm especially satisfied with the ending. While very short, it manages to keep you tense. Check the last part of the level out:

As I've said yesterday, the main focus was to try and mix inside exploration and outside exploration. I cannot attest to the success of the endeavor, because I have not tested it. I'm especially satisfied by the bridge section with missing planks and crushers. It's really tense and provides a satisfying conclusion to the level.

That's it for today, guys. I know I usually write a lot, but I'm tired, it's late and can't see straight :)). I'll make it up in future blogs, I promise. See ya in the next post, bye! 

DAY 70

Howdy guys and girls, hope you are having a great day...well as great as a monday night can be, anyways. Me? Oh, I'm having some second thoughts about the layout of the tree level. And I'm spilling the beans as to why.

Recall that I've been using square platforms in a tree trunk (which is round) and we all know how square pegs fit in round holes (spoilers: they do not). For your convenience, here's and old picture to illustrate how it looks:

That is not pretty in the slightest, but it does the jobs of placeholding and fast iteration. Now, since this level is pretty much done on a layout level (pun not intended), I'd figure I'd "ennicen" the looks of the placeholders. Ennicen is not even a word, I just made it up, but it wouldn't be a far fetch from what sh*t I've heard thrown around. To ennice something is to make something nicer, I've decided :)).

Anyway, so the most reasonable thing to "ennicen" is to make the platforms fit the round shape of the tree trunk. Now, I'm by no means a 3D artist, BUUUUT... I think I know how to do it.

The outer radius of the tree is 2000 unreal units and the inner radius is 1600. Height of tree trunk is irrelevant, because I'll shrink it down to 100 unreal units to be the same size as any platform. There are 64 sides to the cylinder. With this info I can do the following:

- make a semicircle from this full circle

- take the semicircle and half that

- take the quarter-circle and half that too

- repeat process until left with decent sized platforms that can look/feel aesthetically pleasing and thematically sound.

Once those small pieces are done, I can go replace the square platforms in and around the tree. I'm super curious as to how it's going to turn out (I've barely started the work on it)

I will try this in 2 different radius thicknesses (is "thicknesses" the correct term in the context of the radius even? Genuinely asking, I'm not a native English speaker....I think it's "wide"...right? RIGHT?!?!) 

So, on the left hand side we have the 100 unit radius difference between inner and outer radius (1m) and on the right hand side we have the 200 unit radius difference between inner and outer radius (2m). Now, this might be the least interesting screenshot of all time, but I assure you in the end is going to be worth it...which end? The game end, of course. When the game ends development...*sighs and daydreams about a day that is so far away it is incomprehensible*)

I will give it a shot with both thicknesses, because variation. Let's see how that goes.

Now, for the next change that I want to add: if you'd recall, there is a bridge at the top of the tree trunk. This one:

And it has great value for the gameplay experience. So I thought "why just keep that as the only one"? Just place more of them, with variations of course (bridge with full set of planks, bridge with few planks missing, bridge with half the planks missing and so on). I did not expect I would enjoy that bridge so much I'd be making it as a recurring death trap thingy.

Speaking of which, this new idea will allow me to place multiple types of death traps near and/or around the bridge. Some crushers in various orientations, some death traps like arrows, swinging axes and so on (oh yeah, I have those now). Keep in mind, if one touches you, you die.

So yeah, that's about it for today. I know I haven't been showing off with new and interesting screenshots, but it is to be expected when you post this often and about this particular subject too (replacing place holders), but this might be the beginning of a pretty looking tree level instead of the "functionally doing good-to-great, but fugly looking" level.

I'll see you guys in the next post. Bye!

DAY 71

Why, hello, guys and girls. I'm back with another small update on the project.

Last post I've talked about making some aesthetic changes to the current version of the tree level, because the placeholder meshes were simply too primitive and ugly. And in this post I shall present the new changes. Mostly visually, though.

This is the entrance to the level.

Continuation of the entrance

The one below is a layout modification:

...of this area:

This is the view from about a quarter of the way up the tree. Compare the above screenshot with this one:

Now, as you can see, there have been both cosmetic changes and layout changes, but mostly cosmetic. The changes done to the layout happened because I'm trying to find spots for more broken bridges in this level. Broken bridges allow for a more precise type of jump and it adds tension for the player. 

I'm about halfway into the level with replacing the yellow platforms and it looks heaps better. All the platforms visible in the screenshots will be replaced with logs, planks and/or branches in Blender, and the form of the placeholders allow me to make stylized models of platforms in this specific shape.

Not only they are newer versions of these placeholders, but they are also smarter versions: the outer radius of the platform matches perfectly with the inner radius of the cylinder that is a placeholder for the hollow tree. The gimbal/gizmo is placed in the same position as the center of the tree trunk. Put these two things together and you got a placeholder that, when copied in the exact same location as the tree trunk, can be rotated on the Z-axis flawlessly and not worry about minute positioning of the mesh. 

Simple stuff, really. But it helps a lot production wise. There are about 9 versions of these placeholders and they all work wonderfully.  

So that's about it for today. Tomorrow I'll be focusing on replacing the platforms in the other half of this level. See ya, bye! 

Day 71.5

Hello, guys and girls and hoooo BOY, do I have a treat for you guys. Now, I'll keep this short and sweet. Yesterday was the 6 months anniversary of this devblog. And to celebrate this momentous occasion, I present to you....(drum rolls)....gameplay footage of the entire tree level.

No more talking, enjoy: https://drive.google.com/file/d/1LNPIkungJeKm3qWPWP0QAONLc5Iy8Xr9/view?usp=shari...

Let me know what you think, I can't wait. See you in the next post, bye!

DAY 72

Hey, Guys and girls, hope you are doing as well as possible. Me? Oh well...as you have probably observed, I haven't posted any updates recently because I've been learning the shader basics in Unreal. You know, all the math nodes, data types, input vectors, View Space, World Space, Object Space, & Tangent Space...that kind of stuff. Riveting stuff, almost illuminating. Even thought I might dabble in HLSL/GLSL programming.

Though I must confess that, creatively I've hit a roadblock when it comes to level design. Or, more specifically, what musicians and writers call "writer's block". And I've hit that roadblock for quite a while. It's not a pleasant feeling, especially if you think of yourself that you have untapped creativity at your disposal, like I do. 

To give you some context for what follows, I'm also a musician and have been a bedroom musician/weekend warrior for 20-odd years. In all these years, I've hit the writer's block many many times and sometimes I was able to break through the block. 

And, naturally, I thought that the lessons learned in music breaking through writer's block could help in game dev as well, but could not for the life of me figure out how to do it. Until I've spotted the similarities.

1. If your level does not seem to go anywhere, no matter what you add to it, it's time to scrap some part of the level that currently doesn't really work. Do not be afraid to scrap something. What you have scrapped in one level can be used in other levels and/or in other ways.

2. If sections of your creation do not gel together but in and of themselves the sections are great, it's time to focus on other things. This is because stress/pressure has very likely reared it's ugly head and there's nothing really constructive you can do about it except detach from what you are working on.

3. Play other games to get inspiration from. Do other things, completely different things (watch a movie, go for a walk) and allow greater inspiration to hit you.     

4. Writer's block is a mindset. When you fight against a mindset, you actually feed it. When you work with a mindset, you actually feed it as well. Therefore, if you fight writer's block, you feed writer's block. When you work with creativity, you feed creativity.

With this in mind, I've decided to re-make the second level, aka the Rocky Formations level. Well, this:

And this is how it looks like now:

Keep in mind, this is still a first person platformer, but the mannequin is there to show the scale of things. Although I was asked if I would make a mix of First/Third Person platformer, it would still be a First Person (though I would leave the game moddable, and if his/her heart desires so, he/she can make a mod).

The very first thing on my list was to make the very first scene of the level fit the scene composition rule of thirds, with the addition of making it breath taking (basically this would be the first WOW scene in the game, but don't quote me on this). I'll explain later on what the rule of thirds is. The end-point of the level was moved way in the back and the level landmark got way taller. 

As a natural consequence, the level just got way bigger. This was a desired consequence, though not necessarily something that I directly pursued. To populate the level further, I've decided to stick with the BSP brushes instead of using the stylized meshes and replace said meshes where the case calls for it.  

One of the bigger mistakes made was basing the level around "not-exactly-prototype-material-but-this'll-do" meshes. Stuff from the Unreal Marketplace. While that's absolutely great for emerging ideas and going with the flow, not exactly great if you have something specific in mind. 

Since this would technically be the second level (again, don't quote me on this) I would tone things down a bit mechanics-wise and only add the basics. Also, I would be toning down the difficulty of said mechanics. 

The biggest gripe I've had with this level and the reason I've decided to re-do it is because of the scene composition.  It had it's moments, but I knew I could do much more. So I started documenting myself about scene composition. One thing that I have been made aware of (although I kind of knew it from photography) was the Rule of Thirds. 

The rule of thirds means that the screen is basically split into 3 rows and 3 columns. Depending on the artist's desire, the focal points of the scene could be aligned according to the horizontal or vertical lines OR at the intersection of the lines. Like so (hope this gif shows up)

And I thought that I can incorporate this into Unreal. And so I did. The way I did it is as follows:

1. Downloaded a Rule of Third grid picture (with transparency) off the internet

2. Made a material in Unreal with said grid

3. In the material, I loaded the texture and plugged the RGB into Base Color plug and the Alpha into Opacity plug.

4. In the first person character blueprint, I added a plane mesh under the FirstPerson Camera, so that it is attached to the camera.

5. In the Event Graph, I had this blueprint code attached to the plane mesh:

6. With the plane selected, I changed the rendering stats and unchecked the visible tickbox. This is so that the grid will only show up when the G key is held. (the G key is only for development, not a feature that will be present in the game...unless I make a photo mode)

And voila. With this simple tool, I can check the scene composition in-game. Would actually check if I can do it for the editor camera. Like so:

That's it for today, I'll elaborate more about this level in the next post. Buh bye.

DAY 73

Hey-oooh, guys and girls. I hope you guys are doing as great as possible. I'm back with another update on the devlog. I know that I haven't been posting as regularly as I used to, but work on the project is still ongoing. Me, I'm still learning to program shaders and have taken quite an interest on the technical arts side of things, which surprises me because I was afraid of anything programming for as long as I can remember. And to a certain extent I still am scared because it's an overwhelming subject to me.

As for the project itself, remember last post where I stated that the second level is being remade? Well, I am still remaking it and that is what I have worked on since my last post (project-wise, anyway). And since then, functional-wise, I am 75% done making iteration number 2.

Here's how it looks, bird's-eye view:

Structurally, the difficulty is toned-down a lot (maybe too much) and the hazards/obstacles are laid out in such a manner that they explore every scenario possible as of right now. Since I don't have enemies in the game, the mindset is basically "the environment is the enemy". Plain and simple, no two ways around it. 

A new addition to the level is the long and hollow mesa in the middle of the level. This mesa came about similarly to how going out and around the tall sequoia tree: as an answer for the "variety" question. At first I was really skeptic about the idea, because on paper it seemed like it was not very interesting. But the idea kept popping in my head, even though I kept dismissing it. And since it kept doing that, I decided to give it a shot and see what comes of it.

Lo and behold. One long mesa, 4 different sections. Breakdown time!

This section is where I introduce the grappling hook:

This is the section where gameplay with the grappling hook gets slightly complicated, adding falling platforms to the mix:

This is the section where I throw off the player by introducing a different mechanic (the vertical moving platforms).

And the is the section where everything introduced before gets thrown in like a melting pot of mechanics:

To be honest, it's just OK-to-good, gameplay-wise. It's nothing spectacular or out-of-the-ordinary, it's more of an area where the the player can learn the grappling hook mechanic in an easy-to-learn environment. What might be spectacular is the addition of some big holes in the walls of the mesa that reveal the environment from time to time. Towards the end, things get more difficult, as the player has to use timing to his advantage in order to reach the end of this section. Improvements will be made to make it as good as possible, but the focus is to have a structurally sound foundation to the gameplay.

The stage following the hollow mesa is simply a transition area towards what was the entire second level and is now the last stage of the second level. Although I wasn't really for it, I added the jump pad in this transition area to get the player to the last area faster. But that may soon change it. This is because I settled upon having to only walk in the transition areas, no jumping or anything else that might cause the player to die. Just let the player breathe, take in the environment and allow the story to unfold during that time (for this level, in voice-over form).  

The last area (which again, was previously the entire second level) will suffer some modifications to it, since I've also added a double jump feature. I've replaced the stylized cliffs from the previous iteration with BSP brushes so as to have better control over the layout of the area. I've stated before that I'm OK with the "happy accident" of stumbling over a path that the player can take due to the cliffs placed, and I still am OK with it. But I want more control over the layout of the level, because I feel that in this level I relied too much on the "happy accidents" thing. True, they got me going in a good direction, but I can't rely on that too much.

In the following days I'll continue working on this second iteration and keep you guys posted. After this, I may take a break from level design (should I finish the tree level too) and focus on implementing the swimming and the wall climb mechanic.

Anyway, that's it for today. See you guys in the next post hopefully I'll post sooner than I've been doing lately. Buh-Bye! 

DAY 74

Alrighty, day 74. Hello, guys and girls. hope you guys are having as great a time as possible. I'm back with another update on the project.

So up until now, I've managed to prototype about 80% done with the Level 2 version 2. 

Made some minor modifications here and there, because some meshes were weirdly placed before, like so: 

Now, what's left to do is the following:

- Complete/remake the last section of the level

- Make secret areas

- Place more tall rocks clutter

Anyway, after these steps are done, I'll most likely move back to the tree level. And then after that, I'll be moving on to swimming and wall climbing, as stated.

On the to do list was testing as well. I have to say that I really think this level is too easy. Within the first minute of gameplay or so, I start to zone out and that is not good. To be fair, my focus gets kicked into gear a bit later in the level. And this concerns me just a little. As a precautionary measure, I'll make minor modifications to the first section to make the gameplay more "active" and alive, so to speak. 

One other small thing I managed to do, this time regarding the tools, is that I've added a one-point perspective grid to the camera, similar to the rules of third grid.

Someone mentioned something very helpful on another forum, and that thing is to use these grids as guidelines. And he speaks the truth, you can get caught up way too much in a cycle of constant checking, evaluating and reassessing composition. A dash of "guidelines, not rules", a sprinkle of "good enough is good enough" and some good old fashioned planning + deadlines would kick you into high gear and make you not think too much.

And that's all for today, guys and girls. See ya in the next one. Buh-bye.

DAY 75

OK, guys and girls, it's that time of the week again. You know, the time I write an update for the project. I'm happy to announce that I've managed to complete Level 2 v2.0. And it honestly wasn't as easy as I've hoped it would be. Granted, it wasn't hard, but not as easy breezy as I thought.

For one, I was left in a complete stump as to how I'm going to end the level. The previous iteration looks something like this: 

While being an extremely tense and calculated section, the above does not really fit with this second iteration, which serves as being a introductory section more than anything. 

Anyway, here is hot the last section of the level looks now:

(Spoiler alert: the oversized campfire is a placeholder)

This section definitely has better structure to it level design wise and environmental building-wise. Compared to the first version, this definitely looks more as if the person who made these obstacles worked around the environment and with the environment. Whereas the previous version looked tacky and obviously gamified. Definitely not perfect, there are still a lot of touch-up to be made, but it's a big step in the right direction.

While playing it front to back, not accessing secret areas, it has the same..."problem??" if I can even call it that. It starts as really unassuming (borderline boring to an experienced player) and a low effort type of gameplay. But excitement picks up after the first quarter of the level. I would say that the level is not really challenging, but it has kicks of excitement sprinkled all over the place.

But I'm still hesitating it calling this a "problem". At certain points, I would want to add some voiceovers (mix of walkie talkie and voice in this level) and the section that is the least challenging is basically a springboard for the voiceovers. So if the flow of each level starts off as the least exciting gameplay wise and then ramp up the difficulty for the rest of the level, I believe something cool might come out of this. But since I don't have any voice overs, I can't tell. Oh, now there's an action item on the to do list, placeholder voiceovers.

Anyway, that is all I have for today. See you in the next post. Buhbye 

DAY 76

Alrighty, guys and girls, it's that time of the week again...after two weeks, but still. A new entry in the devlog is happening now. And I'm here to talk a little about creative burnout and why this thing is kinda sorta normal and OK to happen.

So, have you guys happened to just have a pretty hot streak in your projects, only for that streak to get colder and colder and colder until it hits ice levels of cold? Well, that is exactly what has happened to me. And honestly this was bound to happen, because things like burnouts are what happen when you try to dedicate yourself to a project such as a full blown game.

So, why is this normal? Well, first and foremost, there's a lot of moving parts and stuff going on that you, the solo dev, must handle personally. It's a daunting task, even for someone who is experienced in solo game devs. I actually came to the conclusion that every dev suffers burnout on their projects at some point, but the more experienced devs are coping much better with it. Either that, or they can manage it a lot better than inexperienced solo devs.

So is there something to do when burning out? Well, for starters, take a giant step back from the project. Like seriously, stop working on it and thinking about it for a couple of days or for however long it is necessary. Then get back right into it if you are feeling revitalized. If you are the kind of dev who goes gung-ho about the project, with the "zero-days-off" policy and whatnot, then at most work on some small part of the project or something that gets fast results....or just do some project management in Excel...or testing...

In my case, burnout occurred thusly: after a user stated that the jumping is floaty, I immediately recognized this as an issue after I posted about it. So I decided to do some tweaking in the character blueprint. At first, I didn't really commit to it, just did some tweaks here and there without saving the changes that were made. After a few days of fooling around with the tweaks, I kind of had a relatively clear idea for what I wanted from the jump mechanic. I knew that the jump (from input to landing) should be under a second, ~800ms to be precise. This theoretically felt the snappiest and the most enjoyable jump and I knew about this for a while. I knew the height should be around 2 times the height of the player character. This further added to the snappy aspect of things. What I didn't knew was what other ingredients to use to make the vision come to life. This mystery didn't last long and I've started messing around with the gravity. And yeah, mesing around with the gravity was for the better. 

But as I started to test out the changes in the levels, I've had a rather unsurprising revelation: all levels needed to accommodate changes to the jump. To be expected, sure. But I did have one surprising revelation: things got way more difficult in the rocky formations level. Which, if you recall, was something that I've complained on more than one occasion. So in that level, *very* few changes were made. Fixed the section where some sequence skipping occurred and made adjustments to the overall layout.

Discovering all these issues, fixing some issues while other issues popped up (of course the height of the character jump affected the jump pad and the monkey bar distances), then fixing those issues as well and the OTHER issues popped up (of course the gravity changes affected the wall run) was just simultaneously draining the joy out of the project and adding to the joy of knowing that the level is closer to being great. 

But in spite all of this, I think I may have regained some of the joy back. Because I've started working on the forest level. I'll only link one screenshot of it, because it's terribly late and I'll be missing my beauty sleep. But here is how it looks as of now: 

I am making a promise to show more tomorrow. Pinky swear.

Well, that is all for today, guys and girls. See you in the next post, buh bye. 

DAY 77

Why, hello guys and girls.

So today I continued to place chopped tree trunks that serve as...well, un-chopped, real living tree trunks. Not much work has gone today, because of a Discord call with a friend (what was supposed to be a short, ten minute or so call ended up being a 2 hour bonanza of talking...not regretting it one bit :D ).

But as promised, here are some more screenshots from the Forest area (including today's work). 

This area would preceed the ginormously large tree from earlier posts and clips. THere are a number of challenges that I would encounter throughout the creation of this level. One of them would be the "kill zone". 

OK, so for falling to the character's death, we've only had heights so far. Continuing having heights will not really go over well, for an obvious reason: variety. So for this area, a thought that keeps popping in my head and doesn't want to let go is the idea of having a huge fire spreading over the area. Or a fire that has already spread wide enough. And that fire would be the kill zone. This allows me to have death situations at low-ground level as well, not just way high above. 

At first I thought about making this area a swamp, but it was already established that the water will not kill you if you so much as touch it. So the next choice would've been fire. Now, the way I want to do it is for it to propagate via blueprints (i.e. controlled situation). I'm not done looking up into this solution, but it is very doable and would look fantastic. Once I have some update on this, I'll tell you guys all about it.

So, that's it for today, guys and girls. See you in the next post. Bye  

DAY 78

Howdy, guys and girls. Hope y'all doing as great as possible. Me, I'm back at it again with an update on the project.

So I've been on again off again working on the Forest level, replacing some assets here and there, making gameplay adjustments and so on. Kind of secretly delaying working on wall climbing and swimming and fixing bugs, but I'll eventually get to that...eventually...

There's still a lot of work to be done, a lot of things to be added and a lot of modifications to be made. First and foremost, I've added a small, make-shift pier with a hut. This would serve as the very beginning of the level, as you'd be arriving in this level via Paraglider.

This pier section would be just for exploration and some exposition purposes. There are two huts (one of them still needs to be worked on) and a toilet, just for fun. Complete with toilet paper.

Inside the first hut there are some computers. I'm not telling why exactly there are computers in a pier near a forest, except that it leaves some story bits for the player to discover.

I've completely replaced the grey tree trunks with a fallen log mesh, just to have a feel about how this level would look. I've also completely replaced all ramps with the bridge blueprint.

So as you can see, work has progressed pretty far in this level. Not up to snuff, tho. I haven't exactly figured out the gameplay: it might be more exploration oriented, it might have some puzzles in it, I don't know yet. But from what I've played, something like solving puzzles to progress to the next area feels right.

Lastly I would actually make a change in how I present the devlog to you guys. In the past few weeks, I've been working on the project bit by bit without updating the devlog. Sometimes literally working just 15 minutes per day, like no joke. Of course, working 15 mins a day doesn't result in a devlog-worthy entry. So naturally, I've decided that devlog entries would be a weekly thing, not a per-day entry. It makes more sense to me both time wise and content wise. Plus I'd have a more balanced work-life-passion project-hobby thing. Hope you guys would also enjoy it in this format.

So that's kind of it for today, guys. See ya in the next post. Bye!

Day 79-82

So naturally, I've decided that devlog entries would be a weekly thing, not a per-day entry.

HAHAHAHAHHA...cool joke, man.....overly optimistic Past Baftis is overly optimistic.

Why hello, ladies and gents. Back at it with an update on how the game is going. 

So I've been struggling quite a bit with working on the game and actually have a work-life balance thing going on. Clearly one of these didn't work out, but I did manage to work on the game more. 

Turns out motivation is a thing and got demotivated in the past few weeks. A vacation (of all things) managed to ease the struggle. Turns out that's what I needed.

So one of the things I've worked on is redesigning the canyon part of the level. There's nothing really wrong with the current version of the canyon, but visualizing the game when falling asleep churns out some pretty inpiring things. One of those inspiring things was the canyon part. Why? I wanted/needed a level where things could get really twitch-y and reflex based and really fast paced. Kind of like Sonic games, but in first person and with jumping. And one of those areas seems to pop up time and again: the canyon.

Now this turned me on big time, and as I started to implement this, I came across what I initially though was a bug. So, I have the jump-pad, right? And whenever you overlap with the jump-pad, the character flings in the air (on the Z axis) and you can go pretty much either way after that. Well, I did try to adapt this jump pad to a monkey bar kinda thing (the pole in DOOM eternal) Where you fling forwards. Well, that monkey bar had a problem: see, the idea is to fling the player forward on the Y-axis of the monkey bar. But lo and behold, the monkey bar does fling you on the Y-axis....of the world!!! So, I though "OK, this is clearly a bug", and went about to fix it. 

Turns out that this isn't a bug. By using LaunchCharacter nodes, the script tells the character to jump on the Y axis of the world, so you can't use relative rotation on the LaunchCharacter node. What this also means is that if I want to fling the character in a certain direction, I'll have to manually input the force on the axes I want that character to fling to. And my brain went "UUUUUUUGH!!?!?!?!" So, for every single directional jump pad/monkey bar that I want in the game, I have to make manual adjustments...."UUUUUUUGH!!?!?!?!" Thank God I don't have to do this on the jump pads that just fling you up, otherwise, I think I might've gotten insane.

So yeah, fun times, guys...really fun times. 

Anyway. For the time being, work on the Forest level is on hold. I've completely ran out of inspiration for it and will touch it once inspiration hits...or I'll visualize it before sleeping again. I'll leave you with only 2 screenshots, since it took a collosal amount of time to get the sequence right.

That's it for now, ladies and gents. See you in the next post. Buhbye. 

Hello, hello ladies and gents. hope you are having a great day. As for me, I'm back with an update on the project.

So the reason I haven't updated the devlog is because I kept putting off making it. Yes, it's that mundane. Because behind the scenes, I actually started working on not one, but two new levels. Let's go!

So the first level I'm going to talk about is the Gap level. This one came (like all good things) in my head, while falling asleep. I though that would be cool to have a level that focuses on wall running and the many ways that it could go to. And, while you can only do so much with a wall-run mechanic, it turns out that it works great when combining it with different mechanics (like, duh), especially the paraglider. 

Now, the Gap level is, to put it simply, a very very narrow canyon. The player, being almost at the top of the gap, must traverse it via wall-running. Here's how it looks: 

It is pretty difficult to capture some screenshots from this level because there is not much space to work with. And because it involves wall running, there's mostly long empty spaces with the occasional small cliff. Oh, but that's not all, there are some Death Traps around this level as well. One of these traps is in the third screenshot, a pendulum axe. The other one is in the BSP brushes, a blade that comes out of the rocks. If any of these traps touch the character, he is dead.

The second level I want to talk about is the Foggy Forest. 

This will most likely be the most simple level in the game in terms of implementation. This is because at it's very core, the level is about orienteering: you simply have some markings on trees/rocks and as the player, you have to find and follow said markings to reach the end of the level. That's it. In this level, you would also have a landmark that coincidentally serves as the end of the level. Said landmark is visible from all across the map if you look for it.

Here's how it looks as of now:

Btw, I was getting really sick and tired of just grayboxes in every single level. SO as a test, I used some assets off the marketplace. So we have GRAPHICS for a change, yay!! I don't know how the level is going to look with all post-process effects on (I'm only using a vignette as a post process effect now, fyi), but I'm sure as hell happy with how it looks as of now. Of course, things will get more populated as time goes. And yes, some trees are not upright (ooooh, that's going to be a pain to fix). 

Now, what makes this level challenging is 1) the low level of visibility 2) finding the markings (they won't be hidden, but they won't be easy to find either. 3) navigating through the forest: it will most definitely have multiple branching paths with dead ends. As such, it will be frustratingly difficult if you DON'T follow the markings. 

Now, there's a fun reason why I made the decision to make a foggy level. 

Initially, I wanted it to be sunny in the level. A hot mid-day kind of vibe. But as it was painfully brought to my attention in the form of hands-on experience, baking the lighting for a level that contains a lot of trees takes literally forever. Like in 2 hours, only 5% percent of the lighting was baked. This was a real problem if I was to iterate a lot on this level. Sure, one could argue that you do not have to bake the lighting at every iteration of the level, and one would be right. But it would still take forever + 6 months to bake lighting if this is how baking the lighting behaves with only trees in the scenery: foliage would be a big pain, props would also be a pain to bake.

So, a little bit off on a tangent, that got me thinking about making photos for textures and how I need to have bad weather so that no weird shadows or anything other than flat lighting appear in the texture. And then it hit me: how about I make a level in bad weather? You know, grey clouds, almost thunderstorm skies. In that weather nothing has a shadow and it looks great, very moody. And then it hit me again: oh, how about fog and/or mist? A little bit of that fog on the trees looks absolutely amazing to me. That definitely set the mood right away. And that is how I ended up doing a foggy level.   

Now, this is not the final layout of the forest because I did this as a test. Trees don't have collision, so that is a big no-no. The path to the end of the level, while defined, I'm not really happy with it. But I'm really happy with the results and I'll continue working on these two levels.

That about sums it up for this update, guys. See you in the next post. Buh-bye

P.S. Hope this time around I'll post more often.