Campaign System – The return!

Last night I had a conservatory full as six of us gathered to put into motion the Napoleonic Campaign that I’ve been working on for over 2 years. It started life when I had the opportunity to join in a campaign run online using Malcolm McCallum’s web system

Since my day to day work is as a database manager, I figured I could do a similar sort of system in MS Access which could be emailed around and would suit my small wargaming group and the growing 6mm Napoleonic Collection I had. Several iterations later of both the campaign system and the tabletop rules later, we realised that Access wasn’t going to work for us, as it depended on everyone having Access for a start, and also chain emailing it around. An online version was a much better option and I changed my hosting to facilitate this. At this stage I knew no php at all, but Malcolm was helpful with certain bits of info and I picked up what I needed to know as I went. As with all things, interest and momentum waned on and off, a major push in time for presenting it at the Conference of Wargamers this summer left me massively dejected when no one opted to attend the session.

However, 2012 is the year of meeting objectives, or something like that, so with extra work over the Christmas break, I got the system to a point where we can start using it.

The basic premise of the system is that it facilitates running a campaign with zero paperwork and replaces the need for an Umpire. Users log into the system on the website , and are able to enter orders, view reports, send messages to allied players and run their game as they see fit. Turns can be automated but for now they will be run manually by me logging in as Admin and pressing the “run” button. A day’s game turn takes around 10 seconds to process, and players can see the results immediately.

There are still a number of areas I want to work on, and this is most certainly not a simulation of what Napoleonic Campaigning was like. It contains a number of compromises in order to increase playability and player choice and hopefully will give a stimulating and enjoyable context to our table top battles.

Essentially when the player logs in, he is viewing a static situation snapshot taken at for sake of argument 12.01am. They can send orders in preparation for the current day’s activities and read reports which arrived during yesterday.

  • Weather is generated for tomorrow if required. (weather is generated in “blocks” of variable length and is seasonal, for example Winter provides a higher % chance of snow than Autumn, while Summer days may be extremely sunny, Winter days almost certainly will not!). The prevalent weather affects the movement of troops, moving in snow adds fatigue for example.
  • Supply lines are checked to see if lines are broken, and reinforcements are generated and delivered where possible. Losses due to fatigue, disease and being out of supply are applied also.
  • Unit Strengths are calculated for tabletop battles from the actual strengths, including a random factor of PoW. Additional Rulesets can be incorporated with a little tweaking, Mike was talking about using
  • Napoleon at War for smaller confrontations for example.
  • Regional Ownership calculations which have a bearing on Courier survivability. Regions have 2 factors which govern how much help or hinderance a friendly courier might get while moving through that region.
  • Move Couriers (morning). This delivers or attempts to move, any couriers currently in the system. Any move orders the player has issued to his units will move in this phase. If they are delivered during this phase then troops can move during the current day. Couriers sent to other players who are in the same location or a single leg away will immediately be delivered in real time so you don’t have to wait for the turn to process.
  • Move Units. Unfortunately while simultaneous movement is possible, its an absolute nightmare to code collision detection, so for now the system operates an IGOUGO turn sequence, with initiative being randomised each day. One side completes all its moves and then the otherside moves where it is able, ie not being attacked.
  • At this point, the system may pause because a tabletop battle needs to be fought. Players will have warning the day before that a battle is due, but this turn allows extra forces to be moved into the battle location. They will of course arrive late on the table! Players will be unable to send further orders while the system is paused, but will continue to be able to view their messages, send messages to other players and generally plan their game.
  • Generate Scouting messages. Units in adjacent towns to each other will report each others location and strength, using their Light Cavalry to screen their own forces if possible. Thus two forces, one of which has cavalry while the other does not, will report differently. The force with cavalry will get a nearly accurate report of the strengths of infantry and artillery, while the other force will simply know that there light cavalry about and may wildly under or overestimate their numbers!
  • Move Couriers (Evening). This delivers or attempts to, any couriers which have been created since the morning courier movement. Any courier that moved in the morning, will NOT move again, although if a courier was in a location that it’s recipient has moved to, it will deliver the message.

The current campaign is based in the Iberian Peninsula and features Matt and Peter playing the Anglo-Portuguese army, while Christie, Mike, Richard and myself each have 2 Corps of French, poised on the Pyrenees border to invade Spain. The date is the 8th March 1809 and the campaign is not intended to be a recreation of the Peninsular War. One reason for this is that we only own about 8 bases of Spanish troops! The French are to capture all regions on the map, while the Anglo-Portuguese players are to prevent that. We’ve left it fairly open ended, and this may be a mistake but for now we want to get going and worry about that at the end. The first turn will process on Saturday morning, in the meantime the players had last night to discuss their tactics and strategy face to face, and from now on all communications should really be through the system.

I must say a massive thanks to Malcolm again, not only for his help, but also for generously allowing us to use his maps that he has handcrafted using Campaign Cartographer. They truly are works of art and a massive help to the players and umpire.

I have set the website up so that people who wish to view the game progress without taking part may do so and see a current situation map with forces drawn on it. Players obviously don’t have this luxury, and must piece their own intelligence together from their reports. If you want to view this, you must register and be set up to do so but I’m happy to do that if you’re interested.

I hope some of you have made it right down to the bottom here, so thanks for reading what must be the longest blog post yet, and for persevering with no eye candy to drool over. I will post updates of the campaign’s progress as we go, although I’ll have to be careful about what information I release as I’ve no doubt some of the players will try to have a crafty read!

3 thoughts on “Campaign System – The return!”

  1. I like the sound of this system – particularly in that it allows you to do without an umpire (not something i’ve really seen before). How did you code the map into the system so that it could cope with movement orders correctly ?

    1. Hi Simon,

      The problem with movement orders isn’t so much storing the map as the pathfinding. Converting the map basically involves mapping each town into one table, and each road into another, identifying which town it goes to and from.(doesn’t matter which way round).

      The pathfinding is done in a series of logic steps. If I know where I am, then can I get to my destination in one leg? -Simply query the road table checking if town1 is your location and town2 is the destination or visa versa. If that doesn’t get you there, you need to check if you can get there in 2 legs, so you do the above query to get all the towns 1 node away, but then join that onto another instance of the roads table to get all the towns 1 node away from them. Sounds much more complicated than it is. The system relies on what Malcolm described as “the rule of three”, which says that if you know where you are, you know everything that is 3 legs or less away. The system will take the shortest route if multiple are found, and if two are the same it will arbitrarily decide. However, the code in the website will handle pathfinding reliably out to about 25 legs, although the more legs, the slower it takes to calculate exponentially.

      Sorry if that’s a little over complicated 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *