List of ideas and enhancements

This page contains a list of ideas and enhancements that have been proposed and discussed by players.

General game behaviour and game model

• Turns per day.
  Description: As mentioned in #197, even though each scenario has a special parameter indicating how many turns should pass before a new calendar day starts, it is not accounted for. In other words, at the moment every turn triggers a new calendar day.
  Impact: game engine.

• Profiles/rule sets.
  Description: Even though we try to follow game model as defined in PGII, there are ideas and proposal to experiment with slightly different rules. As an example, artillery support during the ranged attack, ranged anti-tank attack only during LOS, etc. Instead of hard-coding all these details in the game and arguing which model we should follow, we can just introduce support for "PGII default", "OpenGeneral default", and "custom" profiles so that we can experiment with different game behaviour.
  Impact: game engine, UI, saved files.

• Deployment and supply hexes.
  Description: PGII game model assumes that in the beginning of the game you can deploy units only to the deployment hexes, and in subsequent turns only supply hexes can be used. In addition to it, one deployment/supply hex can be used only for one unit per turn. It provides a mechanism for the scenario designer to control how many units you can inject without caring too much how big army you have. On the contrary to it, OpenPanzer allows to deploy as many units as possible through a single deployment hex within one turn. The enhancement is to introduce same or similar model as in PGII.
  Impact: game engine, conversion scripts (to differentiate between supply and deployment hexes).

Units and related enhancements

• Disband/downgrade units.
  Description: This enhancement is part of the PGII functionality. Since unit downgrading will require more efforts, we can introduce a new "disband" button so that we can sell a particular unit. To make it simple, the amount of received money can be calculated by the same formula which we use now while upgrading units.
  Impact: UI.

• Unit names.
  Description: While SCN scenario files in most cases provide exact historical unit names (e.g. battalion/regiment/division/corps), the game does not import those names into XML files. The enhancement is to import correct unit names so that they can be displayed in the unit inspect window adding historical accuracy and realism. As a related enhancement, there should be a way to rename (at least) core units so that once a new unit is purchased, a particular name can be assigned to it.
  Impact: UI, conversion tools (to add unit names into XML files), saved files.

• Artillery support during ranged attack.
  Description: In PGII and in the current game model, artillery support is provided only during the close combat, whereas ranged attack (e.g. from a tank) does not trigger any artillery support. However, it is more than common/normal that artillery provides support fire regardless of the distance at which you are attacked. To make it more realistic, we can assume that artillery support is provided when a unit under attack can see an attacking unit (or alternatively, when an enemy attacking unit can be seen by any unit). As an example, if a tank attacks infantry at range 2, artillery support will be provided because infantry visibility range is usually 2. At the same time, if a self-propelled gun is being attacked by a tank at range 2, no artillery support will be provided since the former has visibility range of 1.
  Impact: game engine.
  Ruleset specific: yes.

• Transport options during upgrade.
  Description: As reported in #185, while upgrading a particular unit the game does not enforce you to upgrade the transportation unit, if so required. As an example, you can buy a light artillery with horses, and upgrade it later to a heavy artillery without upgrading its transport to e.g. half-track heavy tower, which could be the only option if a new heavy gun unit is purchased.
  Impact: game engine.

• Transport pool.
  Description: As proposed in #186, once you a buy unit with a certain transport option, the only thing it is possible to do later is to upgrade the transport unit, but it is not possible to change it flexibly. As an example, suppose you have a cannon or an infantry with Opel truck. While it is a perfect choice for plain terrains, swap/muddy terrains would require half-tracked or even tracked transport to be able to move quickly. So, depending on the scenario you play and a strategy you pursue, you might consider different transport options for your cannon and infantry units, especially if a particular scenario has a mixture of different terrain types. In summary, you may have a pool of transport units, which you can attach/detach to your units in the beginning of the game.
  Impact: game engine, UI.

• Basic and current unit strength.
  Description: As proposed in #193, at the moment the game only supports current unit strength, whereas SCN files define both basic and current unit strength. The use case is somewhat limited, but it might be useful to model core units of reduced size, e.g. just 2 companies instead of the whole battalion comprising 4-5 companies. Similarly, this enhancement would allow for buying units of reduced size, e.g. 5 instead of 10, which could be useful when you do not need full strength recon unit or when you do not have enough money to buy full strength Tiger or Ferdinand.
  Impact: game engine, conversion tools, saved files.

• Air-borne and air-transportable units.
  Description: According to the PGII game model, there are units type, such as paratroopers, that can be deployed to any hex. And on the contrary to it, there are some units, such as light infantry and guns, that can be transported over air but can loaded/unloaded only at airfields. At the moment the game follows somewhat simplified model, in which we do not account for those differences allowing any infantry unit to be transported over air and be paradropped at any hex. As the outcome, some scenarios are logically broken if played with OpenPanzer. There is "Green devils" campaign which is effectively not playable at all with the current version of the game.
  Impact: game engine, conversion tools.

• Flak and anti-air units.
  Description: PGII has two different unit classes, Flak and anti-air, with somewhat different rules and behaviours for each of them; however, those differences are really questionable. For instance, OpenGeneral game deprecated Flak unit class completely and model all the units as anti-air with the corresponding unit attributes. It is possible to follow the same principle and to model all Flak units as anti-air class (and in fact some Flak units are already modelled as anti-air).
  Impact: game engine, equipment files, conversion tools.

• Air and naval transports.
  Description: In some scenarios it is possible to transport units over air/sea if the scenario has transport units of a particular type. However, there is no way to buy (additional) transport units. Thus, the enhancement is to add the corresponding functionality (availability of which can be controlled by PGII default or a new ruleset).
  Impact: game engine, UI.
  Ruleset specific: yes.

• Defence modifier depending on the unit direction.
  Description: In the real life, it matters from which direction you attack a particular unit type. While the attack direction could be somewhat irrelevant for infantry, it would have a greater effect on tank and heavy artillery units. Since the game model knows unit direction, i.e. which direction it faces, and the direction from which an attacker approaches, it is possible to apply an additional defence modifier. For the sake of simplicity, the corresponding defence modifier can be assigned per a unit class.
  Impact: game engine.
  Ruleset specific: yes.

Interface

Media

• Unit dying sound. When a unit is destroyed the same "dying" sound is played. However, it could be different for different unit types, e.g. sound of crashing airplane, sunk ship, etc.

• Background/ambient music. The SCN file has the corresponding field indicating which music file should be played in the background. Even in those scenarios when this field has a non-empty value pointing to a particular MUS file, we do not play it. One of the reasons is that SCN files refer to music files in the PGII specific MUS format. So, one way to circumvent around the problem is to keep references in the SCN files, but convert music files into WAV format. As an example, if the SCN file refers to the "germany[.mus]" file, we can play "germany.wav" file.