Official New Standard Asset Characters - Third Person

Link from Breath Of The Wild is probably my most beloved TPC in recent games. He is incredibly agile and can get practically anywhere, you just need to make him to. He just feels natural. That is the key point in it: he's really responsive and he will do about anything you want given your input commands and his movement abilities (including beloved paraglider) are really well suited for exploring. He truly represents the player with all the great agility: you are given the rules and stats on how to effectively move around early in the game and you base your further logic on how to progress based on those rules. This feels awesome.

Some other notes: his animation and speed are really well adjusted based on the slope, indicating you early that the road ahead is bound to be hard to climb, so the game tells the player to prepare.
Camera is also quite good: it's pretty much zoomed out and it gives you a nice look near Link so the player rarely needs to adjust the camera to take a closer look at something near him.
Also on that note: the camera's speed is slow, but that makes it perfect. It makes targeting much easier and removes the need to tilt the stick slightly which can make you nervous really easy. It feel smooth and relaxing.

 

Prince of Persia or Tomb Raider might be the best third person characters controllers to date regarding the full range of movements they can employ. Being able to easily replicate all of those movements would be a HUGE help, currently I am having a lot of trouble with the whole wall walking thingy

 

@willgoldstone my personal favourite are the recent ND games and last one it think is from HZD. And for why, it's the responsiveness of the input and the fluidity of the animation and character response from the input. No delay,good transition between animation, stable/doesn't jitter in high frequency rough surface, and leg IK (come on, why your own unity character assets never have proper leg IK??!!)

 

I'm with @Kolyasisan on Breath Of The Wild. Link is easy to control, and looks pretty good while you're controlling him. Riding a horse in that game is also fantastic.

BOTW is as much a game about vertical movement as a game about horizontal movement. You spend a lot of time climbing or paragliding. And both are fantastic. Link transitions between states based on what you're moving him into without a single hitch. Move into a slope, he starts struggling. Move into a wall, he starts climbing. Jump onto the back of a horse, and you're now riding.

When climbing, you feel completely in control over where you are going, and changes in movement are instantaneous.
Paragliding has a lot of conservation of momentum, but even if you miss a landing due to miscalculating the paraglider movement, it never feels unfair, due to consistent results and a very good camera.
They've also nailed the transition from water to flat land and water to climbing, as well as the transition from paragliding to climbing. It's never awkward - and moving from water to land is awkward in every_single_game.

To achieve something like that, the controller needs to:
- Have easy-to-access data about the geometry around the controller, so scripts can use that to make decisions.
- Have easy-to-access data about current heading, speed, etc, again so scripts can use that to make decisions. This is especially important for eg. the paraglider or swimming
- Have a good way to change between states. This should just be handing being replaced with a different controller gracefully. As an example, it should not be hard to maintain velocity when replacing a paragliding controller with a falling/walking one.



A final note: A good third person character controller needs to always respond to the player's input as fast as possible. This sometimes means transitioning between animation states in ways that doesn't look good. The alternative is situations like "I was holding back on the stick, but since my character needed to finish the forwards movement animation, I ran off the cliff in front of me and died". For some good examples, watch about 2 minutes forwards from this video about Max Paine 3.

The design philosophy of the animator controller is the complete opposite of the correct thing here. Since all transitions happen due to pre-defined transitions, every single transition must be authored. This means that unless you define every possible transition, you get instances where movement feels bad.

This means that the character controller should in no way be hard-coded to assume how it's going to be animated. Ideally, the packages should ship with examples for how to make them animate with the default Unity setup, as well as root motion, but ditching those things should not be a problem in any way.

 

@willgoldstone just fyi for the new character assets, please make sure the rig bone have a proper local axis, the rig for ethan have a messy axis

 

For me, @Kolyasisan and @Baste have nailed it on the head for what makes an excellent Third Person Controller. The limitations that I have noticed for out-of-the-box functionality has forced me to re-think using the engine for certain game ideas. My ideal 3rd person controller is fluid, responsive to the environment and flexible to unusual transitions.

Games like BOTW show how the camera and animations don't hinder the gameplay experience through rigid transitions, unflexible melee collisions, and glitchy camera work. The collisions, animator controller, and default camera assets need to be updated to reflect common modern game features at a basic level.

END NOTE:
I think it is wonderful that Unity is taking the time to ask users for suggestions for the ideal 3rd person controller so they can make a better Standard Assets pack. I hope all of our feedback will be taken and applied to the improved package.

 

Joint message from my programmer and I

A well built, comprehensive simply configurable character controller would be a godsend. It is, however, a non trivial task. One very important aspect of a modern character controller, that many character controller designers tend to forget, is to implement good client - server communications.

It is a problem, I agree to choose a framework that everyone agrees on, however currently uNet and Photon are the two that I feel are the most mature and utilised. The problem I find when choosing a character controller is that, as like most assets, they are largely black box - even if the code is available it is a chore to understand them implicitly enough to implement a good network layer, and even if you do, your work has to be redone every time that controller is updated. So, we are stuck with the dichotomy of building our own character controller, as none of them do exactly as we want, or accept their limitations.

----
Often times a badly setup Camera Controller is what will screw up a character controller. Given that Unity has recently bought and given so much effort to Cinemachine, I think it would be a perfect asset to include. I'm curious, if as baste mentioned, about the changes of animation states. There could be a system like final ik\puppetmaster that could put the playables API to work. [Link]. It could patch in between the different animations states making things smooth, so we wouldn’t have to think up every instance of animation handoffs before hand.

 

In Mario 64 ds (maybe it is in the original but i have not played that one) you can press l to center the camera behind the player. That feature really helped the player and helped remedy the weird controls. In games where the characters already feel good to control it feels even better. So something kind of like that would be cool.

 

Horizon: Zero Dawn. I like controllers that flawlessly combine dual analog controllers, one for controlling the direction/movement, one for looking. I found this impossible to do with the 3rd person Unity standard assets. I mean it's probably possible to do, it's just well above my abilities - I tried for about a month and gave up. Had to go for another asset - it was lite version of a paid asset - and while it worked, ok, I wasn't totally pleased with it and stopped working on that project.

 

Please please please whatever you choose provide clean rigs!

Also, some quadraped rigs would be nice, its 2018 and the modern day after all!

 

A few thoughts. General character controls I've enjoyed have been PS4 Shadow of the Tomb Raider and Metal Gear Solid V - both felt there was freedom of movement. Personally I liked the MGS double tap for run, rather than combination buttons. Tough some form of transitioning speeds (eg crawl-walk-jog-run) would be good.
Some time ago I played Resident Evil 4 (I think that was the one) on the Gamecube with it's wild looking controller. I remember thinking at the time, that although it felt weird compared to other controllers, it felt by far the most comfortable to use once I'd settled with it.
Rigs - Male & Female for sure, but why stop there? i.e. Elderly characters and child rigs would be cool too (not every animation is a soldier!). Maybe also Rigs for people with special needs - such as wheelchair bound or with crutches etc

Oh and animals - not just a horse or dog... I mean there are so many , lets have a 'Zoo Rig' - included as standard - with a ton of included anims (lol - I'm being greedy) - Did you see that recent SIGGRAPH work on AI for Quadruped motion (

) . This is the type of level that would fit really good into Unity imo. Something where motions could be added and controlled with the need for hardcoding.

I remember when Biped came out for 3dsMax and then stagnated - It would be great to see a similar revolution in animation tools being developed by/for/with Unity - pioneering work, rather than catch up basics.

We've heard so much on the investment that goes into Unity - which is one reason I'm using it - it would be amazing (from my view) to hear a specific animation team being set up to bring new and advanced tools to Unity's users... with regular updates on the progress etc

OH - obviously VR rigs as well (eg a range of hands/arms/legs/etc from user POV), but hopefully that goes without saying ;-)

LOL - ok I got a bit greedy there - looking forward to the standard player assets/rigs -

 

Unity actually already did some work around AI-based animation controller. At Unite Berlin will be talk about this technology. So i hope this tech will be utilized in new controllers. IK also will be very helpfull addition for character rigs.

 

Last night I spent 9 hours grinding Mad Max - and it suffers from the same as the Batman games: while the fighting has snap-to for every hit, and is almost too easy, normal movement, climbing or jumping is stuff, unresponsive and just poorly executed. The jump-delay is almost a full second, which when running and trying to jump off a ledge onto some other means falling over and over again...

One of the best games when it comes to movement that makes one feel like one is in control...BOTW fits the bill, as does several other games.

 

This is is usually not the controller's fault but the choices of the developer.

 

I would say the choice to animate slowly is controlled by the Controller, and a choice made the developer.

Either way - it is horrible.

 

*narrows eyes*

If you mean the layer of animation and movement put on top of a raycast or rigidbody controller then you'd be right. And now I read Will is actually asking for inspirations from games we've played so he does not mean technical controller.

Otherwise a character controller, like the one included with Unity or Physx, has to be able to do instant movements, and therefore becomes developer choice if it plays badly... (usually badly done root motion, for example, no anim exists for a quick U turn or intercepting the root motion vector with your own).

 

Is there gonna be an early beta release just like 3D GameKit? kinda curious about the new Character Package

 

willgoldstone >> Sounds great!

 

Sounds good, but I don't think anyone here has mentioned Overgrowth or Super Mario 64's character controllers.

Super Mario 64 is a legend, and still feels amazing to play, even with its heavily-outdated graphics. I want to have a character controller that is able to run/jump/climb like that in any world I create -- without physics getting in my way.

A modern take on that SM64 level of responsiveness is Overgrowth's character animation system which is based almost entirely on physics. Its "Character Controller" is entirely physics-driven, with animations being responsive to them -- and it just looks amazing. If you want to rival Super Mario 64 with a modern engine -- this is how you would do it.

This is the key to responsive animation that looks really amazing -- and with Animation C# jobs coming in the pipeline, along with the new Input System, why the heck not?

 

I was going to say MySims or the old Penelope controllers but SM64 is a good example also...
Basically, I would love to be able to move "forward" relative to the direction the camera is looking when I start moving but if I change the camera rotation while I am moving "foward" I don't want my character to change direction. To change direction I will need to stop pressing the direction I was pressing and then press in the new direction I want to go... I.e. being able to look around while running, apart from that, just go wherever I point you at (relative to the camera direction). Having that setup available would be awesome.

What I think would be TRULY spectacular for you guys to do, though, is something similar to the standard assets where you just drag in a camera prefab but instead have a drop down box with preconfigured control types already defined and with buttons setup for keyboard and joypay input etc but editable right there in the inspector if you are not happy with the default.

Just imagine... Add a CharacterController component and it automatically adds a CahracterMovement component also. In that you select from "SuperMario64" or "Super Mario 2D" or "BOTW" etc from a drop down. No need to first go code phyics or do the movement force math via the axis that you first have to go verify has been setup.... You jus add the character controller and you immediately have a working character.

That would absolutely rock!

 

Animation vs Physics (The eternal struggle... OR not.)

Overgrowth and Super Mario 64 both did wonders to make this a non-issue (see my post above, and some details below).

I really hope Unity would provide some support for this style of character controller too. I'm sick of seeing all the "me too" FPS games all over the place. D:



@willgoldstone:


Modularization design of multi-part "Dependent" Systems


I hope it's not too late to offer my feedback -- I know this is a bit different than the BOTW controller (which I also support), but BOTW is best for Adventure-games, and SM64 and Overgrowth are great for Action-games.

Since the two (Action and Adventure) are sometimes combined -- I really don't see why both options/styles cannot be available, perhaps by being modularized (like use the camera from one, and the controls from another, and the animation style for yet another -- or disable, modify, or supplement any individual module anytime you wish, assuming you want to change up the controls / camera style)?

I also think any of these "modules" should contain sub-modules too (for example "Controls" should also be "Camera Controls" and "Character Controls" rather than just "Controls")


An Analysis of Character Controllers (and their use-cases!)

• Super Mario 64's animation style works great for simple character animations with physics-driven transitions (most animations are quick and easy to make -- a simple lerp between keyframe poses.)
• Overgrowth's animation style is really great for those who want to add realism with simple animations and complex physics (acting on both the animations AND the character physics.)
• BOTW is great for adventuring with its two-stick camera system (and less so for jumping around and kicking off of walls, where SM64 was great in this respect with its far-away camera (using C-down to zoom all the way out for hard-to-do-in-3D platforming situations by providing a temporary 2D perspective). That said, BOTW was still highly-responsive nonetheless, and its animation system wasn't terribly far from Overgrowth's (since it included active-ragdoll-physics) aside from a more traditional (heavily-keyframed) animation approach, which costs more time and money because these are harder to produce than Overgrowth's "animation-curve" styled animations, (plus facial and hair animation was included in BOTW).

As you can see, each of these have amazing pros/cons to their character controllers, and each fit a different purpose to the styles of gameplay they'd be used for.

We've got TONS of various FPS, RTS, and MMORPG character controllers -- and they almost ALL feel mechanical and disconnected from the character themselves. Many of these remind me of the "TANK" controls from the early "Resident Evil" games -- except these are "TANK controls" designed for the keyboard and mouse instead... D:

To put the cherry on top -- (forgive me if you liked these games, but...) even Mirror's Edge and Assassin's Creed, initially touted by their developers as "freeing and nimble" somehow still didn't live up to SM64 in that respect -- Why? Because it felt like you were controlling a robot in many ways. This was mostly because either the gameplay (in-game) actions didn't match the camera perspective (Mirror's Edge), or the animations didn't match the pace of the gameplay (Assassin's Creed). In both cases, SM64 (vs Mirror's Edge) wins, and SM64 (vs Assassin's Creed) wins. These games didn't do terrible, but they still had these fundamental flaws in their character controllers which made the whole experience both jarring, and also a major struggle for both the developer AND the player to get a grip on.

And people wonder why some of us still prefer to play "classic games" these days... 9__9

 

I agree with this -- SM64 should be the proper route for this.

The convenience there would be nice, but I suspect it would "feel" too limited right off the bat for most people.


I think the better way of doing something like that is give each part a configurable "module" consisting of various "submodules" (not too much different to how we already configure our "components" on a gameobject), one for "camera" system, one for a "controls" system, etc. -- And this all fits in with the "ECS" approach Unity is moving towards anyway.

I think a "Quick Setup Wizard" might be a good idea to quickly setup these components. This is probably the closest to a "Make my game for me!" button we'll ever see, but if the components are designed well, it could remove a lot of the tedium of setting up a complex character controller -- WITHOUT the problem of TMI (too much information) the old one had.

 

I was thinking along the lines of having one component with configuration options appearing based on which one you selected.

Don't encourage them to make separate modules or else they will go overboard like with the lighting system where you should select the HDR or LDR path then open up a tutorial to guide you through the various other parts you have to to configure to get the lighting working eventually. I took a working project and decided to make use of one of their rendering paths to replace my current lighting (which was just a sun in the scene and the default procedural skybox). After two days of following instructions I was left with a scene that only rendered everything black and in which the directional light didn't make a single difference.

If you encourage them to give us "a default controller setup" which consists out of sub-modules they will take it as a sign to add sub-sub models that require work in advance and after configuration as well as pre and post adding the component to the character and it will turn into a nightmare.

The point here should be to give people a starting point so they can have a working control system "out of the box".It will never please everybody's needs, for sure, but it should be a solid and FAST and EASY start. Imagine that component having an event fire for each button or having virtual functions that you can just extend. Import their starting setup, add your custom script and just extend what they already give you. I would absolutely get behind something like that!

 

Lol! -- I can definitely see where you're coming from with this! In another context, this is exactly the nightmare Mecanim was for me.

I won't go into how terrible Mecanim's design was, but that was largely due to the fact that it's new "Humanoid" (system) was allowed to be a giant monkey-wrench into the whole API by being integrated in the main-design rather than being a separate "system" altogether like it should have been. This is why the ECS approach is going to definitely be a plus, and also why I'd rather it not be a "one-size-fits-all-and-if-it-doesnt-ROLL-YOUR-OWN-and-reinvent-the-wheel-AGAIN" type of solution. I don't know about you, but I'm TIRED of reinventing the wheel all the time -- I just want to make cool games.

I think this could get too close to the current "character controller" design i.e. -- set a few variables, change a few settings, realize none of this fits your idea of how it should work, then go reprogram everything because none of them behave how you need and you need totally different camera/input options than what they provide. A modular system would fix this issue entirely. Sure, Unity tends to suck at modularity -- but their adoption of ECS as standard has given me a bit of hope for them.

As I mentioned above -- sometimes I want Adventure, sometimes I want Action, and sometimes I want both. Sometimes I want a camera that acts like SM64, and sometimes I want one that acts like BOTW -- and sometimes I legitimately want to either edit the existing ones or roll my own entirely -- so having the modules provided (even as a sub-systems) to choose from would make my life lots easier than having a SM64 camera controller that I'd have to modify to make it function like BOTW's camera in an Action/Adventure game.

If they manage to go no more than 1 level deeper than the module itself (i.e. for "control" system, they have "input for character" and "input for camera"), I think it should be workable. Anything more should be a totally separate system.

I'm with you on the extensibility part for sure -- I didn't like the "character controller" idea because it was so rigid and unextensible.

Sure, you could just "drop it in, set some vars, and go" -- but they forgot that -- at some point -- you always have to "go back, remove it, then roll your own solution entirely from the ground up because the "start" they gave you doesn't meet anyone's needs" -- and THAT is the part I'm talking about when I say "I'm tired of having to reinvent the wheel" all the time. So many people have already programmed this base system on so many games before us -- so why do we have to keep doing it everytime we want to make something even remotely similar?

 

Kia ora

As a learner I found the Invector Third Person Controller asset a god sent the only thing I'd like to see it it beable to do is ahve a First/third person toggle like the Elder Scrolls Morrowind, Oblivion and Skyrim controllers the inetrface is great to get a character into a scen while still learning tho it's a little hard for me as a learner to change animations, everything come with male animations and I personaly don't enjoy Femal character walking like the Hulk so having a male Female option or an eayer way to convert/change animations would be great for learners

I guess in simple terms thats an RPG characater set

 

Did anyone mentioned Kinematic Character Controller?

https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131

I use it in my projects, and I think the way it handles collisions and interactions with physics is both modern and flexible, maybe you guys could be interested in it!

 

Do you anticipate the package to be available as part of the 2018.2.0f1 release or during the 2018.2 beta cycle?

 

Looks really good to have for a base physics setup. Basically just drape an animation and some input/movement logic onto it and roll your own "everything else" to move forward. Not as much of a "drop it in and go" solution, but you can't argue that it's not flexible lol.

Seems like the character controller should totally include modular versions of all those levels of configuration. Physics, animation, and input should not only be customizable, but also overrideable.

 

I think that if it englobes more than just movement then it starts to get complicated and things get in your way: I like in it that it doesn't touch anything visual, or anything related to navigation: this allows you to clearly separate logic, although yeah, it's not a full plug and play solution

 

I agree wholeheartedly -- but to those that don't know, the concept of component modularity actually allows it all -- without touching anything else.

I'm not sure how familiar you are with ECS yet, but this is the whole premise of the "component systems" portion of ECS (entity component systems -- a whole two-thirds of the entire concept of ECS that Unity is moving toward.) Each "system component" (yes, an entire system with only one purpose) would be designed in such a way that no system component (directly) touches any other system in any way. The one exception to this rule: output from another system (its output data) can still act as input data to another system. In ECS, this likely will be done by way of attaching it via an entity that has systems that process "layers" of data, or as we've seen, by way of using structs and passing data through/to the C# jobs system. It is this data-driven (rather than function- or object- driven) methodology that makes this system so powerful.

Interdependent systems (refer to the Mecanim/Humanoid API train-wreck) do not do well as "plug and play", nor do they do well for any sort of extensibility. They serve vague purposes that are hard (at best) to deal with in general practice without knowing the entire codebase like the back of your hand -- and even then, it's still possible to forget parts of the codebase, and the near-constant struggle to keep up with your own technology becomes a nightmare the bigger your project scales. This makes it waaay more difficult to bring on an additional programmer to help out, plus, customization is highly project-specific, and takes a lot longer to port over to new projects without requiring (mostly unnecessary) portions of the original "engine" you've built due to the many interdependent systems. Beyond this -- the API (if one exists) is likely also limited to the functionality of the original project, requiring lots of copy/paste and deletion, leading to plenty of potentially bug-riddled code to grace your "new" project.


So the TL;DR is this:

The individual "component" systems I suggested in a previous post in this thread (for camera, input, physics, etc.) all cater to the concept of systems not touching other systems at all. It is still possible to pass-around data via structs between these systems though, and in the end, the "component systems" method still allows for the same functionality one would get with these systems programmed willy-nilly using standard OOP practices alone -- except now with greater flexibility, extensibility, and more in-depth customization and plug-and-play options than we otherwise could ever have dreamed of if these systems were NOT designed as modular component systems.

Just my two-cents.

 

This is the best controller I have ever seen. Link

 

I didn't see this,

There is a certain number of things I always look into character control physics of the highest quality, I'm very picky (action game frame data picky), aside from responsiveness (which mean being able to poll input between frame, have a ready input buffer, and run logic separate from rendering), that is the slip and the hang:

Let say you have a character on top of a simple box with regular 90° angle:

1. The slip, it happen when you get close to the edge, at some point your character slip out the box, ie the character start moving without input due to the shape of collider (generally a capsule or a sphere). This is bad, so bad, yet so many game do it! It's bad for responsiveness and gameplay, it remove control for the player and is a bad surprise overall. There should be a clear feedback when a character is falling and it should be straight down.

2. The hang, it's another instance of the same phenomenon, when you jump to a platform and barely make it, sometimes the character hang a few frame (ambiguous state) on the edge (ie the velocity is killed on collision), yet she's not on the grounded state, and then she slip away away from the edge, it's damning on moving platform.

The reason people has mentioned mario 64 and not galaxy, is that mario galaxy fall into these trap, and while the level design is magic in galaxy, control are overall sloppy. BOTW solve that problem. BOTW does have some slip (geometry has smooth angle) but while slipping you still have a lot of control, it happen over a long range of frame AND it's visually feedback clearly (generally using the feet planting IK, you see you have the feet off and it's dragging the entire center of mass down). Mario 64 also broadcast very clearly and very snappily failure case, grab the won't edge, and without any latency the next frame you are in a totally different pose and a sound that clearly tell the state. Having clear easy hook for them in the controller is a requirement.

Being able to read control state audiovisually is massively important, bad blending kill that. This is a repeated offender in many games, aggravating is the landing and falling, you have the information too late because the blending made the starting too subtle before you can react (and that's when you can react). Having way to jump cut the animation when necessary is massively important to provide visual contrast to read feedback.

I wasted 3 years trying to make a good responsive character controller on unity, like I can do on blitz3D, one reason I haven't yet a game done is because I was left worried with ptsd about unity's ability to just do that (I still do all my control prototype in blitz3d).

One reason is that, aside from poor input handling (blitz3D has great handling of input buffer by default, that work so well I didn't noticed until I knew better), collision and physics are decoupled or badly, for example kinetic collision don't register (multiple) collision on them, that's bad, rigidboy can listen to collision but were expensive and you had to fight against physics introducing noise. I used all the collider shape and type and all sort of raycast, but I couldn't achieve the snappiness I had in blitz3D.

It would be good if the controller had some good buffer by default (to have "coyote time" input for example, or let say the player push a button one or two frame before collision detection it need to register when the collision happen, while having smart cancelling of the buffer to avoid ghost input, blitz handle this so gracefully it's amazing), but that something we can do on our own.

Anyway...

 

Im so excited to hear that you're working with an updated Third Person Controller! Hopefully I'm not too late reading this for any of my ideas to get implemented but here is what I feel could really use an update!

As many people already has said, it would be awesome to get a more "Zelda BOTW" feel as the animations blend so smooth together and how responsive the controllers are.

I personally feel that changing current animations and trying to implement more features in the current package is way to hard, it doesnt feel very modifiable?

One more thing I'd love to see is some more features in movement, the current package is very limited in movement. Many third person games are very fastpaced in movement and especially in combat. (Think dark souls, zelda, horizon zero dawn, lara croft etc). It would be awesome with some dodging animations and maybe more importantly when using lock on enemy is some strafe movement.

Also, it would be great with some animations for jumping over small obstacles, climbing animations and the use of inverse kinematics.

I'd love to learn more about when this package will be released and if you're gonna keep updating it when it's launched. You said before in June for the 2018.2 update but that prediction was in april so I figure you got a bit late. It's awesome that you're taking notes from the community!

To summon up what I'd love to see:

• Easy modifiable controller (Add / remove functionality)
• Combat mechanics (Dodge, strafe, lock on)
• Updated locomotive for jumping over small obstacles
• Climbing animations
• Inverse kinematics for limbs

Looking forward to your response! Stay awesome Unity!

 

Many of you already said that but a BOTW/Naughtydog style are just the best TPC you can find.
Can't wait to get my hands on it.

 

BOTW Climbing System! would be Epic,. currently writing a climbing system but if you are going to do this i may just wait.


Please tell me you will be implementing a climbing system with this or is that to much to ask ?

 

@willgoldstone I forgot to ask do you have any further updates on this regarding time scale, further features (I'm so hoping for climbing system like links) .

 

I wonder if they'll be using C# Animation jobs to accomplish the ragdoll-like nature of the BOTW styled controller.

Any idea on this, @willgoldstone?

 

Tbh I have given up all hope on getting an update from unity on this matter, I have asked on twitter and here and no response.

 

Thank you for your very clear and transparent response Will!
Yes of course it's not your job creating a character controller that fits every need for us game developers! I honestly didnt think you'd consider including climbing animations in the new standard asset, but just added that as a suggestion It's great to hear some updates on this project to know it didnt run out in the sand and that you're listening to our inputs while developing this! I think most of us would be amazed to get to work with this new character with the updated movement and the new "AAA" camera you've talked about in this thread! If im not mistaken, I think I heard you say something about working closely with the people that's working with the new input manager. How has that collaboration worked out? Will the new standard assets work great together with the new inputs?
I figured you've all been busy with the Berlin Keynote (I think I recogniced you on stage!), amazing work with the 2018.2! It would be cool to see some cool gifs of the animations, a little "what to expect" but I understand if you dont want to reveal too much yet!

To summarize, happy to see this project is still alive and cant wait to start implementing this into new projects!!

 

*makes vague whining beggy noises for the low level controller*

 

@willgoldstone

Thanks for your honest reply. That means a lot to help those of us looking forward to this have clearer expectations.


Regarding the "strafing" thing though...

I'm starting to worry that it might be sounding like we're getting just another 3rd person (mouse-look & root-motion animation) shooter controller (like the one that already comes with Standard Assets...) Am I wrong for thinking this? -- Or does this controller still plan to handle "responsive" physics-based movement (with animations taking a back-seat to actual gameplay), similar to the system in BOTW, SM64 (made over a decade ago), or Overgrowth (for a more modern example).


As BOTW's approach lends itself to responsiveness very well (see the GDC on Overgrowth's physics-based character controller and why this is great for responsiveness), I'm wondering if you guys are still going that "physics-based" route.

If it sounds too specific, imagine if the team (instead of defining a controller for a specific gameplay style) just added a nice procedural pose-matching layer right on top of a physics-based character-controller system (like the one from Overgrowth?) instead. That controller was made by just ONE guy -- so imagine if he had an entire team at his disposal? -- That animation/physics portion of the character controller alone would be enough to start nearly any 3rd person project I can think of (since it covers the basics of general physics and its interplay with general animation in a nice, logical, manner that one can easily extend.)

You can now do the kind of animation shown in that video below with C# Animation jobs, so maybe that isn't such a bad direction for this to go?

Like many others here, I too am looking for something more "low-level" and "general-purpose" than a typical 3rd-person "shooter" controller can provide (even if it includes absolutely all the bells and whistles of the genre) because I'd have to customize them down to the barebones level to fit my project's gameplay anyway. So I would just like to know if that whole "general purpose" thing has since gone out the window because of timeframes and deadlines (and now we are just regurgitating the Standard Assets controller) -- or if the "general-purpose" and "low-level" BOTW approach is still underway in some form?

With just the basic movement from BOTW's controller, it isn't but a tiny "hop" (pun intended) to implement all the fancy back-flipping, runs and jumps, leaps and climbs of Overgrowth's or SM64's character controllers. However, with another "3rd person shooter" controller (with root-motion-contrived "physics" and basic linear rotations and translations for "movement" defined by the "mouselook")... Well, that'd be a LOT bigger leap (not to mention a much more distant starting-point to work from) to do the same thing. With the physics-based animation controller, you could just implement mouselook and replace the movement physics on the XZ axis to implement your own linear controls (rather than going the other way around and implementing an entire physics-based animation system) and everything else in the system would still work as intended (such as secondary motions, etc.)


I would personally rather wait an entire YEAR (or two!) for a more "general" solution than to just be handed a system that doesn't actually help me in some way with my specific goals. If I have to reprogram the entire physics and animation system (because it was tailored to fit a "shooter" when I'm not making anything remotely like a shooter), then I'm clearly not able to use the system you've provided to start working from. Unfortunately this clear inflexibility was my problem with the original controller from Standard Assets -- and I'm worried history is just going to repeat itself with this...

 

@willgoldstone thanks for your response, i know it was a long shot asking for a climbing system, but if you don't ask you wont get .

Actually looking forward to this new asset.