What would it take for Unity to become the go to engine of AAA developers?

If I were a AAA studio, looking at a high fidelity title, I would not consider Unity.

Why?

Too much Risk. Currently, Unity has no functioning example of a AAA, high fidelity title. It's got some stuff that looks good, some great looking demos, etc. But no actual, published, best of breed titles.

No Best of Breed Titles == No Proof. In practical terms, from a risk management standpoint, you must have tangible proof that a game of similar scope is possible and can be successful using a given technology. The more examples there are, the safer your bet.

CryEngine and Unreal were both games first. These engines proved themselves at release. Their initial use was a best of breed, high fidelity title. Each new entry was as much a new game as an advertisement for the new tech and expanded capabilities of the platform.

Existing Examples are low performance. The more ambitious Unity titles that have been released were plagued with performance complaints. Maybe this is because the dev teams were less experienced, smaller, or not as well funded, but it doesn't matter. At the end of the day, the highest fidelity Unity titles tended to have very poor performance relative to their peers.

Unity is an unknown quantity. Maybe it can produce a best of breed, high fidelity title at this point. Maybe not. Nobody knows exactly because it's never been seriously attempted. Perhaps the most ambitious high fidelity Unity title to date is Tarkov, which is still in production. If this game is solid and polished, perhaps it can be the first example of a high fidelity title for Unity.

That's pretty much it. For Unity to be a serious consideration, it needs more examples. If UT doesn't want to fund that example themselves, then it will come down to devs slowly producing more and more ambitious titles with Unity.

 

They are both C++ engine (open source) designed and optimized to run open worlds (despite Cry Engine terrain size limitation), this is what make them appart also.

What about "Recore" ? It worked, it had some limitations about texture handling , level loading times, and the levels was not open world big forests, but it was a very good game.
A game like "Prey" considered AAA running on CryEngine could be done in Unity, there is nothing spectacular about graphics or gameplay in this title.

I doubt Unity want to spend time on AAA side, it is already possible to make some AAA game in Unity , for example games like Pamela or System Shock remake (for games with large terrain and forest and open world it's not possible out of the box).
Unity has improved a lot with things like new particles, instancing , image effects and is still improving.

There is different ways to make a AAA game, read this about big team and big budget AAA game.
Engine,editor and tools are made from scratch.
http://www.gdcvault.com/play/1024685/Creating-a-Tools-Pipeline-for

 

Recore got a 63% on metacritic and had technical problems on launch. Most of the notes I saw mentioned a price point of $25 to $30, not sure if this was release pricing or if it just went straight to bargain prices.

To be clear, I am not saying "Unity can't do it" - I'm saying that in terms of a technical/business decision, I would doubt management would seriously consider Unity for a "best of breed" console/pc game at this point. It's too risky and unproven.

I think that once there's a blockbuster high fidelity Unity title, the situation can change. As of now, that title simply doesn't exist. It might in a few years, but it doesn't exist today.

 

When a AAA studio considers a any tool, including engines, they don't base it on examples. They know exactly what their needs are. They rigorously test and evaluate the tool against their known requirements. Most have have ongoing evaluations of a variety of tools. What someone else has done with a tool is irrelevant compared to what the tool can actually do.

Given that an engine is at center of the process, there is a lot more at stake than capability. Existing pipeline, process, tools, knowledge and investment play a major factor. Even if Unity was equally, or even a bit more capable, it would actually have to be significant improvement in all or most of the areas to justify a such a major switch.

And of course a big risk for large studios like that is the dependence on Unity as their engine team. An internal engine team can pivot very quickly for internal tooling, platform or tech changes, for the specific needs of the project. Unity's focus is thousands of developers, not just one game. There is a tipping point where internal engines are more cost effective and effective over a broad solution like Unity. Unity is a perfect solution for 1 person projects, up to very large projects. That last 1% that needs a different solution, needs the most significant changes, which doesn't make sense for Unity to chase, especially at the cost of the other 99%.

 

It's totally related to what king of game you want to make.For example "Prey" on Unity can be done while Witcher 3 would not be possible to the same technical level.
Most popular studios use their own in house engine and tools, this is the way if you want to go very big and it costs a lot.

Yep, this is the major difference, and also the multi purpose capability of Unity like 2D and mobile is the big difference.

 

This is actually not a good thing.

When you adapt an engine that once was a game, you'll end up with odd artifacts from that game. Unreal 4 has this - after all that time, there are still oddities that hint at UNreal being an FPS engine in the past.

It happens because it is easier to make an inflexible one-time engine for one specific game than a general-purpose engine, so something that started as a game will have remnants of the original inflexible engine.

 

But isn't the whole point of Unity that its for indies? That it "democratises game development"?

But anyway I think Unity 2017 will be a step towards that.

I've always said Unity was not optimised well. They addressed some of that with faster scene loading in Unity 5. And they're optimising it more in Unity 2017. So that gives less of a reason for AAA companies not to use it. Together with adding C# 4 support with the task library for parallel processing is another step forward.

But I think still AAA companies will prefer to write things in C++ for speed because Mono is just a black box. e.g. is "Mathf.floor" optimised or not? You can't tell unless you try it. And that takes valuable time. You can obviously write C++ dlls for Unity but then it sort of defeats the point of using it and all the C# API.

An AAA company with its own in-house optimised game engine written in C++ will probably still be the best solution for them. Even though it probably only works for one OS but who plays games on a Mac anyway?

Maybe for AA companies who want to knock out the latest movie game spin-off will use Unity though.

And what's so good about AAA games anyway? You can make some very good AAI games. That's AA plus I for imagination! (Sorry for being corny!)

 

Is it really this rational? I won't pretend to know more about the subject than you do, but I have seen many high stakes decision makers in action in many fields. In general, when someone is risking $10-$20m on a choice that can have serious impact on your career, people tend to be extremely risk averse, especially in terms of technology.

• Nobody is going to get fired for following the pack and using whatever approach is standard to domain.
• On the other hand, making a choice that raises eyebrows can be damaging to your career if things go poorly.

Maybe game studios are far more rational and analysis driven than many other fields, but when it comes to big bets I tend to believe that the same basic rules apply:

• Avoid Risks
• Follow Convention

I could be mistaken, and I will absolutely bow to your inside knowledge, but I tend to think game platform decisions will follow the same model as other major technology selection.

 

Firstly neither of them are open source, they have licensing limitiations.. The only difference between Unity and Unreal / CE in the "access to source" department is you don't have to pay any additional fees to get it.

CryEngine is optimised for open worlds but I get what @frosted is saying, it was originally just a framework for Crysis that evolved. Unreal is only now getting to stage where out the box it's optimised for open worlds. Its rendering pipeline / phsyx / AI / architecture / lighting wasn't originally set up that way. There are *still limitations because UE4 is Epic's first real attempt at a generic do all engine..

*limitations you can of course overcome due to access with source.

Recore was a bad example, tons of reviews and complaints about how bad performance was and the amount of graphical glitches etc. Is it Unity's fault? No of course not, nobody forced them use Unity and it was up to them to sort out any problems. Even still, reputation wise it wasn't a good entry into the catalogue.. Especially as recore isn't at the forefront of AAA mammoths..

When we come down to brass taxes, a AAA company spending millions should at least have some talented engineers guiding them about the best course of action for the project they are going to embark on. For some projects Unity would be perfectly viable and for others it would be close to a re-write..

 

I don't agree about Recore.
I played it on Xbox One, the only issues that bothered me was noticeable low res textures on some parts or the long loading time. Otherwise the game is fun with great gameplay and has a great level design, i didn't need better graphics because the content was great.It's a very underrated game, most gamers that played it agreed on how good it is.

Also the game could have been at the top with a bigger budget and more time, it has not been finished and been out too early. With better character animations, more maps , better effects , more diversified ennemies and better lighting and improvments on outside maps it could have been a great AAA made in Unity.
They took Unity because it was the fastest way , not the better, this is possible but you must put some work (it's not out of the box)
https://blogs.unity3d.com/2016/10/0...ature/?utm_source=tuicool&utm_medium=referral
https://blogs.unity3d.com/2016/10/11/building-for-reuse-mecanim-on-recore/

Indeed.

 

The thing is, it doesn't matter if the game is good or not. It's about the Reputation.

Recore is not an example that many companies would want to follow, since it didn't do very well.

I'm not saying this is fair, or good, I'm just saying that this kind of thing matters. Reputation makes a huge difference.

The reason I mentioned CryEngine and Unreal being games first is because both of these games were wildly celebrated for their visuals on release. They were both examples of best of breed, cutting edge graphics. Both games were very successful.

I'm certain that all of those factors played a major role in making those two engines "AAA" viable.

 

Those conversations/decisions virtually never happen. Take Naughty Dog, they have hundreds of developers, and several games in development at any given time based on an internal engine. The topic of engine switch never happens. The studio is built on their tools and tech and their culture of tech and innovation. While indies, and small teams that are used to a complete interchangeable tool like Unity might consider switching, that doesn't happen at the large scale. Even at Disney, where we had several studios, and shorter cycle projects (mobile), it took over 3 years to switch to Unity from an internal engine. There are no "managers" making random calls based on budget. Change is slow, and happens is small manageable steps. Replacing your core tech, just almost never happens at that scale. (there are exceptions, like acquisition/mergers/etc)

Tech choices are made by tech staff, and change is a huge risk. Unless there are critical, provable problems with a current workflow/process that needs to be addressed, change is unlikely. Especially because with internal tools, they can simply be fixed. Several of us at Disney pushed hard for switching to Unity over several years, and we were given the opportunity to prove our case on smaller projects for assessment. We proved that Unity was viable in our environment. The core case for the switch was two key issues 1) the amount of teams and projects were growing very fast, meaning that the internal engine team was now having to support the needs of many projects, slowing response time. 2) platforms and device software started changing very fast, again, putting massive pressure on internal teams working on the engine. (including tons more QA). We would have had to massively increase the team size and budget, just to keep up. (also the engine was more 3d focused, and wasn't efficient to use in games that were 2d heavy) Moreover, as the studio grew, new hires had longer ramp-ups to learn the engine. With Unity, we could, if needed, hire folks with existing knowledge, but mainly, there was so much more documentation and support already out there.

But, that was my main point. The technical skill and ability of those capable of driving or affecting the choice are fully aware that the output of others using the tool isn't an accurate reflection of the tool's ability. The amount of time, cost and effort involved in tool set choices, means that you don't care about other opinions or examples. You get it and run it through the paces based on your needs. And it goes both ways. Frostbite games tend to be beautiful... but if you spend any time talking to those who used it, you will find a different story. (over half of my current team is from Dice). Examples have little to know impact on choices at that level, you have to get your hands dirty.

 

The issue here was more about lack of budget and time.
With more it could have looked , played like an AAA game. For example there was not time of day only a blue sky, many outdoor assets would have benefit from more design study instead of an empty desert with rocks. I am just syaing it was possible for Recore to get lot better reviews if it was more time and budget, Unity was not the limitation.

 

@zombiegorilla - hrm, thanks for sharing that insight. This actually makes a lot of sense.

I think I see where you're coming from a lot better. It's different from most other domains where the tech is seen more as a means to an end. Although the talk of details and legacy and maintenance all sounds extremely familiar.

What about a new studio though that doesn't have as much prior investment?

Star Citizen is an example of a hard to classify, they clearly have a mammoth budget having raised over $100m - so they are AAA by that definition at least. They went off the shelf with CryEngine/Lumberyard. This kind of decision was probably pretty different from the example at Disney, where you had many, many projects running and many smaller projects for incubation.

 

Certainly there will be situations that vary. But generally "new" studios are tribal, they are collectives of folks who worked together in the past, often rising from the ashes of massive layoffs or studio shutdowns. (My current team has been together for over 6 years, even though they were other studios or parts of larger studios at different times ). Often they will carry their tech choices with them if possible, or switch basesd on budget or inability to access or maintain prior tools. (Like internal engines). Some (like my team) switched to due to nothing more than frustration with prior tools experiences. I don't know the history of star citizen, but as a guess I would assume that the founding team had considerable cry experience. But I don't know.

 

I think that by this time they're no longer have CryEngine/Lumberyard and instead maintain their own highly customized fork of it.

The decision to use cryengine in that case was similar to what google did when they picked linux kernel for their android devices - they got sufficiently advanced tech to bootstrap the project, and then started hacking away customizing it.

 

Fair enough, but again, why does company after company choose either Unreal or Cry as their off the shelf starting point?

Something is different between these engines and Unity.

If it isn't the tech itself, and it isn't the reputation... then what is it? Why is Tarkov the closest thing to a best of breed game targeting high fidelity realism that runs Unity?

Interesting. I really appreciate the little snippits on how the industry generally functions at the AAA level.

 

Source code access without special licensing.

 

https://store.unity.com/products/un...9.1239862402.1494107605-1417327249.1482522883

Source is included with enterprise license. Admittedly Enterprise is a "contact us for pricing" level, but for anyone throwing around $5+ million, that should be a level you're comfortable with.

I read a little about Recore, and MecAnim was the product of collaboration between their studio and Unity. I think that UT would absolutely be willing to work with potentially high profile, high fidelity projects.

I'm sure UT wants that AAA laurel. If nothing else just for reputation's sake.

 

@zombiegorilla

It's not black and white, we always seem to talk in absolutes. Square Enix have their own internal engines, they talked about it and decided Unreal 4 was the best option for the FF7 remake.. But why? There's no specific reason they couldn't of used their own engines.

When it comes down to it, this isn't just a conversation about AAA. Because looking from ten thousand foot down the same issues plague anyone trying to attempt a specific project.. It's all about the project, that defines everything you do..!

I love speaking to dev's and getting their 2c's on stuff from all types of companies big to small, there was a small indie team that tried to make an openworld MMO in Unity quite a few years back. The CEO of said indie is a really cool guy and I helped out from time to time, even though me and @hippocoder thought he was nuts to undertake such a project.

I experienced first hand what he had to go through and the futility of the project within said engine, unlike AAA us indies are somewhat restrained and at the time something like an Unreal license would of started at a cool 1/4 mil.. Two years on the project in Unity is pretty much floating in the water. It's not for lack of trying, it's not like they / we were quitters it's just the limitations of said engine sunk it..

Well anyway, Epic eventually release Unreal.. At this point Unreal 4 is in Beta, to get it to start working properly was a massive undertaking. But the game got released (eventually), small team of 10 that released a decent / good looking openworld MMO.. I mean respect just for getting it finished right?

Indie's and AAA alike will use whatever gives them the best chance of success and I hear guys working on large outfits talking about time as their major factor.. Writing tools, writing API's / pipelines / Art etc. etc. takes time and we are all band limited.. If nothing else shareholders won't be pleased if a project hits the five / six year mark.

Point being, no matter who you are (big or small) again it's all about the confidence *cough I mean project. Unity does not cater to certain projects, it would cost an indie or a AAA outfit either too much time or too much money to complete the project. Whatever the cost analysis is, like re-tooling / training etc. etc.

It's almost silly, why would you choose a tool that works against you? Would CD Projekt dump their bespoke (proven) engine for Unity? As you perfectly said, there's no reason for Unity to cater for fringe cases (whether Indie or AAA).. Unity is primarily a small to mid project leviathan, they are the number one engine and the amount of resources and effort it would take to get it up to Unreal's standard most likely just ain't worth it..

 

About rendering they are superior out of the box, many 3D artists use UE4 or Cry Engine to expose their 3D art.
About tools and features Unreal 4 is miles ahead out of the box compared to Unity, for CryEngine it's also superior to Unity out of the box because it's an open world editor with a character AI suite and also great tools (designer) and features (time of day, real time GI etc ...).

For some big projects the engine will be evaluated "out of the box" about rendering, tools, features.
Unity is not great out of the box for desktop if you target AAA , you must buy lot of plugins for better terrain tools and graphics, better water and vegetation shaders, better editor tools (roads, splines, objects placement etc ... ).
Also it can cost time to search the best plugins, evaluate them and you are dependent on each plugin developper, some times there is no complete source code.
While with both UE4 and CryEngine you don't have to bother about plugins, you know exactly what they propose and what they can do out of the box.

 

Actually, it is an add on. As you said the price is negotiated. At Disney we had source code access for a couple of years at first, but eventually dropped it. Partially because of increased confidence in unity in general, but also, merging was a nightmare. Also, because of the temptation to solve things at the engine level was too great.

 

Correct, it is never black and white. Studio make up also plays a big factor. Larger companies with several teams, may have opportunities to address tech changes due to shifting team structures. While some large companies with smaller catalogs may stick with legacy choices because there isn't a good time to reevaluate. (Crystal). And many big studios (ea) with multiple projects use many engines based on project needs. Which also lets be a bit more nimble on choices because the have knowledge and resources across platforms.

 

All of this may be true and good, but I bet you that once there are a few breakout successes of high fidelity Unity titles, other best of breed efforts will follow.

People aren't that rational in practice, intangibles like gut feel and reputation count for so much in how people make decisions.

Even stuff like evaluation is different. When dealing with an unknown or not reputable product, peoples judgement clouds. They imagine problems, they spend less effort on finding solutions.

Once examples exist, people don't need to evaluate unknowns as deeply, they can simply say "well they did it with Unity, I'm sure we could". The more evidence the more likely future projects are to give it a real and fair shake.

 

I agree, but it's not always about how much stuff something has.. Business ethos has a lot to do with it, sure I / we complain about Unity playing it safe but doing so has one major advantage... Stability.!

I'm not an engine evangelist in any sense, they are all tools to get a job done. It's like discussing Max vs. Maya and like Unity / Unreal it's two sides of a coin.. Unity probably play it too safe and Epic need to stop DICKING around with the engine.

It's somewhat understandable in Unity's case they are playing catchup, but they got a lot of backlash from increased iteration (and bugs) in the Unity 5.X cycle. Personally I believe they could do with keeping on down that path..

As for Epic, it's a grand old joke.. I mean they probably have more tools and features integrated than the entire Unity asset store but they keep on doing it every iteration. Unity who doesn't really have to care too much about stability due to locked subs do and the company that relies on you actually finishing a game (because of royalties) doesn't..

 

Same here. And in my experience, most folks at the professional level aren't either. People who deal with this stuff everyday are always interested in the best solution to make their lives easier, and focus on more design related issues. Unity is the best solution for what my team does today. If, when our next product cycle begins, there is a better solution, we will switch. It seems highly unlikely right now, but we always keep an eye out. Evangelism is for chumps. (except if the product is your own)

And, good point about stability. That is a pretty bit one, and with things in this industry always in shift, Unity's stability is pretty huge.

 

That's a great looking game. Another one in similar style is the Signal from Tolva, that I like the look of:



But they both don't come anywhere near the beauty of that MGS5 pic. They still have, for lack of a better term or understanding, 'flat lighting' although the shaders do a lot to cover that up.

The MGS5 pic I posted was also fairly simple materials - I would say most of them were tiling - and you can see from the obstacle in the middle that they were using SSAO and not a very good one at that. Yet it looks really fantastic to me, and so do screenshots of fairly plain scenes from other AAA games.

Anyway, not to derail too much, but although these screenshots ^ look good, they aren't what I'm personally talking about.

 

That's as may be, but in the meantime, all we have to go on are tangible examples. Project Wight is comprised of largely AAA veterans, it will be interesting to see how that goes for them - although personally I don't like how the game appears in Unity (and I say 'in Unity', because their materials are apparently largely from quixel megascans which are not lacking in quality). But anyway, there's one example.

As much as everybody is probably sick of hearing me rail on about graphics, I think it factors very heavily into choosing a third party engine. I've heard of a few big games switching to UE because it looks better, and one must not forget that gamers are the ones who will judge the game and give you money (or not) and it's well known that graphics plays heavily into their choices. Whether we like it or not, it's something we have to consider not just for own own pleasure but also our business.

As far as I'm concerned, it's a fact that UE looks way better - you may not agree with me but if you spend some serious time on polycount, you will see some things that will blow your mind.
But anyway, my point is that, whether you agree or not that Unity is lacking in this area, many of these AAA devs may well do, and the ability to put out fantastic graphics is going to factor into their choice.

I think it's also worth noting that once you get to the level of 'high-end indie' all the approachability and usability of Unity probably counts for far less, and the raw capability of the engine is much more important - since you'll be whirling up your own tools and shortcuts for everything anyway.

 

The more , the better, i really prefer to have lot of options and only use what i need instead of lacking tools and features.
And there is a reason, because Epic have 3D artists and level designers in their team asking and making tools, for example some mandatory tools like spline tool, vertex painter etc ...
Unity should really favour lot more tools for level designer and 3D artists some day, they are available in the asset store, but some 3D artist making level design and showcase it's portfolio will just pick up UE4 or Cry Engine and won't buy plugins.

MSG5 engine has a great outdoor lighting system and great PRB shaders.
With Unity you must buy Alloy shaders , and outdoor lighting or probe system is lacking something , i don't find the same level as UE4 or Decima engine or perhaps i missed something and didn't seen some good examples.

Yep, they made a good mix between simplistic cartoon and some realistic details, it's a good balance.
It doesn't look they use PBR, the metal parts don't have any small metal reflection or specular.

A success game is always a good balance between level design, lighting technology and artistic sense of lighting, in bigger studios there is specific people working only on the lighting set up for the game maps.
Some games doesn't need the best lighting and PBR to have a very big success.

 

@ShadowK Do you have precision on what were the roadblock in their projects (or yours) with making open world game with unity?

 

Still need good lighting

 

Overwatch does use PBR. And SSR for reflection. And has pretty great lighting.

So I'm not sure it works as an example for what you said.

 

This. Plus, when Crytek shut down their Frankfurt branch CIG scooped up a bunch of Cryengine developers. They aren't just using an off-the-shelf engine.

Can you explain this statement? When the phrase "different story" you're implying that the reality is the opposite of the perception--but are you truly arguing that Frostbite isn't graphically impressive? Or are you talking about the tech concerns required with making Frostbite games?

I know NFS The Run, a Frostbite game from Black Box, was very short and never seemed to work all that great. Additionally, when Bioware moved to Frostbite for their games, they delayed both of their games significantly.

There are definitely very specific reasons.

Crystal Tools was a disaster. They had significant trouble getting it to work for open-world games, which I suspect is why Final Fantasy XIII is such a linear game--and the one open world game in the XIII series is seriously creaky tech-wise.

Now, during XIII-s development XIII Versus was supposedly being developed...but the significant trouble with Crystal Tools, along with the disaster of FF XIV 1.0, prevented basically any work from being done on Versus. So when it came time for work to be done on Versus, they knew Crystal Tools wouldn't work. They then went to work on Ebony/Luminous.

Now, they were developing this engine AS they were developing the game. I'm sure anyone who followed development can remember Tabata's comments about the different Luminous versions. But anyway, it wasn't some complete engine in 2015 (the game didn't even come out until the end of 2016).

2015 was, as you are probably aware, the year that work started on FF VII Remake. Luminous wasn't even a complete engine at that point in time. For VII's development to continue at its own pace they had to use a complete engine. Square didn't have any other real "HD" engines at the time they could use. Hence, Unreal 4.

I imagine it's much the same for KH 3, and DQ 11.

 

Looks very correct to me, the artistic sides matters more (like Zelda BOT success), and well the game success is fantastic lol

I would says it's lot less visible than some realistic AAA games with metals , glass and reflective surfaces everywhere.

 

What I mean is, it does have great lighting, which is what is needed to make even highly stylized art look great.

 

ok, i thaught you was saying the game still needs work to get good lightening lol.

 

After so long I wouldn't say I have "precision", but I do remember quite a few issues I came across. Just as a disclaimer, it has been a while and many things have been updated / fixed since I last tried a big project in Unity.

Some of it's rather obvious, if people are generally suffering from things like Phsyx overhead / GC issues / Async speed etc. in relatively small projects then it's of course going to be multiplied many times over in a large project. A TOD system isn't just for making the sun pop up and down, it's generally a major part of event driven systems controlling thousands of functions (spawn locations, AI profiles / pathfinding destinations (encounters, rest locations) just to name a very small few).

You have overhead coming in every direction, CPU and GPU.. Reason I mention this is I'm trying to set the scene of how complicated a modern RPG is, you will have thousands of things going on before you even have anything near an actual game completed.

One of the major "issues" with complaining about limitations is we can argue over design, a lot of these problems would dissapear if I split the scenes up into manageable chunks and removed a fair amount of overhead from the art budget. But then it's not an open world game is it? I mean at that point you might as well bake lighting and just make everything static, it would fit in with Unity far better. In short a lot of this will depend on how much you are willing to compromise in every aspect of the game..

In Unity 4.X the editor would crash constantly, that was of course due to 32-bit limitations.. In 5.X it still bogs down to a crawl when displaying a large scene, async'ing massive amounts of terrain tiles (with NPC's and large amounts of) Meshes etc. causes long stalled loading times (I'm talking 5 minutes upwards).

We all know the terrain system needs a lot of work but in a load / unload tile based vector boundary setup there's overhead from active tiles, for every segment it repeats frustrum culling. Most modern games have a fairly long frustum so you need X amount of tiles active at any one time.

If we talk about performance, Unreal on my old machine (with a Radeon 390X) was able to display around 45 - 50 million tris before performance would start to become negatively affected. You try that with Unity..

Unity's Vsync implementation isn't right and I swear it's the cause of a lot of micro stutters in EVERY Unity game I've ever seen or played. Of course Epic has an answer for this: https://answers.unrealengine.com/questions/90743/what-exactly-does-smooth-frame-rate-do.html

Umbra as a grid based / static occlusion system isn't really that helpful in the context of an open world game, it doesn't seem to improve performance that much and on top of that it caused issues with water / reflection probes. You can move the camera to an angle so you can't see a terrain chunk for example, but you can still see the water..

Mecanim for me wasn't any more useful than the legacy animation system, some pretty cool animation blend features but it only seemed to work right as a "generic" rig.. Animation re-targeting which is a very useful feature I've never got to work right..

There were too many unknowns about limitations, I originally tried to tackle a temporal AA implementation and I needed a velocity buffer.. TXAA wasn't essential to releasing a game but Unity's AA solutions urked me, Unreals methodology is deep integration so lets take something simple like a vertex painter.. In Unreal it can be use for all sorts of things, use it as a material function to paint crests on a water material, add "fuzz" / puddles to a terrain material if you set it up thusly in the mat editor.

There's tons of examples, the particle system ties into the character system and into the phsyx system.. If you want to add a particle to projectile, you flick open a window drag n' drop. Then you use the character setup suites to socket said projectiles and then set up advanced collision phsyics (and modify via source)..

What exactly can you get away with in Unity? If I wanted to integrate Apex into the pipleline could I? A lot of the time it wasn't worth trying to manipulate sub-systems to do exactly what I wanted because I could just hit a wall and waste a boat load of time.

Also it's that deep integration and logical workflow that really helps, they're not just ad hoc tools developed by one of many teams to serve a few generic user case scenarios.

Talking about tools, just the sheer amount of them you'd need. Hands up, how long would it take you to integrate every major asset store tool into Unity if you had to write it from scratch? Even then you will still most likely not have the equivalent of a major AAA engine.

@EternalAmbiguity is talking about how Square Enix knew it was a bit too much to chew off to take on a complete pre-made solution. So where does that leave us indies?

I could go on for 20+ pages, but in short most of Unity's core systems weren't up to scratch (or not even worth using), it has too much of a reliance on the asset store to fill gaps and that's a risky proposition in its self.

@Billy4184

There's only one reason I can think of why things would look flat (I'm guessing you don't mean normal maps / parallax mapping (shader) sort of flat and that would be a very basic mistake in one of the matrices..

 

Can you elaborate? At the moment I'm completely clueless as to what the cause is, although I can definitely see it. If there's some way to achieve the result in Unity I would very much like to know.

Here's a couple of examples of somewhat similar archviz scenes I found - which will hopefully remove most of the stylistic influences - which demonstrate the effect I mean. First is Unity and second is UE.







The Unity one was made in a fairly early version of Unity 5, but IMO the effect is visible in most of the Unity screenshots I've seen to date.

I call it 'flat' because if I had to describe it, it appears as if the Unity images have a smaller range of lighting values (hence the image is 'flat' rather than 'deep'), although that may not actually be the case at all, it's just a way for me to describe the effect the way I see it.

Here's another Unity one that may come closer in terms of post fx, but still cannot reach the 'pop' of the above scene - it still looks, for lack of a better term, somewhat 'flat':

 

About that, generally you have region managers running only when you are in the region, the world is divided in octree like, spawners and other managers only activate when you are in the neighbour octree zones only.
If you play Far Cry 4, you'll notice there is only a limited number of characters around your player any time and spaw zones are not close each one to other. Zones are noticeable when ennemies stop chasing you at towns limits.
Generally speaking in games like fallout 4, you won't have 30 creatures pursuing and attacking you at the same time.

Sure if you just place all your thousand characters,creatures, events in the level within Unity editor and run the game you'll have serious performance issues. This is more about how you manage your world population and events instead of an engine feature.

Some company like Square Enix picked up UE4 because it's a fully integrated solution with all tools you need to better and faster create your levels. They stay focused on creating the content instead of missing features and tools.

There is too much bloom and too much tone mapping producing this "white" filter effect in the fist pic, it's a common mistake. In reality the room would not be so bright.

 

@Billy4184

Actually that's quite easy to resolve, when you stack post you'll recieve issues with "washout" (especially with things like bloom).. I used to use Amplify colour to sort it out in photoshop, things like Aces (tonemapping) (now included in Unity's post stack) goes a long way towards solving this issue.

 

Mine was set up a lot more like Skyrim, with AI derivative tree's and "Zones / cells".. Works absolutely fine in UE, it's not really about implementation methodology as I spent a long time tweaking it based upon other games open world methodology (that's tried / tested and proven).

It's the whole compromise thing as stated, W3 is a no compromise game.. Forget any other part of the system, you make a terrain that big with the same collision / mesh density and draw distances with nothing but a player character and Unity grinds to a halt.. Every 0.1ms counts and it has to be extremely well optimised everywhere..

 

Speaking of "Flat", Tolva's screenshot looks like it doesn't have any specular component on any material.

Regarding MGS5.... IMO, the area depicted on @Billy4184 's screen is one of the less visually interesting settings in the game.

MGS looked best in high-contrast scenes, indoor scenes, and close up portraits.

Spoiler

Compared to intro mission FOB/Homebase looked almost cartoonish.

Outdoor environments tended to have similarly "flat" look.

Spoiler

 

@Billy4184

Would you say the first pic looks flat (another Unity experiment of mine)? It's not quite the picture below it, but I had this running at 60FPS on a GTX 480.. Whereas I've tried the megascans type (archviz) in UE and it's just not maintainable (even though it's super pretty) .. Point being there is always a compromise..

 

I really don't like the bloom and the PBR metals parts that are less reflective seems out of the box shaders.
Anyway it is sitll gorgeous.

Sure, they tailored Umbra middleware to their own needs, this is not common for indies.

I find outdoor real time lighting working very well in this game and somewhat accurate.

 

OK let's put aside the 'washout' effect for a bit, because that's not what I mean when I say 'flat' lighting.

Unity:



UE:



I deliberately picked out a very empty UE scene here.

@zenGarden of course you're right that the first shot has some mistakes, what about the second Unity shot (bedroom scene) I put at the end of that post? Or this one here ^?

It's very easy to find some mistake with the Unity shots I'm posting and declare that to be the issue, so how about posting the best Unity screenshot you've ever found, and we'll see how it stacks up against a similar sample from UE? The Unity shot I posted above, is the best one I found just from a straightforward google search.

 

I think the lighting in the top pic does have a slight flat look in the same way that everything I've seen in Unity does, but it's about as good as I've seen in Unity.

To me, this screenshot here is what I would dearly like to see reproduced in Unity, this is pure cinematic pleasure to me, of the kind I see in many kinds of AAA games and UE portfolios. It looks like megascans materials to me, so should not be hard to reproduce in Unity if it is capable of it.

 

The first pic, there is again the same issue, too much GI or too much bloom, this is too lighten everywhere, this makes contrast and colour vanished away, it even makes materials loose their PBR identity for example the marble looks unrealistically lighten and unrealistic marble.
On the second pictures, contrast and colours are strong , the bloom is really subtile and the general lighting and GI is not overdone or over lightened , it looks as good as it was a render, it looks more real.
Whatever engine it is or not the second is best on all aspects.

What i see is the same scene as @ShadowK but with better contrast and sharpen or post effects doesn't blurr or mix all objects together. Perhaps it's amore about anti aliasing and post effects in Unity issues or adjustments ?

 

No, sorry, I was unclear. It is definitely one of the visually impressive engines there is. But it's very challenging to work with and get it work properly.

 

Ok, I'll take your forest and raise you a river, this one doesn't look flat (well blurry / merged) to me? I really do love my terrains :

 

Second pic is UE. Anyway, you may be right, but if so, whatever these settings are there doesn't seem to be a single Unity dev out of the multitudes using Unity who have stumbled upon it thus far. I have not seen anything even close, even in the 'high-end' indie games with AAA veterans at the helm wielding Quixel Megascans materials.

If you can find something similar in Unity, please feel free to share!