Recycling Chessboards

Wargaming Miscellany has a really cool article on chessboard games. Turns out one of the oldest, most free wargames we have has a presence for slightly less abstracted games.

Posted in Wargames | Leave a comment

Productifying a Game, part 1

A set of wargame rules is software that uses the human mind, but it’s important to recognize that a wargame is also a product. When we talk about a game, we generally talk about its rules, its structure, how it’s made. But the rules of Monopoly don’t mention that inside the box is a little metal Scotty Dog that you like to use as your piece, or that there are annual worldwide Monopoly championships. They don’t include the relationship you may have built up with the game after playing it with your parents as a kid. The rules themselves don’t even cover the box art or bright paper money. And if you look deeply at the rules you’ll find that they have nothing ostensibly to do with real estate – if you ask another human being, though, Monopoly has everything to do with American culture.

All of these extras that contribute to the identity and fun of the game well outside of the rulebook are part of the productization of the game: The packaging, the design of components other than the rules, thematic elements, the cultural associations with a game, the history of its play, the metagame (ecosystem of strategies, tactics, and procedures) surrounding it, the delivery system (off the shelf, downloaded via an app store, handcrafted, taught on road trips, played at Grateful Dead concerts), and everything else that exists in the space between rules and users.

Posted in Open Source Gaming | Leave a comment

BWS (2012) – Conflict Resolution

I have been tiptoeing around conflict resolution long enough. In my design notes, I’ve gone through many iterations so far trying to come up with just that right feel. Here is how I want it to work in a narrative sense: Some units are in a Zone from both sides. The forces have been building and the tension has escalated and there is a battle. Unlike most wargames, units do not battle each turn unless Command Points are spent to ignite a conflict. Then, both sides roll a bunch of dice and interpret the results.

That’s the idea, anyway, but how to get there?

Zombie Dice
There’s this little game from Steve Jackson Games called “Zombie Dice“. It’s a simple affair: You roll 3 custom dice which have feet, brains or a blast on them. It’s a press your luck game and you want to get as many brains in your turn as possible without getting 3 blasts, because if you get 3 blasts you lose all points that turn. My kids and I play a few games of this a week, usually as a warm up to play something more interesting. What’s interesting about this game is the emergent narrative each time you roll the dice. You can almost hear the people running away screaming when you roll “feet”. Zombies are dropping when you see “blasts”. And some helpless civilian is going down to a zombie mob when you see “brains”. Just a simple roll of 3 dice can bring so much story! You throw the dice and then you can narratively interpret what happened.

I want something similar to this as the conflict resolution for BWS. When the tension has peaked, one player will spark a battle and then both players roll dice and interpret the results. Unlike Zombie Dice, we have a bit more complex world to deal with, so it requires a good bit of design to make it work.

One aspect I like in games is having to make tough decisions. So, the conflict rules should incorporate that. When you roll your dice during a conflict, all 4+ rolls are considered a success. You use these successes to perform conflict actions: attack, defend, move or skill-based. An attack obviously damages the enemy, however a successful defend action would soak that damage. A move action could be used by a unit to flee the combat and a skill-based action would be based on one of the skill mods.

So, I imagine each unit has an index card (or tracked on a single sheet) and you put your successful dice in the quadrant that you want to spend it in (move, skill, attack, defense). Once both players have assigned all dice (alternating placement to allow for reaction to each other) then the conflict is interpreted. This is where I see the narrative coming in as the players tell the story of what happened.

[EDIT: I just realized that I made a mistake in my image. The troop value should be 6. That’s one for the name of the troop and 5 for the mods that have been added. Sheesh…]

How does the conflict start?

Each side has 5 Command Points (CP) to spend each turn. These are like Action Points in the original BWS, but are also spent for things other than unit actions. One of the things you can spend your CP on is to start a battle in a Zone. The cost is higher (3 CP), but it also gives you a small advantage to be the one to start it (an extra die roll).

How many dice does each side roll?

This is the math/mechanics bit that always trips me up, so I would love some input, innovative thoughts or just brutal criticism on this. Here’s what I’m thinking:

[NOTE: all dice are D6…this might change later to allow more dice types, but for clarity, we’ll keep it simple right now.]

  • You get one die if you started the battle (ignited the conflict).
  • You get 1 die for each unit involved in the conflict. These would be any units in the Zone that the conflict was started in and any unit in another zone that can participate (with further range weapons, etc).
  • You also count up the all the troop values (just count the number of Mods plus the Name of the troop for this number) and divide by 6 (round down) for extra dice you can roll. This gives an advantage to the stronger side, but nothing overwhelming. This is where I’m thinking about allowing the other size dice and you buy different sized dice with the troop values (ex. 8 points could buy two 4-sided dice or one 8-sided die).

I think this is the feel I am going for. Now I just need to go through a bunch of conflict scenarios and playtest to see what falls out of this scope. I’ll refer back to John’s article on playtesting to make sure this is usable by new and veteran gamers alike. I want it to be simple to understand but with complex strategies.

Posted in Open Source Gaming, Wargames | Tagged , | 1 Comment

Different Types of Game Testing

When you’re launching a new soft product, whether it’s a game, an app, or a rulebook, you want to hit along multiple axes – especially if you want your product to get market penetration. This applies maybe double to wargames and RPGs. The planes may well be:

  1. The Novice. How does a person who has no field knowledge of you or your competitors fare? Are they able to figure the whole thing out? Are the casual users getting it, or just those destined to work their way in? Do they have any clue how to begin playing?
  2. The Seasoned User. How does someone who knows the field react? Does a Warhammer player see Hordes and immediately walk away, because their miniatures aren’t valid in the long term? Are they sold on the benefits of your product?
  3. The Expert. How does an experienced user react? Do they gawk at the repetition of your game, or do they notice and appreciate the new twist you’ve provided? Are you making depth, and are you making that depth noticable?

It’s tough to design anything for all three groups, but some organizations manage to focus on one and let the others trickle in. Apple focuses on the novice, and Adobe focuses on the expert. The other users tend to slide in.

Since “Games are software for the human brain”, who does what here? Chess doesn’t market itself at all. Connect Four has marketed itself to Novices alone, and Settlers makes millions off of expansions for Experts.

Posted in Wargames | Leave a comment

BWS (2012) – Units and Mods

Looking back in the Building Blocks post, I defined the following:

Unit: Any active participant in the battle. Can represent a squad of soldiers, a single hero, a vehicle or really anything else, depending on the Scope and Scale of the battle.

A Unit is an abstract representation of a force on the battlefield. It is completely unimportant that a Unit be represented by a single miniature on the table. In fact, I typically visualize a single unit as only part of the battle. A focus for the action, while other undefined units are fighting. Consider a movie where you see only one squad, but you hear gunfire off camera and catch out of focus glimpses of the rest of the army. You know that the single focused squad is part of something bigger.

To represent this on the tabletop, I encourage you to use many more miniatures. Move these around on the tabletop, not under any rules mechanics, but what looks cool. They do not affect the battle, but rather provide more immersion for the battle you are playing out. We will mark the Units that are in play with a counter and those must be acted on by the rules, but the other models are freeform play. Play like a kid! Or…if that’s too hard, set up the extra models in such a way that would look good in a picture (and then take pictures!).

Units are defined with Command Points (CP). If you spend 1 CP, you may create a new unit in your deployment zone. You can call this unit anything you like: a type of troop (Space Marine), a name (Captain Sellers), a vehicle (M1 Abrams). Give it some color and put a model or models to represent this on the table in your deployment Zone.

All new Units start with the same base rules:

  1. A Unit can move from one Zone to an adjacent Zone using a Move Action (1 CP).
  2. A Unit can attack enemy units that occupy the same Zone (This is a Combat action that costs 3 CP).
  3. Can take one wound from combat before being removed from the battle.

This is pretty generic and and boring, so that is why we have Mods. Mods cover everything else that defines the unit, including training, strength, weapons, skills, and anything else that makes them individual. For each CP you spend during your turn, you can either add a new Unit or you can Mod an existing unit.

The original BWS (and many other games) take weapons and skills and attempt to balance them with point costs. A pistol might cost half as much as a rifle and does half as much damage, or something along those lines. This game is abstract to the point of not balancing such things. It is assumed that all new units have some sort of firearm or weapon that can attack targets in the same zone.

Mods break those simple base unit rules above by allowing them to shoot further, fight harder, move faster, and perform skill-based actions. That power of creativity and improvisation during the game comes at a price. When a new Mod is added, all players must agree to the effects of the Mod to make sure it is not too powerful. Players also must understand that when a Mod is accepted, all players can use that same Mod or something similar for their own units. This kind of play necessitates a mature outlook on game play, but once all players buy in, the results can be so much fun!

The only rules to adding a Mod to a Unit are:

  1. All players must agree.
  2. The Mod can only alter one thing (ex. no Mod could increase movement speed and fighting strength at the same time).
  3. Each Mod you add to a Unit gives that Unit one more wound they can take in Combat. You see, each Mod you add to a unit, makes it that much more powerful, but when they take a hit they begin to lose the Mods as well.

The third point is important to the narrative of the game. As an example, we create a Unit called “Sniper” with 1 CP. This is just a base unit that follows the base unit rules. We spend 1 CP to add a Mod to the Unit: “Ghillie Suit – Unit is hidden from the enemy if he does not take an action”. Later we spend one more CP on the same Unit to add another Mod: “Sniper Rifle – Unit can attack into one additional adjacent Zone.”

Now, this Unit might be designated as such:

+ Ghillie Suit
+ Sniper Rifle

It has 3 wounds as well. The initial wound you get when you “buy” the Unit (which I associate with the name of the unit), and the 2 Wounds from the Mods. Let’s say this unit is in a Zone that has a combat and he takes one Wound. The player who controls the Unit chooses where to take the Wound. He can scratch off the Ghillie Suit or the Sniper Rifle, but whichever one he crosses out, it’s rules are no longer in play. The very last Wound a Unit can take is to it’s name and that takes the Unit out of the battle. In the narrative of the game, this might represent a weapon failure, a frightened or ineffective soldier or even just a wound.

Any kind of Mod can be added to a Unit that makes sense within the context of the game. “Flying” might not work in a modern ops type game, but would be more than welcome in a Superhero themed scenario. I cannot overstate the importance of agreement of the players on what works and what does not within the scope of the scenario being played.

Some examples of what a Mod can do for a Unit:

  1. Move faster. Instead of moving one Unit per move action, for each Mod they could move two Zones.
  2. Move through rough terrain. Some Zone Mods might make a Zone difficult to pass through, but this Mod would allow a Unit to ignore that.
  3. Move stealthy through a Zone. As long as they don’t attack, the Unit cannot be targeted.
  4. Attack an additional adjacent Zone.
  5. Attack with an extra die (a more powerful attack).
  6. Defend with an extra die.
  7. Take more wounds (like armor or dodging).
  8. Heal a friend unit of one wound (Medic or Healer)
  9. Other special skills: camouflage, climb, hacking, communications, engineer, etc.

These are just suggestions, as I am sure that you can come up with some really cool Mods for Units in your game. When I release these rules to the public, I intend to give many examples.

Also note that the Mods can stack. In our Sniper Unit example, perhaps we spend a CP to give the Unit “Eagle eyed – Add an additional adjacent Zone that can be targeted”. Now this guy can shoot two adjacent Zones away with his Sniper Rifle and Eagle Eyed Mods.

Homework: What other kinds of Mods can you think of that would be interesting to Model on a Unit? Post to the comments below.

Posted in Open Source Gaming, Wargames | Tagged , | 2 Comments

Bonedaddy from a Player’s Perspective

I’ve been following Erik Battle’s Bonedaddy updates since, well, the 90’s, and BWS was a wargame I cut my teeth on. I liked the playability, narrative, and customization, which I much preferred to commercial games at the time.

So far, as I anticipate it, Erik’s Bonedaddy 2012 system sounds like it harkens to elements of Clue, Squad Leader, and 3:16 Carnage Amongst the Stars. I have no way of knowing if it will be like any of these, but in my defense, new games are well described in terms of mechanics borrowed from existing games.

Clue: Also called Cluedo, the game consists of players moving around of free will from location to location. This reminds me a lot of Erik’s concept of Zones in BWS. Instead of worrying about how many inches my soldiers move, I can allocate troops or squads to adjacent zones, interacting with other players and accomplishing objectives.

Squad Leader: Along with Advanced Squad Leader, this game is a classic of wargames. Each unit has an inherent list of actions to choose from, and substantial modifiers to each. Although it feels freeform, the bonuses and penalties to each action for each unit compel players to use units carefully.

316 Carnage Amongst the Stars: Departing from the normal paradigm of U Go/I Go turns, this system introduced a simpler set of command based die rolls, unintentional or uninformed movement, narrativist roleplaying, and was in general an interesting tactical system. In reading Erik’s design notes I keep thinking he’s shooting for similar goals.

Posted in Open Source Gaming | Leave a comment

BWS (2012) – Command Points and “Act Of Valor”

Command Points

In the original BWS, I used Action Points as the mechanic to give motion to your units. You started off with 10 AP per unit and you spent these in your turn to move, shoot and perform other skilled actions (ex. set and detonate an explosive charge). This provides precise control over your units, but it also slows the game down and makes for lots of mostly meaningless decisions.

For the redesign, I want to broaden the scope of these points to something I’m initially calling Command Points. I like this terminology because it implies that you are commanding the troops yourself. You should feel like you are in the game as well, watching your troops die as you make bad decisions.

Command Points will include actions that your units can perform, but also will be used to control other parts of the game. For example, command points can be spent to regain initiative in a bidding manner. They are also used to “buy” new units, “mod” existing units, and to start battles. Each player will have 5 CPs to spend during their turn on any of the following actions:

+ Move a unit from one Zone to an adjacent Zone (1 CP)
+ Use a unit skill in a Zone (1 CP…maybe this depends on the level of difficulty and the skill being performed)
+ Create a new unit in your deployment Zone (1 CP)
+ Add a mod to an existing unit (1 CP)
+ Add a mod to an existing Zone (1 CP)
+ Create a new Zone (3 CP)
+ Start a battle in a Zone (3 CP)

We’ve already talked some about unit movement and we’ll talk about the others in future blog entries. There are some design challenges to be overcome with using Command Points this way, but I think it will give the kind of kinetic action I want to portray on the battlefield.

“Act Of Valor”

I saw “Act Of Valor” at the movies yesterday and think it has a lot to offer on the BWS design. I’m not a movie reviewer, but I’ll go so far as to say this is not a great movie, but the action scenes are some of the best I have ever seen. The acting and dialog was really poor though and found myself just waiting for the next conflict. Luckily for me, these came pretty quickly. That’s all I’ll say about the quality of the movie in this blog.

Man, but those action scenes were intense! Similar to the post about the action scene in “REAMDE” where I broke it down to see what would help my game design, I want to do the same with the first action scene in this movie.

We have a hostage rescue for the Navy SEAL teams as the first real extended action scene. The SEAL objective is to rescue the hostage and get to the extraction point. The terrorist objective is to extract some information from the hostage. They are unaware that the SEALs are coming, but their camp is well guarded.

A SEAL team paradrops into their deployment zone about 4km from the enemy. They march quietly to within view of the camp and do recon to confirm the threat. The team breaks up into smaller groups. The leader and sniper form one unit a good distance away from the camp. From there, they can direct the others on the move and the sniper is in a good position to fire.

The other team sneaks across a river to the camp in that really freaky/cool way that SEALs do (emerging silently like ghosts from still water). Things go a little sideways of the plan as they are trying to wait for confirmation on their extract team, but hear a scream inside the hostile camp. So, they step up the assault sooner than they planned.

The enemy are still unaware as the assault begins and the SEAL team takes out a few of the outside hostiles before the enemy are alerted of their presence. The sniper takes out most of the outside forces on the perimeter before the assault team enters the camp, but he cannot help other than to cover the outside while they are inside. The sniper takes care of any enemy that comes out of the compound.

The assault team takes over, entering the camp and going from building to building. This is standard room to room clearing tactics. They find the hostage and take out most of the enemy. Then they are hard pressed to escape as hostile reinforcements are sighting coming in fast.

Next comes a long chase where the SEALs are being persued by the hostiles in trucks. This is not interesting in an of itself, really, but what is neat is that the SEALs keep missing their extract zones. Their extract is two assault boats coming down the river for them to take them out of the hot zone. The boats and the trucks are trying to meet up, but the enemy pursuit is hampering this activity.

Finally, in this amazing cool scene, the truck and boats meet up (I really won’t give anything here…you just have to watch it, it’s a fantastic scene) and fire a lot of high-calibre rounds at the enemy. The boats take off with the SEALs for an overall victory.

That’s a very simple overview of the action, but hits the points I want to cover in terms of game design.

Awareness – Again we have awareness as an important element. The SEALs are trying to stay undetected for as long as possible. If they are careful, they can be unseen for a long time, but there is a chance that something bad will happen (like maybe they rolled a “1” and made a sound that gave them away) or when they open up firing they will definitely be heard. In the game design, we will have units able to sneak into a zone and remain undetected until they shoot or do something to reveal themselves. A unit that is unaware will always have a disadvantage.

Improvisation – There are moments where the squad leader (portrayed by you in this game) has to improvise. Even with all the planning, things go askew during battle. While following a path, a new path opens to the side and they might decide to take that one. It was not shown before it was needed, but when noticed a split second decision takes the team on the new path.

In game terms, this is what I am trying to do with “mods” to units and Zones, and also by allowing new zones to be created. Say that you have units in one zone and are trying to get to the other side of the battlefield. Lots of enemy sit in the next adjacent zone between you and your objective. Maybe you spend 3 CP to create a new Zone, something just now noticed, but one that makes sense in terms of the field of battle. You might create a Zone called “sewers” going from one city block to another that cuts out walking through an enemy infested street.

Splitting the squad – We see a large team enter the deployment Zone, but that team breaks down into smaller elements when they assault the enemy. In other wargames, you would define all elements that are in the battle and then take actions (moving and assaulting) with each. With this game you can create one unit which is the larger team and take actions with this unit. When you need to, you can spend a CP or two to split off an element from this group. Now you have two units in the Zone. Further elements can be split off of these as you have points to spend, but with only a limited number of CP and the fact that you need to use them to activate the units, you can only do so much per turn.

Firefights are brutal – I think Act of Valor tried to be as realistic as possible in these firefights. You do not shrug off getting hit by a bullet. Typically an shot which hits either kills or effectively takes the unit out of the battle. I’m not sure if I want combat to be that fatal in this game as it will cause challenges for some of my other design ideas, but it’s something to note. Even the extremely well trained SEALs can be taken out.

Chaos of battle – When soldiers burst into a new room to clear it, there is this moment where they have to take everything in and process. Are there any targets? Are any of the targets friendly? Is there anything I should not shoot (like explosive materials)? For SEALs, this process doesn’t take long, but it’s still a factor. If you are waiting for someone to burst through a door, you just start shooting when they do. If you are the one breaking in, you have to be a bit more careful. Maybe units entering a new zone are at a very slight disadvantage while they process the scene.

Zones – There is not a lot to process from this scene in terms of Zones and how they work except for the chase towards the end. One way to model this is to have multiple Zones (and maybe possible branches) and take actions to move from zone to zone and shoot at each other if you have an CP left to do so. Another way might be to make the chase just one very abstract zone and resolve via conflict rules. I’m not sure about that yet.

Relationships – All of the SEALs are close to each other. That comes from training together and saving each other on the battlefield. They have to trust each other. Two characters in particular are focused on as being close friends. This comes into play in the movie with some of the decisions that each has to make on the battlefield. More than that, it gives the viewer more emotional buy in. You care, just a little bit more if one of those characters dies. I want that kind of emotional buy in. Maybe not every character has a relationship as I don’t want some huge relationship map, but some important characters do. These would be positive and negative relationships with other friendly units (“my best friend”) with enemy units (“my brother is my enemy”) and Zones (“Sergeant was killed here!”). I’m not sure how if and how we will represent this yet, it’s just percolating now.

Timers – Again like “REAMDE”, there are timers. In this action scene we have a timer for the SEALs to rescue the hostage before she is tortured to death or gives up important info. There is also some complex timing going on with the extraction. These timers make the armies have to make decisions on when to react. Timers sometimes cause them to make mistakes. Basically…I love them. Still not sure how we’ll use them yet. Maybe we define some timers initially, allow others to be set via CP and allow the timer itself to be sped up or slowed via other CPs spent.

So, lots to process from “Act Of Valor” and I’ve only discussed the first action scene of the five major “Acts”. Our first playtest to see how everything works so far will use this scene from the movie as it’s basis to test some of the mechanics. This will be ready in a week or so.

Posted in Open Source Gaming | Tagged , | Leave a comment

BWS (2012) – Generic Rules vs Specific Situations

Throughout the design of this game, I switch back and forth between working on generic mechanics versus applying those to specific situations. I want the generic rules to be as clear and complete as possible, yet I constantly think of specific scenarios and how the rules would portray those and if additional modifications would be needed. Ideally, I would like these rules to be able to cover many different conflict scenarios.

Here is an example of this interplay between the generic mechanics and applying a scenario against it:

I’m taking a short scene from the really awesome book I am reading right now (“REAMDE” by Neal Stephensen). Without giving anything away, we have two groups (think armies in the game terms) – Russian Mafia (ex Spetznatz) and Jihadist Terrorists. Let’s say for simplicity’s sake, there are 5 units of each…individual soldiers. The Jihadists are unaware of the presence of the Spetznatz.

The Spetznatz travel up the stairwell to the fifth floor and they knock in the door where the Jihadists are building bombs. The Jihadists are surprised and it takes them a minute to react. Now, a firefight ensues as each takes shots against the other. There’s a bit of different tactics as the Spetnatz drop and roll and then shoot, but the Jihadists are aware of the rooms they are fighting in and use that to their advantage. People on both sides are dying back and forth.

The Jihadists were making bombs, right, so of course that stuff is primed to cause some problems if there is a firefight in the room. Flames start up threatening to blow the explosive materials. The remaining troops on both sides realize this a bit late and now they are trying to leave the room and indeed the building while still shooting at each other.

Some escape down the stairwell and some climb out of the windows in a search for a quicker way out and away from the ticking timebomb. One character tries to cross to another building via a tangle of electrical, phone, internet cables.

So, that’s just a bit of the scene so as not to give too much away (cause you really must read this book!), but has many examples of the type of gameplay I want to model in the new version of BWS, but in the simplest form possible. Here are a few ideas I pull from this example:

Awareness – Groups in a zone can be unaware of the other until a visual or aural clue is given. I would say that if a unit fires on another, that’s definitely going to give them away. If they ran into a Zone, that might also do so. But there should be the ability to cautiously sneak in so that the other side is unaware. Now, having one side start with awareness might be scenario specific or maybe all units start aware, but can use tactics to hide their movement.

Zones and Movement – I’ve already discussed Zones and movement, but this helps give some good examples. We have a zone for the stairwell and it’s harder to travel up than down. We have the hallway of the 5th floor and if the Spetznatz are quiet they can keep the other army from becoming aware. We have the apartment of the Jihadists. You could break this down into individual rooms, but it’s not necessary as the zone itself can be modified to have different cover options and the Jihadists will have an advantage when fighting in the room (after the first surprised turn).

One thing that is interesting is that both armies know about all of those zones to a lesser or greater degree, so you could consider if gaming these, that the Zones were preplanned and set up. However, I envision that the tangle of wires leading from this building to another is not something planned. However, one of the players creates this new zone using an action to allow one of his units to escape. I want this kind of dynamic battlefield where you can almost discover as you go. So, I think we allow players to create new zones and connections between zones as part of their actions by spending a token or more on that.

Timers – When the firefight breaks out in the apartment, of course the bomb making material is going to be a risk. In game terms I would set a chance that the materials will ignite and then give a timer on how long before it blows. I like the idea of timers, but do not want it to become a pain to keep track of.

Environmental Effects – Fire damages units, or at the very least is going to affect their performance and make them want to exit the situation. Explosion definitely is going to damage units. I want Zones to be able to change dynamically in the game. It was a big deal when video games announced “destructible terrain” in their first person shooters and that’s what I want to see with Zones. An explosive blast is really going to have quite an impact to the zone, rendering it dangerous or even making it no longer possible to enter/exit.

So a possible setup of the Zones for the above situation might be:

Zone: Stairwell
Mod: Climb – units going up take 2 turns to move out of this Zone or one turn and are exhausted.

Zone: Hallway
[NOTE: I can’t really find much interesting to say about a hallway, but maybe there’s some tactical advantage that can be taken advantage of]

Zone: Jihadist Apartment
Mod: Jihadists are familiar with rooms and have 1 die advantage when fighting in the apartment.
Mod: Explosive materials. On a failed die roll of 1, the materials ignite and will explode in 1d6 turns.

Zone (new): Wire Rope
Mod: Dangerous – chance to fall while traversing or chance it will just separate from the wall it is attached to.

Taking this specific scenario back to the mechanics of the rules, I have to decide if Awareness and Timers are something I want to add to the generic rules and if they will fit in with other scenarios. I’ll consider different scenarios and see if that makes sense.

Production wise, I have always planned on publishing BWS as a free, open-source game. However, I am also considering taking the generic rules and developing very tight settings, scenarios and campaigns that might be published for a small fee. These would contain more art and lots of development to make a stand alone game. We’ll see if that happens.

Posted in Open Source Gaming | Tagged , | 2 Comments

BWS (2012) – Visualization and Building Blocks

I read an interview with Reinier Knizia a long while back about how he starts to design a game. One of the things he first does is dreams about the game: He just closes his eyes and imagines people playing this new game idea. What are the players doing? Are the players excited or concentrating or laughing? What does the board look like? How are the pieces interacting?

I think this is a fantastic way to begin your design and I’m going to share my internal view of how BWS will be played:

Players decide they want to play a WWII D-Day scenario. Like me, they are more familiar with the Saving Private Ryan version than the actual historic events and they are cool with that. They spend some time setting up a cool looking table: blue felt for the ocean; dragon’s teeth on the beach; a sand dune in the middle of the beach; a cliff with a bunker on it. They only have a few WWII suitable miniatures and they decide that maybe a single miniature represents a whole squad, maybe more.

The players then collaborate to define the zones. The ocean, the dragon’s teeth, the open beach, the sand dune, another open beach, a cliff and the bunker all become defined zones. Then the players start using tokens (perhaps a small battle is 10 such tokens per player) to define their units and give advantages and disadvantages to units and terrain. Maybe like this:

+ German player spends one of his ten army points to define the bunker advantage, which helps his defense.
+ American player spends one point to define the sand dune as a defensive advantage.
+ German player spends one point to define the ocean as treacherous (troops could drown due to heavy gear).
+ American player spends a point to define the bunker as “close combat nightmare for the defenders”. Whichever side (probably the Germans) is on the bunker defending it will get a negative if the enemy is in close combat with them only in that zone.
+ German player spends one point on the dragon’s teeth zone to slow down the movement to the next zone. When the americans try to move from the dragon’s teeth to the sand dune zone, it will take them 2 turns instead of one.
+ American player spends a point on stand of troops. This is a squad.
+ German player spends a point on a stand of troops. This is also a squad.
+ American player spends a point on another stand of troops.
+ German player gives his first stand a heavy machine gun. This shoots further or does more damage. The German player can tag it with either, but each costs a point, so this turn he tags with shoots further. Can shoot 3 zones (bunker -> dragon’s teeth).
+ American spends a point on a leader for stand 1. The leader gives the advantage of the guys not running away (or a less chance of that).
+ German spends a point to modify his HMG to give more damage. Now with both tags, he can shoot 3 zones and do double the damage.
+ American spends a point to put a medic in stand 1…

Each player is kind of playing off each other in the first phase. Trying to get the upper hand or deal with something their opponent does. So, the German player has this one unit that’s heavily entrenched (lots of terrain modifiers bought), with this tough weapon, while the American is going for more squads and some support of them (leaders, medics).

Once they have spent some or most of their tokens, they take turns moving around units between zones acting in combat etc, until one or both sides meets their objectives. There is very little fighting each turn, but instead there is a lot of maneuvering followed by intense firefights in a combat zone.

That’s all vague, of course, so here are some of the building blocks I see needing to make it come alive:

Scope – The agreed on genre and rules of the battle. As BWS is a generic set of rules, discussing and agreeing on the Scope before hand will keep players on the same page. Discuss what you want to include (“I want high-tech ninjas”) and what you don’t (“Let’s agree not to have space elves, ok?”)

Scale – General guideline on what size a unit represents. While my default design parameter is to maintain the scale at skirmish level (one figure = one man), the nature of this design should allow for different size battles (ex. a miniatures stand = one battalion).

Unit – Any active participant in the battle. Can represent a squad of soldiers, a single hero, a vehicle or really anything else, depending on the Scope and Scale of the battle.

Army – All units created by a player belong to their Army.

Zone – An area of battle. Each zone represents a tactical vantage point, and be anything from a city to a small section of road depending again on the Scope and Scale of the battle. Think of a Zone as a movie set where a scene will take place, or in terms of where you would put miniatures if you were taking a photo for a battle report.

Battlefield – All Zones inclusive are considered the Battlefield.

Mod – A change made to a Unit, Army, Zone or Battlefield. A mod is an attribute, skill or some other tactically interesting feature that defines a Unit, Army, Zone or Battlefield. Mods are key to customizing the game to make it interesting.

Action – A “move” taken by a Unit, such as moving to the next Zone, attacking an enemy or healing a friendly unit.

Posted in Open Source Gaming | Tagged , | Leave a comment

BWS (2012) – Movement Without Measure

In my Goals statement, I mentioned I do not like measuring. I find it takes too much time, is often the cause of contention among players and really does not mean much to me as an overall decision process.

As kids, we could move toy soldiers around however we liked, putting them where they looked coolest without bringing out a measuring tape. I would like a return to that mindset. One of the problems with free-form movement is the ensuing arguments at the table. So, I want figures to move from Zone to Zone.

In my original design of BWS, I break down into 1 inch movement bought with Action Points and the cost depends on the type of terrain. This was slow. In practice, we used 1 inch round wooden tokens to measure “steps” of each unit. This worked better, but again, I found there were were only a few points where the movement system became tactically interesting.

Now, I’m going to get more into Zones later as I have some ideas on how I want to implement them, but lets say for now that a Zone is a smallish area on the board that represents a specific type of terrain. The size is insignificant really as it could be an area as small as 3 inches square or 6 inches square. A Zone might represent a ruined area, a hill, an alleyway, or some other tactically interesting point on the board.

Think about painstakingly measure the movement of 20 troops across a four foot table. Most of this is just mechanically boring and the choices are not that important whether you move one inch this way or that. But there are points in your movement where the choice is very important as it can set up a tactical advantage or disadvantage. Those are the points that I want to represent with Zones. Not the 3 turns it took both of us to get our guys to the city street, but rather the city street itself.

As for the number of Zones, it would depend on many things. The time you have to spend, the scenario you are playing, the terrain you have laid out on your board. However, it should not be a great number. Ideally, I think between 7 and 15 Zones would be enough. Playtesting will sort that out, though and maybe will even help give guidance for how to reduce the amount of time a game takes (if, for example, we find that each Zone added tends to add a bit of time to overall play).

For set up, I envision creating your board. Lay down terrain in a way to looks cool (or follows some historic map if you have such reference). Then players work together to define Zones. Look at the terrain you have and decide what would be tactically interesting. A specific building which is important to the scenario could be a zone. A valley between two hills. A dangerous lava pit. Think in terms of movie scenes, or in terms of where you would put figures if you were taking a photo.

Each Zone will get designated. I think this can be done with a few numbered tokens on the board to differentiate between Zones, or you could track on a sheet of paper which Zones you have defined. We are going to get into designing Zones and filling them with interesting features and rules, but for now, it’s enough to just define them all. It might help to create a small map showing how the Zones connect to each other, but I want to use the tokens to show that as well.

So movement will be Zone to Zone. Each turn, units will be able to move from one Zone to any connecting Zone, depending on if there are any rules in play to prohibit their movement. Initially, any unit can take one action to move to any adjacent Zone. Of course, there will be Unit and Zone modifiers that allow faster, slower and other forms of movement.

Example Zone map for a battle at the hotel:
1. Driveway – Attacker deployment zone
2. Fountain – Low cover
3. Lobby – Low cover, innocent civilians
4. Pub – dangerous ground (broken glass), heavy cover
5. Rest Rooms – tight space, water (medic refresh?)
6. Ballroom – slippery floor
7. Restaurant – crowded (slow movement)
8. Elevators (though this is labeled differently on map) – Defender deployment zone. There is a small maintenance walkway between Zone 8 and 6.

Posted in Wargames | Tagged , | Leave a comment