Multiplayer Networking framework built around MelonJS - Need testers to help finish it up

[Nathan McDowell]

Hello All!

I've been working on an abstracted multiplayer framework that can sync player / game objects in real-time.  The engine is coming together, but I need help testing out different scenarios for implementing in melonJS and other javascript engines.  

https://github.com/natemcdowel/socketObject

Please shoot me a message at nateclau...@gmail.com if you would like to contribute to the framework (either by testing or contributing code).  Though the basics of the framework are functional, there is still a lot of room for new features.

Thanks,
Nate

[melonJS]

oh, that's really great !

I just gave a first quick look , and the first point that really stood up is the version of melonJS you are currently using. as 0.9.7 is quite old now (now we are working on 1.1.0), we made a lots of changes since then, and most of the melonJS function you are referring to like to remove or get reference to objects have changed :

https://github.com/melonjs/melonJS/wiki/Upgrade-Guide

Then (but now it's just my opinion), I would instead have an  dedicated object that would "enable" user-defined object to be used with the library, instead of defining a specific object for it to inherit from. That could be a function that takes an entity as parameter, and then add/patch the necessary method to, also this would ease developer life by somehow abstracting as much as possible how the library is working, and put in a single place any changes required when updating either your library or melonJS. (but again just my opinion)

[Nathan McDowell]

Thanks for the feedback!  Looks like I have a bit of work to do upgrading :)

[Nathan McDowell]

When I get this working with the latest version and hone the documentation a bit more is this something that would generate interest as part of the engine?  Wondering if there's enough of a need for online multiplayer for MelonJS to include in that way..  Anyone want to weigh in?

[Rob Yed]

Hey Nathan,

I welcome your work, I think this is a really helpfull feature you would be adding to melonJS. I have some plans to create a mutliplayer game based on melonJS as soon as I have some free time. Your framework could really simplify the development. As soon as I am this far, I would try to implement your framwork. For now, I have not the time to be a help.

You were saying, that you want this framework to work with different game engines. I did not really have a look into your code, but maybe it's better to first concentrate on melonJS and later add the support for more engines?!

[Nathan McDowell]

Thanks for the feedback! I am more than willing to work with developers here and do the bulk of implementation who are looking to port their games to online multiplayer using socketObject.  I suppose I have come to a crossroad in development, in that this is a library that needs to be tested in a variety of different scenarios to uncover shortcomings and mature the code.  I can implement my own framework for my own games, but I will learn much more from working with other developers cover a wide range of styles.  

[Jay Oster]

Hi Nathan!

Thanks for sharing this project. I think it could be very interesting and useful for some game developers. With that in mind, I have some suggestions and feedback I'd like to send your way.

The code is currently tied directly to socket.io, which isn't a bad thing per se, but it creates an unnecessary dependency on a socket.io environment. I've played with socket.io briefly, and I was really unhappy about how it requires self-hosting. Anyway, it would be nice if your framework was made protocol independent so that it isn't tied to any particular communication stack. You can design the API to be compatible with socket.io if you like, it just shouldn't have a strong dependence on it. Different drop-in connectors could be added for pure websockets, webRTC data channels, or PubNub...

socketClient.js exposes a lot of variables to the global scope. Please wrap these in an anonymous self-executing function to minimize polluting the global namespace. socketObjectEntity.js in turn uses these global variables, which is a design pattern that is difficult to swallow. Structure it so that socketClient.js creates a single globally-accessible variable that exposes its internals as object properties. Then socketObjectEntity.js can access those internal properties via the single global variable. This containment will help with maintenance, debugging, and performance.

The socketObjectStructure is not a future-proof means of accessing object properties. Starting in melonJS 1.1.0, the Entity class (was ObjectEntity) no longer has a position or velocity; those properties live on the body property, E.g. Entity.body.pos A better way to reference the values you wish to transmit is actually to reference them directly. This would be an example:

this.socketObjectStructure = {

    "GUID"        : this.GUID,

    "pos"         : this.body.pos,

    "vel"         : this.body.vel

    "settings"    : settings,

    "currentAnim" : this.renderable.getCurrentAnimationFrame()

};

Now it's future-proof, as far as I don't necessarily have to update the socketObject code when I update melonJS; The most I might have to change is the list of items referenced by the socketObjectStructure.

And my final, and perhaps most important comment, is that this framework creates a great opportunity to fill a HUGE gap in JavaScript networking multiplayer game development; doing the HARD STUFF like interpolation and prediction. There are commercial game engines that do this, but not any really good open source ones that integrate with other game engines in a seamless manner. It's actually very easy to do real-time network synchronization using dumb message passing. The results are "ok", but far from ideal. Heck, I built just that in an evening using about 60 lines of code: http://www.pubnub.com/blog/lightweight-multiplayer-html5-games-with-pubnub-and-melonjs/ The actual value of a networking multiplayer framework, IMHO, will come from the HARD STUFF.

Here are some articles I want to share, which all deal with the HARD STUFF:

• http://buildnewgames.com/real-time-multiplayer/ - HTML5-specific, but includes a lot of core concepts of multiplayer gaming, and touches on interpolation and prediction.
  
• https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking - An in-depth look into how to do it The Right Way, without being tied to any specific language or development environment.
  
• http://gafferongames.com/2010/03/11/gdc-2010-networked-physics-slides-demo/ - Download the PDF or Keynote presentation. It's very long and describes a lot of pitfalls you will face in real-time networking within the context of games.
  
• http://gafferongames.com/networking-for-game-programmers/ - A series of articles that you need to read (trust me on this).

Of course, there is some reliance on the game engine, like being able to operate the frame rate independent of the physics and network updates. There's an open ticket in melonJS for this: https://github.com/melonjs/melonJS/issues/99

And finally, I will leave you with a list of other concepts and ideas that you should focus on, if you want to make this framework useful beyond dumb message passing:

Features of Entertainment & Gaming:

• Dead Reckoning - http://www.gamasutra.com/view/feature/131638/dead_reckoning_latency_hiding_for_.php
  
• Deterministic Lockstep (catching cheaters) - http://www.cs.duke.edu/courses/compsci512/spring14/15-744/S07/papers/p1-baughman.pdf
  
• Jitter Buffers - http://courses.cms.caltech.edu/cs145/2011/robustgames.pdf
  
• Object Authority Pattern (OAP) - http://udn.epicgames.com/Three/NetworkingOverview.html
  
• Authoritative Client - http://www.gabrielgambetta.com/fpm2.html
  
• Unsynchronized Clocks - http://blog.functionalfun.net/2011/03/lets-synchronize-our-watches.html
  
• Loosely synced Clocks
  
• Client Side Prediction
  
• Latency Compensation
  
• State Streaming VS Input Streaming (where an entity is and what it is doing, vs sending controller or response inputs)
  
• Floating Point Discrepancy - http://stackoverflow.com/questions/10334782/can-precision-of-floating-point-numbers-in-javascript-be-a-source-of-non-determi
  
• Sequence Numbers
  
• Predictive Corrections
  
• Game side Acknowledgements (ACK)
  
• Preventative Flooding - http://security.stackexchange.com/questions/31303/preventing-artificial-latency-or-lag-hacking-in-multiplayer-games
  
• Latency Detection
  
• Leader and Host Authority Negotiation - http://courses.csail.mit.edu/6.852/05/papers/p66-gallager.pdf
  

And Wrappers / Modules Like:

• Game Lobby Room
• Game Room Chat
• Game World Rules
  
• Geo Hashing in Game World
  
• Game Room Splitting
  
• Matchmaking and Skill Ranking
• Ghosting and Spectators
  

[Nathan McDowell]

Thanks again for your feedback.  Jay, you are consistent in your response any time I've posed a question or needed a look at code.

- Yes, it would be great to drop in other technologies such as WebRTC and any other web socket protocol.  This is certainly attainable and could be implemented in a future version.  I am excited for WebRTC, but at the moment it just doesn't look fully matured.  UDP seems to be a superior technology for the purpose of game networking.

- I also agree that socketObject.js should be containedor accessed as an instance of an object or class. My first focus was on getting things up and running and making the it as flexible as possible.

- this.socketObjectStructure is meant to be flexible and pass whatever key / value pair is set other than GUID and settings.  There are a couple of references to this.pos within parts of the code that need to be moved out and replaced with references to keys in this.socketObjectStructure

- Yes, I think there is tremendous opportunity to fill a gap for Javascript game development.  I have implemented some basic interpolation, but there's opportunity to add client-side prediction and all those other goodies that desktop language frameworks have already perfected.  The strength of this framework is how with a few steps any object can be added to a synced game state.  I have had as many as 5 players with about 30 game objects running at the same time (Although it did crash pretty soon , hehe).  My plan is that, as the framework matures this smooths out.  

- No way around it, The "hard" stuff is untested in Javascript-land. I have read several of those articles. Thanks for taking the time to post those!  I remember that PubNub tutorial. Actually, I think this thread may have been your inspiration for that post:  https://groups.google.com/forum/#!searchin/melonjs/nathan$20mcdowell/melonjs/PwdvmchxHr4/KJPftHF47PIJ . 

[Jay Oster]

Yep, WebRTC datachannel specification supports UDP. Which is what I was hinting at.

And yes, good memory; your thread was the initial kickstart for the PubNub blog article. After I wrote the example code, we had a "blog day" at the office to create some new content, and naturally I had this code laying around from a few days prior...

[Nathan McDowell]

Very cool. Blog days sound like fun :)  I think I will go back to the basics and implement the platformer example with the newest beta.  May have some questions incoming .. 

[Nathan McDowell]

I am noticing that when I log out this.GUID using version 1.1 it is undefined in the platformer demo and when logging the class the preview of the class GUID shows undefined, however on expansion of the logged object, the GUID is there.  Am I missing something? I attached a screenshot of the issue.

[Jay Oster]

Yes. The GUID is not added to the entity until it is placed in the world container. Similarly, the `z` property is also added at the same time. When you expand the Object preview in the console, the browser fetches the current property values at click-time. What you see in the preview are the property values at log-time.

This is one reason we need callbacks for world adds and removals: https://github.com/melonjs/melonJS/issues/448#issuecomment-50648417

You can work around it with a setTimeout (which sucks...)

setTimeout(function () {

    console.log(this.GUID);

}.bind(this), 0);

[Nathan McDowell]

Works for me!  Also, Looks like me.game.getEntityByGUID has changed.  How can I find any object using getChildByGUID?

[Nathan McDowell]

Nevermind. I found it:  me.game.world.getChildByGUID(socketObjects[i].GUID);

[Jay Oster]

You got it! :D

[melonJS]

@Jason, actually Aaron added the "onActive" and "onDeactivate" callback in 1.1.0, i'm not sure however where they are documented :)

[Jay Oster]

! I missed the commit because it's not tagged with the ticket number: https://github.com/melonjs/melonJS/commit/68b7ff2c1d9806ff44ba109f13bf0c9258d4ffea I now have some comments to add to the ticket. ;)