This system would present the human player with events that would "instruct" the player what enemy units to add or remove from the paper map, what counters to place and remove for each unit, which commands should be executed, and so on.
However, as I got deeper into my design, I realized that there were a few significant obstacles that were not just cause for concern, but derailed any idea of a non-graphics interface.
In order for the game to have an artificial intelligence, the human player would have to input every human action taken on the physical map into the computer AI system. For example, if you moved your T-34 from hex A to hex B, you would have to enter each hex moved into the computer program, one at a time, to allow the AI to choose whether or not to perform an "Overwatch" command at a specific hex location in your move.
Also, any effects applied in the system software, such as suppression, damage, full cover, etc. would need to be placed on the map for each unit in the scenario for both the human player and the computer controlled player. Even with event messages such as:
"Place damage counter on unit X"
"Turn Fire counter face up for unit Y"
"Pivot unit X number of times clockwise"
...would be cumbersome and time consuming at best.
Under The Gun
I quickly realized that a typical computer war game interface would be a necessity. Playing against a computer opponent on a digital map, but using the rules and tables from the original board game would be an interesting idea if I could pull it off. For me, the most challenging issue would be implementing the user interface, the graphics and the events using Windows Forms. In c# (a programming language pronounced "see sharp"), you could sum up my knowledge of graphics programming as...
myExperience = null;
After a good amount of internet later, as well as a lot of trial and error, things came together fairly quickly. Paint an image on the screen... Update the screen when an update has occurred. Not too bad.
Everything is a Unit
I had already formed a good foundation of code that centered on vehicles only, primarily with Tanks. Tanks could fire, battle and move. However, I wanted to include all units, not just the hulking metal. This required a major re-design. The first thing I needed to do was design a class system for all units in the game. This is what I have to date...
My class system implemented in Panzer SOLO. |
Class Properties
Every counter in the game is a Unit, and every unit has a number of common properties such as...
- Name of unit
- Data card number
- Unit number
- Points
- Facing
- Grade etc.
Certain counters, such as vehicles, also have common properties like...
- Mode of traction (tracked, half-track, wheeled)
- Size
- Armour (front/back for basic rules)
- Armour (front, front side, rear side, rear, for both turret and hull)
- Track hit
- Status (no damage, damaged, knocked-out, or brewed-up), etc.
Other counters, such as leg units, have properties such as...
- Quickmarch
- Different modes of traction (Leg, Bicycle, Wheel, Motorcycle)
For example, since a vehicle is in fact a "Unit", a vehicle inherits all of the properties of a unit as well.
Not all Vehicles have weapons. My class structure differentiates between Combat Vehicles and Non-Combat Vehicles". Both are Units. Both are Vehicles. As such, they get all of the properties of "Vehicles" AND "Units". However, Non Combat Vehicles don't get weapons. That sorta makes sense.
Here is the class structure for the PzIII (data card G-1A):
PzIII ➠ Tank ➠ Combat Vehicle ➠ Vehicle ➠ Unit
Breaking this down...
The PzIII inherits all of the properties and functions of a Tank, Combat Vehicle, Vehicle, and Unit. So... we can say the following is true:
On the other hand, a Non Combat Vehicle like a Truck does not have weapons. A Truck is a Non Combat Vehicle, and as such, does not have the same functions as a Combat Vehicle.
However, both can move because both are Vehicles. Since the Vehicle class contains a "Move" function, both the Tank AND the Truck can Move...
Here is an example for a leg unit...
Class Functions
Each class has its own behaviors, or "functions". For example, a Combat Vehicle obviously has weapons, and therefore can be assigned "Fire", "Short-Halt, or "Overwatch" commands. Since a Tank is a Combat Vehicle, it inherits these functions and can perform these functions during the game.
Here is the class structure for the PzIII (data card G-1A):
PzIII ➠ Tank ➠ Combat Vehicle ➠ Vehicle ➠ Unit
Breaking this down...
- A PzIII is a Tank
- A PzIII is also a Combat Vehicle
- A PzIII is also a Vehicle
- A PzIII is also a Unit
The PzIII inherits all of the properties and functions of a Tank, Combat Vehicle, Vehicle, and Unit. So... we can say the following is true:
- Combat Vehicles can "Fire". The Tank can "Fire" because it is a Combat Vehicle.
- Vehicles have a function called "Move". The Tank can move because it is a Vehicle.
- The Tank can receive a "Track Hit" because it has the property "Tracks"
- Units have a property called "Location". The Tank has a "Location" because it is a Unit.
Truck ➠ Non Combat Vehicle ➠ Vehicle ➠ Unit
The system will not allow any Non Combat Vehicle to "Fire"...
Truck.Fire ❌
Truck.Fire ❌
Tank.Fire ✅
However, both can move because both are Vehicles. Since the Vehicle class contains a "Move" function, both the Tank AND the Truck can Move...
Tank.Move ✅
Truck.Move ✅
Here is an example for a leg unit...
SMG Squad ➠ Squad ➠ Leg Unit ➠ Unit
Different units fire, move, transport, and otherwise behave in different ways. A well designed class structure allows me to simply tell a unit to "Fire", "Move", "Short Halt" etc., and it behaves according to its own rules for each. I can tell a Halftrack to "Fire" and it will use it's own "Fire" function to carry out its fire command. Telling a Rifle Squad to fire uses its own fire command, because it fires differently than a Halftrack.
Halftrack.Fire();
Tank.ShortHalt();
Tank.ShortHalt();
RifleSquad.Fire();
Tank.Move();
SMGSquad.Move();
TowedUnit.Move();
TowedUnit.Move();
You get the idea. For us programmers, this is basic stuff. Although the code can be somewhat complicated, the "coding" is not the challenge. The "design" is the thing! A good design goes a long way.
|
|
Anyway, to make a long story short, my class system is working well. Although, it's not quite finished. You'll notice that off-map artillery is not modeled yet. Neither are "Sections".
We'll get there!
2 comments:
Amazing job so far, thanks for the updates.
Thanks for the encouragement. I'm looking forward to releasing another update soon.
Post a Comment