Tiny-Tree, that is what he was trying to convey. I never stated DOTS is a networking framework. My first statement was about the DOTS platform and my confidence in Unity supporting and growing it, and I followed up that statement with this “DOTS is already great, it will continue to improve. At a minimum, the netcode is something we can learn from and build our own off of.” I never said DOTS is networking API, I said the Networking API or “dots-netcode/fps-netcode” for short is a part of the DOTS ecosystem.
Joe-Censored either completely misunderstood me, or is spreading misinformation and drawing incorrect parallels to aspects of programming that are completely unrelated.
For the final time I will put it as straightforward as possible so that anyone reading this will not be misinformed.
DOTS is Data Oriented Technology Stack, it is a collection of base components like ECS, Job System, and Burst that enable programming of technology with memory aligned data in mind, such that we can take advantage of fast cpu’s and memory efficient caches.
The DOTS ecosystem otherwise known that the tooling is (Dots Animation, Dots Netcode, Dots Audio, Dots Editor, … etc ).
The new networking API, excluding the Multiplay aspects is DOTS. It uses ECS, Burst and potentially even the Job system but I cannot remember seeing Jobs, i think it currently uses main thread .run().
In summation of the post above, the new netcode is called DOTS-Netcode, here is a link to a Unity published article on it, and a short quote extracted from the link
“As you see at the bottom of the flowchart, you have many options, ranging from continuing to use UNet as-is, to targeting our new DOTS-Netcode (efficient, high-level netcode) and Unity Transport Package (lower-level networking stack).”
I’ve no idea why people are arguing about Unity headless server and dedicated servers(Photon Server, SmartFox), as they’re designed for different purposes, in general, they’re not an alternative to each other.
Regarding to the topic, when are you going to release your game? If you’re going to release the game within a few months but have no idea about how to make a multiplayer game, don’t wait for it as you would not have enough confidence and guides about how to build a whole game based on a not battle-proven framework. However, if you’re an expert and willing to build a network stack based on a transport layer, say Enet or any alternative to it, then the brand new networking repo is ready to go.
As far as the OP’s question, If you are just starting to build, I would recommend to build your art assets first and prototype systems with classic unity. If you need to get going right now use an existing networking framework. Ask yourself what are your limits and what are you hoping DOTS can solve, DOTS is creating a new more modular system that will be greatly improved over previous iterations however it is not there yet. At this stage it is best used if you have experience or if you have a specific goal you are trying to solve.
I also prefer to look at it like this, I am currently on no hard deadline, I want to future proof my development. By developing with DOTS now, I am able to grow with it, and learn the ins and outs, once it is production ready, with lots of tooling, I will be able to not only quickly build asset store packages, but will also be able to put in some serious work on my project.
Now for the quick and dirty recommendation. DOTS-Netcode now known as the fps-netcode is build for FPS’s specifically. It can be used and converted, but it is definitely specced around frequent udp updates rather than less frequent tcp updates.
I would ask you, Does your game use any sort of 3D representation of characters interacting with a world?
If it does then you should use unity on the server to simulate, this will increase the difficult and cost of a multiplayer solution.
If it does not, then I would recommend writing a SocketIO or similar based webserver that handles the game logic for you. You can define all your cards etcetera using FlatBuffers or JSON, and transfer that data fast and efficiently.
Unity Transport package
I am currently developing a multiplayer FPS game based on the new Unity Transport package and it is basically working fine, but the high-level functionality (RPC, state sync, networked instances, etc.) need to be built by hand. I am still working with MonoBehaviour and not with DOTS, because I was afraid to lose too much time on learning DOTS. This works and is quite stable and performant, AFAICT. You will end up with very efficient network code as you will handcraft it to your needs. But it will take quite a bit of your development time and bugs in the networking code are hard to kill.
Smartfox Server/Photon
I have been working with both of these and I think they are both incredible. For a card game, I think it is absolutely feasible to write the server code in a different framework like Java or JavaScript. For a card game, I figure that most functionality is either server-only or client-only, as you do not have lots of 3D-world related things. If you can get along without RayCasts, NavMesh, etc. I think it is a good idea to go this way. Also very cheap.
I want to say that it is absolutely possible to combine these providers with Unity binary servers. There is an example in the SFS blog somewhere outlining how you can go about this. To me it does not feel quite right, because you will need a dedicated hosting provider then and it feels kinda redundant.
Multiplay/AWS GameLift
If you do NOT go with SFS or Photon, you will need some kind of hosting provider. Unity plans to integrate with Multiplay, but for now it seems that this is still in very early stages. You cannot get development access and there is no documentation on this. Multiplay stopped their comunity service a while ago so until this integration is done, I think Multiplay has a quite a threshold to get started. Correct me, if I am wrong here, please. Really, please correct me!
I deploy my game (again, working with Unity Transport) to AWS GameLift which does all the scaling and matchmaking for me. I am quite satisfied with it, but have not tested it under serious load. So not sure how smooth the operation will be in the end.