Whats happening with Unity development?

Hi All,

I've been working with unity for about 3 years. I am a personal user and currently been experimenting and learning hoping to take a dive into making a real game in the future. I knew this would take time, lots of time, so I decided to invest into learning the cutting edge. I have worked with the Entities, NetCode, Physics and UI Elements packages however as I learnt how to use them I reached a point where my demands for those packages was beyond the level they are developed to.

So I've had a break and come back and to my disappointment there is very little progress. Things slated to be out of preview early this year have been put off for another year. I just can't use these packages and have to wait.

My questions are really to Unity, but I don't expect an answer, so I ask here for a community perspective so I can make an informed decision as to what I do from here.

Whats happening with the development of Unity Engine and these once cutting edge packages?
Has development stalled?
Can I expect the pace to pick up or is it only going to get slower?

There's been a severe lack of communication from unity and new API documentation is appalling. Bugs reported for latest alpha release use to get responses in a day or so, now I get a message months later asking me if the latest version resolves the issue, by which point the project I was working on no longer builds with the latest release.

I know C++ so I could switch to Unreal, but I have become really proficient in C# through my learning Unity Engine, so if I have to switch I see it as a massive waste of time invested and would mean another massive investment to be made to learn how to use Unreal Engine.

Thanks for your input!

 

I'm not sure that things have actually slowed down significantly, but I think it's fair to say there's been some um... overwhelmingly negative responses to the way preview packages have been handled.

The outcomes of that appear to be:

- the ability to install preview packages is being gated by hiding the options away in the project settings in 2020
- the 'develop in the open' model that was tentatively embraced is being rolled back to a closed doors approach

Long story short; don't expect anything any time soon, the timelines do seem to have been pushed back somewhat. ... but... probably don't expect to hear anything official any time soon either.

I expect we're heading back to a more closed doors approach where you don't hear anything until it's released; I expect, as you've noted, the 'develop closely with the community' collaboration you had before is largely wrapping up and going to go away.

 

Well, people are using preview/cutting edge packages and expecting them to work, for some reason.

I don't see how Unreal will help. It doesn't have any of those things you listed.

All Unity games in existence were made without DOTS, UI Elements, etc. I'm sure you can manage without them.

 

Unity is fine if you use the old stable stuff. Ignore preview and unreleased packages, ignore new features that are not battle tested or documented, and avoid UNET.

I would also say avoid SRPs too if you dont want headaches, regardless of what is being said publically, they are still going through significant churn.

As @Stardog said, all unity games that have been successful are made without all the fancy bells and whistles that are currently in development, so you dont really need them!

 

Three years at an hour or two per day is sufficient in my opinion to learn both the old stable approaches as well as the new cutting edge ones. One problem with the cutting edge is that they undergo massive changes to its API over the course of its development making it not worthwhile to learn until it's nearly done. Meanwhile the old stable APIs have barely changed.

 

Thank you for the responses so far.
I did start off learning the none DOTS framework. It seems my expectations for these preview packages was perhaps a bit over optimistic, and perhaps Unity was over optimistic in the time-frame it could be delivered.
After messing around with those preview packages, using the standard approach is so much easier. I may continue my development without entities and associated packages for now and perhaps use bursted code when needed. I am keen to continue using URP because ShaderGraph is excellent, so hopefully not too many headaches there.

 

Oh! If you are a programmer, don't switch to Unreal or you will regret it. Very much. I came from Unreal, and I live happily here.
The waste of time will be when you have to wait for 30minutes to compile your project, that if you want to create a simple shader in code you will have to write a loooot of code, and people will not understand when you say that Blueprints are a very bad way of programming efficient stuff.
Nobody will listen. And people will keep saying Unreal is great and the graphics are amazing, but all Unreal games look the same. Because to use Unity you need to know graphics, know a lot. Its obvious. The same way as if you want to create great things using Houdini. You need to know your stuff. Nobody is going to do it for you without a price :-D

 

Actually it takes me 17 minutes to rebuild the entire engine. Usually, under a minute to compile change in the commonly used header. Few seconds to recompile change in .cpp with engine/game running with Live Coding.

Compilation times on different machines would vary, but 30 minutes for compilation projects would require some ancient machine and heavy code changes like refactoring half of the project's code. While your post makes it sound it standard "30 minutes", every time on average PC

It's quite rare to write shaders in code since there's the material editor, this what's mostly used for shader creation.
And Blueprints are like every other programming language - it's perfectly fine if used by a competent person

UE4 games don't look the same, this statement is so false... I don't know even where to begin to say "mhm, nope? let's check a few games"...

Your opinion seems to be heavily biased. Please, don't spread misinformation

 

Here is a link to the thread about changes to visibility of preview packages in Unity 2020:
https://forum.unity.com/threads/visibility-changes-for-preview-packages-in-2020-1.910880/

 

Haha, that may as well say don't switch to C++ ... It's been a long lasting and popular language but is fundamentally flawed to enable production of buggy code with ease.

Anyway switching something I want to avoid, in fact I'd rather switch to godot and use Rust with that if I was to switch. But really I find C# and the Unity platform a breeze to work with. With a standard project it's easy to get something up and running without much ground work.

 

This may be silly to some but the deal breaker for me was not having the z axis be the forward axis. That would be two decades of using Cinema 4D down the tubes. Unreal was set up to be a 3D Studio Max import pipeline. I have grabbed some free assets from the Asset Store..characters.. and went to edit them for usability and was like..crap..adjusting simple animations and accommodating the rotations was a small nightmare of WTF to where just creating my own was a time saver.

 

People should understand that developing RELIABLE software takes HUGE amount of time. Especially that last "polishing" phase may take many YEARS. I order to have a good experience with Unity use only those APIs/features which have been tested/used by dozens of professional quality, shipped games. Avoid everything else. Basically DON'T be an "early adopter" because it will cost you a lot of pain and problems. Instead be VERY conservative with your choice of tools. Use old and reliable solutions and avoid most novelties.

 

We are really going through big changes in unity

From what I see, unity wanted to change everything at once which ended up giving several problems along the way. That is why the next 2020 versions are being focused only on correction and performance improvement.

Of course last year (or 2018) they showed everything they had in mind, but unfortunately they underestimated the time needed to make it happen. and I don't blame them, the new pipelines, DOTS, shader graph, VFX, 2D tilemap, and a lot of really interesting stuff. as for example the packages, we can finally create mobile games with 5mb to 10mb at least, which is fantastic.

So I wouldn't say it was a regression, but a change of focus, I look forward to the corrections, and the news. But they are not as close as most people expect.

For example:
Native Bolt 2 (Blueprint cries lol)
Global illumination in real time (Only arrives in 2021)

What the community doesn't like is unity's delay in releasing packages in preview. but ... I use a lot in previews and I almost never had any problems with them ... I'm not afraid of getting stuck in something that is buggy (Often it is just exporting the project to the next version that the problem is simply solved, because I don’t know, but it’s like that) And I’ve never had any problems with SRPs either. I know some of their features are not yet ready, but they are usable, so why not try?

unity is changing, that doesn’t mean you can’t create games with the old tools, but it’s also an opportunity to try something new. It would have been worse if the unity had been left behind without innovating at all.

Sorry about my English

 

Unity is notorious for missing expected or implied dates for big feature upgrades. It is best to only experiment with preview or still in development features to see what you might be able to do in the future, but for serious projects stick to what's currently stable. Don't make your project depend on Unity hitting a release date for some new feature development.

 

Blueprints have some valid use cases, such as quick prototyping of ideas and one-off level scripting, but writing core gameplay code in a visual scripting language seems like a terrible design decision.

 

Yes. You can say it about every single programming language "X has some valid uses cases, such as [here list it], but it's not designed for [here another list]". Especially if the given environment provides more than one way of programming (which Unity also provides through plugins).

So... I'm not exactly sure what you actually replying... A competent developer would be aware of what you said and would use proper tools as they were designed.

Previously I only replied to a harsh opinion "don't ever use engine X, it's terrible because some people abuse some functionality". It's like me saying "Unity is terrible, don't use, I've met people who write awful and inefficient C# code." (and I had to rewrite the entire systems after them although I wasn't formally hired as a programmer)
Cpt. Obvious enters the scene: people write terrible things in every possible language

C# or blueprints are these things that make both engines easier to use for so many people. Both of these environments aren't perfect from a performance/design point of view and code written by people working exclusively in these environments is usually slower than something written in asm

End of Cpt. Obvious

 

I didn't comment on the performance aspects of Blueprints or the quality of code you can achieve. As far as I know, both Blueprints and Unity's C# API are optimized well enough, that there would not be a huge performance win in using C++ in anything other than some hot loops. And I agree that you can write good or bad code in any language.

Maybe I'm interpreting too much into your original comment, but "Blueprints are like every other programming language" to me implies that it's a valid choice to build an entire game with. This is what I disagree with.

Unreal developers like to claim that you can implement anything in a Blueprint. This may technically be true, but you're just making your life unnecessarily difficult. With a visual scripting language you are mostly stuck with whatever tools the creator of the language implemented. When you write code, you can use anything from Notepad, Vim, Visual Studio.

Everything is more difficult and tedious with a visual scripting language, except maybe the initial quick clicking together of a prototype. Structuring, maintaining, refactoring, testing, reviewing, merging are all more complicated. Not impossible, but more inconvenient and slower.

 

Dude. People published successful games even with Playmaker. Which is a significantly slower and dumber version of Blueprints in Unity.

There are many projects, where the speed isn't the main factor. Obviously you won't ship an e-sport title with it, but it is perfectly good for VN or a PNC or even for a platformer and for many other genre.

 

Where did I say that Blueprint code was slower? I explicitly wrote in my first paragraph that in lots of cases the performance difference is probably negligible.

The part that you quoted I'm talking about different aspects of development that I find to be slower and more tedious with a visual scripting language.

 

Nope, only meant that every language can be used poorly by someone who doesn't understand it. And can be awesome if someone used for what this language was designed

To be more precise, this is mostly what Epic's marketing does in a post on the official blog and many "engine feature" showcases. They repeat "Make games without coding! Blueprint it's not programming! Entire games can be done in blueprints". That not only the fault of their marketing, there are also countless resources on the internet that would say that "visual scripting it's not programming"...

This leads people to naively believe that they don't need to learn anything about programming, its concepts, best practices, code architecture, how computers actually work...

On another hand, it's also not 100% true that making the game only in blueprints is "making your life unnecessarily difficult" - if you don't know a thing about traditional programming and you would never start making a game if you would have to learn C# or C++ quickly. In this case difference between "created nothing" or "created mechanics/game, perhaps not by using the best possible tools, but this work".

Teams should have at least a person as a programmer, so they can mix these languages properly. Making informed decisions "should this in C++ or blueprint" instead of relying on blueprint only. The thing so many solo devs and people learning engine doesn't have a comfort of hiring programmer or becoming programmer while making their first, relatively simple game

 

Yes, I'm sorry, I have cut half of my previous post because I had to leave for a bit. I assumed that what I wrote so far covers more or less the subject at hand, I was wrong.

What I also meant to say, that VS is perfectly capable of serving as a programming language. The fact that you find it hard to maintain or decode, doesn't mean everyone else experiences the same.
I personally hate VS-ing, I'm a software developer, normal people are writing their code, not clicking together.
But I also recognize that many people do not want to learn the syntax, the keywords and whatnot and they also better at recognizing shapes and structures as opposed text lines and functions.
(There are some studies, BTW, that many developer also recognizes parts of the software by the shape of the code and not by reading it through when they are looking for specific things - although I find it believable, I'm not sure if this is legit, that's why the side note)

And plus add the performance question what I already wrote. So VSing is a perfect tool to build an entire game in it if the game is certain type. Which people are actually doing in real life already. So saying that VS isn't capable or more difficult (if it were, those people wouldn't VSing at the first place) or tedious.
They are, for you and me, but not for everyone. This is why these blanket statements are always false.

Hope I could make my answer more round this way and I actually included my argument this time.

 

- About the time span of building, you're right. Not always that much until your project grows, I'm talking about the size of a decent big project. I've met people who worked on a very famous game that I don't want to mention here. At the time where they were working with Unreal and they said they were on the verge of suicide related to this. In my case, it took a long while to compile a simple change, to the point that they had to get outside to get a cofee everytime.

- I work on high performance code optimizations. That's why I'm probably biased. In that case, nor blueprints, nor material editors, can make a coded shader as fast as it is with written code, and no blueprint can create the code that is executed millions of times in a frame as fast.

- About the language. I prefer c++, by far. C# is easy to use and learn, and easy to misuse. Very little control over memory.

- I don't agree with you I honestly think most unreal games look the same because people love their default postprocesses and leave them as they are. But I'm talking about the vast majority, not AAA games, unless they heavily tweaked the graphics, which most people don't do, because Unreal gives them enough good looking graphics by default. I can tell by looking at a gameplay for seconds. But sometimes I'm wrong.

I'm not biased, seriously, I tried really hard to work on Unreal and I did for more than a year, and It sucked big time. Seriously. It's not made for programmers. But what turned me against it and made me move to Unity was the terrible management of the marketplace they released. I talked with them for a long while trying to find a way to make it work, and it didn't. Plus, it takes minimum 1 month (they just review assets once a month, or that's what they told us at the momento) and people complaining it could take up to 6 months to get an asset accepted. Hopefully they fixed that already.

 

Yep, it was inferior initially. At some specific UE4 release, it took like a month to verify all code plugins and make them available for this new release. I remember buying one plugin again on Gumroad - to just get a recent version
- Epic did finish automated pipeline for that soon after this, it works smoothly now. You could update your engine with the plugins day or two after a major release. (if project is small enough to get engine before the first patch).
- Not sure how long it takes to process new assets, but they see people complaining about it on forums/discords anymore.
- UE4 community grew much since 2014, so got a more profitable place for asset creators. Especially that's a very little or none work needed to update assets to the new engine versions. Obviously, sometimes there's more work needed to update a code plugin, but mostly a few minutes to compile plugin from the older engine version.

I only miss the wishlist functionality from Unreal's marketplace right now...

Nobody should expect some cloud repository/CI solution from Epic though, it that's important.

First, thanks for the long reply. I hope you would read my reply as pushing the discussion forward than some critique. As every team should choose matching technologies for a project, instead of discarding it before evaluation - so I always see discussions on public forums much valuable for less experienced people

Well, I'm aware that programmers are usually the only group of developers that often don't instantly love the transition from Unity to Unreal. Or just using Unreal instead of Unity. Especially if they used to programmer-heavy team workflow/structure.

Personally, it difficult for me to spot a huge difference.
Unity C# was actually super-annoying for me a few years back
- missing incremental code compilation and simple change actually also took too much to compile - supposed solved by now
- requiring compiling code on non-programmer side
- super-slow starting a game in editor once a project grew up (while usually instant in UE4, if a team didn't mess up something) - also improved in one of the last releases?
- not fan of environment that allows for ignoring hundreds errors on calling a function on invalid references/objects...

Although long compilation times in any engine should be less an issue if using modern CPUs. It was a pain indeed for any engine in times of Core Duo, indeed

If you use used UE4 a long time ago, you might encounter few issues that are (mostly) solved now
- IWYU (Include What You Use) and few more build settings set by default, so compiling many/huge modules would be faster
- Making Unreal Header Tool running parallel (it happened often that it took around 60 seconds before starting compiler itself) and other UHT/UBT optimizations
- Introducing Live++ which make compiling changes in .cpp super-fast and stable while running editor/game, which finally allows to freely mess around in code, quickly check few versions of function.
- Hot Reload was always in UE4, but the biggest bugs (causing occasional data loss) are marked as fixed in 4.26 - I guess that's important for people who hate restarting the editor. (I don't care since it happens rarely during a day and engine loads so fast, even the big production map)
- Modern C++ tools like Resharper++ come with actually working code inspection. It instantly highlights a lot of actual errors in my code, so it lets me fix many compilation errors before calling compilation. While Intellisense for C++ it still a non-functional crap and it's best to disable it entirely

Another important note. I'm very focused on workflows allowing the entire team to work/iterate super-fast. Programmers are just a part of a team and serving as support for all other people. From this perspective it was weird to read "don't use Unreal, it's hell" like it would be bad for everybody...

TL;DR
It's not like is wise to let not-very-technical people go wild with their toys without supervision. Only the way of "overseeing" is different. In AAA in-house engines and Unreal, it's shifted from "do everything in code, control everything" to "provide tooling for everything, give freedom to non-programmers, but don't trust them entirely".
- In Unity, you'd hide everything you can in code - super-convenient for a skilled programmer in the team when programmers have a lot of time to spare (so they can quickly make requested adjustments). That's just often terrible for other team members. Although much better than a lot of (most of) smaller in-house engines, i.e. in Telltale they used to have "content programmers" - programmers would simply read a screenplay of the game and basically hardcode, since there were no tools for designers and writers to implement on their own.
- In Unreal you expose every system you can to proper visual tools. Everybody is able to prototype, experiment and implement a lot of ideas/screenplay/levels. It's just team should have somebody in the role of a technical artist, technical designer. Following the rule: "trust, but always check". Or it's like police in a democratic country, allowing people to do their things, but just correct the bad behavior

- The speed of executing blueprints usually doesn't matter - no noticeable performance penalty, unless someone would put heavy operations on Tick. But that's issue of every realtime engine if abused.
- The biggest problem of blueprints is lack of proper education - this is the language used by people not exactly knowing what they're doing. And I observe that full-time programmers in a team often choose to totally ignore teaching blueprint people basic things. Instead of they just wait to drop napalm on blueprints and rewrite systems to code once blueprints are already a huge mess and it takes a lot of time to refactor it - because the script is messy and difficult to understand.
- And that's what I see as a big issue here, ignorance on side of designers and programmers. Although the list of major performance traps in blueprints is really short and I compiled to the single wiki entry. Slower performance of scripting isn't usually noticeable if a team doesn't try to do everything in blueprint without competent technical people. Or a game is simple enough.
https://www.ue4community.wiki/Fundamental_Blueprint_Practices
- If C# would be a scripting language for designers in UE4 (or any other engine where C++/Rust is an engine language), I bet C# scripts would be much less performant because of wannabe-programmers would write scripts without understanding the programming..

Moving the majority of blueprints and materials to code is a waste of time on many projects. Performance gains are very often negligible, but it takes a lot of time and disallows people to tweak every second and every square inch of the game, which is the major advantage of UE4.

I admit I do try exposing only needed things to scripting - especially in multiplayer game. But that's for better workflows, saving time on implementation and making systems easier to maintain. Many designers love to make a mess with every feature they touch, totally ignoring things like proper encapsulation, code architecture, etc.

I guess Unity will see a similar set of issues once native visual scripting will be added to the engine and immediately widely used.

The same goes for shaders. To some extent, at least. Artists sometimes try to make the entire "shader-rich" game without learning anything on how rendering and GPU work. The reason for creating too many unique shaders, going crazy with amount of instructions in the single shader. Or simply relying on difficult post-process settings, quite often the last thing after assets are largely done...
For me, most of the Unity games look the same - to simple/primitive and primitive lighting to bother and play such games. Uber-shader gave me cancer

That's definitely a huge benefit of having a technical artist in the team if many artists are allowed to create their own shaders. It bit another workflow than programmers having control over shaders. For me just feels "natural" since I work with such workflow for a decade. First with in-house AAA engines, later with UE3 and UE4. The less programmer's help is needed, better for a team.*

* For 100% clarity, technical artists are often a half-programmer, half-artists. Able to find and locate performance bottleneck. More importantly, TA builds such workflows/pipelines that artists and designers wouldn't have too many opportunities to hurt the performance.