Fragmentation and future proofing: Which packages should I use for a new project?

I'm considering trying out a 2d project in Unity. Before I've even gotten started I've run into a difficult problem. There seems that there's a lot of fragmentation in the packages available from Unity right now and I'm not sure which ones to use!

The primary concerns about picking packages for a new project are:

1. I don't want to incur a lot of technical debt by using deprecated APIs. Writing some code only to need to tear it down and rebuild it in 6-12 months because the "official" API has changed would not be very fun.
2. I'm concerned about encountering impassible problems due to missing features in newer packages. It seems "preview" means something closer to "experimental -- absolutely nothing is nailed down, this is missing most of its features and may be removed or changed entirely"
3. I want to do a small (download size) mobile/web first project that starts up very quickly. This pushes me toward newer APIs but I haven't been able to discern if/when they will be in a usable state. I'm unsure from searching if "small and fast" is possible at all with the "classic" Unity packages.
4. I don't want to waste time learning the intricacies of the older packages if they're going to be completely obsolete soon.

A few particular confusions I have about the current packages:

At the highest level I'm confused about the new ECS system vs classic OO system. I have several questions about it, the waters appear very muddied here.

1. The ECS system appears to be part of the DOTS and Project Tiny initiatives. Is that correct?
   
   
2. The ECS/DOTS/Tiny system is incompatible with almost all existing unity features and 3rd party packages. It appears to be at an alpha level of completeness and is missing many core APIs at the moment, not ready for "real" use, correct?
   
   
3. There is also some reference to a hybrid ECS system but I can't tell what that really entails. Does that approach allow for writing forward-compatible games while still leveraging all "classic" features/assets/libraries?
   
   
4. I'd like this project to start quickly, have a small bundle size, and run on the web in addition to mobile. DOTS/Tiny seems to be all about this but not quite ready to use yet. Is the classic/OO system capable of producing small quick games for web/mobile or is Unity constrained to "heavier" experiences until DOTS is ready?

My project will likely be UI heavy. There seems to be several UI options built into Unity but I can't get a clear picture of their completeness or benefits and drawbacks.

1. UI Toolkit appears to be the "new" package similar to ECS/DOTS but it's hard to gauge its maturity. Is it usable for real projects?
   
   
2. There seems to be no plan or mention of making UI Toolkit compatible with ECS/DOTS. Is UI Toolkit actually the future-proof UI framework or is it likely to be abandoned in favor of something new for ECS/DOTS?
   
   
3. Most existing assets won't work with UI Toolkit, correct?
   
   
4. Is using the older Unity UI still viable? Does it contain glaring flaws or performance issues that make it less suitable for use since it's no longer actively developed?
   

I'm drawn to Unity by the size of the community and the resources available but it seems that the platform is totally in flux at the moment. It seems likely to me that any project started now will suffer from either outdated API usage and technical debt or run into unsolvable problems due to missing features in the new APIs.

Which packages/APIs would people with more Unity experience recommend for a new (small, fast, 2d) project?

Thanks!

 

good luck. i dont think youll get anything useful. its a crap shoot

 

Pretty much this. Most of your questions are unanswerable based on history. And any that are, are completely subject to change. "Future Proof" is simply not a term that applies to anything when developing with Unity.

 

I stumbled across this unfortunate image



Jokes aside, I don't mind using the "legacy" systems if they're capable. My big concern there is that I want to make a small/fast mobile/web game and I haven't been able to determine if the classic tools are capable of that. Searching turns up very little. I would be a shame to put in weeks or more of effort learning the basics only to find out that there's no way to make simple 2d games that load quickly on modern devices. ECS/DOTS/Tiny look like they are going to be great but I get the sense that they're 2+ years away from a stable release with full features.

 

Current fragmentation is an illusion right now. If you want to do a short term project (less than a year), you need to behave like Entities and co. don't even exist (you can use jobs and burst though). Don't look at them. I said No!
If you have a lot of time and you're willing to create your own <del>adventure</del> sub-systems, like animation and whatnot, then yeah, good luck, just do it.

But you opened with the statement you're not willing to have technical debt. I don't think it is possible. And never were.

You're out of luck then. Learning is never a waste of time. Besides the same people made the new systems as well, a lot of things are in common.

Yes.

Yes and no. Job system and Burst compiler are parts of DOTS and they are absolutely ready. ECS is not.

Hybrid is when you write your main code in ECS/DOTS and whatever is missing you solve through communicating with game objects. It will slow down your application a bit, but when Unity rolls out such feature you only need to rewrite that component. But since you stated you don't want any technical debt...

Use project tiny and roll your own stuff whatever is missing.

Everything is usable. It's a new package, especially for run-time. Probably contains unexplored bugs as every new software does.

There are plans.

There is no such thing as "future-proof". It's a new package, I think it is here to stay.

Depends on the asset.

Why wouldn't be? Countless games were shipped with it.

Yes, but luckily you can avoid them if you know what you're doing.

It is not. There is an open development of new things. Do not look at them. It's not for you. It is for future you. Period.

 

Not unwilling, just would like to avoid it if possible and it's currently not very clear to new users what the situation is in that regard.

How do I figure out which preview packages are usable and which ones aren't? You're recommending Jobs which is preview but not entities. What bout UI?

edit: you edited and answered most of my questions while I was typing this, thanks =)

 

You try them out and play with them. It is time consuming, if you have a deadline, forget every preview package. If you are in doubt, forget it.

Jobs are in preview but are in a very good shape. But if you're in doubt, forget it.

I think I wrote about both UIs too. Which one?

 

You mean the classic tools that have been used for years by countless developers to create mobile games?

 

Hello, and welcome to unity

Have you tried looking at Godot, it is pretty much perfect for 2D games, with perhaps the exception of some of unity's advanced 2D lighting solutions.

 

Absolutely, I know that tons of excellent mobile games have been shipped with Unity over the years!

I'm uncertain about the specific case of creating a game with a small download size (let's say < 20mb) that loads very quickly on mobile and web (let's say ~2-3s from opening tap to gameplay on modern devices). The overhead imposed by the "classic" tools may make them unsuitable for this requirement but I haven't been able to figure out yet if that's the case.

Given those requirements it seems that Tiny is what I want. Given the very-alpha nature of Tiny I think I might be better off trying a different "lighter weight" engine like Defold for this project. That definitely comes with its own set of tradeoffs however -- tiny community, less features, not many prebuilt assets for rapid prototyping, very few libraries to lean on with Lua, etc. Godot is also interesting but again, tradeoffs -- no commercial support, tool-specific scripting language, smaller community, no asset store, etc.

Tough choices when considering which tool to spend hundreds or thousands of hours working with. It's painful to pick wrong in those situations -- I had the misfortune of working on an AngularJS 1.x project once.... it was the wrong choice.

 

Monetization is exceptional in unity,what type of 2D game is it?

 

Not a traditional game, but a gamified version of a productivity app. I've built a prototype with React Native which is very good for the "app-ish" parts but absolutely painful for the animated game-ish parts. I'm investigating game engine options to determine if it might be worth it to build a future iteration on a game engine instead of React Native.

 

Hehe well angular 7 has better dependency injection and observables but since learning vuex with vuejs, I haven't looked back.

I guess, it depends on animated game-ish parts. I mean, if you are talking full 2D physics engine, then you'll need something like unity / godot etc.

There's unity UI is to be more like flexbox and bootstrap based but not sure.
https://docs.unity3d.com/Manual/UIE-LayoutEngine.html

Spoiler

 

I just started learning Unity last month and ran into the same problem. I will tell you my conclusions and hopefully someone will correct me if I'm wrong:

User Interface

There are three options:

• IMGUI: The oldest and slowest. It is now only used for modifying the Editor. Do not use in your game.
• Unity UI, also called UGUI: The standard for a long time. Use this. The documentation is external for some reason.
  
• UI Toolkit, formerly but also sometimes still called UIElements. This is new. It is not well documented or easy to use yet. It does not yet have all the features of UGUI. It has bugs. In the future, there will be more tools to make it easier to use. Do not use this yet.

Conclusion: Use UGUI. UI Toolkit is too far off and too incomplete to make it worth learning right now. It looks like the workflow will change, because (1) new tools will be created and (2) some current workarounds will be superseded by actual features.

This is too bad, of course, because it means that we must learn UGUI, which is a difficult system, even though it will be deprecated in a couple years.

Edit: Related to this is TextMeshPro, which is used for UI but can also be used without using UGUI and canvases. For some reason, TMP's documentation is external. The Unity landing page is here but it will tell you to go here for the actual manual.

Animation

There are five ... systems:

• "Legacy" animation: This uses the Animation class. It is fully deprecated. Do not use it.
• Mecanim: This mostly uses the Animator class. An animated GameObject must have an Animator Component, which you assign to an Animator Controller asset, and you put Animation assets into that Controller. This is the current, standard method for animating 3D models or 2D graphics that have bones, as well as spritesheets. Use this.
  
• Anima2D: This has been the standard system for creating Animation assets by rigging or adding bones to 2D graphics. It is now deprecated.
• 2D Animation Package: This is the replacement for Anima2D. Use this for rigging 2D graphics. Its documentation is here. You will want to download the 2D IK package, which is in preview.
  
• Unity Animation: This is an experimental system built on the new DOTS core that, from the description, will apparently replace Mecanim, Anima2D, and the brand-new 2D Animation Package. It's not ready to use yet.

Conclusion: Use Mecanim (Animators) and, if you're rigging, 2D Animation Package, and the 2D IK package.

Render Pipelines

There are three options here: the built-in pipeline, and two "scriptable render pipelines": the Universal Render Pipeline formerly known as the Lightweight Render Pipeline, and the High Definition Render Pipeline.

Conclusion: I'm ignoring this. I have enough to learn so I haven't touched this, which I assume means I'm using the built-in pipeline. Pictures appear in my game, so it must be working.

DOTS

DOTS is an umbrella term used for multiple new core processing systems. It means "Data Oriented Technology Stack." It includes (1) the ECS system for a different architecture paradigm away from objects and components, (2) the jobs system, for putting tasks onto different threads and allow great control over multithreading, and (3) "burst" functionality. It looks like there are a bunch of other packages too.

It's not yet ready unless you very much know what you're doing. There will apparently be more features and tools for using the new systems. I believe you can use some of the systems piecemeal right now, like jobs and burst, without having to adopt the whole "stack." Maybe Unity will just integrate some of this to allow the improvements without adopting the ECS architecture and workflow. There are minimal documentation and learning resources, particularly compared to the 15 years of learning resources we have for "normal Unity."

Conclusion: I'm ignoring this too. If I ever run into a bottleneck or need to do something resource-intensive like pathfinding with many things at once, I'll look at jobs and burst. Or, more likely, use someone else's solution that uses jobs or burst.

Finally, be aware that there are systems you probably want to be using that must be obtained through the Package Manager. Some are in preview. When you open the Package Manager, click the Advanced pulldown and enable Show preview packages. I am specifically thinking about the 2D packages. 2D IK is still in preview.

And a question for experienced users: I thought I read a post on these forums that said if you do ... something simple, check a box or just import a package or something? it will enable one of Unity's newer systems and provide a performance boost. I can't find the post again. Maybe it was the Burst package which we should download? If anyone knows about this, please let me know. Or maybe I'm making it up.

 

For a 2D project today, use URP with Unity 2019.4 (LTS). And use the usual game objects for now. Don't use DOTS for 2D today.

 

With usual game objects do you mean sprite-renderers etc. or just using textured quads and handling everything from sorting to animation on your own?

 

No, irritatingly, despite the 'verified' status of the URP, some parts of the 2D stack are still experimental now.

Specifically, camera stacking was broken until the June 5th release last week, it's currently not clear what else might be broken, but some things (shadows) are still 'experimental' despite being inside a 'verified' package.

This was particularly poorly done on Unity's side, and breaks pretty much all of the communication of 'verified' vs 'preview' packages, but it is what it is.

tldr; dont use the URP for 2D projects at the moment, unless you accept the same caveats as all the other preview packages. eg. the job system. It's 'pretty good shape', but not stable.

 

Actually the Job system is a very bad example, it is stable. That's why I even brought it up as possibility.

 

I mean, you're probably right. To be fair, it basically is stable, there haven't been any major API changes in a long time. (For anyone who wants to see, look at the changelog).

...but it's a preview package, so there's no guarantee the API won't change.

On the other hand, the URP is 'verified', and there's no guarantee the API won't change (in fact, it almost certainly will, if you read the 2D forum).

It's probably more meaningful to tell people; look, forget it. Your packages are going to change over time, and it'll break stuff. If you think using only 'verified' packages will save you from this, you are mistaken.

Tough. Luck.

Here's a link to the changelog for the package you're looking at using; you decide if that API change cadence is suitable to your project or not.

Those changelogs are generally available here: https://docs.unity3d.com/Manual/PackagesList.html

(Click on the packages menu on the left, find your package, click on it, open a version (it doesn't matter which version), then look for a 'Changelog' entry on banner at the top of the project page. If there isn't one, well, you're screwed I'm afraid, some packages just don't track that)

The change log will tell you:

- When the package was last updated
- How often the package receives updates
- How significant those updates are

This varies wildly across packages, regardless of the 'verified' or 'preview' tag.

Basically; do your due diligence before using a package. /shrug

...but also, seriously, the experimental stuff in the URP for 2D is just a super screwed up surprise for people after they've gone and done their investigations. That's just rubbish. It should have been a separate package. All we can say is that's a legacy cluster-F from poor initial planning of packages, which people just have to live with.

 

For input, use Input System. Yes, it's in preview now, but it's very close to completion and will be verified on 2019.4 LTS after it's verified on 2020.1 (check the 2019 LTS thread for proof). Unity removed the resolution/rebinding dialog from 2019.3 so the old Input Manager has no way of rebinding keys anymore, so your only way forward from here is to use the Input System, which is honestly already better in almost every way.

 

Thanks for all the thoughtful responses.

It seems like the answer to "which packages are the right ones to use at the moment" boils down to "there's no good answer, unity doesn't give us enough information, you have to spend time with each one to figure it out yourself".

That's a bummer but it is what it is. Can anybody shed light on Unity's capability to make very small and quick loading builds for web/mobile? Is it possible to keep sizes < 10-20mb and load times < ~3s for a hypercasual or even playable ad scenario? I know Tiny is focused on enabling that, but can it also be done with the existing mature tools or do they impose too much overhead for that sort of project?

 

If you want it that small, then project Tiny is really the only way to do that properly.

 

I second this. I just spent the past couple of weeks playing around with different ways of using the new input system and all of them are fairly straight forward and flexible with the easiest being a single line of code and the hardest being around a couple hundred if you need multiplayer support.

That said rebinding has always been available if you were willing to build a framework on top of the input system which is what I did prior to the new input system.

 

Tiny isn't in a usable state at the moment, it's still in early preview. Honestly I wouldn't recommend Unity for quick loading web games, I'll use PlayCanvas instead, until Tiny comes out.

 

Really good post. A more detailed version of this post is exactly the sort of breakdown the Unity team/developers need to give about the systems in Unity. It would be so helpful to newcomers to Unity rather than having to piece the information together yourself from hundreds of different bits.