Because these 2 character controllers are “official from Unity”, I think that they could also be a useful learning experience for a beginner like me
So I started to study and compare the “ThirdPersonController.cs” and “FirstPersonController.cs” scripts.
I think that most big differences are:
a) the presence of Animator component in Third Person Controller and relative code to manage its animations
b) the “CameraRotation” method
c) in the “Move” method, in line with “_controller.Move”, it’s passed a different input
I don’t fully understand the differences in b and c so I’ll need to study the code more but if someone could explain me the logic behind them, I’ll really appreciate it
I already have some other issue/questions that I’d like someone could explain to me:
In “FirstPersonController.cs” script, the private field “_mainCamera” is set in “Awake” but not used nowhere else: why?
why all configuration properties are “public” instead of “private” with a [SerializeField] attribute? Maybe to be accessible from other scripts (for example a damage dealing script that decrease character speed when wounded?)
public filed “GroundedRadius”: its tooltip says “Should match the radius of the CharacterController”: why not use that radius directly?
In “FirstPersonController.cs” script, the comment “Note: animations are called via the controller for both the character and capsule using animator null checks”: why is it there if the animator is not used?
what does “#if ENABLE_INPUT_SYSTEM && STARTER_ASSETS_PACKAGES_CHECKED” at the start of both files mean? And why is it necessary?
When using the gamepad on the PC the look up and down works great. Once I build it to an Android Samsung tablet and run it if I just barley press the up or down right stick the camera is moved all the way up to the 90 view clamp instead of only going up a little. Please help!
If I understand your question correctly, you’re asking how the PlayerInput is hooked up to the StarterAssetsInputs?
On PlayerInput there’s a field to select the behavior, whether it’s C# events, Unity Events, Send Messages or Broadcast Messages. For simplicity we chose the Send Messages option, which uses the Send Message function to call OnMove, OnLook, OnJump, OnSprint, etc.
The approaches you’re describing would the other options (C# events or Unity Events). They’re all valid approaches, so choosing one depends on designing a solution for your particular situation and of course taste.
This is due to the damping values on the CinemachineVirtualCamera on the PlayerFollowCamera. By default the Z damping is set to 0.3, but you could turn that down (likely all the way to 0).
If it helps, you could make it an embedded package for now.
Copy the StarterAssets folder to your Packages folder.
Rename the folder to (something like) com.unity.starterassets.
Add a package.json file. I’m attaching an extremely basic one, if you want to use the attached one you must remove the .txt extension so the file becomes “package.json” rather than “package.json.txt”.
And it’ll be under Packages instead of Assets. If you want to pull any updates you’ll have to overwrite the folder with the newer version, but if you’re ok with that then it’s a quick solution.
Can you explain the situation in a bit more detail? Am I right in guessing that you’re trying to make an over-the-shoulder camera and have the character look in the direction the camera is pointing?
If you need the target to be part of the player prefab, but it works as part of the main camera, can you spawn it with the player prefab and reparent it after spawn? Or have a script that manually moves it based on the camera position every frame?
That sounds like a mistake. It could probably be removed, but I haven’t checked it.
For simplicity. Like you mentioned this allows outside scripts to change the values of these fields. Alternatively, they could be private fields with public properties to access them, but that’s a bit less beginner friendly.
It could, but having a field gives users the flexibility to use the asset in ways we might not have predicted.
That sounds like a mistake as well. I believe that comment is out of date.
These prevent the file from compiling unless those scripting defines (ENABLE_INPUT_SYSTEM and STARTER_ASSETS_PACKAGES_CHECKED) are set. If they aren’t set then the files will fail to compile because they rely on references to packages that may not be installed. Then, if they fail to compile, then we can’t run the script that installs the packages .
Now you can use the mouse scrolling up and down to switch between the third person and the first person view. If you are interested, you can watch the whole list. Cheers!
(3rd person scripts) What’s the variable analogMovement for? / do? Making it either true or false does nothing to change how the character is controlled in run time?
When the analog movement option is checked, the character animation moves according to the float values of your game controller. For example, if you press the stick button very slowly, then the character movement animation will be slow.
Why the “Speed” float value works weirdly? When the movement stops, the speed value doesn’t go 0, but instead, it keeps going down to frightening numbers. It is especially troublesome in multiplayer sync because the animation looks glitchy when the animation stops.
Ah, so it looks like its an issue with the stick-to-camera sensitivity for that gamepad. Admittedly, I have never tried that gamepad plugged into an Android device let alone been able to test with it.
It might be a case of having to extend the Camera Look script to have platform-specific stick magnitude processing when running on Android.
How is the Movement Joystick input? Does it also have the same behaviour?
The ability to climb using the Animation Rigging package and some examples for modular animations using modular-rigigng, such as look-at targets or different kinds of runs would be highly useful as a starter package (since all of these conventions were present all the way back to Mario 64) and would make this (official, Unity-supported) package, to me, actually useful as a long-term, easy-to-use, asset when starting up new projects. When it is ready, DOTS Animation would be useful here too – since this is the kind of thing that is useful as both an example – and as a starter asset.
Eventually both DOTS Visual Scripting and Unity Visual Scripting support would be handy for many designers as well, who are looking to quickly prototype without having to fool with that much code. Moving platform support would be great also (if it isn’t already available) because, you know, some basic climbing behavior for platformers. That climbing bit should of course be able to be disabled or removed if necessary (and show how to “extend” the package via modules that can be authored visually), and since it would be more of a modular “addon” thanks to Animation Rigging, some of that special coding it might need to handle the transform shifts when climbing is enabled should be easy to spot and also easy to modify (in case a character has multiple kinds of climbing animations, for example).
Outside of these (sorely missing) elements, I think you’ve got a good start so far.
