Server Drop Fix Idea : Saved Games

Ideas for expansions and improvements to Defcon

Moderator: Defcon moderators

User avatar
PSBirch
level2
level2
Posts: 82
Joined: Thu May 03, 2007 6:22 pm
Location: Seattle, WA

Server Drop Fix Idea : Saved Games

Postby PSBirch » Sat May 12, 2007 4:08 pm

I've kept a roughl tally of my last 10 games and these are the results:

- 2 wins
- 3 losses
- 4 server shutdowns
- 1 server crash

I don't know if others' experiences are similar, but half a chance of a server shutdown before the end of the game seems pretty typical. As this is significantly hampering my enjoyment of the game, I've been trying to think of a way to mitigate the annoyance factor of losing the server. Here's what I've come up with: A snap-shot of the game that can be re-loaded and re-played after the server shuts down.

In terms of data, Defcon has a very simple set. There's bit of overhead -- players, territories, alliances, time-index, comm msgs, etc,. Additionally, a simple X,Y plane which every city, building, and unit has a position on. Each item has, if I'm correct, but nine additional data references: unique ID, owner, population, no. fighters, no. bombers, no. nukes, mode (ie, a carrier in bomber launch vs anti-sub), countdown to mode, and vector. Silos and subs are the only exceptions, where in launch mode they have vectors for their nukes. However as these nukes are also within the list it should be possible to have these items' modes and time-to-mode finagled once their container enters launch mode to maintain their state -- {Unit ID: xxxx, owner: ABC, Position X,Y (the silo/sub), mode: launch, time-to-mode: (container's time-to-launch + (position queue * interval between launches)), vector:target X,Y}. As this relates to save-game size on disk, and to the mean-time to resynch, the simple dataset should translate into a short resynch time.

Regardless, all this information is already within the game in some form. Two things would be required to implement the saved game: 1) the server push to the clients the datasets for all other players -- which I believe already occurs, and the client simply determines what portions of th data set is "visible" to the player. 2) a facility on the client side to save to disk all the data at a particular time-index. At a voluntary server shutdown, 1 and 2 could be easily managed -- part of the server shutdown process would be to flush the data at the present time-index. A server crash would be no more complex, though it would require that 1 above was a constant feature of the game.

A single player game could be be loaded from the saved game quite easily -- the player indicates which saved-game player he or she wishes to play, and then the existant "resynch/re-connect" processes implemented with the remainder being under CPU control.

However the ideal situation would have the whole of the game available. A 3rd function might be written to achieve this, which could be implemented in a variety of ways. The most appealing, from what I've been thinking, would be this: After shutdown, the players are kicked back to the lobby *together* into the familiar Ready screen, where they decide who will be the new server. They can wait for the original server-player to re-join and similarly any player who doesn't wish to continue the game at that point could leave and let the CPU take the player's place. After deciding the new server starts up and the resynch/rejoin process begins. The server receives the dataset from each player, reconciles them (hopefully something as easy as an md5 checksum, but given the heterogeneous Linux/Mac/PC environments, perhaps a slightly more complex data comparison would be necessary) and the game begins again in the slowest game speed -- and you're off again!

Yes, this is a little more than a patch fix, and might not be available until DefCon 2.0, if IV hasn't already anticipated the need. But I do believe there is a need. I think we're all familiar with some yahoos who'll shutdown their server as soon as they begin losing and some facility will be necessary to mitigate this behavior. And while this idea doesn't address server crashes directly, the save game functionality should have some application to crashes.

Anyone else have any thoughts on how to salvage a game from a server quit / server crash?

* As a caveat, and something that could be a simple patch fix -- how about, when a server quits / drops, we get a frozen screen akin to the Conection Problem screen so we can at least get a screenshot for our own personal archives?

Return to “Think Tank”

Who is online

Users browsing this forum: No registered users and 2 guests