I’m going to try to upload weekly Windows builds of my work in progress so players can try them out. Bear in mind that these are not complete games, and will have bugs and unfinished features, but they will include additional features and fixes not in the previous proof of concept version.
I’m pleased to make available for download the final proof-of-concept version of Armoured Commander II. This means that I think the design of the core gameplay is good enough in its current incarnation to start work on a proper Alpha version. I’ve gone through quite a few re-designs and re-factors over the past year and a half, but with this system I think the game is finally starting to click.
Note that the game in its current state is incomplete and likely still buggy, and nothing works exactly the way it ought to. It will, however, give you a good sense of where the game is going and how it will continue develop in the future.
Download here – no installer is included so you may have to manually inform Windows that the programme is okay to run.
Edit: Fixed the download link!
Edit 2: A weekly build is now also available, more up-to-date than the version linked above.
I’ve just today added objectives back in to the map, along with a display of their distance from the player, the direction toward them, and a colour signifying their status: neutral, friendly-controlled, or enemy-controlled. Objectives must now actually be held by a unit to count as captured, meaning that in the future the player will have to decide which of their friendly units they leave to defend an objective if they have to hold on to it.
You might also notice from this screenshot and the one form the previous post that the command menu looks quite different from before. I’ve returned to an earlier idea of having basically one action (or set of actions) per turn, rather than adopting the wargame-style phase progression. This brings ArmCom2 even closer to the play experience of a tradition roguelike, without, I trust, losing anything in terms of realism and fun. The way I have it set up for now is that moving ends the player’s turn, but in the future there will be a chance to get a free turn if you’re moving along a road or in open terrain, the roll for which will be influenced by the type of tank you are commanding. Difficult terrain, on the other hand, might make you skip your next turn. Firing a gun doesn’t end your turn but you are limited to firing for the rest of that turn, and most weapons can only fire once per turn unless they maintain their Rate of Fire.
These are all ways of abstractly dealing with time, turning a reality where everything is happening at once into an orderly system of discrete events, but I think it’s a system that should work well in practice. Certainly the change to an action-based rather than phase-based means that things can happen much more quickly, both when traveling overland and when fighting a battle.
Have returned from a couple weeks conference travel and had a little time to continue working on a number of minor but essential systems in the game. One of these is restricting attacks to covered arcs, as shown in the image above. As you can see, the Hull MG is in arc for this target, but since the turret has been rotated, the main gun and the co-ax MG cannot. I’ve started adding additional Polish tanks and guns in preparation for writing the AI routines and testing them.
I’ve also completely removed the on-map pop-up labels. As with ArmCom1, these have turned out to be difficult for the player to follow in the heat of action, and I think the message console below the map, in conjunction with on-map hex highlights that activate when a message is added and a message log window for the player to review, will work much better.
Facing the difficult problem of trying to cram too much information into a limited area of the game screen, I’ve added a new console display in the upper left corner of the map viewport that displays different information depending on the current turn phase. In the movement phase it shows the movement class of the player’s tank, their maximum and remaining Movement Points, and in the future will also display any movement-related restrictions (immobilized, bogged down, etc.) In the shooting phase, it contains essential information on the player tank’s main gun. Both movement and main gun information will always be available from the player tank screen, but for the most part players will only need this data during the appropriate phase, so it seemed to make sense to move it there. As a result, I’ve been able to display more important data about the player tank, such as its crew and armour ratings.
I’ve also improved by roguelike credentials by adding a message console to the bottom of the map view, with a message log window to come in the future. The full messages will eventually contain much more specific information about what is going on (timestamp, name of the unit, etc.) while the on-screen pop-up messages will only provide quick indications of events and outcomes.
I’ve made a fair bit of progress on Proof of Concept 4 of Armoured Commander II:
expanded the base terrain map and edited terrain generation to handle maps of any size
implemented a basic concealment/spotting system with a set of rules on when and how units are spotted depending on their unit type, current terrain, range to spotter, etc.
implemented reloading and rate of fire rolls for ordinance weapons on the player tank
added a new system for attacks, using modified to-hit and firepower calculations; this system is similar to that used in ArmCom1 but is steamlined and modified in a few ways
One major change from previously is that successful AP hits on armoured vehicles and small arms attacks on units are now applied only at the end of each phase. This means that the player (and other friendly and enemy AI units) will know when an attack has been successful / has penetrated the target armour, but will not know what the end result of these attacks will be until the end of the phase. For infantry/guns this ranges from a pin test to destruction, while armoured vehicles might only suffer minor damage or might be knocked out completely. This is a central mechanic of the game and it’s important to get it right. My goal with this system is to replicate a little of the fog of war, where the fate of an enemy platoon or vehicle after an attack isn’t always immediately evident, and firing units don’t have the luxury of taking attacks one at a time and seeing what final effect they have before proceeding to the next. It also allows multiple units to add their firepower in attacking a single target, the sum of which is resolved at the end of the shooting phase.
After some reflection prompted by a brief mention of ArmCom2 in The Flare Path, as well as reading the excellent discussions of early computer gaming in The Digital Antiquarian, I’ve decided to return ArmCom2 to its roots, abandoning my static-map, platoon-based plans. The strengths of ArmCom1, such as they were, stemmed from the game experience of commanding a single tank and having to meet challenges with the crew and weapons available to you. I’ve re-worked the main map display in ArmCom2 so that the player tank is always in the center, and the game map moves and rotates around you. The crew is also back, as is a detailed description of your tank’s main gun and current status. This means that the ANSI depiction of your tank has had to be removed from the player tank console, but I did incorporate these unit portraits into the attack resolution window.
So what’s going to change from ArmCom1? My hope is that I can build on its strengths and make up for at least some of its shortcomings. In brief:
I will continue working on early war German and Polish units to start, with the aim of including all major units and theatres of the war, 1937-1945
The campaign day map and encounter map of ArmCom1 will be combined into a single map through which the player travels with their allied units, and on which battles also take place.
This map will be less abstract than the ArmCom1 map, with each map hex representing a 160 metre wide area. The position of units relative to your own will be more clear.
The player will be able to order allied units but won’t direct control their actions. Using these allies, which can include reconnaissance, tank-destroyer, infantry, etc. units, will be key to survival
Your tank will also have 2-4 allied tanks in its squadron. These tanks will follow your lead, and will try to support your attacks as best they can
For the most part the player won’t have to issue individual orders to tank crewmen; you can choose your tank’s actions and your crew will do the actions needed. If you do want a crewman to do something out of the ordinary, attempt a repair for example, then you can do that at the start of your turn, but this will restrict possible actions later on if, for example, your driver is occupied and can’t drive the tank.
Those are the core gameplay changes that I have in mind to start; hopefully I can get this working and there will be a lot more to come in the future. Next major goal is to complete a playable Proof of Concept version with the revised map and gameplay.
I don’t have a new version of ArmCom2 ready to show off, but I have been making some changes over the past few weeks. Most important of these is shifting the core gameplay from a platoon-based system back to individual tanks and squads as in the original ArmCom. This means that the player will again take control of a single tank with its crew, and will have a small number of other tanks in their squadron that will be AI-controlled but which follow the player around and serve as extra guns and extra targets. I agree that the experience of commanding a tank and its crew is the element of ArmCom that makes it special, so I’m working to recapture that experience in ArmCom2. Right now I have the basic tank functionality working, and will add in crew orders and actions next. My plan is to have the crew act intelligently to player commands, so that the player will only need to change their order if they want to do something out of the ordinary. The player will be able to move and fire with their tank and the crew will perform the tasks required of them, but if there’s a main gun malfunction then you’ll need to intervene to order a crewmember to repair it. I’m also drawing upon my experience with the first game to design a system that is more flexible: for example, crewmembers will be able to move to different positions in the tank as needed, if for example a crewmate is incapacitated.
I have a busy couple of weeks coming up, but hopefully soon after that I will have a new Proof of Concept version for players to try out.