I’m converting my Asteroids MMO over from OpenGL/C++ to Unity. I’ve considered using Node.js as my server, where the client would just send player input commands to the server. The server’s job would be to handle movement, collision, etc, and send the results back to all users. Would it be a good idea to build my server-side simulation in Unity using its physics engine, and use Node.js as a mediator between that and my Unity-based client?
EDIT: After thinking about it, I might just drop either Node.js or Unity on the server-side, and just other whatever I don’t drop exclusively. I’ve decided that the servers don’t need to scale, and the game is supposed to be simple anyway. I’ll probably just go with Unity since it’s workflow would boost productivity, and at least both the client and server are using consistent tech… I’d use Socket IO in my client and server Unity projects. Clients would connect to the server, and only send player input to the server. Servers would authenticate (kinda, lol…) connections, and create corresponding GameObjects to represent each player server-side which will have all the rigid body properties configured. The only drawback is now my server would need resources to render the game, unless I can turn rendering off when in production. I only need the Unity-built server to run as a daemon. I would prefer it if the server didn’t need to display anything. I could write a Unity-based admin tool that could securely log into the server, and render what the server is processing. Seems redundant, but I don’t want the server processing graphics if it largely doesn’t have to. Worst-case, I guess I could render my Unity server at a really low resolution, and raise the resolution when I log in. Problem is, now my server needs a window server (I’m going to go with Ubuntu).