At the Unite CPH 2019 Keynote we showed you a demo of several new DOTS features working together. If you want to take a closer look, we have now released all the packages from the demo and the project itself. Some of the technology is very experimental at the moment. This project is coming hot off the presses and provides a snapshot of where things are right now.
You can get started by following the README file in the project.
Whoa! This is awesome! I really like the ability to make changes on the server and see it reflect on the client, so cool! Can’t wait to play around with this, been waiting for this to udpate my project to multiplayer!
Details:
I’ve checked the code, but it looks some codes are from FPS Sample.
It’s fine but I’m worried that it’s too old and including legacy codes in term of DOTS, especially compared to com.unity.netcode.
For example, I took diff “Assets\Scripts\Networking\NetworkClient.cs” between FPS Sample and DOTS Sample.
It’s almost same.
Scripts/Networking codes looks also similar with FPS Sample one.
Additionally, Assets\Scripts\Game\Main\ThinClientGameLoop.cs looks almost same with FPS Sample one.
com.unity.netcode 0.2.0 is already released and Networking codes should follow it even if ThinClient.
In addition to that ClientGameLoop.cs is totally different from FPS Sample one.
It should be good but strange since ThinClient code is almost same with FPS Sample one.
ClientGameLoop.cs doesn’t use NetworkClient.cs (It means probably uses com.unity.netcode?) anymore however ThinClientGameLoop.cs still uses original NetworkClient.cs. (It doesn’t mean use com.unity.netcode)
What is happening? This is still under migration from FPS Sample?
This is really cool to see everything working together! Will this sample be supported/maintained with future iterations of the DOTS packages? I vaguely remember someone mentioning some of the netcode scripts in here getting moved to the Netcode package at a later date.
Also, do you have plan to put detail documents about DOTSSample ? I’d like to learn practical usage of netcode asap.
Thank you very much for your efforts!
when hit play button (only 1 client with burst on) , it runs at only about 15~30 fps on my machine (3900x+2080Ti), does this sound “Performance by default” to you or i miss something?
Running in editor I would get ~8fps until I turned off job debugging and leak detection - 25fps now. I mean its still not great but at least it’s usable now. I imagine building a client and server and running outside the editor would be a lot smoother too
Be sure to disable debug exporting, and also jobs and burst debugged per that performance tip in the readme…
Also be sure you are on the correct unity editor version.
After what I assume is the initial entity conversion and maybe lighting bakeing, I was seeing good frames on a 8700k/32gb ram/1080ti/m2s
I have not done a full compile, but that would be a better way to check out performance. I will be diggin in next week ! (Friday, for the normals out there)
I was taking a look at the DOTSSample and I’m not going to lie, It has become more complex than the FPSSample.
It is seems to be more modular than before. But everything just seems too much spread out.
Also as ECS is evolving, I’ts even taking me longer to understand how the code works and what it actually does.
Also the project should use URP instead of HDRP, as it is just a sample and to understand the FPS NetCode architecture also because I’m having long build times because of those HDRP Shaders, 13.50 min~
I ran into a similar problem (Ryzen 5 3600, RTX 2060) in the editor, but performance is fine if you build a client and a server. We were able to get 32 clients and 1 server running across 4 computers at mostly playable frames.
Strangely though, the built demo runs just fine, just about 7% for the server and 5% for the client CPU load on a Ryzen 3600. But it really is strange that editor has such poor performance, hope they’ll improve it substantially.
Performance in the Editor comes down to a couple things:
Job Debugger, Burst Safety Checks & Leak detection. They can all be disabled in the Jobs menu.
By default all C# code runs in debug mode so that the debugger can be attached (Disabling editor attaching significantly speeds it up)
(They are listed in the readme for the project)
With those things configured I can get a solid 60 FPS in the editor on my machine.
Also note in the editor we run both full server & client worlds & sending packets throught the transport player via sockets. This way in the editor you actually simulate the full setup with two isolated worlds but you go through all the network layers, this is super important for ensuring that you are always testing with the full netcode rig. You can even setup Lag simulation & packet dropping this way while running in playmode.
In a real game the server & client is on two seperate machines…
With all that said, it’s clear we need to make our debugging tools faster. It’s great that they exist and make it so we can safely write multithreaded code but we still need to make sure that all this safety tooling can run at 60 FPS in the editor.
If you want to look at performance you really want to use the standalone player and run a game session with the amount of players that you want to have in your game connected. In our internal playtests we have done up to 50 Players with solid > 60 FPS. So far it was simply limited by amount of people to get into the playtest. Clearly we are going to scale that up a lot more. Make many moree optimizations etc.
Also there is a million things we want to improve in the game code. We learnt & already improved a lot of things from going through the process of shipping this sample. This is just the first release, there is still a lot for us to do of course.
We are not done, but we want to share early for those who want to see how the sausage is made and figure out how a larger FPS game can be structured with DOTS.
Our goal with this game in particular was that we would like to run the server on a single core. We want to prove that you can have very cheap server simulation code and that implies running multiple games on the same machine.
For now we do this by using .Run(), in the future we want to use Schedule() and at compile time switch it based on a build setting. So on the client it runs multithreaded and on the server it runs on a single core.
So you are saying that the server should stay single core ? On a server machine, why would we limit ourselves to only one core ?
A reason I can think of would be if we want to run one server per core on the same machine, is this what on the roadmap?
Probably. I think problem with multicore server is jobs will fight for resources and some simulations will wait resource freeing until other server instance already processing that, it of course can be solved, but not trivial I guess.
This really completely depends on each game. But generally speaking if you have a server with 16 cores, it would be great if we can run the game at 60 FPS on instance of the server pinned to each core. Server cost is certainly a massive problem that we would like to solve with DOTS.
I am not saying every game should do that. Some games want massive simulation and would like to use all the cores on a machine. DOTS makes that easy. For now the game code mostly uses .Run. But we want to make it configurable at build time instead if you run multithreaded or pinned to a single core.
