Page 1 of 1

[REF] All-Human Play Modes

Posted: 2019-11-03 22:59, Sunday
by HexCode



Online Play Mode

Networked H2H Play Modes: "Desyncs"

Technical Spoilers



All-Human play modes are often referred to as Multiplayer or H2H play modes. H2H stands for "head-to-head" play, meaning all-human play. The preceding terms distinguish things from the way more popular play mode where a human does battle against a software program's Artificial Intelligence (AI).

A) HOT SEAT stands for two human players taking turns playing a game utilizing the very same computer. It's an "old-fashioned" form of H2H play.

B) PBEM stands for "play-by-email". Two human players take turns sending one another E-mails with attachments containing the current game snapshots as play evolves. This too is an "old-fashioned" form of H2H play.

C) ONLINE stands for network-enabled, all-human play. This can be a Local Area Network (LAN) or a Wide Area Network (WAN) (i.e., Internet-enabled). Either way, the presence of an appropriately configured and effectively maintained server is practically required. The "traditional" technical approach has been to adopt a technical solution based on the client / dedicated server architecture.


Posted: 2019-11-03 23:40, Sunday
by HexCode

The fact that PGF doesn't... blare to the world that "Classic IGO / HUGO" play between humans is actually doable has led quite a few hobbyists to assume that, well, such things just can't be done. Not so...

Clearly, PGF doesn't make allowances for passwords. To boot, what is one supposed to do with... sneaky opponents ? Does all this necessarily imply non-viability ? Ok, the key point here's that:


How To Do It


1) The two opponents agree on some PGF scenario that they're about to PBEM. They also agree on the mutually acceptable Prestige, Experience, Weather, Supply and Fog of War settings.

2) The opponent playing the side that moves first (OPP-A) starts things by selecting the scenario to be played, making absolutely sure that the two "Player" radio buttons at the very top are selected (the default) and that all other agreed upon settings are effected. He then presses "OK".

3) OPP-A now looks at the black screen which exhibits the following information about his half-turn that is about to commence:

- Whose half-turn is about to commence (i.e., Axis or Allies)
- The half-turn's numerical identification
- The current scenario date
- Weather conditions
- The number of full-turns remaining to be played

4) OPP-A clicks his mouse anywhere on the black screen and gets going. Once he's finished moving, attacking and so on, he presses the "END TURN" button.

5) OPP-A may now look at the black screen which just exhibits the following information about his opponent's (OPP-B) half-turn that is about to commence remotely:

- Whose half-turn is about to commence (i.e., Axis or Allies)
- The half-turn's numerical identification
- The current scenario date
- Weather conditions
- The number of full-turns remaining to be played

6) This is critical !! At this point, OPP-A "closes" PGF by clicking the "X" button at the upper right hand corner of the screen...

The game will display the following rather ominous sounding message:

"Your current game will be lost. Continue?"

Undaunted by such... scare tactics, OPP-A bravely presses the "Yes" button... OPP-A now gazes at the familiar Scenario Selection Screen...

7) OPP-A goes into the "SAVE" sub-folder corresponding to the "Game" that the scenario belongs to (i.e., Panzer General, Allied General and so on). He identifies the Autosave (??????).pgsav file that's appropriate here. Thus,

- if OPP-A plays the Axis, he must zero in on file Autosave (Allies).pgsav.

- If, on the other hand, OPP-A plays the Allies, the file to zero in on is Autosave (Axis).pgsav.

8) OPP-A copies the identified file somewhere on his hard disk. He then renames the file to something appropriately specific. Finally, he attaches the renamed file to an Email (zipped, perhaps, to minimize the chances of file corruption due to electronic transmission) and sends it to OPP-B.

9) Upon receipt, OPP-B copies the received (possibly, unzipping it first) file to the "SAVE" sub-folder corresponding to the "Game" that the scenario belongs to.

10) OPP-B fires up PGF and clicks on the "Load Game" option. He then selects the option corresponding to the file that he just placed in the "SAVE" sub-folder and presses the "START!" button.

11) OPP-B is now in familiar territory...

By the way, the procedure outlined above establishes a no-frills PBEM environment. Specifically, it doesn't allow players to replay their opponents' half-turns...


Posted: 2019-11-05 15:48, Tuesday
by HexCode

PGF explicitly features an online play mode. Players should make sure that, down at the very bottom of the PGF screen and to one's right, it should say "Version 1.02 (May 28, 2012)".

Presently, the Server arrangement and maintenance are in the hands of a gentleman who has assumed the requisite responsibilities and has been shouldering the attendant costs out of hobbyist camaraderie. To this effect, the Server operation should be viewed on a "best effort basis". In other words, no permanent guarantees are possible when it comes to the availability and maintenance of day-to-day online play functionality...

PGF doesn't include an in-built, match-making communication mechanism. Thus, players must arrange things using alternate communication channels.

PGF Discord

introduces a specific such communication channel.

Playing custom content doesn't require that the requisite data reside "somewhere inside" the Server. As long as players utilize identical setups and content definition files, the Server has "no say" in the matter.

The Server appears to allow a limited amount of time for players to commence scenario play. The maximum number of minutes that the Server is willing to "wait" before it "nullifies" the attempted game is unknown to me.


Posted: 2019-11-05 23:21, Tuesday
by HexCode

The Internet is a Wide Area Network (WAN). Information doesn't travel over the Internet instantaneously. Data traveling between two different computers (i.e., client / server or client / client) takes a typically very small amount of time by human standards. This is referred to as ping, lag, latency and so on. It's the delay between when data are being sent to the other computer and the time that it takes for the triggered response being sent back to and received by the first computer (expressed in milliseconds). The lower the number, the better. Many people can get a ping below 100ms while most people can get one below 200ms. If one lives in a technically disadvantaged part of the world, he may have to live even with something like 500ms (that's half a second)...

"Sync Errors" occur in multiplayer online games because such games are attempting to run an identical simulation on multiple computers. That means that it's not a centralized server that is running the simulation. Instead, multiple clients are attempting to run an identical simulation with enforced latency and a queue of all user inputs all at the same time. A lot of games do this because it removes the overhead of server-side simulation and upkeep. It also renders the implementation of instant replay kind of easy. The downside to the preceding is that if either of the clients' simulation no longer matches up with the others, the simulation becomes "undefined". Which version of virtual reality is the "right one" ?

Invariably, "desyncs" happen because of careless programming of the network layer in games (often, because the layer is added later and isn't thought clearly through from the beginning, but not always). That said, here's a list of other factors that can also impact the frequency of "desyncs":

A) The computer can't keep up with the global simulation: this can be because the computer is too slow or because the ping to the server is too high. In any case, data can't be exchanged fast enough with the server to keep up with the current game state.

B) The Internet connection's bandwidth is insufficient: some games exchange far too much data to keep the clients in sync. If one can't send or receive data fast enough to keep up with the current game state, he will experience "desyncs".

C) The Internet connection's quality is poor and a lot of packets are being lost: if one plays on wifi with a bad range, he's likely to lose packets. He will lose information the server sent or the server won't get his computer's data. If the game can't handle this correctly, "desyncs" are quite likely to happen. But, note that packets can get lost even if one has a great Internet connection...

Here's a couple of additional reasons why a game session may get out of sync:

(i) Random number generation that isn't properly deterministic; and,

(ii) Floating point representation and math that aren't standardized.

It's the job of game developers to ensure that "Sync Errors" don't occur. Unfortunately, this is a rather high standard to meet ! Well known games have gone through multiple expansions and numerous patches and are still plagued by "desyncs". Upgrading one's Internet access and computer can certainly help. Nevertheless, if software are coded well enough "desyncs" would happen very seldom, even with sub-par hardware...

To combat "desyncs", some online games choose to use an architecture that rigidly forces every game state to stay synchronized at all times. Thus, in games blessed with dedicated servers, one can never get a "terminal sync error" that crashes the game in toto. One just reconnects and gets right back into the game... Obviously, the benefit here's that game data residing on different networked machines never get out of sync. At the same time, the downside to this is that any action a player may want to take (e.g., pressing a key or clicking the mouse) has to travel to the other computer, be confirmed as such and the confirmation, then, needs to travel back to the first computer before the player is actually allowed to take that action. If one is blessed with very low latency, he won't notice this delay between initiating a desired action and observing that action actually occurring on the screen. This sort of synchronization scheme works very well for slower games where not a lot is happening simultaneously (e.g., turn-based wargames).

Finally, ridiculously immature and self-centered players have been known to willfully cause "desyncs", lest their "pride" takes a beating...


Posted: 2019-11-06 03:34, Wednesday
by HexCode

Hot Seat Showstoppers

A program / application or even the entire OS misbehaving are not exactly... science fiction. Sooner or later, some hot seat game will be rudely interrupted by a game / computer crash. Such are the ways of technologies...

Corrupted Interim Saves

Whether PBEM or online, saving a game state with the intent to resume play later is never risk free. Deficient programming or freak memory conditions can readily corrupt the saved game state file...

Corrupted Transmissions

Whether one sends a PBEM attachment ("zipping" helps but is no panacea) or a client / server engages in data (re-)transmission, all kinds of things can go wrong in virtual space (e.g., "desync")...