Some of this information is a Repost but intended to try and focus Firaxis on getting Armies fixed in a near term patch that gets released to the public.
The ARMY unit in CIV3 may be the most embarrassing set of examples of coding mistakes that still exist within the CIV3 Beta version that has been on the public market.
A number of features of the ARMY as a unit should be simply shifted in the coding to allow these features to be applied to other units, while there are some outright bugs in Armies that have to be fixed without further delay.
Fix ARMIES to eliminate the following bugs:
1) Allow the units in an army to heal damage at the same rate as units outside the army. Currently (as of 4/21/02) the units in the army heal slower than their peers and receive no healing benefit from barracks. It can take 6 or 7 turns for a badly damaged army to heal whereas the individual units of the same caliber will heal in one turn if located in a city with barracks.
2) Allow units in an army to exercise their zone of control powers such as taking pot shots at passing units. Currently (as of 4/21/02) an army 3 infantry does nothing as enemy units run past the army. The standard features of the Army indicate that it should confer a zone of control on all units, just like a fortress, but this feature does not work.
3) Fix the Armies defensive priority calculations to determine if the units in the army are intended for attack or defense purposes. Currently (as of 4/21/02) an army of 3 veteran Cavalry will be the priority defender even when stack with 3 veteran musket men. This appears to be due to the algorithm that calculates the defender power of the army as 4 hit points times 3 units times a D value of 3. The Army has to stand there and get pummeled until it loses at least 7 of its 12 hit points before a musket man with a stronger D value of 4 will take over and defend the stack.
4) Fix the unit attack and movement points calculations for armies to address the current bugs as described: “An army of 3 or 4 cavalry can only attack once in a turn. When faced by three spearmen defenders, an advancing army of cavalry will take three turns to reduce the defenders while a group of three separate cavalry units will almost always reduce the 3 spearmen defenders in a single turn.” Standard features indicate that armies should have blitz mode, so if the cavalry still have movement points they should be able to attack.
5) When disbanded in a city, Armies should yield the salvage shield points of the army AND the salvage shield points for the units contained in the army. Currently (as of 4/21/02) the units in the army just evaporate. Either yield the shields for the units in the army directly, or leave the disbanded units for us to disband individually but definately the units should not just vanish.
6) Increase the range of defensive visibility for Armies by 1 extra tile in radius to simulate the multi-unit capability of the army. Even when poised on a single square, the equivalent units to a cavalry army would have great visibility each turn due to scouting and reconsolidation. Movement of the individual units would cut a wider visibility swatch through terrain and then reconsolidate.
7) Give Armies the ability to pillage improvements in some appropriate scale to the units in the army.
8) Give an Army 1 extra defensive point to simulate at least the minimum power that a leader will have in military police or resistance and culture flipping suppression. Currently (as of 4/21/02) an army of 3 cavalry has no greater impact in these areas than just a group of three warriors. Since the army is a military unit with combat capabilities it should have some leadership and military police value. Answering the question “should it be easier to revolt against an army of powerful military units or against an equal number of similar but less well organized units.” This effect has been tested in V1.21 and has no unbalancing impact on combat strength.
Armies are a unique unit in that they are currently the only unit that is limited to the number of cities AND Armies are also unique in that they are the only unit that can be limited to being built in a city that has a specific small wonder or improvement already built.
FLASHING LIGHTBULB AND CLANGING GONG.
Why would someone spend the effort to write these coding constraints and then hardcode the restrictions into the general settings for the game that limits the use of the programming to only one specific unit???
Why not set these choices as options on the units dialog and then make Armies the only current choice where this dialog applies to the unit released in the standard Civ3 product?
Expanding the usefulness of this programming would only require adding a drop down menu to the units dialog page that would let the editor restrict building of units to a city where a specific wonder or improvement has been built. FLASHING GOLD STAR and CASH REGISTER DING.
You would also add a check box to engage a ratio restriction on the units that would let you restrict the number of units that can be maintained relative to the number of cities, or number of improvements, or number of another type of units. For simplicity this Ratio should be implemented per 100 items of the restricting prerequisite. ANOTHER FLASHING GOLD STAR and CASH REGISTER DING.
Implementing these army like features to be potentially applicable to any or all units will give you a set of tools that can be used by the game play balancing Nazis to help control balance without just simply making the units worthless, ineffective, technically and financially inaccessible.
Other simple unit features that should be implemented along the same philosophical approach should include:
• A unit support cost multiplier and a transport utilization factor. Both of these factors should be implemented based on a 100 factor being the 100 to 100 ratio.
• An “obsolete by upgrade” flag that allows units to be built and then upgraded without eliminating the ability to build the first unit as is the current default implementation.
• Units “upgrade cost multiplier” that allows the upgrade costs to be defined as more or less than the standard calculated shield to gold ratio of 100%. This feature will allow units to be built in some towns and cities and then “sent to school” in other cities for the upgrade without making it impossible for towns to build the lower units.
• A “targeted unit” selection box and factor that allows each unit to have a defined other unit where its major attack or defense strength is most effective. This last item will have significant impact on letting the game play balance advocates control specific results without creating universal destroyer or universally worthless units. Examples of implementing this set of choices would be perhaps an A10 Warthog against tanks or a machine gun against infantry. These selective choices would avoid the seemingly silly scenarios where a longbow man kills a tank or where galleys can sink privateers 60% of the time.
Note that most of these simple drop down box restrictions and other ratio restrictions already exist and have been tested in the game code for units and for improvements/wonders (witness Armies, Wall Street, Battlefield Medicine, and SDI). Just take the coding and tie it to the appropriate drop down boxes and ratio boxes on the units pages and improvement/wonder pages and the result will be 15 orders of magnitude closer to a rave reviewed product by the core group of users that will drive all the market expansion.
This open letter really is meant to focus on encouraging the philosophical shift to make the features of the game more accessible for simple adjustment because we need to recognize that the hundreds of creative minds in the game play and modification community will use features in new and creative ways that may go well beyond anything that the original creators can envision.
Also, this letter should emphasize a need for an approach to game play balancing that does not simply focus on rendering the included unit incapable of reasonable and cost effective functioning. There ought to be a winning game strategy that includes valid reasons for building and using each unit in the game instead of a philosophy that actively tries to prevent the units from being any advantage to the human player if the unit are built and utilized in an appropriate strategy.
The ARMY unit in CIV3 may be the most embarrassing set of examples of coding mistakes that still exist within the CIV3 Beta version that has been on the public market.
A number of features of the ARMY as a unit should be simply shifted in the coding to allow these features to be applied to other units, while there are some outright bugs in Armies that have to be fixed without further delay.
Fix ARMIES to eliminate the following bugs:
1) Allow the units in an army to heal damage at the same rate as units outside the army. Currently (as of 4/21/02) the units in the army heal slower than their peers and receive no healing benefit from barracks. It can take 6 or 7 turns for a badly damaged army to heal whereas the individual units of the same caliber will heal in one turn if located in a city with barracks.
2) Allow units in an army to exercise their zone of control powers such as taking pot shots at passing units. Currently (as of 4/21/02) an army 3 infantry does nothing as enemy units run past the army. The standard features of the Army indicate that it should confer a zone of control on all units, just like a fortress, but this feature does not work.
3) Fix the Armies defensive priority calculations to determine if the units in the army are intended for attack or defense purposes. Currently (as of 4/21/02) an army of 3 veteran Cavalry will be the priority defender even when stack with 3 veteran musket men. This appears to be due to the algorithm that calculates the defender power of the army as 4 hit points times 3 units times a D value of 3. The Army has to stand there and get pummeled until it loses at least 7 of its 12 hit points before a musket man with a stronger D value of 4 will take over and defend the stack.
4) Fix the unit attack and movement points calculations for armies to address the current bugs as described: “An army of 3 or 4 cavalry can only attack once in a turn. When faced by three spearmen defenders, an advancing army of cavalry will take three turns to reduce the defenders while a group of three separate cavalry units will almost always reduce the 3 spearmen defenders in a single turn.” Standard features indicate that armies should have blitz mode, so if the cavalry still have movement points they should be able to attack.
5) When disbanded in a city, Armies should yield the salvage shield points of the army AND the salvage shield points for the units contained in the army. Currently (as of 4/21/02) the units in the army just evaporate. Either yield the shields for the units in the army directly, or leave the disbanded units for us to disband individually but definately the units should not just vanish.
6) Increase the range of defensive visibility for Armies by 1 extra tile in radius to simulate the multi-unit capability of the army. Even when poised on a single square, the equivalent units to a cavalry army would have great visibility each turn due to scouting and reconsolidation. Movement of the individual units would cut a wider visibility swatch through terrain and then reconsolidate.
7) Give Armies the ability to pillage improvements in some appropriate scale to the units in the army.
8) Give an Army 1 extra defensive point to simulate at least the minimum power that a leader will have in military police or resistance and culture flipping suppression. Currently (as of 4/21/02) an army of 3 cavalry has no greater impact in these areas than just a group of three warriors. Since the army is a military unit with combat capabilities it should have some leadership and military police value. Answering the question “should it be easier to revolt against an army of powerful military units or against an equal number of similar but less well organized units.” This effect has been tested in V1.21 and has no unbalancing impact on combat strength.
Armies are a unique unit in that they are currently the only unit that is limited to the number of cities AND Armies are also unique in that they are the only unit that can be limited to being built in a city that has a specific small wonder or improvement already built.
FLASHING LIGHTBULB AND CLANGING GONG.
Why would someone spend the effort to write these coding constraints and then hardcode the restrictions into the general settings for the game that limits the use of the programming to only one specific unit???
Why not set these choices as options on the units dialog and then make Armies the only current choice where this dialog applies to the unit released in the standard Civ3 product?
Expanding the usefulness of this programming would only require adding a drop down menu to the units dialog page that would let the editor restrict building of units to a city where a specific wonder or improvement has been built. FLASHING GOLD STAR and CASH REGISTER DING.
You would also add a check box to engage a ratio restriction on the units that would let you restrict the number of units that can be maintained relative to the number of cities, or number of improvements, or number of another type of units. For simplicity this Ratio should be implemented per 100 items of the restricting prerequisite. ANOTHER FLASHING GOLD STAR and CASH REGISTER DING.
Implementing these army like features to be potentially applicable to any or all units will give you a set of tools that can be used by the game play balancing Nazis to help control balance without just simply making the units worthless, ineffective, technically and financially inaccessible.
Other simple unit features that should be implemented along the same philosophical approach should include:
• A unit support cost multiplier and a transport utilization factor. Both of these factors should be implemented based on a 100 factor being the 100 to 100 ratio.
• An “obsolete by upgrade” flag that allows units to be built and then upgraded without eliminating the ability to build the first unit as is the current default implementation.
• Units “upgrade cost multiplier” that allows the upgrade costs to be defined as more or less than the standard calculated shield to gold ratio of 100%. This feature will allow units to be built in some towns and cities and then “sent to school” in other cities for the upgrade without making it impossible for towns to build the lower units.
• A “targeted unit” selection box and factor that allows each unit to have a defined other unit where its major attack or defense strength is most effective. This last item will have significant impact on letting the game play balance advocates control specific results without creating universal destroyer or universally worthless units. Examples of implementing this set of choices would be perhaps an A10 Warthog against tanks or a machine gun against infantry. These selective choices would avoid the seemingly silly scenarios where a longbow man kills a tank or where galleys can sink privateers 60% of the time.
Note that most of these simple drop down box restrictions and other ratio restrictions already exist and have been tested in the game code for units and for improvements/wonders (witness Armies, Wall Street, Battlefield Medicine, and SDI). Just take the coding and tie it to the appropriate drop down boxes and ratio boxes on the units pages and improvement/wonder pages and the result will be 15 orders of magnitude closer to a rave reviewed product by the core group of users that will drive all the market expansion.
This open letter really is meant to focus on encouraging the philosophical shift to make the features of the game more accessible for simple adjustment because we need to recognize that the hundreds of creative minds in the game play and modification community will use features in new and creative ways that may go well beyond anything that the original creators can envision.
Also, this letter should emphasize a need for an approach to game play balancing that does not simply focus on rendering the included unit incapable of reasonable and cost effective functioning. There ought to be a winning game strategy that includes valid reasons for building and using each unit in the game instead of a philosophy that actively tries to prevent the units from being any advantage to the human player if the unit are built and utilized in an appropriate strategy.
Comment