I'm stalled in trying to get the new release out the door. I introduced a set of timing parameters in an effort to nail down the pace of the game. Not to slow it down necessarily, but to make sure that it doesn't continue to speed up as CPUs continue to become more powerful, and especially as we're on the verge of a major breakthrough in Internet performance. I've been working with Singularity to try to establish a set of timing values that will work well with modern, fast-paced games, and these will be defaults for the game. While Sing has been extremely helpful, he's also busy, as am I, so our progress has been slow. I thought I couldn't ask for a better consultant in this effort than Singularity, but at this point I think having a larger group of testers might help me to move more quickly.

I'm looking specifically for players with experience with modern scripting tools and tactics, as well as access to a reasonably fast server running the current public TWGS v1.03. What I'd like to do is analyze the timings of the most critical operations on the current release, then duplicate those timings as best as possible under the new version using pacing parameters. So any beta tester will need to be able to gather timing values for a variety of operations, then present those timing values to me so I can set the appropriate parameters (or even set them yourself in the editor), then time the same operation in the new game to verify that game behavior is unchanged.

As a quick overview of what I've been doing here, I've streamlined and optimized the game's IO so that it's about 10x faster (and more efficient) than it has been. So without any pacing, the game will play differently than it has. Now I need to slow it down to the point that it is currently running so that the new version will play just as modern players expect it to play. I've already introduced one generic pacing mechanism, connection emulation, that will allow a gameop to specify how much data a connection should transmit for input and output, as well as the connection's latency. This will allow some gameops to emulate older games if they choose to, but modern games will be played at the maximum pace of 1 Mbps and maybe 100-150 ms latency. This slows the game down from the maximum possible pace (which would peg CPU to 100%), but is still faster than today's games, which is why there needs to be additional pacing delays for most actions.

This is the last thing I hoped to accomplish before releasing this version. If I can get these timings nailed down soon, I can finally get this version out the door. If I can't get any assistance in establishing these timings, then I will be forced to release this game without timings appropriate to the modern game, making it the responsibility of the gameop to find the appropriate timings or else pass on the new version. I would hate to see that happen because I have invested a great deal of time trying to make this version suitable for today's active players, even though they are not my target audience.

IMO, the current beta is about as close as we're going to get w/o
a widespread test. I don't think we're going to get a widespread
test in a traditional setting tho. What we need is to expose it to a
turny and get feedback.

What kind of actions are pegging the CPU at 100%?

And yea, I think 1mbit and 150 ping are probably good defaults
to start with.

Well, without any pacing, just displaying the ? menu pegs the CPU to 100%. Really, anything would, because I've removed all of the internal delays that have slowed the game down in the past. Those delays were not easily controlled, while the new ones will be more directed.

You're probably right that we need a tournament, but I'd still like to get some timing numbers if I can, then after getting a set of starter numbers, try them in real games to see how they stand up. I don't think the 2 ms defaults will stand up well.

Wow. Ok, so how much does a ? need for pacing? How could we test
something like that, just flood a bunch and bring up the delay till it's
manageable... or?



You don't think they'll be enough, or you think they'll be too much?

that was a timely post JP... i just wrote a post that mentioned incoming speed.
Do i understand your efforts concerning the timing? : control the player speed thru the server by modifying the programming...?
I am way out of my league here.
Can i think of it like the performance of a resistor in an electric circuit?
if so... then is it possible to modify the player speed prior to server connection, using a seperate "resistor" like hub or card to slow signal. That sounds like it would alliviate the need to rip at the software.
It sounds so simply it is probably not a useful idea, but wanted to throw it out there.
Of course it would be up to the sysop to purchase the hardware needed to slow the incoming signal.
cc bee... out

> You don't think they'll be enough, or you think they'll be too much?

Well, I don't really know either way. Let me get a bit more into detail. I know you and I have discussed this quite a bit already, but for others who might be following along, I'll repeat some details.

You asked about how much pacing we need for the ? menu. Really, the bandwidth setting handles that. With 1 Mbps on the twgs.classictw.com server, bursting ? commands maxes the output bandwidth and the CPU fluctuates between a few % and 10%, probably averaged at about 8%. If it needs to be slowed more than that, then we would have to add a pacing parameter specific to ?. I'd probably use a pacing parameter for any display, not just ?, so there wouldn't be a ton of settings to deal with there. But I'm not convinced that there needs to be a separate pacing parameter for these, because output bandwidth should pace that.

The original game has some delays that are used for IO and event processing. But these delays are basically random from 0 to 250 ms for events, and 0 to 100 ms for IO. Those delays kept the game from running at full speed and kept CPU usage down. With those removed, the game will be more predictable. The 100 ms IO delay only effects a block of input, not each command. So in that way, it's similar to latency. However, it always adds to a player's own latency. The new latency emulation will basically have the same effect as this old IO delay, only it will tend to absorb a player's own latency up to 100 ms (or whatever it's set to) so that all players with ICMP latency < 100 ms would experience the same delay here. So that is a benefit of the new system. But still, this will only apply to blocks of input, not to individual actions. What I want is to pace actions themselves so that it doesn't matter if it's the first action in a macro burst or somewhere in the middle of an input block, you'd have the same pacing.

So to get back to your question, the current game basically has 100 ms+ICMP ping delay for the start of processing for a block of input, but zero delay for each action being processed (well, the per-action delay would be CPU processing time). The new system, with 2 ms synch delays and a 150 ms latency, would be 150 ms delay to start processing a batch of commands, then 2 ms minimum delay between each action. For actions that have very little CPU overhead, this should be fine. But there are many actions that have enough CPU overhead that they take longer than this 2 ms overhead. I'd like to determine what the current timings are, then set the synch delay to that timing so that as CPU continues to speed up, the game will become more efficient, but pace will not continue to speed up. An example of this is the comms system. Sending a comms message is a pretty CPU-intensive action, so a delay of 20 ms per line is more appropriate than 2 ms. This is just something that needs to be looked at on a case-by-case basis.

k. So what we need then is to test the release on as many
servers as possible, run commands and stuff, and report
back what generates a high load and how long it took to
resolve?

Any way to add that kind of logging into twgs so we could
generate lots of events and you can then track it?

I had suggested in another thread that we might like to play the SG Tribute game on the latest Beta.

What do you say guys? Let's kick the tires and light the fires!

I appreciate the thought, Cruncher, but I'd rather that tribute game run smoothly and be as much fun as possible, without worrying about balance issues related to these timings. I think it's going to take some effort before it's ready for a serious game.

Sing, to your question, yes, I probably could modify the current synch points so that they generate log entries showing the actual times between the synch points. That would allow people to just crank through a bunch of actions and record those measurements. Of course, the measurements would be taken on the new version, not the older one, and I really wanted to get measurements from the older one. There's no way I can log timing measurements in the old version. I think there would be some value to doing the measurements on the new version, but it wouldn't guarantee that the timings were close to those of the older version.

How about a practice tribute tourney game?. Also I would like to upgrade my twgs and start a server up and I would be willing to help in any testing.

Well, anything I can do to get some real-life activity on the latest beta would be great.

I'm actually very close to having this release ready to go public. I just want to get some feedback on the timing and then anyone who wants to upgrade will be able to do so. I don't want to extend the number of beta sites. I will benefit more from player activity on my personal beta site than I will from various other beta sites. Of course, once I get over this hump and the server is finally released, I will be looking for feedback from those who upgrade, and I will continue to address bugs and issues for as long as I need to.

Ok, let's just start with this. Can I just get as many people as we can to connect to twgs.classictw.com and just sit in a game? You can use game R, my stress-test game. I don't need more than one connection per player. I'm looking for as many connections from different IPs as I can get.

Playing the r game or stress game and pair port trading kept locking up after 2 to 3 trades. I am using the newest version of swath.

Ok it did it only 3 times then seemed to work fine.

The connections I've seen on there have been very helpful in finding and fixing some issues. Thanks! The more the better, though, so if you can round anyone up, I'd appreciate it.

bobad, keep me updated if you continue to see a problem. Major changes to IO here, so there might be something causing a glitch.

I will log in again when I get home, is there anything you want players to run? or just world trading be sufficient?