New Standard Asset Characters - Third Person

Unity Engine
21

Hi all

Some updates for you - we’re working away on this project with a dedicated development team and a broad review board of developers and Unity vets. Our third milestone arrives this week so things are moving along well.

Here’s an overview of what we aim to deliver and how it’s being put together -

Package 1 - Characters

  • First and Third Person character package. This package uses a rewritten new C# equivalent of the PhysX CharacterController which frankly is super old (read: Quake2 references in the code old) and also not versatile enough. We are aiming to replicate the basics of it’s functionality and then make it extensible and as useful as possible for you all. Animation wise we did a new mocap shoot and are building a detailed blend tree with an emphasis on responsiveness in the controller to match what a lot of you are asking for here - leaning more toward a Zelda BOTW feel than a Mad Max sluggish feel.
  • Cinemachine rigs for the above, we’re working with our Cinemachine developers to make sure we show best practice and provide you with an out of the box AAA game camera that’s highly adaptable to a variety of scenarios and play styles
  • New Input - working with our input devs we’ll be shipping with the Preview package of the New input system, which will act as a way to demonstrate usage for you as an added bonus. We’ll also include a Touch input rig for those of you working on mobile.

Package 2 - Prototyping

  • Proto Environment - This arena is a prototyping playground designed to help you test out characters and mechanics. Built in Probuilder the aim here is to give you space to test out the characters in the first package and try building out ideas of your own.

That’s all for now, I will keep you updated as often as possible. Any questions keep them coming!

Cheers

Will

9 Likes
22

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

23

willgoldstone >> Sounds great!

24

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?

1 Like
25

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!

2 Likes
26

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

2 Likes
27

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.

28

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!

29

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?

2 Likes
30

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

31

Did anyone mentioned Kinematic Character Controller?

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!

32

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

33

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.

34

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

1 Like
35

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.

2 Likes
36

This is the best controller I have ever seen. Link

8 Likes
37

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…

3 Likes
38

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!

39

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.

40

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 ?