Search Unity

Typical code problems in Unity projects

Discussion in 'General Discussion' started by DaniilGalahow, Jan 31, 2024.

  1. DaniilGalahow

    DaniilGalahow

    Joined:
    Dec 2, 2013
    Posts:
    12
    Hello everyone!

    I want to analyze typical code problems in Unity projects. Each one of us faced strange and unexpected code constructions in scripts, sometimes in legacy projects we need to support, sometimes in our own projects.

    I want to understand a sources of this problems, and, maybe, make a guide how to awoid this - something like "How to make a good code for Unity".

    Can you share an examples of such code or such troubles (most exceptional sh[beep]tcode you saw in your practice)?

    For example, what I faced in my practice:
    1) Totally incorrect usage of Unity. One company tried to make a mobile app for video editing using Unity, motivating this like "well, Unity is good for multi-platform apps, so we can shorten the time for development of interface for Android an iPhone using Unity". And I don't want to remember about how its code looked (you all may imagine how to edit video "between" Update() calls).
    2) Using "non-Unity-way". Animating assets through code from MonoBehaviour without using Animator. Ignoring Unity tools (like, changing color of sprite through redrawing all of its pixels in memory). Forced usage of OOP principles and patterns in Unity projects, ignoring MonoBehaviour-based behaviour logic. Using MVC, inverted direct dependency injection and other techniques which is not utterly necessary in game projects. Making a code for Unity in a way used in other PL and stacks (Golang, Java, Fortran, you name it)... And so on.
    3) Overthinking and overdoing. That's continuing of what I said about force usage of OOP - everything is abstract, making a code with 3 levels of abstraction and overloading bitshifting operators on simple demo with 3 moving objects
    4) Creating Unity over Unity. I.e., when developer has an experience from other stack and PL, and trying to make sort of a "wrapper" for "big an misterious Unity" for himself.

    Also, I appreciate you to say your opinion about sources of such problems. What is the roots of this? How can developer avoid it?

    (Sorry if I posted it at wrong forum. But I thought that it's not only about code, but also about code quality, coding theory, and, we can say "way of thinking". If it's in wrong place please say or transfer it)
     
    Last edited: Jan 31, 2024
  2. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    > Animating assets through code from MonoBehaviour without using Animator.

    This is not an error. DoTween says hi.
     
  3. CodeSmile

    CodeSmile

    Joined:
    Apr 10, 2014
    Posts:
    5,824
    I've been doing that for so long I cannot remember. You caught my interest with just this first sentence. :)

    I just released a video where I talk about the many things devs do wrong (out of habit, ritual, cargo cult) in relation to the AssetDatabase, and examples were saddeningly easy to find via GitHub. For each snippet in this video I only had to look into two or three scripts at a time:


    In summary, the issues in my video exist because:
    • Examples and tutorials were incorrect to begin with. Repetition creates truth.
    • Developers simply apply what they know. They work with their blinders on for various reasons (time pressure, getting things done, why question what works, etc).
    • The API is confusing, inconsistent, not discoverable, too technical, bloated. Hence my complete refactoring of the AssetDatabase.
    Take the latter. You want to do something with labels with the AssetDatabase? Autocompletion is not too helpful, not even after you type two letters:


    Whereas my version, you can even pick the right category straight from the initial list:


    And then you see all the functionality at once:




    As to your examples:
    1. Clearly a case of technical incompetence on behalf of both developers and decision-makers.
      • In a software dev team, I'd expect even the most non-technical product manager to understand the differences between realtime 3D rendering and native GUI development and their implications.
      • I imagine highly motivated juniors or inept devs convincing management otherwise simply because they know/like the technology or want to have it on their CV (this happens!).
    2. A case of lack of experience with Unity, blindly buying into paradigms, and/or not enough research.
      • Likely involves inexperienced developers and/or those that blindly apply principles, paradigms or tech that they're either familiar with or recently became followers of.
      • Chance of decision makers to blame, though they may be the same as above. Or they may have forced their team to a very tight schedule which often results in applying what you already know rather than properly researching/learning the new stuff.
    3. Close to #2 but clearly with a focus on trying to apply best practices / not repeating past mistakes.
      • Commonly happens in rewrites or major refactorings of a previous project. This time, we'll do it right!
      • This has Technical Direction failure written all over it. Either there was a lack of senior developer competence in the team or the senior(s) forced those paradigms onto their team, perhaps to enforce architectural boundaries, divide up the work, and similar well-meaning ideas.
    4. That's #2/#3 again.
    Overall, I'd say your examples are mostly caused by ineptness or incompetence, and inexperience - which is practically the same except there's still hope for learning.

    I attribute your examples 100% to teams that consist of people either largely in the Ignorant stage (example #1) or within the Cultured low (examples #2-4) with none, not enough, or not influential enough seniors/experts. In the Cultured area you'll most often, and fittingly, find Cargo-Cult Programmers.


    Personally, I'd say for Programmers specifically the upward trending curve ought to be way flatter than it is. As you move towards Expert level, programmers often fall prey to questioning too much, which ends in analysis paralysis or over-engineering solutions.
     
    Last edited: Jan 31, 2024
  4. liquify

    liquify

    Joined:
    Dec 9, 2014
    Posts:
    187
    Unity recommended ScriptableObject event architecture to avoid those problems and to make the code more modular. They posted a video about it on their YouTube channel with a PDF link to explain the concept in details and made a comprehensive example with their first open project or UOP1
     
  5. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,062
    PrimeTween might be better these days. Next to no allocations, async compatible and is safely destroyed with the gameobject, no need to track stuff manually for transforms.
     
    KyryloKuzyk and Ony like this.
  6. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,122
  7. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,062
  8. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    Speaking of Dunning-Kruger effect.

     
  9. kdgalla

    kdgalla

    Joined:
    Mar 15, 2013
    Posts:
    4,626
    The only constraint to what code problems you might encounter is your own imagination. Anything is possible and the sky is the limit!
     
    DragonCoder likes this.
  10. DaniilGalahow

    DaniilGalahow

    Joined:
    Dec 2, 2013
    Posts:
    12
    Well, no, that's not what I mean. I spoke about situation when developer developing "his own" DoTween. I mean, when you facing a script, for example, where someone moving parts of object with bare code, like applying new
    Transform.position
    at key times.

    And yes, btw, DoTween is slow and why you need it when you already have Animator?

    Great video, CodeSmile! And that's really great that you understanding what I'm talking about. I deeply agreed with issues you wrote. One of the most important, by my opinion, is problem with examples and tutorials, multiplied by misunderstanding of concepts how Unity works.

    For example, I'd say that Unity is a thing working in "soft real time", because of its frame-linked logic. So programming for it is closer to a programming drones and industrial robots, than to general programming. A lot of developers never thought about this (many of them didn't get deep even in Unity's official documentation) and from this grows a lot of issues. It's exactly a multiplication - without understanding a basic concept coder could make a lot of weird solutions to force app to work.


    Yes, lack of competence is a scourge of Unity development (and developers). Unity has relatively low entry threshold - any school-grader, having a computer and motivation to make games, could get a try. Some of them even achieving some success. Of course, nobody needs them in professional teams - but team leaders and product managers, especially in cases where is no experienced seniors in a team, could be catch in a trap named "schoolboy on Youtube said that it's easy".:mad: And a trouble is that a lot of programmers trust them (or supporting their decisions 'cause of different reasons).

    I have an additional question to you. What you can say about usage of OOP paradigms, rules (like SOLID principles) and templates in Unity development? It's interesting to hear your opinion.

    Well, that's not exactly what I'm talking about. Usage of
    ScriptableObject
    can help in some cases, but it's not a silver bullet. But your opinion also could be an example of what I'm talking about in sence that good developer should know his tools. Not everyone using
    ScriptableObject
    in their projects.

    No. I strongly disagree. Don't forget - someone could need to support your code after you. Self-expressing via code, especially in commercial projects, is a bad thing.
     
  11. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,812
    I really dislike this stance. A lot of these have important uses in certain situations, even in games. MVC especially. My current project wouldn't even work without applying the pattern. It's also a very good pattern when it comes to UI.

    And there's plenty of reasons to ignore or bypass Unity's built in tools. Some are incomplete, others like the Animator are massive performance sinks and often overkill for simple situations where a few lines of code will do the job.

    It's really about applying the right tool for the right job. Monobehaviours are a good tool for certain jobs. Sometimes they're not.
     
  12. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    Which is also not an error. Dotween is an external dependency, and explicitly forbid redistribution of modified versions. It is not MIT or opensource. That means you can't tweak it and put modified version onto github.

    You'd have stronger point if it was MIT/BSD software, but it isn't.

    To drive procedural animation.

    Ken perlin had a lot of good examples at one point on his page, before java got discontinued. Animator does not work for every situation.
     
    angrypenguin likes this.
  13. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    463
    I agree with you in general, except this one. MVC is an archaic pattern when it comes UI-based applications. I think MVP is a step in the right direction, but it's still too limiting at databinding. "The good" pattern when it comes to UI is MVVM. It facilitates bi-directional binding and still keeps separated and clear boundaries between components. IMHO if you bother to setup any kind of pattern to serve your UI, it should be MVVM most of the time. Quick rundown why. As always: IMHO.
     
    DaniilGalahow and spiney199 like this.
  14. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    7,812
    To be honest I wasn't quite aware the various 'MV' acronyms actually represented slightly different patterns. Figured they were just different names for the same thing, or slightly different things that ultimately do the same thing.

    To me it's generally just about separating your data from the view, however the implementation of that may end up being structured. So TIL I suppose!
     
    CodeRonnie and Lurking-Ninja like this.
  15. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,714
    Because animator has a ton of performance overhead (and I mean, if you think DoTween is slow, have you profiled the animator?) and its controller gets messy real fast if you have a ton of animations, has a ton of weird implementations (like if you animate a var in ANY animation in a controller, that var gets stuck in default value for all animation clips), it is the source of many off by one bugs and weirdness and in general just sucks for many situations.
     
  16. CodeRonnie

    CodeRonnie

    Joined:
    Oct 2, 2015
    Posts:
    529
    I still feel that way. The more I research MVC, MVP, MVVM, the more I think everyone is trying to describe their own idiosyncratic application that they wrote one time. I take all the useful concepts swirling around in my head from all that research, including the stuff that flat out does not / can not / should never apply to Unity that people still seem to push anyway. Then, instead of trying to make up a new acronym like MVCVMP, I just go back to hand waving at the general concepts to properly separate your application layers as "MVC." There are at least three different types of "controllers" that I can think of, that should be used in any Unity project, that are completely unrelated to one another. Trying to get hyper-specific always ends up describing someone's particular architecture or taking in circles in my humble opinion. I think the general concepts, and the ability to apply them properly when building up a system are more important than this particular acronym versus another. The source acronyms usually don't originate from within the Unity environment anyway. Like in the linked article, there is no consideration given to working in a loop based environment, as all games are. Everything is event based like it's an enterprise application, and the view needs to be told to update. In Unity, a view widget can just have an Update method that invokes a loosely coupled callback to poll the current data each frame, with no hard dependencies. That design isn't even mentioned because half of the trademarked coding wisdom on the web comes from event based app architecture. However, I want to be clear that I'm not disagreeing with LurkingNinja because in the context of that article, I think that the main point is that views should not have hard dependencies on models, and I totally agree with that.
     
    Last edited: Feb 1, 2024
    Ryiah and DaniilGalahow like this.
  17. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,122
    DOTween is slow and generates garbage but Animator isn't any better and in some cases it's actually worse. For example it's actually really bad to animate UGUI with Animator because it will continuously trigger a refresh (ie it will set the dirty flag) even when nothing is changing. This was covered way back at Unite 2017 by Ian.


    Of course you shouldn't use DOTween either. It's incredibly outdated at this point with multiple alternatives that are not only an order of magnitude faster but generate zero garbage. We've mentioned PrimeTween and LitMotion but there's also MagicTween (same developer as LitMotion).

    PrimeTween is licensed under the Unity Asset Store license. MagicTween and LitMotion are MIT and on GitHub.

    https://github.com/AnnulusGames/MagicTween
    https://github.com/AnnulusGames/LitMotion
     
    Last edited: Feb 1, 2024
    Ony, MadeFromPolygons and neginfinity like this.
  18. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,856
    Lerps, timers based on for free deltaTime and duration alongside an animation curve eval can make any custom tween happen on nearly any type..floats, color, vectors, strings changing text walking their char indexes through the alphabet...3 lines of code.
     
  19. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,062
    Yea, but then you'd probably want to abstract those 3 lines so you are not copy/pasting the same code all over the place. And then you'd probably want to sequence some of that, add cancellation logic, various callbacks, etc, etc. Some of the additional features introduce allocations if done the easy way. You can easily spend weeks writing your own in-depth tweener engine to cover common use cases and then have to maintain it.

    The benefit of a high performance 3rd party library is that it already does all of that and with very good performance and you don't have to spend time on maintaining it.
     
    liquify, Lurking-Ninja and Ryiah like this.
  20. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,856
    I make a utility. I can drop it on anything. Makes Rube Goldberg-ing easy and fast. I make my own libraries..often faster than available...because they are custom to my purpose and I do not have to use flawed implementations, often discovered after adding the code, running into roadblocks and jumping thru hoops to extend or compile code I have no need for. Weeks writing a tween library..heh..that is like a late night session and a cup of coffee. We wrote a custom curves library in a few hours. Has all the tween curve types and a dozen custom eval curves we found useful. It is a prefab. You drop it in a scene and send a value and curve type to evaluate. Here are some math libraries we wrote https://github.com/OpenBrainTrust/OBT.Maths
     
    DaniilGalahow, Ony and neginfinity like this.
  21. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,130
    Yeah, gotta go with ippdev here. A custom tailored tweening library is a day or two tops since you're really not going to be implementing the whole thing, just what you need. I think even in mine the most complex thing to implement was the accompanying spline tool for the Unity editor.
     
    Ony and neginfinity like this.
  22. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,714
    I mean, it depends on how complex your tweening needs are. If you get to a point where you want to make a tweening sequencer or whatever, then a ready made library is probably the way to go.

    Otherwise... yeah, we also grabbed a bunch of tweening curve functions, slapped them in a library, and a couple of helper functions and that's about it. It took a day, and most of the time was spent making a visualiser tool for funsies:

    fun.gif
     
    ippdev and spiney199 like this.
  23. halley

    halley

    Joined:
    Aug 26, 2013
    Posts:
    2,420
    Nice feature. I think AnimationCurve.Evaluate() is way under-rated by the newbie set. It can emulate/approximate all those as presets, but also let the designer make their own blinky, jagged, swinging, and other curves visually.

    Another thing I think should be in every newcomer's toolbox is a simple set of gizmo classes. Rewriting functions that use Debug.DrawLine() or Gizmos.DrawWireSphere() comes up very often, but for half of the time, I just have a quick GizmoRaycast or GizmoCapsuleCast behavior I throw onto an object and get the benefits immediately. And if those aren't good enough as-is, they're a nice encapsulated reminder of how the API works to show someone how to use the functions directly.

    example.png
     
  24. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    Nah. Half of those things are nice in theory, but are not necessary.

    I wrote a dotween replacement while tinkering with walker tank demo. Additionally, there's no goal to eliminate all allocations. Only those that cause issues.

    If you somehow end up spending weeks on this, there's a huge design problem.

    Here's a good site: https://easings.net/
     
  25. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    463
    Sorry, but this mentality what I hate when it comes to Unity's teams as well. They don't use unit-tested, established services from each other, because "they write it at night with a cup of coffee", so we end up with multiple stuff doing the same thing on different ways.

    My guiding line is simple:
    - do I particularly enjoy writing something?
    -- yes: I write it myself without looking elsewhere
    -- no, but do we have unit-tested solution from a third-party usable, ok licensing, etc?
    --- no: write it myself anyway
    --- yes: just use it, if it contains some bug I can fix it myself and/or report it to the author

    And no, I'm aiming for allocation-free run after the initialization at all times, debugging, profiling is expensive and time consuming, the further I can avoid those the better and I can spend more time with the parts of development I actually enjoy.
     
    Last edited: Feb 3, 2024
  26. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    If a language comes with static type system it is a good idea to eliminate unit tests and attempt to write code in a way where it wouldn't be necessary.

    Basically, unit tests are necessary in python and javascript, because compile time checks are bad. You can eliminate them in C++ (const correctness allows for nearly functional level of side effect elimination). In C# it depends on what you're doing.

    The problem with tests is that you're writing the same thing twice. Code should fully describe intended behavior. IMO.

    C# as a language is simply not made for this, so you'll be fighting your tools. The language WANTS you to produce garbage. Dogmatic C# is heavily leaning towards immutability and that's garbage generation everywhere.
     
  27. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    One other thing.
    There are valid reasons to want to own all code you're using.

    3rd party library introduces a fault point which is beyond your control, because there's no warranty that your goal aligns with those of the 3rd party author. Projects die and change. While initially you get "free labor", there's also risk that the library will change to something that is no longer usable.

    Such risk does not exist with code you wrote, because code does not rot.

    I personally ran into a fairly fun situations when dealing with AFrame framework. Basically the library initially was developed by energetic enthusiast. The enthusiast has ran out of energy and moved on. People took over, formed a steering group, and steered the project so far that their changes made all tutorials obsolete, disabled half of useful functionality it had and so on. That happens often.

    In this thread there are people saying DOTWeen is outdated and obsolete. Several years ago it was a recommended library. Now there are new libraries, and of course those too can in time die, move on, become warped visions of themselves and so on. By the way, does anyone remember UMA? Used to be a popular thing, seems to be dead now.

    And let's not forget stuff like peacnotwar where someone installed HDD wiper into NPM for political reasons.

    Your own library in time will grow into your own personal tool similar to customized emacs config. That's the value in it. So, yes. It is reasonable to add 20 tweening functions into it over a coffee break.

    Same applies to C# allocation. Advanced features of this particular language produce garbage. So writing allocation free code comes at a fairly high cost. But a good idea is to ask, "what do you gain by paying that cost". In many scenarios the cost of garbage is minimal. In such scenarios making code allocaiton-free would fall under premature optimization.
     
    Last edited: Feb 3, 2024
    Ony likes this.
  28. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    463
    I'm not sure you understand the unit-tests' role in this context. You test that your logic is what it needs to be. And if later you change something, the test will fail if you break your logic. It is imperative on bigger projects where sometimes dozen of people are working with the same scope, same code. It's especially great if unit-test libraries you publish, so you and the people who uses it can be sure the logic laid down in the tests is intact after any number of changes.

    This is a false risk. What happens is you don't get any updates later. If you find some bug you will need to fix it for yourself. Which isn't as complex than it made to be here on the forums by people who claim that they write all those functionality one night with a cup of coffee... I hope you see the conjecture here.
    There is no real risk other than you end up getting your hands a bit dirty with a library, nothing extraordinary.

    Good thing that I'm not leaning towards dogmatic C#. So that's the end of this nonsense.


    Sadly it was never popular and it is alive and well. Many people are using it if not directly but through other assets/services like MMO-stuff.

    Nothing is beyond my control. I have the source code, I have two eyes and a brain to use, I can figure out if the author ends support and I find a bug or need an improvement. It doesn't negate all that time I gained using it up to this point. It's a false risk.

    Shameless plug
    If you or anyone reading this wants to improve UMA, please donate a small amount here to fund new base models and artwork:
    https://www.gofundme.com/f/lets-fund-some-new-artwork-for-uma
     
    Last edited: Feb 3, 2024
    Ryiah likes this.
  29. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    And if the project goes into odd direction, you'll have to freeze your version. Which will be the same thing as not getting updates.

    Risk isn't false, because I saw this happen.

    In situations where you're dealing with a pile of code that is several megabytes big, most likely you won't be fixing things quickly. Because you'll need to waste time figuring out how that thing works, what their abstractions are then possibly deal with interpersonal bullshit while trying to submit the patch. Cause bigger projects can form their little club of friends a random stranger will not be a part of.

    Fixing bugs is trivial only in trivial code. And when the code is trivial, you can just write it without a thirdparty lib.

    To quickly FIX things in a 3rdparty lib, you'd need to spend time familiarizing yourself with it, which can take LONG time depending on severity of the problem and complexity of codebase. Multiply it by your hourly rate, because you'll be doing unpaid labor.

    Coffee break code can easily end up being cheaper.

    Honestly, just try to dive into Unreal codebase.

    And yes, it is all valid.

    Regarding dogmatic C# and you not following it. The language is made to implement dogmatic C#. Because it is controlled by steering group which doesn't care about unity. So the moment you're deviating from it, you're fighting tools. Immutable strings along signal what kind of paradigm the language follows.

    --edit--

    Anyway, none of this matters in the end. Just don't end up thinking in black and white.
    Unit tests are not inherently good. Writing your own thing is not inherently bad. For most things there are situations where they're useful.

    Thinking about it, this is the issue with opening post. There are situations where advice given wouldn't be good. As demonstrated by procedural animation.
     
    Last edited: Feb 3, 2024
  30. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    463
    No, you're convoluting things. You wont' lose or even substantially delay a project because of an easing library. If you find a bug in your easing library and you can't fix it under an hour, I don't know what to say to that. Other than dump it and choose another one. It's a non-issue.
    Obviously the more a library does for you, the more of your code is substituted by the 3rd-party the more rigorous you need to be when you decide if you use a 3rd-party or write your own. Or which 3rd-party you want to use.
    This is a problem with these forums. People tends to magnify certain things like the risk of relying on foreign code.

    The more beginner you are the bigger the risk is. If you have experience, you will choose a library which is manageable by you. If you don't have the stomach to bugfix a foreign library you choose to write your own, if you're like me, who don't have a big problem with reading other people's code and fairly quickly get what they are doing, it's time saving to choose one with fairly reliable unit tests and with functionality I need.

    This is why I like to use easing libraries from 3rd-parties but not movement scripts from other people. The feel of the movement in a game is in the vast majority of the cases makes or breaks a game. I like to control that as much as possible in the given game engine. But I can replace a faulty easing library under a minute, I throw a stone and I hit three of them at once.

    So, I get where you're coming from, I just think you gone too far. We aren't talking about a functionality which makes or breaks your game. It's (usually) aesthetic problem in the worst case.

    I really don't care what they are doing with the language as long as I have the opportunity and way to write my code on a way it doesn't allocate greatly during runtime. I don't think it is something they can stop by any means. Unity does release more and more APIs with non-alloc behavior, so the direction is the opposite.

    Exactly.
     
    Ryiah likes this.
  31. ippdev

    ippdev

    Joined:
    Feb 7, 2010
    Posts:
    3,856
    My unit test is to hit the Play button and see if the numbers, colors and objects act as intended.
     
    neginfinity and Ony like this.
  32. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,714
    The argument was against complicating things.

    I find having a simple easings library and managing the tweens myself to be more straightforward than a full fledged tweening library.

    I also believe that if Unity made a tweening library, we wouldn't be getting something equivalent to LitMotion or PrimeTween or even DoTween. We would be getting a slow, awkward and over-engineered library and the common advice would become "eh, it's fine for some situations, but you should use the animator instead".

    That said, for years I couldn't understand why they didn't include a library of just the easings math (and maybe a couple of helper functions) with the engine. Even in Unity rates of development, it just needs a couple of weeks (mostly to figure out the fastest math, because there are multiple viable methods for the more complicated curves, and some perform better than others). I feel like providing that would open up using curves in more areas as well, like: Animator crossfades are always linear, why can't I have them be non-linear (a slight S-curve looks a lot better and more natural).

    But. Would they do that? They wouldn't. They would write a library, they would release it in the feature grave that is the package manager and let it rot (and then fire the one that wrote the feature). Nothing else would use it.

    Plus they will manage to miss a few super common easings, (say, inoutExpo), and they will pick really slow versions for some of them. People here will figure it out, tell them to change it, we will get a 30 page thread, but Unity won't want to change it because of fear of breaking things. A few Unity employees will post passive aggressive stuff about users being unable to understand how complicated this stuff really is, but then DM the users that were complaining that "they were right", after they get fired.

    The common advice will then become "use the package, but replace InOutQuad with InOutQuadCommunity etc etc and add InOutExpo yourself and (etc etc)"...

    ...

    In the end, there are two options when using Unity:

    A. You want to use a feature Unity doesn't have:
    1. Figure out the problem.
    2. Implement a solution that suits your project.

    B. You want to use a feature Unity already has:
    1. Figure out the problem.
    2. Try to use the Unity feature, find a showstopper real fast.
    3. Try to understand why Unity's implementation is this way so you can figure out how to circumvent parts of it.
    4. Post on the forums about it and lose some hair in the process. (and if you really want to go completely bald, submit a bug report)
    5. Implement a workaround, probably with icky stuff like reflection, because of course Unity doesn't make their features easily extensible.
    6. Finally, implement a solution that suits your project, if you still remember what you wanted to do.
    7. Redo all the above when updating to a newer Unity version, because they changed something from one undefined state to another undefined state and your workaround doesn't work anymore.

    And unless Unity changes something and another option appears, it's better to pretend Unity doesn't have a feature and use option A always.

    I used to ask for Unity to implement things, so certain problems would be solved once for everyone instead of being solved individually by everyone, but I no longer believe they are capable of solving problems. I guess they are currently too busy (not?) figuring out how to make a right click menu suck less, but hopefully they will be done with that by the time Unity 8 comes out.

    So yeah, I can totally understand why even internal Unity teams, when they want to use a graph system, they see the in-house solution, which is likely (going by Unity's track record) over engineered, cumbersome, has a ton of boilerplate and works in esoteric ways that have nothing to do with the rest of the engine, and go "yeaaaah... I guess we'd rather write a simple system ourselves instead".

    This attitude is indeed frustrating and leads to problems, but it is born out of the way Unity works.
     
    Last edited: Feb 3, 2024
    Ony and PanthenEye like this.
  33. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    Your previous post was talking about libraries and 3rd party code in general. And I was discussing 3rd party code and libraries in general. And not about specific case.

    For easings you do not need 3rd party library in the first place. Or unit tests. Or updates. Functions are known, they do not change and they do not break. Because code does not rot.
     
  34. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,697
    Thinking "I can do it better and more stable" is quite an anti-pattern you see often.
    Why use an engine in the first place? xP
     
  35. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,130
    Many games use Unity specifically to handle rendering, input, audio, and nothing more.
     
  36. neginfinity

    neginfinity

    Joined:
    Jan 27, 2013
    Posts:
    13,563
    To save time on prototyping.

    A lot of things fall into "I can do it better", and unity has many bad ideas and bad code within it. Also, unity ignores suggestions for an improvement so if you want something improved, you do it yourself.

    So, in time, using unity as a scene graph and nothing more, like Murgilod said, becomes a reasonable idea, and then in time, replacing unity with custom solution may become a reasonable idea as well.
     
  37. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,697
    Sorry but for an indie that is everything but a good idea.
    For large scale industry maybe.
     
  38. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,122
    How are we defining "indie"?
     
  39. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,697
    Maybe project size is the better measurement. Was refering to projects where programming is done by no more than two or three fulltime devs.
    Think that still coveres the vast majority of Unity users (and also of Godot).
     
  40. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,130
    CodeRonnie likes this.
  41. CodeRonnie

    CodeRonnie

    Joined:
    Oct 2, 2015
    Posts:
    529
    Last edited: Feb 4, 2024
  42. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,697
    That someone does such a thing does still not mean it is a good idea or prove anything...

    EDIT: And looking at that particular persons profiles, he seems like the typical tinkerer who enjoys having fun with details more than getting a game done ;)
     
  43. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,714
    I too wish more of Unity's out of the box features were good enough so I didn't have to work around them all the time, but here we are.
     
  44. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,122
    Brian Bucklew is the developer of Caves of Qud. That thread details how he ported the game from Unity to Godot in about 14 hours which is very much the opposite of what you described. Game is insanely successful too with hundreds of thousands of copies sold.

    https://www.cavesofqud.com/
    https://steamspy.com/app/333640
     
    Last edited: Feb 4, 2024
  45. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,130
    Also having code that is maintainable to the point where it can be ported to a whole other engine is a pretty good thing, so the entire post is wrong.
     
  46. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,697
    It is a good thing to have that, sure. But is it also worth the immense effort?
     
  47. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 5, 2024
    Posts:
    463
    Well, it's a good thing to have a bunker when someone drops the nuke too... But really?
     
  48. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,062
  49. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,714
    For the record, I believe Caves of Qud started as a C# non Unity project and was then ported to Unity, so it being mostly independent of Unity was the natural way to go.

    But again, Unity should have features that are some good balance of robust, easy to use and performant.

    Ideally it would be all 3.

    Realistically, maybe 2 out of 3.

    But since we've been getting 1 or none out of 3, everyone is used to "rolling their own", including Unity's internal teams.
     
  50. Murgilod

    Murgilod

    Joined:
    Nov 12, 2013
    Posts:
    10,130
    The effort isn't insane at all. If you start a project this way from the start, it's actually pretty simple if you have even intermediate level skills. This is something a lot of Unity projects do in general if they're expected to see any amount of long term support or they're quite rightly abstracting away from internal methods as best they can because of how frequent API changes happen in things like packages.

    What you see as "insane effort" is actually a best practice for a lot of people for a lot of good reasons.

    It's been less than half a year since Unity specifically did that and if you've ever had to update something like URP mid-project you'll find that they also tend to do less severe bombing runs roughly every two months.
     
    Ryiah likes this.