Spring RTS Engine

lurker wrote:

Tobi wrote:Also sync errors generally don't propagate to other players as some people suggest sometimes.

People have suggested that?

Sometimes on previous spring versions sync errors did seem to jump from player to player, but that could be the host going out of sync and spewing errors.

Kicking spectators because some of them might lag is as retarded as spectating with a crappy computer imo. ~~

Teutooni wrote:Kicking spectators because some of them might lag is as retarded as spectating with a crappy computer imo. ~~

i disagree!

a spectator should only get the positions of the objects and what are they doing. if his pc is quick enough fine, if not he will have very low fps.

there is absolute no reason that a spectator computes something!

Ok, let's rewrite the whole network system and simulation then...

Peet wrote:Ok, let's rewrite the whole network system and simulation then...

no need to rewrite the whole network system and simulation. just send the spectator only the object data and don't wait if he is in sync...

come back when u have a patch

dust wrote:there is absolute no reason that a spectator computes something!

Spring sends only human input (orders given to units) over network afaik. There is every reason for spectators to compute the simulation.

It might be a good idea to not wait for spectators though, like what zerver described.

Evil4Zerggin wrote:

lurker wrote:It means 50% of the players have less than ideal cpu, but only 0-2 are likely to be screwed.

Yeah, but when they drop, the median increases. Unless dropped players are still counted in terms of speed?

It'll increase, but not much. The rest of the group will be close enough together that none of them at all should be heavily affected.

dust wrote:send the spectator ... object data

Do you have any idea how much data that is? When you can have 10 specs?

KDR_11k wrote:Wouldn't median mean 50% of the players are screwed?

No, because it does not aim for a 100% cpu usage for the median player.

IIRC the target currently is 60% so you need about 40% slower machine than the median to be screwed. And naturally you will not be screwed unless the median cpu usage really is as much as 60%, which will require a rather big game.

The next version of spring also counts mandatory rendering time as CPU time (one draw frame every 15 sim frames = 2fps) if you are running the single threaded version.

dust wrote:

Peet wrote:Ok, let's rewrite the whole network system and simulation then...

no need to rewrite the whole network system and simulation. just send the spectator only the object data and don't wait if he is in sync...

Read this before giving more suggestions plz

(That's more or less also Spring's networking design)

Tobi wrote:

dust wrote:

Peet wrote:Ok, let's rewrite the whole network system and simulation then...

no need to rewrite the whole network system and simulation. just send the spectator only the object data and don't wait if he is in sync...

Read this before giving more suggestions plz

(That's more or less also Spring's networking design)

Figure 7. A "star" configuration of peer-to-peer clients in a session.

Peer-to-peer strengths:

*
Reduced latency due to the direct client-client nature of the system, rather than a client-server-client roundtrip for messages.
*
No central point of failure -- if a client (even the host) disconnects from the session, the game can continue.

Peer-to-peer weaknesses:

*
More active connections in the system (Summation n=0 to k-1 (n)) -- means more potential failure points and latency potential.
*
Impossible to support some NAT configurations with this approach.

is this star architecture used in spring?

No. (Tobi meant the general concepts on the first two pages of that article, another good read is the X-Wing vs. Tie Fighter one which has even more in common with Spring due to the real-time aspect.)

hunterw wrote:whoever is the weakest computer in the game lags everyone down with them

if there are 8 players and 8 specs, theres a 50% chance its a spec all thigns considered

also specs tend to alt tab and shit which usualy makes them no sync and if a spec no syncs i usually kick em

Before you start the game you could look at the spectators cpu, and kick anyone who has lower then any of the players.
So if you can read, and i assume you can, there shouldn't be even a single procent chance that a spec would "lag" the game.

Oh and btw, anyone know what the lowest recomended cpu is for spring to run on 1.0 ingamespeed?

There's a few problems with that. First, people can change their displayed CPU speeds manually (I forgot who, but there's someone running around with a "1337 MHz" CPU). Even if people don't change the displayed values, sometimes multicores add all the cores together and sometimes they don't, leading to "4.6 GHz" processors. Second, especially nowadays, speed != power. I'd take a 2.7 GHz Core 2 (or better yet, whatever new family they're using now... Core i7?) over a 3.6 GHz Pentium 4 any day. Finally, the processor is only one factor contributing to how fast a computer is overall.

Then i will stand corrected

I supose that this is of such a low priority that noone would make a battlewindow-inbuilt-pre-game testing?
That would, for an example, run a program that messured on what speed everyone could run at?

edit: btw, even if some of those that have a high cpu are slow, you could still be wary about those who have a very low cpu.

Soul wrote:Then i will stand corrected

I supose that this is of such a low priority that noone would make a battlewindow-inbuilt-pre-game testing?
That would, for an example, run a program that messured on what speed everyone could run at?

It's a good idea, but as you say, it's probably more work than it's worth and you'd need to make sure people can't just fudge the result/bypass it.

It would be great to have a proper score/value assigned to each persons computer performance, but how do you determine what threshold to set for each map/game with x amount of players? It also depends on which game settings a person has to how well they can play a game.

Well, i was kinda hoping someone would come up with some smart idea.
when it comes to this kind of things i only know the basic.

However, if we skip the smart ideas and just use a practical one.
A button sends everyone into a ingame sequence, that for an example would first detonate 10 kroggs/coms then 50 kroggs/coms etc.
And during this the individual speed will be recorded and be inputed in a string that in the end will apear as a popup window for the host.
(And plz dont flame the idea, i know its farfetched, but i supose it "could" work )

edit: another thing occurred to me, in the code there must be something that looks up the slowes individual so it could slow down so that he would not crash, couldnt this same thing be used to see who was the slowest one before you actually started the game, (in a short ingame sequence like that one abow)
edit2: Couldn't someone "elaborate" the code so instead of just finding and determing the best speed for the slowest individual, look up everyone and put all the data in a string for the host to get in a popup?

And then they change lobby or spring to give fake results, or they just change the lobby because then they don't have the hassle of waiting for it.

All that's used is the cpu percent, widgets already can and do access it.

Instead of all this, we can easily add a checkbox to only use players, not specs, when setting speed.

lurker wrote:And then they change lobby or spring to give fake results, or they just change the lobby because then they don't have the hassle of waiting for it.

Its not a simple lobby matter, you would in essence start another short game, its not a lobby, its spring itself, but if you meant that they would get another "spring" that differs ours and still be able to play with us....

edit:
Your idea of those boxes are intresting, but what if one of the player are the one that later on in the game will lagg?

I still say that it would be good to have some sort of information about the varius speed of everyone involved.

sad to see the discussion about how to find out the slowest pc and kick em instead of how to make it possible for low spec pc to play!

dust wrote:sad to see the discussion about how to find out the slowest pc and kick em instead of how to make it possible for low spec pc to play!

edit: I see your point, but im currently in lack of ideas that would improve the preformance of the game engine...

Well, i think this have gotten away from the topic a bit, but what im trying todo is just to make a playable game.
This should problebly be posted in development instead.

But that doesnt matter, this would still be a useful tool,
i dont even think it would be hard to fix,
i mean, you just get a button next to start,
that says "test start" or something.
The game would then be launched like a normal game, but with a script that spawned kroggs and detonated them in rapid order.
And to feed the data into a popup window for the host to get after the short sequence have been made and they are all back in the battlewindow.