I had an idea of what I hope will be a better approach to the game pacing that I want to introduce.

What we were talking about before was a system where many actions would be given an additional "micro-delay", a delay that's as short as I can do within timer resolution, but long enough to "lock in" the pace of the game, irrespective of CPU speed. My concern here is that as CPU speed continues to increase, the speed of taking certain actions will continue to increase while the speed of paced actions like movement and attacking will stay constant (or approach the constant delays). Based on the Win32 sleep function, the smallest I could make these "micro-delays" would be 15 ms.

After trying some other things, I discovered I could use a waitable object to achieve accurate delays of a few ms, making it possible to make these micro-delays so small as to be difficult to discern from the current "zero delay", but at the same time locking in the pace of these actions so that they don't continue to change relative to delayed actions.

But while exploring this new approach, I came up with an alternative idea I'd like to consider. It's slightly different from delays, but has the same basic effect on scripted play. It also has the potential to give gameops some flexibility in trying to create game edits that will limit the effect of network latency, and also level the playing field between manual and scripted players.

The new approach uses synch points. Basically, a synch point initializes a timer, and it tests the time that has elapsed since the last synch point. Most synch points will use a default elapsed time, though some can be set to different values in particular cases. The point is, as long as the elapsed time between two synch points is greater than the specified duration, no delay is used. But if the elapsed time is less than the specified amount, a delay is called that will hold processing until the specified duration is reached.

Here's an example. Let's look at a landing/taking off delay. Suppose I want to set a pacing delay of 50 ms for these actions. If you're sitting at a prompt and you hit 'L', the time since the last synch point will be larger than the 50 ms delay, so no delay is used. But now let's consider what happens if you send a macro of "L Q". This is a simple land/take-off macro. The initial "L", assuming you haven't done anything else immediately prior to sending it, will have zero delay. But the "Q", entered immediately following the "L", will occur before the 50 ms synch delay has expired. A delay is used to hold the "Q" action until 50 ms after the synch point of the "L" action. If CPU load is high and the "L" action takes, say, 30 ms to complete, then the delay would only be the additional 20 ms needed to reach 50.

In some cases, there will be keyboard entry between synch points, so that any time lost to latency, CPU, or speed of entry is absorbed into the synch delay. And this is where it's possible to introduce delays that would tend to level the playing field regarding network latency as well as entry speed. I know many scripters would want to avoid any long synch delays, but if a game used, say, a 250 ms standard synch delay, then this provides a buffer of a quarter of a second that can offset differences in latency or entry speed.

One place these synch points would be used is to pace the response to event triggers. Whenever a player receives a "player entered sector" event notification, or a fighter notification, for example, this would trigger a synch point reset so that no synched action could be taken immediately following the event in less than the specified synch delay. Again, this would tend to decrease the effect of latency on gameplay. If a synch delay is 250 ms, and player A has a ping of 100 ms and player B has a ping of 250 ms, player A gets the event notification and sends a command within 100 ms. But the synch delay is 250 ms, so an additional 150 ms delay is issued prior to taking the action. Player B receives the event and sends a command 250 ms after the event. No additional delay is issued here. In this case, both players take the action in the same amount of time. Had there been no synch delay, player A would have been able to react over twice as fast as player B.

Obviously there are some complexities in how these synch point delays will effect current gameplay. My goal would be for default synch delays to impose a "maximum pace" that's fast enough that current scripted play is not effected much, but at the same time locking that pace in so that future hardware improvements don't change it. I would be very much open to feedback from players on how to avoid disrupting the current gameplay. I would also like to provide a screen of synch delay times so that gameops could explore these settings themselves and create special game edits for particular circumstances like non-scripted games.

I know this all sounds very complicated, but implementation-wise, it's very simple. I'd like to try this out in a test game on classictw.com and see how much of a disruption it is from currently expected gameplay and then go from there.

It's an interesting idea. I can think of a few good ways we can use
it, but at the moment it doesn't address the real concerns I had with
delays.

Let me explain...

Changing scripted play is not a problem, but imbalancing the core
nature of the game is. Right now, gridders have a very slow lead
over grid defense. It's so slow, that as long as a person grids
a little bit and defends a little they can usually keep a stalemate.

That's a good thing, because otherwise nobody will ever be able
to develop planets. If it takes 3 days to go mobile, who is going
to get to keep one if its found in 1 day?

The real concern non-scripters have is the need to maintain constant
grid defense. That's understandable, but this doesn't address that
concern. We will, someday, have to find a way to do that. But that's
for another day.

So...

The problem isn't variable delay, it's 0 delay. A 0 delay means
that we can burst an infinite number of those commands to lock
up the server. Thus we need some small delays to keep the server
paced. Variable delay is not a concern, server stability is. We're
smart enough to deal with variance, but 100% CPU load is 100%
CPU load.

To that end, we need some delays. But if they're put in the wrong
place, it alters the balance of play. It only takes small changes
to do this. Delaying the land command is a perfect example of
altering the balance. That will make planet gridding impossible
because it sends 10 lands in a burst, even tho 9 of them don't
succeed. That gives grid defenders much much more power than
they currently have.

This is why I recommended doing the delay after the landing, at
the defense check. It would lock in some processing delay on the
landing, preventing us from lagging a server to death and adding
stability, while not affecting the balance of play. It's all about
adding delays in exactly the right amount to exactly the right spot.

Which takes me back to the original discussion. Whether we use a
flat delay or a sync delay, we need to use exactly the right amount
in the right spot or the balance goes to heck and the version becomes
unplayable.

But, a 20ms sync delay on a pwarp is MUCH better than a 20ms flat
delay. It would give us the ability to balance out ping a little, and
not alter play too much.

Also, additionally, how would something like this affect CPC?

So I guess the next step would be to figure out where and what
delays to use, and what type of delay to use.

How does this tie in with max commands per cycle? I had always thought that the purpose of the max commands setting was to reduce the load on the server by slowing the commands that were processed. A default setting of 4 and the game drags.

A 50ms delay may not sound like much to a turns player, but move 5M ore at 250 holds a trip and you now have a 100ms addition (two planet landings/lifts) for each of the 20,000 trips this will take (2,000 seconds or 33 minutes extra?). Someone can correct me on this
time requirement.

It appears the changes would allow a somewhat sloppy script to compete against better written scripts. This would eliminate the need (desire) to create the most efficient script possible. A sort of "dumbing" down of the scripting community.

I can only speak for myself, but delays that slow down what I do are something I really dislike. I am an unlim turn player and speed is what help differentiate a lot of players, just as turn efficiency does in a turn game. I probably spend more time trying to improve script speed than anything else. If the game itself throttles the speed, then I can just pretty much toss together a script and not worry about its execution speed as much.

I have not seen the problem of hardware speeding up causing any in game problems from a player perspective.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

Moving 5m ore in 30 minutes is still pretty dang fast. 5m ore is
a lot of ore. Meanwhile during that move, the server CPU can
be spiked pretty high. A little pacing here would improve server
stability, even if it's 20ms instead of 50ms.

At 20ms:
20,000 trips @ 40ms per = 800 seconds or 13.33 minutes.

That's really good for moving 5m ore. If it's a sync delay rather
than a flat delay, you probably wouldn't notice it at all with the
various text flood delays.



The xport lag trick works better on faster servers since more
xports can be completed in less time.

I was thinking that would be the extra amount of time over what is currently required. I haven't ever timed the ore move, but I know it takes a long time (esp at 4 CPC) and the additional delay would take even more. It probably needs some delay to prevent a server kill script from working or just bogging things down, but it should be as small as feasibly possible.

               / Promethius / Enigma / Wolfen /

"A man who has no skills can be taught, a man who has no honor has nothing."

From what JP describes, a sync delay would basically timestamp
2 actions. If the 2nd action happens greater than the delay, then
there's no extra delay. If less than the delay, then there's a delay
of the difference. So if it takes 5ms to do the move, and 10ms for
the text to get paced out by the server, then the added delay
would only be 25ms per round rather than 40ms.

On actions like move, this would be really sweet. For instance a
270ms sync move allow us to pace the delays to keep balance,
but would also mean that server processing such as figlay would
be vastly reduced. To that end, we might need to tweak the numbers
a little, but the concept would be solid there.

Since we can work w/ smaller delays, an xport delay of 20ms sync
would also accomplish the same results. Bwarp, pwarp, all of it would
benefit from this approach. I wouldn't delay firing a foton however,
because that just adds a lot of complications. I'd also be very careful
about planet landing delays, but a 20ms delay at the defense check
would be fine as long as it happens after the actual landing.

In game delays to pace the game and make it slightly less ping sensitive as well as allow the server to process the game as designed would be a good thing imo. LOW CPC settings are are poor way to control server stability but its the only thing the sysop's have atm so we deal with it. A game with well balanced delays evens the playing field a little and make the speed and efficiency of the scripts more important NOT less....

I appreciate this discussion. It's a complicated issue but I think we're making progress on a way to improve the current situation.

I see this as a replacement of CPC. That was an early attempt to accomplish some degree of pacing, but it's flawed in a number of ways. For one thing, a "command" is any prompt, which means if an action has 3 sub-prompts, that counts as 4 total commands. What I really want here is a pacing of whole actions, regardless of the number of info prompts they might have. Also, the CPC allows commands to be processed as fast as CPU will allow, but once the limit is reached, the process waits until the end of the cycle. So all of the processing is jammed into the start of the cycle, and the idle is at the end. And finally, CPC puts the delay at the prompt. There's no way to control at what point in an action that delay is placed. Synch points solves all of these problems. I place a synch point after all lead-in processing (sub-prompts, checks, etc), but just prior to the meat of the action (processing and committing data). This way there's only one synch point per major action (not per prompt), the delay is placed exactly where we need it to be placed on a case-by-case basis, and the actual delay is related to a target "commands per cycle" by setting delay = CycleTime/CPC (or set specifically on a case-by-case basis). So just as an example, a 4 CPC setting would result in a synch delay of 250 ms. Every synched command would be spaced from the previous synched command by 250 ms, and that time would absorb latency and CPU time used during those commands. A setting like we've been talking about, 20 ms, would be a setting of 50 CPC.

Another point to consider is that I am able to reasonably support pacing delays as low as 5 ms (200 CPC) with high accuracy. This is a lot more flexible than what I had before. Putting a minimum time between actions of 5 ms would mean that on slower systems, the game would run at the pace allowed by CPU, but on faster systems, the game would tend to run at a pace of 200 commands per second maximum. This is a very small delay, but there are actions that currently run at a much higher rate and push the CPU to 100%. By having such a pace in place, as CPU speeds continue to increase, there will just be more CPU available for more people to run at full speed without anyone having an advantage. Ideally, I'd like the game to be able to support something like 20 players running full CPC with no more than half of the CPU in use, allowing the game to run smoothly and consistently for everyone.

The emphasis here will be more on how well you use the limited number of commands per second rather than how many commands you can squeeze into a second. I think that's a positive thing. But I also think that at the extremes, the number of commands per second will be high enough that you will feel very little difference over the way the game currently plays.

I forgot to mention that I agree that the first goal is to introduce a set of synch point delays that balance the gameplay, without concern for something like attempting to balance the playing field for manual vs scripted players. I think that's something that could be looked at later. The main thing to look at there, I think, is the event trigger delay. I don't think an event trigger delay is necessarily needed in a basic free-scripting game. But that option is there as a way to maybe decrease the advantage of bots in special games.

What I'm most focused on right now is really just trying to absorb CPU times in current actions so that these actions can be locked in and will no longer be paced by the CPU itself. To that end, one approach would be to use profiling to determine how long a particular action takes running on a baseline CPU and then use that as the synch delay for that action. So if a planet update takes 10 ms on the baseline system (drive speed as well as CPU are a factor here), then a planet update could be given a synch delay of 10 ms, locking it in at the current speed so it will function at that speed from this point on no matter how much systems improve. In practice, I'd probably want to baseline this on a system that's a few years old so that modern systems have a bit of breathing room.

Sing, I think you're right that there needs to be some additional thought put into balancing these times to optimize gameplay, but as a general rule I think a good starting point could be obtained by profiling the actions in question.

Would it be possible to do 2 separate delays?

Say a sync delay that we use to balance the game on a command by
command basis AND a separate CPC delay?

Because having the same delay for every command would be very
bad. It would mean that smaller commands are faster, and that
would shift the balance to a stalemate every time. Nobody could
beat an adj photon.

It would also mean that movement is considered just "a command"
same as scanning a sector. When, realistically, it should take more
time to move than scan.

Oh, and...

I've already profiled most actions. What do you need to know?

Yeah, I definitely don't intend to have the same delay for EVERY action. But on the other hand, I think a default delay is useful, and then we can tweak delays on a case-by-case basis.

Thinking about what I just posted in the previous post, if the synch is placed just prior to the heavy processing of a command, you can't really factor the time of that processing into the synch delay for that action, because in practice the time spent on that action is likely to be absorbed into the synch delay of another action except in cases where the same action is repeated multiple times. You could factor in the time that leads into a command, which will tend to be information-gathering prompts, etc. But a part of the delay between two actions will be caused by the processing time of the previous action, and you can't know what two actions are going to be paired and set a custom delay time based on a command pair. The best you could do would be to set a large enough standard delay that most command pairs would be completed with room to spare. Things move along so quickly these days that I think that's definitely doable.

So this is not going to be perfect as far as trying to customize delay times to actual current processing times as I proposed above. But I don't really think it needs to be. Just a reasonable commands per cycle is all I want here. But again, there may be certain cases where pacing should be faster or slower to effect gameplay and we can handle that.

Sorry if I'm talking in circles a bit. Just thinking out loud about this.

Oh, about moves, I'm treating move delay (and attack delay) as different from a synch delay. So when you issue a move, the time of the move is always the same. We could consider handling "zero move delay" with synch points and fractional move delays as true delays, but for now I have not done that. You have the synch point just prior to the move delay. So with a synch delay of 20 ms, and a "zero" move delay of 250 ms, the total delay could be 270 ms, though the 20 ms could be absorbed by other activity.

The functional issue for setting delay times per-action using the approach I'm currently using is that the delay is handled prior to the actual action. So if we say, for example, a planet update action should have a 20 ms delay because the act of actually updating the planet involves a lot of processing, then specifying that at the synch point for the planet update would cause the 20 ms delay to occur prior to the update. That's not really want we want, I think. Instead, a better approach would be to specify at the synch point how much time I want to elapse before the NEXT synch point can be processed. And in fact, though this does complicate things a bit, the most flexibility would come from specifying both a pre-synch and post-synch delay. At a given synch point, the pre-synch delay would be based on the amount of time we want to allocate for pre-processing on the command, things like prompts for gathering info and checking for validity, etc. This generally will be low-overhead processing, but there could be situations where pre-processing inputs cannot be simply burst in a macro, but instead need to be sent in response to output by the game, and in those cases, pre-synch delay could factor in reasonable latency delays. Post-synch delays would be the ones that take into account actual processing time, with some actions being very fast and some taking much longer to complete. Putting the two together, when you hit a synch point, the actual delay would be the sum of the post-synch delay from the previous command and the pre-synch delay from the current command. Such a system would allow me to really nail the current timing and lock it in, but it's really much different from the simple idea of a "commands per cycle" that's a more generic pace that ignores actual current processing times. If it's necessary to tailor delays to current processing times and balance, I can introduce this two-delay system. Functionally, it's pretty much the same as what I've done, it's just there's quite a bit more actual design that needs to go into defining these delays. I guess if that's the only way to do it right, though, that's what I'll do.

If the entire sync is placed before, yes. But what if
you adjust the concept a little to put the first half
of the sync before, and the second after? So that the
delay basically just pads out the processing? Wouldn't
that work for a small number of commands?

As for CPC, neither is a problem.

Now... move delay. I think the flat 250 plus the 20ms
will work fine.

I think a post-sync system would work fine too. I think
either would work, simply because a single action is not
a big issue for stability. It's large loops of actions that
cause the problem, and in that case before or after is
fine. I wouldn't worry about it too much.

So what kind of things do we need to time?

Ok, the code is in place to support two delays per synch point. Every synch point that's in place, except for moves and attacks, is set to default pacing, which is 20 ms per action. Half is applied to pre-synch delay and half to post-synch delay.

What we need to do now is make a list of actions that should be included in this synch system and propose delays from maybe 3 ms on up for both the pre-synch delay and post-synch delay for each. Anything on the list for which the default delay seems reasonable we can just ignore for now.

Sing, you said you had profile data. That would be a great start. We'll need to divide that up into pre-synch and post-synch delays for each action. Also, depending on the speed of the system you used for profiling, I may want to add a certain percentage to these delays to support older systems.

If this looks like it's going to be awhile to get it right, I can easily disable the entire system and release without any delays while we work this out.

That may be a bit much for every action. Like if I hit L command
10 times, then land on the last, would take take 200ms? In the old,
it takes about 10ms. Also what about laying figs and hitting figs?
In the old, that's about 10ms total. Currently, as long as you're less
than the CPC, some of these things take no time.

Trying to balance that will be tricky. We'd need a 500 CPC w/ that
system to get close. We can balance for the figlay/fighit, but the
landing... not so much.

That's why adding a delay to landing is tricky if it's done before you
reach the shields.

Ok, here's my list of commands we need to consider. We might
need to add a few... a default pacing will probably work for most.

Killing planet shields
Killing planet figs
Claiming planets
Evicting traders
Porting
Moving
Attacking
Landing
Displaying sector
Density Scanning
Holoscanning
Beacon
Locking tow
Towing a ship
Changing to the computer prompt
Changing to the corp prompt
Xporting
Getting I info
Getting / info
Firing a gtorp
Detting a planet
Jetting cargo
Turning on interdictor
Attacking
Eprobing
Laying fig
Killing fig
Displaying all figs
Laying armind
Laying limp
Showing mine list
Upgrading a port
Building a port
Setting navpoint
Plotting course
Setting avoid
Showing avoiding
Firing photon
Personal planet list
CZ ship list
various other computer prompt info things
Transferring cash via corp menu
Transferring shields via corp meun
Transferring figs via corp menu
Send corp msg
Corp planet list
Various other corp prompt stuff

I'm using a 3.2ghz P4 (hyperthreaded) to test this on. System
cost about $200 total, so its not a bad reference point. Its not
a multi-core system and there's quite a few machines faster.