MP, should this be left on the client side?

[Elvar]

Hey fellow developers .

I've developed a Tower Defense game using ImpactJS, or at least the base mechanics for it. I'm now working on porting it for Multiplayer use, points of the games however, i don't know wheather should be on the client side or on the server.

Say player sets a tower on the map, as it is now, the Tower enitity check every frame, if there is creep inside its radius. I assume that if the client would have to poll the server every frame, to check if a creep is inside the tower radius, the server would be very stressed, so how should i approach this? If i leave this on the client side, i would be rather easy to cheat.

[Jackolantern]

This is where multiplayer game development gets complicated, sad to say. Obviously you can't check it with the server every frame, because a frame works in the ~30ms range, which is shorter than average network latency. This is where creativity has to come in. For example, when a mob spawns and starts coming for your tower/target, will it follow a linear path (not necessarily straight, but at least known at spawn time)? If so, then the server can know on its own when the mob is in range of the tower, since it also must know where the tower is. All it would need is some syncing, probably dealing with movement deadlines and if they were met or not, to ensure the client and server's mob locations are "close enough".

If the movement of the mob is not linear, then you would likely need to start reporting velocities to at least break down its total path into as long of linear portions as possible. So say the mob is going to move NE for 700 ms, the server can tell that to the client, and the client can animate that movement on its own, and then the server can notify the client if it moves into the radius of a tower so that the client can play the appropriate animations.

In the end, the client mostly has to be a dumb terminal that does little more than play animations and sounds, and controls input.

[Elvar]

Hi Jackolantern.

First, thank you for your respond!

As it works now, creeps have a path array. When a creeps spawns in first picks path[0], lets say that would be right, the creep will move right, until it collides (at a certain point on the map, set in mapmaker), it now picks path[1] which could be down, and so on.

So i would know where the creep is, and when it is in range. But now say that player has a tower with a freeze effect, which slow the target creep. That would make the server out of sync, forcing me to guess which exactly creep is slowed etc.

Also another issue is the projectiles the towers fires, say a tower fires 5 projectiles in a second, would i have to foresee that aswell?

[Jackolantern]

The freeze effect would have to be known server-side, and the calculations on whether or not something is frozen would have to occur there. Basically, your server needs an entire interpretation of your map and everything that is going on. Provided you aren't using any complex physics calculations, this isn't too bad. For projectiles, you could simply send a JSON object that has the number of projectiles fired as well as their origin as an (x, y) point and their direction as radians (or degrees, I guess it doesn't really matter since you could convert it client-side, but the trig for the animations has to be radians if I remember right, and as you probably already have it set up). Then the client can simply animate the projectiles.

You can allow the client to determine collisions for the projectiles, but it has to ask permission from the server to update the game state, so the server must know where they are. You could pull a bit of a shortcut by allowing collisions to be determined client-side, and once a collision is detected, use the collision event handler to get the name of the object it collided with. Send that to the server, and on the server calculate the angle from the origin of the projectile to what it hit to ensure the collision is possible. You also need to find the distance between the projectile origin and the collided surface point and compare that with the speed of the projectile and when it was fired to ensure that someone isn't causing collisions to happen sooner or later. If anything about the collision is found to be impossible by the server, the server will send an abort signal to the client telling it no collision was registered and to continue with the projectile movement.

Whew...that made me exhausted just going over that, but that is why online game making is really only for the bold. The challenges are greater, but the rewards are much greater, too. Online games can become immensely more popular than single-player games

[hallsofvallhalla]

Agree with Jack here. Only have the client and server talk when there are changes beyond what is predicted or set by the client. The logic should be the same on both so no need to have the server doing all the work.

For example

Bot1 is instanced and sent to client and put on screen, with that, its first path is sent and on the client the bot moves and after moving 30 pixels it collides with a wall. The client then sends the server "hey the bot moved 30 pixels in this direction and says it collides" the server then does a small calculation to be sure that collision could even happen..
So lets say someone attempts a cheat and tries to move the bot to another path, when the check gets sent the server is going to see that 30 pixels from the original location is not on another path and it will re-sync it.

[Elvar]

Thank you for your respond guys.

I think i might have looked at this the wrong way. I thought it would be enough, just to have like a sessions json object, for storing the entire game data, like "sessions[gameid].activeCreeps[3].hp".
But validating client data out from a array, would de for some serious guessing right?

Would it make sense to have a instance of the game, running at the server aswell? In that way you don't really need to do much of a guessing, as the game is an exact copy of the servers. In this way the server could still save "the entire game" in "sessions[gameid]". Client would then send a sync message like every 200ms, which the server returns the sessions[gameid], ready for the client to comply to, correcting the game after this array.
Client would then still send messages, when creating towers etc.

Would this cause too much stress on the server, saying that we have 150+ games running at the same time?

Also, i've looked at https://github.com/cmcculloh/node-impact, does any of you have any experience with this?

If this seem to be the way to go, i have plenty of questions

[Jackolantern]

I think 150 games would be fine, since you will be stripping out all the graphical routines from your game to run it server-side, and the graphics are what bog any game down.

Do some looking around on the Impact forums, and on pointofimpactjs.com, since there has been a lot of discussion about trying to get Impact running on the server (in Node) for this specific reason. Larger MMO games obviously cannot have the entire, full game running on the server, and instead rely on database hits and calculations to deliver their data, but for smaller games where the entire state is all seen on basically one screen, it would probably just be easier to run the entire game on the server and your network code would basically be syncing state.

Of course that won't solve everything, since, where we began at, we can't update the state every frame, so creativity is still going to go into making it bandwidth-friendly.

[Elvar]

Yea me too, read a article about nodejs handling, well lets just say very many concurrent connections .

I did some reasearch already, and i found a bunch of repos on github, that should be doing just that. i guess the todo is, remove all graphic related code, from the instance that runs on the server, and the start the games in a sessions array, i suppose. Gonna spend some time fuzzling around!

[Jackolantern]

If you get something going with it, let me know I don't think the issue has been definitively solved yet.

[Elvar]

I will, and i will probably get back before, for some advice ^^! Thank alot for your time tho .