Game Development with Unity and it's version massacre.

Good evening,

tonight, i want to respectfully spin the wheel for a little discussion about the current state of Unity and its future for actual game development.

A short information about myself. I am Senior 3D Artist and in the last five years i worked full-time on a project which used Unreal Engine 4 as the base for the game. During the years, our team upgraded every two-three major versions. We started with 4.6 and ended up with 4.20 for the final release of the game. During this time, we got a lot new features in and aside some Network bugs never issued bigger blockers.

For our new game pitch, which we're preparing for a year now, we switched from UE4 to Unity after the Book of the Dead demo came out and just blew the mind from my boss. He just said: That's what we want!

Now, we're working with Unity and since then i have days where i just get lost in the woods. We switched from Unity 2017 to Unity 2018..from standard render pipeline to HDRP..back to standard..sometimes trying HDRP again. Back to 2017 because of certain plugin incompatibility with 2018..then moving forward to 2018 after plugin developers provided new versions of their assets. By next month, we are switching from pitch to real production and i bet you get the deal why i am writing these lines.

When we start working on a new game, we also look forward into the future which features are coming to the engine and which of these we want to use. Now, you would say stick with what you have and what is working stable right now like the 2017 LTS. I try to tell this to myself each day. But then, it's pretty hard to stay with the current 2018.3 for example when i read about the GPU Lightmapper, which of course is in development but claim to have all features in 2019.2 and up while facing backwards incompatibility with 2018.3.

Another example would be the render pipeline. At the moment, we're using the standard render pipeline while i would love to reach new grounds with HDRP in the next years. This is a tough decision upfront because the current module does not seem final and if we would start with the standard pipeline, we probably need to convert hundreds of shaders and assets lets say after a year or two inside an ongoing and deadline driven pipeline.

If some experienced Unity Developer may read this, i want to ask kindly if there is some light at the end of the tunnel. Would we, for example, ever see a final HDRP module for a current Unity version like, lets say 2018.3 or will it end up in some never ending "beta" status for 2019.1..2..3..4..2020. I've talked with certain Unity Plugin developers which stated that they're not working on HDRP updates before it gets final. This month, we need to decide which pipeline we're going to use for the next 4-5 years.

Certain available modules are under constant development but might end up being incompatible with older module versions later on. Within, upgrading to newer Unity iterations would probably end up in some sort of exclamation mark massacres which we would love to avoid. (which we already experienced..).

We have a hard time now deciding with which version to start the main production cycle when 2019.1 - 2019.2 are already knocking on the door with features we may want to use but may are not going to be available in 2018.3 due to incompatibility. If this is going to be a common issue in the future, we should probably need to talk about.

At the moment, Realtime GI, HDRP and probably certain new network and job features are on my bosses wish-list. We just don't know about the current status of all of these modules. We are looking for a Unity version where even the Unity Developers would say: Start with "this" version now to have a future proven, fully upgrade-able and safe editor/game-environment that may support all upcoming modules and features that will work out of the box without bigger surprises or conversions in the next couple of years.

Suggestions and advise appreciated! Help us Unitywan-Kenobi.

All best and have good Sunday,
Toby

 

If I was starting a new project this month, I would definitely use Unity 2018.3. I would definitely not roll back to Unity 2017 for a new project. I would not switch to Unity 2019 until 2019.2 probably, and that won't be available for quite a while.

 

HDRP has only been out in any real capacity for like 8 months and even then it's still in preview. Trying to use something in preview in production is just as bad an idea as trying to use a beta version of the editor in production. Use the tools you have, not the ones you'll have in the future.

 

As our colleagues said, you shouldn't be switching and twitch software version back and forth.
Test the grounds, make some prototypes, test plugins.
If happy, go forward, if not, management should discuss with you guys, what really is needed, what to ditch what, to keep. And of course, should really keep to stable Unity version.

 

This post is not only total nonsense but I'm not sure it has anything to do with anything.

 

I would say that you could start with 2018.3. But, this month will come 2019.1 with additional shader graph improvements and with HDRP 5.6.1x. With this you would easily or less painfully upgrade to 2019.2 when GPU lightmapper comes out.
I also don't like this constant flux of upgrades. When I upgraded from 2017 to 2018.3, whole project broke.
But, with 2019.3, preview will leave the beta so we will have stable Unity.
This is biggest API change Unity got and devs are doing the best they can.

 

You shouldn't change versions unless it is absolutely required to complete the game.

 

There were massive improvements from iteration to iteration.

But thing broke always on the way, when porting to newer version. Therefore, smart developers either stay with working version to them, or put effort to port and fix things, to get best of latest tech.

Current porting however, is nothing, in comparison when was moving large project Unity 4 to 5, to 2017 for example.

Not to mention, if someone still works with Unity JS or even boo.

 

The usual, and expected, rant from someone who is frustrated and need to vent their frustration. We should be used to this by now.

 

What doesn't? Even if a product was absolutely perfect, you'd always find someone who would be unhappy with it. C'est la vie.

 

Wasn't terribly entertaining either.

Welcome to being a beginner. I haven't had serious frustration with it in a long time.

 

Agreeing with ShilohGames here. Use 2018.3 and the Standard pipeline. The HDRP is still too new at this point.
Generally said, you should stick with one version - unless you absolutely need to upgrade to a newer version.

I didn't know that you speak for the majority of Unity devs.

I never had any serious frustration with Unity. Take the HDRP as an example: I know it's WIP and not final by any means, thus I expect bugs or stuff breaking. But that's something you get told about very early on: Blog posts explicitly say it's work-in-progress and not ready for production use yet + it has a "Preview" label next to it.

 

I really don't want to see people slapping others for having an open opinion. I really advise that some people here need to respect that - we're grown up people. In fact both, jrumps and Murgilod are correct at certain spots. At one side its safe to stay with a stable version without the full upcoming feature set. On the other side its like standing in front of a new theme park with really sweet things and a big note in front of the gates telling: "It's open, but be aware that our next ride might kill you". We are aware how alpha/beta development works because we never used "experimental features" in UE4 till they were proven production ready. Giving another example, we've read that Unity's Network system never got finished but is being deprecated now for some new "idea" while we could not find any proper documentation about the new system. This is something we need to cover in our current plannings. We can't start to work on an soon deprecated Network system if the new one is not meant for production yet. I hope people understand my point of view here as some sort of newcomer.

We don't want to change versions a lot since this is the safest way to go, that's for sure. I used this forum to see if there are people who may have experienced a similar experience in the past. A big thanks from my team for the honest opinions and we're going to discuss our options.

All best,
Toby

 

And yet you decided to move to Unity based on a demo built almost exclusively with experimental features?

 

Everybody has an opinion. It worth nothing.

No. It's "enter on your own risk". You have a choice. And those, who gladly accept this "theme park with risky rides" also have a choice. If you take away this, you gain nothing, but us, who like to try the "new rides", would lose a lot. So there is a single good solution to this situation: keep that theme park open, let us in, who would take the risk and allow you to remain outside on your own if you don't want to take it.
In other words, the current setup is good enough for everyone, changing it would take away freedom and choice.

If you're not sure in the support of things: roll your own. Do not rely on future features from anyone, including Unity. They have plans, but those are just plans, they can change any time. If you rely on them, it's your risk and you can gain on it (you don't have to develop a feature) but you also can lose on it (you need to develop your own, but you start late).

Do not rely on not "finished" (published, reasonably stable) feature-promises. Promises are there to break. Always.

 

@AcidArrow: As strange as it sounds - yes. And yes we knew that the demo was too good to be true. But if you start working on a game, you also need to think about how your game wants to look in its final state. And in our case this might be 4-5 years in the future. While engines like Snowdrop are getting features based on the game, we need to rely on given features and tool-sets from Unity and within we need to plan upfront to stay competitive.

 

@Lurking-Ninja Thank you for your opinion, good points.

 

No. This is a false statement. It was true. Period. You just don't want to put the amount of work in it that Unity guys did put in the demo. It wasn't a custom Unity Engine. It was a custom Unity Demo. In other words: everything you see in the demo is possible without engine modification. So it's not a lie.

And no, you don't HAVE TO rely on Unity's features, you can develop your own ones, you CHOSE to rely on them, because you don't want to invest the resources to develop your own. This is a huge difference.

You take too many things for granted.

 

New versions and incompatibility is a pain. It always is and always will be. However, it's not as big of a pain as you initially think. The key is to choose one, which ever one it is and stick with it until you absolutely cannot stick with it anymore for compatibility reasons with the target OS and hardware.

I started some of my projects way back on Unity 3.3, I've gone through the pain of the late 3 and early 4 version updates and again going from 2017 / 2018 as Unity made a bunch of older system obsolete.

Along the way I need to replace a few systems with things of my own that I previously used plugins for but that's ok. After several years working on a project you come to understand that most of the features a plugin offers are redundant and you can in fact get by with just a small implementation of a subsection of what a plugin offers.

If I were you, I'd start in 2018.x. Only if your game absolutely REQUIRES the newer features.

 

HDRP is currently in Preview (As labeled in the Package Manager Window) and thus is not 'recommended' for Production. Of course, that doesn't stop anyone from using it in Production; but its good to be aware that breaking-changes are likely happen between now and when it leaves 'Preview' and is 'Production-Ready'. That is aimed for sometime later in 2019.

 

We actually have several internal teams that use Unity every single day to build projects/examples/tutorials and give feedback to R&D directly:

Demo Team: Making our high-end graphics demos such as Blacksmith, Adam, NEON, Book Of The Dead, etc

Sample Game Team: Making larger advanced vertical slices, such as FPS Sample. Some of the team also work on the Mega City project.
https://unity.com/fps-sample
https://unity.com/megacity

Content Team: Making a lot of tutorial/beginner projects, such as 3D Game Kit, 2D Game Kit, Roll-A-Ball, Tanks, Nightmares, Trash Dash etc.

Evangelism Content Team: The team I am in! We often build smaller-projects focusing on upcoming/preview features; we have made projects such as Penny Pixel, Hover Racer, Robbie 2D Platformer, Angry Bots 2, etc

And this isn't including all the other people and teams at that use Unity; including Graphics Foundation, Machine Learning and Unity Labs (https://unity.com/labs)!

https://www.youtube.com/watch?v=vfMXSFrMio0

 

And not forgetting mega city and other

 

Most of them are Vertical Slices of Games or Cinematics. Did you check out the FPS Sample project; which has a range of different tools and systems made during the process of the project being built?

At the end of the day; Unity Technologies is not a company that make and sells videogames. We make and sell a Game Engine; and we use the tools internally when building the engine.

However, whatever Unity projects we do built internally won't fully cover the broad spectrum of what the Unity Community uses Unity for. Thats why we have Developer Relations Engineers, User Experience Researchers/Designers, Technical Evangelists, Field Engineers, Product Managers, Account Managers, Education Trainers, and many other roles that spend a lot of their time meeting external Unity and Non-Unity developers to find out their pain points/feedback and then communicate that back internally.

 

You don't have to make a game for a rendering and performance tech demo. I think you'll find that the vast majority of tech demos are little more than sweeping camera shots across advanced rendering tech or things that communicate the performance change scale, like ECS demos do.

 

What led you to believe that this wasn't likewise considered for a tech demo? Book of the Dead was made to run off of a console to show that Unity can achieve very high quality graphics without sacrificing performance. You can see the videos of this in action on YouTube.

Adding game mechanics on top of the demo won't impact performance in the way many seem to believe it would.

Spoiler: Book of the Dead on PS4 Pro

 

Well, does it have to be "games only" just to showcase what an engine is capable of?

Unity can be used for art installations or concert visuals - at least that's what Keijiro from Unity Technologies Japan is doing: 1, 2, 3, 4, 5, 6, 7, 8, 9
Even the Unreal Engine is widely used for the broadcasting area (Weather Channel).

 

Point is, these are not rendering, as typical 3D software does. These are real time show cases, of current capabilities.
Game devs are integrator. Meaning, they pick relevant features, and put them together, to create new content, or product.

In any of these examples, you can add camera controls, and call it a game already.
It will be rather walking simulators, but game never the less.
Thats bear bone minimum. And you build up from there.

 

does anybody here actually make games that come close to looking like Book of the Dead or these other demos? Is that level of performance really a consideration?

I can only think of one Unity game with graphics even in that ball park. As such, I figured the point of demo's like that are more as adverstising. Getting people like OP's boss to say, "hey, we can do it in unity!"

Seems like most people worried about performance in Unity projects is more because it's a mobile or VR development.

 

This is why I'm still working in 5.6. Unity is a freaking mess

 

Why using Unity at all then?

 

Pretty much this.^
When you start on game, you make many decisions, including the version you are going to use. You don't change versions during development unless it is ship critical. (like a changes to to deployment target hardware/software/requirements that require something new at the engine level). Even then you don't upgrade until you have fully tested it. Never upgrade your software just because a new version comes out, that is pretty much professional development 101. Also, you never, never, never make development decisions based on what a tool has "coming out" or on the roadmap. That is common sense 101. Only ever plan on the current and stable feature set.

 

I wonder about very long term projects. Say something like Red Dead Redemption 2. That was like, eight or ten years in the making? Technology changes a lot in such a time frame. How do they keep up?

I'm not talking about that game specifically. I just mean in general practice. Say you've got a five year project, do you just ship with waxy skin textures and no GI while everybody else is coming out with SSS and beautiful god rays? Does stuff like that factor in? Major technology upgrades (not saying my examples there constitute that, but you know what I mean)?

 

They are not. This is why version locking the editor and not using experimental/beta tech is common in almost all development unless you're making those tools yourself.

 

Because a mess is often still better then the alternatives.

Unity might not be the best all purpose engine that could exist. But its easily the best all purpose engine that does exist.

 

5.6 is one of the more stable version I've used back then.

Personally I thought that 5.2 was a terrible mess, 5.4 a bit less mess.
When the other alternative (at the time) was UDK3, Unity is the far better choice.

 

I wouldn't quite go this far. For my current project we've actually upgraded more than once, which probably sounds shocking to anyone who knows my history 'round here. Each time it's a choice, though - there's something specific we want, and we choose between the cost of upgrading to get it, or implementing it ourselves, or just doing without it.

At the end of the day, though, we wouldn't have started the project in Unity if we weren't confident we could finish it in Unity, in the state things were in at the time.

So that when it comes time to pick engines for a project, people are already aware of Unity and whatever cool stuff it's recently had added. So it's not forgotten or overlooked.

People rarely make decisions rationally. Both marketing and sales people understand this and take full advantage of it. They could rely on everyone doing project-specific prototypes and tests every time they start a new project, but they know that's not how engine choices are usually made in the real world.

 

It's okay to blame a user if it's their fault.

 

Well, humanity in general really.

Marketing and sales strategies that don't rely on human irrationality tend to be less competitive then those that do. Which means over time, only companies which exploit human nature tend to survive and grow.

The only real solution would be to eliminate the humans.

 

he is the user. Then it's called "taking responsibility."

 

i'm not sure what you're talking about really. "take responsibility" is just my standard response when I see "blaming the user?"

I'll go away.

 

I would of phrased it more in terms of organic evolution. There is no end or means, only continuing and not continuing.

Companies that continue to exist and grow are those that are successful.
Companies that are successful are those which exploit human nature.
Therefore a large company that does not exploit human nature cannot exist.

 

too many big words man. You see my avatar? You think that dude reads big words?

 

The problem that is a fundamental part of almost all software development? Diligence is not a "problem."

Unity is the most commonly used game engine out there, but go off I guess.

 

Where are all these videos on the site? I found them on YouTube after clicking on them in these posts but why are they not in the tutorials section?

 

Nobody is "deliberately" making it a good idea to version lock the editor to a specific version and use actually released tech, it's naturally a good idea because it provides a greater level of reliability.

 

I don't think of it in terms of "blame".

This is a well researched phenomena. There are books written on it. It's not about "blame", it's about learning how the world works to best achieve results within it. Marketing and sales people are doing that, and it's the answer to the question that was asked.

 

Yes. Let me put it differently... you should work under the assumption that you aren't going to change versions once you start. Upgrading mid project for some benefits and shifting to larger version numbers is something you can (and often) do, with careful testing and willing take the risk (of additional development and or, lost time).

The important point you hammered on is "choice". You knew what you are were doing when you did it. You knew the risks and costs and are taking responsibility for your effort. When a person does that it is one thing. But, when you upgrade because Unity posted a new version, and no other reason or testing, you are being a fool. When folks get all hot and bothered because "I upgraded to latest and Unity broked my stuffs!!1" . Pure user error.

 

If we followed that we would be on 5.2 or similar.

 

@zombiegorilla I totally agree on this. Before each bigger major UE4 version upgrade we had weeks of discussions before actually considering an update. That's why we skipped at least 1-2 versions between each major one. At the moment we're pinpointing all of the marketing hooks for our game and within the features we want to see.

We take a look at Unity's given tool-sets and third party plugins before considering own in-house tools because at this stage of development we don't have the resources to afford high ranked artists and coders out of the box. To boil it down a little bit now - i just mildly asked for some advise whats the current version to start with in the first place and we got some interesting opinions on this. Thank you.

Best,
Toby

 

Stop trying to make every thread your own personal devlog.

Anyway, maybe that explains why you've been in early access for over a year and a half.