The ArmourSoft Inc. Newsletter
Die Haus OrgelAugust 1995/Issue #7
Published, oh, about quarterly, give or take
All contents copyright © 1995 ArmourSoft Inc. Send submissions, subscriptions, complaints, questions, and bad poetry to: ArmourSoft Inc., [obsolete mailing address deleted]
Inside this issue:
Click here to return to The DHO Index.
I Tank, Therefore I Am
Some thoughts from the designer of Tankbase
Building a wargame system from scratch is much like any other large project in that it's vital to remain focused and to always keep in mind the goals and objectives. This is especially important when deciding which elements to put in the game and which to leave out.
The focus of Tankbase (TB) has shifted somewhat since the project's inception in the early 1980's, but the primary objectives are unchanged: it is intended to cover everything and everybody involved with ground combat since the earliest tank designs of World War I (and even the years prior to WWI; our local game group is pondering the idea of playing a company-level American Civil War miniatures game using the infantry combat system from Tankbase) and it has to be strong both as a game and as a simulation. However, whenever an irreconcilable conflict arises between the two, good game will win over good simulation. After all, this hobby is called wargaming, not warsimulating.
In the process of figuring out what TB is, it's also important to figure out what it's not. It's not going to be an exercise in physics or ballistics or metallurgy, for instance. TB looks at what happens to something when a piece of ordnance hits it, not what happens to the piece of ordnance through every point of its flight path. Nor will TB be concerned too closely with the Brinell ratings or the precise effect of shell splintering at a 20° angle as opposed to a 22° angle. This goes along with what we were saying a couple of issues ago: we've got some very good metallurgical data on Shermans and T34s, but practically nothing on the other 600+ tank types in the database. The minute details of ballistics and metallurgy aren't particularly appropriate in the time, ground, and unit scales covered in TB.
Continued - see Murders on Page 2
Newsletter Editor Ruthlessly Murders
the English Language
Continued from Page 1
The game also won't be an engineering thesis on armour layout. The origins of TB go back to a computer-assist version of the old TSR Tractics ruleset from the early 1970's, and those roots still show in the description of each tank's armour in the "Eleven Spots": turret front, gun mantlet, turret sides, turret rear, turret roof, upper glacis, lower glacis, hull sides, lower hull, hull rear, and hull roof. (Quite a few armour miniatures rules in existence today are also influenced by the venerable Tractics system. Most of these are easily recognizable by the use of some variation of the "Eleven Spots" of armour.) Tankbase goes a bit further than most other armour rules in that armour thicknesses and angles are expressed separately for each of the "Eleven Spots", rather that the more common approach of combining the two into one value. This is because different angles have different effects on different types of ammunition.
Even with that in mind, while researching the armour thicknesses for the tanks it quickly became obvious that it wasn't practical to take into account all the possible armour thicknesses and angles on a given vehicle type. It's easy on a Panther or King Tiger, which have nice simple plain slabs of armour for upper and lower glacis plates, with only a few odd bits sticking out here and there for hull machineguns or drivers' vision ports. On the other hand, the typical British early WWII tank front end consisted of lots of plates and bits sticking out at all angles. However, the effect is much the same: the "armour base" (effective thickness, taking angle into account) is usually constant across the front of a tank. We have in our source libraries a few of the old Bellona prints, which have some very nice cross-section drawings of tanks that give precise measurements of armour thickness and angle at many points. The Valentine (for instance) has a number of plates of varying thicknesses assembled at varying angles making up the front end of the tank, but the armour base is constant for the whole front.
If we were making a game system that was meant to include only 30 or so different tank designs, we could have a very elaborate procedure for keeping track of armour characteristics on dozens of different spots on each type. That doesn't really fit in with what we're trying to do though. Perhaps someone else would be interested in writing such a simulation (it would be kind of interesting, in a way) but it falls outside the scope of TB.
From Our Point of View...
The "soft" factors are another important issue in the game design. Morale and command & control are integral parts of the game, but Tankbase is not intended to be the final word on C3 (Command, Control, and Communications) or morale rules. There were a number of game designs in the 1980's that followed a revisionist "'hard' combat factors like weapon statistics are meaningless, the 'soft' factors like morale and C3 are the only important factors, therefore these rules will stress C3 and ignore weapons data" approach. While that argument has its merits, the games following that line of thinking tended to be pretty boring and have for the most part been forgotten by the gaming public. Part of the appeal of tank games is that lovely "tanky" feel that you get from all the weapon characteristics and vehicle data.
For at least a decade now, there has been a debate raging in the wargame design community over the concept of Point-of-View (POV). Several prominent game designers have stated that they felt that a particular unit scale was the appropriate scale to game in, and that anything else was folly. One particular school of thought holds that each player in a miniatures game represents a battalion commander, so the information available to him should only reflect what a "real life" battalion commander would know, the units should only be the size that a battalion commander would handle, and so forth. There is a certain amount of logic in this argument, but it has two very big problems:
There has been some discussion recently on the Internet about the validity of different gaming scales. Several gamers (and designers) have posted that they felt this scale or that was all wrong, that everyone should use 30 minute turns (for instance) and nobody should use 15 minute turns, and so on and so on. These remarks are usually accompanied by some good reasons, but it always boils down to personal preference, which is why there's no concensus between everybody about exactly which scale is the perfect scale. Gamers as a whole tend to be opinionated people (possibly due to the above-average level of intelligence and education among wargamers) and the enthusiasm with which these opinions are expressed is often matched only by the diversity of opinions to be found on the subject.
We don't mind the strong opinions held by gamers, in fact we expect it as a normal and integral part of the hobby. The only time it bothers us is when it steps over the line from "in my personal opinion, this is how we should game" to "this is how it should be and no one should do it any other way", attempting to inflict the individual's personal preferences on everyone else in the entire hobby.
Places to Go, Infantry to See, Things to Blow Up
Having said all that, we're trying very hard to make Tankbase as flexible as possible, to make it work well with as many gaming styles as possible. Obviously we can't make everybody happy; no single set of rules can. One person's favourite game design feature will be completely anethema to the next person. The best we can hope to accomplish is to make most of the people happy most of the time.
In order to implement this desired level of flexibililty, we listen carefully to every suggestion that comes our way. Unfortunately, some of the suggestions fall into the "sounds nice on paper but..." category. There are two suggestions we hear about once or twice a year, that go a bit like this:
In theory, these are both good ideas, otherwise so many people wouldn't be coming up with them so often. In practice, they don't work at all well with the sort of games we do.
We tried both these ideas years ago, both did very poorly in playtesting. Both work okay in small scenarios with only a few units, but fall apart rapidly if there are lots of units in the game. ArmourSoft designs are all intended to handle everything from the smallest scenarios to the largest, so the game systems have to be able to handle really huge scenarios.
The first idea, having the computer keep track of every unit's position, runs counter to the fundamental ArmourSoft philosophy of having the miniatures and terrain on the tabletop represent relative positioning (3D objects are really good at that sort of thing, especially well-painted miniatures!) and having the computer do what it does best by taking care of the game mechanics. Otherwise, we might as well put away the miniatures and terrain and go play a "proper" computer game.
Years ago, just before we started work on the original Shipbase I, we worked up a pre-Dreadnought naval game based on Metagaming's boardgame Fire When Ready that used the second idea listed above. All the parameters for every combat were keyed in at the beginning of every turn. It was terrible. If the scenario involved a dozen ships or less the system was bearable, but it became incredibly cumbersome for even a mid-sized battle like Tsushima (56 ships). The computer operator had to key in every single combat, which took a lot of time even with the simple user interface that FWR had, while the rest of the players sat around yawning with nothing to do. Then, after everything was keyed in, someone had to read off the results of 56 combats one after the other, greeted with more yawns. It made for a very, very boring game, with everyone but the operator sitting idly for long periods of time."Ya Can't Chop Down an Infantree..."
Getting back to the flexibility thing, our main tool in reaching for this goal is the variety of scale settings available in TB. Unit scales are set at the beginning of each scenario, with vehicles set at either 1:1 or 1:x (x is set individually for each unit, but will usually be something like 1:5 for most gamers; it can be anything from 1:1 to 1:200, but the higher up you go, the less accurate the simulation value you get and the sillier the abstractions become.) Infantry units are the most flexible, available in 1:1 (popularly known as "skirmish" scale), fireteam/squad (each infantry unit representing 1 to 15 soldiers), and 1:x (again, x is set for each individual unit and can be between 1:1 and 1:9999. It works well, especially at 1:40 or so (platoon level) but as with vehicles, as you go higher you lose simulation accuracy and the abstractions can become really silly. Still makes for a fun game though, and allows for units of up to brigade or even "light" division size, if you don't take it too seriously.)
TB takes a bit of a different approach to things than most other games, as exemplified by the infantry combat system. When one squad shoots at another, for instance, rather than simply examining the number and type of weapons the squad is carrying (the venerable "counting rifle barrels" method of wargame design) and coming up with a set, constant "attack factor", TB makes the assumption that not every single man in that squad is going to fire every time he's ordered to do so, for a variety of reasons. Out of a squad of ten men, some might not be able to work their way into a good firing position; others might be busy hiding under the nearest large object; others will be occupied with reloading their weapons, or looking back to see where Sarge is, or waiting just a few more seconds for the target in their sights to move just a little bit closer. If the troops are good, all of them will fire on some turns. If they're, well, not so good troops, perhaps none of them will fire in a given turn. This is one of our little ways of simulating the importance of training, morale, and leadership.
When you tell the computer that your Squad A is shooting, it looks to see how many men are in Squad A, what their weapons are, and what their condition is in terms of morale, leadership, quality ("training", if you like) and health (unconsciousness, wounds, death). Then it takes a look at each man one at a time. If a man is unconscious, dead, or has taken a morale hit, he isn't going to shoot. If he's wounded, that reduces the likelihood he'll shoot. Squad quality and leadership have the most effect on his shootiness.
There aren't "straight" die-roll modifiers for these factors as with most other games, i.e. you don't get a +5 for being "elite" or a -5 for being "green". Instead, the TB program rolls for each and every combat to see what sort of bonus is applied within a specified range. So, f'rinstance, one turn you might get a +2 for being "elite", the next turn you might get +6 for the same soldier, and the following turn you might not get anything at all. This is our way of simulating the "things tend to change a lot" aspect of real life.
The end result is that just like real squad leaders and commanders, you'll never know exactly what you're going to get from one turn to the next, but you can be sure that the higher quality troops, leadership, and equipment you have, the better your results will be overall.
Obviously, this isn't going to be a game for rules lawyers. We actually got complaints from two or three people who said they didn't like Shipbase III because they couldn't manipulate the rules and study the combat charts to ensure they were getting every single die roll bonus available. Tankbase is going to be even more so. Our response to this is, "well, ya can't make everybody happy all the time..."
Hah! This issue is on time! So there!
Thousands flee, mostly just for the heck of it
Longtime DHO readers might have noticed by now that each issue looks slightly different from the last. That's because each issue was printed on a different laser printer. Issues 3 through 5 were done on several different printers each, so one copy of issue #4 might not look quite the same as another #4. The reason behind all this is that DHO is put together on a shoestring budget (also something obvious to longtime readers) and we could never get our hands on a given printer for more than a few months at a time.
Well, all that's changed now. The recent changes around here have caused quite a bit of turmoil but also led to a situation where we can afford to buy some new equipment (see Editor Gets New Day Job, Makes More Money, Is Executed for Using the Wrong Typesetting Fonts In ArmourSoft Newsletter in the last issue of DHO). We just bought a new Epson Color Stylus 720dpi inkjet printer, which will add a sprinkle of color to these (mostly) previously drab pages. (A handful of copies of issue #3 were printed with an older color printer.)
This is a good spot to remind all our readers that the best way to get in touch with us is via electronic mail. We all have "day"/"real" jobs and don't have a separate office or phone, and the post office box is only checked once or twice a week, but we read and reply to e-mail almost every [month]. The on-line presence of wargamers is constantly growing. If you don't have access to the Internet and especially e-mail, we highly recommend it.
This is undoubtedly the worst picture of a P51D Mustang we could've run in this spot. But what the heck.
Who's behind ArmourSoftThe crew, as of this week:
However, we can bring you
The DIPCo Section
We briefly mentioned in last month's issue that we needed to change our beloved DIPCo logo. This image, which graced the bottom righthand corner of each of the previous issues, featured several DIPCo personnel who are no longer with the company. This turn of events sent us scurrying madly through the artwork archives, searching for a suitable replacement.
It was an interesting endeavour, for in our voluminous storage facilities (well, a small cardboard box actually) we found several folders filled with long-forgotten logos that had been created but never used. The earliest of these logos were simple pencil sketches drawn by the same fellow who had created the artwork for Slargeball (the lying, cheating, murdering bas-- ooof!)
However, most of the pieces in the portfolios were drawn by Tom Davenport, the artist who had worked on the cover art for Shipbase III as well as Chart Wars/Space Waste. These were the most intriguing, partially because they prominently featured a creature first seen on a corner of Tom's Space Waste masterpiece. This figure is alleged to be Zapnik Glek, renowned Venootie practical joker and erstwhile Irvanian Commando, and this figure also appeared in the "five guys in the dark alley" illustration that graced the corner of this newsletter for lo these many issues.
Then, of course, there was the famous "This is your brain [anatomical picture of brain], This is your brain after playing a DIPCo game [picture of a potted flower], We're really sorry about that" logo. We liked that one, but it too was shot down by the Powers That Were. Just like our idea to produce Napoleon at Chattanooga: the Collectable Card Game, which we still think would have been a big hit.
Click here to return to The DHO Index.
The content on this page was written in 1995
Last updated: June 11, 2016