#multiplayer programming

Development of server seams for nengi.js. In the gifs above the edge of the grid is the border between two separate game servers. Each gif is progressively getting closer to the goal. It begins with just seeing across a server boundary, to seeing both ways, to interacting across lines, and finally efforts to make things feel more and more seamless. Still not done is the player or npcs crossing the server boundary smoothly.

 This is different than the instancing in most AAA mmos where instances don’t share true borders -- they merely pretend to, and players can see everything phase into existence as they cross one of these server boundaries. A dozen players can walk out the front gate of a town and they won’t necessarily end up together. That form of instancing (which is really easy in nengi) is great for having 500x instances of the main town b/c there just too many players to all be in the same spot at the same time. But this experiment is about treating a world as one big place. I miss UO.

I’ve got it so that extremely large maps can now be loaded from Tiled Map Editor into a game rendered with Pixi.js. I had to write my own loader that converted Tiled maps into spatial grids. Then I used the same culling/rendering logic that I use for all tile-based games on this blog. So it was a big improvement overall.. for the 1000x1000 maps the rendering is like 200,000% faster than it was with the other loaders (apples and oranges, I guess). The other cool thing that comes from exposing the map data in-game is that I can now make a layer that stores the collision logic, shown in blue on the second screen capture. This is pretty handy as it allows me to quickly just draw the collisions right on the map instead of writing some tedious logic about which tile types are collidable. The same thing could be used for all kinds of things, like a layer containing the locations of monster spawners... though if there were too many things like that I would trim them from the clientside version of the maps.

Client predicted projectile @ 300 ms of latency, followed by the server side shot (white is client prediction, black is server-confirmed reality, though seeing it is subject to the latency as well). 

Out of the 7 projectiles, the first 4 have been created on the server as far as this client knows. The 4th projectile has a line demonstrating its relationship with its counterpart. The last 3 white dots are projectiles that have also been fired on the client but due to simulated lag have yet to be created on the server and confirmed again on the client (which is the point at which the black dots appear).

Getting these things really deterministic (and therefore consistent) with date/time related math seemed inherently flawed, so I’ve favored a fixed timestep + deterministic simulation approach instead.

Example/process:

When the client is determining if it can fire a projectile, it does so by comparing the weapon cooldown with an accumulator variable. e.g. is our accumulator greater or equal to our cooldown of 0.500 seconds? Each frame it adds 1/60 of a second to the accumulator.

The server also uses the same logic to determine if it should created a projectile -- at a rate of 1/60 being accumulated for each frame it receives from the client.

 The result being that the number of frames experienced by the client is the number of frames processed on the server... and the small aggregate of 1/60s being added up will pass 0.500 on the identical frame for both computers (deterministic). 

The server can also decide if the frames it receives from the client are valid... did they contain actions that are feasible for that player? Are they coming in at a believable framerate? 

From there each computer (client and server) can simulate their own highly-similar result for the projectile. The server might determine that the projectile hit another player, and deduct hitpoints. Meanwhile the client, which for cheating reasons does not get to say anything about anyone’s hitpoints, might instead determine that the projectile hit another player and draw a purely aesthetic blood effect.

Those moments when collisions are programmed A) serverside, and B) predicted on the client.

Clientside prediction, lag compensation, packet loss mitigation, and enhanced playability for low/variable frame rates are among the advanced features in this release. There’s also a really basic 3D demo game in Babylon.js. Ofc just making a basic multiplayer game is still possible as well.

I’ve released 5 videos covering these advanced topics:

interpolation - nengi beta 3, part 1

movement prediction - nengi beta 3, part 2

shot prediction - nengi beta 3, part 3

lag compensated collisions - nengi beta 3, part 4 

packet loss / low frame rate correction - nengi beta 3, part 5

There’s also a nengi.js discord channel:

https://discord.gg/7kAa7NJ

Just come into the lobby and say hi @ Alex and I’ll grant you access.

I’m getting close to a decent implementation of the multi-instance nengi features. The demos / nengi-game-templates are also going to be buildable with webpack in addition to browserify. I’ll be updating some of nengi’s core to ES6 (for those that tinker directly with nengi.Client and nengi.Instance). There are a few bug fixes and perf tweaks for the interpolator. There’s also a new client/server/common organization that clearly illustrates the division between client and server, and also which code is explicitly designed to be run on both. Most of this comes from recent feedback and feature requests. Thanks everyone!

I’ll be temporarily pausing the nengi tours until I can get this new version published. I really think these changes will make nengi easier to understand and these tours more meaningful.

My ETA for release is within the next 10 days, hopefully even this week. I’ll be resuming nengi tour/tutorials after that.

I’ve also created a subreddit for nengi. My schedule is all over the place, but I will make an effort to read and answer questions on that subreddit when possible. I’ll also try to add nengi-related things from this blog to reddit going forward.. it’s a bit barebones a the moment.

Ported the `2d shooter demo` from pixi.js to three.js to show a different renderer being used with nengi.js. Available at https://timetocode.com/nengi (downloads section).

The red spheres are players (simulated via bots that connect from an external source). Green are bullets, yellow are impacts. Replace the placeholders with some spaceships, make 3 types of weapons, widen the play area, and go make some $$$ IMHO. Oh and take out those impact effects, they are good for the demo but bad for a real game.

There’s some mediocre documentation, some verbose but informative videos, and some pretty solid demo code available on the site. See the manual and downloads pages.

It’s not FREE! Well... it is often free.. you can read the license on the site but the gist is: 5% royalty for revenue greater than $3,000 per quarter, and FREE for anything less. It is my hope that if nengi works for you, it makes you $$$. Also that you send me like 5% of that $$$ ;). 

The games I make can have 50-200 concurrent players and run on servers for about $10/mo. I’ve seen other games in that same range cost anywhere from $40-$300/mo by comparison, not to mention many attempts at networking struggle to break a player count of 20. So potentially high player counts and potentially cheap servers are the selling points.

Nengi is not particularly easy. It doesn’t try and hide the complexity of multiplayer programming. It is more about power, flexibility, and development speed. Nengi tries to expose the stuff that matters (without forgetting about performance, like everyone seems to these days) while automating the tedious stuff.  Sometimes it seems like a few lines of code doing a lot of work means something is easy -- but its deceptive b/c in truth you still have to understand the underlying concepts to get anything done. If it is too frustrating yell at me and I’ll make more tuts or come to terms that I’ve made something too crazy.

Good luck and happy programming!