Test Plan outlook...

[JanSorensen]

The usual approach in games (unlike databases) is to only commit to persistent files when the user actively asks for it (which in a sense includes auto-saves). Its also usually considered cheating to revert to an old save unless you are forced to by a bug or a crash. So, if the application crashes information is lost and you have to revert to an old save which could be hours old but unlike (some) business applications this is not a real problem. Thus persistence of data is not major issue in game design.

Undoing moves on the other hand is normally done purely in memory and may normally only be done back to the last point where something happened that was outside the moving players control (the (possibility of) unveiling of hidden enemies, any rolling of dice, any option for the enemy to react etc). Thus I expect that you can move your land units experimentally undoing moves as you wish untill you trigger even the smallest thing outside your control. Once thats done all moves prior to that point should be locked in place.

[Shannon V. OKeets]

ORIGINAL: JanSorensen
The usual approach in games (unlike databases) is to only commit to persistent files when the user actively asks for it (which in a sense includes auto-saves). Its also usually considered cheating to revert to an old save unless you are forced to by a bug or a crash. So, if the application crashes information is lost and you have to revert to an old save which could be hours old but unlike (some) business applications this is not a real problem. Thus persistence of data is not major issue in game design.

Undoing moves on the other hand is normally done purely in memory and may normally only be done back to the last point where something happened that was outside the moving players control (unveiling of hidden enemies, any rolling of dice, any option for the enemy to react etc). Thus I expect that you can move your land units experimentally undoing moves as you wish untill you trigger even the smallest thing outside your control. Once thats done all moves prior to that point should be locked in place.

MWIF runs pretty much as described in the above 2 paragraphs.

During a movement phase (there are several distinctly different ones), the player moves units around and the game keeps track of what has moved from where to where. The status boxes above each counter indicate which units have moved and which have yet to move. There are often units that can not be moved and they are marked as such too. If a player wants to undo a move, it can be readily undone. The player controls when he ends a phase and at that time all the moves he has entered are committed to and can not be undone.

As Jan noted, there are some instances where merely moving a unit commits the player to the move. In WIF the best example is moving naval units through a sea area where enemy units have the opportunity to intercept. It doesn't matter whether the enemy actually intercepts or not. Simply moving units such that the enemy has to make a decision commits the phasing player to the move - no undo allowed.

I am more generous in saving game positions. If the player wants to save a game position, why not let him. He paid for the game, who am I to exert parental authority? There are some complicated situations where savnig a game is difficult. For example, if during a naval combat some units are aborted and have to return to base and while so doing they get intercepted by different enemy units and a new sea action occurs. That is a lot of stuff in progress to keep track of and restore a game back into the middle of. So, there will be times where saving a game will not be an option - but that is more related to the difficulty of coding it, than any moral imperative. If the player wants to save and restore before every die roll, it's his software and he can use it as he likes [as far as I am concerned].

I am also maintaining a game record log which records moves once the player has committed to them. I actually think of this as both a temporary and a permanent record. The temporary storage occurs when a player saves in the middle of moving his units. The moves are in the game record log but they have not been committed to. They can be undone. This is to protect against machine crashes or even the simple occasion of a plyaer forgetting to save before exiting the program (perhaps abnormally). The idea is that the player can restore a game from the last saved position and the game record log, even if he was in the middle of doing something. There are a couple of ways to do this and I haven't decided which to use yet, so I can't be much more specific than this vague generality.

[JanSorensen]

Sounds good Steve

I certainly did not mean to imply that the game should disallow saving just because reloading might be considered cheating. That is, as you say, up to the player (when playing the AI).

I do hope though that you consider some sort of basic anti-reload-cheat feature for pbem games. Even though its usually possible to curcumvent such protection for the determined cheater its still a good idea to atleast prevent cheating on the most immediate level.

The game log and its application concerning the restoration of a position after a crash sounds interesting. I am looking forward to seeing how that pans out.

[Frederyck]

When undoing moves, will it be possible to undo moves out of order? Ie, can I move unit 1 from one hex to another, then move unit 2, and then undo the move of unit 1 without affecting unit 2?

[Shannon V. OKeets]

ORIGINAL: Frederyck

When undoing moves, will it be possible to undo moves out of order? Ie, can I move unit 1 from one hex to another, then move unit 2, and then undo the move of unit 1 without affecting unit 2?

Yes. Each unit has its own undo move information. There are some exceptions where moves are linked. For example, when 3 land units are moved as a group and perform an overrun. Moving transported units is another case. In general though, you can undo any movement 'order'. Most orders for movement involve only one unit. Those that move several units at once can only be undone as a unified group.

[buckyzoom]

Thanks for the answers everyone!

[buckyzoom]

Hey, what are the projected minimum system requirements for MWIF?

[Shannon V. OKeets]

ORIGINAL: buckyzoom

Hey, what are the projected minimum system requirements for MWIF?

I don't know for sure. 16 bit color graphics card minimum. Windows 98 not supported. Beyond that I am going to rely on the playtesters to tell me if the system response rate is too slow on certain configurations.

I have yet to add the detailed bitmaps for: the coastlines, the air units, and the naval units. But I do not expect that to impact screen redraw speed.

I will have the AIO execute as a separate thread in the background while the player is shoving units around on the screen, so as much preliminary work as possible will be done for determining the AIO's move before the player passes control over to the AIO. The last time I wrote an AIO was for an Atari 800 which had a CPU speed of 1.2 MHz. AIO response rate was a real problem then (only 32 kb of main memory and the disk dirve capacity - used for swapping code overlays - was 128 kb. Yes, I mean MHz and kb.

I am developing the program using a 2.53 GHz CPU with 1 GB of main memory, 80 GB drive, under Windows XP Professional. Even with the debugger running interference when I test program execution, screen redraws are less than 1/10 of a second.

[stretch]

Steve,

as long as you're logging moves so they can be undone, are you planning on keeping a log of the moves for the game in its entirety? It sure would be cool to be able to look back at everything you did during the game. As a matter of fact, the more info in this log the better. Moves, attacks, losses, etc. Sure it might be long, nasty, and messy looking, but there are people here who, post-release, would most certainly devote their energy and time to writing utilities to parse the logs and produce reports. All you would really need to do is leave the info behind in some form for people to mess with later.

Stretch

[Shannon V. OKeets]

ORIGINAL: stretch
Steve,

as long as you're logging moves so they can be undone, are you planning on keeping a log of the moves for the game in its entirety? It sure would be cool to be able to look back at everything you did during the game. As a matter of fact, the more info in this log the better. Moves, attacks, losses, etc. Sure it might be long, nasty, and messy looking, but there are people here who, post-release, would most certainly devote their energy and time to writing utilities to parse the logs and produce reports. All you would really need to do is leave the info behind in some form for people to mess with later.

Stretch

Here is a copy of my earlier reply to this question. It is buried in the abyss of earlier threads.
=================
Here is the first section of the 28 page document I have written on the game record log. The other pages list all the record log entry types. There are over 450 unique entries for MWIF. If you are desperate for something to read, I am willing to send a copy of the document in PDF format to anyone who asks (Steve@PatternDiscovery.us).

===============
Game Record Log and History File
(as of October 9, 2005)

I Overview

MWIF maintains a record log of all events that change the game state. Each record log entry is a text string, comma delimited, that records an atomic level of detail. For example, “E1512, ULMv, T1000100, P2, U199, H2010, H2011" records Entry 1512, where Player 2 Moves the Land Unit 199 from Hex 2010 to Hex 2011, as part of transaction T1000100. There are over 450 different entry types/codes that control all modifications to the starting game state. In aggregate, the record log entries progress the starting game position incrementally through the entire game to the final game position.

The record log serves as a repository for the history of a game and can be used to replay a game in its entirety. In combination with saved game files, an individual turn or impulse can be replayed. Note that each entry contains sufficient information to retract (undo) an action. What this means is that an entire game can be played backwards, starting with the end of the game and receding in reverse to the starting position. As an additional function, the record log is used for debugging the game.

Record log entries are processed by the record log entry processor (RLEP) which, for PBEM games, validates entries received through email and from eMWIF. For other modes of play, all entries are generated by MWIF itself and do not need validation. The RLEP is responsible for keeping the copies of the game residing on different computers synchronized. For security’s sake, the record log file is kept encrypted during play. After a game has been completed, it is decrypted for replay and after-action reports. During a game, a player has the ability to replay the game from his own perspective, but can not see what the opponent has done (or at least no more than he can normally see during a game).

Note that saving and restoring games is not part of the record log. Because different players can save the game on different computers, it is impossible to guarantee that the record logs are identical if they contain entries about saving games. However, each saved game contains the name of its associated record log and the most recent entry # in the record log at the time it was saved. In particular, the PBEM system expects players to have saved games that are out of sync on different computers. It uses the record log entries to bring each game up-to-date as play progresses through email.
======================

[stretch]

Pah.. I knew it would already be there. Searches on this board and I don't seem to get along, I missed it.

[c92nichj]

I am developing the program using a 2.53 GHz CPU with 1 GB of main memory, 80 GB drive, under Windows XP Professional. Even with the debugger running interference when I test program execution, screen redraws are less than 1/10 of a second.

Have you noted any difference in redraw speed at different zoom levels?

[Shannon V. OKeets]

ORIGINAL: c92nichj

I am developing the program using a 2.53 GHz CPU with 1 GB of main memory, 80 GB drive, under Windows XP Professional. Even with the debugger running interference when I test program execution, screen redraws are less than 1/10 of a second.

Have you noted any difference in redraw speed at different zoom levels?

Yes, at 25% and 50% it takes long enough that you can see the screen be drawn, if you pay attention. At 75% on up the screen redraw is as fast as I can press a key or click a mouse. I can cause the screen to lag behind me if I type in 4 or 5 up arrows very quickly. The lag is still only 1/5 of a second though. I am running this in the debugger, which makes it slower too.