i searched a little bit. It seems doable. It’s possible to run unity app on AWS with headless mode (but i also hear it can’t use PhyX). but is it good to do it?
I am not talking about a lan game between several players, i am talking about something close to MMO (my target is just 50~200, it’s for special use). The good point is, i can develop the game mechanic in a game develop tool so it’s easier to test and debug quickly, which can save me a lot of develop time and i don’t have to handle another IDE. but it sacrifices performance, and i don’t know how bad it will be.
Is there any example experience you can share to me?
For an MMO you need a completely different infrastructure which unity doesn’t provide. A lot of functionality in unity revolves around visuals and physics, and when you’re running a headless server, you are not using any of them. So it’ll be a waste of resources… also, unless I’m mistaken object updates in unity happen in ONE thread, and in case of MMO this is not what you want.
I think you’ll be better off writing a server in any other language, then making unity clients for it. You can still use unity as a scene editor for this server - you’ll just need to write few extension scripts.
Basically, while trying to use unity as a headless server you have a dubious benefits and lose most of the advantages unity provides.
Anything you want to share between the game and the server should be written in a stand-alone C# DLL which you can then reference from within the game and from whatever type of server back-end you decide to build. The DLL shouldn’t have any Unity dependencies.
If you don’t have any experience with server-side concerns, probably Microsoft MVC 5 WebAPI 2 is going to be one of the better-documented and easy-to-learn approaches for a C# developer to get up and running quickly.
Learn about security and plan it early, don’t store anything important on the client, don’t trust any data from the client.
i am trying it with virtual machine now, and going to try it in AWS later. Experiment costs time, it will be better to know if there are people already tried it.
Let’s me write more details, the projects i have to make is special. Users are using a webpage on their phone to play a multiplayer game on a public monitor. When the project scale was still small, we just need to care one monitor, so we just run the game in that computer, and the server just forwards the web socket signal to the game. But now we want the single game played in several spots, so it’s no doubt that the game has to run in server. So you can imagine there will be 20-200 mobiles (hopefully) sending websocket control signal and several computers mirroring the game data from server.
It’s more about one time use creativity media so i need to make the development time low but the flexibility high. And that’s why i am thinking about directly use unity as server, receiving web socket signal, run the game, and sync with other computers.
In your case I’d put Unity on a PC driving that monitor, and have it communicate with a non-Unity server program (like I described earlier, you could use DLLs to share core functionality between Unity and the server code), and of course, your users could continue to communicate (far more efficiently) with that server program.
There is a reason good server design targets discrete, individual, request-driven, stateless behaviors – scalability and throughput. A game engine’s focus on aggressive looping performance is almost the complete opposite of the right way to handle server code. I professionally write server-side software that handles hundreds of thousands of simultaneous users from all around the world, and I’m here to tell you, if your plan is to run Unity on a server, You’re Doing It Wrong.