In the first installment, Wolfgang told us how a desire to create his own system slowly grew out of a similar Scenario Generator for “Lock’n’Load.” He wanted modular battles in which he could tailor everything to the way he wanted it, but also keeping in line with the Campaign System. How did “Assault – Red Horizon 41” develop from here?
Time Frame: July 2014 to November 2014
The first plan was to design a tactical wargame in which each individual soldier was represented by a wooden cube. We had the old “Steel Panthers” in mind, as well as “Close Combat” and “Combat Mission.” “A combination of these three would be perfect!” we thought to ourselves.
For the first attempt, we had planned a small-scaled approach. For instance, the buildings would have several rooms, windows and doors, as well as varying number of floors. A vehicle had individual crew members and different abilities, areas of technical specialization, and functions. All soldiers were portrayed as wooden cubes. An infantry troop consisted of 10 cubes (1 group leader, 9 riflemen). Every cube would indicate the soldiers status, depending on which side was showing. Therefore, individual soldiers could be wounded or killed. And the breakdown of machinery in the vehicles and artillery could limit or completely destroy the functions of these units.
We wanted to have a scenario landscape that was as modular as possible, meaning the game set up was completely free-form. This would give countless possibilities for setting up a scenario. Standard terrain types were then developed. These pieces would, however, have to be compatible to each other in every direction. During all of this, we always had our Campaign concept in mind. Our tactical system should later also fit to Campaign games.
The rules were layed out in tables. A soldier could move in different ways and perform different actions. There were Group Orders to move a whole group of blocks. The order system consisted of markers, which were placed concealed on the units in the Planning Phase. During the battle, the players took turns performing actions. This should eventually simulate delays in orders. The individual status of a soldier were indicated on the six sides of the soldier’s cube.
After hours and hours graphic work on the computer, printing and a near eternity of putting everything together, the first prototype was born: Design #1. I was already looking forward to playing the first battle.
But wait. How do the Orders, Units, and Weapons even work? For that we first had to at least come up with some basic rules or better overall terms, so we had tables with outlines and flowcharts. The rules should develop from the feel of the game and the situations that arise. We attempted to build the weapons’ game abilities and functions from the actual real-life specifications. And here we finally needed a break to assess the strength of each individual weapon. This was our starting point.
In just the first turn of the scenario, we were already having a good amount of fun. You could really put yourself in the situation of the wooden soldier cubes. Groups of soldiers advanced from hex to hex under armored support. The goal was to take an enemy defensive position on the edge of the forest. An anti-tank cannon and accompanying infantry opened up the fight. We had the first losses. A medic took care of the wounded and it kept going. Then there was a hit on the light tank—the engine, cannon and track were damaged. The medium tank put everything he could on the AT cannon. The crew leader and a crew member were wounded. The order to advance further was given.
That’s the gist of our first party. It sounds pretty action-packed, doesn’t it? In actuality, it was so. However, games tended to last a very long time because of the large amount of cubes (soldiers) and the detail of the rules. We had to come up with a way to reduce the playing time.
In the next installment of the Developer’s Journal, we learn which steps were necessary to further improve the game.