Blog and Forum Pages

Wednesday, March 30, 2011

Smoothing out Activations in Ganesha Games' Games

As anyone who has read my blog for a little while knows, I do like the Song of Blades and Heroes (SoBH) engine put out by Ganesha Games. The Yahoo forum has had a bit of traffic of late talking about scaling up the engine so people can use more toys. Always a good idea.

One thing that Sergio Laliscia did to advance the franchise was, in the Sixty-One Sixty-Five rules, to shift the activation roll from the individual to the squad (about four to ten figures, depending upon options) and having all orders be implied group orders. This allows you to avoid the "roll for the leader, who gives an order to the group, who then rolls..." cycle and reduce it down to one. The leader becomes a part of the group, just as I was advocating in my earlier blog entry (some say "rant") on Flying Lead. (See the first section, "Leaders don't lead, they order people about".) I think that one change is what enamored me to Sixty-One Sixty-Five the most.

So, I was thinking about how to scale this up further. Sergio has been working on Song of Drums and Shakos Large Battles and Drums and Shakos Battalion Level and in an exchange it seems he and I are thinking the same thing: each figure represents more than a single man, but the rules play as if the figure were a single man. This has been a successful model for more than 20 years as The Sword and the Flame (TSATF) uses that same sort of abstraction and, in my opinion, so do the rules in the Warhammer franchise. This blog entry is about activation methods for using units rather than individual men running around separately.

One of the experiments I was pondering was whether you could find a way of smoothing out activations while still retaining the core tactical decision provided by the SoBH engine? First off, what do I mean by "smoothing out activations" and "core tactical decision"?

Currently the activation model is that only side acts until they have completed all units' actions, or fail prematurely. This leads to what Wally Simon used to call "gotcha' gaming". The IGO UGO model allows you to move your units forward into range, strike a blow at the opponent, and eliminate him, all before he can act. This often leads to a game of two people cautiously approaching one another until one side makes a mistake (or gets bored) and the other springs forward and it's "GOTCHA'". To smooth out the model you either give a player some mechanism to interrupt their opponent's action and react to the move before the blow can fall, or you develop a means where the attacker can only spring the trap with limited numbers. Examples of the former method would be the "Overwatch" rule in Flying Lead; examples of the latter would be the card activation method of most Too Fat Lardies (TFL) rules.

The core tactical decision of the SoBH engine has always been the choice of whether to roll 1, 2, or 3 dice to activate, altering your odds of turning over and ending the turn prematurely, leaving you with some units that will not get to move.

A recent discussion on the Yahoo forum surrounded the idea of a new ability that allowed a figure to interrupt an opponent's turn and execute their own actions. As many people pointed out, if the reacting character rolls dice for activation, why would they roll anything other than three dice? Because you are interrupting the opponent, you have no chance of turning over, so there is no risk to you. It was when I read this that I started thinking about how you could try and introduce risk in this situation. Specifically, how could you penalize the interrupting figure if they rolled a turnover?

The simplest method was that if the reacting figure turned over, the player lost their next turn (i.e. the acting player that was interrupted would get to finish their turn and when they turned over, they would immediately start another turn). This would be a powerful incentive not to roll too many dice when reacting. Probably too powerful, as the interrupted player could now start acting recklessly, knowing that they still had another turn before their opponent could act.

Another method is to penalize the interrupting figure by having it forfeit its next turn if it turned over while reacting. This is probably too weak, as the reacting figure should probably not be allowed to act the next turn anyway as it acted out of turn. But simply penalizing it by not being allowed to act is not penalty enough for it not to risk throwing three dice all of the time.

Rather than try and solve that problem, I started thinking about how TFL rules handle activation. Most of their rules have you place one card into a deck for each unit, and usually some additional cards to spice up the action, and finally a 'reshuffle' card that ends the turn prematurely. Thus, the deck drives the order that units act, removing the tactical decision from the player, and denies players the ability to act will all units based on when the reshuffle card appears. TSATF alters this method slightly by using a standard playing card deck and simply designating one side as 'red' and one as 'black', allowing the player to choose which unit to activate next.

So, taking those two ideas in combination - using a card deck to determine which side acts with one unit next and failures carry over to the next turn - you might have an interesting experiment. The idea is to allow each side to react more quickly to enemy events while still presenting consequences for failures in activation. That way you increase the tactical choices a player has to make - which units will act and which will remain in reserve to react - while still penalizing players who take greater risks and fail.

So, take a standard playing card deck and some markers - one for each unit - and play a game of Sixty-One Sixty-Five (or modified rules for Song of Drums and Shakos to account for units) and designate one side as black and one as red. When a side's card is drawn, designate a unit to be activated. Obviously that unit cannot already have been activated that turn, just as with the normal SoBH engine rules. The player has a choice of 1, 2, or 3 activation dice, as normal. If the player does not turn over, and after the unit has completed its actions, place the marker behind the unit, indicating that it has activated for the turn. If the player does turn over, and after the unit has completed its action, if any, place the marker in front of the unit. (For aesthetics you might consider a pile of rocks on a base as the marker.)

When all units on both sides have been activated (have a marker either in front or behind them), perform the following steps:

  1. Remove all markers that are behind units.
  2. Move all markers in front of units to behind the units.
  3. Shuffle the discard pile into the remainder of the deck.
  4. Start the next turn.
Note that by moving the markers from front to back those units with a marker in front, i.e. those that had turned over, they miss their next turn as they are already marked as having moved that turn when the new turn starts.

So, by using a card deck we randomize the order in which the players have to act. This adds another tactical decision for players while simultaneously lowering the GOTCHA' factor of IGO UGO. (If you don't want to introduce a random element, or another game device like playing cards, simply alternate between players, each activating one unit at a time.) By tagging the unit that turned over, we penalize aggressive, risky play (or at least that play which fails), but penalize the unit that made the play, not the rest of the force. Finally, if you want to add one more random element, you can add a Joker to the deck. When the Joker is drawn the turn ends, regardless of whether all units on both sides have moved.

Note that the use of cards is recommended for multi-player games, so this is not a totally new game device for Ganesha Games' games.

I think I am going to grab some miniatures this weekend and give this a try. Let me know if you do.

Sunday, March 27, 2011

Using Map Tool for Gaming

Some of you may have read my previous blog entry on using Battle Chronicler for writing up battle reports. I used it for DBA and TWTUD, and John Mumby did a guest blog entry using it to show the setup for his Battle of Trautenau. The advantage to Battle Chronicler is that it makes it easy to show the progression of the battle from turn to turn, playing it back for others. Where I think it has problems, at least for the types of games I play, is with unit management. (Making it hard to drag units around the map doesn't help either.)

What I mean by unit management is that some rules are figure-based and others element-based. Battle Chronicler does better with figure-based rules. When trying to use it with element-based rules that use concepts like hits, disruption, varying levels of morale status, etc. it falls short (or I need to learn it better to account for these factors). It was while reading a thread on the Yahoo forum for Song of Blades and Heroes (I read it for the Song of Drums and Shakos, Sixty-One Sixty-Five, and Flying Lead messages mostly) that I ran across a reference to MapTool by RPTools where someone was using it to play miniatures games.

So, what is MapTool? It is basically a tool for an RPG GM to run a game over the internet. But, in order to be successful at that it has a number of features that miniatures gamers could use. Rather than repeat everything on the RPTools web site, follow the link above and read about it. Suffice it to say that here are a few aspects of the tool that caught my interest:
  • Easy to lay down a square or hex grid of any size.
  • Easy to lay down and size terrain images.
  • Easy to create 'tokens' - images representing figures, bases, or units - and move them around the map.
  • Practically everything can have attributes or properties, all of which you can easily customize.
  • Easy to game over the internet.
  • Easy to introduce a Fog of War (hidden troops and movement).
To give an idea of how easy it is to create attributes for a unit you do the follow.
  1. Open the Campaign properties.
  2. Create a new token type (click of a button).
  3. Type in a list of attributes for the token type, one attribute per line.
  4. Drag an image onto the board.
  5. Apply the token type to the image.
  6. Enter the values for each attribute. (The program automatically converted to list of attributes in step 3 to a property sheet.)
You might be thinking, "So what? What does all of this have to do with playing miniature gaming rules on the computer over the internet?" Let's take an example, Neil Thomas' Napoleonic Wargaming, for example. I have used these rules in the past for my American Revolution gaming. The basics of the rules are that you have a certain number of units, each unit has four bases (save for artillery) and each base has four hits. So, there are some attributes: unit, base number, and hits. Also, some troop types have attributes that apply only to them, for example, does your Close Order Infantry in 2-rank or 3-rank line? There are two more attributes: unit type and ranks (which only applies to the Close Order Infantry type).

The effect of all this is that you can apply these attributes to each token on the board - in this case each base - and the system can track it for you just like a tool designed for an RPG GM would track hit points for all those separate goblins that your characters are bashing.

Finally, and this appeals more to the programmer in me, there is a macro language that you can embed into your creations. This is what takes it way beyond Battle Chronicler or VASSAL. Both of these systems are notorious in one aspect: they don't know or enforce the rules. With MapTool and macros, you actually can program in the rules. Know that the Elite troops fire at a +1? Program a macro that looks at the selected unit when you click the "Fire" button and it automatically applies the +1 for you.

One of the arguments you see a bit on forums like The Miniatures Page (TMP) is "playability versus realism" or "playability versus complexity". What it should really be is "playability versus detail". It is very easy to add detail to a set of rules and end up with more complexity, less playability, and less fun. However, some added detail can actually add to "realism", and if it just had a helper - like a computer program - the complexity and tedium would be offset.

An example is a set of rules that tracks several morale states (for example: Impetuous, Normal, Shaken, Broken, and Routed) for each unit, along with the number of disruptions (reflecting disorder and disorganization), and casualties, each of which has different effects in the rules and creates different modifiers when moving and shooting, by having an easily accessible roster for each of units you can track all of them with a minimum of effort (relatively speaking).

There are numerous other features that I have not even touched upon, such as light, line of sight, fog of war, and an infinite table size (no "edge of the table" syndrome here). This looks like the tool of choice, certainly for prototyping out new rules, trying new rules without committing to their basing schemes (yet), and playing over the internet some games where tracking several factors don't work as nicely with the other tools. This tool probably does not excel at free movement, but it is certainly capable of it.

Friday, March 04, 2011

The Battle of Trautenau

Today I have a guest blogger, John Mumby of the Colorado Military Historians club describing a battle he ran at Genghis Con on Feb. 19, 2011. Take it away John.

Austrians  vs. Prussians

Overview

Scenario: Trautenau 1866 Austro-Prussian War

Location: Genghis Con, Denver, Colorado, USA

Date Played: Saturday, February 19, 2011

The battle of Trautenau was the only battle that the Austrians won against the Prussians in the Austro-Prussian War of 1866. The game that I hosted at Genghis Con on February 19, 2011 is based on this battle.

Deployment

The Prussians have 5 infantry battalions, 1 jaeger battalion, 1 light cavalry regiment, 3 field gun batteries, 1 brigadier general, and the Commander-in-Chief coming in by the bridge (at the top of the map). Next to that Line of Communication (a game concept in the rules used), the Prussians have 4 infantry battalions, 1 light cavalry regiment, 2 heavy cavalry regiments, 1 horse gun battery, 2 field gun batteries, 1 cavalry brigadier general, 1 brigadier general, and 1 division general.

The Austrians in the left corner (bottom of the map) have 4 infantry battalions, 1 jaeger battalion, 1 light cavalry regiment, 3 field gun batteries, 1 rocket battery, 1 brigadier general, and the Commander-in-Chief. Between the farm and the woods, the second Austrian player has 4 infantry battalions, 1 jaeger battalion, 1 light cavalry regiment, 2 heavy cavalry regiments, 1 horse gun battery, 3 field gun batteries, 1 cavalry brigadier general, and 1 brigadier general.

Victory Conditions

The two blue bullseyes (at the top of the map) are Prussian Lines of Communication (LOC) while the two red bullseyes (at the bottom of the map) are Austrian Lines of Communications. Each  LOC is worth one victory point each. The three hills with black bullseyes and the village of Trautenau are also worth 1 victory point each. There are 8 bullseyes on the table so the game could end in a tie.

The Game

The score at Genghis Con was Prussians 4, Austrians 3, with the middle hill disputed (no points scored because both players had units on the hill). The Prussians won the game on the last turn!! The same thing happened the week before at our club meeting (Colorado Military Historians) while playtesting the scenario. The rules used are Wars of Empire I by Keith Warren and Real Time Wargames. This map was created with the free Battle Chronicler software. You can find more discussion on these rules and other Real Time Wargaming rules, and the definition file for Battle Chronicler, on the Real Time Wargaming forum on Yahoo.

Thanks again to John Mumby for guest blogging today's entry.