As difficult a time as this is, I need to push ahead with the new release. When I left off just before the new year, I had SG running a beta version with new pacing parameters. I was working with Sing to come up with a set of defaut parameters that would work well with modern games. We were trying to nail down the timing as precisely as possible, but we hit a snag with some indeterminate delays. I spent a lot of time trying to figure out the origin of the lag, but have been unable to do so. It may be that it's not going to be possible to control the timings as precisely as we'd hoped. I think the timings are more tight than they've ever been before, though. What I need to know is if it's going to be possible to establish a set of timings that will allow the game to continue to play as it currently plays. I want to lock in the game timing, but I don't want to disrupt gameplay in doing so.

How much was that version played on SG's server? Are there any major issues with the timings that were being used on that server? I had planned to discuss this with SG this week and decide how to proceed. Basically, I need to know if I can require all games to use pacing, or if I need to allow that to be disabled. I could go either way, but I'd prefer to push the pacing by making it mandatory (but again, only if that doesn't disrupt gameplay).

The timing as it is will be difficult, but I can create
some estimates and just get something down. It may
have some issues tho, we might find they need
adjustments. I think we can get pretty close to
matching the old ratios.

The version hasn't been played a lot. And none of the
timings so far have been tested. So there hasn't been
an issue, but that doesn't mean there won't be one.

Question... without SG, are there any plans for the
server? We can't expect his wife to continue funding
it.

I don't have any plans for the server. I don't expect it to be available. I hope I can get back up and running on the 21-6 server so I can host my own. Otherwise, I may be back to where I've been most of the time, relying on sites like ice9 and others to bang out the kinks of new versions, or just releasing to the public and getting bug reports from them.

If not for the timing changes, there wouldn't be that much left to test. Aside from those changes, the version that's been running on Ice9 and the other beta sites is pretty stable and could be released to the public, I think. I would like to get some timings established and get that tested with real play, though, without disrupting a major site like Ice9. So that's tricky.

I think I'm going to take a look at changing TWGS to allow more than one server to run on a single site. That way sites like Ice9 can run a beta without having to disrupt their main games. There were some technical issues that led me to restrict sites to only one server per machine, but maybe I can work through those.

Great, that would be nice when trying to work through some issues. I do want to let you know I had a player the other night that had ran out of time and tried to get back in at extern and the Flag for time did not reset.
I am currently using 2.0.41.3114 was installed on 11/11/2010 file size was 1,394KB

Ok, I had a look at what it'll take to allow multiple versions to run concurrently. It's just too messy. So I'm just going to do my best to get this version out there without being too disruptive.

Sing, I think I'm going to put this out in wide beta with all minimal pacing rather than those that you suggested. Eventually I do hope we can put together a set of timings that work well for today's games, but until we have that, I think the best thing is minimal pacing so the game runs as fast as it can. We'll see how those minimal settings effect some of the games running at the wide beta sites. I just need to get this version out there and tested, and since I don't have a personal beta site at the moment, I need to push it out to the wide beta sites (those who want to run it).

The problem you're going to have w/o any timings, is that it's
essentially unplayable. The grid balance is completely out of
whack, it will make the game very one-sided. You do not want
the game to run as fast as possible, it will make it impossible
for people to even move against a ptorper.

At the very least, use the last timings I suggested. They won't
be perfect, but they'll be a huge improvement over nothing
at all.

Let's look specifically at what's changing here.

In the current version, the game accepts input from TWGS. There's some delay in TWGS processing input, and that hasn't changed. In TW, there's up to a 100 ms delay on grabbing new input into a buffer, but once it's there, it processes through input quickly, without any defined delays. In addition to those internal delays, you have internet delays which can vary from player to player, plus CPU processing times for the actual commands which will vary from server to server.

That covers input delays. The other important consideration is event delays. How long does it take for an event to be posted to the event queue and processed by another player? This includes in-sector events like "player just entered the sector", messages sent to players like "your fighters were attacked in sector N", as well as changes to a player's data like when attacked directly. These events are only processed once every 250 ms, though multiple events can be processed in the same "tick". So that means whenever there's an event generated, there's a delay of anywhere from 0 to 250 ms in a player receiving that event.

Ok, so if you put that together, there are a number of delays that come into play in interactive scripting. An event is generated, and you have from 0 to 250 ms before you receive it. Then you have a ping lag of, let's say, 50 ms one-way, just for illustration. That should be fairly constant for a given player, but as I said, varies from player to player. Then once an event is received, it's processed on the client side, then commands are sent back to the server. Let's assume the time to process and respond is negligible. Once on TWGS, there's a delay of up to 100 ms to pull any new data, and in some cases, the first block and all additional data in a burst do not arrive at the same time (haven’t figured out why, if it’s the Nagle algorithm at play or something in TWGS, etc), so really you can see 0-100 ms plus 100 ms (100-200 ms) for anything more than a single character command. I’m not sure whether or not the additional 100 ms can be ignored here. Let’s include it in the analysis. So after the game receives your instructions, the effect on the player can be almost instantaneous, though the player won’t be notified of it for up to 250 ms.

So the turn-around time, in the current release, for responding to an event, should be 200 ms to 550 ms, assuming a 100 ms ping. If you average out the variable delays, it would tend toward about 400 ms. Does that correspond to measured times?

Now, what has changed? What I’m trying to address here is not the turn-around time for event processing, but how quickly commands are processed once received, especially when multiple events are in the IO buffer and can be blasted through very quickly, as fast as CPU will allow. The pacing parameters I’ve added will limit how frequently any given command can be processed. The minimum pace is 2 ms, so 500 commands per second. For event-driven scripts, these delays would be absorbed by the other delays already discussed, so they would only come into play if those delays go away somehow. On the other hand, if those delays are increased sufficiently, they can absorb these other variable delays, making the game pace more consistent over various player connections and servers. That is a desirable thing, if it can be achieved without destroying gameplay.

I didn’t need to change the internal delays described above in order to implement the pacing system. I made those changes at Singularity’s request so we could attempt to tighten up the timing and make it more “by design” than random. So I removed the 100 ms IO delay and the 250 ms event delay, making these event-driven so that the game will react as soon as IO appears on the server, or as soon as an event appears in the game’s event queue. Because of this, the only delay in the above scenario should be ping delay, so 100 ms instead of 200 to 550 ms. That’s about 1/4th the average of 400 ms for the current version. So event response is definitely faster now, and that definitely will effect gameplay.

So there are really two things going on here. One is the addition of pacing for commands. But this isn’t really a factor in these event cycles. The other is how long it takes for a player to receive and respond to an event. I think if all I did was add minimal 2 ms pacing delays, it wouldn’t effect balance much. But by taking out those internal variable delays, I have definitely changed the pace of the game, and I’m not certain that setting pacing and delay values will adequately restore the balance. It may be necessary to introduce some way to replicate the variable delays caused by event and IO processing. Even if we can eliminate those delays entirely, I’m not sure it’s desirable to do so. Maybe it’s a good part of the game that there’s a variable response time of up to half a second so that no one script or tactic works every time. All I care about is that the pacing is “by design” and not driven by CPU and network speeds. But that pacing could certainly include some random variation if needed.

All of this detail is in response to the statement that I shouldn’t put in minimal 2 ms pacing values for the new release, because it would make the game too fast. In the current version, these delays are all 0 ms, so having 2 ms doesn’t “make it too fast”. It’s the lack of the variable, random IO and event delays that is making the game too fast under the new release. So maybe what I should do is use the 2 ms delays, but introduce a random command delay that will effect how quickly a particular action can be taken. Based on how the current game works, I’m not sure that having tight, consistent timing is a good thing. I wonder if having a fairly sizable random delay is preferable. Consider the current game where a 250 ms ship movement is really overshadowed by an up to 500 ms internal delay for event response. If you’re attacking a ship that’s generating an event, some of the time you’ll get a hit and some of the time you’ll miss. That’s better than someone with a good connection always getting a hit while someone with a less speedy connection always gets a miss using the same script, right?

What this really all gets down to is how long it takes to receive and respond to an event. That’s the only time these delays are important. I already introduced a delay for responding to events that have been received, but it’s a constant delay. Maybe it should be an option for this to be a random delay over a given range. That would be easy to implement given the current pacing system.