Spring RTS Engine

spectators are not players but still use alote of cpu time, as if the spectator is doing more than just spectate as if it is actually playing what is being seen.

Spectator is playing .. just like anyone else :) Or even more, because he sees all units

It's logical that spectators have higher cpu load than other players. There is no cpu intensive operation that real players need to calculate over spectators - tracking user commands and sending them over net is very cheap.. you won't save much by removing just that..

The difference between specs and normal players should be negligible.

Maybe spectators are a little bit heavier because they need to send more data to the GPU because everything is visible, but that should barely be noticeable.

so it's because of the graphics rendering ?
why should spectators calculate that much ? I thought they were just getting the unit position and drawing it on the screen, spectators are not running the simulation ?

Every client runs the simulations.

It would look mighty wierd if it was just the unit positions. Stuff like LOS and weapon status and projectiles and pathfinding and terrain deformation and animation need to be kept in sync too.

yay more spec hate.

jackalope wrote:yay more spec hate.

on the contrary I like spec, just trying to find out if specs could watch without lagging the game.

I see, the spec must see the actual game happening and the sync is needed to make sure the specs see the game and not something similar to it (like units with different animation which is irrelevant to what is happening) or terrain deformations which are happening by themselves.

so it is not possible to prevent specs from influencing the game's speed if their cpu is hogged.

but, what about the network ? do the specs only receive data or do they also send data back other than the markings, drawings and messages ?

This also regards networking: specs are just like normal players except that they don't control a team, and see everything.

So they send less (no commands) over the net, but they still send something (cpu % messages, newframe replies to calculate ping, chat, map drawing/labelling, sync checksums).

Really the only reasons to disallow/kick specs are 1) non technical reasons, 2) limited upload rate of host or 3) spec having worst CPU of all players.

jackalope wrote:yay more spec hate.

I have no idea why people kick specs so much. Springie having an option to kick specs is really annoying because if you're running an autoserver you should have enough bandwidth/cpu anyway and everybody has it turned on.

this just hit me : every client has to receive a comfirmation reply for every action that takes place in the game, that means the server takes all the data from all the players and sends the data back to the players with the data of all the other players, correct ?

all of the things mentioned above, are done by every client, but every client's requested operations are dependant on the server, and as far as I managed to understand there is only ONE simulation that is being run by every client.

so I was thinking, if operations that are issued by every client are dependant on the server's response, it would be possible to let ONLY the server run the simulation, or at least as much as possible, and since the server sends back data to the client, it could at the same time send results of calculations of the simulation to the clients, thus there is only one simulation which is run by only one system and being sent to all clients with the simulation results, for example :

a player sends a command to move a unit to somewhere on the map, the server receives the command, performs pathfinding and returns to the client the resulting path and allows the unit to move using the given path, thus the path calculation has been performed during the "lag" time between the sending of the command and receiving.

now I figure that this probably does not work as you would probably already have done it this way, so the question is : why all the synced data cannot be done only once and only by one system, and let the clients only do the unsynced stuff ?

because it does not make sense to let every client run the simulation while there is only one simulation, and that this simulation is dependent on the server's response.

monohouse wrote:this just hit me : every client has to receive a comfirmation reply for every action that takes place in the game, that means the server takes all the data from all the players and sends the data back to the players with the data of all the other players, correct ?

all of the things mentioned above, are done by every client, but every client's requested operations are dependant on the server, and as far as I managed to understand there is only ONE simulation that is being run by every client.

so I was thinking, if operations that are issued by every client are dependant on the server's response, it would be possible to let ONLY the server run the simulation, or at least as much as possible, and since the server sends back data to the client, it could at the same time send results of calculations of the simulation to the clients, thus there is only one simulation which is run by only one system and being sent to all clients with the simulation results, for example :

a player sends a command to move a unit to somewhere on the map, the server receives the command, performs pathfinding and returns to the client the resulting path and allows the unit to move using the given path, thus the path calculation has been performed during the "lag" time between the sending of the command and receiving.

now I figure that this probably does not work as you would probably already have done it this way, so the question is : why all the synced data cannot be done only once and only by one system, and let the clients only do the unsynced stuff ?

because it does not make sense to let every client run the simulation while there is only one simulation, and that this simulation is dependent on the server's response.

...no

No, because spring uses UDP, which is basically broadcast packets. Server sends info to anything that will listen.

It would be somewhat true if spring was using TCP (which you should do some research before trying to discuss using it etc) which in a way would be nice, and might cut down on sync stuff, but it would require a lot of overhead on the network.