Fiddling with Assassins Creed like System

Right now I am trying to recreate a climbing system like in the Assassins Creed Games.

Procedural Ledge Detection and everything is already working great - but the tricky part isn't the actual climbing, nor the animations. It's walking D:

To be more precise: Balancing on bars, pillars, ropes, "spikes".
Examples:




I went with a pretty naive approach of just getting the Closest Point of all Colliders around the Player, then filtering (too far away, already above the player, not reachable with current downward speed), taking the closest one and adding velocity to reach it.

This feels horrible.
Not having anything helping the player when airborne also feels terrible.

This seems to require some kind of prediction system, making assumptions where the player wants to land .. based on velocity, input, maybe even the camera rotation?

And I have no idea how I should add all those vectors ..

(My game isn't assassins creed of course, my player can jump much higher which might make things even more complicated)

Any help appreciated.

 

I think that even in AAA, many interactive elements are marked on level design stage, instead of being procedurally detected. Using things like trigger volumes.

 

Yes and no - I am pretty sure a lot of games have predefined ledges/points for climbing/balancing but I am 99.99% sure it is not based on trigger volumes. It's more like a nav-mesh.

My game on the other hand has to use a procedural system because the player can change the environment. I think I will just go with a very stupid imperformant approach first and then sort things and increase efficiency over time. Because having all idk 20 (?) possible results sorted out in a single foreach loop is just way too complicated.

 

Yes and no, it's call "tools", let you decide and bake results, but gdc vault show that assassin's creed over abused procedural generation for anything he can get away with.

 

Still, nothing gets generated on runtime. And depending on the scope of the project, I think developing such tools can be more trouble than it is worth

 

Well it's not an opinion, it's how things are done, it's amply documented all over the internet

https://www.gdcvault.com/play/1024029/-Ghost-Recon-Wildlands-Terrain

There is enough High performing indie rogue lite like risk of rain 2 to not bother adressing this one.

 

I have to admit that I didnt research this topic enough, and those videos are impressive. Still, techniques from games with a budget of a small country are hardly applicable to anyone here. (and we do not know enough about level design in OP's project to compare it with roguelikes). Even in case of Horizon, the "small" team of 4 worked on biome generation ONLY Not on enemy AI, character controller, ability system, etc.
What I was getting at by "even in AAA" was to pre-annotate things to make the detection easier. Even in most naive case, make those bars OP mentioned as prefabs with a select Tag or Layer. No matter if they will be placed by algorithm or by hand, this'll still help to filter the unwanted stuff out instead of searching through ALL colliders in the vicinity. I could be more specific if OP would provide more details on the project. How much procedural generation is involved in making a level, and how exactly player can "change the environment" will be the most important details.

 

In my experience, I never went past ledge detection with a simple raycast sweep up wall until it fails. But what is more important, performing a scan in a direction specified by input looked like good option for me. In modern 3rd person games, camera is orbiting a character, and then movement forces are applied to character in camera space. So, the "attempted direction of movement" would be camera.right * h input axis value + camera.forward * v input axis value. Then, a BoxCast, BoxCheck or SphereCast of limited radius could be performed in this direction to look for objects marked as "bar"

 

Oh don't worry, I was just lazy and skip the small indie, because there hasn't been a convenient repository of talk for smaller team, but I guarantee you, there is equivalent, and most importantly, there is the asset store, tutorial, twitter, youtube, too look at stuff. Minecraft was indie not long ago and has plenty procedural, no man's sky was a 14 team big, only got marketing push from sony NOT financial, spelunky, risk of rain 2, astroneer, wildermyth, FTL, blueberry kingdom, dead cell, cubeworld, terraria, don't starve, valheim, road 96, delver, 20xx, deep rock galactic, many more just for the runtime generation!

 

It is funny how you mentioned No Man's Sky, a game who took more than a year of actually adding content after release to get to playable state, since developers couldnt live up to their marketing lies of generating something from nothing. All the titles you've mentioned have shown is that procedural generation lends itself well to dragged out Early Access model, when devs are essentially selling promises and "potential". Still doesnt mean that it is suitable for any developer and any type of game. It is not procedural generation itself I take issues with, but fanaticism and magic mentality surrounding it. Pretending that it can superceed basic laws of computing, like "garbage input equals garbage output".

 

You want to hear more about the project? Sure, but don't tell anyone yet (just kidding)

Videos are the best to describe it, so I'll show you what I've got right now:

This is the current state of my procedural climbing character.

And this is the current state of .. the rest of the game? xD

A Game where you can destroy buildings - and you play as some kind of Cole (infamous) or Alex Mercer ([PROTOTYPE]) Superhero Character who can climb those buildings (or whatever is left of them).

When Chunks of a Building fall down, they can rotate and become stable again - which changes climbing spots/ledges and creates new ones.

I know, I know, all of this isn't very impressive right now, it's very rough and completely work in progress, but I am sure it will get way better with more "visual eye candy" (particles, post processing) and audio.

Buildings could be built procedurally or by the player, minecraft-style (or idk, Rust, ARK, Fortnite). There will be Bridges, Factories, Towers and normal Houses. Resulting in a lot of edge cases for climbing spots. So a procedural system seems unavoidable.

And I definately need some kind of ascending buildings without stairs, because stairs can be destroyed. Climbing is just a cool thing I liked from other games, so I went with this approach.

Right now this is more of a side project because it is somewhat big and complicated ->

custom physics engine for calculating the stress on buildings so this doesn't happen:


plus the procedural climbing, plus some kind of procedural navmesh for enemies.

The game world will be a lot like Red Faction Guerilla -> open world (yes I know how hard that is, I made one in the past, but maybe I can reuse the tools I wrote to load/unload chunks so the framerate stays alive)
with "villages" or "fortresses" (10-20 Buildings at a spot).

Maybe I'll need some clever LOD for the buildings, we'll see.

So yea, superhero / supervillain who can destroy buildings and punch dudes through walls. That's the concept. Minimal story, maximum focus on gameplay. (even when I love writing stories)

 

Oh this surely complicates matters. Scanning in the intended direction of movement should do the trick, still. Your character controller should have something like movement vector somewhere, use that as your scan direction. SphereCastAll https://docs.unity3d.com/ScriptReference/Physics.SphereCastAll.html should give you array of all collider hits in the given direction and radius. Which point is chosen as "hit" per individual collider is the question that needs to be tested though. I believe it should be the closest point to the SphereCast origin. Then you could run your ledge detection code up from each collider hit point to determine which of them are climbable. Finally, pick up closest ones. Later today, I'll see if I can draw some schematics as examples

 

BTW, can the individual blocks in your buildings be broken further?

 

OverlapSphereNonAlloc is the foundation for my ledge detection system ^^
Sphere Cast .. well, it just provides one hit per collider (first intersection point of sphere & collider), ignoring all colliders that start inside the the virtual sphere that is moved through the 3D space.
(because a sphere cast is basically moving a sphere)
I tested all of them, BoxCast, SphereCast and CapsuleCast (which is used in the system to check if the character has a clear path to a climbing ledge).
But I am just dealing with primitive colliders and convex mesh colliders (everything can become a rigidbody), so I went with OverlapSphereNonAlloc, getting specific points and checking for overlaps with ClosestPoint (ClosestPoint will return the input point, when the point is inside a collider).

The direcion is somewhat complicated - that's why I was talking about a predicion based on velocity, input and maybe camera rotation.
Infamous 2 for example just uses the character velocity and once it starts moving towards a climbing/balancing-spot, you can rotate the controller-joystick as much as you want, it is completely ignored. I analyzed their climbing system because it is close to the one I want to create. Overall it feels kind of clunky. So the playerinput should influence the predicted movement.

Yes, this should be possible in the future. It's more of a visual thing for the building physics.
But for the climbing system, it will influence the ledge detection (and make things more complicated).

 

The climbing system is basically split in three parts:

1) Ledge Detecion - which provides lines and points in the game world where the player can balance/hang
2) If the character is airborne -> slightly alter the velocity, so he moves towards balance/hang points & lines
3) When already balancing -> The actual movement on those lines & points

... and 4) The whole animation thingy xD But with Final IK, that's not a big issue.

I think I am almost done with 1 & 2 .. point nr 3 is somewhat tricky .. entering and leaving balancing states - from a flat ground -> to balancing on a rope -> back to flat ground without falling down
.. preventing running off ledges
.. understanding where the player wants to move
all combined with somewhat fluid movement and animations.

 

Wow, you went more in-depth with this than I ever tried. I could only advice you to use inputs (converted to camera space; as it should already be basis of your orbiting third person controller) exclusively to provide your scan direction. Having input direction determine the choice of next climbing point should feel more responsive than velocity. And why I asked about breakable blocks; this sadly should invalidate my idea about marking them somehow at the prefab state

 

Once the whole climbing system works with animations, I'll post a showcase video on my youtube channel. So if you are interested, you can follow me there. ^^

For now, I think I have all the information to get it done, thanks to this post. ^^ So, thanks everyone who commented here ^^