Interested in using Unity for a Demo Application

I've done a bit of searching and looked through the docs but didn't specifically find what I am looking for so I thought I would ask.

I need to put together a demo for a game. The game needs a backend server that handles all of the collision detection and world state but not any of the avatar data beyond an identifier.

Can I run a headless version of Unity as a collision detection/world state server? Does it require a full 3D instantiation of the world to do so? Our Windows Server 2008 server only has a Rage Pro XL 8Meg video card in it as do many Server 2008 servers. What are the minimum server requirements if it is even possible to run Unity in a server mode?

I'm looking to have a server and 2 - 3 Unity client 3D apps connected to it but the server has to be stand alone and not a full client application in and of itself. I have no need for audio, textures, meshes(beyond what's used for CD), UI elements, etc etc on the server. I'm envisioning the architecture to look like the attached diagram.

Can I do this with Unity 3D out of the box from a networking standpoint? I know I can access the web services using WWWForm so I am good there. I know I can write the web site and the custom server so I am good there. I can probably reverse engineer the communication protocol enough to get the Unity server to think the custom server is just another Unity 3D client. Comments would be welcome and thanks for your time.

 

Welcome to the community!

I don't see why you'd want the "custom server" part unless you figure it'll have a workload combined with the unity server which exceeds the capabilities of the server hardware - in which case having that custom server on a different machine hooking up to the unity server would make sense.

If not, I'd just merge the whole shebang into the unity server. Unfortunately you cannot run a unity server headless. However you needn't render your world on the server either, so what I do is simply turn off the camera = no rendering done.

Since unity uses .net, you have access to sockets which will let you set up any custom communication you need besides what the WWW class and standard unity networking offers (which is a flavour of RakNet by the way).

Finally, your diagram is missing one component: The MasterServer. This server simply facilitates connections between clients and servers - doing nat punch-through and everything. You can either use the standard MasterServer which is hosted by UT and used by everyone testing their unity networking or you can compile and set up your own custom MasterServer.

 

Ah, didn't think I needed a master server if there was only a single game server running and it was in a static location. Not a big deal though if it's required. Can you modify the master server through scripting or make your own to handle logins to the game?

I seperated the servers the way I did because I'd like to see if Unity can scale appropriately without the need to buy something like NetDog. Hopefully, if all the Unity server does is manage collision detection and server to client message routing then it will be lightweight enough to support more clients. The demo doesn't need it but it would be nice to be able to grow it into a more full blown application.

Additionally, the custom server isn't a single machine like the diagram implies. AI might be on one machine, zone management might be on another machine and chat might be managed by a third machine. The custom server connects to a DB to do all of its persisting work so there's that server as well. In the demo all these "servers" will run on the same machine but as a tech demo we'll be able to say that the servers can be federated out to more machines to scale.

 

The masterserver is required for NAT punchthrough which might actually be of importance, otherwise no one with a firewall will play your game.


The main problem with your design there is that Unity Server = 3D application
This will have a pretty heavy impact.
The majority of time is "burnt with nothing" related to the work of the server.


Thats why things like SmartFoxServer and Neutron are more appropriate solutions for something in the range of an MMO.
NetDog is nice but its mainly a network library, no server backend solution so does not really relate to the problem.

 

That's what I was afraid of and I'm coming from a Torque universe where the server can be a headless server that doesn't compute anything beyond the collision detection and prediction routines. That's the only part of this that I am missing when I look at Unity 3D because I have to be able to show a clear separation of server and client. It can't look like a peer to peer FPS style game so the server has to be it's own application.

I'm sensing that Unity 3D is made more for single player or Xbox Live style multiplayer and not MMO/single server multiplayer, at least not out of the box. Is this a correct statement?

 

dreamora:
I disagree. That completely depends on what you choose to instantiate on the server, where you want to calculate physics, which machines really need what info.

The server doesn't need a "complete" version of the world - it only needs the data which it should monitor. If this can be accomplished with simplified collision meshes and very few objects, then thats what should be on the server.