GMT Panzer SOLO Project

Panzer SOLO: Latest Development Update

2020-12-29T11:25:00.008-05:00

Today we'll cover a number of areas that I've been focusing on lately, including suppression recovery, ammunition availability, ammunition limits, the new battle map, a more useful spotted units area, the short halt command, as well as the implementation of the solo rule for identifying the most dangerous enemy unit.

Suppression Recovery

Let's start thing off with my implementation of "Suppression Recovery". When each turn has ended, any units that have "Suppression Off" counters will attempt to "Recover". The suppression recovery form appears for each unit and indicates any modifiers (such as "Command other than No Command"). in the screen below, we see that the Soviet ("Green grade") unit did not roll in the recovery range (highlighted in orange).

Suppression recovery failed. The unit will remain suppressed for the next turn.

Ammunition Availability

Ammunition availability dates (like HVAP, APCR) can only be used when they are available according to "Notes" section on the unit's data card (bottom of each card). Note the scenario date (July 1943) at the top middle in the screenshot below. The T-34 M44 unit card is displayed, but notice it's HVAP ammunition type is not listed. HVAP for this unit is not available until January 1944.

It's July 1943. HVAP is not available for the Soviet Tank until January '44.

Notice in the next screen (below), after changing the scenario date to January 1944 and reloading the scenario, HVAP is now listed in the unit's ammo listings on the unit card...

This scenario now takes place in November 1944, so HVAP is available for the T-34.

Ammunition Limits

Ammo Limits presented a bit of a logical challenge the way my code works, but it's done! You'll notice in the screen below that the T-34 has ammo limits (A:A5) indicated for its 76.2 mm L/43 main weapon. Normally, the T-34 has HVAP ammunition which is subject to ammunition limits. However it is too early in the war for HVAP, therefore no ammo limits apply in this case. This is indicated in the "Battle Box" window in the area called "Ammunition Limits". If the T-34 ammo limits indicated A:3, it's AP (armour piercing) ammunition would have been subject to ammo limits.

No ammunition limits apply in this case.

In the next screen, we have a different scenario that takes place later in the war, making HVAP available to the T-34. The Soviet player has selected the HVAP ammunition against the German Panzer IV. Since the HVAP ammo is subject to ammunition limits (indicated by the "A" beside the HVAP ammo listing on the unit data card), our first roll for this FIRE command is to roll to check if ammo limits will apply for this shot. Since the T-34 has an indicated ammo limit of 3 for any "A" type ammunition (A:A3, indicated in the main weapon data on the data card), we need to roll 3 or less to avoid ammunition limits. The Soviet player rolls a 4, so ammo limits apply and will modify the upcoming "To Hit" number...

Unfortunately ammo limits apply to the Soviet player's shot.

You can see in the screen below, that the ammunition limits modifier is highlighted in the "AP Hit Modifiers" table below (Ammo Limit, Heat Haze). This modifier represents a shift of 3 rows down (not good) on the "AP Hit" table. Instead of moving only 3 rows down on the AP Hit table because of the Unit Company's "Green" grade (highlighted in orange), we actually end up moving 6 rows down. 3 rows down for the green unit grade, but then an additional 3 more rows down because of ammo limits. The result is a "To Hit" number of 20 (20% chance of hitting the target), instead of 35 (35% chance of hitting the target)...

Applied ammo limits affect this shot reducing our chances of hitting the target by 15%.

Battle Map

Moving on, I have implemented a "Battle Map" (screen below) that opens when a unit executes a FIRE command. The battle map focuses on the firing unit and the target unit and displays them in the window. This comes in useful when the 2 units aren't necessarily both viewable at the same time on the main map...

The "Battle Map" gives a better visual of the shot's firing and target units on the map.

In other developments, I have created a new "Spotted Unit" area where the player can view many more details of units that have been spotted by the player's selected unit. You'll notice in the screen below that the selected unit's data card for the Panzer III is displayed at the bottom left. To the right of the data card is the "Spotted Units Area", listing all units spotted by the Panzer III, including the top down graphic and relative size of the unit. Included in the details for each row are the range to each spot, the aspect angle relative to the selected unit, and any counters applied to each unit. Each column in the table can be sorted as well...

Note the counters (Damaged, Bail, Track, etc) displayed for each spot in the Spotted Units Area.

Short Halt

I have also added the logic for the SHORT HALT command. It was easy! Because I had already wrote the code for FIRE and MOVE commands, the logic for adding a SHORT HALT command was pretty basic... just add a FIRE and a MOVE command to the unit :)

Most Dangerous Enemy Unit

One of the more exciting blocks of code I've written so far, was the solitaire "Most Dangerous Enemy Unit" function. This function assesses each spotted enemy unit for a selected unit and calculates the how "dangerous" the enemy unit is to the selected unit. It takes into account a number of factors, including aspect angle, range, combat modifiers, ammunition penetration, defensive armour, chance of elimination, N-effect (for general purpose ammunition) and more!

Code, code, code. And more code.

I'll definitely be posting a video of most of the items covered today. Check back soon and until next time. I hope you enjoyed this update.

Firing Attached AP Ammunition - Leg Unit to Combat Vehicle

2020-12-02T15:00:00.015-05:00

Today we'll look at a small test of leg unit vs combat vehicle action for the purposes of demonstrating an AP (armour piercing) attached crew served weapon attack. We'll assign a fire command to the leg unit and fire the M1 Bazooka on an unsuspecting Panzer IVG.

The situation: A lone Soviet elite Rifle Squad carrying a crew served M1 Bazooka attached weapon sits above the clearing to the south, protected by light woods. A single elite crewed Panzer IVG is spotted making it's way to the end south of the village of Stravrhevoy. The Soviet squad waits patiently for the German tank to creep into range of their Bazooka's AP ammunition.

Our first catch of the day.

We can see the solid green spot line from the Soviet squad to the German Panzer. This not only indicates that we have line of sight (LOS), but that the squad is also able to fire with at least one of its weapons. Looking at the Soviet data card, we can see that this unit has 2 weapons. Its intrinsic GP (general purpose) Rifle squad weapon, as well as a crew served attached AP M1 Bazooka.

The Rifle squad has both a GP and an AP weapon.

The German unit is at range 3. At this range the Soviet Rifle squad's intrinsic GP weapon has a factor of "6". However, its M1 Bazooka at range 3 has a factor of 20. Much better :)

Each ammunition listed can be either enabled or disabled (greyed out) depending on whether it can be used against any of the unit's spotted targets. If an ammunition is out of range, or cannot be used against a particular enemy unit, it cannot be used in battle. In this specific case, both ammunitions listed are available to be used against the German unit.

Here is the data card for the German tank. The "Defensive Information" area displays the possible data points (highlighted in orange) relevant to this attack...

In this attack, the Soviet squad has a "Front Side" aspect angle on its target.

We use the Defensive Information "Front/Side" data points due to the target's Front/Side aspect angle. We cross reference this with the type of shot (Level, Rise, or Fall), which in this case is a "Falling" shot because of the higher elevation of the Soviet squad. The AP defensive data along the "Fall" row relevant to this attack includes armour values for:

"TF" (turret front)

"TS" (turret side)

"HF" (hull front)

"HS" (hull side)

"DK" (deck)

The Soviet unit is given a "Fire" command. The computer controlled German Panzer unit decides on a "Move" command. For the purposes of this test, we purposefully give the computer controlled German unit a "Move" command. The command is face down (below), but we do in fact know it is a Move command. When playing against the AI, we will not know the command assigned to any of the enemy units.

After the "Command" phase.

Once we have locked our target, the Battle Box appears with the battle details loaded for AP combat resolution...

The Battle Box. Ready for armour piercing combat resolution.

The right side of the Battle Box contains our direct fire data and process for determining the result of the attack. To start the process off, we open the AP Hit form by clicking the first "Roll" button...

The AP combat modifiers are listed on the left (below). Any modifiers highlighted in orange are added up and push the AP Hit row up or down. In our case, we have 2 combat modifiers that apply. "Target Moving" at a value of "-2", and "Shooter Grade" at a value of "5". Adding these together we get a total of "3". Since the German unit is at "E" (extended) range for the Soviet's Bazooka ammunition, we use the "E" column of the AP Hit table. Using our modifier total of "3", we travel 3 rows up from the "0" row (the grey row). This leaves us with the highlighted AP Hit value of "13". We must roll a 13 or less to hit the German Panzer IVG...

We rolled well. It's a hit. We had a 13% chance.

Sometimes we need to determine the number of hits. To do so, we would open the "# of Hits" form. However, the Soviet squad has an "N" (normal) "ROF" (rate of fire), and therefore we do not utilize this table in this specific battle. ROF is listed for for each ammunition on the leg unit's data card. This is what the "AP Number of Hits" table looks like...

This table only applies to ammunition with Q (quick), F (fast), or R (rapid) ROF (rate of fire).

Next up in the process is the "AP Hit Location" determination...

We roll a single D10 die to determine the hit location on the enemy tank.

Since the target aspect angle is "Front/Side", we use the "Front/Side" row (highlighted in yellow). We've rolled a "4", which indicates that we have hit the "TS" or "Turret Side" of the Panzer unit.

We've hit the tank on the side of the turret. We now determine whether or not the shot has penetrated. This is automatically calculated for us using a few pieces of data from the data card of each unit...

At the bottom left of the screen above, we take the "P" (penetration) value of "20" from extended range of the Soviet M1 Bazooka row. We compare it to the target's armour rating listed in the Panzer's "Defensive Information" under the "TS" (turret side) column. In the "Fall" row, the cross referenced value is "7". The Bazooka's "20" beats the turret side armour of "7". The shot has penetrated.

Now we determine the damage the shot made to the Panzer. Looking at the Soviet M1 Bazooka row, we see the "AP Damage" values for "ND" (no damage), "DM" (damage), "KO" (knocked out), and "BU" (brew up). We roll a single D10 and see where we land...

Great result! Bazookas rule.

We roll a "0" (which is a 10). This results in a Brew Up and the unit is destroyed...

The Soviet leg unit is marked with a "Spot Fire" counter.

Our "Fire" command counter is disabled. The Soviet unit can now be spotted from much farther away, since it has been marked with a "Spot Fire" counter. By firing, they have exposed themselves and possibly compromised their location. Who knows what the enemy will throw at us next :)

I hope you are enjoying my work and I look forward to any comments and/or suggestions.

Firing General Purpose Ammunition - Leg Unit to Leg Unit

2020-12-02T01:11:00.002-05:00

I've been working on assigning targets and firing AP (armour piercing) and GP (general purpose) fire ammunition types. There are a lot of details to consider and the code is getting much more complicated. Let's setup a simple scenario for testing purposes.

We'll consider a single Soviet leg unit and a single German leg unit for our test. Here we have an elite Soviet Rifle Squad. We've kept it simple and not included any attached weapons for now. The only weapon that this unit has is it's intrinsic GP (General Purpose) weapon, listed on it's unit card below.

The Soviet S-8A Rifle Squad just outside the village of Stravrhevoy.

Let's have this unit perform its initial "Spotting" phase. As you can see below, The Soviet unit has spotted a veteran German Rifle unit approaching from the east. The range to the German unit is 5 hexes, or "M" (medium) range.

A German Rifle Squad is spotted in the clear.

You can easily identify which gunnery range factor applies in this case, as it is highlighted in orange in the Soviet unit card. With its intrinsic weapon at medium range (4, 5 or 6 hexes in away), the Soviet unit has a GP factor of 5.

Gunnery Range and GP factors.

If the German unit was 3 hexes away, it would be within "S" (short range) and have a GP factor of "6". If it were 10 hexes away, it would be at "E" (extended) range. Obviously (in most cases), the closer the enemy unit is, the higher the GP factor. High GP factors serve us well when it comes to combat.

We see that the German unit's "Defensive Information" highlights the "GPD" (general purpose defense) and indicates a value of "2S". If this unit were in "Heavy Cover", it would receive a GPD of "8S". The higher the GPD, the better off the unit will be defensively when it comes to GP (general purpose) combat.

The German Rifle Squad is in the open with no cover.

Now we'll assign a "Fire" command during the "Command" phase, then select the German Squad as a target in the "Direct Fire" phase. The Soviet unit is designated a Fire command counter and the spot line to the German unit indicates that the German Squad is the target.

The Soviet Squad is ready to fire.

Now it's time for combat. Once our target has been locked in, we can execute our Fire command...

The "Battle Box".

The "Battle Box" is where our Fire command combat begins and ends. On the left, we have our shooter. On the right, our target. The "GP Direct Fire Data" area (far right) displays the necessary initial information we need to calculate our combat results. In this case, we are executing a GP Fire command against a leg unit and therefore need the shooter's GP Factor, as well as the target's GP Defense Factor...

Getting there!

We can also identify the possible outcomes by looking at the "Result Ranges" for our GP Combat dice roll...

What will we roll?

These ranges are determined by using GP Factors, in this case "5" and "2" and cross referencing them on the "GP Combat Results" table...

The GP Combat results table.

Looking across the top of the large table above, we locate the shooter's GP Factor of "5". We cross reference this with the target's GP defense factor of "2" down the left of the same table. There are 2 rows for each GP Defense Factor. The first is the "N" (no effect) row, which in this case is 39. The second row is the "S" (suppression) row and in this case is 68.

If we roll 39 or less, the combat result is "N" (No Effect).

If we roll between 40 and 68, the combat result is "S" (Suppression).

If we roll 69 or more, the combat result is (Effective).

Of course, it's not as simple as this. We haven't taken into effect any of the GP Combat Modifiers listed in the table...

GP Modifiers affect your roll.

GP modifiers in effect are highlighted in orange and are cumulative. We can see that in this case our shooter is an elite unit and gets a bonus of "10" added to our GP Combat roll. Modifiers can also reduce our roll, so we need to make sound tactical decisions to maximize our outcomes. The GP combat modifier total is calculated and displayed under the dice roll area...

Let's roll.

Clicking the "Roll" button, we get a value of "70"...

An effective result after our modified roll. That's what we're looking for.

Our roll is modified by a +10. Our modified roll is therefore 80. If we look at the orange highlighted values, we see that we needed a 69 or greater to achieve an effective result.

After closing the window, our Battle Box is updated with the results...

Reduced to a Half-Squad.

The damage to the unit is indicated in the "GP Combat Result" area. Because of the effective result, the German Rifle Squad is reduced to a Half-Squad. The unit's counter is updated to reflect this fact and now displays the Half-Squad image. The "Bailout" area does not apply in this case and is disabled.

Closing the Battle Box, we can see that the German Unit's data card reflects the fact that this unit is no a Half-Squad, and displays the appropriate Half-Squad values for it's weapon. Note the new "Gunnery Ranges"...

The gunnery range values are reduced for Half-Squads.

Next time we'll take a look at a leg unit vs a combat vehicle. Maybe we'll add the Bazooka to give the leg unit a fighting chance.

Thanks for visiting and leave any comments below :)

Command Phase and New Features Video

2020-11-11T08:32:00.001-05:00

I've put together a short video of the new features and command phase implementation discussed in the previous blog post. Enjoy!

Panzer SOLO Digital Wargame Progress Update

2020-11-06T23:55:00.012-05:00

It's been a while, but the work (and progress) continues. There are a number of items to cover, so let's get to it!

If you any questions, just let me know in the comments below.

When a unit has spotted another unit, a "Spotting Line" is drawn from the selected unit to the spotted unit. If the unit is able to fire on the spotted unit with at least one of its weapons, the spotting line is a solid line. If the unit is not able to fire on the spotted unit with any of its
weapons, the spotting line is a dashed line.

The selected unit at the top right has spotted 2 units. However, it can only fire at the unit with the solid green spotting line. The other spotted unit with the dashed spotting line cannot be fired at.

Front and rear firing arcs have been implemented for turretless vehicles. For example, the Soviet SU-100 M44 (Data Card S-4B) has a turret turn rate of zero (TT: 0), which indicates that it is turretless and has a front firing arc of only 60 degrees. In order to assign a fire command to this unit during the command phase, it must spot a target within a 60 degree arc to the front of the unit. If the unit wants to fire on a unit outside of this arc, the unit itself must turn (in the movement phase) in order to bring its weapon to bear.

The selected unit has a front firing arc of 60 degrees. The dashed spotting line to the German Panzer III indicates that the German unit has been spotted, but that it is not in the Soviet unit's firing arc.

Ammo types are greyed out on the unit's data card when they cannot be used on a particular enemy unit.

The "AP" and "GP" ammo types for the Soviet SU-100 are greyed out because they cannot be used on the highlighted spotted German Panzer III (in yellow).
Gunnery ranges on the unit's data card are highlighted (in light blue) for each ammo type depending on which spotted unit is selected. This makes it easier for the player to look up the range and penetration values.

The Rifle Squad can use its intrinsic weapon at gunnery range "P" (point blank range) against the currently selected German Panzer III. The penetration value at this range is 8 (highlighted in blue).

There is a "Spotted Units" area that displays the selected spotted unit. Players can click on the unit to display the data card for the unit in a popup window. This window will display highlighted offensive and defensive values for this spotted unit against the players' selected unit.

The Soviet Rifle squad spots 2 units. The currently selected spotted unit is displayed in the spotted unit detail area at the bottom middle of the screenshot. The player can click in this area to open a popup window with the spotted unit's data card (bottom right).

The command phase has been implemented. Players can select a unit and right-click on it to assign any of the applicable commands from a context menu. The context menu disables commands that are not eligible to be assigned. For example, a unit that has a track hit cannot be assigned a "Move" command. The "Move" command will be disabled in the menu. If a unit cannot fire at a spotted unit, the "Fire" and "Short-Halt" commands will be disabled.

Because this selected Soviet unit can be moved or can fire, all command options are available.

I rotated the SU-100 so that its firing arc no longer applies to any enemy units. Since it can't fire at anything, the "Fire" and "Short-Halt" commands are disabled in the context menu.

Commands can be shared between units from the same company by one of two ways. All commands (with the exception of the "No Command" counter) display a number on the counter. Shared commands will have the same number on the counters. The player can select a unit that has a command assigned to it and drag-and-drop the command to another eligible unit. Eligible units need to be from the same "Company" and also need to be in "Command Range" (0, 1, or 2 hexes) of the selected unit. Command Range is automatically determined based on the "Grade" of the Company that the units belong to.

Players can also share commands by right clicking on the selected unit and selecting "Share Command".

Assigning shared commands with units in the same hex or within command range. The player simply clicks the images to share the same "Fire" command as the selected unit. Each fire counter above has the number 1 assigned to it, indicating that these are shared fire commands.

That's all for now :) I'll post a video of these features shortly. Leave any comments below.

This Soviet T34/85 is sizing up a German Tiger II. Note the highlighted gunnery ranges highlighted in the Soviet data card and the rising shot defensive data highlighted for the Tiger.

Time to Refactor

2020-08-31T12:42:00.009-04:00

I've been spending most of my time rewriting major portions of the code to accommodate weapon systems and their ammunition. Each unit now has weapons that can have multiple ammunition types. Weapons can be a "main" weapon. Although each unit has one or more main weapons, most units only have one.

Weapon systems consist of:

Guns

AP Direct
AP Indirect
GP Direct
GP Indirect

MMG
Leg Unit Intrinsic Weapons (Rifle, Infantry, SMG)
Attached Crew Served Weapons for leg units:

Attached AP Direct (i.e Panzerfaust, M1 Bazooka, RPzB 43/54)
Attached GP Direct (i.e BM41, GrW 36)
Attached GP Indirect (i.e German GrW 34 Mortar)

I have added a number of other items to each unit:

A unit's main weapon data is now displayed along the top of each card.
A number of combat vehicle units have coaxial MGs which are indicated by the boxed number in the unit's GP ammunition under "Point Blank" range.
Leg unit cards only display the relevant leg unit data. If the unit is a Rifle Squad, the SMG, Section and Infantry data is hidden.
Leg units now only display gunnery range data for either full squad or for half squad units. If the unit is a half-squad, only the half-squad data is shown. This makes data intel gathering simpler and easier to decipher.
If a leg unit has attached crew served weapons assigned to them, they are readily available for reference on the same leg unit card.
Leg units now have their ammunition limits
GP Effectiveness is now displayed for each ammunition type.
Unit grade is displayed at the top of each unit card.
Points values for each unit is displayed at the top right of the unit card. Leg units with attached crew served weapons display the total point value of the unit and all attached weapons.
Unit cards display formation symbol.
Notes and basic game armour are displayed the bottom left.

I still need to implement leg unit "Sections". This shouldn't be too difficult, since all of the "leg work" has already been done.

GMT Panzer SOLO AP Fire Command Process

2020-06-11T09:15:00.000-04:00

Fire commands assigned.

I've been working on the user interface for performing armour piercing fire commands, which has been a bit of a challenge. It's not difficult to code, but there is a lot going on under the hood. Testing has been quite a challenge and takes significant time to verify numerous possible outcomes.

Anyway, I think I've got a good foundation. There are still a number of items to implement, such as the "AP Number of Hits" and "AP Penetration" tables. I'll be tackling those right away.

In this short video that demonstrates what I have so far for AP direct fire, we have two soviet units, an SU-85 M43 and a T-34/85 M44. Both units are in the woods and have spotted 2 German units out in the open and headed north.

The Soviet units are both assigned individual "Fire" commands. Both have targeted the German Panther. Let's find out what happens. Make sure to turn subtitles on...

Unit Weapon Range and Hexes in Line of Sight

2020-05-01T16:32:00.002-04:00

This is pretty cool :) I've added a mechanism to display a unit's range for it's longest weapon. You can select the range you would like to display, and the map will show you all of the hexes that are within that range and line of sight (LOS) for that unit. It takes a lot of the "guesswork" out of play and provides a lot of invaluable info for the player.

Let's take the German Panther out for a stroll...

If we focus on the "Offensive Information" area of the Panther's data card, you'll notice the 3 rows of ammunition...

The Panther has 3 different types of ammunition to choose from when attacking an enemy. Range factors for each ammo are denoted by a single letter. At the top of the image above are the letters:

P = Point Blank Range
S = Short Range
M = Medium Range
L = Long Range
E = Extended Range

Each ammunition type has both a Range (R) and a Penetration (P) value for each of the 5 range factors. For example, the first row is "AP", or Armour Piercing. We can locate the point blank range factor for the AP weapon by looking under the column "P". We see that at point blank range, the Panther has a range (R) of 4 hexes and a penetration (P) value of 32.

For the same AP ammunition, the Panther's short range (S) is 8 hexes. At medium range, the Panther can fire it's AP ammo 14 hexes. The maximum range the Panther can fire it's AP ammo is at extended range, which is a range of 24 hexes.

The 3rd row represents the unit's GP, or General Purpose ammunition. At point blank range, the ammo can fire up to 6 hexes. GP fire can reach 38 hexes at extended (E) range.

The player can select a range factor (P, S, M, L or E) and display all of the hexes on the map that are at that range and in line of sight...

The "P" button (at top middle) is selected. This button highlights all hexes that are in
line of sight and at a point blank range of 6 of the German Panther's GP ammunition.

Note the "E" button is selected at the top of the screen. The Panther can obviously see a lot more hexes at extended (E) range. Extended range for this unit's longest ammunition, which is GP, is 38 hexes. Since the map is 38 hexes wide, it has the ability to see clear across the board from one end to the other, as long as it has line of sight.

The screen above has hexes highlighted in green for the unit's extended (E) range of it's GP ammunition. Establishing which hexes can be seen on the table top version of the game would be a long process.

Here's a video demonstrating this feature. Turn on your subtitles! I hope you enjoy it :) Don't forget to subscribe!

Panzer SOLO Line of Sight Tool

2020-04-20T16:22:00.001-04:00

Just a short note today...

I've added a "Line of Sight" (LOS) tool that allows the player to view whether or not there is line of sight between two hexes. Just select a hex, click the LOS button, then roll the cursor over any hex on the map. If you have line of sight to the hex under the cursor, the hex turns green. Red if there is no line of sight.

I think I'm going to expand the functionality of the tool to include the reason why no line of sight is possible. I'll also add an area to indicate range to the selected hex. The more info the better... right?

You can see the LOS Tool in action in a video I posted...

Heat Maps for Hot Zones

2020-04-18T16:44:00.003-04:00

I've been working on developing "Heat Maps" for the AI opponent to better manage situational awareness. The areas in "red" indicate the extended range of a particular unit and the hexes it can target with it's longest range direct fire ammunition.

I'll work this function into the AI system for determining these hot zones. The computer will calculate overlapping areas of "hotness" and be able to better determine risk through identified areas of safety, danger and retreat. Here are a couple of sample shots of a single unit on the board...

A Soviet T-34/76 M43 on the ledge scouring the terrain for German presence.
It can fire its GP weapon at a range of 27 hexes.

The T-34 in the above screen is sitting on a hill. The longest range that the Soviet unit can fire at is 27 hexes. Its general purpose (GP) weapon has a penetration level of 2 at that range...

At extended range (27 hexes), the T-34 can fire its GP weapon.

The heat map will calculate the line of sight to each hex on the map, up to and including the unit's maximum range of it's weapon it can fire the farthest. The T-34 has multiple weapons, but it's GP weapon can fire the farthest.

I am able to drag and drop a unit to any location on the map and view exactly which hexes are within line of sight of its maximum ammunition range. There are a lot of surprises that pop up here and there, revealing locations that otherwise might never be discovered using the tabletop map. It's actually a great way to identify any problems with my line of sight algorithm.

The T-34 moves into Kurvha. Notice that line of sight passes through the streets of the town.

Eventually I'll have multiple units display their lines of sight. Any overlapping areas will be displayed as a darker shade of red (or other colour). Each hex will receive a "score", indicating how many times it has been overlapped. If a hex has a high overlap score, it will indicate a very high area of danger for the enemy. The AI will try and avoid these areas unless absolutely necessary.

There are some edge cases that I still need to work out. Terrain such a gullies, hedgerows and streams aren't quite ready yet, as there are a few anomalies. Once I have these figured out, I'll post a demo video :)

That's all for now. Until next time!

GMT Panzer SOLO Class Structure

2020-04-01T13:29:00.000-04:00

Originally, I began my GMT Panzer SOLO project as a non-graphics AI system that would be used in conjunction with the paper map, counters and data cards.

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.

German Tiger II supported by a German SPW 251/2 and Infantry Squad.

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.

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.

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.

Truck ➠ Non Combat Vehicle ➠ Vehicle ➠ Unit

The system will not allow any Non Combat Vehicle to "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();

RifleSquad.Fire();

Tank.Move();

SMGSquad.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.

Scenario design.

Half-track data.

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!

Bresenham and Line of Sight in Panzer

2020-03-16T16:06:00.005-04:00

So you say you want to calculate line of site on a hex based digital map...

Lines are made up of individual pixels. But which pixels?

We need to know how lines are represented on a computer. Horizontal lines are obviously constructed using pixels in a single row from point A to point B. The same can be said for any vertical line... all pixels from point A to point B from a particular column are used. Diagonal lines at 45 degrees are somewhat more complicated, but if we just travel one to the right and one up, we can cobble a fairly straight-forward algorithm together to manage these 3 simple cases.

However, it's when we start to draw lines of different slopes/orientations that we need to come up with something clever to determine every pixel that a line contains. Fortunately, my detective work paid off and the case was solved. The magic bullet... the Bresenham line algorithm. I know... very exciting.

Let's back up for a second. At this point, you might be somewhat confused. Why do we need to know what pixels constitute a line on a computer?

Let's start with how I have represented the GMT Panzer map in my project. The basic game comes with a paper map. The map is divided into hexes...

Hex id 1006. Clear terrain.

I took a single hex from a digital version of the map and brought it into GIMP, which is like Adobe Photoshop. From there I used the "Line Tool" and drew lines over top of the hex borders...

Tracing the border of a hex.

Now if I remove the hex image, it will leave us with just the red line I traced...

A single side of a hex border. We can use each pixel in this line to our advantage.

It turns out that GIMP (and other programs like "Paint") uses the infamous Bresenham Line Algorithm (or versions of it) to draw the line I just painted. Cool. Now I can trace the entire border of a single hex...

Now we can identify each pixel that is used to define the hex border.

... and manually record each pixel coordinate. This will define the border of my hex. Here's how I'm storing the hex pixel border data...

Each hex border pixel is stored as a "Point".

Let's take a closer look at the first line...

There are two points specified in this line. The first point (43, 0) is the upper left corner of our hex border. The second point (130, 0) defines the upper right corner of our hex border.

The second line is as follows...

Here we have another two points (42, 1) and (131, 1), which define the left and right border pixels one row down from the top row.

We continue to do this for each set of points in our hex borders, row by row, until we reach the bottom of our hex.

When a line is drawn on the Panzer map for line of sight purposes, we use the Bresenham Line Algorithm to determine all of the points on that line, then compare each of its pixels to see if it falls between our pixel boundaries for each row of pixels in the hex. If one of the pixels does fall within these boundaries, the hex is in our line of sight.

Pixel points of line falling inside hex border points.

Now that we have our starting hex with all of its border points established, we extrapolate out the border points for all other map hexes based on their map hex number. If we are determining the border points for hex 0210, we simply shift the left and right border points the 2 widths of a hex and shift the rows down "10" heights of a hex using multiplication. With a little trial and error, the system works!

Of course, there are some minor details that I haven't communicated, but I don't want to bore you!

Although, if I haven't already...

Map

2020-03-12T22:23:00.000-04:00

The base game comes with a single paper hexagonal map. It contains a variety of terrain features, hills, gullies, cover as well as a number of paths, roads and crossings. Villages are represented as wood, stone and brick buildings, some with alleyways. Hedgerows and walls are sparsely located, but add a level of complexity to the project.

The hexagonal base game map contained in Panzer. This will be a challenge to implement.

Each hex on the map will need to be represented in the system. A terrain key identifies all of the existing types of terrain on the map. Each hex has a single terrain such as Woods, Scrub, Bridge, Ford, Clear, Stream, Road etc.

Terrain key

Each terrain type has different properties, listed in the Terrain Effects table below. Each type of terrain is listed in the left column.

Terrain effects table

If we take a look at the "Clear" terrain type, we can determine that is has a height of "0" and a cover of "None".

Alternatively, the "Woods" terrain type has a height of 3. The height of the terrain type might block our line of sight to enemy units. We'll cover line of sight later on.

"Woods" also has a cover of "Medium", which allows us to hide from the enemy at certain distances.

Additionally, if we look across to the "T,H" column, we see that "Woods" terrain type has a movement cost of "3" for any track or half-track vehicles. If our Tiger I is moving through the "Woods" terrain type, it will use 3 of the 4 movement points to do so.

All in all, the terrain effects table is a very straight forward table to represent in my project.

The biggest overall challenge I faced is one of "Line of Sight". Line of sight in GMT Panzer is fairly straight forward in terms of game play. The technical challenge of applying this to a computer game was, at least in my opinion, one of the tougher pieces to consider.

In Panzer, we must be able to determine what a unit can see on the map board. After all, you can't hit what you can't see (generally speaking). So, before a unit fires a shell, bullet or volley, it must be able to see, or spot its intended target. Spotting a target requires "Line of Sight", in which we take a straight edge or piece of string and align it on the map from the center of the shooting unit's hex to the center of the target unit's hex. Centering the straight edge on each hex is made easy by the white dots in each.

Line of sight is measured from the center of the shooting unit's hex to the center of the target unit's hex.

Once we have a line drawn from hex to hex, we verify that there are no obstructions between the units. We do not include the hexes that either unit occupies. From the image above, we can see that the Soviet SU-100 M44 (hex 1308) has line of sight to the German Tiger I (hex 1905). Our line crosses a number of hexes, including 1408, 1507, 1607, 1706 and 1806. We note that none of the hexes in which our line crosses has an obstruction. Therefore we have determined that the Soviet unit has line of sight to the German Tiger. We can also say that the German Tiger has line of sight to the Soviet SU-100.

This is a very simple example of line of sight in Panzer. Things get a little more complicated when the line crosses very small portions of hexes. Let's look at another example...

Our line crosses parts of other hexes. Each hex crossed must be considered for obstructions.

The example displayed above demonstrates good line of sight from unit to unit, however the algorithm will need to be able to consider whether the line touches any portion of a hex in order to return line of sight determination. This line of sight crosses hexes 1307, 1406, 1507, 1607, 1707, 1807, 1906, and 2007.

Special Cases

Line of sight gets even more complicated. When our line is horizontal or a specific diagonal, it will be drawn across the entire side of a hex. This also means that the neighbouring hex that shares the side will also be included in the line of sight determination.

Consider the following example...

Horizontal line of sight must include hexes that share borders.

Both units have line of sight in the screen above. We need to include hexes that share a border with the line of sight. Let's start our line of sight determination with the Soviet T-34. We don't include the hex that the T-34 occupies, but we do include hexes 714 and 715 because the line crosses the entire length of each hex's sides. Moving on, we see that the line crosses through 0815. As we continue, we see that 0914 and 0915 must be included as well. This continues until we reach the German Panther.

If you take a close look at the map, the same situation arises when we have to determine line of sight on certain diagonals. In the image below, we can see that the line crosses the entire border of a number of hexes. The hexes include 0712, 0613, 0713, 0614 and 0714.

Some special case diagonal line of sight calculations are required.

I have identified all of these special cases and taken them into consideration. Along the way, I stumbled onto the fact that hex based maps have an offset column structure in terms of numbering. Hexes are "pushed down" every other column. This isn't exactly a perfect row and column numbering system here. I'll need to determine whether a unit is in an odd or even hex to determine the neighbouring hex numbers for these special cases.

I think that's enough for now. I'll explain how I managed to accomplish the map generation in a future post. Meanwhile, here's a short Panzer SOLO video of line of sight in action...

Units

2020-03-12T22:02:00.001-04:00

Tiger I counter represents

a single unit on the map.

Each tank (or unit) is represented by a counter. Players have a number of counters that they command. Each counter contains various pieces of important information, including whether the vehicle has tracks, halftracks or wheels, as well as the speed of the unit across roads, paths and open country.

During the course of a player's turn, they will move these counters around the map in order to tactically gain an advantage over their opponent's units, and then firing upon the enemy until the scenario is over.

Counters are great, but the real meat and potatoes of this game are each units "Data Card". Data cards are the life and blood of each unit, describing their properties, offensive capabilities and defensive protection.

Data card for the German Tiger I.

We won't get into the greasy details of the cards for the moment. For now, we'll just say that these data cards are one of the primary reasons I thought I might try to pull this project off. If you analyze each card long enough, it becomes clear on how you might represent the information in an object-oriented way.

Each unit has a variety of defined properties, such as:

Speed
Bog modifier
Size
Turret turn rate

Each unit also has data that can be represented as lists:

List of ammunition types
List of gunnery ranges
List of armor piercing damage
List of defensive data

We'll get into each of these in due time.

Let's get rolling!

2020-03-12T13:28:00.001-04:00

GTM Panzer basic game. There
are a number of expansions that
are available as well.

I want to convert the GMT Panzer series war game to a desktop computer game.

I'm going to add an intelligent system that provides an artificial enemy.

And then I will play this game solo.

I'll be documenting as much as I can, as often as I can. The programming challenges are daunting, but we're going to give it a go...

What is Panzer? Without going into too much detail, it's a hex-style war game covering the second world war. The focus centers on tank warfare. Each piece on the board represents a single unit. Each player manages a formation, taking turns spotting, firing and moving until one side manages to outscore the other. What's left at the end of the game is a heaping map of twisted metal and burning hulks.

Game play consists of a number of phases, each of which I will need to explore in minute detail in order to translate to the computer version. There are a significant amount of rules to implement. This will be no trivial task to program.

I'm making this up as I go. Things might not be as clear as I intend, although I am not trying to explain every little rule. That's what the rule book is for. What I will do is try and demonstrate some of the complexities that must be conquered.

Of course... complexity is subjective :) I have never created any kind of computer game let alone implement an AI system. I have never done any Windows graphics programming either. Not a great resume! But I'm up to the challenge. Hopefully at least a few will find this site somewhat interesting. Either way... I'm excited to get rolling.