next »

[InfiniteStateMachine]

So I guess the title says it all. I've recently started investigating Unity for the first time since using it in 2012 and never coming back.

Is there any general knowledge a experienced individual might impart to someone just learning the engine for the first time? Could be anything, programming practices, useful hotkeys. Anything that might be useful.

Thanks!

[oahda]

Welcome back to Unity!

Was writing a reply that was basically a list of good to know changes and additions since then but I felt like that didn't qualify as "lessons learnt" so I should ask you first if that's of interest too?

Can't think of many actual nuggets of wisdom besides you probably want to go into the physics settings and uncheck most of the checkboxes in the collision matrix so you don't have more checks going on than you need. And when you create a new project these days there are probably packages preinstalled that you don't want/need and should just remove right away.

[TonyLi]

Hi,

Be prepared to rebuild your project at least once. One of Unity's strengths is its ability to prototype quickly. But it's also Unity's biggest weakness, since rapid prototyping leads to poorly structured and poorly optimized projects. Don't get caught up in optimizing prematurely. Get some things running quickly so you can familiarize yourself with the editor, scripting, and Unity's general patterns. Don't worry about code quality or performance. You won't have good insight into Unity-specific optimization and clean practices until you've played around with it for a while.

Also, bookmark https://learn.unity.com/ -- it's full of tutorials and other learning material. And have fun!

[BorisTheBrave]

Unity is currently in the midst of developing a whole bunch of new features. They are not nearly as ready as Unity claims they are, and you will probably court woe if you use them. I'd skip DOTS and the new render pipeline, sticking with regular C# code and the "legacy" renderer, unless you *know* there is some feature you need, such as Shader Graph.

If you are working on a 2d game and using the animator component, watch this:

. Again, the way the Unity docs recommend is not really the best way.

Structuring your project the "Unity way" takes some practise. Too few components and it becomes hard to customize and share code. Too many and you get bogged down passing messages, events and references between components.

[InfiniteStateMachine]

Hi,

Be prepared to rebuild your project at least once. One of Unity's strengths is its ability to prototype quickly. But it's also Unity's biggest weakness, since rapid prototyping leads to poorly structured and poorly optimized projects. Don't get caught up in optimizing prematurely. Get some things running quickly so you can familiarize yourself with the editor, scripting, and Unity's general patterns. Don't worry about code quality or performance. You won't have good insight into Unity-specific optimization and clean practices until you've played around with it for a while.

Also, bookmark https://learn.unity.com/ -- it's full of tutorials and other learning material. And have fun!

Thanks for that, performance and "doing it the unity way" are definitely a concern I have right now which I'm trying to ignore while I'm still learning the engine.

Unity seems a lot more... loose than I'm used to. I'm doing a good amount of querying and adding of components in various monobehaviors start methods and even sometimes later in the update calls. Definitely feels like I'm doing it ore than I typically do with other engines. The loose-ness is also really neat though, I'm definitely noticing I'm able to prototype faster.

Unity is currently in the midst of developing a whole bunch of new features. They are not nearly as ready as Unity claims they are, and you will probably court woe if you use them. I'd skip DOTS and the new render pipeline, sticking with regular C# code and the "legacy" renderer, unless you *know* there is some feature you need, such as Shader Graph.

If you are working on a 2d game and using the animator component, watch this:

. Again, the way the Unity docs recommend is not really the best way.

Structuring your project the "Unity way" takes some practise. Too few components and it becomes hard to customize and share code. Too many and you get bogged down passing messages, events and references between components.

I googled DOTS and from unity's preview page it appears to be a replacement for gameobject? That seems like quite a bold move if I'm reading that correctly.

As for the 2D animation. Thank you! I watched some other videos on 2D animation and I kept saying to myself "this can't be how people do 2D in unity". It was one of the main reasons I decided to do 3d stuff to learn the engine haha.

Welcome back to Unity!

Was writing a reply that was basically a list of good to know changes and additions since then but I felt like that didn't qualify as "lessons learnt" so I should ask you first if that's of interest too?

Can't think of many actual nuggets of wisdom besides you probably want to go into the physics settings and uncheck most of the checkboxes in the collision matrix so you don't have more checks going on than you need. And when you create a new project these days there are probably packages preinstalled that you don't want/need and should just remove right away.

A list of changes is certainly interesting to me. It's been about 8 years though. It sounds like most of the engine has changed :D

I'll have to look at packages a bit closer. I haven't had to really use them much yet.


Thanks!

[InfiniteStateMachine]

This one just came to me. Is it still true that unity runs on an old version of mono with perf issues related to Linq and foreach?

I've never had Linq or foreach be the source of performance issues when using .net with something like monogame against the .netframework but that's because they've improved the performance considerably since .netframework's release.

I'm not using linq in any tight loops, I am using foreach there. Am I being overly paranoid?

[oahda]

A list of changes is certainly interesting to me. It's been about 8 years though. It sounds like most of the engine has changed :D

All right! I saved the post in my notes app in case you did, so I'll just paste it back (I think some of it might have already been mentioned by others by now):

I think it's worth being aware that a lot is actively happening ATM, basically a new set of workflows being added in parallel to the old ones. A lot of it is being added as packages through the new package manager, and even some old stuff like the sprite editor has been moved to a package so you actually need to install that for a new project if you need it.

For example there are now the new lightweight and HD render pipelines as well as scriptable custom pipelines in addition to the old one.

A new, nicer input system that is able to deal with a bunch of different controller setups and mappings out of the box is available as a package in addition to the old input system, so you might not have to buy Rewired anymore, but it's still WIP.

There's a new "proper" ECS where you can program actual systems to iterate over component types rather than have each individual object carry its own script instance with monobehaviour callbacks, but again you can still use the old stuff. Comes with a "burst" compiler that you might be interested in. All WIP.

JavaScript and Boo are gone! All C# these days, and they're finally staying up to date with recent versions of it.

There's a fancy smart camera system with a timeline editor called Cinemachine that can be useful for cutscenes as well as gameplay cameras.

They added a visual node system for making shaders called Shader Graph. Can still code them up the traditional style too.

HTML5/JS/WASM builds with Emscripten instead of the old Unity web player, yay!

I don't use half of these new things myself for my small jam games, especially since a lot of it isn't fully done and might not work on web, and you might not either depending on the size of your projects, but it's good to know your options.

[InfiniteStateMachine]

Thanks for the info. I took a look at some DOTS stuff the last few days. It's certainly a interesting way to solve locality issues via c#.

One thing I've noticed is that Unity seems to be a lot better at auto-batching than Unreal. Unreal generally will restart a draw call for each actor. Even if it could easily be batched. Unity seems to be a lot smarter. I generated a bunch of gameobjects that each have their own buffers and mesh objects. Coming from Unreal I expected it to generate one draw call per cube but Unity was smart enough to auto-batch it into one draw call.

I guess what I need to realize is gameobjects are a lot lighter than Unreal's actors and they don't necessarily mean a guaranteed new draw call