Summary
A while back I wrote a sample game called Battlefield One. This game was a turn-based war game that was built on SVG, javascript and C#. I have since converted this game into an MVC application (although it still uses the same code-behind techniques and I keep track of the game state with a session). I have also refactored much of the game to expand it, add unit tests, make the dimensions more flexible and I added tanks.
Review
OK, here’s how the game was designed:
- The game board is rendered in hex cells.
- Game units do not stack, only one unit can occupy a cell at a time
- Attack distance assumed to always be 1 for simplicity.
- No terrain effects.
- Capture all cities to win.
- Destroy all enemy units to win.
- Movement phase then attack phase.
- Areas of board not visited will be blacked out.
- Areas not visible to any unit will be dimmed and not display any enemy units.
I improved the AI some since the first game was written:
- Enemy units will attack the lowest defense numbered unit. This causes many enemy units to gang up on one nearby unit. Reducing the number of Allied units quicker and reducing the number of future Allied attacks.
- All enemy units will choose a city to move toward.
- There is a test flag in the GameBoard object that will allow you to turn off the masks so you can test the game. This mode will also draw red lines between the units and the destination they have chosen.
- If there are two allied units next to an enemy unit and one allied unit is on a city, the enemy unit will attack the unit on the city first.
Algorithms Used
The Die Roller object was improved. Instead of using one 6-sided die, I used a combination of three die rolls. The problem with one die is that the outcome is linear and the game is boring. As you use more dice, the outcome becomes more like the normal distribution of events and your attack and defense outcomes become more realistic. This was not much of a problem until I introduced tanks which could inflict a damage of 1 or 2. I wanted to have a damage of 1 occur more often than a damage of 2. Wolfram Alpha has an article on this here. My interest was in this chart (from the wolfram article), which explains it all visually:
I added unit tests to complex parts of the game. The original game was written without any unit tests. This was due to the fact that the original game was only a demonstration of what can be done and I only needed it for an example in a blog post. Now I intend to turn this into a project (aka hobby) that I will add features and blog about the features (like AI enhancements).
I added a unit list class. This is a list of units for the entire game and it allowed me to refactor some methods that were performed against the list of units. This object also has an AddUnit method to insert a unit into the list without referencing the list of units (called “Items”) directly.
I added a game board class to contain all the information and methods pertaining to the game board itself. Each cell now references a GameMap object containing variables for the terrain, mask and visibility settings. The previous version of this game contained three arrays to keep track of this information and I wanted a way to be able to change the game board size at game startup.
I changed the map background pieces into individual hex pictures so I could create a board of any size. The original game had a large painted background that was fixed in size and had 4 cities painted in place. By creating hex images of the green areas and a hex image of a city, I can just set the array at game start with the map size and city positions I want. Future versions can contain a mixture of different textures to make the game more interesting.
There was a bug involving the movement of playing pieces. The movement calculator would follow a straight line and then snap the unit to the closest board hex. The problem with this algorithm is that any piece traveling close to the edge of the map would stop because the closest hex position was off the map and the edge detector prevented the unit from going off the board. The new algorithm gathers a list of up to 6 surrounding hex squares. It will eliminate any hex that is off the board and any hex that is already occupied by another unit. The remaining list of hex positions is measured by distanced to the destination and the shortest one is chosen as the next hex to enter. This allows units to go around each other if necessary and the destination will always be reached unless it is totally blocked.
Playing the Game
You can go here to play the game on-line, or you can download the source code and experiment with the code yourself. To download the source code, go to https://github.com/fdecaire/BattleFieldOne and download the zip file (there’s a button in the lower right corner).
Update: My new hosting service is in Unix so the on-line game is no longer available. You can still download the source and play it on your local machine.