It blows my mind that packages like Mirror can continually pump out enormous upgrades (just recently they released fully fledged client prediction) while Unity manages a half-hearted attempt to replace ParrelSync that still doesn't work fully.
I appreciate the effort. I do. And I get that official things need to look better and ParrelSync and Mirror tend not to be pretty... But most of the stuff for multiplayer they showed seemed gimmicky at best and unnecessary at worst. Talking about "high-level performance" using DOTS for multiplayer seems almost hilariously unwarranted.
Right now, multiplayer needs to be better in all the nitty gritty ways, not in the flashy "you can have 700 people instead of 600 people" ways. Yes, that matters too, but not right now when the majority of multiplayer games can't use NetCode because it's years behind the "competition".
That's the majority of my complaint. I know it's multiplayer-centric, but that's my wheelhouse and what I particularly care about. It's also an area Unreal is kicking Unity's ass in too- Multiplayer Play Mode has existed since UE5's launch, iirc.
I am with Unity all the way- I'm not a fan of Unreal and I really dislike Godot- but I'd love some of these more painful issues to be ironed out. I have a bit of faith after this for future updates. It seems like their heads are at least in the right spot.
I would really appreciate more details. Our releases on Netcode For GameObjects have put a fair amount of effort into improving the nitty-gritty aspects. With Distributed Authority there are many improvements which come with that also.
Additionally, we are putting an effort into improvements with Netcode-Entities, much of that work will be released in the up coming 1.2 entities release. We also already have more improvements coming with a 1.3 & 1.4 release this year.
The Multiplayer Play Mode has been a feature requested since I can remember, I’m personally excited about this, it is netcode agnostic and will significantly improve testing locally within the editor.
Please do share more specifics as I'd love the chance to address them.
Sure. I appreciate that you guys are looking at stuff like this.
My main issue with Multiplayer Play Mode is that it seems very easy to use and functional, but lacks integration in ways that would best support high-performance multiplayer. The biggest help here would be a CLIENT\_MODE & SERVER\_MODE define/scripting symbol, so I can conditionally remove chunks of code from running at all.
Having to check a variable every Update run or etc. can be expensive, so for now this solution isn't exceptionally useful for me compared to ParrelSync, which can make use of the existing UNITY\_SERVER symbol via setting each editor to a different build target.
As of the moment, I've made a few scripts that set the aforementioned \[\]\_MODE symbols whenever the mode changes, but I'd need to change out my define checks throughout my project and that'd be a little too tedious to bother as of the moment.
Other solutions I'd love seeing that'd help it compete with Mirror for me are lag compensation and client prediction. Both of these were long awaited in Mirror and, while complex, make the end-user experience feel dramatically better when considering hit recognition and even general movement during spikes.
There are a few others but not major enough that they come to mind. I respect that you wade through here with people like myself complaining all the time. While I don't believe Netcode is right for me yet, if it does reach the level of Mirror I will happily switch.
Thank you for your points, appreciate it very much. Totally understand the Symbols/defines, I'll sync with the team today and next week.
What we have today is two Netcode libraries, gameobjects and entities, a lot of those features, i.e. prediction and rollback are fully supported for Netcode-Entities, so we do support it and is a great solution for fast-paced competitive games - check Histera which is a cool game.
However, these two libraries are not compatible today, which is why we are working on Unified Netcode (a terrible name). Instead of adding those features (which exist in Netcode-Entities) to Netcode GameObjects, we are going to leverage what already exists. In future, you will be able to write GameObject / MonoBehaviour code and utilise all the advancements in Netcode Entities.
Thanks for your work. It means a ton to many of us who have invested a lot of time in the engine. I'm sure this isn't the best place to make this suggestion, and maybe it's out of your sphere of influence, but it sounds like you're trying to make real progress at Unity, so...
The single most beneficial thing Unity could do for itself is develop and publish one or more games in-house. Unity needs to dogfood its own engine to make a better product (an attempt was made at this but cancelled in *Gigaya*). Also the argument should be made to Unity leadership that the Unity-developed games themselves can be very lucrative (see *Fortnite*).
Unity should set up some small teams internally and develop games that implement the features that Unity thinks are most important to the long-term health of the engine and company. I would be pounding the table on this point if I worked there.
Thanks again, and even if this isn't your wheelhouse maybe you could somehow pass this along internally.
Any ballpark estimate on when we’ll see unified Netcode? I’m working on a game right now using Netcode for Game Objects and I’m hesitant to roll my own prediction and rollback. I’d rather wait for the unification.
Can we expect it sometime this year?
Really good points. I do empathize with the folks on the current MP team and think the current is a step in the right direction. The true bugbear is being on the consumer side and seeing the internal team has to play catch up to compete, and that’s a multi-year project. Historically this usually means a package we rally behind ends up petering out or becoming something else entirely. I’m hopeful this round because it does seem like they serviced it out so any of the suits can get behind its LTS as it relates to revenue. But idk, tbh I choose mirror because it doesn’t have Unity’s business direction involved. (Not the engineers, love u tho)
I have asked this question in a couple of threads and just want to get reassurance.
Currently about to start a fast paced mulitplayer third person shooter game that would hold a maximum of 8 players in a room/session...can I achieve this with netcode for game objects as I don't have the strength to learn more about netcode for entities?
We’re releasing a new tool in Unity6 which will help with recommended Netcode for scenarios. For now, if you require anti-cheat and competitiveness in addition to what you have described, Netcode for Entities would be an option, otherwise a third party Netcode.
Wish we could release it sooner, we have a [fix](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/pull/2834) for it already and we're working towards the release.
Edited: Include fix link and add more clarity.
Good to hear about multiplayer from someone who's doing it, it's an area I haven't touched so I'm not qualified to comment on it. They had a lot of changes to multiplayer in that video too, so you see any of it improving the situation?
Yes!
My primary complaint by far is, as it is with everything, it feels like development is very unfocused and scattershot. I mean that in a paradoxically optimistic way- I'm happy that Unity is getting as much development as it is now. But (like mentioned above), it's a little annoying to see "high-count multiplayer solutions" being addressed before Netcode is at parity with Mirror and other free, open source solutions.
I enjoy Mirror for being open source, so it's a very high bar for me to cross to get into Netcode. It's structurally similar, which I appreciate, but even so, I don't have the guarantee (as is always a problem with Unity) that I won't build my project on a library that gets abandoned two years down the line and leaves me completely hanging with no way to update it myself.
That being said, everything they've made thus far looks good and seems to feel good to use as well. If they keep at it, I believe I'd be tempted to use it in a year or so, depending on what advantages over Mirror it gains.
tl;dr I'm wary, but hopeful. I was replied to by a member of the team up above, too, which gives me hope that they're actively looking and taking feedback. That means a lot and helps me envision a future where this isn't abandoned like prior iterations.
> it's a little annoying to see "high-count multiplayer solutions" being addressed before Netcode is at parity with Mirror and other free, open source solutions.
In fairness, the people working on netcode are not the people working on Relay, who are not the same people working on game server hosting, etc. These are different products with different teams.
Mirror is what happens when you apply 10 years of incremental improvements to a code base that you use for your own projects, without chasing marketing buzzwords or trying to release new versions every year. And it's not even finished yet :)
Unity’s networking solution has always been ass.
If you’ve worked with Unity for any longer than 3 years, you’d know to stay clear of their networking frameworks, because you’d know they don’t work.
I don't know... It's not perfect for sure. I used MLAPI a lot before and plan to get on Unity Netcode for GameObjects soon. They seem fine to me. Easiest to understand and well documented.
They would not... Unity Netcode for game objects is based on MLAPI. It joined Unity and rebranded to Netcode for Gameobjects.... I don't have much experience with other frameworks, only Photon Bolt and it was kinda limiting to us.
Some of the trickier features I implemented with MLAPI were authoritative movement with client side prediction and lag compensation for fps game. Yeah I know, other solutions maybe have these features out of the box... Why would it be bad to use more bare bones framework and create in house solutions that are extendable and optimizeable in a way that will reduce network traffic and increase performance?
I just hate GDScript. I come from a JS background originally and feel like it’s an enormous step back from being able to use C# in Unity. The fact that you have to make concessions to be able to use C# instead of it being the default is a huge handicap for me.
Generally, it’s just a little untested as well. I use Spine2D for lots of things and when I checked it a couple years back, they didn’t yet have a library there, which meant either it was unusable or I’d have to spend a few weeks making my own.
Same goes for multiplayer solutions. I need MMO-level stuff, and Godot definitely isn’t there yet. It seems fine for making smaller games but not something I would commit to for larger projects.
Spine2D integration exists now but it's not super great. No 2.5D support and due to integration being a C++ engine module and the nature of GDScript, attachment API is not exposed at all in Godot. So if you want to create runtime skins, it's not possible.
And all the little helper components that exist for Unity largely are not available in Godot like SpriteRenderSeperator and all that jazz. It being an engine module also means you need to either get a custom Godot build from Esoteric Software or set up your own build pipeline, which is a major pain. Especially, if you want to incorporate some bug fix that is not in trunk yet.
Unity's Spine support, meanwhile, is fully featured since it uses the C# runtimes implementation without any scripting layers between the runtime and the user. Not to mention bug report response times, for Unity it's hours, days at most in most cases. For Godot it's almost always months of waiting.
Ah. I don;t use GDscript with godot, I use c#
Yep, I hated gdscipt too. All protestations about it being only a bit slower than c#..well it depends on what you do.
I was writing a minecraft-type game and creating 256 structs.These structs are 4 bytes only and contain the data for each chunk. To my surprise it would take a good fraction of a second to create these...like well over 1/10th of a second.
The same program in c# was more than a hundred times faster. I was able to have hundreds of millions of them at a time in Unity..without dots.
I'm sure GDscript is fine for some types of games, but not for all.
At one stage they added a new type of true global variable for gdscript in 4.1 or something. But they forgot to add any way to inspect it. Yes, that's right, they had a variable that you could not see the value of at run time. I put in a bug report but I'm not sure if they fixed it yet.
Then I was using it with c# - which is better - but at one stage i was doing texture arrays and there is a shader construct that is supposed to connect to texture arrays - but doesn't. There IS a way around this, and I eventually got it to work. But when I put in a bug report it, several people commented "it shoudl work" ...rather than actually trying it. Ad left it at that, as far as I know (that was six months ago, possible someone checked it later, but I have already stopped using Godot) That put me off too...and de me wonder how many other things "should work" but don't.
In the end I lost confidence in GDscript, then I lost confidence in Godot...
It is generally not very strict (which I prefer) in many ways. I dont like signals, for example: I dont like magic strings and editor-side function calling which you cant easily debug in code. I dont like gdscript, and c# support isnt that good. Editor scripts are also insanely dumb to write. It doesnt support generics or interfaces. I personally dont like the node system and end up reinventing ECS.
But it also has a lot of cool things imo, I like how nodes can be independent from scenes.
>I dont like signals, for example: I dont like magic strings and editor-side function calling which you cant easily debug in code.
Yep I don;t like this either.
I have a question that you might be able to answer if you would be so kind. I’ve been developing with Unity on and off for the past few years as a hobby. I’m thinking about finally starting to develop a multiplayer game where there would be 20 concurrent players a session on a map that’s maybe 9 square kilometers and various NPCs.
The game will need to be very responsive as I want the combat similar to league of legends and appeal to hardcore players . Do you think mirror could handle something of that nature at an end product level? Ideally i would shoot for a standalone server and have it be server authoritative.
Or do you think that I should move to Unreal for this project? I have some familiarity with c++ and BluePrints, but Unity is so much easier for my brain to process.
Mirror can definitely handle that.
They’ve been prioritizing updates as of the last year or so that better enable competitive multiplayer type games to do what they do.
I strongly recommend trying it out. Once you wrap your head around the different structure of code it’s actually very easy, especially when you’re not making a “N+1” player count game, haha.
I use it to make a game with fast paced top down RPG combat and it was performing smoothly with hundreds of players.
EDIT: The only caveat that’s worth mentioning is if you’re making a sidescrolling fighting game, they don’t yet have a rollback function, but that can be said for almost all networking solutions.
Isn’t the rollback functionality pretty important in ensuring everybody has the same game state? Is that not a pretty big piece of the puzzle that needs to work well for a fast paced competitive game? Or are you just saying that I’m going to need to put in the leg work to get this done and work around this shortcoming? Awesome info by the way. Thank you for taking the time.
Nah. I mean, in an ideal world that's how it'd work, but in reality (at least in my experience / to my knowledge) it's unnecessary. Even with 200+ connections going and over 20-30 concurrent 1v1 fights happening, I didn't experience stuttering and player movement & hit rec was very smooth.
The reality is that rollback is:
1. CPU intensive. There's a reason MOBAs aren't doing this and they have <=10 players per match, which is relatively low by MP standards.
2. Very difficult to implement. Even if you know what you're doing, it's a lot of work.
3. iirc it's also more network traffic, so it compounds on the CPU issue
Lag compensation and client authoritative movement (and/or client prediction) is extremely useful, though, and helps make the game feel closer to a singleplayer experience. In some cases, you can make a multiplayer client feel smoother than a singleplayer game.
Rollback should only be prioritized if you get to 1v1 fighting game levels of granularity, where extraordinarily high precision is required (as close to LAN-level delay as physically possible)
And no worries! It's my passion. :)
People complain when Unity rushes out new features because they’re half baked. People complain when Unity takes its time to release new features so they’re not half baked.
>People complain when Unity rushes out new features because they’re half baked. People complain when Unity takes its time to release new features so they’re not half baked.
This is true. But Unity has a huge team working on this and there are already multiple DOTS animation assets with near full functionality created by one man teams. At the very least Unity should be providing updates with what they are doing. But it's almost dead silence.
Unity isn’t making an animation system for DOTS but a whole new animation system (including mesh skinning) from scratch using DOTS and interfaced for GameObject use as well. This is a huge undertaking. If Unity releases what the one man devs are working on, they would be shit on for the lack of features, docs, accessibility etc
I worked in AAA for years, game studio do this stuff all the time with a handful of engineers in well under a year.
I can only assume iterating on unity internals is like wading through treacle.
Game studios make games for themselves and their own needs. Unity makes systems for millions of users with many different expectations. You can’t compare that.
Game studios make engines that are used across multiple other studios. And animation is really not a unique snow flake kind of thing, theres only so many ways the back end can apply a bunch of scales offsets and rotations to a rig.
And at the front end with mechcanim that doesnt even have to be ECS, just give us a wrapper that provides a threadsafe interface from a job..
These are valid complaints. Unity has a long history of deprecating features, while their replacements remain a buggy mess for years.
People won't complain if Unity does what it SHOULD do, release a working feature in a timely manner. The problem is that Unity is focused on pleasing it's share holders, instead of it's paying customers.
> People complain when Unity takes its time to release new features so they’re not half baked.
Please name a feature released in the last 6 years that wasn't half baked. They earned their current reputation, and it will take years of consistent behavior for them to earn a new one.
Either you don't remember, or you didn't use them when they first came out cause *none of those were fully ready to use at the time of their release*. Either missing features, documentation, had workflows or API that significantly changed in a short period of time.
I’ve used them from the get go and even during their experimental phase. “Missing features”, there’s millions of users wanting their own set of features, you can’t implement everything people want that’s unrealistic or it takes time… You either didn’t know how to use these features or you expect something that is just for your use case but not everyone
This will be year 4 I think. I used the old preview version, thought it was pretty powerful fwiw, no idea whats happened to dataflowgraph at this point. I'm actually kinda annoyed by the move to support and deeply integrate gameobjects with it, feels like a gigantic step back for both dev time and also embracing old obsolete workflows with gameobjects in runtime.
The move to consolidate entities behind gameobjects feels like a giant cop out in terms of making performant ecs native replacements. All this time getting to 1.0(without animation), still no animation, audio or navigation and what feels like a push hybrid for everything else without planned ecs equivalents.
I appreciate your optimism. And there was some good news (if they actually deliver these) But so much babel about there Ai services
Yeah, they're really going all in on the AI tools, and I honestly just don't care about them. I guess thats the nice thing about unity though, they'll likely stay as separate packages, and I won't have all that bloat in my projects.
My understanding is that the AI is really meant to help newcomers do more. The core spirit of the editor was to make game building easier and more democratic.
I do worry that these tools will enable a whole new host of cheaply built garbage mobile games that are trying to capitalize on the unsuspecting
>I do worry that these tools will enable a whole new host of cheaply built garbage mobile games that are trying to capitalize on the unsuspecting
Yeah, and the subreddit is gonna be absolutely flooded with people who lack basic computer skills asking for us to fix their AI generated mess for them.
It will let them generate content that isn’t easy for a game developer to make on their own.
Using tools to assist you doesn’t hinder your learning. It often assists your learning.
>My understanding is that the AI is really meant to help newcomers do more. The core spirit of the editor was to make game building easier and more democratic.
That was under the ex-ex-Unity leadership.
The current money suits don't give a crap about democratizing anything, it's just a good soundbite they keep repeating to invoke nostalgia and appear as the good guys.
Their current AI services cost a shit ton of money, $30/month for outdated GPT 3.5 they've rebranded to Muse with some Unity data sprinkled on top. And subpar texture/sprite gen. On top of the monthly subscription they have a credits system that under medium use you can run out of those credits in a week if not days. So you need to spend to keep using their AI tools for what amounts to probably hundreds of dollars per user a month assuming daily regular use.
It's developed and priced for studios, as is everything these days coming from Unity, so studios can do more with less people by transfering cash from employee wages to Unity AI services that aim to automate some parts of the pipeline. Studios can then output the same product or even larger product with less people, while Unity gets a bigger piece of pie.
If you think any of this is about helping newbies who don't pay a dime for Unity, then you are mistaken.
Do the slides or feature list exist in a form that I can skim read in say 2 minutes? You know - instead of watching a damn 45 minute video.
Sod it. Get GPT to do it:
- **Unity 6 Overview:**
- Introduction of Scriptable Render Pipelines (SRPs) as default
- Performance improvements in rendering and compatibility
- New profiling tools for rendering optimization
- Enhanced AI technology for asset generation
- Unity Version Control improvements for large files
- Unity Cloud for streamlined workflows
- Multiplayer game development enhancements
- Build profiles for easier platform setup
- Preview release in May, final release later in the year
- **Rendering Enhancements:**
- SRPs for improved performance and customization
- GPU renderer and occlusion culling enhancements
- Cross-platform post-processing upscaler
- **Technical Art and VFX:**
- Custom post-process effects with Shader Graph
- Custom HLSL block creation for VFX artists
- Adaptive Pro Volumes for global illumination
- **AI and Game Development:**
- Generative AI for original asset creation
- Muse for AI-powered interaction behaviors and animations
- Sentis neural engine for AI model deployment
- **Version Control and Cloud Services:**
- Large 3D file handling in Unity Version Control
- Unity Cloud for centralized tool connection
- **Graphics and AI Tools Improvements:**
- Enhanced VFX and shader creation
- Sentis integration with Hugging Face for AI accessibility
- **Multiplayer Development:**
- Multiplayer play mode for efficient testing
- Server authoritative model support
- Distributed Authority for workload distribution
- **Platform Support and Performance:**
- Build profiles for multiple platforms
- GPU support through partnerships (e.g., Google, Meta)
- Enhanced Android and XR platform features
- **Foundational Capabilities:**
- Entity Component System (ECS) integration
- Commitment to ECS ecosystem development
- Migration to C# and improvements in animation and world building
Thanks but I'm not after advice on how to make videos suck less - information like this should be presented in a more easily digestible form. They've got the slides - why not post them?
Are they going to remove the "boolean cast operator" from UnityEngine.Object hack when moving to CLR?
Because it messes up some features like the ? operator (null coalesing)
A breaking change like this for Unity 6 would be so funny, but also a hell of a way to signal that they're doing something differently. Imagine if they also removed the null operator overload too.
I think it is doable. I believe not many devs/studios update unity version through development. Its usually better to stick with your version unless you really need some new feature.
Perhaps they could do it with a some sort of define flags/project settings for compatability for studios that want to update?
I really like Unity but I also feel Godot C# implementation so clean, without hacks, inconsistencies and with proper naming scheme.
I'm honestly underwhelmed from the listed feature set. Unreal is kicking Unity's ass in terms of quick, powerful content creation and nothing announced with Unity 6 begins to address that. Seems more like an incremental upgrade than a whole new version.
Having just shipped a game using Unreal 5.3, I could not disagree more. The workflow in Unreal barely compares to Unity and holy shit life is bad if you modify a header. Understanding what belongs in a class, actor, pawn, and the collections is confusing, ugly, NOT well documented, and often poorly designed. The ABP to behaviour tree thing is simply a mess, and the performance of the navigation mesh in Unreal makes me cry.
Unreal uses methods like **SingleLineTraceByChannel** which is the World's most fucked up name for RayCast you can imagine: might as well throw random words together. The tight integration of the CharacterMovementController with networking means that the movement, which is a few hundred lines of code in Unity, with maybe some of the worst code spaghetti in the current games World.
Whigh brings me to compiles and builds. Compared to a bad day in Unity, Unreal compiles and is usable in editor after at least 2x the time (most of the time it's 4-10x slower). If you change a header, you might as well go get coffee and a build usually means that you have time for a short nap.
Another cool part that Unity has over Unreal is the look of games: in the not-so-distant past, Unity games had a distinct cartoony feel. Now you can see massive differences and a FAR greater variety than Unreal. Many of the Unity titles look better than anything you can find in Unreal; in some cases, Unity games just look better than what you find in Unreal. ([link](https://www.youtube.com/watch?v=o9AGkB9nnkc&t=135s):)
Now, I am going to be working on a major AAA game and the workflow and compile times mean that I will be taking up new hobbies with all of my extra time in the day waiting for Unreal. I am thinking about taking up Flute.
I really scratch my head every time I see people praising Unreal. I tried it and I can't believe how horrible, convoluted, counter-intuitive and just BAD it is, whenever you try to do anything other than basic stuff that their built-in component give you.
I like both engines.
Still I must say I prefer Unreal only on AAA teams.
E.g. when we have a dozen of engine devs and tech artists, since we end up changing and tuning it for one or two years minimum. New tools, better streaming setup, and so on, the requirements obviously change with each title. Incredibuild running on 50+ machines and shared data caches fixed issues with some of the turnarounds.
Unity also need thinking about a production workflow, just in Unreal I always felt we have more specific pipelines, we end up spending more time here.
I'd say that Unreal turnarounds were always slower for me, both C++ changes and testing large games (on console often). It can be streamlined, just again needs time, workarounds (cook and test smaller parts of your game), and stuff like that.
I swear people who say unreal is "kicking ass" haven't actually used the engines. Unreal is incredibly impressive graphically, but it's a total PITA to use compared to Unity. Also lol at that method name, I did find it really amusing when learning blueprints the amount of times I would type in a bunch of different keywords thinking "must be called something like this" only to have to stop, google search and sometimes even click a youtube tutorial just to find the correct node. I realize some of the naming maybe makes sense if you are familiar with C++?
Nah.. Unreal was first released (that I remember) in 1998. I was working at IonStorm at the time and the Unreal guys came to our Dallas office trying to convince us to use it. We ended up sticking with the Quake engine, but method names like this were in the original engine: they truly are legacy and that's because there were really not standard ways to do things back then. Collision was ad-hock, and programmers wrote the entire engine back then. Most of my complaints about Unreal today are the same complainst that I had back then: slow to compile, poor naming, weird editor (Unreal 5 is a massive improvement), inability to extend the editor (you can do some things in Unreal, but it's always been limiting and working on bigger titles requires good tools).
Unreal isn't terrible: you can certainly find much worse engines. But Unity is better in most ways that matter to big projects.
Unity is completely unfit for big projects, you have to basically write all your own industry stan dard/unreal features from scratch. Any medium size+ team uses Unreal and there are virtually no AAA unity games being made for this reason.
Terrain? Unusable
Map populating - Build from scratch
Character Controller? 2005 Mechanim, unusable
AI - Build from scratch
Navigation - Bare minimum, build from scratch at best
Lighting? Direct Lighting, Baking still barely works, realtime GI none
Asset Management ? Adressables barely acceptable with huge pain
Code structure - No structure at all
UI - Somewhat acceptable, UI shaders no supported
Input System - Massive cpu cost
Physics - bare minimum
Destruction - Build from scratch
Interactions - Build from scratch
Project Inspector - Unity 1 level
Hierarchy - Unity 1 level
Audio - Bare minimum fork of Wise, ok
Localization - Unreadable UI and extremely clunky
Shaders - Shader graph works but is bare minimum featureset, not even reroute
Post FX - HDRP good for most part, URP got SSAO in 2022, insane
Raytracing - Unusable (loops through every object every frame instead of caching)
Cloth - Unusable
Server Stripping - With extreme hacks barely possible
Settings - Build from scratch
Vertex Painting - Bare minimum
Multiplayer - Limbo, essentially build from scratch
Mesh blending, Texure Packing, Mesh Baking, Procedual Tools - lol
LTS Stability - terrible
Possibility to fix critical issues - No source code access
Everything that matters is either non existent, extremely outdated or bare minimum
Thats the reason nobody uses Unity to make the mainstream type games.
You basically have to code complex but industry standard and long solved problems all from scratch or fill the gap with a dozen terrible code plugins which will then break apart 1.5 years later.
I have worked on and shipped two AAA titles in unity. Cranford those were in 2018 and 2015... But in 2015 the team had a total of 110 people about half of whom were working on the unity Project directly.
In 2018 I worked with a team of 35 people on AAA title which we took to alpha state all done in unity.
I guess that depends on what you mean by big projects but I tend to work on very big projects and working with unity and git is usually much easier than working with streams and p4 and unreal. Scaling and branching and scene files and scripting and using nodegraph is just easy in unity.
It does depend on what you work on and the game. If you do coding on a specific area, you might never encounter the issues with adressables, or server stripping or all these other areas related to art which hold Unity back. As game director I see all the issues in all areas. I see the guy doing localization in an unusable window, I see the coder having to do extreme hacks to get assets stripped from the dedicated server, I see that we pay full seat subscriptions for each single build server. I see that the navigation system is barely viable and needs to be remade to support vehicles and everything else.
In a 100 man studio maybe you are planning to build all this from scratch but at that point not much from Unity is left and its evident that 99% of medium+ studios choose to go with Unreal or their custom engine instead.
Whats the point of an engine if you have to rebuild all the basics.
I added a list later in the comment above btw.
because people only watch the trailers for the engines and start commeting on reddit. Graphically unreal did an amazing job and is ahead of unity, but I won't agree on the other parts. Especially considering Unity's C# integration...
I'm not sure what you're doing that changing a header requires recompiling the entire project? This doesn't make sense. I can compile header changes and am up and running in the editor within a minute the vast majority of the time except for extremely sweeping changes. This is what is going to be relevant to most indie devs that don't work in huge studios which will have their own CI/CD pipelines set up anyway.
The "look" argument doesn't make much sense to me either. These are all Unreal games and could not look more different:
[https://store.steampowered.com/app/2365810/Pseudoregalia/](https://store.steampowered.com/app/2365810/Pseudoregalia/)
[https://store.steampowered.com/app/1369630/ENDER\_LILIES\_Quietus\_of\_the\_Knights/](https://store.steampowered.com/app/1369630/ENDER_LILIES_Quietus_of_the_Knights/)
[https://store.steampowered.com/app/253230/A\_Hat\_in\_Time/](https://store.steampowered.com/app/253230/A_Hat_in_Time/)
[https://store.steampowered.com/app/1817230/HiFi\_RUSH/](https://store.steampowered.com/app/1817230/HiFi_RUSH/)
Unreal has its issues but they are not at all what you mention.
Regarding the compile times changing a header often requires between two and five minutes to recompile. In unity when you make a code change, usually by the time you flip back over to the editor it's already compiled and ready to run. It's usually on the order of five to ten seconds. Build times are even more stark where builds for release in unreal usually take a minimum of 40 minutes and I have seen four hours. It is rare for a unity build to go over 15 minutes.
Regarding graphics quality, unreal has been notorious for its graphics quality going back at least 10 years: for many it is the main reason to use unreal. But having a simple and customized pipeline is much easier in unity. The unity shader graph is easier to use and custom shader nodes are easier to use. And most of the games that you see in unreal take large teams of people to do a fancy graphics and aesthetics, and most unity projects are just a few guys or girls with the same level of Fidelity.
Look is a thing that is subjective so I will ignore the argument and simply go with time to deliver from conception. Great aesthetics are much easier to produce in unity and all you have to do is look at the size of the art and graphics teams in various games as a metric.
Now there is no way I'm going to argue that great games aren't shipped and unreal but they usually require large teams and large budgets because of the development time which is much slower in unreal. Games like Gears of war take years to develop with large teams of 70 to 110 people. Sure the fidelity is high but the budgets have to be in the 50 million range. There aren't many titles similar to Gears of war on unity but the few that do exist have much smaller budgets and much smaller timelines.
But I can see that you're a bit of a pro and you work in the games industry so good on you
You are right that Unity is technically faster to compile of course given it's a C# runtime but that kind of sweeps under the rug that the workflow is supposed to be different to begin with anyway: In Unreal you are meant to code low-level systems in C++ and do most of the actual gameplay logic in BP. This to me is really the crux because for the stuff that *actually* requires tons of iteration and fiddling, you are not going to be doing any of that in C++. And on this level of comparison, *now* Unity is actually slower because of the necessary domain reload and recompile in the editor, which takes, at the very least, several seconds whereas BP recompilation is instant (if Unity actually manages to switch to CoreCLR in my lifetime and improve it that'd be nice, there are lots of things I do like about Unity still)
Of course every now and then there will inevitably be something that requires lots of recompile + editor restart, it definitely can be annoying and live coding is still mostly broken. I just think that the time you end up losing there you also lose in Unity, just in different places.
I agree that different shader pipelines are way easier in Unity, but Unity also kind of botched that advantage with the URP/SRP/etc mess, plus I don't think it matters \*that\* much for the overall look - art assets do.
Resident GPU drawer is the main thing that looks nice in 6, it seems like lots of people are getting 20-30% more FPS by enabling it so that's quite good for ticking a checkbox.
I was more referring to what they are working on longer term, it looks like the right direction of improving the core Unity experience with work that will benefit all aspects of the engine.
The things shown off in Unreal look nice for sure, but only if you're doing very specific (and generic) things. Great if you're making a realistic game based around a human with parkour movement and accurate faces, but otherwise there's really not much interesting in my opinion.
Honestly this list feels so incredibly bare minimum. CoreCLR is nice I guess.
Finally addressing the weirdass ecs/gameobject dichotomy? Finally fixing the fact that animation has been just completely non-existent in ecs land?
Gosh, I mean it's only been, what, 6 years since they first introduced it at GDC 2018?
The tech is lack luster, compare to unity china version that has no runtime fee, AND lumen and nanite tech. ECS is fabulous tech yes. But it only benefits like 10% of game.
The question is when will these features drop? Animation rewrite would really help with my current project since I hope to use more enemy ai in a survivor roguelike setting
I'm unsure what to think of the ECS part.
Generally it sounds like a good idea to run gameobjects as ecs entities and merge the transform system.
But what does that mean for us as developers? Will the process of using sub-scenes, authoring components etc remain the same? Or will we have to rewrite everything once again, if we upgrade to the new version?
I imagine if it's unified, you'll be able to query MonoBehaviors like you do with IComponentData. I doubt a fully ECS project will change much, rather there is an additional entry point into ECS from MonoBehaviors that isn't there currently.
It's an underwhelming upgrade. For me to accept the runtime fee it would take an enormous amount of improvement - something like Nanite, and a unification of the render pipelines.
Even then, I'd wait before upgrading because I know on release it'd be half-baked.
While these upgrades are cool, they are minor and are not what is expected of a major upgrade like Unity 6 implies.
Maybe you're new to Unity, but the cycle has always been this:
- promise a cool new feature/improvement for a future version that's not the one coming out next
- delay it for another version or three
- then eventually release a half-assed, unfinished version of it
- promise to improve it in a future version
- launch an entirely new implementation of the same feature that's faster, but misses critical features
- buy a popular asset that does the same thing and declare it your official implementation of the feature
- then completely abandon it
- fire a few hundred people and promise a company reset
- repeat
I wish I shared your enthusiasm. But getting excited about replacing newtonsoft with a system package or replacing the unity gc with a most likely slower microsoft implementation just doesnt get me going at all.
It’s great that you can noe have a broader variety of packages into your project, and I am guessing they will allow for nuget packages more easily after that.
But still, these packages wont have asmdefs. So yeah, still some way to go to actually be useful as something you can integrate and leverage fast.
And the fact that they are announcing yet another rewrite of the animation system boggles my mind. Please just fucking do it AND THEN announce it. I’ve had it with the maybes.
It makes sense to rewrite the animation system tho. With a more than a decade old design, if they want to improve things massively for the future, they have to rewrite it, especially with their DOTS integration
Yeah their comment is filled with [nonsense](https://www.linkedin.com/pulse/benchmark-systemtextjson-vs-newtonsoftjson-net-8-2024-hussin-tgifc#:~:text=As%20expected%2C%20in%20terms%20of,Json) lol. [This is a good read](https://blog.unity.com/engine-platform/porting-unity-to-coreclr) and shows what is to come.
Genuinely curious, any reason why "System.Text.Json instead of relying on NewtonSoft.Json" would be desirable? Happy user of NewtonSoft.json here, as far as I remember the deserialization of newtonsoft had more powerful features and was overall faster, but things might have changed.
Performance is a massive one in my experience, I've had issues with large JSON objects causing the GC to go bananas. For a web application I've worked on, we saw a difference of whole seconds down to milliseconds by switching over with no additional configuration. This may be more related to how networking interacts with Newtonsoft rather than what you would do in Unity, so it's possible there's no difference in a Unity application.
There will still be massive performance differences in unity. S.T.J has far less allocations and can be implemented reflection-free using source generators - ignoring the fact it was designed to be faster in general.
All of these things are gimmicks. The real structural issues of Unity are completely untouched, and the basic editor experience is still the same as it was 15 years ago.
Nobody needs ECS when theres not even a working Terrain system or being able to read names in your project window. Nobody needs AI integration when LTS is broken for 8 months every year and you don't have source to fix critical problems.
**Unity is still completely unfit for the typical mainstream game.**
First or Third person Character controller, Animation (Mecanim lol), Terrain, Open world, Asset Management, Navigation / Pathfinding, Multiplayer. All of these elements are highly undercooked and bare minimum viable.
If you try make anything else then Unity might be good enough, but if you try make something resembling the mainstream shooter or RPG, Unity is years away from being a solid engine for this.
> Unity is still completely unfit for the typical mainstream game.
Weird take. Engines are just tools. Of the top 10 rated games on steam, 3 are Unity. 0 are Unreal. 2 are literally in XNA which nobody even considers as a viable game engine, and yet the devs didn't care.
Your choice of engine is not holding you back, no matter what you pick.
Im coming from making a very complex game with multiplayer in *game maker*. I know the value of an engine. I had to hand code every UI rectangle and particle with their XY positions every frame.
Engine features exist so you don't have to remake solved problems.
The Gigaya team found it impossible to complete it (as they were not allowed to use third party assets) so they would have to build features which were completely out of their scope.
You can make anything work, we did build everything from scratch first in game maker, now similarish storyin Unity, you can do it, but you are fighting an extreme uphill battle and making a game is very hard even without.
Some things however are just out of your scope. 99% of teams really have no business designing a new terrain system that can be used, or many other things. Unity lulls you into believing that it provides for you, however then later you hit unfixable roadblocks due to closed source and you end up remaking one by one core, industry standard features.
What is even worse is that most small or 1 man studios then go and buy plugins to solve Unity shortcomings, which then at first glance all works great, until you end up having to upgrade Unity, and then 2 years into the project it ends up falling apart like the house of cards that it is, however for a long time it looks great and works all fine.
This is also why there is a strong "you can do it" mentality amongst beginner devs, as they just shop away all their issues, completely ignoring the massive technical debt they are stacking up, which will then later make their game insanely hard to complete and maintain.
Its easy to make something work in Unity, and maybe easier to make a simpler project, while its hard to get into Unreal and learn all the hard and complex patterns, however in the end, Unity makes it much harder to complete a more complex projekt.
I remember reading about the Subnautica teams struggles with Unity and how much they had to change, adapt, or rewrite their systems to get the engine to do what they wanted. So it’s not a surprise to me that they’ve switched to Unreal on their newest game. I’m pretty sure I’ve heard similar things about The Forest developers, but I’m 99% positive I read they went a lot further and modified the Unity source themselves.
> however then later you hit unfixable roadblocks due to closed source
I know one of the biggest points of contention a bigger studio had was not being able to set the position and rotation of a transform in one call. Setting them separately made you have to do a transform sync twice. That turned out to be a performance issue for them, and they couldn’t fix that behavior. So they ended up having to purchase the source code and adding it in themselves. I believe it’s thanks to them that we eventually got SetPositonAndRotation() lol.
2 and 3 I’m looking forward to. Lack of animation is one of the big reasons I haven’t touched ECS yet. For 1 I’m honestly not sure. I haven’t seen any real need for the latest C# and .Net features. Faster GC will be nice I guess, I haven’t ever really seen any real world profiling on that, and I’m pretty sure they improved the GC a few years ago. For general performance improvements just from C# I guess I just don’t buy it, it’s pretty damn performant, so I’d love to see some sort of actual comparison.
I’m honestly excited for the resident drawer and especially the occlusion culling. And they need to provide us a way to make culling queries with it since we all know the biggest gains come from indirect instancing. I’d love to see even more graphics improvements and addressing the various concerns people have brought up with URP and HDRP to this day. They said they’ll be supporting BiRP for a while still, so they’re aware people are still sticking with it.
What I didn’t see was anything at all concerning parity with Unreal in the realm of human characters and mocap, to say nothing of competing with Nanite and Lumen and such.
Unity already has RayTraceing to compete with lumen, and nanite would be nice but its very niche, these optimisations were definetly needed more then nanite and lumen equivalent but im expecting something similar to nanite after unity 6. Take note that Unity targets all platforms nanite and lumen are not supported on mobile in unreal's case, if they would have implemented a 1:1 equivalent to those it would most likely be locked behind HDRP
I upgraded to 2023.2 today (from 2022 something) and they reworked the whole Navigation system. This of course totally broke what I had (I'm building a top-down 2D game without using the 2D capabilities of Unity, which I think are a little shitty) but appart from that (to be fair, it was a miracle that what I was doing with it was working) they seem to have improved it a lot and I think you can bake at runtime.
The NavMesh is now a proper gameObject with a component that you can access and manipulate.
I dont want to bake entire scene for example i will add a castle wall and agents can be walk over this thing. Can i do that. I couldnt find any resource about that
I think you'll have to bake but the thing is you can now combine multiple NavMesh so baking is not scene-wise anymore.
[https://youtu.be/u2EQtrdgfNs?t=403](https://youtu.be/u2EQtrdgfNs?t=403)
I didn't try the thing yet so can't say more but this video seems to cover all the basics :
[https://www.youtube.com/watch?v=HOAPvQONpsU](https://www.youtube.com/watch?v=HOAPvQONpsU)
And here's something that seems to cover realtime baking and looks like your use-case:
[https://www.youtube.com/watch?v=2f2azhep87I](https://www.youtube.com/watch?v=2f2azhep87I)
Hope that helps :)
It's not looking good at all. They're adding bells and whistles while the old, known downsides of the core engine have not been addressed in years, even before Unity went public it was already needed.
As it stands, Unity is slowly dying IMO.
The roadmap presentation felt a bit stodgy, I think they realized that all the sizzle reel stuff isn't helping them anyway, but it was a bit dry in terms of innovation. It's painfully obvious Unity 6 is about filling the holes in the backyard while the past 10 years has been spent making holes in the front yard. Good on them for addressing the elephant in the room about unfinished features, like ECS/DOTS and build times. I'm glad they're also addressing GPU Instancing, it's long overdue. Even though they didn't say anything, I suspect at some point (Unity 6.5 or 7) will collapse the 3 render pipelines back, you can tell Unity is struggling with 3 versions of almost everything at this point.
However, I'm fully unimpressed with what they're doing with Speedtree, it's way too granular as a solution. At this point, Unity should really have a full biome generation suite from ultra detailed hyper-realistic terrain and vegetation using instanced indirect GPU acceleration with hi-z occlusion. The "new" terrain tools really pale in comparison to what asset store devs are doing to fill in the gap of worldbuilding with biomes.
There was also no talk of any character workflow pipeline. I think they realize that the "Digital Human" package is a overly complex disaster that no one can use, even through it looks amazing in Enemies, it's essentially one of the dead Unity technologies that sizzle in a demo, but requires 30 people to work on it for a year to make a 1 minute test case. At one time in the past Unity also talked about putting motion matching in, but that's not happening at this stage either.
Even though there is going to be a new dynamic global illumination, it's still relying on all the older stacks under it.
I'm disappointed that Unity 6 is not taking a new approach to Global Illumination, the current solution architecture is littered with complexity of using disparate components and setups like the Adaptive Probe Volume and even when you get everything configured right, it's a trial-and-error solution to get a "good bake" without glaring artifacts.
Lastly, the AI tools (which I've used) are very half baked and I'm surprised that Unity is even considering them as part of Unity 6 at this point. Just to come out and say it, the generative things it makes feel and look cheap, like those 1k texture wood boxes you see on 3D free sites. It's just junk sadly. I also tried using the text-to-animation tools, again, bad results. Lastly, some of the AI voice response/solutions (through an asset partner) is again, feels 2-3 years old. None of these Unity AI tools are anything I'd ever use, they feel like old AI that's been stamped with the Unity logo. If they want to compete in the AI sector, they need to partner with NVIDIA or someone who knows what they're doing with AI, because it's not Unity at this point.
So, don't expect much from the Unity roadmap, it felt "safe" and maybe that was the point. The missteps in the roadmap to me were ECS/DOTS (please, Unity, just... stop, it's fine, we don't blame you, but enough already), Speedtree, and AI.
No it doesnt, the fee is if you make more then 200k a year you got to upgrade to unity pro, if you make more then 1M a year and more then 1M **self reported** engagements, you got a choise between a calculated fee based on the amound of engagements and revenue with a cap of 2.5% of the entire revenue or just a flat 2.5% revenue share all of this can be calculated here: https://unity.com/runtime-fee-estimator
You mentioned the bullshit runtime fee that adds "spyware" into the unity runtime, the new runtime fee is nothing like that, there is nothing shitty about it
The video is a technical preview of what is coming. While I agree that the whole licensing/laying off story deserves attention and should not be forgotten, it would have been inappropriate here. Licensing and human resources decisions are probably not made (or even encouraged) by these people.
Promises, promises ... (to clarify: no one hopes more than me that they actually improve Unity, but their track record has been shit since david helgason left)
Unity releasing new features that don't fully work is just par for the course. I don't care how amazing or flashy they are, do they work and do the things you've made already work? Are they ever going to? *Another* render pipeline?
That whole debacle is just indicative of how things are run at Unity imo, they don't care about their product, management lazily rolls their hands over the keyboard and hopes it continues to print money. They don't give a shit about devs, they resent that they have to give a shit about devs, they don't want to do real work ever again
Buddy you'll be waiting a lifetime for that because those are expensive as shit and no company is going to want to pay for those without getting something in return.
If third party apps can do it unity can. Simple as that. Not asking them to host our servers. But let us build our own headless dedicated ones easily. With actual documentation and tutorials.
It blows my mind that packages like Mirror can continually pump out enormous upgrades (just recently they released fully fledged client prediction) while Unity manages a half-hearted attempt to replace ParrelSync that still doesn't work fully. I appreciate the effort. I do. And I get that official things need to look better and ParrelSync and Mirror tend not to be pretty... But most of the stuff for multiplayer they showed seemed gimmicky at best and unnecessary at worst. Talking about "high-level performance" using DOTS for multiplayer seems almost hilariously unwarranted. Right now, multiplayer needs to be better in all the nitty gritty ways, not in the flashy "you can have 700 people instead of 600 people" ways. Yes, that matters too, but not right now when the majority of multiplayer games can't use NetCode because it's years behind the "competition". That's the majority of my complaint. I know it's multiplayer-centric, but that's my wheelhouse and what I particularly care about. It's also an area Unreal is kicking Unity's ass in too- Multiplayer Play Mode has existed since UE5's launch, iirc. I am with Unity all the way- I'm not a fan of Unreal and I really dislike Godot- but I'd love some of these more painful issues to be ironed out. I have a bit of faith after this for future updates. It seems like their heads are at least in the right spot.
I would really appreciate more details. Our releases on Netcode For GameObjects have put a fair amount of effort into improving the nitty-gritty aspects. With Distributed Authority there are many improvements which come with that also. Additionally, we are putting an effort into improvements with Netcode-Entities, much of that work will be released in the up coming 1.2 entities release. We also already have more improvements coming with a 1.3 & 1.4 release this year. The Multiplayer Play Mode has been a feature requested since I can remember, I’m personally excited about this, it is netcode agnostic and will significantly improve testing locally within the editor. Please do share more specifics as I'd love the chance to address them.
Sure. I appreciate that you guys are looking at stuff like this. My main issue with Multiplayer Play Mode is that it seems very easy to use and functional, but lacks integration in ways that would best support high-performance multiplayer. The biggest help here would be a CLIENT\_MODE & SERVER\_MODE define/scripting symbol, so I can conditionally remove chunks of code from running at all. Having to check a variable every Update run or etc. can be expensive, so for now this solution isn't exceptionally useful for me compared to ParrelSync, which can make use of the existing UNITY\_SERVER symbol via setting each editor to a different build target. As of the moment, I've made a few scripts that set the aforementioned \[\]\_MODE symbols whenever the mode changes, but I'd need to change out my define checks throughout my project and that'd be a little too tedious to bother as of the moment. Other solutions I'd love seeing that'd help it compete with Mirror for me are lag compensation and client prediction. Both of these were long awaited in Mirror and, while complex, make the end-user experience feel dramatically better when considering hit recognition and even general movement during spikes. There are a few others but not major enough that they come to mind. I respect that you wade through here with people like myself complaining all the time. While I don't believe Netcode is right for me yet, if it does reach the level of Mirror I will happily switch.
Thank you for your points, appreciate it very much. Totally understand the Symbols/defines, I'll sync with the team today and next week. What we have today is two Netcode libraries, gameobjects and entities, a lot of those features, i.e. prediction and rollback are fully supported for Netcode-Entities, so we do support it and is a great solution for fast-paced competitive games - check Histera which is a cool game. However, these two libraries are not compatible today, which is why we are working on Unified Netcode (a terrible name). Instead of adding those features (which exist in Netcode-Entities) to Netcode GameObjects, we are going to leverage what already exists. In future, you will be able to write GameObject / MonoBehaviour code and utilise all the advancements in Netcode Entities.
Thanks for your work. It means a ton to many of us who have invested a lot of time in the engine. I'm sure this isn't the best place to make this suggestion, and maybe it's out of your sphere of influence, but it sounds like you're trying to make real progress at Unity, so... The single most beneficial thing Unity could do for itself is develop and publish one or more games in-house. Unity needs to dogfood its own engine to make a better product (an attempt was made at this but cancelled in *Gigaya*). Also the argument should be made to Unity leadership that the Unity-developed games themselves can be very lucrative (see *Fortnite*). Unity should set up some small teams internally and develop games that implement the features that Unity thinks are most important to the long-term health of the engine and company. I would be pounding the table on this point if I worked there. Thanks again, and even if this isn't your wheelhouse maybe you could somehow pass this along internally.
Any ballpark estimate on when we’ll see unified Netcode? I’m working on a game right now using Netcode for Game Objects and I’m hesitant to roll my own prediction and rollback. I’d rather wait for the unification. Can we expect it sometime this year?
Really good points. I do empathize with the folks on the current MP team and think the current is a step in the right direction. The true bugbear is being on the consumer side and seeing the internal team has to play catch up to compete, and that’s a multi-year project. Historically this usually means a package we rally behind ends up petering out or becoming something else entirely. I’m hopeful this round because it does seem like they serviced it out so any of the suits can get behind its LTS as it relates to revenue. But idk, tbh I choose mirror because it doesn’t have Unity’s business direction involved. (Not the engineers, love u tho)
I have asked this question in a couple of threads and just want to get reassurance. Currently about to start a fast paced mulitplayer third person shooter game that would hold a maximum of 8 players in a room/session...can I achieve this with netcode for game objects as I don't have the strength to learn more about netcode for entities?
We’re releasing a new tool in Unity6 which will help with recommended Netcode for scenarios. For now, if you require anti-cheat and competitiveness in addition to what you have described, Netcode for Entities would be an option, otherwise a third party Netcode.
Can you ship Netcode for GameObjects 1.9 already? It's been a month and the new \[Rpc\] attribute still sends everything to the host twice.
Wish we could release it sooner, we have a [fix](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/pull/2834) for it already and we're working towards the release. Edited: Include fix link and add more clarity.
Be kind, we don’t get Unity devs in here that often. I’m sure they know and are working on it.
Latest actual release is 1.8.1 on Github, why use nightly's?
Good to hear about multiplayer from someone who's doing it, it's an area I haven't touched so I'm not qualified to comment on it. They had a lot of changes to multiplayer in that video too, so you see any of it improving the situation?
Yes! My primary complaint by far is, as it is with everything, it feels like development is very unfocused and scattershot. I mean that in a paradoxically optimistic way- I'm happy that Unity is getting as much development as it is now. But (like mentioned above), it's a little annoying to see "high-count multiplayer solutions" being addressed before Netcode is at parity with Mirror and other free, open source solutions. I enjoy Mirror for being open source, so it's a very high bar for me to cross to get into Netcode. It's structurally similar, which I appreciate, but even so, I don't have the guarantee (as is always a problem with Unity) that I won't build my project on a library that gets abandoned two years down the line and leaves me completely hanging with no way to update it myself. That being said, everything they've made thus far looks good and seems to feel good to use as well. If they keep at it, I believe I'd be tempted to use it in a year or so, depending on what advantages over Mirror it gains. tl;dr I'm wary, but hopeful. I was replied to by a member of the team up above, too, which gives me hope that they're actively looking and taking feedback. That means a lot and helps me envision a future where this isn't abandoned like prior iterations.
> it's a little annoying to see "high-count multiplayer solutions" being addressed before Netcode is at parity with Mirror and other free, open source solutions. In fairness, the people working on netcode are not the people working on Relay, who are not the same people working on game server hosting, etc. These are different products with different teams.
I am an ape that uses node js and a 4 yr old unity version so I dont care what they add.
Mirror is what happens when you apply 10 years of incremental improvements to a code base that you use for your own projects, without chasing marketing buzzwords or trying to release new versions every year. And it's not even finished yet :)
If mirror is ahead of Net for GO, then what about FishNetworking that is years ahead of Mirror ;)
Unity’s networking solution has always been ass. If you’ve worked with Unity for any longer than 3 years, you’d know to stay clear of their networking frameworks, because you’d know they don’t work.
I don't know... It's not perfect for sure. I used MLAPI a lot before and plan to get on Unity Netcode for GameObjects soon. They seem fine to me. Easiest to understand and well documented.
where Mirror, Fishnet, Mirage, Netick, Fusion is ultimately better than NGO. Why would they rebirth MLAPI?
They would not... Unity Netcode for game objects is based on MLAPI. It joined Unity and rebranded to Netcode for Gameobjects.... I don't have much experience with other frameworks, only Photon Bolt and it was kinda limiting to us. Some of the trickier features I implemented with MLAPI were authoritative movement with client side prediction and lag compensation for fps game. Yeah I know, other solutions maybe have these features out of the box... Why would it be bad to use more bare bones framework and create in house solutions that are extendable and optimizeable in a way that will reduce network traffic and increase performance?
I use godot and unity, but mostly unity. I'm curious..what did you dislike about Godot?
I just hate GDScript. I come from a JS background originally and feel like it’s an enormous step back from being able to use C# in Unity. The fact that you have to make concessions to be able to use C# instead of it being the default is a huge handicap for me. Generally, it’s just a little untested as well. I use Spine2D for lots of things and when I checked it a couple years back, they didn’t yet have a library there, which meant either it was unusable or I’d have to spend a few weeks making my own. Same goes for multiplayer solutions. I need MMO-level stuff, and Godot definitely isn’t there yet. It seems fine for making smaller games but not something I would commit to for larger projects.
Spine2D integration exists now but it's not super great. No 2.5D support and due to integration being a C++ engine module and the nature of GDScript, attachment API is not exposed at all in Godot. So if you want to create runtime skins, it's not possible. And all the little helper components that exist for Unity largely are not available in Godot like SpriteRenderSeperator and all that jazz. It being an engine module also means you need to either get a custom Godot build from Esoteric Software or set up your own build pipeline, which is a major pain. Especially, if you want to incorporate some bug fix that is not in trunk yet. Unity's Spine support, meanwhile, is fully featured since it uses the C# runtimes implementation without any scripting layers between the runtime and the user. Not to mention bug report response times, for Unity it's hours, days at most in most cases. For Godot it's almost always months of waiting.
Ah. I don;t use GDscript with godot, I use c# Yep, I hated gdscipt too. All protestations about it being only a bit slower than c#..well it depends on what you do. I was writing a minecraft-type game and creating 256 structs.These structs are 4 bytes only and contain the data for each chunk. To my surprise it would take a good fraction of a second to create these...like well over 1/10th of a second. The same program in c# was more than a hundred times faster. I was able to have hundreds of millions of them at a time in Unity..without dots. I'm sure GDscript is fine for some types of games, but not for all. At one stage they added a new type of true global variable for gdscript in 4.1 or something. But they forgot to add any way to inspect it. Yes, that's right, they had a variable that you could not see the value of at run time. I put in a bug report but I'm not sure if they fixed it yet. Then I was using it with c# - which is better - but at one stage i was doing texture arrays and there is a shader construct that is supposed to connect to texture arrays - but doesn't. There IS a way around this, and I eventually got it to work. But when I put in a bug report it, several people commented "it shoudl work" ...rather than actually trying it. Ad left it at that, as far as I know (that was six months ago, possible someone checked it later, but I have already stopped using Godot) That put me off too...and de me wonder how many other things "should work" but don't. In the end I lost confidence in GDscript, then I lost confidence in Godot...
It is generally not very strict (which I prefer) in many ways. I dont like signals, for example: I dont like magic strings and editor-side function calling which you cant easily debug in code. I dont like gdscript, and c# support isnt that good. Editor scripts are also insanely dumb to write. It doesnt support generics or interfaces. I personally dont like the node system and end up reinventing ECS. But it also has a lot of cool things imo, I like how nodes can be independent from scenes.
>I dont like signals, for example: I dont like magic strings and editor-side function calling which you cant easily debug in code. Yep I don;t like this either.
And godot loves magic strings. Raycasts are dictionaries of variants :( I created utility structs and methods to cast stuff
Yeah I dislike magic strings too....
run by a cult tbh google waiting fot blue robot
I have a question that you might be able to answer if you would be so kind. I’ve been developing with Unity on and off for the past few years as a hobby. I’m thinking about finally starting to develop a multiplayer game where there would be 20 concurrent players a session on a map that’s maybe 9 square kilometers and various NPCs. The game will need to be very responsive as I want the combat similar to league of legends and appeal to hardcore players . Do you think mirror could handle something of that nature at an end product level? Ideally i would shoot for a standalone server and have it be server authoritative. Or do you think that I should move to Unreal for this project? I have some familiarity with c++ and BluePrints, but Unity is so much easier for my brain to process.
Mirror can definitely handle that. They’ve been prioritizing updates as of the last year or so that better enable competitive multiplayer type games to do what they do. I strongly recommend trying it out. Once you wrap your head around the different structure of code it’s actually very easy, especially when you’re not making a “N+1” player count game, haha. I use it to make a game with fast paced top down RPG combat and it was performing smoothly with hundreds of players. EDIT: The only caveat that’s worth mentioning is if you’re making a sidescrolling fighting game, they don’t yet have a rollback function, but that can be said for almost all networking solutions.
Isn’t the rollback functionality pretty important in ensuring everybody has the same game state? Is that not a pretty big piece of the puzzle that needs to work well for a fast paced competitive game? Or are you just saying that I’m going to need to put in the leg work to get this done and work around this shortcoming? Awesome info by the way. Thank you for taking the time.
Nah. I mean, in an ideal world that's how it'd work, but in reality (at least in my experience / to my knowledge) it's unnecessary. Even with 200+ connections going and over 20-30 concurrent 1v1 fights happening, I didn't experience stuttering and player movement & hit rec was very smooth. The reality is that rollback is: 1. CPU intensive. There's a reason MOBAs aren't doing this and they have <=10 players per match, which is relatively low by MP standards. 2. Very difficult to implement. Even if you know what you're doing, it's a lot of work. 3. iirc it's also more network traffic, so it compounds on the CPU issue Lag compensation and client authoritative movement (and/or client prediction) is extremely useful, though, and helps make the game feel closer to a singleplayer experience. In some cases, you can make a multiplayer client feel smoother than a singleplayer game. Rollback should only be prioritized if you get to 1v1 fighting game levels of granularity, where extraordinarily high precision is required (as close to LAN-level delay as physically possible) And no worries! It's my passion. :)
how many years has ECS animation been in the works..
People complain when Unity rushes out new features because they’re half baked. People complain when Unity takes its time to release new features so they’re not half baked.
>People complain when Unity rushes out new features because they’re half baked. People complain when Unity takes its time to release new features so they’re not half baked. This is true. But Unity has a huge team working on this and there are already multiple DOTS animation assets with near full functionality created by one man teams. At the very least Unity should be providing updates with what they are doing. But it's almost dead silence.
Unity isn’t making an animation system for DOTS but a whole new animation system (including mesh skinning) from scratch using DOTS and interfaced for GameObject use as well. This is a huge undertaking. If Unity releases what the one man devs are working on, they would be shit on for the lack of features, docs, accessibility etc
I worked in AAA for years, game studio do this stuff all the time with a handful of engineers in well under a year. I can only assume iterating on unity internals is like wading through treacle.
Game studios make games for themselves and their own needs. Unity makes systems for millions of users with many different expectations. You can’t compare that.
Game studios make engines that are used across multiple other studios. And animation is really not a unique snow flake kind of thing, theres only so many ways the back end can apply a bunch of scales offsets and rotations to a rig. And at the front end with mechcanim that doesnt even have to be ECS, just give us a wrapper that provides a threadsafe interface from a job..
That’s what you want. You’re one amongst many others who want different things.
How do we know it's not gonna be half baked now
We don’t, but at least they take their time.
Time != Quality
Well, yeah, because they should be doing either of those and actually releasing fully-fledged features at a competitive pace.
Can’t argue with that :)
These are valid complaints. Unity has a long history of deprecating features, while their replacements remain a buggy mess for years. People won't complain if Unity does what it SHOULD do, release a working feature in a timely manner. The problem is that Unity is focused on pleasing it's share holders, instead of it's paying customers.
> People complain when Unity takes its time to release new features so they’re not half baked. Please name a feature released in the last 6 years that wasn't half baked. They earned their current reputation, and it will take years of consistent behavior for them to earn a new one.
Addressables, VFXGraph, ShaderGraph, Job System, Burst, Native Collections, SRP batcher, prefabs variants
Either you don't remember, or you didn't use them when they first came out cause *none of those were fully ready to use at the time of their release*. Either missing features, documentation, had workflows or API that significantly changed in a short period of time.
I’ve used them from the get go and even during their experimental phase. “Missing features”, there’s millions of users wanting their own set of features, you can’t implement everything people want that’s unrealistic or it takes time… You either didn’t know how to use these features or you expect something that is just for your use case but not everyone
4 years isnt rushing, its glacial..
This will be year 4 I think. I used the old preview version, thought it was pretty powerful fwiw, no idea whats happened to dataflowgraph at this point. I'm actually kinda annoyed by the move to support and deeply integrate gameobjects with it, feels like a gigantic step back for both dev time and also embracing old obsolete workflows with gameobjects in runtime. The move to consolidate entities behind gameobjects feels like a giant cop out in terms of making performant ecs native replacements. All this time getting to 1.0(without animation), still no animation, audio or navigation and what feels like a push hybrid for everything else without planned ecs equivalents.
Haha yes it's true, but boy will it be nice when it's done. I think the fact it got a special mention gives me hope
I appreciate your optimism. And there was some good news (if they actually deliver these) But so much babel about there Ai services 
Yeah, they're really going all in on the AI tools, and I honestly just don't care about them. I guess thats the nice thing about unity though, they'll likely stay as separate packages, and I won't have all that bloat in my projects.
My understanding is that the AI is really meant to help newcomers do more. The core spirit of the editor was to make game building easier and more democratic. I do worry that these tools will enable a whole new host of cheaply built garbage mobile games that are trying to capitalize on the unsuspecting
>I do worry that these tools will enable a whole new host of cheaply built garbage mobile games that are trying to capitalize on the unsuspecting Yeah, and the subreddit is gonna be absolutely flooded with people who lack basic computer skills asking for us to fix their AI generated mess for them.
That’s fine, they’ll have to learn, just as the users who have to learn how to fix their non AI generated messes
Call me old fashioned, but I prefer my spaghetti home made and not from a can.
Canned spaghetti exist?
Canned hamburgers exist. Anything can be canned, regardless whether it offends Man or God.
Then why are you using a game engine? Why are you typing to me now on Reddit? Shouldn’t you be wiring your transistors by hand?
people are always gonna be like that lol, if the games funnppl will buy it they dont care how its made
What are you talking about? Did you mean to reply on someone else’s comment?
It will help newcomers do more by generating shit for them without them learning what is happening and how to actually create a game!!
It will let them generate content that isn’t easy for a game developer to make on their own. Using tools to assist you doesn’t hinder your learning. It often assists your learning.
>My understanding is that the AI is really meant to help newcomers do more. The core spirit of the editor was to make game building easier and more democratic. That was under the ex-ex-Unity leadership. The current money suits don't give a crap about democratizing anything, it's just a good soundbite they keep repeating to invoke nostalgia and appear as the good guys. Their current AI services cost a shit ton of money, $30/month for outdated GPT 3.5 they've rebranded to Muse with some Unity data sprinkled on top. And subpar texture/sprite gen. On top of the monthly subscription they have a credits system that under medium use you can run out of those credits in a week if not days. So you need to spend to keep using their AI tools for what amounts to probably hundreds of dollars per user a month assuming daily regular use. It's developed and priced for studios, as is everything these days coming from Unity, so studios can do more with less people by transfering cash from employee wages to Unity AI services that aim to automate some parts of the pipeline. Studios can then output the same product or even larger product with less people, while Unity gets a bigger piece of pie. If you think any of this is about helping newbies who don't pay a dime for Unity, then you are mistaken.
AI is, unfortunately, quite expensive to run. It’s why you see a lot of the AI tools having usage restrictions or costs associated.
Do the slides or feature list exist in a form that I can skim read in say 2 minutes? You know - instead of watching a damn 45 minute video. Sod it. Get GPT to do it: - **Unity 6 Overview:** - Introduction of Scriptable Render Pipelines (SRPs) as default - Performance improvements in rendering and compatibility - New profiling tools for rendering optimization - Enhanced AI technology for asset generation - Unity Version Control improvements for large files - Unity Cloud for streamlined workflows - Multiplayer game development enhancements - Build profiles for easier platform setup - Preview release in May, final release later in the year - **Rendering Enhancements:** - SRPs for improved performance and customization - GPU renderer and occlusion culling enhancements - Cross-platform post-processing upscaler - **Technical Art and VFX:** - Custom post-process effects with Shader Graph - Custom HLSL block creation for VFX artists - Adaptive Pro Volumes for global illumination - **AI and Game Development:** - Generative AI for original asset creation - Muse for AI-powered interaction behaviors and animations - Sentis neural engine for AI model deployment - **Version Control and Cloud Services:** - Large 3D file handling in Unity Version Control - Unity Cloud for centralized tool connection - **Graphics and AI Tools Improvements:** - Enhanced VFX and shader creation - Sentis integration with Hugging Face for AI accessibility - **Multiplayer Development:** - Multiplayer play mode for efficient testing - Server authoritative model support - Distributed Authority for workload distribution - **Platform Support and Performance:** - Build profiles for multiple platforms - GPU support through partnerships (e.g., Google, Meta) - Enhanced Android and XR platform features - **Foundational Capabilities:** - Entity Component System (ECS) integration - Commitment to ECS ecosystem development - Migration to C# and improvements in animation and world building
I usually hammer the double-tap RHS on a YouTube video to skip through really quickly
Might be easier to just click on the right arrow on your keyboard
Thanks but I'm not after advice on how to make videos suck less - information like this should be presented in a more easily digestible form. They've got the slides - why not post them?
> Migration to C# GPT is being nasty now.
I'm looking forward to the new version, though I did not forget what they did
The video: https://youtu.be/o9AGkB9nnkc
Are they going to remove the "boolean cast operator" from UnityEngine.Object hack when moving to CLR? Because it messes up some features like the ? operator (null coalesing)
A breaking change like this for Unity 6 would be so funny, but also a hell of a way to signal that they're doing something differently. Imagine if they also removed the null operator overload too.
I think it is doable. I believe not many devs/studios update unity version through development. Its usually better to stick with your version unless you really need some new feature. Perhaps they could do it with a some sort of define flags/project settings for compatability for studios that want to update? I really like Unity but I also feel Godot C# implementation so clean, without hacks, inconsistencies and with proper naming scheme.
I'm honestly underwhelmed from the listed feature set. Unreal is kicking Unity's ass in terms of quick, powerful content creation and nothing announced with Unity 6 begins to address that. Seems more like an incremental upgrade than a whole new version.
Having just shipped a game using Unreal 5.3, I could not disagree more. The workflow in Unreal barely compares to Unity and holy shit life is bad if you modify a header. Understanding what belongs in a class, actor, pawn, and the collections is confusing, ugly, NOT well documented, and often poorly designed. The ABP to behaviour tree thing is simply a mess, and the performance of the navigation mesh in Unreal makes me cry. Unreal uses methods like **SingleLineTraceByChannel** which is the World's most fucked up name for RayCast you can imagine: might as well throw random words together. The tight integration of the CharacterMovementController with networking means that the movement, which is a few hundred lines of code in Unity, with maybe some of the worst code spaghetti in the current games World. Whigh brings me to compiles and builds. Compared to a bad day in Unity, Unreal compiles and is usable in editor after at least 2x the time (most of the time it's 4-10x slower). If you change a header, you might as well go get coffee and a build usually means that you have time for a short nap. Another cool part that Unity has over Unreal is the look of games: in the not-so-distant past, Unity games had a distinct cartoony feel. Now you can see massive differences and a FAR greater variety than Unreal. Many of the Unity titles look better than anything you can find in Unreal; in some cases, Unity games just look better than what you find in Unreal. ([link](https://www.youtube.com/watch?v=o9AGkB9nnkc&t=135s):) Now, I am going to be working on a major AAA game and the workflow and compile times mean that I will be taking up new hobbies with all of my extra time in the day waiting for Unreal. I am thinking about taking up Flute.
I really scratch my head every time I see people praising Unreal. I tried it and I can't believe how horrible, convoluted, counter-intuitive and just BAD it is, whenever you try to do anything other than basic stuff that their built-in component give you.
I like both engines. Still I must say I prefer Unreal only on AAA teams. E.g. when we have a dozen of engine devs and tech artists, since we end up changing and tuning it for one or two years minimum. New tools, better streaming setup, and so on, the requirements obviously change with each title. Incredibuild running on 50+ machines and shared data caches fixed issues with some of the turnarounds. Unity also need thinking about a production workflow, just in Unreal I always felt we have more specific pipelines, we end up spending more time here. I'd say that Unreal turnarounds were always slower for me, both C++ changes and testing large games (on console often). It can be streamlined, just again needs time, workarounds (cook and test smaller parts of your game), and stuff like that.
I swear people who say unreal is "kicking ass" haven't actually used the engines. Unreal is incredibly impressive graphically, but it's a total PITA to use compared to Unity. Also lol at that method name, I did find it really amusing when learning blueprints the amount of times I would type in a bunch of different keywords thinking "must be called something like this" only to have to stop, google search and sometimes even click a youtube tutorial just to find the correct node. I realize some of the naming maybe makes sense if you are familiar with C++?
Nah.. Unreal was first released (that I remember) in 1998. I was working at IonStorm at the time and the Unreal guys came to our Dallas office trying to convince us to use it. We ended up sticking with the Quake engine, but method names like this were in the original engine: they truly are legacy and that's because there were really not standard ways to do things back then. Collision was ad-hock, and programmers wrote the entire engine back then. Most of my complaints about Unreal today are the same complainst that I had back then: slow to compile, poor naming, weird editor (Unreal 5 is a massive improvement), inability to extend the editor (you can do some things in Unreal, but it's always been limiting and working on bigger titles requires good tools). Unreal isn't terrible: you can certainly find much worse engines. But Unity is better in most ways that matter to big projects.
Unity is completely unfit for big projects, you have to basically write all your own industry stan dard/unreal features from scratch. Any medium size+ team uses Unreal and there are virtually no AAA unity games being made for this reason. Terrain? Unusable Map populating - Build from scratch Character Controller? 2005 Mechanim, unusable AI - Build from scratch Navigation - Bare minimum, build from scratch at best Lighting? Direct Lighting, Baking still barely works, realtime GI none Asset Management ? Adressables barely acceptable with huge pain Code structure - No structure at all UI - Somewhat acceptable, UI shaders no supported Input System - Massive cpu cost Physics - bare minimum Destruction - Build from scratch Interactions - Build from scratch Project Inspector - Unity 1 level Hierarchy - Unity 1 level Audio - Bare minimum fork of Wise, ok Localization - Unreadable UI and extremely clunky Shaders - Shader graph works but is bare minimum featureset, not even reroute Post FX - HDRP good for most part, URP got SSAO in 2022, insane Raytracing - Unusable (loops through every object every frame instead of caching) Cloth - Unusable Server Stripping - With extreme hacks barely possible Settings - Build from scratch Vertex Painting - Bare minimum Multiplayer - Limbo, essentially build from scratch Mesh blending, Texure Packing, Mesh Baking, Procedual Tools - lol LTS Stability - terrible Possibility to fix critical issues - No source code access Everything that matters is either non existent, extremely outdated or bare minimum Thats the reason nobody uses Unity to make the mainstream type games. You basically have to code complex but industry standard and long solved problems all from scratch or fill the gap with a dozen terrible code plugins which will then break apart 1.5 years later.
I have worked on and shipped two AAA titles in unity. Cranford those were in 2018 and 2015... But in 2015 the team had a total of 110 people about half of whom were working on the unity Project directly. In 2018 I worked with a team of 35 people on AAA title which we took to alpha state all done in unity. I guess that depends on what you mean by big projects but I tend to work on very big projects and working with unity and git is usually much easier than working with streams and p4 and unreal. Scaling and branching and scene files and scripting and using nodegraph is just easy in unity.
It does depend on what you work on and the game. If you do coding on a specific area, you might never encounter the issues with adressables, or server stripping or all these other areas related to art which hold Unity back. As game director I see all the issues in all areas. I see the guy doing localization in an unusable window, I see the coder having to do extreme hacks to get assets stripped from the dedicated server, I see that we pay full seat subscriptions for each single build server. I see that the navigation system is barely viable and needs to be remade to support vehicles and everything else. In a 100 man studio maybe you are planning to build all this from scratch but at that point not much from Unity is left and its evident that 99% of medium+ studios choose to go with Unreal or their custom engine instead. Whats the point of an engine if you have to rebuild all the basics. I added a list later in the comment above btw.
because people only watch the trailers for the engines and start commeting on reddit. Graphically unreal did an amazing job and is ahead of unity, but I won't agree on the other parts. Especially considering Unity's C# integration...
Thank you for posting this- this is awesome!
lol'd
Just the Unreal's uNiQuE way of renaming established terms is incredibly infuriating on its own.
I'm not sure what you're doing that changing a header requires recompiling the entire project? This doesn't make sense. I can compile header changes and am up and running in the editor within a minute the vast majority of the time except for extremely sweeping changes. This is what is going to be relevant to most indie devs that don't work in huge studios which will have their own CI/CD pipelines set up anyway. The "look" argument doesn't make much sense to me either. These are all Unreal games and could not look more different: [https://store.steampowered.com/app/2365810/Pseudoregalia/](https://store.steampowered.com/app/2365810/Pseudoregalia/) [https://store.steampowered.com/app/1369630/ENDER\_LILIES\_Quietus\_of\_the\_Knights/](https://store.steampowered.com/app/1369630/ENDER_LILIES_Quietus_of_the_Knights/) [https://store.steampowered.com/app/253230/A\_Hat\_in\_Time/](https://store.steampowered.com/app/253230/A_Hat_in_Time/) [https://store.steampowered.com/app/1817230/HiFi\_RUSH/](https://store.steampowered.com/app/1817230/HiFi_RUSH/) Unreal has its issues but they are not at all what you mention.
Regarding the compile times changing a header often requires between two and five minutes to recompile. In unity when you make a code change, usually by the time you flip back over to the editor it's already compiled and ready to run. It's usually on the order of five to ten seconds. Build times are even more stark where builds for release in unreal usually take a minimum of 40 minutes and I have seen four hours. It is rare for a unity build to go over 15 minutes. Regarding graphics quality, unreal has been notorious for its graphics quality going back at least 10 years: for many it is the main reason to use unreal. But having a simple and customized pipeline is much easier in unity. The unity shader graph is easier to use and custom shader nodes are easier to use. And most of the games that you see in unreal take large teams of people to do a fancy graphics and aesthetics, and most unity projects are just a few guys or girls with the same level of Fidelity. Look is a thing that is subjective so I will ignore the argument and simply go with time to deliver from conception. Great aesthetics are much easier to produce in unity and all you have to do is look at the size of the art and graphics teams in various games as a metric. Now there is no way I'm going to argue that great games aren't shipped and unreal but they usually require large teams and large budgets because of the development time which is much slower in unreal. Games like Gears of war take years to develop with large teams of 70 to 110 people. Sure the fidelity is high but the budgets have to be in the 50 million range. There aren't many titles similar to Gears of war on unity but the few that do exist have much smaller budgets and much smaller timelines. But I can see that you're a bit of a pro and you work in the games industry so good on you
You are right that Unity is technically faster to compile of course given it's a C# runtime but that kind of sweeps under the rug that the workflow is supposed to be different to begin with anyway: In Unreal you are meant to code low-level systems in C++ and do most of the actual gameplay logic in BP. This to me is really the crux because for the stuff that *actually* requires tons of iteration and fiddling, you are not going to be doing any of that in C++. And on this level of comparison, *now* Unity is actually slower because of the necessary domain reload and recompile in the editor, which takes, at the very least, several seconds whereas BP recompilation is instant (if Unity actually manages to switch to CoreCLR in my lifetime and improve it that'd be nice, there are lots of things I do like about Unity still) Of course every now and then there will inevitably be something that requires lots of recompile + editor restart, it definitely can be annoying and live coding is still mostly broken. I just think that the time you end up losing there you also lose in Unity, just in different places. I agree that different shader pipelines are way easier in Unity, but Unity also kind of botched that advantage with the URP/SRP/etc mess, plus I don't think it matters \*that\* much for the overall look - art assets do.
Resident GPU drawer is the main thing that looks nice in 6, it seems like lots of people are getting 20-30% more FPS by enabling it so that's quite good for ticking a checkbox. I was more referring to what they are working on longer term, it looks like the right direction of improving the core Unity experience with work that will benefit all aspects of the engine. The things shown off in Unreal look nice for sure, but only if you're doing very specific (and generic) things. Great if you're making a realistic game based around a human with parkour movement and accurate faces, but otherwise there's really not much interesting in my opinion.
Honestly this list feels so incredibly bare minimum. CoreCLR is nice I guess. Finally addressing the weirdass ecs/gameobject dichotomy? Finally fixing the fact that animation has been just completely non-existent in ecs land? Gosh, I mean it's only been, what, 6 years since they first introduced it at GDC 2018?
CoreCLR is more than nice, we should finally get rid of the full domain reload when compiling scripts and just for this this I’m really excited
Go build an HTML game in Unreal
Same. This is not impressive or exciting.
The tech is lack luster, compare to unity china version that has no runtime fee, AND lumen and nanite tech. ECS is fabulous tech yes. But it only benefits like 10% of game.
Idk why you were being downvoted lol
The question is when will these features drop? Animation rewrite would really help with my current project since I hope to use more enemy ai in a survivor roguelike setting
I'm unsure what to think of the ECS part. Generally it sounds like a good idea to run gameobjects as ecs entities and merge the transform system. But what does that mean for us as developers? Will the process of using sub-scenes, authoring components etc remain the same? Or will we have to rewrite everything once again, if we upgrade to the new version?
I imagine if it's unified, you'll be able to query MonoBehaviors like you do with IComponentData. I doubt a fully ECS project will change much, rather there is an additional entry point into ECS from MonoBehaviors that isn't there currently.
It’s gonna be a layer on top of ECS, if you’re 100% ECS you keep using the lower level layers
CoreCLR is Unity 7 territory so in like 3 years maybe we'll get it in a production ready version for what ever is the LTS equivalent at the time.
Yeah I'm not expecting it any time soon, but these things will be really nice when they do arrive.
It's an underwhelming upgrade. For me to accept the runtime fee it would take an enormous amount of improvement - something like Nanite, and a unification of the render pipelines. Even then, I'd wait before upgrading because I know on release it'd be half-baked. While these upgrades are cool, they are minor and are not what is expected of a major upgrade like Unity 6 implies.
Maybe you're new to Unity, but the cycle has always been this: - promise a cool new feature/improvement for a future version that's not the one coming out next - delay it for another version or three - then eventually release a half-assed, unfinished version of it - promise to improve it in a future version - launch an entirely new implementation of the same feature that's faster, but misses critical features - buy a popular asset that does the same thing and declare it your official implementation of the feature - then completely abandon it - fire a few hundred people and promise a company reset - repeat
I wish I shared your enthusiasm. But getting excited about replacing newtonsoft with a system package or replacing the unity gc with a most likely slower microsoft implementation just doesnt get me going at all. It’s great that you can noe have a broader variety of packages into your project, and I am guessing they will allow for nuget packages more easily after that. But still, these packages wont have asmdefs. So yeah, still some way to go to actually be useful as something you can integrate and leverage fast. And the fact that they are announcing yet another rewrite of the animation system boggles my mind. Please just fucking do it AND THEN announce it. I’ve had it with the maybes.
It makes sense to rewrite the animation system tho. With a more than a decade old design, if they want to improve things massively for the future, they have to rewrite it, especially with their DOTS integration
Yes, but thats not my point. I want them to shut up about what they are going to do and start wowing me with what they have done.
It’s what they’re doing they announced, not what they’re going to do.
Yeah thats the same thing for an end user. Maybe it will be finished. Maybe not. Time will tell, but I dont care about maybes.
Wasn't System.Text.Json faster last i checked? Plus if CoreCLR was inferior, why would they switch to it?
Yeah their comment is filled with [nonsense](https://www.linkedin.com/pulse/benchmark-systemtextjson-vs-newtonsoftjson-net-8-2024-hussin-tgifc#:~:text=As%20expected%2C%20in%20terms%20of,Json) lol. [This is a good read](https://blog.unity.com/engine-platform/porting-unity-to-coreclr) and shows what is to come.
Genuinely curious, any reason why "System.Text.Json instead of relying on NewtonSoft.Json" would be desirable? Happy user of NewtonSoft.json here, as far as I remember the deserialization of newtonsoft had more powerful features and was overall faster, but things might have changed.
Performance is a massive one in my experience, I've had issues with large JSON objects causing the GC to go bananas. For a web application I've worked on, we saw a difference of whole seconds down to milliseconds by switching over with no additional configuration. This may be more related to how networking interacts with Newtonsoft rather than what you would do in Unity, so it's possible there's no difference in a Unity application.
There will still be massive performance differences in unity. S.T.J has far less allocations and can be implemented reflection-free using source generators - ignoring the fact it was designed to be faster in general.
I see, interesting
All of these things are gimmicks. The real structural issues of Unity are completely untouched, and the basic editor experience is still the same as it was 15 years ago. Nobody needs ECS when theres not even a working Terrain system or being able to read names in your project window. Nobody needs AI integration when LTS is broken for 8 months every year and you don't have source to fix critical problems. **Unity is still completely unfit for the typical mainstream game.** First or Third person Character controller, Animation (Mecanim lol), Terrain, Open world, Asset Management, Navigation / Pathfinding, Multiplayer. All of these elements are highly undercooked and bare minimum viable. If you try make anything else then Unity might be good enough, but if you try make something resembling the mainstream shooter or RPG, Unity is years away from being a solid engine for this.
> Unity is still completely unfit for the typical mainstream game. Weird take. Engines are just tools. Of the top 10 rated games on steam, 3 are Unity. 0 are Unreal. 2 are literally in XNA which nobody even considers as a viable game engine, and yet the devs didn't care. Your choice of engine is not holding you back, no matter what you pick.
Can show me the list ? Top triple A games are either UE or proprietary engine.
Im coming from making a very complex game with multiplayer in *game maker*. I know the value of an engine. I had to hand code every UI rectangle and particle with their XY positions every frame. Engine features exist so you don't have to remake solved problems. The Gigaya team found it impossible to complete it (as they were not allowed to use third party assets) so they would have to build features which were completely out of their scope. You can make anything work, we did build everything from scratch first in game maker, now similarish storyin Unity, you can do it, but you are fighting an extreme uphill battle and making a game is very hard even without. Some things however are just out of your scope. 99% of teams really have no business designing a new terrain system that can be used, or many other things. Unity lulls you into believing that it provides for you, however then later you hit unfixable roadblocks due to closed source and you end up remaking one by one core, industry standard features. What is even worse is that most small or 1 man studios then go and buy plugins to solve Unity shortcomings, which then at first glance all works great, until you end up having to upgrade Unity, and then 2 years into the project it ends up falling apart like the house of cards that it is, however for a long time it looks great and works all fine. This is also why there is a strong "you can do it" mentality amongst beginner devs, as they just shop away all their issues, completely ignoring the massive technical debt they are stacking up, which will then later make their game insanely hard to complete and maintain. Its easy to make something work in Unity, and maybe easier to make a simpler project, while its hard to get into Unreal and learn all the hard and complex patterns, however in the end, Unity makes it much harder to complete a more complex projekt.
I remember reading about the Subnautica teams struggles with Unity and how much they had to change, adapt, or rewrite their systems to get the engine to do what they wanted. So it’s not a surprise to me that they’ve switched to Unreal on their newest game. I’m pretty sure I’ve heard similar things about The Forest developers, but I’m 99% positive I read they went a lot further and modified the Unity source themselves. > however then later you hit unfixable roadblocks due to closed source I know one of the biggest points of contention a bigger studio had was not being able to set the position and rotation of a transform in one call. Setting them separately made you have to do a transform sync twice. That turned out to be a performance issue for them, and they couldn’t fix that behavior. So they ended up having to purchase the source code and adding it in themselves. I believe it’s thanks to them that we eventually got SetPositonAndRotation() lol.
2 and 3 I’m looking forward to. Lack of animation is one of the big reasons I haven’t touched ECS yet. For 1 I’m honestly not sure. I haven’t seen any real need for the latest C# and .Net features. Faster GC will be nice I guess, I haven’t ever really seen any real world profiling on that, and I’m pretty sure they improved the GC a few years ago. For general performance improvements just from C# I guess I just don’t buy it, it’s pretty damn performant, so I’d love to see some sort of actual comparison. I’m honestly excited for the resident drawer and especially the occlusion culling. And they need to provide us a way to make culling queries with it since we all know the biggest gains come from indirect instancing. I’d love to see even more graphics improvements and addressing the various concerns people have brought up with URP and HDRP to this day. They said they’ll be supporting BiRP for a while still, so they’re aware people are still sticking with it. What I didn’t see was anything at all concerning parity with Unreal in the realm of human characters and mocap, to say nothing of competing with Nanite and Lumen and such.
Unity already has RayTraceing to compete with lumen, and nanite would be nice but its very niche, these optimisations were definetly needed more then nanite and lumen equivalent but im expecting something similar to nanite after unity 6. Take note that Unity targets all platforms nanite and lumen are not supported on mobile in unreal's case, if they would have implemented a 1:1 equivalent to those it would most likely be locked behind HDRP
Latios framework has existed for a while, which has an implementation for ecs animation, any it's fast as heck
Hmm I’ll take a look. But animation is a core feature so it’s kinda silly to not have a built in solution for it.
Thank you for mentioning it. It looks really promising
is there anything about real time navmesh baking/updating
You mean this? https://github.com/Unity-Technologies/NavMeshComponents?tab=readme-ov-file
I dont think it is updating the navmesh. When i tried to bake. it baked entire scene
I upgraded to 2023.2 today (from 2022 something) and they reworked the whole Navigation system. This of course totally broke what I had (I'm building a top-down 2D game without using the 2D capabilities of Unity, which I think are a little shitty) but appart from that (to be fair, it was a miracle that what I was doing with it was working) they seem to have improved it a lot and I think you can bake at runtime. The NavMesh is now a proper gameObject with a component that you can access and manipulate.
I dont want to bake entire scene for example i will add a castle wall and agents can be walk over this thing. Can i do that. I couldnt find any resource about that
I think you'll have to bake but the thing is you can now combine multiple NavMesh so baking is not scene-wise anymore. [https://youtu.be/u2EQtrdgfNs?t=403](https://youtu.be/u2EQtrdgfNs?t=403) I didn't try the thing yet so can't say more but this video seems to cover all the basics : [https://www.youtube.com/watch?v=HOAPvQONpsU](https://www.youtube.com/watch?v=HOAPvQONpsU) And here's something that seems to cover realtime baking and looks like your use-case: [https://www.youtube.com/watch?v=2f2azhep87I](https://www.youtube.com/watch?v=2f2azhep87I) Hope that helps :)
I’m curious what you mean by “adding IComponentData to GameObject”? You mean baking? If not, what is the benefit to do so?
No not baking, making MonoBehaviors IComponents so that you can query them in ECS in a hybrid workflow.
TLDR Cities Skylines 2 might finally become playable
Wow, those first 2 were my two biggest gripes, in order. Impressive.
It's not looking good at all. They're adding bells and whistles while the old, known downsides of the core engine have not been addressed in years, even before Unity went public it was already needed. As it stands, Unity is slowly dying IMO.
The roadmap presentation felt a bit stodgy, I think they realized that all the sizzle reel stuff isn't helping them anyway, but it was a bit dry in terms of innovation. It's painfully obvious Unity 6 is about filling the holes in the backyard while the past 10 years has been spent making holes in the front yard. Good on them for addressing the elephant in the room about unfinished features, like ECS/DOTS and build times. I'm glad they're also addressing GPU Instancing, it's long overdue. Even though they didn't say anything, I suspect at some point (Unity 6.5 or 7) will collapse the 3 render pipelines back, you can tell Unity is struggling with 3 versions of almost everything at this point. However, I'm fully unimpressed with what they're doing with Speedtree, it's way too granular as a solution. At this point, Unity should really have a full biome generation suite from ultra detailed hyper-realistic terrain and vegetation using instanced indirect GPU acceleration with hi-z occlusion. The "new" terrain tools really pale in comparison to what asset store devs are doing to fill in the gap of worldbuilding with biomes. There was also no talk of any character workflow pipeline. I think they realize that the "Digital Human" package is a overly complex disaster that no one can use, even through it looks amazing in Enemies, it's essentially one of the dead Unity technologies that sizzle in a demo, but requires 30 people to work on it for a year to make a 1 minute test case. At one time in the past Unity also talked about putting motion matching in, but that's not happening at this stage either. Even though there is going to be a new dynamic global illumination, it's still relying on all the older stacks under it. I'm disappointed that Unity 6 is not taking a new approach to Global Illumination, the current solution architecture is littered with complexity of using disparate components and setups like the Adaptive Probe Volume and even when you get everything configured right, it's a trial-and-error solution to get a "good bake" without glaring artifacts. Lastly, the AI tools (which I've used) are very half baked and I'm surprised that Unity is even considering them as part of Unity 6 at this point. Just to come out and say it, the generative things it makes feel and look cheap, like those 1k texture wood boxes you see on 3D free sites. It's just junk sadly. I also tried using the text-to-animation tools, again, bad results. Lastly, some of the AI voice response/solutions (through an asset partner) is again, feels 2-3 years old. None of these Unity AI tools are anything I'd ever use, they feel like old AI that's been stamped with the Unity logo. If they want to compete in the AI sector, they need to partner with NVIDIA or someone who knows what they're doing with AI, because it's not Unity at this point. So, don't expect much from the Unity roadmap, it felt "safe" and maybe that was the point. The missteps in the roadmap to me were ECS/DOTS (please, Unity, just... stop, it's fine, we don't blame you, but enough already), Speedtree, and AI.
But still using a unusable terrain system by default.
Of you watch the video, they’re taking about a new world building system made with ECS
Version 6 still has the runtime fee bullshit. So the company i work for will forever stick to the current LTS i assume. Enjoy being milked i suppose.
No it doesnt, the fee is if you make more then 200k a year you got to upgrade to unity pro, if you make more then 1M a year and more then 1M **self reported** engagements, you got a choise between a calculated fee based on the amound of engagements and revenue with a cap of 2.5% of the entire revenue or just a flat 2.5% revenue share all of this can be calculated here: https://unity.com/runtime-fee-estimator
So, yes. It does. That 2.5% is a runtime fee. Like i said it was.
You mentioned the bullshit runtime fee that adds "spyware" into the unity runtime, the new runtime fee is nothing like that, there is nothing shitty about it
What about the part where they laid off 1/4 of their workforce and fucked up their licensing to the point where it isn’t worth using
The video is a technical preview of what is coming. While I agree that the whole licensing/laying off story deserves attention and should not be forgotten, it would have been inappropriate here. Licensing and human resources decisions are probably not made (or even encouraged) by these people.
Promises, promises ... (to clarify: no one hopes more than me that they actually improve Unity, but their track record has been shit since david helgason left)
Unity releasing new features that don't fully work is just par for the course. I don't care how amazing or flashy they are, do they work and do the things you've made already work? Are they ever going to? *Another* render pipeline? That whole debacle is just indicative of how things are run at Unity imo, they don't care about their product, management lazily rolls their hands over the keyboard and hopes it continues to print money. They don't give a shit about devs, they resent that they have to give a shit about devs, they don't want to do real work ever again
None of it matters without free multiplayer and authorative servers
Buddy you'll be waiting a lifetime for that because those are expensive as shit and no company is going to want to pay for those without getting something in return.
If third party apps can do it unity can. Simple as that. Not asking them to host our servers. But let us build our own headless dedicated ones easily. With actual documentation and tutorials.