Hai @mistertomat

they are a few games here that you can look at for online gaming examples.

else for your second question you can set the alwaysUpdate property of your renderables to true, this will keep them "alive" even though they are out of the screen. Be careful thought, that obviously, the more objects you have the more resources it will use.

Out of curiosity, how do you expect running melonJS on the server to prevent cheating? This is a topic which I have studied fairly extensively. Unless you implement a mechanism to actively address cheating, you're going to get a very sad surprise one day when your players start complaining about cheaters. For starters, here's a short list of relevant resources on the subject:

• Deterministic Lockstep

• Lag Hacking

• Pick your favorite anti-cheat tools; EAC, Punkbuster, ...

To followup with an idea provided in that Stack Overflow answer, running the game only server-side is effective against cheaters if you can guarantee low latency while streaming an audio/video feed (or the procedural equivalent). But that's way beyond the scope of what melonJS intends to provide.


By the way, are you familiar with the concepts of prediction, dead reckoning, and jitter buffering for networked multiplayer? If you miss these, you're going to have an unpleasant experience because the network is unreliable. Once your game goes multiplayer, you've entered the realm of distributed computing. And as with the CAP theorem, you can't sacrifice partition tolerance. This is a fun can of worms that many platform engineers will spend their entire careers learning and dealing with.

Isn't it amazing how extending a simple game to play on even two computers suddenly raises the complexity exponentially?

I think you will find it significantly more difficult than it appears at first. I'm not trying to discourage you, that's just the reality. But if you can manage to make it successful, then that is awesome.

You mentioned my game (Contra) so I'll comment on what I think.

Don't try to solve problems you don't have....you're game would need to be really popular before anyone would bother with cheating....I am NOT saying that you're game wont be popular (I bet it will be awesome)....point is - first goal should be creating a great multiplayer game that works well.

When I started to make the multiplayer parts of my game I had no clue what to do (I still dont). At first I got lost in the advanced concepts, but I stepped back and just wanted to make it work. Of course you can cheat my setup...the server has zero validation. But why on earth would anyone be cheating.

I made Contra as simple as possible...each client handles his own gameplay...client publishes updates of his own player's state to the server...the server then broadcasts that state to all other clients. When each client recieves another player's state update...the client simply tells that player's character to run over to that reported position.

Running a Java server is probably an odd idea (but I think it has merit). My motivation - curiosity about some new reactive functional frameworks for java. A better idea might be running a simple node server using sockJs or some other pub-sub library. Or even just vanillaJS using node's HTTP module and RXJS. Anyhow .... This way (theoretically) ... when the time comes ... your client side JS code could be moved into you're server-side JS code.