5 ms·

I finally ditched Unity because I’m sick of compile times in the newer versions of Unity. It’s been getting worse since 2017 or so and it finally got to be too

I finally ditched Unity because I’m sick of compile times in the newer versions of Unity. It’s been getting worse since 2017 or so and it finally got to be too much for me. 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.

Eyas 6y ago
I'll have to check out Heaps. But you're totally right that the "Unity way" of using the editor isn't how a lot of us would naturally gravitate to creating a game. I learned to like it, though (I think). 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.
- learc83 6y ago
  > 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.
  - ratww 6y ago
    Yeah, the usefulness of the editor really depends on the workflow. If you're using procedural generation or using an external tool to design your levels, then the Editor definitely becomes a hurdle.
thurn 6y ago
Huh, I've always found Unity orders of magnitude better than something like Unreal, never seen more than 10 seconds to compile which seems quite reasonable to me. (You do need to turn off Auto Refresh though, no idea why they think having that setting enabled by default is a good idea.)
- learc83 6y ago
  It's a problem that many people on the forum complain about. It's mostly based on the size of your codebase (plus other assets), and which version of Unity you're using--newer versions have gotten much slower. Using the new DOTS stuff also increases it pretty dramatically (they say they are working on fixing this). 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.
datalus 6y ago
I've heard horror stories of trying to develop a game and also maintain an up-to-date Unity install. AFAIK it's best to just live with whatever Unity version you've started your game in and be careful of upgrading point releases and avoid upgrading to any major release. 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-heaps-game/ https://deepnight.net/tutorial/using-my-gamebase-to-create-a...
- BoorishBears 6y ago
  How is that any different than the average game engine? 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...
  - vvanders 6y ago
    It depend on if those features coming with major versions include one of the platforms you intend to ship on... 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.
jayd16 6y ago
>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. 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.

Eyas 6y ago

I'll have to check out Heaps. But you're totally right that the "Unity way" of using the editor isn't how a lot of us would naturally gravitate to creating a game. I learned to like it, though (I think). 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.

learc83 6y ago
> 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.
- ratww 6y ago
  Yeah, the usefulness of the editor really depends on the workflow. If you're using procedural generation or using an external tool to design your levels, then the Editor definitely becomes a hurdle.

thurn 6y ago

Huh, I've always found Unity orders of magnitude better than something like Unreal, never seen more than 10 seconds to compile which seems quite reasonable to me. (You do need to turn off Auto Refresh though, no idea why they think having that setting enabled by default is a good idea.)

learc83 6y ago
It's a problem that many people on the forum complain about. It's mostly based on the size of your codebase (plus other assets), and which version of Unity you're using--newer versions have gotten much slower. Using the new DOTS stuff also increases it pretty dramatically (they say they are working on fixing this). 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.

datalus 6y ago

I've heard horror stories of trying to develop a game and also maintain an up-to-date Unity install. AFAIK it's best to just live with whatever Unity version you've started your game in and be careful of upgrading point releases and avoid upgrading to any major release. 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-heaps-game/ https://deepnight.net/tutorial/using-my-gamebase-to-create-a...

BoorishBears 6y ago
How is that any different than the average game engine? 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...
- vvanders 6y ago
  It depend on if those features coming with major versions include one of the platforms you intend to ship on... 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.

jayd16 6y ago

>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. 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.