Using a modified version of babylon in nodejs

[tajen]

I want to make an autorative server for a 'realtime' multiplayer game. My theory is that if I had a version of babylon where anything related to rendering is removed, and I am only left with the physics and meshes, I should be able to simulate an enviroment in nodejs which could act as a server.

 

Do you think this is feasible? Most likely this will take a hefty perfomance hit compared to a something made specifially made to handle this type of problem, but it makes it possible to easily create a multiplayer enviroment. I made a naive try to remove the canvas yesterday, but if I am not mistaken the meshes are played in the vertex buffers for the canvas. 

 

Anyone tried something similar, or have good suggestion for another approach?

 

 

[GameMonetize]

Sounds like a great idea. I was thinking about something similar to move collision engine into a web worker

[joshcamas]

This seems like a cool idea! Then you could have a quick babylon only built to calculate positions and such, then push the data forward to the clients! I like it!

[macguyvok]

If a node version were going to be built, I'd also request a Browserify version (tl;dr: it compiles node modules into browser modules). The two would, basically be the same thing, except the node version would turn off parts of the code if, say, typeof window == 'undefined'. I'm pretty sure that should be all that would be required to support both.

 

Alternatively, I suppose you could pull the simple collision code (or whatever else) out into it's own library, build it as a node module, and use browserify to turn it into something Babylon.js could use/rely on. (I don't know how node, browserify, and typescript play together, but I'm assuming any issues would be solve-able.)

[macguyvok]

As for tajen's initial post, I have some thoughts. Currently, I'm using node.js for my server, and the plan is to make it authoritative as well. Our plan (which we're right in the middle of implementing) is to use cannon.js on both sides, and to sync trajectory and velocity on player input, with periodic position/orientation syncs at a much lower rate. (I'll explain why in a bit.)

 

There's some intersting problems you need to solve with an architechture like this, and I'm not going to lie, it's nontrivial. Ignoring the details of physics or collision; let's just say you want to move a cube around on the screen. Every player has their own cube, and can see all other player's cubes. Server is authoritative on state. The first thing you try would be simply sending a message to the server every time your cube's position changes. The server calculates the move, and your client updates to what the server calculated.

 

In a perfect world, this would be correct, and fine. Client and Server would never disagree, everything would be smooth, and you'd be done. Unfortunately, here's where reality sets in. In the real world, there's going to be some latency between the client and server. You always want that as low as possible, but you need your game to be playable between 15ms (I've never seen lower on my home Cable internet) and 100ms (high, but not uncommon in rural areas). For comparison, 60fps means each frame is ~16.7ms long. According to the FCC latency seems to average ~31ms in the United States, so, call that 2 frames. If something is moving at a decent speed on screen, the distance it covers in two frames can be huge; which means that you'd end up with the following scenario:

• Player moves box on screen
• Client sends update to server
• Wait 16ms
• Server calculates position, sends to client
• Wait 16ms
• Client gets update, and applies it
• Box moves to position it was in 2 frames ago

That might not sound bad, but trust me, it's often what players mean when they call things "laggy" or "jittery" in a multiplayer game. So, what can you do? Well, the common solution is for the client to know how much time has passed since the message was sent. Then, it would run the result through it's own calculations, to try and build an 'far forwarded' message from the server, and apply that. Now, this does work (and for some types of games, it works really well!), but it has it's shortcommings as well. Without turning this into (more of) a discertation on the difficulties in networked games, I'll just say that this method has problems with 'teleporting' players, and relatively high bandwidth requirements.

 

My preference is to go the route of WoW. You send the server some representation of player input (not key presses, but something like a velocity vector), and it distributes that to everyone. Client track their latency from the server, and use the 'fast forwarding' trick on these messages. For the most part, since the client and server are calculating things the same way, they should share a close enough view of the world. But, to make sure, you periodically (once a second, once ever 30 seconds, it really depends...) send a position and orientation to the client. For things not controlled by the player, simply update them. For something controlled by the player, however, even small jerks can really affect gameplay, so I'd maintain a hidden object that's from the server, and have the player's avatar attempt to smoothly update to the server representation. Player input would control the avatar directly, but also send the updates to the server. Then, you need to pick a threshold of difference between the hidden server avatar and the player avatar; over this threshold you do a single 'jump' to update.

 

I know this is probably way more than you were thinking about getting into right now, but I've been down this road many a time; figured I might as well share my map of the land.

[tajen]

Yeah, I have read several articles about multiplayer and its problems, for example:

https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

 

As I am normally used to doing backend, non-mathematical programming, and really just started to play around with graphics/physics, I find the matrices and vectors more scary than a little lag.. But I will try and see if I am able to extract the essential parts and make a server version. If I make it work, I'll share the code. If someone else happens to solve the same problem, I dont mind if you share the solution 

[joshcamas]

Using the vector way (Instead of saying "This player is here" it would say "This player is going this direction") is what a lot of people do I believe.