Basic Concepts in Unity for Software Engineers
blog.eyas.sh
blog.eyas.sh
It's easy to get started, iterate on ideas, there are tons of examples of things online.
That said, it's not without its warts -- APIs change constantly, which means many of the examples or assets you find are no longer functional or need to poking to get working. Sometimes things just... behave oddly... in the editor. And the story around collaborating with friends is still not great (though a free tier for Unity Collaborate has helped with this a bit.)
If you haven't messed around with Unity, I encourage folks to give it a try. The new Universal Render Pipeline stuff they've been building is really nice for a solo/small team project.
Unless you plan on developing an open source game or need absolute total control over your project I wouldn't use Godot.
The greatest advantage of Unity is anyone can develop something for it very fast. The worst part of Unity is anyone can develop something for it very fast. An asset developer might build something which he or she doesn't actually update, or has a nasty habit of completely breaking your project.
The one thing I don't like about Unity is the lack of quality control with assets. Some assets will give you a nice foundation for a fantastic project, others will set you back days. Asset authors are almost always either absolute Angels, who will go out of their way to help you and if they can't offer you a refund.
Or their jerks, their assets don't do what they promised and they'll refuse to refund your money. If I could fix one thing about the unity ecosystem, I'd tell Unity to give asset buyers a few no contest refunds . I probably spend about 1000$ on Unity assets per year.
The one time a $15 asset ends up not working correctly I should be able to get a refund without begging the author for it.
Plus it's essential to understand what your goal is. Do you want to actually ship your game within a reasonable amount of time? Or do you feel like creating a project primarily for learning, or to just share the code on GitHub?
If you want to ship a game, either use Unity or Unreal. These are the only two engines which are well supported enough where you can get something done within a reasonable amount of time.
Open source engines are cool, but there is absolutely no expectation of things working as well. Let's say you want to build a project with Godot, and it's going well so you want to publish it to Switch. You're going to run into a ton of problems off the bat, one open source projects tend to not support closed apis which council manufacturers force you to support. So you're going to have to build your own integration there.
Vs clicking a build to Switch button with Unity.
Honestly I can't say enough good things about Unity, you have an amazing amount of educational material they publish. And for the most part I've been able to buy assets for $50 or $100, and save myself 80% of the development time on my projects. You aren't going to have a good time with Unity if you're adverse to buying assets.
That's basically a 2D / 2.5d game framework.
Nothing from the Asset Store is essential, but it would take much longer to do everything yourself from scratch, as well as being difficult to learn how to do everything yourself without examples to experiment with.
> The Corgi Engine is recommended by Unity as part of its 2D Essentials Pack.
Maybe I read too much into it.
Especially for a software engineer, there's of course always the fantasy of coding everything on your own. I might not get a platformer system because that seems "fun" to implement, but shaders often feel so beyond me that I'd just rather get someone's optimized shader.
Very surprising. ;-)
It's simply nowhere near as polished as Unity or Unreal. If you want to make something in Unity, you can pay a few hundred dollars for some assets, snap them together like Legos , add your own character models and be ready to ship in months.
In Godot, it's rare at all to see any paid assets. Meaning instead of being able to buy a starter kit and get my project done, I'm coding all this stuff by myself.
What important features is Godot missing that Unity has?
Here's a summary: https://www.reddit.com/r/godot/comments/axsohk/in_your_opini...
Missing occlusion culling is on the top of list.
The latest reference (from 9 months ago, so not much more recent) I could find for occlusion culling[0] says it and LOD are planned for the Vulkan branch, so those are still issues.
[0]https://old.reddit.com/r/godot/comments/emachb/how_long_unti...
When I played with Godot (two years ago, a lot has been improved since), it was definitely a bit raw. It worked, but I found it a bit of a struggle. I’ve been reading their release notes since and they’ve improved a lot, but I haven’t actually tried it out yet.
The one thing I personally don’t like about Unity is how much emphasis is put on C#, I just never got into the language and have no desire to use it. Godot is a bit nicer for me in that respect. I prefer Unity’s ECS and job system over Godot’s scene system though, but lots of people say the opposite.
I don't see anything so far to back up the claim that Godot isn't finished, which would mean it's not suitable for anything except for experimentation. Seems like it's at least fine for smaller games.
So you're saying we're Waiting for Godot?
Assets load differently, in surprising ways. Materials may work fine in Editor but not in Client.
Code executes differently. Timings are different, the Editor shares managed Heap with the Client, and so garbage collection is different.
And so on.
Rule 0 with Unity: _do not rely on the Editor for testing_.
I think with time/experience you'll learn to spot what to ignore (frame lengths, etc) and what you could count on. And just to test fully-build games often, and across clients.
* C# does something similar with hash across builds (so you don't depend on serializing/deserializing hashes and expect them to work; they want the freedom to change hash functions).
I agree that you can't easily use editor performance profiles though; there's far too much editor noise.
Unity is still crap at loading things in order but you simply have to make peace with that. Instead you have to write a bit more defensively and assume that your code will get initialized in a random order. As long as you use Unity serialization all the references will be set when the lifecycle callbacks fire.
You can - Use coroutine Starts to wait for initialization
- Ensure all the inits are done in Awake so things are ready during Start
- You can also move away form initialization towards a more lazy pattern and make sure any calls into your behavior are asynchronous and include self init when needed.
It is a bit clunky but you can get used to it. Lean into the idea of behaviors being asynchronous actors and it makes a bit more sense.
All coroutines on a gameobject are halted if it is disabled, _and do not restart_ when it is re-enabled.
For this reason it is easy to mistakenly leave a game object half-initialized, due to an enormous amount of plausible situations where some event, script or other may disable the game object.
Now, there is a work-around: have Start yield a coroutine started on a "safe" object that will never disable.
The caveat is that the caller can be destroyed during execution of the coroutine but the coroutine will persist to execute because it is on another object.
The only lifecycle a behavior can trust is its own. Relying on other objects turns into a mess when your weak assumptions are violated.
Besides causing a spaghetti mess of lifecycle tracking and callbacks and such, it leaves you wide open to the major problem if callbacks running pass the life of the thing to call back to. You've thrown away Unity's lifecycle tools by dumping everything into a big pot. Now you have to null-check in the callbacks to make sure your things are still alive. Track your own state and you'll be fine.
Coroutines will stop when the owner dies and that is by design. Leverage that to ensure brain dead clean up.
Objects are very often going to be disabled through user action anyway, eg quitting a level. Its better to just assume that will happen at any time and plan accordingly.
https://docs.godotengine.org/en/stable/getting_started/step_...
After spending literally hours trying and failing to get Unity to run at all on my computer, I downloaded Godot and ran a demo project in 5 minutes. It’s a great lighter-weight option for software developers who want to feel a little closer to the code.
Both are fine, but if you're going to pick one, I'd suggest Unreal by a long shot. Switching between the two is tricky and is likely to make one feel whichever they started with is more intuitive as the UI design is pretty different for each editor, but both feel fine after a short effort. The main reason I'd vote for Unreal is that Unreal feels like it's getting better at a noteworthy pace, and Unity is stuck in a one step forward, one step back pace.
* C++ (unreal) is not as fun as C# (unity). But Unreal's blueprint system (a visual, node based coding system) is much easier than both, and super helpful in the game dev world because it makes the engine API easily discoverable. Not good if you want to write a list sorting algo. Very good if you want to make a character jump. Dispense any preconceptions they may have implied about "not needing to know how to code" to use blueprints. If you can't code you will likely burn out trying to use blueprints without grasping the fundamentals of coding, because blueprints are just code with visual syntax, and syntax is not the hard part of coding.
* Marketplace assets on unreal seem way better. The high end stuff is better. The free stuff is better. The number of high quality textures and prefabs you get for free via quixel in Unreal is astounding.
* Unreal requires more computing power, and I found the editor crashes more. That's not so good.
* Networked multiplayer is just broken in Unity, versus integrated into everything for Unreal. This is huge! for shame, unity.
* Unreal's financial terms are more indie friendly (free for first million of revenue)
* Neither is going to make or break your game dev experience versus the other.
Unity's licensing model has always been that developers or users must pay for their own license (for an asset or non-free subscription) unless they are part of an entity's license. Unity clarified that only employees of an entity, or subsidiaries of an entity and the subsidiary's employees, are covered by the license.
This is generally always how it works with software licensing: independent contractors, by virtue of being separate businesses, must pay for their own tools and licenses (and indeed, that is one of the factors in the independent contractor test under federal US law).
However:
Programming in Unity is quicker and easier.
* In Unreal you have to choose between Blueprints (which have some issues) and C++. C++ compile times are slow. Unreal supports hot-reloading of C++, but it frequently breaks stuff, so it's safer to save your work, close the editor, and then recompile and restart the editor. It takes a few minutes, which really slows down iteration times when you're tweaking a feature. If you have a bug in your C++ code, it can crash the whole editor, and you'll lose any unsaved changes.
* Unity's architecture is simpler, lighter, and more pure. Unity has GameObjects. They hold a collection of components. An empty GameObject has very few functions or variables. GameObjects are purely containers; you don't inherit from them, you just make components. Unreal has Actors. An empty actor has 448 functions. sizeof() and empty actor is over 1 KB. You inherit from actors, and functionality is mixed between inheritance and components. This flexibility may sound like an advantage, but I find inheritance tends to cause more problems, especially in conjunction with Blueprints. Unreal's built-in classes (AGameMode, APawn, APlayerPawn, ACharacter, APlayerController, AGameState, UCharacterMovementComponent) set up a somewhat complex architecture for you that's strongly biased towards the FPS genre.
* Unity's API documentation is miles ahead of Unreal's. The community is also larger which makes problems more googleable.
Blueprints kind of suck.
* Blueprints look friendlier to non-programmers, but code is easier to read and write for anything complex. Even short things are often simpler in code. For comparison, here's the same function in Blueprints (https://i.imgur.com/86rt8qp.png) and C++ (https://i.imgur.com/7HSnlR9.png).
* Blueprints are saved in an opaque binary format. This doesn't work well with version control. Unreal has a diff tool for Blueprints, but you can't merge them. On rare occasions, a Blueprints will get corrupted or bugged and your only option is to revert it in your version control (we've had Blueprints crash the Unreal editor whenever you open them).
* Blueprints are an order of magnitude or two slower than C++.
* Blueprints lack a lot of functionality compared to C++. Only API functions that are intentionally exposed to Blueprints can be called. You don't have anything like functors or lambdas. There's nothing like templating or generics. While there appears to be a dropdown to make Blueprint functions public/private/protected, it doesn't work (it literally has no effect).
* Making C++ code useable from Blueprints is extra work. It can be tricky to write classes and interfaces in C++ that can be used from either C++ or Blueprints. It's not much of a problem for a single concrete class, but it gets tricky when you want to make things flexible with interfaces.
Unity has more resources for developers
Epic is slowly closing the gap here, but Unity has a bigger community, a bigger asset store, and better docs. For models and sounds, we often would use the Unity Asset Store for our Unreal projects. Unfortunately, that's not possible for code plugins. Stuff like Amplify Imposters and FinalIK just doesn't exist on the Unreal Marketplace (although looking again, the Unreal Marketplace recently got a Fabrik IK plugin, so maybe they're catching up).
I don't agree with this. I do think C# is an easier language to follow, but Unity's game engine API has less stuff built into it, which is a far more time consuming element to work around. If you want to say, launch a projectile, Unreal has the projectile movement component that you can slap on something. Unity you'll need to implement it yourself. I went from Unity to Unreal and find the number of things that are automatic vs. manually implemented is a way better time saver.
> Blueprints kind of suck.
I've never had them run too slowly versus code. I do miss lambdas. But I think blueprints have some advantages that code does not. It's incredibly useful to visually see at a glance what functions are pure with no side effects. It's lovely to be able to collapse large sections of code into nodes with long descriptive names that you don't need to look at. I code in blueprints as much as possible. I low key wish I could move my python jupyter notebooks from work to such an environment because it makes the pipelines so easy to follow. That is, I find it way easier to produce excellent documentation for them than with code. Mind you many people seem to have the opposite interaction and create lovecraftian spaghetti horrors.
I don't quite follow what Imposters does, but I think this is likely to be outclassed in UE5 with its nanite and lumen. IK solvers are just a part of the engine via Control Rig. Haven't used em though.
To each their own though. Unity is good. I just have doubts about its future management.
> It's incredibly useful to visually see at a glance what functions are pure with no side effects.
You can use the const keyword for this in C++.
> I code in blueprints as much as possible.
I also code mostly in Blueprints. The fast compile/iteration time is the main reason. But it has it's downsides (code review is largely impractical, no merging, physically much bigger and longer to read than equivalent C++).
Imposters and IK are actually both things that Unreal has built-in, but the built-in versions are limited or poor quality. Unreal has two-bone IK, and more recently, a FABRIK solver, but it didn't support multiple end-effectors or joint constraints. So basically, if you wanted something like a multiplayer VR game where the character poses somewhat realistically to match the positions of the headset and hands of the player, you couldn't do that. The main use for Unreal's two-bone IK (which was the only built-in IK for a long time) is for smaller tweaks like adjusting the position of a characters foot to be in contact with the ground.
UE5 looks very cool. I'm looking forward to its release.
Oooh thank you
I pick Unity every time. Yes it has many many issues, but as a hobbyist you'll pick a version of it and stick with it. Improvements isn't where the end goal is at, it's at allowing you to deliver a game/product on a given version.
C# is definitely a lot better than old-school C. Unreal C++, everything is just extremely clunky and verbose. Sure there are blueprints, but then now there are free alternatives for the same on Unity as well (although not working as well). If you need to know something there are 10x more free resources for Unity. If you need to buy something, there are 1000x more items on the Asset Store.
You don't need Unreal for Quixel, you can also use it in Unity. You can also use Substance. Sure there are many useless assets, but there are also many many many awesome assets in Unity. Use them.
Both editors have issues. I won't comment on Unreal. Unity's can be a real piece of work sometimes. They all give you issues and make you go arrrgh.
Networking. Unity has nothing by default, it's all in the Unreal corner. If you want to do it in Unity, install Raknet, cloud options, etc., you'll have to figure it out. It's a big ball they have no clue about.
Financial terms, let's see. Both are ok. As an indie first you need to produce, then it's about the fine print. Both are ok, really.
Last point, 100% agree. It's about producing a game. Both engines will fight you hard if you try to produce anything outside their default mindsets. Unreal by default focuses more on fps action. Unity is more open. but GameObjects are extremely heavy and restrictive. You'll need to figure out instancing (until whenever DOTS becomes production ready and useful). Other issues, newer options like HDR isn't supported in Unity by default yet, so if you're heading that way it's definitely not for you.
One thing that’s interesting to me about Unity is AFAIK it bakes the Entity Component System pattern into its core. Any good guides or resources on this?
I found Robert Nystrom’s excellent book a good resource for this (http://gameprogrammingpatterns.com/component.html) and even wrote my own post on the concept to help crystallize my understanding (http://ripplega.me/development/ecs-ez/). I’m interested to see if there’s a good authoritative Unity-specific post on the topic.
Don't know how close these patterns would fit Unity, but I would suspect a large overlap.
I’ve switched over to the Heaps engine by the creator of the Haxe language.
In addition to the compile time issues, I found myself constantly fighting the Unity way of doing things in that I prefer doing things in code as opposed to using the editor.
For me, I realized that wanting to "keep it all in code" is a learned habit, and part of why I learned it is because the tooling when everything in code is just so much better. I can navigate references, etc., count on compiler errors runtime errors, etc. But none of this fundamentally required me to keep it all in code _if_ the tooling allows it. With ~2020 it feels like the tooling is getting to that point.
I don't think Unity is nearly at that point for my use case. Part of the problem is that I tend to build games that require a lot of procedural generation and user created content.
I basically end up needing to build some kind of level/content editor for my end users, which removes a lot of the value Unity brings to the table.
If you're using procedural generation or using an external tool to design your levels, then the Editor definitely becomes a hurdle.
(You do need to turn off Auto Refresh though, no idea why they think having that setting enabled by default is a good idea.)
Changing a single line of code can take close to a minute on a medium to large sized game under a 2020.1.
Using something like Heaps where you can compile a large game like Northgard completely in 4 seconds is a completely different experience.
Also, I think it's worth mentioning that if you care about the longevity of your game (like 10+ years into the future), depending on the Unity runtime being compatible with future OS versions is also a risk.
Then again, the alternative requires some pretty hefty engineering chops and prior knowledge of a whole host of lower level concepts and APIs.
EDIT: Also Heaps is the choice of Dead Cells dev and he's written about it some here: https://deepnight.net/tutorial/using-my-gamebase-to-create-a...
It's not that they make it impossible upgrade to a new major version, but yes it's not prudent to switch between major revisions of a game engine deep into development, that's not unique to Unity.
Game engines don't have the JavaScript style churn where your library is dead if it doesn't do something major every month
Unreal Engine 3 => 4 was 8 years?
Unreal Engine 5 is going to launch next year, almost 7 years later
Unity 4 => 5 was 5 years, and then Unity switched LTS releases which are getting updates for 3 or 4 years?
-
The improvements that come with major versions just don't make sense to try and pull in on a game deep in development either
I mean look at this year's releases, a big focus has been the new render pipelines, but are you going to rip out your game's entire graphics stack mid development and redo every single shader and material?
Unless you really have a good reason, probably not...
You can pull new versions while under development. I've been on a team that did it and it was not fun. Usually involved some poor soul pulling the short straw, spending ~6 weeks 3-way merging followed by a large uplevel commit that breaks everything. This follows ~4 weeks of bugfixing at which point you start the process again since a new major version was just released.
But can you imagine the nightmare if you weren't standing on the shoulders of Unity and trying to do it in your own custom engine? Especially on console? Unity is probably getting hardware before 99% of devs on some platforms, and they have resources that dwarf most dev teams when it comes to shaking out issues. It'd 10000x the nightmare to go it alone...
Like I said, it's not just Unity, and it's not like the game engines are even doing anything particularly brutal, they just treat major version releases with the weight they really ought to carry. You can upgrade, you just better have a damn good reason, and if you don't have good testing procedure you're going to suffer twice as much.
-
And honestly some of the pain is just out of their hands
I remember Wii U development was tied to a specific major release of Unity when N+1 came out due to their custom integrations. But Nintendo didn't track that update, and gave no time frame for doing so for a hot minute. Unity 5 just ended up shipping out of beta with no Wii U support
I don't know what a game planning on requiring Unity N+1 to ship would have done there, but I'm sure similar dependencies exist internally on other platforms that Unity has to manage.
They've essentially got multiple engines that all need to be landing changes together in sync, I don't know why people are surprised that such an insane technical challenge requires you to treat major versions with some real weight...
Last in-house game I did we had to bring a while networking layer online for a platform that didn't previously have it and that part was a pretty painless process.
I mean to put it very simply, do you think that adding support for a platform with hardware that was probably pretty new since Unity does tend to be ready near launch for major consoles... was more work or less work than your 10 weeks of merging stuff then bug fixing?
You could spend 10 weeks on a new hardware platform just getting to a working engine just because of toolchain teething problems... and I bet someone at Unity definitely did to get you to the point where all your biggest worry was testing and merge conflicts
Also this comment in your original post:
> at which point you start the process again since a new major version was just released.
Surely you're not trying to imply Unity... which went half a decade between releases for a while, then switched to LTS releases with 3 years of support minimum... is forcing you to upgrade every 10 weeks...
The larger point I was trying to make is that an internal team is aligned with your goals and can support you. And external engine is tied to their own goals that might not align with your schedule/platform/feature set/etc.
No one wants to be going through a contract dispute in the middle of development as it's a sure fire way to sink your title.
Anyway, it's just a long way to say that when you do your due diligence on an external engine, is to only look at what you see now and not what's on the roadmap.
Due diligence on an external engine is planning ahead instead of acting like a deer in headlights when a new release comes breaking changes, because that's what you should expect.
That's what my comments have said thus far, nothing more nothing less.
People are acting like it's a problem specific to one engine that yes... an external engine is not marching to your personal timeline and will have breaking changes on major releases so you need to adjust your own schedule to theirs...
If you did your due diligence the cost of having to conform to their schedule should lower than the value that they provide is. Otherwise you shouldn't have used the engine.
Honestly it's surprising I've had to spend this many comments explaining that... that's kind if the basic math before you should even use a game engine
I've seen whole platforms which were on the milestones in the contract delivered in an incomplete and unusable state.
I've seen engine developers prioritize high profile internal titles over licensees including explicitly telling developers that their features will be de-prioritized until they ship.
I've had to implement non-insignificant features(ex: LoD geometry streaming) because it wasn't a 'priority' to support open-ish world games.
While internal engines shared across studios may not have the same level of polish they can align with what the teams need and roll out large breaking changes in an organized manner. Once you have 2-3 studios using an internal engine there's a critical mass that builds around it(assuming game types overlap to a degree).
Like everything there's pros and cons, however if I were evaluating a external engine in 2020 anything beyond what's present today would be a nice bonus and not something I would plan around.
Of course you can not update, but then you might be relying on half-finished/half-broken features that could be fixed just by upgrading.
Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time.
First part of this sure, Unity likes to have different ways to do stuff and I do wish they'd focus more. The roadmap approach they're taking shows that they are committed to working on it, and I'd say they've done well tackling that.
But the second part? About getting cornered into updating by new features, not buying that for a second.
If the feature is done enough to use it in a game with a large scope trying to follow a real development schedule, it's not disappearing. If it's not, don't use it.
LTS releases are getting 3+ years of updates, before that we were going 5+ years with the same unity version, so when you say "actively maintained" when you mean is they're not getting changed anymore. Which is a good thing.
Unity 5, from 5 years ago, is still getting security updates.
Where you get cornered is trying to pull in beta features into a game that has a hard schedule then getting screwed when the beta feature takes advantage of has breaking changes during a major release... which is kind of the point of a beta.
Unity has a huge community with a wide range of expertise and scope in their projects, if you're just blindly following what people in the forum are talking about, you'll follow some people working on small projects with small lifecycles.
Unity has never been for rug pulling, if something works well enough for your game today, it's going to work well enough tomorrow, they're not going to yank it just because it's not the new hotness. Even Unityscript ended up getting a smooth path into the sunset with a converter tool despite being used heavily in under 4% of projects (and being used exclusively by <1% at the time)
-
> Also, the whole upgrade process itself could be improved if they put time on it. There's nothing inherent to game engines that forces Unity to have so many breaking changes all the time.
Again, where are these breaking features "all the time"? Unity 4 => 5 was half a decade?
Now they have their date-based versioning, but LTS releases still get at least 3 years of support, and the next LTS is the next year, not the old 5+ year cadence, so you get an incremental upgrade path with 3 whole years of smoothing.
Outside of major releases I've only ever seen a tiny handful of breaking changes per release, the majority of which where back when we were going 5 years between major revisions so they'd hold everyone's hand with a detailed guide and "pay once, cry once": https://docs.unity3d.com/Manual/UpgradeGuides.html
Note how now only LTS versions need these...
I mean, someone brought up Monogame here, apparently not aware that XDA 4 which it targets was a major breaking event from XDA 3. Game engines have breaking changes on major revisions.
Software, often has breaking changes on major revisions.
Don't build your software, on other software, hoping to blindly chase every major release painlessly, it's just not going to happen once you get to a certain level of complexity. These companies are not abandoning previous releases instantly, they still get maintained
I could Ctrl+R Unity for Unreal in this comment and nothing would change, it just comes with being a swiss army knife of this sort
Nope. Unity still has a lot of very important features that are or were in Beta or unfinished state for a very long time, at least until very recently. DOTS, SRP and HDRP, to give a few examples [1]. If I strictly follow your advice I would have to virtually stick with features from 2015. Thanks, but no thanks.
These problems with Unity have been going on for about 5 years and the official line by their team is that "we're rewriting stuff and it's going to be great, but in the meantime just wait".
--
> Again, where are these breaking features "all the time"?
> Don't build your software, on other software, hoping to blindly chase every major release painlessly
So, you're saying that there aren't many breaking changes and updating is easy, but at the same time saying that people shouldn't even think about updating an engine mid-project because it's reckless?
Sorry, but you can't have it both ways.
Notice how you're blaming users for everything here: they can't update because it's hard, but at the same time we can't complain that it's hard because Unity is great and doesn't have many breaking changes. Also there's some whataboutism going on when you mention that Unreal and Monogame. This doesn't matter since them both don't have the crazy update schedule that Unity has where a major-upgrade is released every now and then.
--
[1] And btw I fully expect an answer like like "Oh but you're not up to date on those, feature X has been finished in version XXXX.X, you just haven't upgraded yet". Well, guess what, there are breaking changes and I can't easily upgrade.
You expect wrong, I'm point out how hilarious your complaint is.
That hard to implement features are in beta (And pre-beta!) for a long time so that we can actually contribute to their development cycle with feedback and bugs, instead of Unity getting them almost done then throwing them over the fence...
It's insane to me someone would try and spin this as a bad thing with a straight face, and in fact it makes me question if I'm talking with someone who just has never dealt with the stuff behind the scenes here (like actually having to implement features of this scope)
Every single feature you just mentioned was Unity reaching deep into the bowels of their engine and reimagining something. DOTS is literally a reimagining the core concept of how entities exist in Unity! Literally a core tenant of the engine.
You're complaining features like that are developed in the open? You realize the gnashing of teeth that probably forces them to go through to allow it? Are you joking?
-
> If I strictly follow your advice I would have to virtually stick with features from 2015. Thanks, but no thanks.
No, you'll get to use plenty of features, it's just you won't get to use the unfinished ones unless you're ready to deal with the fact... they're unfinished...
Unity doesn't make that confusing to know either, they literally won't even show you a preview package by default!
Hard stuff takes time, when development happens in the open you get to see that. Unity has plenty of features people are using to ship games that aren't in preview lol, imagine acting like Unity's preview system is a bad thing
-
> So, you're saying that there aren't many breaking changes and updating is easy, but at the same time saying that people shouldn't even think about updating an engine mid-project because it's reckless?
Lol that's a uh... creative straw man, I'll give you that much
Literally the words you quoted spell it out, breaking changes happen during major revisions and that major revisions are not a frequent event or easy to track.
They used to happen twice a decade. But that also meant it was very awkward for them to ship big things.
Now they happen once a year but to avoid forcing you to track breaking changes once a year they switched to the LTS model
So now you have 3 whole years to deal with breaking changes.
Can't deal with that, it's kind of on you.
The problem is that the alternative is to work with features that were so behind the curve that Unity themselves decided to rewrite them years ago, instead of fixing them. That's my issue.
All I'm asking from Unity and its evangelists is honesty: you either have ready to use features or you don't. Putting all the good stuff that you're advertising behind a "preview" label and claiming it's the customer's responsibility when it doesn't work well is not ok.
The features that these new ones supplant on not "behind the curve" just because their replacements take a lot of effort to make!
I don't know what it is that has rotted the ability of some devs to understand the concept of things that actually work without constant refresh, this isn't NPM that's why they can afford to take a couple of years on features and still have a state of the art engine without it .
Literally DOTS is coming down right as we're seeing a reworking of how games approach data and latency.
If Unity had never said a word about DOTS and released it next year, they'd be fully "on the curve". In fact in that specific example, they're ahead of the curve, DOTS is really a rethinking of architecture that no middleware type game engine has tackled yet.
And look at HDRP, it's landing right as Unreal also releases their first major graphical shake up in half a decade next year with Unreal 5.
Do you even know what "the curve" is for middleware game engines? It honestly sounds like you don't
> All I'm asking from Unity and its evangelists is honesty: you either have ready to use features or you don't. Putting all the good stuff that you're advertising behind a "preview" label and claiming it's the customer's responsibility when it doesn't work well is not ok.
That's how things work when you don't care about your relationship with developers. I feel like some devs just don't know what good software practices look like when I read stuff like this.
I mean abject insanity to find someone complaining a company is putting things out, make it very clear that they're in progress, not even letting you use them without changing settings! and then gasp replying to developer feedback?!
Incorporating that feedback into their roadmap even though landing multi-year projects is already hard enough with just internal input?!
After all it's not like Unity is dangling carrots here, even these preview packages are getting treated with the same rigor that normal ones do in relationship to bugfixing, and they are always cognizant of the fact that even preview packages have users if you actually look at their conversations in the forums
-
What you seem to be missing is Unity would still be a top engine if they never mentioned another preview package again. But it'd be a worse product.
Taking external input? Constantly cleaning up your work to put it over the fence? Having it end-user ready years before completion? That's a lot of work.
Unity features would be less work for them if they didn't do that.
But the features would have come out after spending a bunch of time in that state are better for everyone involved.
This all started with people whining about breaking changes, you think breaking changes would be better or worse if they weren't happening incrementally with real users in preview?
Read again. They're not behind the curve because there's new replacements. They were already behind many years ago, and that's why Unity decided to rewrite them instead of upgrading. Non-preview replacements still haven't arrived for a lot of those features. Maybe that's ok for you, but it's not for me. The end.
The rest of your post seems to be making the point that Unity is great for people who want to give input on how to create an engine. Sure, but I'd personally rather have software where the major advertised features are ready for use without having to "deal with the fact... they're unfinished".
I didn't even try porting my 10 year old XNA game until a year and a half ago, and I was able to get it compiled and running with 90% functionality (again shaders and storage was broken) in just 24 hours.
And they just had a major new release that, among other things, supports .Net Core, just two months ago, yet I'm still able to do this.
Monogame is _literally_ an implementation of XNA 4: https://www.monogame.net/about/
> MonoGame is an Open Source implementation of the Microsoft XNA 4 Framework.
It's raison d'etre is to let you run stuff that ran on XNA 4 specifically, you could almost say it's psuedo-ABI is XNA 4. So while they've built on that... it shouldn't be surprising that yes, literally the one thing it was built to do, works.
I mean it's to the point once upon a time XNA's API reference was MonoGame's documentation and to this day they match, even if it takes harming the soundness of the API:
https://gamedev.stackexchange.com/questions/67040/where-is-m... https://github.com/MonoGame/MonoGame/issues/5487
-
Also you realize XNA broke stuff on it's major releases too right?
It's actually kind of ironic and funny you'd bring up XNA 4, because it REALLY broke stuff:
https://www.shawnhargreaves.com/blog/breaking-changes-in-xna...
Literally the words of a Microsoft dev lead at the time:
> I was relieved when the comments on my earlier post about backward compatibility agreed with the approach we chose for XNA Game Studio 4.0. Banjobeni summed up the general sentiment:
> "If you break it, break it good."
-
But also, and I mean you allude to this right there in the first sentence, it doesn't have half the surface area Unity has, it'd be like pointing out SDL's API staying stable?
Even if you look at something that isn't Monogame I'm sure you'll find some frameworks that have had static APIs for decades, after all, if your layer of abstraction is high enough while your scope is small enough, DrawPixel 0,0 is still probably going to end up drawing a pixel somewhere just like "forward 50" is going to "move the turtle forward 50"...
But then to that point, the basic APIs like that in Unity haven't been completely ripped out or something, they're still there in the same way they were.
I googled "how to jump unity" with older than 2007 and this code still works 7 years later: https://answers.unity.com/questions/30127/how-can-i-make-my-...
Sure Unity added a new Input system, but they don't force it on you, it's not even enabled in new projects by default (probably so you can cut and paste 13 year old code and have it work)
Even Unityscript, the most glaring removal since Unity 1, has an official conversion tool, and deprecation wasn't even started until heavy usage had dropped to under 4%. I actually find it a great example of how to deprecate software gracefully. They waited for usage to fall off, they had excellent reasons to drop it, and they bent over backwards to make it painless.
If you're just doing basic stuff like moving CharacterControllers around and stuff decade old code still works in Unity. Most basic tutorials from back in the day still work.
What broke was fancy shaders that were written back when graphics models we use today weren't even an academic concern... and like you pointed out, that's stuff that breaks as time moves on because it's just not high-level enough to be easy to have work in a backwards compatible manner
Baking work into serialized objects at build time (or dev time) is your friend. You should learn to love it.
There are some terrible things Unity does but loading a large block of prebaked assets is one of the things Unity is fairly good at.
The second installment (already published) talks about some of these best practices, but it doesn't quite dig into architecture just yet.
If you use Microsoft’s DI Extension it gets even easier.
But don't use dependency injection. Unity's Scene/Prefab load/instantiation is already a form of DI. Using another causes issues with juggling multiple lifecycles.
You also lose the ability for Unity to prefetch assets because Unity can't inspect the dependency graph if it's not done through the asset system. Instead you hit situations where you're loading several objects and running DI code over several frames when unity could have loaded everything at once.
I am not a game dev, more app/audio/web, but our app uses Unity for the 3D and interactive video lesson playback parts and recently I’ve been refactoring the video part, which is a perfect candidate for building out with unit and integration tests. It took a lot of digging to work out how to use the Unity unit test stuff effectively as there are really just a few toy examples out there, same with async/await (and the unit test runner still cannot handle async/await in tests!).
I guess maybe it’s a culture thing to some extent, unit testing maybe isn’t as prevalent in games for whatever reason? Once I worked out, as you say, that I could move most of the logic into plain C# classes and test them much the same way I would any old business logic, things became much easier to deal with.
I did think about using DI but in the end found that passing GameObjects in via the IDE and public members as the other comment says sufficed for anything which is a GameObject, and the other (plain class) dependencies I am new’ing up in a top level Manager class and passing down through the constructor, and using NSubstitute to pass in mocks in the unit tests.
I might write up my experience/findings some time when the work is complete.
On the whole, I do think Unity is great, I’ve seen how fast we were able to build out a great looking experience and it’s pretty easy to figure out. C# is a really nice language too. Just a shame that more “modern” dev practices are not actively promoted, and parts like async/await and unit testing seem to be left half-finished.
One thing I noticed from just skimming the tutorials is there is a lot of Unity editor specific creation of stuff. How much of that is the actual game programming? Maybe web dev is headed in that direction if we ever eventually map Figma to components, where you kind of define it via a GUI. Seeing that felt a little off putting since I’m used to working with a tight scaffold that’s mostly code.
Godot looked less GUI intensive so I was thinking about digging into that instead.
I guess another way to pose this question is, do I need to get over this and accept this is how games are made?
I kind of wrote about "keeping it all in code" and why it isn't desirable in the second installment: https://blog.eyas.sh/2020/10/unity-for-engineers-pt2-six-pra...
But once you get the placement / connection / injection right, you'll still be spending the bulk of your non-testing development time in the code editor.
One thing that I am struggling with though is settling on good ideas for general architecture for structuring the logic, and then doing things like communicating between entities/objects in a scalable way. Not everything that needs to communicate exists in a nice parent-child relationship - occasionally you need to communicate "across branches" in a hierarchical tree when there is no other interactions such as collisions etc.
You can get a long way with just cobbling stuff together, but eventually you get into growing pains where it becomes a mess.
The "best" solution I have so far is awkward "god"/"manager" objects that act as glue to let everything access everything. There has to be a better way?
The nice with with Unity though is that the logic is in .NET IL so it is trivial to see how people are doing things and learn.
Don't be too worried about mediators though. Games are a little bit different in that you typically want to act on a shared world. If you have systems that act globally on the world then you're just matching the data that exists. Even the physics system itself is basically a singleton that's mediating interaction.
This can get kind of tricky if you use a lot of procedural generation or prefabs where for some reason you can’t immediately set the reference to that other GameObject (for example, the player has no gun yet). In those cases you should try to set the reference programatically, such as when the Player picks up the gun. You might have a reference from the Player to the HUD, and when the player picks up the gun you set the Gun’s UI reference via some SetUiObject(GameObject ui)
I end up relying on asset-ized SOs to do a lot of this. When communication between any two nodes is mostly one directional, events and triggers work great. (Ryan Hipple has a great talk on this, just search for "Ryan Hipple ScriptableObject".
Try organizing your code around the data your components have to work with and let your code react to changes to that data. Using Scriptable-objects is a great way to facilitate this model, because with them your game components will reference data assets instead of other components, reducing dependencies, which gets harder and harder to manage as the complexity of your application grows.
I can really recommend watching Ryan Hipple's presentation titled "Game Architecture with Scriptable Objects". [0]
At our studio we've built a framework based on these ideas for a high-complexity game project and we're very happy with it so far. We have a clean and well-performing codebase that's easy to maintain and test, because no sub-system has any hard dependency on any other sub-system.
This was useful.
The tl;dr for anyone who can't spend an hour watching (why are so many Unity things done as videos?!?! so infuriating!) is that you use "Scriptable Objects" (new to me - this is a first-class thing in Unity) to store common state and so break statically defined dependencies between Game Objects by having them share the Scriptable Object rather than reference each other.
So you might have a Scriptable Object that contains the player's score/coins picked-up/zombies killed etc. On its own this is conceptually basically just a number/several values/etc wrapped in a small singleton class. You then reference that Scriptable Object in your player game object/script that will mutate that value. Anything else that needs to know the score/coins picked-up/zombies killed (e.g. UI code) references the same Scriptable Object.
So now two separate parts of the game share the state without being statically bound to each other (they are only bound to the Scriptable Object). Plug in as many or as few new components all using the same state stored in the same Scriptable Object and nothing else needs to change as they only share the Scriptable Object. No references to other game objects required.
You can do the same for events - create a Scriptable Object for an event (e.g. PlayerHurt or PlayerShoot etc). Since Scriptable Objects can contain code like any other class, you can have GameObjects register their interest in this shared singleton event by calling "PlayerHurt.RegisterListener(this)" etc, and then have another GameObject trigger/raise/activate the event ScriptableObject ("PlayerHurt.Trigger()" etc). Neither side know about each other, so you can plug in as many or as few listeners as you want. The talk uses some extra cleverness to use a UnityEvent to allow for a function call in reaction to the event being triggered - this means a lot can be done directly in the unity editor, but that seems separate from the main secret-sauce of the scriptable object as the mechanism for shared state.
Site here that basically repeats the video nearly verbatim: https://unity.com/how-to/architect-game-code-scriptable-obje...
Cheers!
Some things I would really like to figure out are some of the idiomatic ways monobehaviors are structured, the variability between them, how best to separate game logic from implementation specifics, and best practices for reusability in real life, beyond what most of the tutorials teach.
Subscribed. Looking forward to seeing the next set of articles!
There are two kind of opposing directions I see a need for:
- "Beginner Unity" take tailored for an Engineer. E.g. let's talk about the input system, frame-rate independence, overview of rendering/lighting, a high level overview of the editor, etc. And get that out of the way.
- Satisfying what I might call a thirst for idioms/best practices from a SWE perspective. E.g. separation of concerns in MonoBehaviors, using ScriptableObjects, etc. Also maybe overview of things like "Should I still use Git with Unity or look into Collaborate?" and the like.
My current sense is that I'll end up toeing the line between these two. But, regardless of this specific series, I enjoy writing about best practices and software patterns in anything I'm working on, and Unity is no exception -- so stay tuned!
What is your take on that?
Still, the game engine market is unlikely to be dominated by a single player anytime soon. I think you'll continue to see something that looks rather similar to the mobile OS space: lots of players, but ~2 dominate the space. Unreal's revenue cut is also a lot more prohibitive than Unity's, so you'll also keep seeing a healthy indie ecosystem (which translates to a community, assets, etc.) in Unity.
A lot of Unreal's recent investments are incredibly impressive. Especially with better rendering and realtime raytracing. But Unity is also making some big investments, DOTS (see https://unity.com/megacity for example) comes to mind in particular.
Unreal is used for on-set visualization (see e.g. the Mandalorian) but Unity is frequently used for pre-viz/planning work because you can just literally drag and drop things in and run them (see e.g. the Jungle Book, from the same director).
i feel the money and R&D that will span from that in the unreal engine will allow them to totally crush unity. already today most of the modern games made with unity are 2d or average 3d games.
Most of the modern games today aren't made with the Unreal engine...For example, among triple-AAA studios, EA, Rockstar, Activision, and Ubisoft all use their own engines (note: Activision uses Unity for some of its games).
Epic already makes a few hundred million each year from Fortnite. The relative pittance they get from Hollywood studios isn't even a drop in the bucket and generally won't effect the pace of development of Unreal, though it has driven Epic to put even more effort into making Unreal a better component in Hollywood workflows. However, this effort won't have much, if any, impact on game production since the workflows are completely different.
Just played Tony Hawk 1+2( remaster by Activision) , which uses Unreal.
It's going to heavily depend on the team and the project.
Generally lower spec games are good fits for Unity, while Unreal is best for higher end ones
> What is your take on that?
I think this year has demonstrated the appeal of games made with Unity - "Fall Guys" and "Among Us" have been very successful over the summer (despite "Among Us" actually coming out in 2018).
I've tried to get started with Unity a few times before and have the exact issues described. I know how to program, just tell me how to do it in this IDE!
I got up and running faster with Unity in 1 week. But after 1 month with each I found unreal to be easier.
A major problem with both is that the learning communities are terrible, because they're filled with wannabes who, while well intentioned, have no idea what they're doing. Question and Answer forums are plagued with dumb questions that aggressively try to assert that they need to know X when actually the problem begins at A, B, C. Youtube tutorials are filled with hilariously bad narrators who spend an hour trying to demo a basic concept and then for unfathomable reasons, do not show the final result before ending the video.
Find a single good set of tutorials to go through the process of making something (anything!) and an active place where competent people discuss things. Googling, unlike most coding problems, is not your friend if you want to find best practice stuff.
For Unreal, I thought this guy was decent: https://www.youtube.com/watch?v=DywBqQtTHMo
I only did the first fifteen or so before I decided to start figuring stuff out on my own. The unreal slackers discord channel is the best place I've found for asking knowledgable folks.
Sure , you can add more scenes . I've never done it to create terrain though. Another trick is to not destroy certain game objects on load.
See “mode” parameter—additive. This doesn’t answer how you unload.
https://docs.unity3d.com/ScriptReference/SceneManagement.Loa...
https://gamedevacademy.org/a-guide-to-handling-huge-worlds-i...
I was using the ECS for the last 2 years, and I wouldn't recommend it to anyone who actually wants to get something into production. My guess is it will be somewhere late 2021 or 2022 before it's actually production ready.