MEST v2.x :: Additional Archetypes

Overview

As always, I'm striving to make MEST v2 complete and correct.

Archetypes are basically standard collections of attributes and traits. Common Archetypes are normally what each game session of MEST starts with. The most most basic is the Average Common Archetype where all Attributes are just 2 (average human), and there are no traits assigned.

The most expensive is the Hero Common Archetype which has a whole bunch more. See the image here for the complete table;

The Common Archetypes representing most human or humanoid characters. These haven't changed very much from MEST 1.6x except for maybe their BP costs and some tweaking of traits, especially for the Acrobat. I think the Beasts (Dog, Fiend, Predator, Monster) have had some adjustments as well.

Variant Archetypes

To add variety to each game-session, I introduced Variant Archetypes. Again, these are presumably human or humanoid character types. Therefore I've introduced entries such as Average, Cultist, or Acrobat, Sneaky, and Mystic, Leader. I've created quite a few to cover most situations or settings, being that MEST is a per se "low-magic" or "realistic sci-fi" game system. 

Here's a sample of the provided Variant Archetypes;

Animal Archetypes

For some players with a wide collection of figurines and miniatures, I've added Animal Archetypes. The table is a bit large and in all likelihood incomplete, but it does include entries for Bear, Cave Bear, all sorts of Dogs including Wargs, all sorts of Horse, and even a Komodo Dragon. As I build out more of MEST 2.x I'll probably expand the table just wee bit more, but the idea is to not be complete in the baseline rules since I'll have the genre documents to do that for me.  For example, the Dunjon of Death genre document will include varieties of giant spiders, rodents of unusual size, and maybe a few slimes or molds.

Here's a quick look at the include animal species;

The various animal species available for MEST 2.x. I like the fact that I've got all sorts of dog species listed so that I can differentiate between Wargs, Wolves, and Hounds!

Sophont Archetypes

A Sophont is an intelligent species commonly encountered in science-fiction and fantasy settings. The default sophont for MEST is "human", and most humanoids in MEST are just like what you'd find on television or in movies; humans with make-up otherwise known as "rubber-forehead aliens".

Therefore it wouldn't be unusual to limit alien species in MEST gaming sessions to just the Variant Archetypes and have ALL Klingons be Veteran, Warriors or Brawler, Knife-fighters, with just a few also being Leader, Fighter or Brawler, Brawny.

However, I've decided to list a few common sophont species for quick use. Just like the Animal Archetypes table where this list of Sophont Archetypes is not meant to be complete because each of the genre documents will introduce setting-specific entries. For example, the Gothic Horror genre document will introduce Wampiri ("vampires"), Lycans ("werewolves"), and Ungasumati ("mummies"). 

Here's a quick look at the included sophont species;

The current set of intelligent species included with MEST 2.x. Many of the names are specific to my FYBS role-playing game (I'll create a post later), but some of the entries shown are intuitive such as the Tcho-tcho being Pygmy, Leng or the Verminati being espys for GW's Skaven or Mantic's Verr-Myn.

Custom Archetypes

I wanted to provide a way for players to create their own Archetype, just in case the tables for Variants, Animals, and Sophonts is not enough!

The problem is that the points-costing system I use is very prone to abuse, as is any points-costing system. I've been tweaking and adjusting the system for several years now and I think I've got the numbers pretty much where I want them. 

Here's the gist of the system;

• All characters have a BP cost which is a combination of all costs of their traits and attributes.
• Some traits and some attributes are so powerful that they make the character exponentially more effective. Such considerations are REF, FOR, Tactics, and Leadership. 
• For these traits and attributes, I introduce a Cost Ratio factor [CR]. These are written as +1 or -2.
• Each CR represents a proportional cost adjustment. +1 CR means that for every 10 BP a character is worth, it increases in cost by +1 BP. So a 100 BP character with +1 CR is worth +10 BP extra; total is 110 BP. Also, a 100 BP character with a -2 CR is worth -2 BP per 10 thus -20 BP less; total is 80 BP.
• You can think of CRs as fractional factors. Just divide by 10 and add 1.0. So +1 CR is x1.1 and -2 CR is x0.8. Same with +4 CR or -3 CR; these are x1.4 and x0.7 respectively.

You can see how having a spreadsheet or maybe having a very clear, concise process for determining costs will be useful.

Building a Custom Variant Archetype

So, one of the many ways of creating a Custom Archetype is to combine a species template from the Animal Archetype or the Sophont Archetype tables with an entry from the Variant Archetype table.

Let's combine the Brute Sophont with the Brawler Variant. Here's both templates next to each other; take note of the last two columns for dBP ("delta build-points") and CR ("cost ratio").

We'll combine these two templates.

Steps

1. The first step is to add the dBP from both templates together. This makes +26 dBP plus +25 dBP for 51 dBP Total.
2. The second step is to note the CRs and order them from highest to lowest. So, its +1 CR and then -2 CR.
3. The third step is to adjust the dBP Total using the CRs in order. First is +1 CR. This means for each 10 dBP, adjust the cost by +1 BP. For 51 dBP this is +5 BP, causing a new total of 56 dBP. Second is the -2 CR. This means for each 10 dBP, adjust the cost by -2 BP. For 56 dBP this is -10 BP, causing a final cost of 46 BP.

Here's the above in picture form:

Math. How does it work?

For people with calculators, we can just convert the CRs into decimal factors by dividing each by 10 and then adding 1.0. So +1 CR becomes 0.1 plus 1.0 = 1.1. And -2 CR becomes -0.2 plus 1.0 = 0.8. Multiply both together 1.1 x 0.8 = 0.88. That factor is multiplied against the Total dBP of 51 making (51 x 0.88) = 45 BP.

The difference of 1 BP between the two methods is small enough to ignore during game-play because players are allowed to have upwards of 25 BP differences into totals for their Assemblies.

Anyhow, we'll call this combination of Brute + Brawler maybe "Brute Brawler". If we'd add Leap, Claws, Bite, and Detect, it could maybe become a Kzinti in "rage mode".

Other Custom Archetypes

I've included rules for creating other archetypes as well. I've got one for creating new Sophont species and another for creating new Animal species (or Sophonts, or whatever). 

Tables for generating new Sophont Archetypes.

Tables for generating entirely new Custom Archetypes. These can be used for crating new Animals and new Sophont species.

Traits Lists

Lastly, I've decided to make the most common Character Traits become available. This is sort of open-ended; I'd rather that any new archetypes don't use more than few beyond whichever was used for the creation of Variants, Sophonts, or Frames. Use at your own risk!

Here's the pick-and-choose list for traits. Go wacky and make things unbalanced if you'd like.

Finishing the Kzinti

Above we've created the Brute Brawler Archetype. It's 46 BP using +51 dBP and CR 0.88. Let's make it represent a Kzinti from Larry Niven's Kzin-Man Wars by adding Leap, Detect, Claws, and Bite. And for theme, we'll also add [Berserker]. 

We can get those traits and their values from the Character Traits List above.

Bite is +9 dBP

Claws is +3 dBP

Leap is +8 dBP

Detect is +5 dBP

[Berserker] is -2 dBP and -1 CR

Brute Brawler is +51 dBP

Total is 74 dBP.

Final Cost is 74 x 0.88 x 0.9 = 52 BP

And there you have it! 

The Kzinti Write-up 

Using the MEST v2.x recommended format, the Kzinti write-up looks like this:

Kzinti 402|044|424

Brute Brawler (+Bite, +Claws, +Leap, +Detect, +[Berserker])

[Beast+][Berserker]. Bite. Brawl. Brawn. Claws. Detect. Leap.

52 BP /+74 dBP -2 CR

The top series of numbers is CCA RCA REF | INT POW STR | FOR MOV SIZ in that order.

Designer's Notes for Barbarian Suns v2

The Avausim. The memetic representation of the Milky Way galaxy.

Preface :: These are my designer's notes for Barbarian Suns version 2. I think that BSv4 will have a better chance of getting published but it may take a while. Therefore I present my designer's notes here as a way to prelude the thinking behind the game design. Please note that both versions of the game (v2 and v4) play on a grid; v2 is on a square-grid and v4 is on a hex-grid.

Additionally, any mentions of SH2156 is in regards to my Superhero '44 Campaign.

There's a blog post describing what that means.

Designer Notes

A. Conception

It was a cold night in that cellar at Dan Pellerino’s house. Just myself, Dan and Damon Williams. None of us had any money to spend, and we were a bit hungry. In order to bide the time, we decided to create something a piece of graph paper. We didn’t have dice, so we modified our pencils into “Egyptian dice” by adding pips to each of the six sides. That was back in 1987. We didn’t have a name for it at the time, but we knew that the idea didn’t yet exist any where else in the gaming industry.

The basic game concept was actually formulated during my military years in 1983-86 in order to

support a strategic view of the SH2156 RPG game universe. As a science-fiction super-hero

role-playing game, SH2156 tried to meld the worlds of military gaming (a la Marc Miller’s

Traveller) and fantasy gaming (a la Hero Games’ Champions) into something more tangible.

This is understandable since it grew from the game I created in 1977 as a child to something

much larger when I revisited it after the USMC.

The adult that revisited the game needed to make it a bit “more”. So the background had to expand, and had to focus on events external to just interstellar warfare and comic-book heroes. Part of the background was to show that the events within the RPG were a small but critical part of a larger intragalactic war.

So, that night in the basement was something that we all hoped would be fun to play as well as

something we could continue to develop over time. What started from simple rules on scratch

paper and make-shift “pencil dice” has now grown into a comprehensive gaming experience.

B. Design Choices

All of us involved with refining the concept of an intragalactic conflict simulation game were

unsatisfied with the take of existing games like Stellar Conquest or Cosmic Encounters. Each

seemed to be on the opposite extremes of accounting practice or over-simplification. What we

wanted was something that could capture the sense of an RPG with all of its attention to detail,

but with enough martial constraint as to make it seem like a serious wargame.

We didn’t want a parlor game but we also didn’t want to have to learn a lot rules. We did want

something that was light, but could be played with seriousness between experienced players –

like a chess game but with spaceships and dice.

• First. The first design choice was the board. It could have been a hexagonal board, or even a grid like it is now – but with more cells. What we decided was to have a small board such that any military movement would have a great impact, without having to resort to a large number of markers. In this way, any military movement became critical because the number of potential bottlenecks increased dramatically.
• Second. The second design choice was the concept of movement. We realized that if we were to use a square grid, units would need to account for diagonal movement. Normally this is done by forcing a 1.5 movement point cost across diagonals. However, we decided that it would be too much math and also problematic in order to track which units had fractional movement points remaining.
  
  So a solution was to devise Movement Technologies” and to limit diagonal movement to an advanced form of intragalactic drive. Since the SH2156 RPG already had the concept of “Tunnel Drives” which would allow units to create worm-holes for unprecedented movement ability, we opted to allow diagonal movement under that guise.
• Third. The third design choice was the concept of accounting. We didn’t want to have to track all of the improvements that we associated to each player in a large matrix or note pad. Other games of the time allowed for such, but we felt that it would be too much information.
  
  When our system sectors received improvements, we decided to instead show that information on the mapboard itself. At Dan’s, it was just a special symbol drawn on the mapboard, but soon there were too many symbols to draw. This necessitated the creation of System Improvement Markers. It’s one of the unique things about Barbarian Suns that makes it fun to play; look at the mapboard and you can instantly assess your worth. When it came to creating the military units, we encountered the very same problem all military conflict simulation games have to address; too many markers.
  
  Some existing wargames had thousands of markers to account for specific variations or order-of-battle appearance. We had to drop the concept of an Order-of-Battle tree; too limiting. We also didn’t want to have three variants of the galactic equivalent of the Panzer III. We did want to have units that could be improved; but how to do so without adding more markers into the game?
• Fourth. Our fourth design choice addressed this by allowing nearly all technological changes to be accounted for via “technology” cards[4]. Each card would represent a specific rules alteration that could account for the addition of either new units onto the mapboard, or the modification of an existing rule or unit. In this way, if we wanted to improve a Dreadnaught[1] unit into an Ultradreadnaught[1] unit, it was only a matter of possessing the card indicating such.
• Fifth. The fifth design choice we made was the System Ownership cards. Again, we didn’t want to have to do a lot of paper work; we wanted a game in which the pieces and the statuses could be displayed via some other mechanism. The System Ownership cards allowed us to identify and account for what we owned much like the “Title” cards in Monopoly. An added benefit was like the Technology cards; any system-specific rules could be written upon the face of the System cards.
• Last. The last design choice came about after play testing. We had to create the Turn Order cards in order to offset the advantage a player had by going first each time. Initially we randomized this with a die roll, but we found ourselves re-rolling several times in order to beat ties that would occur.
  
  Additionally, once the dice were cast we were expected to memorize our order of play or else write them down. Since we wanted to avoid accounting work, we brought in the cards. A very large amount of play-testing went into the game to help refine its balance and the abilities of each unit and technology.
  
  For a game of this scale, it is really impossible to balance every aspect, but we tried to focus on three primary aspects; economic warfare, martial warfare and technological warfare. What I’ve discovered after several hundred hours of play-testing is that its best to capture a “feel” than to use numbers.

So, each Frigate[1] matters. 

One Minor System can support the creation of a Frigate. One Frigate can conquer a Minor System or control a Sector of the game board. The economy should be able to be grown via territorial conquest, as well as infrastructure development (“Boost”) and also via technology (“Economy II”, “Merchantry”). In this way, the player that sits by himself will also be able to compete with the player that aggressively conquers territory. This bodes well for that third player in a 3-player game.

For the aggressive player, we decided to allow numerous fleet units to be built and of a variety of form. Many of the variations would not be available unless technology for them was first had, but the pay off would be to provide capabilities that would make a great impact. An example of this is the Dreadnaught[1] unit. As a basic fleet unit, it would be available at any Shipyard[2] or Capital[2]. By itself, it is quite formidable. But when upgraded to a “Deathmoon”[1], it acquires just that “extra bit more” which makes it a unit worth employing in the place of dreadnaught. The best thing about it is that once “Deathmoon”[1] technology is achieved, ALL dreadnaughts become “Deathmoons”…

As for the System sectors, I wanted them to be able to be built into huge resources over time –

and so we created stages of advancement; Province, Minor, Major, Mega and Nexus. In this way, the player that can dig-in would be able to upgrade their few systems into something a bit more formidable.

As for the Technology trees, I wanted this to be completely different from existing games[4]. I

wanted technology to make an impact in the game. I didn’t want long technology trees because I didn’t view revolutionary technology to behave in that manner. Each step of technology research had to generate a definite edge in game play. In that way, a non-aggressive player could force the game to be one of “technological warfare” if the other players weren’t aggressive enough.

In order to help add more flavor to the game, I created four different kinds of Nexii to suit the

playing-style of each player. This theme we carried to even the Basic Fleet units and to the

Color cards. The premise works well in play – align the playing style with the proper Nexii, fleet

types and Color cards and the player will acquire a distinct advantage over those that don’t do

the same.

C. Artwork Choices

The first real complete set of playing pieces created for Barbarian Suns was done in 2-day

frenzy by myself while working the weekend as a physical security guard in late 1987. There

really wasn’t any artwork and nearly all of the original pieces were cannibalized from existing

games like SPI’s Starsoldier and Outreach. The game board was drawn within a 30-minute

flurry that next day with lack of sleep; using Prismacolors, acrylic line-tape for the grid and axis

labels; acrylic paint and a toothbrush in order to draw a simulated shape of the galaxy. This

was all done while my date was sitting in the car in front of Ray Wisneski’s apartment when I

gave the excuse to go and “use the bathroom”.

Since then, the game has gone through at least five redesigns of the artwork and pieces.

Raymond, Robert Curtis, Richard Frausto each of created one compete set of the game by

painstakingly gluing the laser printouts of my vector art to poster-board and carving them out

with a matt-knife. I think Richard created three sets and Robert two. Regardless; I lost them or

“accidentally” cannibalized them each time.

In this last iteration, the actual art itself is heavily influenced by a “meta-concept” I conceived to

tie in the SH2156 and the Barbarian Suns game. I call that the “Ovodium Cosmogos”. Using

the basic concepts of “memetics”, I fused fractals, art nouveau and baroque into a design basis

for all of the artwork. The result of which looks like the popular, “edgy” gothic tattoo work

employed by today’s youth. It wasn’t intentional, but there it is.

The single item where this comes together well is the mapboard which shows the four

metamemes by their colors (red, blue, green, yellow) overlaid upon a fractal “mandragora”

pattern of the galaxy, overlaid upon a digitally quarter-mirrored galaxy (actually M51), overlaid

upon some symbols representing the inner circuitry of the galaxy.

D. Pseudo History

The story of the “Ovodium Cosmogos” is the background for the game of “Barbarian Suns”. It’s

a lot more comprehensive than what is shown here, but the simple outline shown below pretty

much captures it. 

The fundamental reasoning for all of this is as follows:

1. IF Man is special
2. IF there exists other intelligent life in the universe
3. IF super-science exists
4. IF there exists a Great Force which control the behavior of the universe
5. THEN what would happen when Man begins to conquer the universe?

My take on this is that the Great Force would either want to enhance Man’s ability to conquer

the universe, or hinder Man. Unfortunately for Man, a vote had already been cast, and action

has already been taken to shut the Milky Way galaxy off from the rest of the universe so that

Man can’t spread any further. What remains within the galaxy are sub-sets of that Great Force,

each striving to collect absolute control so that they can then focus on re-connecting the Milky

Way galaxy back to the rest of the universe.

In game terms, each player assumes a sub-set of the Great Force (here, “Dios Primin”) known

as the “Colors” and are identified by a color (red, blue, green, yellow). The Standard Victory

Condition for each game scenario is then assumed to be the goal of achieving absolute control

of the galaxy. The victor in this case would then be able to – as a choice - reconnect the Milky

Way galaxy (here, “Spermanova Lucifix” or “The Solidness”) to the rest of the universe (here,

“The Eventine”) according to a common ideology (“metameme”).

The only thing preventing them would then be the multi-forking time hysteresis loop known as the “Codon Barrier” put in place by the Dios Primin which prevents all information from escaping back into a single time stream (hence “even tine” – a single tine of a fork utensil). In story terms, this is handled by the having the Lesser Magellenic Cloud (here, “The Visitor”)[3] interrupt the Codon Barrier and thereby provide an escape route for information (“codons”) from our galaxy to the next and beyond.

Barbarians Suns then is a game about the personification of the natural forces and events

surrounding this galaxy and the beings within.

Footnotes:

[1] These are all military vessels ranging from the smallest and fastest to the largest and slowest in this order; Frigate, Destroyer, Cruiser, Dreadnaught, Deathmoon.

[2] These are build centers which allow construction of military vessels.
[3] I now think that a better choice would be the Sagittarius Dwarf Galaxy.
[4] This was before the arrival of a game which did something similar named Twilight Imperium.

Superhero 2044 Second Edition Revised :: Combat System

OVERVIEW

Old School

At the time of its first publishing in 1977, Superhero 2044 originally had four different combat systems; Transformation, Mental Combat, Direct Physical Combat ("melee") and Range Combat.  These used a D6 for resolution, and for "melee" and "range combat" involved the use of a D6 for hit-location. The "range combat" was not an opposed die roll, the "mental combat" mimicked "melee" but used Mentality stat ("Prime Requisite") instead of Stamina.

The second edition rules introduced two new ways of combat; using a D100 for "melee" and "range combat", and then a D100 for hit-location.

SH2044SER

I have decided to make everything more consistent.

There are still four combat systems, but they all hinge upon the use of the "Universal Mechanism" which is a D10 roll against a target number (usually 6 or higher) written as D10=6+. Effectively these rolls are all "Saving throws" and received dice modifier (DM) adjustments against the target number (TN) according to a Simplified Score representing a +1 per every 5 Prime Requisite value above a value of 20. For example, a 20 PR gives a DM +0 but a score of 30 gives DM +2.

Of course, the Referee will have access to a slew of sensible dice modifiers for success such as DM -3 if target is behind cover or DM +2 if shooter is focussing effort on an attack.

OPPOSED vs. UNOPPOSED

Overview

The primary feature of the combat resolution mechanic is that it has an accuracy roll which is always an opposed check. What this means is that each character, the Attacker and the Defender, make a D10 roll. The Defender's roll comes first and, after applying any modifiers, becomes the Target Number for the Attacker.

The Attacker then rolls its D10 against that TN for success. The Attacker of course gets its own set of DMs to adjust its roll. 

The Referee will note the Margin-of-Success [MoS] or Margin-of-Failure [MoF] and this affects the outcome of damage. Should the Attacker roll higher than the Defender's TN, the MoS will adjust the amount of the effect of the attack. 

Handling Damage

Damage from all attacks automatically cause damage; there is no Opposed damage roll. 

For example, a Psychic Blast 10 will do 10 Damage to the target character's Psyche; causing Stress damage. An average character could take about 4 of those blasts directly. Each MoS will allow an additional D6 of damage.

Hit Location

However, for "melee" and "range combat" actions; the Attacker will need to check the hit-location of the target using a D10, with "0" being the target character's head and "9" being the target character's "left-leg". If this is a "range combat" attack and the target was behind cover, a D6 is used instead which allows hit-locations to cluster around the target's upper body.

Standard Hit-Locations

Body Points

Each of the ten Hit-Locations on a target will have an amount of Body Points equal to that character's Vigor. This is standard in the original SH2044 rules. When the number of Body Points is reduced, this will affect the capabilities of a character. Having negative Body Points for the Head will kill a character, while having reduced Body Points for an Arm will make it less useful in lifting things or for using it to attack others.

Physical Damage

Depending on the Body Part hit by the attack, the Defender character may take more or less damage. Physical Damage is always Body Points (express as VIG or Vigor loss) and an accompanying amount of Pain (resulting in Fatigue loss).

For example, a Sword will automatically do an amount of damage equal to the Attacker's Vigor. So a VIG 20 character will cause 20 VIG loss against a target. Should the Hit-Location be the Defender's left leg ("Leg, Left"); that automatically loses 20 Body Points. Swords themselves have the "Cleave" keyword which would remove the target's leg from its body.

Armor

20 Body Points is a tremendous amount of Damage!

This is where protective armor gets to help the targets of physical attacks. At its most basic, armor is ablative; it will stop all damage less than its Armor Value. Therefore, AV 20 will stop 20 Damage. These AV20 could be Psychic Shielding which protects from Psychic Blasts, or Physical Armor which protects from "melee" and "range combat" attacks.

However, all is not so simple.

Physical Armor rated at AV 20 is fairly heavy armor especially if it were to cover the entire body. A mere Bulletproof Vest will cover just the "Torso, Chest"+ "Torso, Middle". A Bulletproof Jacket will cover as a vest plus the Arms, etc. When those 20 Damage come down to the Defender, the Hit-Location could be protected by Armor ... or not. That D10 Hit-Location roll then becomes critical.

Armor Values

Armor Values have a degree of effectiveness. This can be overlooked when attacking Minor Characters (being "Minor NPCs", "Minions", and "Mooks"), but becomes important for Major NPCs and all Player Characters (PCs).  

• If the VIG damage is greater than the Armor Value [AV] by more than 5 then full damage goes to the target location.
• If the VIG damage is less than or equal to the Armor Value [AV], then the armor stops it completely.
• Otherwise divide the VIG damage by 2 and apply to the target.

Those three simple conditions make armor behave a bit more realistically against very powerful attacks by allow them to ignore lesser armor completely. Therefore Leather Armor (AV 5) would stop most punches, but shouldn't do a thing to affect damage from bullets and swords.

This scales up as well. Tank armor with AV 100 should ignore all Damage 100 and below. Damage 107 should not become 7 Damage after applying armor protection; it becomes fully 107 Damage.

As a result, players will be able to fully appreciate the benefits of armor and the deadliness of high-Damage weapons. This should encourage all characters within the game to avoid combat unless adequately prepared.

ADDITIONAL DETAILS

These are the bitter details used for when tracking Major NPCs and all Player-characters. The Referee is encouraged to ignore such rules as necessary ("wing it") in regards to lesser NPCs.

Body Points

All characters have an amount of Body Points for each Body Part location based upon their Vigor and their Mass (in kilograms). This comes to about 20 Body Points for the average adult human male. It could go much higher for characters like Marvel's The Hulk (1000 Kg and very strong ... high Vigor). Vigor is used within SH2044SER as the equivalent of "Strength"; physical power.

Stress

A character receives roughly 50 points at Ego 20, 100 at Ego 40, etc. Doubles every +20 value in Ego. Is reduced by Mental attacks, some Magic / Transformation Attacks, and by attacks involving a high amount of Pain such as from Bombs and Fire. Having little or negative Stress start curling up into a ball and crying, or run away from combat or the source of Stress Damage.

Fatigue

A character receives roughly 50 points at Endurance 20, 100 at Endurance 40, etc. Doubles every +20 value in Endurance. Is reduced by damage which causes Pain, and actions which cause actual fatigue. Radiation damage, doesn't cause (immediate) Pain, but a Punch in the face does. So does Fire (until the nerve endings are destroyed). Torture causes Pain but not necessarily Body Points. Having little or negative Fatigue puts a character into a coma; drained of energy. Characters which take large losses of Fatigue as a result of Pain become Stunned and may eventually pass out from exhaustion or curl into fetal position to try to avoid participation in combat.

Variable Damage by Hit-Location

I'm hoping the image above shows enough legible information. Basically, kicking somebody in the groin ("Torso, Groin") should cause more Pain than normal. And punching somebody in the bony chest ("Torso, Chest, Center") should cause less Vigor damage and Pain. Weapons and the method of attack will of course change all of this. A sword could slice through the thin bones of most humans, and an attack involving acid or fire would certainly cause additional Pain damage.

NPC Types

There's some lore I'm building out for the NPC Types (see here for the foo-foo).

There's tiers of NPCs ("non-player characters"). In the parlance of the rules for SH2044SER these tiers are, Major NPC, Minor NPC, Minions, Mooks, Cast of Thousands.  The tier system is an mnemonic aide to the Referee as to how much an impact to the game each NPC of a given tier could affect change. NPCs of lower tiers (Mooks and Cast of Thousands) would get promoted slowly upwards until they become Major NPCs. In game-terms they'll have more care given to their presentation and details as the Referee sees fit, but they shouldn't swing actively through their tiers during the course of a single session (a "scene") and should probably await completion of a campaign arc (an "story") before switching tiers.

• Major NPCs - Here to annoy and plague player-characters. Nemesis. Arch-villains. Rival heroes.
• Minor NPCs - Side-kicks and second-in-commands to Major NPCs. Love interests, kid-brothers, etc.
• Minions    - All of the bothersome NPCs encountered during gaming sessions which are useful during Handicapping Scenarios.
• Mooks      - A variety of Minions meant to be SH2044SER equivalent of Star Trek's "Red Shirts". They'll not even have a name.
• Cast of Thousands - If the Referee ever needs to blow up a building full of innocent bystanders, or maybe need to nuke a city ... these are they! A footnote in the history books.

Game Design - State Space

NOTE: This is a cross-post from an entry I made at Delta Vector within the game-design forums.

In Regards to State Space

When designing a game I think there are several realms of concern in regards to state space, that abstract realm where information is kept for use by players in order to make wise decisions during a game.  These realms of concern are public vs. private information, presentation, state complexity, and hidden dependencies.

Public vs. Private Information

These are two different ways for presenting state information.

1. Public - Information that is public is displayed for all to see. This usually is information readily apparent to all players and typically presented between the each of them upon a game board or playing field. Public information is often made known with tokens or markers upon a track or made proximate to the physical thing to which is modifies or signifies. Ease of play is a feature of public information because what a player needs to know is visible before them.
2. Private - Information that is private is recorded for a single player to see; the one controlling the recording. This information usually is logged and is only available upon request to other players. There's some mechanical advantage here as well; a private ledger can keep track of a lot of information.
   
   As a result of the information being private, to request a value is a "slow mechanic" which makes a game take longer to play. because a communication sequence must be pursued.
   
   You can imagine this silly exchange between two players;
   
   [ Jim ] What is the status of your knight, is he wounded?
   [ Rob ] Yep.
   [ Jim ] How about on fire. Is he on fire?
   [ Rob ] Yep.
   [ Jim ] Charmed or not?
   [ Rob ] Not charmed.
   
   etc. essentially the players in the above exchange are doing some variation of Go Fish!

State Representation

State representation are common ways to show, typically, public information in some ubiquitous manner.

1. Presuming that a game design is a tactical boardgame, the one common bit of state information is the position upon a field of play. 
2. Some games allow a figurine to face forwards or backwards; their orientation informs others when a model becomes vulnerable to a bonus "stab-in-the-back" attack.
   
   -- Games like Strange Aeons allow models to face up or face down to show Knocked-out or Out-of-Action. Presuming they have a facing [ if they aren't Flying Polyps  ].
   -- Many games show status like "on fire" with strips of wool.
   -- Or, in Blackpowder; the rules use white cotton ball "puffs" to show that a model has fired its weapon.
   
3. In mostly boardgame designs, public information is shown upon tables or charts with tokens.
   
   -- In Advanced Civilization there exists the time track showing where a player's civilization is in position to another.
   -- In many heavy Euro-style games where each player presents a tracking board for their resources. Like in Power Grid.
   -- At the minimum there would be a victory point track.
   
4. In card games, the cards themselves become public information when played. They'll serve multiple state fields; as assets, as resources, as terrain, and as modifiers.

State Complexity

This is a combinatoric feature of a game design. The more discrete states there are, the more combinations there can be.

1. This is where, for me, a game becomes interesting because it allows opportunities for players to manage the "state space".
2. However, by having too many statuses, the game can become slower because the state space - the total matrix of state combinations - grows very large. This usually requires more time to think things out and for people who experience "analysis paralysis" this will cause them to utilize deeper mini-max optimization.
3. One thing which helps flatten the time to analyze state is the commonality of representation. A game board, especially a simple grid or open field with easily recognizable "terrain" is much simpler to parse by our ability to do visual pattern recognition. So though a battlefield for a tactical game is large, we don't usually think that it makes a game any more complex. Same goes with the orientation of a model, its facing, or whether it "on fire" or "has fired".
4. Other things are harder to parse, even when the presentation is clear and public. Such as weapon reach of 1-inch or 2.5-cm from the center of a model, or yaw and pitch or whether a model is flying at 4-Altitude or 5-Altitude without resorting to gimbaled telescoping flight stands.
5. Regardless, the more state the more interesting combinations there can be. "KO'd", "Fired", "Done", "Sprinted", "Hidden", "Facing", "Position", "Panicked". You can imagine the combinations here and how game play could change dramatically.
6. And with each state, there could be rules to manage those states. But too many states and then the game gets too complex to play quickly or to play at all.

Hidden Dependencies

Hidden dependencies are things that make the game operate as intended but are not declared explicitly with a rules set.

1. In well written rules for boardgames, there will be an inventory of all game assets similar to this list;
   
   -- 1 x battlefield
   -- 4 x dice "red", "yellow", "blue", and "green".
   -- 120 x models each with its own stat card.
   -- 32 x status tokens for "on fire", "hidden", and "panicked".
   
   Having something like that at the preface of a rules set is very nice. Maybe the rules might include something like this as well;
   
   "this game include 32 copies of a private ledger for recording and tracking campaign game progress. You are free to photocopy for your own non-commercial use".
   
2. What I see in tabletop miniatures games is usually something different. Typically there is nothing like an inventory at the start of the game rules. I think part of it is that the nature of the genre allows for some flexibility on which available models there could exist for play in the game, as well as what sorts of battlefield terrain such as buildings, trees, and hills could be available.
   
   However, it would be nice if I could see something like:
   
   "This game requires a minimum of 4 models per player, 8 pieces of terrain representing hills, trees, or buildings, and 10 six-sided dice."
   
3. Another category of hidden dependency is status tracking. It may not be until later in a particular set of rules I might read and discover that I need to somehow identify a model as a "Big Man" or that I have to track that a machine gun is "Out-of-Ammo" or that a unit is "Routed" or that a squad is "Suppressed".
   
   These are all interesting state complexity values with their own rules and I like it, but I'd prefer to have such things made known at the front of the game rules.

The Ledger

Lastly is the ledger, or commonly known as the record sheet. Some games just identify this is as "the log".

1. Games like Warmachine have explicitly available datacards for private information tracking which have stat lines, model-assigned-rules, and then a suite of checkboxes to mark damage received. These in principle I have no problem with regardless of how fiddly such a feature is because they are made known as a game feature within the rules by their very presence.
2. However, many games in order to reduce publicly represented state information clutter move that information into private control and management. This is a reasonable trade-off but what will happen is that the tracking of that information is often implicit (maybe through omission, maybe through intent) and also declared (if at all) late into the rules set.
   
   Or not; sometimes it seems that it is up to the consumer of the rules to decide and I think this is bad practice and also makes it harder to learn a game.
   
3. For example, a model might have 5 weapons each of which could be in these states;
   
   -- "Nothing changed",
   -- "Destroyed", or
   -- "Out-of-Ammo".
   
   For a single model, that is something like 0 to 10 statuses to track just for its weapons Where to display this information? Publicly? Nope, on a ledger. But for some games there is no ledger provided by the rules or indicated by the phrasing of the rules.

Trade-offs

I think that to limit a game design to some arbitrary fixed number of states active or otherwise is a designer's choice. There are always trade-offs.

1. Many games, card games especially, and in particular Magic: The Gathering; have dozens of states categorized into a dozen state fields with each field being something like "in hand", "discards", "in play", etc. 
2. The multiplier as a result of all these combinations can create humongous state spaces which are time-consuming to search through.  If players were to compartmentalize these using some sort of heuristic strategy for visiting and analyzing, then the game becomes manageable.
   
   So, for example, M:tG has this thing called The Layer System which groups states into categories of effects. Each category then groups state modifiers within them.
   
3. Something I think is already understood by most players if not most designers is that complexity (and time to resolve) increases with the number of players involved and the number of assets involved. It'd be nice to have a deeply intricate game allow inclusion of a third or fourth player, but it probably is too complex to resolve quickly.
4. The more assets (units, models, figures) which are in play also is a state field and also increases the complexity of the game. Imagine a game between two "flying battleships", each with detail on the level of Starfleet Battles.
   
   It might take 1 hour. Imagine such a game with 16 such vessels in play ... the game might take 1 hour or more likely ... ? 6 hours?  Take that an then divide those 20 ships across 10 players instead of two players; the game will definitely take longer because of at least two additional factors; transition of flow between more players is a friction because it is a physical/social mechanism.
   
   And the last is that the search space is larger since each player - were they computers or persons with "analysis paralysis" - would want to optimize their moves they'd have to regard additional combination.
   
   BTW, I did this last thing; 16 ships and 10 players using all of the Starfleet Battles rules we knew at the time. It took 6 hours. I think in SFB circles, this is a "medium length" game session. =)
   
5. I presume that game designers would want to have a sense of how much time they would want a standard game session to last. At that point, they scale down (or scale up) the available complexity in their design. Then they'd do some math regarding available assets and divide.
   
   For example, I'd rather that a game take at most 90 minutes per session for 5-11 units each player or about 16 units in total for all players. I'd want to have at least 5 player Turns each (5 Rounds), and so this would be 90 minutes divided by 5 Rounds is 16 minutes per round. Divided by 16 units means an average processing time of 1 minute per asset. That's about 8 minutes per player.
   
   Therefore if I can get move + combat down to that average per asset, then my design is as I have intended. If resolution time runs slower, then I need to trim my state space and reduce complexity by removing some statuses. If not, then I shouldn't be too surprised that it takes 6 hours.
   
6. If I were to want to make that Starfleet Battles game as fast as 90 minutes to resolve, then I'd need to remove or simplify lots of the features. I'd probably start by reducing the impulse chart from 32-impulses down to 8-impulse. Then the energy record sheet would need to be simplified. Then the Damage Allocation Chart would need to be simplified. Then the number of tactical options (HET, Wild Weasel, Transporter bombs, Boarding Parties, etc) would need to be trimmed. Etc.
   
   There's a lot of cruft to remove! It'd be a different game afterwards and maybe would require being given a new name, like "Starfleet Commander" or "Federation Border" or something.