I am currently working on rewriting the old Nintendo Entertainment System (NES) game Conflict in Java for Windows and OS X with various changes and improvements over the original. This page will give you information on the game and it's development timeline.
Conflict source code will soon be available to select individuals. Once the Butler server is back up and running, the main Conflict code will be hosted there using CVS.
The Original Game
Conflict was originally produced by Victokai and released in 1989 for the NES. The basic game design lays out a terrain map in a hexagon pattern which includes various forms of terrain, along with factories, cities, and airports. Each player begins with two factories from which she can build new units, a flag tank, and zero or more other starting units. Only one unit may occupy a hexagon terrain tile. The different terrain types offer different advantages and disadvantages to occupying units. The game ends when one player has destroyed the flag tank of all opposing players.
The units a player can build will depends on that players current FP. (FP stands for Fame Points. It is the term used in the original game, although as to what exactly it means, I will leave that up to your own speculation.) Any city or airport occupied by a teams unit for the period of 1 turn will gain the player additional FP. A player also gains FP from her factories, and from destroying enemy units. A player loses FP when one of her own units is destroyed. The FP gained or lost depends on the unit. In addition to attacking enemy units, players can also attack and destory enemy factories. Factories cannot be rebuilt.
Deviations From The Original
My rewrite of Conflict will maintain the essense of the original game, yet will have quite a few changes due to design issues and the plan to incorporate numerous enhancements. Changes from the original include (subject to change):
Copyright and Trademark Issues:
My code is completely written from scratch, with the exception of several components for playing music, parsing XML, or performing other specific tasks. All of those components are licensed under some form of GPL-style license, and credit will be given to the authors of those pieces in several locations.
I am satisfied that my game will be sufficiently different from the original such that the only major copyright or trademark issue will be the name, Conflict, along with several images I am using in modified form. For the name issue, I considered renaming it to a rather cryptic C:TNG. This comes from a brief consideration of naming the game Conflict: The Next Generation out of love for Star Trek. In the end, however, I expect this game will slip under the legal radar due to low circulation. I will therefore leave things as they are for now. It won't be too difficult to change them later if necessary.
This section details noteworthy updates to the core game code, which affects both the game and the map editor.
Why no mp3 support? In general, not many mp3 files will be appropriate for the game. Most mp3 files are songs with vocals. In game music is meant to be a background enhancement, and should be limited to simple instrumental scores. Nevertheless, I looked into options for adding mp3 support, but from my design perspective, all of the available options would add excessive bulk to the game. Since Conflict is being developed as a windowed game, anyone interested in listening to mp3 music while in game can do so using an mp3 player.
Current Version: 0.7
|Name||The name of the weapon.|
|Ground||Whether or not the weapon can be used against ground units.|
|Air||Whether or not the weapon can be used against air units.|
|Power||The amount maximum amount of damage the weapon can inflict.|
|Accuracy||The accuracy of the weapon as a percentage, from 0 to 100. This is the percent change that a single round of ammo will hit the target.|
|Max Ammo||The maximum ammo the weapon can hold.|
|Burst Rate||The amount of ammo used in a single attack.|
|Reload Rate||The amount of ammo that can be reloaded per turn if the unit in a location where it can resupply. In the classic theme, air units resupply at airports, ground units resupply at cities, and any unit can resupply when adjacent to a supply truck.|
|Name||The name of the defense.|
|Defense Bonus (Simple)||A percentage, from 0 to 100, that a Simple weapon will be reduced in effectiveness. A Simple weapon is any weapon that has no guidance system, such as guns and dumb bombs.|
|Defense Bonus (Guided)||A percentage, from 0 to 100, that a Guided weapon will be reduced in effectiveness. A Guided weapon is any weapon that uses a guidance system, such as anti-air or anti-tank rocket.|
|Variance||A percentage, typically from 0 to 100, that the defense bonus can vary by chance.|
|Offense Modifier||This is a percentage, from -50 to 50, that alters the chance that the unit will be able to retaliate with an offensive attack. In the XML, this is referred to as Offensive Balance, and ranges from 0 to 100, with 50 being no modification. Subtracting 50 from the Offensive Balance yeilds the Offense Modifier. This distinction was made to avoid the use of dashes for negative numbers in the XML, as some XML parses can be confused by this.|
|Supply||Analogous to ammo for a weapon. Unlike ammo, however, supply can be unlimited for many defenses.|
Note: This section is subject to change as the game develops.
Scenario: Unit A attacks Unit B with a weapon that is 90% accurate, with a burst rate of 20, a damage of 40, and a variance of 25%. Unit A currently has a 5% experience bonus, while Unit B currently has a 20% experience bonus. Unit B is in a forested terrain which has a 10% defense bonus. Unit B executes a defensive tactic with a 20% effectiveness and 50% variance.
The damage done is determined by starting with the weapon accuracy, and adjusting that accuracy multiple times to account for all conditions. The final accuracy is then applied to each round of ammo fired in a burst. Defensive adjustments are performed first, followed by offensive adjustments.
It is been deemed desireable that highly accurate weapons remain highly accurate. To ensure this is the case, all defensive adjustments will be subject to a reduction equal to (weapon accuracy / 100)^15 (this equation has roughly the distribution we want). In the scenario, this equates to 0.2, or 20%. Therefore, a defense with a 10% effectiveness would be reduced by 20% of that 10%, resulting in an 8% effectiveness. This computation has an exponential effect, having little effect on weapons with less than 80% effectivness, and a profound effect on weapons with greater than 90% effectiveness.
|90.0%||Default Weapon Accuracy|
|Apply variance to defensive tactic (assume variance comes up 0, no change)|
|Reduce by defensive tactic (16%, adjusted down from 20%)|
|Reduce by defense bonus of terrain (8%, adjusted down from 10%)|
|Reduce by experience of defensive unit (16%, adjusted down from 20%)|
|Increase by experience of offensive unit (5%)|
|61.3%||Final Adjusted Weapon Accuracy|
For each ammo round fired, apply a 61.3% chance of it hitting the target. In this case, there are 20 rounds fired. Assume 12 rounds hit. Each round can inflict 2 damage (40 damage / 20 rounds = 2 damage per round). This means a total of 24 damage. This amount is then ajusted by the final weapon variance factor of +/- 25%. Assume this computes to 10%, resulting in an additional 2 damage. After this last computation, we have a total of 26 damage inflicted. The health of Unit B is reduced by 26.
You can see from the computational process that weapons with a high burst rate, such as guns, will almost always result in a hit for at least partial damage. Meanwhile, single burst weapons such as missles and tank guns will be hit or miss.
Current Version: N/A -- now part of Conflict 0.7
From here forward, the Map Editor will be considered part of Conflict. Thus, improvements over Map Editor version 1.0 are now considered part of Conflict version 0.7.
Changes of Conflict 0.7 from Map Editor 1.0 include:
Changes of Map Editor 1.0 from Map Editor 0.9 include:
Changes of Map Editor 0.9 from Map Editor 0.9 (beta) include:
|Last Updated 8/3/2005 by Scott Arnold|