#html5 multiplayer game engine

I’ve recently given tours of nengi to 3 developers. The feedback has been very helpful.

The top requested features/changes so far are:

demo (and api) for multi-instance game worlds

demo of sending tilemaps via nengi

webpack support in demos, build/run scripts, es6 module support

division of demos into client, server, and shared code

code sample for authenticating players

code sample for saving/persisting a game world

more support for 3 dimensional space (z-axis, different ways of calculating entities within view of a player)

a more complete game example that goes beyond nengi features for newer devs to disect (player, enemies, camera, medium sized world, map data, animations)

Also on the TODO list for the current game that I'm working on are improvements to clientside prediction, serverside lag compensated collisions, and polishing+modularizing the current entity interpolator. These probably won't be seen in the published version of nengi until after I've tested them.

BTW if you're using nengi currently and trying to make use of multiple instances as one game world, a player can travel between instances the same way the player gets into the instance to begin with: via connecting. So it is possible to have a player step into a cave entrance (for example) and then have the server detect this and tell the client to connect to another instance. This is a manual process at the moment. The feature that I may add is a streamlined version of the same idea, perhaps with an api like instance.transferClient(whoToTransfer, instanceToTransferTo).

If you make a multi-instance game in nengi I recommend being very tidy and modular with the game logic, such that it can be used across all relevant instances. Like in a classic mmorpg.. much of the game's core logic applies in all areas of the game world, with only the terrain, creatures, and players varying. Perhaps a few instances are slight exceptions... maybe the big city of the game is optimized for higher populations by having a lower tickrate and disabling the CombatCollisionSystem. Maybe an arena instance is optimized for responsiveness via a higher tickrate, and also carries slightly different rules.

I'm also debating a feature where a client can connect to multiple instances at the same time as a means of hiding the seam between the areas of the world controlled by one server and another.

ETAs are largely unknown. v1 prediction/compensation is going to be released with my new game. I hope to add multi-instance support and do a big code reorg around the same time (6-8 weeks)