Official New Standard Asset Characters - Third Person

Since we are going to have a BOTW-like controller, is there an easy api to implement dynamic physics behavior?
(like standing/climbing on moving platform/floating wood trunk/collider, hit by big rock etc..)

see reference below

 

I was kind of hoping you'd be able to switch from 1st to 3rd person on the fly, seems like more games are letting you do that these days. Could a crouch be added? Seems like pretty standard behaviour.

 

I think concrete features are not very important for a general purpose CharacterController, crouch is just one line code for a good designed package like Kinematic Character Controller

Code (CSharp):

1. Motor.SetCapsuleDimensions(0.5f, 1f, 0.5f);

Swtich 1st and 3rd person would be a cinematic related thing i assume

 

It's might seems nitpicky, but does the team as an experience in 3d platformer third person navigation games?
I ask because all commercial game made by experienced team don't update the vertical offset of the camera when the character jump or is airbone (generally with a very generous dead zone before adjusting it or literally none) and I notice in the quick video that the camera jump with the character. You can look at game dating back to mario 64 for evidence for this, it's an essential feature of basic third person controller. That's another grip I have with indie platformer, most aren't aware of that, it make for subtly uncomfortable camera.

I also notice that the character don't seem to have the hang when jumping over the fence that's great!

 

How tightly coupled is the CM setup for the standard controller? We'd probably either completely redo the camera settings, or just dump CM completely, so preferably that won't require any script changes to the controller.

 

I think many of us here would like to contribute, i hope this asset is not only for "prototyping purpose" but also can be a foundation which we can build features on top of. thx for the hard work, looking forward!

 

Thanks Will. Yeah I guess camera switching isn't actually that common, only recent ones I can think of are Red Dead 2, Fallout 76, and PUBG.

 

Yeah "moving-tilting platform hooks" support should be at least a basic generic feature because it's not that trivial to implement for the basic user. Moving platform is one big stumble I had for a long time to have gameplay prototype running. It's super easy to get lost in the math of matrix multiplication, reference frame, and fall back on physic friction that mess things up dearly. Everything that is basic collision and some basic camera targeting is fundamental. It doesn't need to be specific, but it need to allow easy implementation and extension, also it need no assumption of verticality and gravity.

Although things like animation and all while important for the feel of a game are secondary for a generic asset.

 

Please, something like this:

Auto climb, auto jump, ladders, swimming ect.

 

Something that would be a good idea if not already implemented, would be an adjustable ik setup. Something like a foot ik that automatically works without doing anything, but can be played with.

 

If the controller can't execute a Lutz and a triple Rittberger loop jump I will uninstall unity because it is obviously nowhere near ready.

 

It's a prototype controller, I doubt it can have specific state like climbing, swimming etc ... moving, collision and basic camera should be the bare minimum. Everything else need specific animation and specific tag on environement, ie that's making a game not a controller, what's needed is not more interactions, but a good base to hook these actions.

Also it's not an animation system, that's mecanim.

 

Just bought this one:
https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131

It's the smoothest, most responsive third person character framework I've ever come across.

 

Will the new controller have physics? So run and jump will maintain speed and direction (momentum) till "is grounded" . With possibility to disable if needed. If I jump, it should not be possible to change direction mid air. (unless that is what you programmed to happen).

 

The previous version of the standard assets character controller had this behavior by default with an option to toggle air control. I don't see why they wouldn't do the same thing with the new CC.

 

@leftshoe18 . If that is so, then great. I am still learning Unity, so I have not found everything yet. But non the less, I am eager to see what is in the new controller.

 

I hope the new one isn't as sloppy as the one we got to work with for years on end.

The default third person character cancels out forward movement upon jump against a float value height edge.
Cannot properly stay snapped onto slopes or stairs. And lastly, the gravity/animator glitches out sometimes when going off ledges and colliding against walls. To be fair, I think it's really bad and not even close to being game ready at all. We want something low key, that works flawlessly and something that is easy to work with and expand on.

@neoshaman
You have no clue what you're talking about. Expanding upon a controller isn't 'making a game'. Besides, we aren't all programmers that are able to go from something as half-assed as the default to something above mediocre, you know. It's a matter of adding in functionality. Reports that can be called from to have specific abilities. Reports like ledge detection.
With these kind of things build in, that'd be absolutely great.

 

You actually do know that these weren't and aren't intended to be game-ready, right? They never were. These are intended to be quick prototyping tools. You always should develop your own controller.

 

I'm not a programmer either and I have to wrestle with controller making, too, I spend and failed 3 years trying to make one, so I already have that bitter experience. SO I kinda know what I'm talking about since you allude to it . But you follow up exactly with the nuance I was pointing at, they shouldn't build the ability, they should give the "report" and deal with the collision that allow to hooks the ability, that's the difference between a controller and a specific implementation.

Walking/basic navigation is the bare minimum as adhoc supplement, a true controller wouldn't even have that animation to begin with, and be just a collider with some raycast like the old character controller. But they need to draw a line in the sand because it will be exponential production time with each addition and you will never see the controller coming out if they go the path of adding any ability while remaining a small team. There is dedicate asset on the store and they still struggle to meet all demand, I have been following them and see the hassle of meeting specific requirement and be generic enough.

Take a thing like edge grabbing, there is multiple way to do it on a game by game basis, and some game even have multiple contextual implementation. It's a non trivial, highly specific and highly contextual action. And the controller will feel clunky if they do down one way and not another and it's not your desired way. Though they can still provide example sample further down the line with particular implementation of edge grabbing, combat, swimming, flying, which are complete problem of their own to which many solution exist. Or an entire sample project that mimick one of teh famous example like botw or mario 64.

 

Hey, I was just about to nag you about access so I could try it in a game jam over the weekend. Nice.

And I mean, really, we don't need the camera in order to start testing it. A big, fat "camera's not done yo" message when you post it would be plenty.

 

Thanks Will, reading that back it looks as if I was being sarcastic, but those were genuinely the only 3 I could think of

 

* Are the third person and first person controllers based on OCC or the Physics Character Controller?
* If the latter, does Physx 3.4 bring in the definable Character Controller Up vector or is it still axis constrained?
* If its based on OCC, does Open CC mean we can see the full source and adapt to context or are we limited to what you come up with?

 

We're waiting...

 

I don't know if this is the right place to provide feedback on the Standard Asset Characters, but here we go.

First of all, it could be useful to have a version number in a comment in the top of the scripts. I started using Unity October 22 2018, and soon after installed whatever version of the Standard Assets there was at a time. I'm not sure though if this is the most current version, or the version other devs use. Maybe such version number already exist for the asset as a whole, I don't know.

Regarding the scripts it would help to understand if things were better named, or otherwise explained in a code comment. As an example, what is the difference between m_Jump and m_Jumping? After some reading through the code (and some months of C# and Unity experience) it appears m_Jump is true from the player presses the jump key, until the first fixed update when the characters takes off, while jumping is true for as long the player is in the air. It would be nice though to easier see this, and not have to dissect the code to understand it, especially when you aren't used to the language or the engine yet. If my conclusion is correct, perhaps one variable could be called m_AboutToJump.

In general I think it would be less distracting and easier to understand if some extra attention was put into the polishing of the scripts, e.g. make sure comments are actual sentences starting with a capital letter and ending with some sort of punctuation. There are other things like inconsistent double line breaks that just makes the code feel noisy and makes it harder to read.

Since this is examples I think it's extra important to show best practices, and increasing readability would definitely help new users.

 

@willgoldstone can you share us some updates ?

 

Thanks!

From a first quick look the new asset seems a lot better! As an example he variable name OnJumpPressed makes it so much easier to understand what the variable represent and how the code functions.

 

First impressions from the repo beta:

• Cameras are obviously not ready, so not much to comment on those yet. I've had some of my own success with a first-person Cinemachine camera before so I expect those will improve quite a bit.
• I really like the base OpenCharacterController + CapsuleBrain. I plan to dig further into that setup. Curves for Jump Gravity Scale, etc.. seem particularly nice, (though I need more practice with animation curves because I find them time-consuming and easy to mess up a previously nice setting).
• The ThirdPersonBrain seems to work very fluidly, but looking I don't see any direct speed control, so I'm guessing it's root motion directed? If that's the case, that makes for the same frustrating experience from most root motion controllers, where matching speed between characters is so difficult. I would really like to see a root motion controller scale automatically to match a ground speed for good consistency. Unless I'm mistaken and that's in there (and I missed it?) I just see the multiplier (RootMotionScale).
  Summing that up: I'd prefer root motion to be matching, not the driver.

Overall this seems really promising. I can see the hesitations on releasing earlier, because there's clearly a lot of work in this and yet it still needs that extra mile. Character controllers are in a sad state on the asset store right now too, most of them are so crufty and aren't updated well. Unity needs strong default controllers.

 

here is some of points i feel important,

• can the character allow for hot-swappable configuration? swap model/animations/walking speed easily?
• can we use a very simple animation state machine? meaning is it does not need all the state as long as parameters are same, that would allow to use it with any character from store if they do not have all animations.
• generic character support for like animals?
• can we swap input ? like have touch control then swapping an other character swap to our own Ai iinput?

 

A tip for who are using 2018.2: you'd better downgrade InputSystem to `0.0.14-preview`

See also https://github.com/Unity-Technologies/InputSystem/issues/348

 

There's some issues with the namespaces for the Editor scripts. Shouldn't they be moved into StandardAssets.Characters.Editor instead?

 

After play with SAC a while, i found some buggy(or not?) cases using CapsuleBrain (i use kcc's playground as test base):

1. I can't jump beside some object
   
   
   expected:
   
2. I can't snap on ground when step offset is large
   
   expected:
   

 

..go on

3. when move against a wall, should slow down character (by the angle):

expected


when i import ThirdPersonBrain in, even more bugs:

1. jittering

2. can not step over a cylinder

3. jittering

 

I don't think this is a bug, as a majority of FPS games got the same behavior (same speed even when colliding against a wall), it would be a nightmare if the characters would slow down in thight corridors.

Even thought it should be an option as some games require a slow down on walls.

 

i don't think you said is right, I checked overwatch & doom & half life also tps game like zelda, all these games behaves like the latter one.
maybe i express my point the wrong way, i mean this:

the SAC's actual speed is constantly high when you move towards a wall. if you tried yourself, you must know what i mean

 

Ah yes, I understand, in this case, I could propose this:
There should be an option where you can define a max angle difference (between the move direction and world input direction).
If the angle is smaller than the option, it should go at constant speed, if it's bigger, it should slow down.

So that way, everyone will be able to choose how they want their gameplay when "sliding" on a wall (constant speed everytime? constant speed only if the input direction is close to the movement direction? or slow down no matter what?).

 

actually i never see any game with constant speed everytime, that makes me feel so slippy

 

@filod @Guerro323 I think this is a game specific detail. You will develop it in your final product. I don't think this is important in a prototype which this asset is for.

 

I'm with guerro, I actually need the constant speed for speed platformer, also I think starlink implement similar stuff but toggle to constant speed when going fast and have the angle slow down on small speed.

 

I think it's quite basic functionality to project the movement vector to whatever plane you are limited by. The actual speed should be the desired speed multiplied with the dot product between the desired move vector and actual move vector. If the actual speed is the same as the desired speed, even when the actual move vector differs from the desired move vector, you'd get super weird results when you walk [almost] straight onto an obstacle. You would seemingly randomly go, in full speed, to either side, rather than barely moving sideways as you push towards the obstacle.

 

Just to make it clear, we are not talking about some sort of friction against the wall here, but using a projected input vector to stay true to the user input, rather than directly copying the length of the input vector and apply it in another direction.

 

Ok I just downloaded these Character Controllers from the Repository and tried them on 2018.3 and here's my feedback:

SimpleMovementController: I don't know if this is what you were going for, but even if I just barely nudge the mouse, the camera swings around nearly 90 degrees and it honestly makes me nauseous (and I'm not one prone to motion sickness). Do not like it at all. Otherwise it would probably be fine. but I expect more control over the camera than I'm getting.

SimpleMovementEffect: Pretty nice overall. The camera is better on this one (though still a bit touchy) Even though I'm getting like 400-500 fps during the demo, the view *seems* 'stuttery' or low framerate while the camera is rotating and the character is moving. Not sure if this is due to Cinemachine fighting me or what.

SimpleNavMeshInputController: NIce demo, I just find it confusing and un-intuitive that to move the camera left you move the mouse down, and to move the camera right, you move the mouse Up. Wouldn't Left, Right make more sense? or why can you even move the camera at all? Shouldn't it stay centered on the character? I'm not sure what that's about.

If I was trying unity for the first time this would probably be what I try first. And the (pardon the term) goofy controls would put me off. I hope this can be improved.

 

A ton of red compiler errors in 2018.2.5f1 right now. Fresh project. Errors regarding Collaboration.ConnectInto and CollabHistory being inaccessible due to protection level. Other errors about InputSettingsProvider, XRSettings, PackageManager. It's a long list of 80 or so errors. Anything I should know about using this in 2018.2?

 

Had the same problem, I managed to fix it. I Changed in the manifest.json for the packages, removed some packages and changed versions. Here's my manifest:

Code (manifest.json):

1.  
2. {
3.   "dependencies": {
4.     "com.unity.cinemachine": "2.2.8",
5.     "com.unity.inputsystem": "0.0.10-preview",
6.     "com.unity.package-manager-ui": "1.9.11",
7.     "com.unity.purchasing": "2.0.3",
8.     "com.unity.textmeshpro": "1.2.4",
9.     "com.unity.probuilder": "3.0.9",
10.     "com.unity.progrids": "3.0.3-preview.0",
11.     "com.unity.modules.ai": "1.0.0",
12.     "com.unity.modules.animation": "1.0.0",
13.     "com.unity.modules.assetbundle": "1.0.0",
14.     "com.unity.modules.audio": "1.0.0",
15.     "com.unity.modules.cloth": "1.0.0",
16.     "com.unity.modules.director": "1.0.0",
17.     "com.unity.modules.imageconversion": "1.0.0",
18.     "com.unity.modules.imgui": "1.0.0",
19.     "com.unity.modules.jsonserialize": "1.0.0",
20.     "com.unity.modules.particlesystem": "1.0.0",
21.     "com.unity.modules.physics": "1.0.0",
22.     "com.unity.modules.physics2d": "1.0.0",
23.     "com.unity.modules.screencapture": "1.0.0",
24.     "com.unity.modules.terrain": "1.0.0",
25.     "com.unity.modules.terrainphysics": "1.0.0",
26.     "com.unity.modules.tilemap": "1.0.0",
27.     "com.unity.modules.ui": "1.0.0",
28.     "com.unity.modules.uielements": "1.0.0",
29.     "com.unity.modules.umbra": "1.0.0",
30.     "com.unity.modules.unityanalytics": "1.0.0",
31.     "com.unity.modules.unitywebrequest": "1.0.0",
32.     "com.unity.modules.unitywebrequestassetbundle": "1.0.0",
33.     "com.unity.modules.unitywebrequestaudio": "1.0.0",
34.     "com.unity.modules.unitywebrequesttexture": "1.0.0",
35.     "com.unity.modules.unitywebrequestwww": "1.0.0",
36.     "com.unity.modules.vehicles": "1.0.0",
37.     "com.unity.modules.video": "1.0.0",
38.     "com.unity.modules.vr": "1.0.0",
39.     "com.unity.modules.wind": "1.0.0",
40.     "com.unity.modules.xr": "1.0.0"
41.   },
42.   "registry": "http://staging-packages.unity.com"
43. }
44.  
45.  

It seemed like there where also a bug in the input system for my unity version (2018.2.9) so I had to change a file there in:
AppData\Local\Unity\cache\packages\staging-packages.unity.com\com.unity.inputsystem@0.0.10-preview\InputSystem\Utilities\Unity2018_2_Compatibility.cs (had to remove the write protected flag first)

where I removed the

 #if UNITY_2018_2

and

#endif

(seems like 2018.2.9 is not UNITY_2018_2?)

Finally I had to delete all .dll files in the Library/ScriptAssemblies, restart Unity and reopen the project and now it works (with some missing scripts but at least the character can be played with my gamepad)