Unity / NodeJS Projectile synchronization

Question

I am working on a MOBA game similar to League of Legends. I am building the game server system in NodeJS/Socket.IO but I'm running into issues on figuring out the best way to handle projectiles (aka player skill-shot abilities) on the server-side. The Main goal is to be able to spawn a projectile (or projectiles) on the server-side and update the position in a certain direction (all on the server-side separate from Unity) until I specify the projectile to be destroyed. This way, each time the projectile moves I can check with every single players current position and see if the projectile hit (thus allowing me to damage the player on the server-side).

How could I achieve this effect, or something similar?

Answer 1

As far as I know Pomelo has no way to do this internally. It is more of a message transport framework than an engine. So to answer your question you can do this in at least two different ways: you can implement an "update" method in your server that will run periodically and update the position/status of all your entities accordingly or you can have an update method for each projectile instance that will update the position of the projectile at every tick. The latter might be easier to implement but will make it more complex to manage and understand what code is running when. Keep in mind that the setTimeout function in javascript is not very precise. The intervals might be off by a few milliseconds so keep track of how much time has passed between updates independently, don't assume the delay was followed rigorously. Also remember that you may need to bind a context to the function being called. This is usually not recommended but there are node libraries that implement faster but more restrictive bind operations that should work.

Also note that, at least when I used the Unity client, there was no support for UDP packets on the client (although this is easy to implement). If you are going to use TCP, remember to disable Nagle's algorithm by passing setNoDelay as an option to the connector.

You are also using a asynchronous engine, and in order for users to not notice lag, you will have to implement some features client side to compensate for lag. In my experience player movement is critical and clicking on buttons to attack has a less noticeable lag, so start there. You will also have to implement some client side movement prediction for the other player characters or position will be way off.

You can also use a synchronous engine, there was a project to implement this in Unity. That way you can use Pomelo as more of a message relay and less as a game engine. Alternatively you can use Unity to setup a server and run all the code there and use Pomelo to create lobbies and direct players to the appropriate servers.

Answer 2

Fabio's answer is right. I wrote a multiplayer Command & Conquer: Red Alert 2 clone back in college, in Java using NIO for multiplayer. I came up with or read somewhere about the concept of "frames", which is basically the same as what Fabio refers to as "ticks." Frames or ticks should be controlled on the server in a timer. I think I spaced them 100ms apart, but I don't remember. The server should keep in memory (like a javascript object or array) the positions of all mutable/changeable objects (characters, tanks, buildings etc), on a given map. For development purposes or an alpha version (just to get a feel for how it works), the server should serialize the javascript object into JSON representing the assets on the map and send it to the clients on every frame (every 100ms or so). Each client should only update its view of the map when it receives the JSON from the server (again, about every 100ms it will receive a new JSON object). When the client wants to move a character, fire a bullet, etc, it should send a JSON request to the server describing the attempted action, but no change should happen on the client's view directly (except maybe a red x showing where a character is going to move). The server will then receive the JSON action and compute the movement or interaction, interacting with the timer so that the event happens over time. The client will see the action (along with other clients) because the server will be sending out the frames every tick.

To improve this as far as bandwidth concerns, you could only send out changes/updates (updates to the javascript object tracking game state) to the clients every frame. I would still send the entire javascript object every 5 minutes or so in case there are bugs in your changes/updates code or dropped packets if you're using UDP.

There are more advanced ways to deal with latency than this, which you may need to explore as you improve your game out of alpha version, but this should get you started.