CONTENT LINKS
==============
Terminology
viewtopic.php?f=100&t=533#p8914
PBEM Mode
viewtopic.php?f=100&t=533#p8915
Online Play Mode
viewtopic.php?f=100&t=533#p8916
Networked H2H Play Modes: "Desyncs"
viewtopic.php?f=100&t=533#p8917
Technical Spoilers
viewtopic.php?f=100&t=533#p8918
===================================================================
The topic's contents may be modified or progressively added upon as time goes by.
===================================================================
TERMINOLOGY
=============
All-Human play modes are often referred to as Multiplayer or H2H play modes. H2H stands for "head-to-head" or "human-to-human" 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 is an "old-fashioned" form of H2H play. In fact, the very same human could be playing both sides (i.e., Auto-Hot-Seat). Play may be uninterrupted or punctuated by interim game-state saves.
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.
[VP] All-Human Play Modes
[VP] All-Human Play Modes
Last edited by HexCode on 2021-06-28 19:05, Monday, edited 4 times in total.
PBEM MODE
PBEM MODE
==========
The fact that PGF does not... 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 cannot be done. Not so...
Clearly, PGF does not 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 is that:
"PLAYERS SHOULD TRUST ONE ANOTHER"
How To Do It
Instructions:
1) The two opponents agree on some PGF scenario that they are 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., Side 0 or Side 1)
- 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., Side 0 or Side 1)
- 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 Side 0, he must zero in on file Autosave (Allies).pgsav.
- If, on the other hand, OPP-A plays Side 1, 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 over 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...
PGF does not include an in-built, match-making communication mechanism. Thus, players must arrange things using alternate communication channels such as E-mail.
==========
The fact that PGF does not... 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 cannot be done. Not so...
Clearly, PGF does not 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 is that:
"PLAYERS SHOULD TRUST ONE ANOTHER"
How To Do It
Instructions:
1) The two opponents agree on some PGF scenario that they are 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., Side 0 or Side 1)
- 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., Side 0 or Side 1)
- 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 Side 0, he must zero in on file Autosave (Allies).pgsav.
- If, on the other hand, OPP-A plays Side 1, 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 over 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...
PGF does not include an in-built, match-making communication mechanism. Thus, players must arrange things using alternate communication channels such as E-mail.
Last edited by HexCode on 2021-06-27 18:47, Sunday, edited 2 times in total.
ONLINE PLAY MODE
ONLINE PLAY MODE
=================
PGF's programming 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)".
For something like eight years, the Server arrangement and maintenance were in the hands of a gentleman who had assumed the requisite responsibilities and had been shouldering the attendant costs out of hobbyist camaraderie.
Currently, the requisite Server which makes this play mode possible is unavailable.
In any case, 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 does not include an in-built, match-making communication mechanism. Thus, players must arrange things using alternate communication channels such as E-mail.
Playing custom content does not 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.
In the past, the Server appeared to allow a limited amount of time for players to commence scenario play. The maximum number of minutes that the Server has been willing to "wait" before it "nullified" the attempted game is unknown to me.
=================
PGF's programming 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)".
For something like eight years, the Server arrangement and maintenance were in the hands of a gentleman who had assumed the requisite responsibilities and had been shouldering the attendant costs out of hobbyist camaraderie.
Currently, the requisite Server which makes this play mode possible is unavailable.
In any case, 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 does not include an in-built, match-making communication mechanism. Thus, players must arrange things using alternate communication channels such as E-mail.
Playing custom content does not 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.
In the past, the Server appeared to allow a limited amount of time for players to commence scenario play. The maximum number of minutes that the Server has been willing to "wait" before it "nullified" the attempted game is unknown to me.
Last edited by HexCode on 2021-06-27 18:48, Sunday, edited 4 times in total.
NETWORKED H2H PLAY MODES: "DESYNCS"
NETWORKED H2H PLAY MODES: "DESYNCS"
=====================================
The Internet is a Wide Area Network (WAN). Information does not 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 is 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 is 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 is 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 is not thought clearly through from the beginning, but not always). That said, here is a list of other factors that can also impact the frequency of "desyncs":
A) The computer cannot 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 cannot 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 cannot 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 is likely to lose packets. He will lose information the server sent or the server won't get his computer's data. If the game cannot 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 are two additional reasons why a game session may get out of sync:
(i) Random number generation that is not properly deterministic; and,
(ii) Floating point representation and math that are not standardized.
It is the job of game developers to ensure that "Sync Errors" do not 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 is 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 will not 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...
=====================================
The Internet is a Wide Area Network (WAN). Information does not 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 is 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 is 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 is 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 is not thought clearly through from the beginning, but not always). That said, here is a list of other factors that can also impact the frequency of "desyncs":
A) The computer cannot 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 cannot 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 cannot 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 is likely to lose packets. He will lose information the server sent or the server won't get his computer's data. If the game cannot 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 are two additional reasons why a game session may get out of sync:
(i) Random number generation that is not properly deterministic; and,
(ii) Floating point representation and math that are not standardized.
It is the job of game developers to ensure that "Sync Errors" do not 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 is 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 will not 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...
TECHNICAL SPOILERS
TECHNICAL SPOILERS
===================
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")...
===================
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")...