-
Notifications
You must be signed in to change notification settings - Fork 38
List of ideas and enhancements
This page contains a list of ideas and enhancements that have been proposed and discussed by players.
-
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). -
MAPX format.
Description: Each scenario has associated map, which effectively comprises the background image and the MAP file that defines parameters of each hex (e.g. terrain type, roads, etc). One of the downsides of the legacy MAP file format is that it does not provide any railroad information. Even though the background map image may have railroads, there is no information on them. As a result, we cannot use properly railroad units, such as armoured trains and artillery on rail cars, etc. At the same time, since quite many maps come with both MAP and MAPX files, it is possible to switch to the MAPX format that will enable new features. For the sake of backward compatibility, the conversion tools can search first for the MAPX file and fallback to MAP file if needed.
Impact: conversion tools. -
Railroads.
Description: Referring to the item above, once we have information on railroads we can support properly railroad based units such as armoured trains (refer to #160). The next logical step would be even to enable railroad transports.
Impact: game engine.
-
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. -
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. As an example, some anti-air guns were capable of attacking only air units, whereas some anti-air guns, such as German Flak, were able to attack also ground targets. 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) allowing them to attack ground targets trough the corresponding unit specific attributes.
Impact: game engine, equipment files, conversion tools(?). -
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 (refer to the following discussion in #187). 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. -
Line-of-sight fire for anti-tank guns.
Description: Most of anti-tank guns would require clear line-of-sight fire for the ranged attack, which is not really the case with the current game model (refer to discussion in #116). In other words, you can initiate a ranged attack even if there is an obstacle between you and target, e.g. city, forest, mountain, etc. In the simplest form, we can just account for the terrain type and prohibit ranged attack for the anti-tank guns in case of certain terrains. There were ideas that also a unit type, if any, on the intermediate hex should be accounted for.
Impact: game engine.
Ruleset specific: yes. -
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 further controlled by PGII default or a new ruleset (#120).
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.
-
Unit movement sound
Description: At the moment the unit movement sound is determined by the unit movement type, which works fine in most cases. However, there are certain exceptions such as cavalry: its logical movement type is "leg", but the sound should be something close to cavalry, not infantry. Same problem exists for truck and horse transports: both of them are modelled as "wheeled", but the movement sound could be different. Each unit description has a special field indicating an alternative sound file, so it is possible to leverage that field to indicate an alternative movement sound when the default one does not apply.
Impact: equipment file, conversion tools, game engine. -
Unit dying sound.
Description: When a unit is destroyed the same "dying" sound is played. However, it could be different for different unit classes, e.g. sound of crashing airplane, sunk ship, etc. As in the enhancement above, the next logical step could be to assign, if needed, a unit specific dying sound.
Impact: game engine. -
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.