Official Say hello to the new Starter Asset packages

it happens in built too. I think it might be the camera rotation multiple by time.deltaTime. I havent check if that is causing the problem yet. If put a gun or just a cube in place holder of a gun, u can see its trying to catch up with the camera.

 

Please believe me -- I appreciate the consideration on this part.

But, if you really mean what you're saying, then I fundamentally disagree on this part (in bold).

As experienced programmers, Unity devs automatically feel like they can easily "add" anything.
On the other hand, for beginner programmers (and non-technical people such as technical artists who must dabble in code) -- the story is MUCH different. We rarely want to code. We just HAVE to code -- because Unity offers us no other choice.

Many beginners don't even know where to look in the (heavily broken-up) API and packages in Unity (much less the required assemblies, callbacks, etc.) for the code they need to "add" -- and for many, it is MUCH easier to simply modify something existing (or strip away things that have a clearly-defined, centralized, location).

Fine, I won't argue about what's approachable.
But I will argue that you would be wrong -- and you would lose that bet.

While I am an "advanced" user, I am only "advanced" on the technical side because I have HAD to learn that side in order to accomplish anything in Unity. I don't know who is churning the rumor-mill there at Unity, but they've got it all wrong.

Have you never wondered why there are so many programmers in Unity (and not as many artists/designers?) This kind of thinking (i.e. it is easier to "add" than to take away) is why. It most certainly is NOT easier to "add" than to "remove" code (at least for non-Unity team programmers) -- especially when your API is all over the place and even how you are supposed to code certain things changes all the time, and with every version.
As an artist/designer, I happen to enjoy thinking more laterally by default. I refuse to force myself to internalize "thinking like a programmer" because that would require me looking externally for every answer, without any real clue as to what I want -- and then (blindly) experimenting and failing constantly -- wasting a lot of time -- even though I already have a clear and solid approach to the basic structure of the design I'm after that should work already. This is wasting of time digging through disparate API and poor documentation is not "fun" for me as an artist/designer. I am not privy to the info you as a Unity developer have. So it is MUCH slower for me to "add". In place of that knowledge, I want to iterate and add OR remove -- as needed. And the "remove" part is simple -- just keep it containerized and modular (and easy to access and/or discover) -- rather than not having basic functionality to begin with.

After all, if you really did understand what an artist/designer needs, you would also know that "adding" doesn't always 'improve' a thing. Usually it is what you remove that makes things "better" in the long run. However, you have to actually have something there to "remove" in the first place. :/

I appreciate your perspective, but I must say this --
Maybe _your_ experience clouds your judgement on these issues, but my experience actually benefits mine.
If you are looking at someone who has become an "expert" at being a 'beginner' -- look no further than yours truly.

I am an artist/designer who just so happens to be a researcher who researches the most efficient artist/designer tools and workflows available for beginners (and small-to-large inexperienced teams). Said tools and workflows often involve a non-technical approach to a solution of very "technically-minded" problem, meaning I am extremely used to dealing with the whole "programmer bias" thing you're referring to here. However, as an artist/designer who actually uses these tools/workflows -- I understand that there are other (better) ways to seek the answers you need from users than to poll random users (whose experience and mindset varies wildly) on (programmer-designed) tools that are only slightly better in one area -- while being immensely worse in other areas -- for those same users. It is, after all, impossible to "test" every single element without the context of many other, unexpected, elements being thrown at the design (elements, such as proceduralism) that the programmers/designers didn't fully anticipate (or provide solutions for).

Mecanim comes to mind here.

Remember how "great" the state-based approach was to author animations? -- Remember how cool it was to be able to 'blend' walks in various different directions with a nice UI? -- Remember how NOT procedural it was? -- Remember how terrible its UX (and various APIs) were to make it do anything it wasn't actually designed for?

No? -- Well, I do -- And it sucked -- and that's why Animation Rigging exists now.
Yet people like me (as in artists/designers who must code to fulfill their design vision) are STILL trying to figure out that damn muscle/skeleton API to this day -- because it's "default" -- and is naturally thought of as the 'foundation' of what Unity's version of "animation" is supposed to be. I still have to correct people who are after procedural animation and point them to Animation Rigging -- all because of a broken-up, tool design that has no (and can't have a) very clear and centralized structure (like Mecanim tried to be). This "if we don't anticipate it, don't add it" mindset trickles down to tools like these Starter Assets. Again, this is a design problem -- not a programming one.

Programmers really shouldn't be solving these kinds of problems. This is because "form-follows-function" is typically an 'artist' concept and clearly not a very well-understood aspect of Unity's in-house programmer 'design' artistry, since "function" is not well-enough understood by those at Unity who must take liberties on said 'form' (such as deciding which things should and should not be included). This also applies to which things should be centralized (versus tucked away in the API) -- And thanks to your statements, this lack of understanding is both clear and evident (and quite provable) because (you said it yourself) that you must rely on user testing (users of wildly varying experience levels and ideas of game development processes, patterns, and methodologies) to finally 'justify' your own in-house "designs" to yourself -- when you don't even know what you're truly "designing" to begin with. Unity's version of "user-testing" would be like if Picasso asked his friends/family whether his paintings were "good" or "bad" before he decided to ultimately still paint in the strange style he had already chosen -- in order to "justify" it. How much sense does that make?? -- If those particular friends/family are not people who sympathize with his viewpoint (or if these particular people are not people who even understand it), that "justification" process quickly becomes baseless. But it was baseless to begin with, since Picasso chose to go his own way anyway!
Unity does this all the time!!! -- People often know what they like -- but without the (correct) type of experience (and knowhow to be thinking globally), people's opinions, ideas, feelings, mindsets, methodologies, and priorities are so different that mindlessly listening to them can easily wreck your design (without you even realizing it). This is exactly why users without objective reasoning cannot be relied upon, since design clearly follows a more globalized approach to a solution that helps everybody -- not just that one person (or their way of thinking) that the Unity programmers think has a good idea. This objective thinking, from multiple users' perspectives, that takes _everyone_ into account, is exactly what I've offered you with my suggestion for something more centralized and inclusive (and also "humane") -- and your reductionist ideals are dismissing it, without a clear rationale as to why my suggestions are the wrong approach.



I'm not here to stir the pot, but anyone who agrees with me should speak up -- otherwise, we all will have to just deal with this mindset in the future (and the shape of the tooling and designs you keep getting will remain the same -- that is, unpredictable and hard-to-use, because of the reductionist philosophy.)

In life, things are not always so cut-and-dry.
True simplicity is always composed of some inherent or implied complexity under-the-hood.
In this case, "complexity" just means better design and organization (and discoverability) of something's functionality (for the purposes of "addition" or "removal" -- at least in this case of the definition of "functionality").

 

Sorry -- I didn't mean to unload on you like that. What I mentioned above is just a perspective that bothers me because it's so prevalent and everybody seems to act like there is no other way to look at hard problems. I'm very passionate about what I do, and so I can be a bit stubborn about making it known when I feel people are following a limited mindset.

I understand that not everyone wants to change their thinking. However, I definitely feel people should listen to one another more often regardless -- especially to those who are passionate about something (and don't have an agenda to push). There is always a lot to learn, even if one does not ever fully adopt the other person's perspective.

 

Found an issue and fix for

ThirdPersonController.cs

- propably just an oversight.
Currently when using Analog Movement, using a analog stick for movement, the character will slide, keep on moving too fast, when slowly decelerating via the stick.

Code (CSharp):

1. // ThirdPersonController.cs
2. // → regarding the else statement, current implementation and easy fix
3. // --------------------------------------------------------------------------------
4.  
5. // Line 186-199 currently in v1.0:
6.             // accelerate or decelerate to target speed
7.             if (currentHorizontalSpeed < targetSpeed - speedOffset || currentHorizontalSpeed > targetSpeed + speedOffset)
8.             {
9.                 // creates curved result rather than a linear one giving a more organic speed change
10.                 // note T in Lerp is clamped, so we don't need to clamp our speed
11.                 _speed = Mathf.Lerp(currentHorizontalSpeed, targetSpeed * inputMagnitude, Time.deltaTime * SpeedChangeRate);
12.  
13.                 // round speed to 3 decimal places
14.                 _speed = Mathf.Round(_speed * 1000f) / 1000f;
15.             }
16.             else
17.             {
18.                 _speed = targetSpeed;
19.             }
20.  
21. // --------------------------------------------------------------------------------
22. // SHOULD BE:
23.             // ...same as above
24.             else
25.             {
26.                 _speed = targetSpeed * inputMagnitude; // FIX
27.                 _speed = Mathf.Round(_speed * 1000f) / 1000f; // round now as well
28.             }

 

I have a doubt, I've never used the New Input System, and I don't know how it works at all. I want to add a new button in mobile devices UI (UI_Canvas_StarterAssetsInputs_Joysticks), I added a new button and functions in scripts:

• Assets/StarterAssets/InputSystem/StarterAssetsInputs.cs
• Assets/StarterAssets/Mobile/Scripts/CanvasInputs/UICanvasControllerInput.cs

And assigned the "Output -> Button State Output Event" in my new button under "UI Virtual Button (Script)"

Finally I don't know how to bind my new UI button in the New Input System as well:

Why and where is the config to say, for example for jump: "Button South [Gamepad]" I can't find the relation between.


Thank you a lot, this asset is awesome!

 

Okay! So the binding is in case there is a controller connected, I thought it was related to the virtual button somehow in the "Input Actions". I just needed to add in Assets/StarterAssets/ThirdPersonController/Scripts/ThirdPersonController.cs the condition input.fire:

Code (CSharp):

1.  
2. private void Fire()
3. {
4.     if (_input.fire)
5.     {
6.         // update animator if using character
7.         if (_hasAnimator)
8.         {
9.             _animator.SetTrigger(_animIDFire);
10.             _input.fire = false;
11.         }
12.     }
13. }
14.  
15.  

It works perfectly!

Thank you!

 

Hi,

Firstly, thank you for this, it came at just the right time in starting a new project for me.

I'm a relative novice with unity, but have some coding experience. I'm finding the new input system challenging on this CC, becasue if you look up Unity tutorials for the new input system, they don't use the framework you have used.
Regardless after an hour of watching tutorials that don't match what you have done, and looking through your code, I have worked out how to add Inputs and call those Inputs in code. Is there good documentation to work out this system in your CC release? Again from a novices point of view it's a barrier to get into, because most guides online reference the old input system, or recommend using the new input system in a different way.

One issue I do have is using your method I have no idea how to make an action happen on press or release. I tried just selecting this in the Input mapper - but that didn't work. I tried setting the input action to false in code and that worked for on button press.

Thanks again.

 

Is there a way to give the character a little farther jumping distance forward? Right now it seems like he barely moves during a run and jump.

 

it sticks both there(joystick) and there (zones).
I asked the same question before).

 

Hello! I have a new question. I'm trying to remove "SprintButton" and do run the character with the joystick instead. The movement must be depending on the magnitude of the joysticks drag. For example, from start to middle the player must "walk" and from middle to end, the player must "run". Would it be easy do this change?

Thanks for the support!

 

So after doing some tests with basic Probuilder cubes as a measuring stick, the character was able to do a standing vertical jump about 0.27m farther than a standing forward jump.

Using Unity 20.3.11

 

Inside the Starter Asset scene, i jump straight up from flat ground to the top of the cube (space then w). Then, i do i standing foward jump ( space then w, also reversed, w then space).

I will test the cube to cube tonight.

 

Yeah! It works like a charm!

Thank you so much! I hope that my game sees the light in Google Play

 

I was doing a flat jump from the ground to determine the jump height. And from flat ground with a thin cube in front of character to determine jump distance.

After seeing your post, I retried both jumps. From flat ground straight up, and then from 1m sized cubes with 1m of space in-between each cube.

Average forward jump distance going from cube to cube was around 1.56m
Height jump, a little harder to determine exact height, appears to be in that same range.

But, standing forward jump on a 3m long cube, jump distance was pretty steady at 1.80m. I ran the jump tests 10 times each.

Why would the cube to cube jump distance be shorter than just jumping forward from flat ground to flat ground?

 

I found an issue with the jumping in the first person asset. If you take the controller into the yellow tunnel and jump, the character will be stuck midair until they leave the tunnel where they will be forced to complete the jump.

Additionally, It would be nice to have some sort of ceiling check because even when the controller doesn't get stuck in a jump, the controller 'sticks' to the ceiling until the jump force runs out.

Relating to the stutter issue, I think its two simultaneous stutter issues. The known issue of having the 'Transform' section expanded causes stutter, but on top of that, having some scripts expanded (i.e. StarterAssetInputs, InputSystemUIInputModule) also causes stutter. Also an odd thing I found is that even when the mouse input stutters, using a gamepad remains smooth for both stutter issues.

Currently my stutter 'fix' is to just click on the scene root when I'm not changing or monitoring any values because there is absolutely nothing in the inspector there.

 

How can I change FOV? It is fixed with 40 and I can't move it as I want.

 

Thank you so much for your information! This made my day, very appreciate!

 

Just testing the FPS controller:

• The look sensitivity seems related to the screen resolution? I don't know how FPS games handle this but it doesn't feel quite right. This might explain why some people thought the default was too slow.
• The actual look sensitivity seems far higher in my build rather than editor, when compared to game window maximized.
• The random camera jumps whilst playing in editor are really annoying, still seems to occasionally happen when nothing selected in hierarchy.
• If you start the playground scene, turn 90 degrees and then look at your feet the camera will jump slightly every time, maybe a cinemachine issue?
• Even looking around in the build looks quite jittery, I guess FPS smooth out your input to some degree?
• Maybe add a crosshair? Just so a beginner knows how they work.

 

How apply footstep sounds?

 

how can we apply forces to the 3rd person controller if it doesnt has a rigidbody? (i've tried to add to it but then it got stuck with with the falling animation)

 

Oh. But wait. Don't you know how much _easier_ it is to "add" things to this than it is to "take them away"?

Wait. Hold on a sec...

Uh..

Umm...

Uhhhh...

Errr...

Okay -- I sense some conflicts in logic here. Sorry. Just mindlessly repeating what has been told to me in the past.

Carry on. ;P

 

Hey good work however I can't seem to figure out 1 little problem. (On a fresh scene when I Import 3rd person capsule then jump down a slope or stairs, I'm not able to jump agian unitl I get off that slope.)I see The Grounded check is constantly being set to true and false simultaneously when moving down slope after jumping on it. I tried to make ground check bigger and change step values but nothing seems to work.

 

You've mentioned "dark patterns" somewhere before.

The Starter Packs are another funnel through which to feed the pattern mill.

Once you look at them from this perspective, the design decisions make some sense.

As does the Unity Learn site's design, structure and flow.

 

I can agree with that to an extent -- but we're talking about complete beginners here. In my experience, both as an expert _and_ as a beginner, showing them the cooler possibilities first, then letting them modify/remove/disable those possibilities (and then later modify and even one day make their own even cooler ones independently) is a better -- and more productive -- course of action (for the intended audience).

As a pattern, unless it is HUGE set of options (I'm talking > 3 options that affect the fundamental behavior of the entire system and/or most child patterns and systems -- i.e. a 2D character controller with many options that can become a 3D character controller that can become an FPS character controller that can become an RTS character controller that can become a physics-based 3D/2D character controller, etc.), these sorts of options are otherwise quite easily manageable. We are strictly dealing 100% with a 3D platformer controller here that is _maybe_ doubled as an FPS controller or 2D option -- all of which require similar options (no point and click styled behavior, no multiplayer components, no physics-based procedural movement, etc.) Removing options is a viable way to approach this sort of system (and the addition/removal portion could be repurposed for other options/tools/behaviors).

Just food for thought.

Also, Unity Learn is actually not too bad for its intended purpose. Although it can be clunky and a bit indirect sometimes (when you're trying to use it as a reference later on or return to a video you've either seen or know about already), outside of that -- I kind of like the basic idea of its approach.

---

Never said I was disappointed with your efforts -- only with the (apparently viral) mindset behind them at Unity.

You sound like a pretty good guy.

Just reconsider some of your assumptions is all I'm asking. That's all.

In the end, I hope you take this all as general feedback -- not as a personal critique. I'm genuinely only trying to help.

Thank you for your efforts in this.
And for being cool enough to try to improve things.

 

Hello

Just downloaded the 3rd Person package and added it to a new asset store landscape and built it for Android all worked great on 2020.315f2.

We are a pro customer, upgrading to Enterprise shortly.

1. I like to resleeve the robot with Unity-chan Anime girl. The documentation there is scant and in Japanese. But I do not see much complications.

Is there someone at Unity side who could lend a hand?

2. I like to write a program to move the avatar as a predator to chase and fight the Anime girl, but need a sample code from some other Unity project. Possible if some Unity person could send me such code/project please?

Thanx.

Dara

 

As a newbie, I say it would be useful a tutorial or so about how to add new controls to the Player (example: I'm trying to implement a new button for interactions with colliders).

Edit: there is an excellent one here with lots of implementations using the Starter Assets

 

This is pretty cool stuff. I've been toying around with Unity a decent bit and looking through the documentation trying to learn what I can. Although I noticed the Player Input is set to send messages, but I don't see anything in relation to gameobject.sendmessage.

Maybe I'm not looking hard enough or maybe this is done in such a way that sendmessage isn't explicitly used. I am curious as to how it's using sendmessage the way it was designed, I would like to look and understand this a bit more before trying to convert it over to an event based system.

If anyone can help me understand how it's invoking send messages or can point me to some documentation that I can check out to learn how this works the way it's designed I would really appreciate it.

 

I really like the new controllers, especially the third person one.

Is there a guide or resources to use it with MLAPI , for a multiplayer game?

Thanks in advance.

 

Some feedback after using the new Starter Asset for an internal prototype:

- I wonder why the team opted to use a StarterAssetsInput + Polling changes from ThirdPersonController, instead of using Invoke Unity Events from Player Input.

- Because of above decision, the scripts are tightly coupled; in order to customize them properly, we end up changing the whole structure on how character is controlled.

- One more gripe is how these scripts interact with Cinemachine: they work, but only when virtual camera are setup exactly as the sample scenes. Supporting multiple virtual cameras, again require a completely different handling.

I knew Unity content team often had to release within a short timespan and little manpower, so I am not going to argue for a 5-Star Asset Store release.

All in all, I am glad to finally see a refreshed starter asset! but this feels more like a proof of concept, than a solid starting point for users to learn best practice.

 

I have the third person character controller in a project, and it worked fine initially. Now however I am getting three compiler errors.

Two reference as "'CharacterController' does not contain a definition for 'velocity' and no accessible extension method 'velocity' accepting a first argument of type 'characterController' could be found"

The other one is the same error, but for the variable 'Move' instead of 'velocity'

I am not sure what has happened, I have tried completely removing the character controller and re-importing it, and I immediately receive the errors again (the errors disappear when the controller is not in the project).

Fairly new at Unity, any help would be greatly appreciated!

 

Hi, new to Unity and Starter Asset Package, we are using the First Person Controller to test the game in Game mode.
We can use WSAD to move around but when turning the (rotate Left or Right), the only way to do it is to use mouse.

Is there anyway, we can setup other Keys to do rotate Left/Right so the player can turn and see 360 degree then move using WSAD?

Thanks,

SpaceDragonMap Team