GM/FC Workload Reduction Methods

[Molon Labe]

A common theme in any discussion about how the GDT experiment went is how much time/work was involved in running it. This thread explores ideas for ways to reduce administrative burden.


Software-based Mobility Accounting
A huge amount of admin work was spent in the GDT doing the things which, honestly, are the sorts of things we have computers for. The GMs job is essentially to act as a dynamic campaign engine because DW doesn't have one. So, to simplify things... and to make them more realistic at the same time, existing programs can be used to keep track of as much as possible.

That software could be DW or Fleet Command run in single-player mode. To accomplish this, the GM would simply use movement orders received to place the appropriate platforms in the battlespace with assigned tactics corresponding to the movement orders received. This would allow the continuous tracking of all platforms' movement according to their actual capabilities, instead of an abstracted hex movement system.

Because the precise location of platforms would be accounted for in this system, a much more realistic detection system can be used. This would involve established detection chances for all sensors vs. all other platforms/sensors, which could vary based on range, target-based factors, and environmental conditions. This would require a very large amount of work up-front to determine the ranges, but once this system is in place implementation is quite simple. The GM simply notes whenever any opposing platforms come into proximity and tests for detection based on that system. Successful detections are reported to the appropriate player/side. Note: this system need not be disclosed to the players at all, leaving them to guess, for example, how dense a buoy field would have to be to detect a class Y submarine at X speed.

The rigid turn and phases system would also be dispensed with. Detections and orders would be given in a fluid manner, with time being lapsed as quickly or as slowly as is needed for the sides to issue orders.

Finally, this method would offer the advantage of time savings in GM to side communications. Instead of having to prepare a map and reports of enemy units in a rather clumsy fashion, the GM can simply run the DW/FC simulation and take screenshots at appropriate times (for each side separately, obviously), instantly reporting the disposition of friendly units, and with just a little bit of work, possibly including contact information against enemy units as well.

The main disadvantages of this system would be the amount of up-front work it would take to create the detection system, and potentially added work in terms of fuel accounting that would probably have to come with this system.

No combat would ever be resolved as part of this system of mobility accounting; the simulation is being used solely as a tool for tracking movement and reporting contacts.

"Outsourcing" Communications
That's a snarky way of saying taking work away from the GM and giving it to the players. Communications between the GM and sides were mostly done through email, and dominantly took place between the GM and FCs.

A forum-based, instead of email-based, system might work better. Each side would have a secured forum dedicated exclusively to platform orders. One sticky thread would be made to post assignments of platforms to task forces. The FC, or better yet, authorized individual players, would then post threads for every task force or independent platform containing that platform's current orders. Those orders will include, at a minimum, a course or destination and a speed (I'm assuming the software based solution above is being used for mobility accounting instead of hex movement). Optionally, other information can be included, such as waypoints, formations, movement modification patterns (like zig-zags, sprint and drifts, crazy ivans), active sensor state, or tube reloading orders... anything that the player would want the GM to use rather than make up on his/her own.

Posting rules would be strict. Only persons authorized would be permitted to post orders in the thread (to prevent contradictory orders). No editing of posts would be allowed (to prevent fraudulent conduct). The only valid orders at any given time would be the most recent orders posted; no reference to prior orders would ever be made (preserves efficiency). The end result would be that the GM can quickly check the current orders of all platforms by browsing the most recent posts for each platform/task force, with little opportunity for error if the rules are followed.

[Molon Labe]

I've been thinking about the consequences of moving from a turn based system to a fluid time system. The problem a fluid time system causes has to do with intelligence. Whenever there is something to report to a side, the clock needs to be stopped so that side can issue orders in response. But, if the clock is stopped and a side hasn't been given a report, then that side can be pretty sure that the other side has detected them, which may cause them to change their plans in a way they shouldn't have.

I think this can be dealt with by having a specific time of the day designated when the clock is to be run. During this time, each side will be required to have an officer with command authority on-call. This way, reaction to reports will be nearly instantaneous. As a side benefit, I think this may be a way to help get the whole team on board in command decisions, since the on-call officers will have to be familiar with the plan to know how to react on the fly.

Another problem, or perhaps opportunity, is the reporting of neutral contacts. It used to be that only military contacts were reported; neutral contacts were not tracked at all and were spawned somewhat randomly when battles were played. This can still be done... But in a world where contact is being reported back to the fleet nearly in real-time, it seems odd that classification would be reported as well. If contacts are reported as unknown, then information overload can become a problem, and the clock might get stopped a little bit too much. This might be alleviated in part by having the sides issue standing orders for how to handle unknown contacts; if the order is known in advance there is no need to stop the clock to ask. Another sub-issue to this is projecting known detection ranges. If more than a handful of platforms are going to be subject to detection rules, it probably makes more sense to test for detections on the fly than to do all the work in advance. That's not a dealbreaker, but I do think it's a red flag.

[TLAM Strike]

I think this can be dealt with by having a specific time of the day designated when the clock is to be run. During this time, each side will be required to have an officer with command authority on-call. This way, reaction to reports will be nearly instantaneous. As a side benefit, I think this may be a way to help get the whole team on board in command decisions, since the on-call officers will have to be familiar with the plan to know how to react on the fly. Hmmm sort of a combonation of a turn-based and real time system. Its a good idea but I liked the pure turn based system it does have the advantage of players being able to drop and pick up the game at will.

If we had someone who new a little C++ or something a plotting program would be quite system. Sorry to say that I remember nothing about C++ or Visual Basic that I learned in school, and don't have time with work, LWAMI DB work and finishing EV: Firefly to learn it again. Maybe we should asked around subsim?

[Molon Labe]

Hmmm sort of a combonation of a turn-based and real time system. Its a good idea but I liked the pure turn based system it does have the advantage of players being able to drop and pick up the game at will.
Is that really an advantage? Getting people to turn in orders on time and schedule matches was like herding cats. I think the easier it is to drop and walk away from, the worse the problem gets...

Whether this is a good thing or a bad thing, I think it's a wash between the proposed system and the old system. Once the clock is stopped pending orders, it's just as easy for someone to walk away from, and the records are all there to pick things up from just the same.



If we had someone who new a little C++ or something a plotting program would be quite system. Sorry to say that I remember nothing about C++ or Visual Basic that I learned in school, and don't have time with work, LWAMI DB work and finishing EV: Firefly to learn it again. Maybe we should asked around subsim?

I'm not entirely opposed to a new turn-based system, but as I've said before, I'm not terribly enthusiastic about using the same turn-based, hex-based system. Even if the workload that system involved was reduced by a C++ program, the abstractions, imprecisions, limitations, and other compromises stay with it. To use the obvious example, a real-time, real-space system has the advantage of allowing for a detection system that is barely abstracted at all and needs very few rules--compare that to the very complicated and abstracted system we used before (go ahead, look at the rulebook, there's a lot of shit there! And as voluminous as it was, it only worked "good enough" instead of well). If you can think up a better turn-based system that what we used before, then maybe this approach is worth doing. But I really do think the old system has got to go.

[Phil21]

The main problem i see is not whether we should use a 'real-time' or turn-based system, but how dynamic and accurate the campaign will be. I have no answer for this, its just my thoughts as they came into my mind right now, i just wanted to share them before they fade. So they are fare away from being complete...

If you want a total dynamic campaign involving all units with their movements then a real-time system based on another game or program is much more acurate. It calculates all the things you need in realtime, you don't need complex rules. Problem is getting all the players to make decisions at the right time...and to find software suited for this.
But if you want to make it more easy - like 'one mission, the outcome affects the next mission, but the next mission is either this or that' - semi-dynamic campaign then the turn-based system is your choice. Reducing the amount of workload by this also decreases the dynamic of the campaign, which is its major drawback.


I like the idea of having a complete dynamic campaign, but without a good program to take over the workload it will be quite impossible. And if we decrease the dynamic to a limit where we can handle the workload ("attack A or B or defend C") we could also use a normal campaign where the results of each mission influence the next mission slightly...



Your aproach of the combination of turn-based and real-time has some problems: If the clock is stopped because As submarine has detected Bs submarine and decided to attack, what will the mission look like and when is it played? You see, if you say the mission is normal ASW-Areasearch with the given conditions for A and a single transit mission for B and its played right when the decision to attack is made, then B knows that their sub was detected and will be attacked in the mission.
its the same Problem you have found earlier:

originally posted by Molon Labe
Whenever there is something to report to a side, the clock needs to be stopped so that side can issue orders in response. But, if the clock is stopped and a side hasn't been given a report, then that side can be pretty sure that the other side has detected them, which may cause them to change their plans in a way they shouldn't have.


so much from me right now....im quite tired and have to get up early tomorrow....and its quite late here.

Phil

[Molon Labe]

The main problem i see is not whether we should use a 'real-time' or turn-based system, but how dynamic and accurate the campaign will be...... If you want a total dynamic campaign involving all units with their movements then a real-time system based on another game or program is much more acurate. It calculates all the things you need in realtime, you don't need complex rules......But if you want to make it more easy - like 'one mission, the outcome affects the next mission, but the next mission is either this or that' - semi-dynamic campaign then the turn-based system is your choice. Reducing the amount of workload by this also decreases the dynamic of the campaign, which is its major drawback......And if we decrease the dynamic to a limit where we can handle the workload ("attack A or B or defend C") we could also use a normal campaign where the results of each mission influence the next mission slightly...
The less persistent/dynamic campaign idea is pretty much what the DW+GR/CMSF idea is. It is a separate, much less ambitious project. The GDT concept, and whatever it evolves into (if anything), is a persistent dynamic campaign.



Problem is getting all the players to make decisions at the right time...and to find software suited for this.That is an issue... but I think the "HQ officer on watch" idea adequately answers this. It shouldn't be too hard to find two people to be on watch at the same time. Don't you think?



I like the idea of having a complete dynamic campaign, but without a good program to take over the workload it will be quite impossible. Not impossible. Just burdensome. We already did it once!



Your aproach of the combination of turn-based and real-time has some problems: If the clock is stopped because As submarine has detected Bs submarine and decided to attack, what will the mission look like and when is it played? A sub v. sub duel, more or less.



You see, if you say the mission is normal ASW-Areasearch with the given conditions for A and a single transit mission for B and its played right when the decision to attack is made, then B knows that their sub was detected and will be attacked in the mission.There is no getting around that as long as the sim we're playing is DW. The side not making the call to attack is going to know what's happening the moment he/she enters the lobby and sees who else comes in. Until we get a new sim to play, this is a limitation we have to live with. But we have this same "problem" every other time we play any DW MP match. I'm not going to lose any sleep over it.

But, no, this isn't the same problem I described earlier: "But, if the clock is stopped and a side hasn't been given a report, then that side can be pretty sure that the other side has detected them, which may cause them to change their plans in a way they shouldn't have." (emphasis added) The missions aren't made until all actions are declared, so it's too late for anyone to change their plans at that point.

As a side-note, the mission wouldn't be designed to start right when the decision to attack was made, but would wind the clock back so to speak, by 5-15 minutes. If the exact position the platforms start in was predetermined, then a CTD or lost connection would fuck the match over pretty badly. (Too bad we can't lock the replay files!) So some randomness has to be built in, and those random positions will have to extend away from the opponent rather than toward it...the result being that the platform who did the detecting will probably have to do a little bit of stalking before finding the enemy.

[Phil21]

Ok, i think i got confused a bit with the GDT and the DW+GR/CMSF thing and where the differences are.
And the "officer on watch" could be the answer, i just could not get it into my picture of the concept...but now it starts to fit. Maybe i just got it wrong at first...

My problem with the persisten/dynamic campaign is still that i cannot really imagine how it could work effectivly work with another game used as 'campaign-engine'. Sure, you can take one strategy game and fight every battle that occurs with DW, but how do you create the missions, get the results into the engine-game? Lots of questions...
But if you can solve these, then it would be a really great thing...something like a 'Total War' game for modern warfare and MP-based would be the result.

Reducing the workload for shorter, non-persistent campaigns should be easier: Using a relativ small conflict region a low numbre of DW-Areas could be used for the missions. These areas are then modelled as templates (including bases, basic random merchant traffic, etc.) and would be used as the background for every mission.
Then the given units would be inserted, giving them specific tasks for each round. According to whether theses tasks were completed and the new orders by the sites, the next mission would made in the same area with only 'minor' changes (changing/deleting bases, repositioning units for the next round etc.).
Sure, it would be a vey simple way, but for short tournaments over a month or so it would fit qutie well.

[Molon Labe]

My problem with the persisten/dynamic campaign is still that i cannot really imagine how it could work effectivly work with another game used as 'campaign-engine'. Sure, you can take one strategy game and fight every battle that occurs with DW, but how do you create the missions, get the results into the engine-game? Lots of questions...
Input to and output from the DW tactical simulation must necessarily be done by human beings, as it was in the GDT. Unless we've got someone with 1337 hax0r skills to modify the hell out of DW, anyways.

The role of a "strategy game" or any other software necessarily cannot amount to a complete campaign engine, so if I've used that term to describe its use that was wrong and I apologize for causing the confusion. The proposal was to use DW or FC as an alternative system for mobility accounting--it just helps the GM determine where the platforms are in space-time. It's basically a high tech chart and ruler, but with the added bonuses of being able to erase/move things around without crudding up the chart, taking screenshots to provide updates to players, observing the movements of all platforms simultaneously, and possibly of being able to use the tactical simulation's detection rules instead of creating fixed detection rules in advance.

[Phil21]

Ahh, now i got it. OK, that would really help since mobility and detection seem to be the key-problems...

[TLAM Strike]

I'm not entirely opposed to a new turn-based system, but as I've said before, I'm not terribly enthusiastic about using the same turn-based, hex-based system. Even if the workload that system involved was reduced by a C++ program, the abstractions, imprecisions, limitations, and other compromises stay with it. To use the obvious example, a real-time, real-space system has the advantage of allowing for a detection system that is barely abstracted at all and needs very few rules--compare that to the very complicated and abstracted system we used before (go ahead, look at the rulebook, there's a lot of shit there! And as voluminous as it was, it only worked "good enough" instead of well). If you can think up a better turn-based system that what we used before, then maybe this approach is worth doing. But I really do think the old system has got to go.

Maybe something a little more abstract would be the way to go, Have you ever played 'PTO II: Pacific Theater of Operations'? In that game you could send subs and fleets out to a point on the map with a simple order like "Patrol (Search area and report contacts)" or "Land (Land Marines safely at X Base)" or "Stabotage (Sink transports at X Base)". Lets say we divide the map up in to fewer hexes or squares etc (say by as much as half) and each side deploys units there with orders (Variations of Search, Attack, and Hide based on its capablities). Detections (and subsquent battles) would be the result what units had what orders and what their capablieies are (IE a P-3 on ASW patrol would have X% chance detecting a sub that is transiting while a Seahawk as Y% chance of detecting). The diffrent forces in that section would then have a oportunity to attack, the nessary manuvering would be automatic.

Basicly I'm talking about making the GDT stratigic wargame in to something less of a minatures game and more of a battle generator with humans determing the forces aviable.

For example lets take the GDT map we played and laid it out diffrently. One of the sections includes Bluefields, Dom Hasquez and the Canal. We have an Red sub in that area and Blue FFG W/helo. The Red Sub has orders to 'Attack: Shipping' at the canal, while the FFG and its helo has orders for 'ASW Search: Canal Area'. If a dice roll based on each untis speed, orders and capablities indicates that the FFG or the Helo detected the sub those forces can battle. If the FFG had orders for say 'ASW Search: Entire Region' there would be a more diffcult dice roll for detecting the Red Sub but it would be able to have a dice roll for every Red sub in the area.

[Molon Labe]

I love PTO II!!! I only wish someone would redo it, or make another game like it, with better AI. It's way to easy to predict what the enemy fleets are up to since their plan doesn't change until the end of the month.

Anyway, I think there is merit to the system you describe. It's going to turn on having decent detection rules, though, although I think with the greater level of abstraction, simpler rules might be possible than what we used before.