Run without rendering (for online game)

[chinesestorm]

hi everyone

I want to make a online game, so I need to run the game at the same time in local (browser) and on a server (nodejs),
on the server, all the code must be executed, except the canvas rendering.

any clue where to start?

PD: the biggest problem I see is that the objects that leave the screen, by default are no longer evaluated.

[obiot]

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.

[chinesestorm]

Yes I know
but each of them has a logic for the server side and another one for the game itself, for example Contra 2000 uses a server in java. Another option is use a server just to synchronize events like Node-Mayhem , but that generates many problems in the gameplay (if there is a lag) and it is very easy to cheat.

that's why I have the idea of running the logic of the game on the client and the same on the server, I'm not sure if I'm explaining it well, but I'm sure it's a good idea.

and indeed the idea is not use "alwaysUpdate", instead make the server use a default size, and now that I say I think it is not so complicated, I will create a plugin or something and I will show them
regards

[Parasyte]

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?

[chinesestorm]

I think of it this way

• I want to make a game for web browsers (javascript)
• and it has to be multiplayer
• in addition to the game, I need a server
• Why do I have to create a server if I can run the javascript on nodejs?

Yes, what you say is true: "running the game only server-side is effective against cheaters[...]", that's exactly what i want to do, but "[...]if you can guarantee low latency while streaming an audio/video feed" not necessarily, because I will have all the game on the client side too.

And Laghacking, if you are playing in a console and voluntarily release the joystick, only you lose. the same here.

it's my vision, I don't want to make a mmorpg or some huge production, I just want to avoid developing two times (server and client), and if I can gain a bit of security, much better.

[Parasyte]

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.

[PLAYERKILLERS]

The server's logic will differ from the client's. There's no escaping developing them separately.

 

Just think about what you want for your server side game loop and go from there. 

[chris.daniel]

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.