[Peaks of Yore]

Release update!

It's been a long time since I've posted any devlog updates to this project.
I would've loved to keep this devlog going if I had the time on top of working a full-time job, but unfortunately this wasn't going to happen.

With that said, I haven't been idle on this project and very I'm happy to announce that Peaks of Yore is finally out!

Click above to go to Steam!

Release Trailer

This project has been in development for a little over 4 years, and I'm very happy I stuck with it throughout. As I was kind of learning as I went along, I did refactor a bunch of code and reworked a bunch things while I also added new things on top of this.

It was a long project, so it will definitely be nice to have a break and then work on fresh projects!

That is really cool. Looks so professional with all those gizmos. Also funny to see the arm in the editor viewport.

Thanks! Until recently, I haven't been using gizmos/debugging that much, but I've found that it's incredibly useful (and satisfying too!). Tools development is super fun!

That is a really handy tool for your process, I'm sure you will not regret having invested the time to make it.

Definitely! I regret not having done it sooner. Tools development is a lot of fun actually!

I just digged into your devlog and can't praise the concept and execution of your game enough. From what I have seen so far, the tone and feeling it conveys is just incredible. I'm looking forward to see more of this wonderful piece!

Thanks a lot, I really appreciate that!  

[Route Setter Tool]

After a long hiatus, it feels great to be back and working on this!

Route Setter Tool

Since the beginning of the project I have been manually placing all holds by duplicating, moving, and rotating each individual hold. This process of creating levels makes it a thousand times more tedious than it needs to be, so I decided that I needed a tool to make the level creation process easier and faster.

A nice bonus of working in Unity is that it is easily extendable and has some nice built in 3D GUI drawing. Between my day-to-day work and this, I've only spent a few nights on it, but its now in a state where I can make a lot more progress on the list of levels I have planned.

The tool has two components that makes putting objects in the scene very easy:

• Collections/palettes
• Prefab selection

The 'collections' is basically a Scriptable Object that asks for a list of prefabs. This means that I can have a collection of climbable rock prefabs, a collection for obstacles, and a collection for environmental assets with each of these collections having any number of defined prefabs.
This collections and prefab selection system is based on the functionality of ChevyRay's PrefabPalette.

The Tool

One of the crucial things I needed for this tool was measuring the distance between the last holds I've been placing, as well as selected holds.
Currently, the max length in units that the player can reach reliably is anything below 1.50 units/meters.

Selecting two holds shows the distance between them, and if the distance is safe or too far.

There are some contingencies though. The distance of 1.5 meters is only reliably safe if the holds are more horizontal to each other. Once a hold is 1.5 meters straight above another, the hold becomes a lot harder to reach and requires both using side-to-side swing momentum and also swinging slightly backwards while pulling up.

To fix this, I simply compare whether the hold I am currently about to place is too far above the last hold I placed.

The whole point of this measuring system was basically to eliminate the need to playtest as much. There have been too many times before, where I have been recklessly placing holds and not been able to get the distance right - only realising when playtesting that the holds were way too far apart.

For more specific cases like the Slopers (which all have widely different sizes), measuring between the objects shell and the last hold is crucial since there can be a wide distance between what part of the Sloper is reachable if its facing a certain way.

To solve this, I use a sphere cast from the last hold placed to the newly created Sloper. This way I can more reliably get the distance information I need from weird edge cases like this. The cast only happens whenever I have just placed a Sloper or selected one, as I usually need to rotate them a bit more manually. If the cast is from a Sloper and not a normal rock hold, the cast is started from the shell of the first Sloper gets the distance information when it hits the last one.

The sphere cast is nice because I can get away with just casting towards the general direction of the Sloper to get whichever part of it sticks out the most and closest to the previous hold.

The green ball represents the nearest point where the distance is measured.

Two other features I added for the tool were buttons for easy selection and focus of the Player and Summit, since these are two objects that get kind of lost within the scene hierarchy and I need to tweak regularly when adding features or placing the start and end of each level.

Another small but useful feature I've added to the tool is a toggle to have the route visualized in the scene view. When creating a level, some of the rock holds usually disappear for me, mostly due to the visual style, so this feature is great when I need to see the entire route throughout the level. It takes in account all of the rocks I have placed, including other types of holds like Slopers and Micro holds.

The last feature I added was the ability to paint/drag place rocks. When painting, this allows me to continuously place rocks with a set distance, defined by the Placing Distance value. This value can be changed by holding Alt and scrolling up or down with the mouse scroll wheel, so it's very useful when I need to place a whole bunch of holds.

This feature is also extra useful when I need to populate a level with a lot of environmental assets. Applying a random scale to this also gives great results and faster environment creation. I have also made the feature toggle-able by hotkey which always makes working easier.

The lightbluish outer circle is the range of the Placing Distance.

The last two features I added were surface offset, which is self-explantory, and a hotkey to randomise the rotation on the go. The surface offset was needed because some of the holds clip more or less into the wall depending on the type of hold. The randomising rotation on the go is also super useful. The scaling and rotation modes were adopted from PrefabPalette, but modified heavily to suit my needs.

I'm happy I got down to it and actually worked on this a bit more extensively than I had originally planned, because this will end up saving me a lot of time in both playtesting and level design.

Ohh, that’s interesting. And you don’t want lines where it’s bright?

Nope, just the darker formations. I'm thinking there'll only be a few maps with very dark skies, so I'm sure it wont be too distracting. 

Gorgeous! Is it intentional that they're not getting the same diagonal stripes as the rest of the graphics?

Thank you! The stripes / dithering effect is applied based on a luminance threshold, so the clouds are only picking it up if they get really dark. I really like when the clouds pick it up, so I'll probably have to do some more tweaking to get better results on each individual map.
I have found though that the dithering only looks nice on the clouds when the weather or atmosphere on the level is dark / moody, so for most maps the clouds will not have the dithering. If the area is sunny with a couple of clouds getting the dither effect, the stripes becomes pretty jarring.

Example from the Lighthouse map:

... Ain't this the truth of any creative endeavour Seriously tho, people to meet sounds like a really cool addition, looking forward to it!

Very true!   Good to hear another opinion on it though. Thanks!

[Update]

Update

Been busy with life stuff so haven't had much time to work on the game, but I thought I would show a few screenshots of the new volumetric clouds.
The old skies and clouds were basically just an inverted hemisphere with a scrolling seamless clouds texture layered on top of each other. Since the player is also looking up a lot of the time, I thought it would breathe a little more life into the environment by having procedurally generated clouds that had a bit more depth. I am currently using the fantastic OverCloud system by Felix Westin.

The system can be tweaked endlessly, so the clouds for each peak will have different heights, scale, fluffiness, and speed depending on the weather type on each individual level.

Here's a few screenshots with the new clouds, and a sneak peek on a couple of new areas.

Some of the skies need a bit of tweaking but I'll leave that for polishing later.

Characters

Another thing that I'm slightly excited about, is bringing in a couple of NPC characters that the player would encounter as they progress through the game. These NPCs would be going about their own business, but I do have a few things in mind for them interacting with the player.

At the moment, the only thing preventing me from creating NPCs that talk and interact with the player, is the heaps of work it would take, and also because the game has been developed from the start with only the player in mind as a character - the idea of going about on your own climbs in solitude.

Personally, I think it would bring light-hearted charm to the game and some potential for story-elements which the game is currently lacking, but it would be nice to hear other opinions on this - NPCs vs climbing alone (black screen with text only encounters)?

I'm definitely interested at least!

Good to know, and thanks!

Share more, I insist

Seriously, in my experience this is the kind of forum where game developers love to exchange high-level (or even low-level) technical discussions

Might have to now!
Yeah, I agree. I enjoy doing the more technical posts as well as less information-heavy ones, so guess I'll mix it up a bit to keep some ebb and flow.

Loving the animations, they're so detailed!

Very interesting! Love seeing projects where some of the development is outside the digital environment.
Is it heavy to run performance-wise, considering the amount of polys you get from photogrammetry, or do you clean up the topology before putting them in the game? I'm curious about the polycount, since that last walk animation gif looked pretty intensive polycount-wise.

I'm not sure if the assets have some kind of translucency in the materials already, but I think a bit of translucency or subsurface scattering would really help sell the claymation/waxiness. Just a suggestion.

Also, I think a time-lapse or video of modelling some of the clay models would be cool to see (no pressure)!

Nice! Always cool to see the different layers that make up a post-process.

This thread was new to me. This is so unique and interesting! The 1900s sepia æsthetic is a great touch, too. Really cool to see all the tech going into this, and the game itself looks fun to play. Love the pocket watch as well.

Ah thanks, appreciate that! I love to talk about the technical stuff in a more detailed fashion, but I am always afraid that it might not be so exciting to read.

That watercolor shader looks great! Is the wobbliness of the edges done in the shader, or is it a combination of the shader and modelling? Excited to see more as well!

[Time-attack]

Time-attack

Thought I would make a post about one of the features I've previously implemented.

I've been a fan of watching speed-runs for a long time and watching skillful players with deep knowledge and execution of in-game movement and mechanics is very satisfying to me. I've also thought that this game would lend well to speed-runs as the game is a lot about perfecting movement and learning the way both the aiming and physics momentum works.
Naturally, these were considerable factors in my motivation for implementing a time-attack system.


The Pocket Watch

To make it period-appropiate, I thought that a simple pocket watch would be a nice representation of a time-trial sort of system.

Simple polygon modeling and some bezier curves to the rescue.

Modeling and texturing was pretty straightforward. I usually just look up a bunch of real world references, this time relating to pocket watches.

Texturing these kinds of items usually involves going back and forth between Photoshop and Unity. I have to make sure things match up with the post-processing in Unity, but luckily Unity is quite nice as you can just save directly into the project directory which lets you see the change instantly.

I usually have to tweak a lot of the contrast and brightness values in the texture to make sure they match up and look nice in-game.

50/50 Diegesis

One of the things with implementing new stuff is figuring out how it fits into the world. With the time-attack system, I knew this also had to be based in the game world as well. With time-attack systems, I usually prefer when there's a counter visible somewhere on the screen so I know if I'm doing better or worse on any part of the route.

The hands on the pocket watch are also set to be corresponding to the actual timer as well, which will then be displayed later when you finish the run.

Pocket watch hands runs according to game time (just for demonstration)

If I put the counter entirely on the watch, you would have to pull out the watch every time you wanted to check your time, which would be extremely inconvenient and also put your run on a grinding halt. The counter also helps with distinguishing if you are actually on a timed run or not, so this is one of the things I can live with not being purely in the game world.

Using the pocketwatch to start the time-attack, then setting a score on a list of 'Best Summits'.
The scoreboard will contain all peak names eventually, perhaps with more pages for different categories.

The system is set up so you can pull out your pocket watch to ready the time, which you can only do in the starting area of each level.   The timer starts automatically when you grip the first hold and leave the ground. To set a new score, you have to beat the best time, have the fewest holds or the fewest ropes when summiting.

This means that you can set three individual scores based on time, holds made, or ropes used. Setting it up this way, you can essentially can ignore the timer and try to get as few holds as possible, use the fewest ropes. The 'ropes used' score is probably less relevant, except for the few maps that the ropes are a prerequisite. The score basically shows how fast, careful, or daring you are on each peak.

The scoreboard itself is a mix between the 3D model and a world-space UI canvas to input the different text fields and scores.
I've made a few satisfying sounds to accompany setting a new score which includes some cymbal crashing, some scribbling noises for the value being scribbled in, and a bunch of typical pocket watch noises.

The time-attack system was all implemented before the inventory system and also before I even thought about the inventory, so the code also had to be rewritten to make it work with the inventory interaction. Lots of uninteresting code later, and the hand now properly interacts with the pocket watch, with satisfying button-clicks and all.

An actual pocketwatch.

In the end, I think this system adds some decent replayability while also filling a gap in my own need to try and best my own runs. This time-attack system isn't purely for speed-running or besting your own scores, as I have some in-game events in mind based on scores you set.

Next post will probably be a bit about a few updates to the environments.

That dedication to avoid breaking immersion is impressive! It looks like it pays off too (can't tell for sure until I try it of course)

Thank you! Always nice to see your support. 
It definitely pays off compared to introducing a bunch of new buttons, but yeah I should probably get around to making another build so I can get some feedback on it.

The overall feel of this game is amazing

Thank you!

[Inventory System]

Inventory System

Since I have been adding a lot of extra items for use on climbs, I figured that I would eventually need to gather all of these tools under an easily accessible inventory system.
I have always been a fan of keeping interactive systems inside the game world rather than in user interfaces, so I thought I would make use of the player having a belt where every item the player has unlocked would be accessible.


Testing in 3D before coding

To test the foundation of this mechanic, I started in Blender.
I set up the viewport camera to mirror the movement I wanted within the game - keeping in mind the player's horizontal rotation limits and vertical view angles.

I created a lot of the inventory item placeholders during this time as well. Testing it early was useful before I started creating any sort of scripts.

I only created as much of the upper body as the player would actually be able to see. I also created ropes to hang over your shoulder that would be visible while viewing the inventory. I created these to depict how many you have collected / have available for use.

Although the standard climbing arms are stiff with no bones or any IK, I knew the inventory belt had to interacted with using a pair of rigged arms. Another issue with using the climbing arms, was that the climbing arms in game are significantly larger than what they should be for interacting with the inventory belt.
The solution was to have a separate pair of "regular-sized" arms that are used individually when the player interacts with the belt, and so they could be hidden individually when the player is using the climbing arms.

I rigged up the same mesh as the climbing arms, scaled them down, and also added bones to the fingers so they could wrap around objects in the belt.


Creating the interactivity

Making the inventory belt viewable and interactable in game took some time, mostly working out some camera-repositioning, angling adjustments, as well as making the arms look 'right' when they hover over items and grab around them smoothly when you can view the right angle.

Under the hood, I do a lot of lerping with values to get the position and angling of the camera right. The positioning and angling of the camera to view more towards the inventory is lerped gradually depending on the player camera's vertical rotation.

With the arms/hands, the only animation actually happening is the 'reaching' and 'grabbing' on the hands which is triggered by the angle that the player currently views. The arms themselves are moved using IK targets and procedural animation.

Putting all this together took a long time, but I feel like it was worth it rather than introducing a new button for each new item you unlock.

Another important element to the system was that once you hang on to the wall with either hand, your other hand must be able to interact with every item in the inventory belt. If I didn't allow this feature, you would have to constantly switch arms to pick the item you want if they are on the other side of the belt. This would get annoying quickly, so I knew I would have to implement interacting with all items using either hand.
A bunch of time also went into tweaking the hands and IK targets enough to make them look natural enough.

The way the system works now, I can easily implement new items. All I have to do is define an angle with which they will be available to pick from, and then an empty target object which defines each different interacting hand's position and rotation when grabbing the item.

Interacting with items with each respective hand. Also a small preview of a few items that I haven't posted about yet..

Making it work on the ground also meant that each arm would had to interact with each respective side of the inventory, since the player will be standing on the ground rather than hanging onto the wall with either of the hands. When you look down, your view will be locked as long as you are looking at your inventory.

I will probably come back to polishing up some of the interacting arm's movements, but this is good enough for now. I have also got to keep a balance between how many items I add to the belt, as it can get crowded with items pretty quickly. There are only a couple more items I want to add, so it should probably be fine.


Animating legs and fixing clipping issues

After finishing up most of the major work on the inventory system, I decided I needed to do some animation on the legs since I had completely ignored walking animations up to this point. Movement has been mostly focused on the climbing, but a simple walking animation can really do wonders to ground the player more in the world, so I had to get them done eventually.

Good enough for now, as I can always brush up the animations later.

A small issue that came about with the inventory system, was that the items in the belt on the side of the hips would clip into the leg as the leg came around a 90 degree angle. I fixed this by angling the items according to the angle of the thighs. This is mostly noticeable when climbing, but it also adds a bit of procedural animation to the items when the player walks. (You can notice this on the thermo coffee bottle and monocular in the gif above).

There are still a few items left to add to the inventory, but for now I can focus on some more important things for the overall game. I have added some exciting things, both a while back and quite recently that I haven't posted about here yet, so look out for that in the nearest future!

[Automatic Foot Placement]

Automatic Foot Placement

As feet are very important in climbing, I thought that I should at least bring a pair of legs in that would make the player feel more 'grounded' in the world and on the climbs.

Using the brilliant FinalIK asset by RootMotion/Pärtel Lang for Inverse Kinematics, I had a nice system for testing out how the legs would work visually in the game as well.

Before I usually embark on creating new features like, I like to have a clear idea of what the visuals and sound would feel like. This was the case for this system. The boots the player would wear would obviously be period-appropriate, with big wide mountaineering boots:

I began with touching up the legs of mock-up character I had made earlier in the project, which I then tweaked enough to be dense enough in polys so the bones would not stretch the vertices in a weird way.

The boots were more of a focus on the leg system, so the player would be noticing the feet placed on the rock wall.

To stay on the 19th century mountaineering fashion, I also wanted the big 'ol boots, socks, and rolled up trousers.

A solid pair of legs.

I threw together a quick rig with a few IK constraints to account for correct joint movement. The right and left knee bones floating in front of the legs would work as targets for the legs IK bend goals.

In Unity, I imported the legs and parented them to the player. The functionality to detect whether the player is climbing is already in, so I started writing the automatic foot placement script.

When the player is holding on, two different rays are cast to detect a rock face in front of each knee. If a rock face is detected and the player is holding, the IK solver's weights are adjusted accordingly to give a smooth transition from the default position to the IK target's position. The foot will then stay in that position until the raycast's hit point exceeds a certain distance from the last foot position, where it will the reposition the foot smoothly.

Here's a relatively old gif of this in action:

The green dots are where the last positions of the placed feet were, so I can check the distance between those, and the current desired foot positions.

The system required a lot of tweaking certain distances that the foot should stay in place vs distances where it should keep in place, and I reckon I can still tweak it a lot more to make it work better.
The system also makes sure to move the feet out of the way if they're blocking the player's face.

When the player is not in range of the rock face while still holding on, the feet will move back and dangle under the player.
Under the hood, this looks extremely awkward but whatever isn't visible I can pretty much get away with.

For demonstration:

Result

With more tweaking, they have started to look pretty decent.

Adding a small smoke puff effect with some pebbles falling - similar to the hands grabbing onto rocks, and a couple of nice and chunky 'boot-on-rock' sounds, the automatic foot placement system came better together than I had hoped.

Even though the are only seen and heard when looking downwards, the legs do help in immersing and grounding the player more on the cliff while also eliminating the 'invisible legs while climbing'-problem.

Right now you only have legs while climbing, since I haven't made any walking animations for when you are grounded. I would like to amend this in the future but there is still a lot to work on in terms of sheer content for the game.
Now that this system is in place, I do feel like there is something more that I could do with it but I will have to think a bit on it, as I don't want to include a lot more complexity to the game which might detract from the experience of climbing. I'm thinking this could be for later levels but I am not sure yet.

More to come!

Looks great!! Loving the details on everything, and can imagine myself playing it already.

This is a fantastic idea. A stylized simulator - a marriage between the technical aspects and the artistry of the visuals. Good stuff!

Good to hear you're a still working on this, and glad to hear your university work went well!

Thank you, glad you like it!

My fingertips and nails hurt just from looking at those sliding gifs

Would probably yield some thick calluses that's for sure!