Sometimes Unity Technologies makes me so, so angry. Why do we have to rely so much on third parties?

I've spent the last 15 hours implementing Unity's Navigation System. NavMeshSurface, NavMeshAgent, NavMeshObstacle.

Everything went fine at first, within reasonable frustration (as always when it comes to Unity, working with anything created by Unity is a struggle & problematic - something simple will take many extra hours fumbling around to figure out why X is happening, only to discover some unmentioned quirk or undocumented detail - but eventually you get past what should be simple & everything finally works as intended.)

Then I discovered something awful. Hideous input lag. Unacceptable 30-140ms input lag from when I SetDestination() and movement actually occurs.

I spend hour after hour in documentation, debugger, and trying every possible solution. I know the problem: SetDestination just takes time to finish calculating the path. I don't actually have a problem with this. Unity isn't known for its amazing performance, and who am I to question how long it should take anyway?

-----------------

So the solution is obvious right? Start movement immediately in the direction of the destination, and upon path completion - stop manual movement & allow the NavMeshAgent to take over movement when it's finished calculating the path.

Nope. Not simple at all.

Unity's tech strikes again.​

If you want details about the problem:

Spoiler

But nope. Even with the method below, it will still report PathPending = false, and then 30-80ms later start actual movement. (I use System.Diagnostics.Stopwatch to test input lag. It's also noticeable visually.)
When I use only my manual method, I get 1-3ms input lag. Never lags. No problem.

Code (csharp):

1.   //If the NavMeshAgent has not yet calculated the path, then predict movement by moving in the direction of the destination
2.         if (myNavMeshAgent.pathPending || !myNavMeshAgent.hasPath)
3.         {
4.             //Debug.Log("Path still Pending or Path Null... Moving Manually...");
5.             ManuallyMoveToDestination(targetposition); //Just simple call to MoveTowards() gives 1ms input lag, but uses no pathfinding. Just straight line to destination.
6.         }
7.         else
8.         {
9.             //Debug.Log("Path Finished! Moving Automatically via NavMeshAgent following its path...: ");
10.             myNavMeshAgent.isStopped = false;
11.         }
12.  

The only possible cause is PathPending. I can simply remove the if statement & always call ManuallyMoveToDestination(), even keeping NavMeshAgent.SetDestination() & all other logic the same.

Input lag will go from 50-140ms to 1-3ms.

• Without checking pathPending at all & letting NavMeshAgent handle movement entirely, the lag is unbearable at 70-140ms. This is hideous, especially for a single character with no obstacles nearby.
• Whenever I put in my custom code above, checking pathPending, there are two results.
  • Result1: 1ms because pathPending reports true, manual movement starts immediately, and upon completion of the path the NavMeshAgent takes over. Success!
  • Result2: 30-50ms. PathPending will report false, even though it's still true, and 30-50ms later the character will begin movement. My only conclusion, since Unity is black boxed, is that it's still calculating the path 30-50ms after reporting PathPending false.

Accelleration is at 999999. I've made sure the SetDestination returned true & added a condition for !hasPath. I've messed with setting Velocity, and pretty much messed with every relevant variable.

No matter what, it seems as though PathPending is just lying to me. And this is only sometimes. Sometimes the logic will be successful. Then other times it will just decide "nah, I will lie & claim PathPending was successful when we still have 30-50ms to go."

I don't believe this is a problem in any other part of my code, because when I just use ManuallyMoveToDestination(), it moves immediately with 1-3ms input lag. Since adding an if(pathPending) conditional isn't going to add 30-50ms of cpu lag, I have a hard time believing this is anything other than Unity creating, once again, a seriously flawed system.

This is frustrating but not necessarily so much anger-inducing.

The anger comes when I begin asking people in various unity communities, and nearly everyone's response is "Unity Navmesh? Eww." and "I don't use Unity navmesh. It sucks." or "Unity-Anything is awful. Try [asset store asset].

When you discover that Unity's latest update that looks so awesome? When you naively think "They just revamped the system, and it looks great! It'll be great!" And then you discover you're pretty much the only one who was dumb enough to not use A*PP or another navigation system? Ugh. Unity got me again! I was tricked into thinking I would actually get a feature that didn't have glaring problems or lying variables.

My work time is limited - and this is as frustrating as when I tried implementing UNET when it was first released, worked my ass off for 40 hours, and then discovered in the forums that it was literally broken (didn't even work) with updates that came weeks later. Unity quality at its finest. I chat with the same communities with navmesh, and they feel the same with UNET: It's trash & abandoned. Oh gee, what a surprise that Unity users think nearly all of Unity's features are seriously flawed or problematic.

I won't even go into people reporting flaws like "SetDestination will randomly decide to fail. For no reason. It's just a thing you have to compensate for." Oh joy, more potential issues with a Unity feature that I haven't experienced yet!

 

I've learned my lesson.

Anytime I have the choice between a paid Asset Store Asset & a native Unity system? I will go with the Asset Store. Even if the reviews aren't perfect.

Cause Unity.

I also got quite an informative conversation from some chat users about Third Party Asset Store developers who went to work for Unity to implement their asset, and a few weeks later? Poof! They quit. They couldn't stand working for UT. A repeating pattern of UT needing competent third party asset developers to come in & fix their problems for them, and then those same asset developers quickly run away frightened at what they saw.

I just don't get it - why is it so much for us to expect features to not have serious flaws or be utterly broken or with insane design decisions?

Unity itself has been one of the biggest hindrances for development. After my current game, I am pretty sure I will be looking at other engines or just creating my own.

 

I've been there, I do understand and I've done my fair share of ranting over the years.. I think anyone working on a complex game can understand..

Although every engine has it's share of issues, I've hit the source code of UE on more than one occasion to fix bugs although 99% of the time I agree with their implementation decisions.. Also LY as odd and complex as it is to use is very powerful..

When it comes to Unity I only use Mecanim / Physx the rest is completely custom / half custom or store bought.. Although I've always believed that's the purpose of Unity, it's like a replacement for XNA where they give you examples as opposed to an "out the box" solution like most AAA engines are but they force a specific workflow because of it..

Wrestling with a AAA engine is never a good idea..

Question is does that fit your workflow? The more complex the game the more tools you'll need and time is a factor so you'll rely on the asset store more and more..

 

I often wonder, if the asset store wouldn't exist, would this raise the quality of the engine, because UT needs to "make sure it's useful".

I mean, if there is no 3rd party assets to "fix unity", the engine itself wouldn't be very valuable if it doesn't work or just don't provide the feature set required to build games.

 

For the game I'm currently working on, Unity is pretty much the perfect engine. 2D characters in a 3D world, the asset store's high quality assets are exactly what I need, use of nearly every single feature Unity has to offer, and an acceptable workflow for creating content.

Although not perfect, I don't think any other engine would be anywhere as good since I use so many of Unity's features.

It is just a huge demotivator when a native system which seems perfect just plain doesn't work. It's unbearably frustrating when something like PathPending returns false when it's still true. It's even more unbearable when no one has any clue how to solve the problem because they stay far away from the system or use a better asset.

What you said is what I hear all the time. Someone just mentioned how Unity is great because it's like a blank canvas. Then multiple people mention how they just write their own systems instead of using Unity's. This makes me beg to question why anyone would use Unity though in the first place. Just to render? Just for PhysX? Is this really that hard to do without Unity? I'm mostly 2D, so I honestly don't know, but am skeptical of Unity's value sometimes.

 

I am very, very confident in my theory that if the Asset Store didn't exist, Unity would have gone bankrupt years ago, as no one would use it. It would be at best a barely-successful unpopular engine. At worst, it would cease to exist long ago.

I've used Unity since 2.0 and I can honestly say I saw it as having negative value (even with the asset store) until somewhere around 4.x and especially with 5.0. I honestly do not see it having any success if it had never added the asset store, relying on third part developers to push the engine further by convincing people to use Unity Engine.

I could be wrong, but I really don't think so. That Asset Store is vital to Unity's success. I think they know that too, seeing as how they hire asset developers to help them fix what they can't do on their own. Which seems to be everything.

 

Can you post a repro project? I definitely don't see this lag with Agents untilI have 50+ concurrently trying to repath with many obstacles every frame. Sounds like there is very likely something else going on that you haven't considered.

The rest the thoughts here are fairly irrational, in my opinion. No one is obligated to use the asset store, so if you don't like it then roll your own solutions - but then, why not just buy them? No engine has accomplished what Unity has accomplished with the help of the asset store. The flexibility and speed granted by Unity + AS is unmatched. Frankly, if you can't see that then you should consider your thought bias and take an objective look at the alternatives. Is it without flaws? No, or course not, everything is imperfect, growing over time and will not perfectly meet your requirements.

On the thought of hiring, literally every company hires people to do literally everything for them. They get hired so that 'the company' can actually do that thing. But who's to say why or if people they hire might quit? Better offer? Disliked the corporate environment compared to freelancing? Change of circumstances? It's not our place to assume that they were unhappy since we have no valid pool of information to draw conclusions from, it's really not even our business anyway.

 

Didnt understand this at all because I have high praise for the asset store.

As for the rest, it isnt irrational at all. I have objective measurements of time working, there is nothing wrong with my code (pathPending just reports incorrectly or there is an uncobtrollable delay in pathPending and actual movement by NavMeshAgent).

The asset store saves time, but Unity works against you and is less efficient over time compared to a 2D game. I have actual objective measurements of a 60hr project in Unity and in a custom 2D engine, and Unity loses out on every aingle level. This study having years of Unity experience, no experience in a custom engine, and work only in setting up the basics (all else not ibcluded in time, such as the actual game simulation. Were just talking about rendering, input, and content).

So I have scientific evidence Unity has a negative value in certain projects. Asset store not included.

Your post is very insulting, as if my frustration is baseless and the solution failing when it should work.

The actual input lag isnt the problem. So performance is irrelevant. The problem is the fact I cant create a solution to compensate for it because PathPending is lying or Unity is not starting movement up9n PathPending true.

So it isnt relevant what else is going on in my scene. I could have 100000ms input lag and Problem2 would still remain.

 

Well, like I said, I haven't seen this and asked if you could post a repo project.

 

Try taking a project and killing performance with 1000 obstacles (so SetDestination isnt instant).

Then just loop movement update method to use MoveTransform() when pathPending and nothing when !pathPending.

Stopwatch Start on click. End & output results on transform.position change.

There is your repo. Some clicks will be instant bc pathPending. Some will have lag for no reason bc !PathPending when it is still calculating. I gotta go IRL.

 

The input lag isn't the problem. It's Problem1, which is easily resolved with Solution1. The problem is that Solution1 doesn't work due to PathPending reporting false when NavMeshAgent isn't yet ready. It's either reporting falsely or changing internally too early.

Yea, it's very irrational when you attach frustration & anger to scientific research, evidence-based conclusions, and logical reasoning. If only I hadn't felt human emotion, perhaps I wouldn't do something as irrational as basing my conclusions entirely on the evidence, scientific testing, & years of personal experience.

This is absolutely true, but only for very specific projects. For other projects, Unity is unmatched in its slowness & lack of flexibility.

Overall, I would argue this should be dismissed as fanboy nonsense. Project context aside, I could form a very strong argument that Unity is quite the opposite of flexible specifically because it is black boxed. That closed source & lack of low level understanding is a serious drawback. Quite arguably the worst aspect of using Unity. Now you could form a rebuttal claiming "But you can use Unity for ANYTHING!" but this argument is worthless because you can do this with most of the alternatives. Of course you can bypass Unity-Feature-X with your own custom system. You can do that in Unreal. You can do that in your own engine. You can do that in Godot. You can do that in Torque (not that anyone uses it, but you get the picture). I'm not sure how extendible GameMaker is, but I would not be surprised if even that can be "flexible" in this way. So to claim Unity has a strength that every other engine has? That's hardly a strength of Unity. That's just a fact. It's like claiming Unity is great because "You can write your own code logic in Unity!" Yea. You can. No one will dispute that. It makes it very flexible. However it's hardly anything special to Unity.

You know what IS flawless? Your own custom solution to a game. Your own engine/game. You can argue "You will have so many additional bugs!" or "That is so hard!" but for a competent programmer there is nothing better. For a team, there is nothing better. For Indie or AAA, there is nothing better. A custom solution perfectly designed to fit your game? It is the ultimate choice. Flawless, excellent decision.

However writing your own game/engine from the ground up is a lot of additional work. It is a perfect solution with a single drawback. Unity & other engines are imperfect solutions with many drawbacks. However the singular drawback of your own solution is the heaviest drawback in existence: Time. You lose time. You lose a lot of it. If you're not self-employed? You're losing money too. You're unsustainable if it stretches to infinity. Unity & other have a multitude of drawbacks, but those drawbacks are situational & often light. The weight of the drawbacks in each engine will vary. Depends on the feature. Depends on everything.

Um, the people themselves. This isn't speculation. This was information I was given by someone claiming to have evidence. A direct source from these users about their experiences. Others may be rumors, but they are not exactly unsubstantiated rumors. They fit a pattern reported by the very people who quit. First-hand anecdotes give a lot of credit to the idea that people quit for the reasons they stated they quit.

Of course it's our business. If UT is so poorly run that they alienate all the talented third party asset developers? That is bad. Bad for us. If I had known that? I might not have trusted Unity's Navmesh system. The result? I wouldn't have wasted 15-20 hours. If I had never touched UNET? I wouldn't have wasted 40 hours. That's 55-60 hours of my work. That is actual hours worked. Most programmers only put in about 2-4 hours of actual work each day in their 9-5. So that's 3 weeks down the drain. You can't tell me that's not my business when their incompetence costs me 3 weeks of development hours. For me? That's 1-2 months of work, because I am part-time developer who can't put in a full "40 hour (20 hour)" work week.


Perhaps rather than being so quick to accuse people of being irrational, you actually give other users the benefit of the doubt. Don't just go around assuming they are irrational people who are ignoring all evidence to the contrary. The only thing irrational I see in this thread is your mindless defense of Unity. As we must defend it when someone points out its weak areas.

 

I'd also like to point out that it is extremely inappropriate @LaneFox to come into a thread where someone is expressing significant levels of frustration & anger, and then begin insulting them "you're irrational!" followed by statements that their problems aren't real or valid.

I created this thread to vent. It made me feel better. Then you come in & stir back up all that anger and stress. Very S***ty of you. Try thinking before posting. I'd place you on ignore, but I really detest bullies who go around insulting people who are just trying to vent.

 

Sorry, I'll think before posting next time.

Also, I looked into it, verified the issue, created a repro scene and was posting a solution when you blew up my inbox with Linkin Park level angst so I think I'll just be on my way.

 

I could go on a re-rant of all the issues / failed projects I've had to move over to another engine to get working right but at this point I don't think it matters.

Today it completely depends on the project, I'm aware of Unity's quirks and if I'm in the mood to mess around and make a simple game amongst the ongoing drudgery that is artwork I'll use Unity..

It's simple / quick and efficient to create which most "AAA" engines aren't..

Although for major projects / anything complex I'd rather use <Insert engine here>.. Then again UE's BP's are getting better all the time and I'm getting used to it so I might not even use it for small games / prototypes at some point.

Unity is my "backup" although I'm thinking of moving my backup over to Lumberyard. I need realtime GI for one project and besides LY and Unity no others seem to have it (well a properly working version anyway).

 

Good post, thanks for sharing!

Yea, the project's needs definitely change what is best to use. Unity is a good backup too.

I also still absolutely love Unity for game tools. Even when I make my own engine, I will almost certainly use Unity to make tools for it.

 

I completely agree with you. While I love Unity, the initial thing that attracted me to Unity was the amount of free and open source resources to use whether it be scripts or assets. However, I really wish I didn't have to rely so much on the asset store for essential things. You bring up a good point because the frustration and stress of having to rely so much on third-part assets can drive many developers away to other engines. I think the best thing that Unity can do is to address these issues with full open transparency and recognize in certain areas, Unity really can improve when compared to other engines. I still love the community, but I definitely agree from a hobbyist perspective it can be extremely frustrating to have to rely so much on third-party assets.

I really hope that Unity can take this opportunity and see it as a way to improve their engine and better serve developers who have spent so much time and money on Unity.

Also, thank you for posting this, I have definitely felt the way you have felt many time during development of the project. I too have limited time as I work a full time job. I mostly do development time on the weekend. However, recently I have been trying to get more done on the week days after taking time to cook a healthy meal.

 

And thank you for posting that you share a similar experience/feelings. Also good luck on development & I really hope you end up getting more done on week days!

Whenever I began forcing myself to do the "at least 20 minutes every day" habit forming, it has really helped. I've found myself doing 4-8+ hours every day. That's a huge change from mostly 0 days.

One thing in particular that helped me feel a lot of satisfaction with only being able to, at my best, commit 20 hours per week, was when I realized that is actually what most programmers report being capable of. Full time employees.

Reading Self-Reporting on actual productivity and then The Myth of Developer Productivity, I began to realize that nearly everyone reports only getting 2-4 hours of real work done each day. So they go in for 40 hours/week of work, and output only 10-20 hours of actual work. So when I only have 2-4 hour days, I am actually accomplishing a lot more than I realize. I always thought I was accomplishing little unless I did a full 8 hours of coding.

I felt a lot less guilty for the times I only did a few hours of programming, and even more accomplished when I actually manage two 4-hour chunks in the same weekend day.

 

I'm gonna play Devil's Advocate. Note that none of the following is to detract from how much it sucks when you've got a 99% solution in your hands and have to backtrack or rework to get around that last little bit that's not in your control. I've been there, it's pretty lame.

Even assuming Unity were 100% perfect as a general purpose tool, I'd still be writing my own purpose-specific stuff for it for any non-trivial project. If I can buy that stuff instead of writing it myself, sweet.

The NavMesh stuff in Unity is a great example. I've had a bunch of successful projects where I used it and it worked out really well. I've also had a bunch of projects where it wasn't the right tool for the job, in which case I either made my own solution or grabbed one someone else had already made. That's not even Unity specific, it happens in any kind of software development, regularly.

 

I've skipped about 50% of the thread because I'm in a hurry, hope this isn't too reduntant.

It wouldn't. I'm sure no one at UT has an attitude of "ah it's fine, the assetstore will fix it". Almost everyone has at least a shred of pride and wants to be better than others at what they do. Without the store they'd miss out on what seems to be an important avenue to hire proven talent.
The main problem with the assetstore imho is that it's economically based on self-exploiting developers that take huge financial risks.

Unity probably has the quickest way of all engines to get "placeholder tech" into place to have something there that you can replace later. The 15 hours to have flawed pathfinding don't sound too bad to me. I'm sure I spent waaaay longer on trying pathfinding solutions. Only I started at A*PP because at that time the built in solution was no good for runtime navmesh baking. But A*PP doesn't fit my usecase. I tried the built in one later, and it doesn't fit my usecase either. I tried a very simple steering behaviour without path finding, that looked much better, but had no actual pathfinding in it. Then I wrote my own custom multithreaded solution that is crazy limited in its own way, doesn't scale well with fast-forwarding time and has huge latency between updating the nav data for all enemies, but it is closer to what I wanted than all previous attempts, so that's what I'll likely stick with. From my point of view the assetstore is as much a "false hope" as the built in stuff. Shader, shader-editors, IK solution, postFX, and highly specialized single-purpose assets from the store so far have worked reasonably well for me, but I've bought and dropped tons of other assets that just don't fit my usecase or my style of working.

Thanks for sharing, I'll put those two articles on my to do list. Sounds very relevant to me.


My condolences for the hours you've lost, we all know the feeling, but as sort of a silver lining I hope it was educational in some way and will save you some grief in the future.

The lesson I personally draw from this kind of thing is to always first think "can I write this myself?", because usually I can't buy what I need in terms of code assets, and my self-written stuff by nature fits my requirements better.

 

I hope I learned enough for it help me in the future.

I did learn about System.Diagnostics.Stopwatch, which is great for when the profiler isnt detailed enough. I can see that being majorly useful in the future.

I am going to try Apex Path. I read the reviews talk about its performance being better than even A*PP and the code very professional.

I was thinking of writing mt own system since my needs are really simple, but I really wanted that flexibility in case I change things up post-prototype.

I came really close to trying it out before going with Unity Navmesh.

Oddly enough, a huge waste of time failure would usually get me to take a break. After forming my habit, I am still excited to go back in for round 2.

I started when I got an unexpected full week off work, which helped form the habit since I wasnt worn out by work.

It has been a week since I've done the "At least one session a day." habit. It was hard the first half to commit so much each day. Then it become easy. A habit. I dont think. I dont feel. Motivation isnt a thing. I just get to work.

I am not sure how going back to work will effecf my habit. I think it will be okay though. When off work I take 2-4 hours to wake up anyway. When I work, I wake up at 4pm and basically go straight in to work, eat while working, and am wide awake when I get home. So that saves me some time.

While I know there is no way I can do two 2-4 hr sessions on work days, I feel confident I can definitely do 1 every single day.

This has made me very happy with myself too. Very satisfying not having that regret of a 0 day. I can definitely see myself working 40hrs a week if I could ever become a full time gamedev.

I also find myself talking only with positive communities like this one or Discord chat. And less time wasted browsing the net or getting trolled in a bad community. "Aint nobody got time for that!" LOL. I still enjoy forums, but I feel I have less time to waste. I guess cause I actually do. No more TV binging either, lol. I just want to work and take 1-2 hr breaks inbetween sessions.

 

With the navmesh stuff part of the problem is understanding the inherent limitations of the underlying tech. Obstacles on recast graphs never perform well if you have a lot of them, it's going to slow stuff down. Grid graphs are limited to small sizes. If you have large maps with lots of dynamic obstacles, there is no solution I know of that will just work out of the box.

I would suggest using grid graphs with some additional logic to navigate graph boundaries. That logic isn't that hard to do, and grid graphs tend to work well for lots of obstacles.

 

When you push something past it's inherent limitations or what most people use it for, expect stuff to start failing. That's how it is for any software. Rarely will a system just degrade nicely when pushed past it's intended limits.

 

Huh? Did you even read the post you just responded to? I didn't push it past any limitation. I had an extremely simple use case.

If checking if(pathPending) is pushing Unity's Navmesh past its limitations, then it's beyond incompetent programming - it's a flat out joke.

 

It's quite disingenuous to lie & pretend like you created a solution. It's also disingenuous to say sorry in public but in PM double down on your trolling. Seeing as how you can't fix pathPending reporting incorrectly without source code access, we know you're lying.

If people are naïve enough to believe you very conveniently created the solution but refuse to show it, lol, then fine. Just don't cry when you get called out on being a disrespectful jerk.

 

I hear Yoga is an excellent stress reliever.

 

You said take a project and put 1000 obstacles in it, that's what I was going off of. If you understand how navmesh cuttting works, which I do having hacked on recast nav which is what the Unity stuff is based on, then you can easily see how that many obstacles could start to mess with finding paths generally.

 

The only stress remaining in my life is your persistent bullying of me in this thread. Reported.

Welcome to the ignore list too. And thanks for derailing this thread with your bullying. Well done. Stay Classy. And say hi to Trump when you crawl back into whatever swamp you two came from.

 

If Yoga doesn't work, there's always those nice scented lavender oil steam things. They smell nice and they're healthy!

 

Fixed...

 

Ranting/venting is allowed to a degree... but it has gone of track and devolved to name-calling. 'Nuff.