Jump to content

making connected campaigns


poesel

Recommended Posts

This is in tech support because I would first like to know if its possible and then ask if someone wants it.

What I would like to have is a set of connected scenarios where the outcome of the scenario would decide what scenario will be played next and under which circumstances.

An example: the old Warhammer rules had such a thing in the back: two sides fighting over a long valley. First over the bridge in the middle, everything even. If for example the left side won, then the next battle would be a bit to the right in the valley. Right side had a farmhouse to defend while left side got some more resources. If Right would win its back to the bridge. If Left won then a battle over a castle follows and if Left won that too its over.

Surviving troops would be carried over to the next battle.

Back to DT: for that to happen the DT server had to have the ability to stop at the end of a scenario, dump the results (killed and surviving vehicles, buildings taken or destroyed,...) and wait for a signal. After the signal from another process would be given, the server would read the next scenario from a specific location and proceed.

The task of the 'other process' would be to read the scenario results and prepare/create the setup for the next scenario. Since DT relies only on text this can be done in the language of choice of the campaign creator. If the communication to the DT server is by UDP for instance than the whole thing is platform independent.

The 'process' could mess with the Inventory to add surviving vehicles to the next scenario. Or remove a certain type. Or add some vehicle if a certain building was captured in the scenario before. Or choose a certain scenario. Whatever.

So first question goes to Clay: is that possible and would you consider doing it?

Link to comment
Share on other sites

That would be just fantastic. I think it's even easier to do without restarting the server process. Just:

</font>

  • Don't reload the inventory when the next scenario starts - leave it alone (already in RAM)</font>
  • Pick the next scenario based on winner/loser instead of pulling from ScenarioList.dat</font>
  • Check to see if this is the "last" scenario and show a special AAR screen for winning the entire connected campaign</font>

Very simple actually. And very cool. You would just need some additional tags in the original scenario file (the middle one) that provide a list of the "left" and "right" scenarios. You could already override the starting inventory in that first scenario with current tags. Wouldn't that cover what you're trying to do?

Link to comment
Share on other sites

I like that solution as its easy and elegant and can be done without much effort from the scenario creator. I really would like to see that happening.

One drawback is that it provides a static linking. There is no way to modify the setup of the next scenario with regards of the outcome of the last. That is, no matter HOW you win or loose, the next scenario will start the same.

Dynamic linking would need some more effort from the scenario creator. Done from inside DT we would need some set of rules in a XML file to create the next scenario. This would mainly put the workload on you Clay. This is why I proposed the other solution which would provide some kind of interface for external programs to do just that.

Btw I didn't want to restart the server. Just wait for a signal and then continue.

The static link would be very interesting none the less and much easier to handle for everyone.

Link to comment
Share on other sites

The next scenario would start with the inventory still left as it was at the end of the last scenario. That's what I meant in that first bullet item in the list above. That's the main thing you wanted to keep from one scenario to the next, right? Are you also thinking of things like buildings that were destroyed previously are still destroyed, or other dynamic things like that?

Link to comment
Share on other sites

Keeping the inventory as is would probably be not very good for the gameplay. Since there may be an infinite number of scenarios the game would soon be an infantry battle and the last man standing wins. smile.gif

For starters I'd propose that a scenario should be able to hold the information which scenario follows (and who plays which side) depending on which side wins. A scenario should also be capable to have separate inventorys for each side.

Going a bit further would be: modifying the inventory depending on how good you played the previous scenario (normal inventory + % of remaining vehicles with min/max conditions). Persistant battleground if battles recur on a location. Stalemate conditions (battle is repeated on same ground).

To give an example with current scenarios I would link:

Tough Nut - Raid - Dead Gulch - Raid - Tough Nut

Start is Dead Gulch with no one owning the objective. If an attacker wins Tough Nut then he has won the campaign.

Link to comment
Share on other sites

Mmm, probably worth noting that it'd be a good, if minor, thing for the Scenario Creator to be able to name the sides based on Scenario. (If only because I'm tired of being Blood or Water, when there are so many more creative or informative names, like "Agressor" and "Defender.")

Most wargames have had a "Campaign Series" in either the core book or a suppliment that could create a linked set of missions based on a simple set of rules. With the descriptions of scenarios in XML, we can probably go as arbitrarily more complex as we want. As poesel says, we likely need the ability to modify the inventory based on programmatic constraints, both adding, removing, flooring and ceiling-ing-ing-ing (hard word to finish). That is to say, "If RedFor beats BlueFor by 200 points, they should add 20 ion turrets available, maximum 40, minimum 10."

Mind you, there are probably a few conditions we can guess up front we might want:

</font>

  • Point values: Pretty obvious how they'd work, keying both inven and scenario selection.

    "If RedFor's points exceed BlueFor's by 500 or more, go to Scenario Deep Push. ElIf Points(RedFor) > Points(BluFor) + 250, goto Scenario Shallow Push. Etc."

    "If Points(RedFor) > Points(BluFor) + 100, increase inv of Thors for next scenario by 10, minimum 5, max 30."</font>
  • Positions Held: Some scenarios should branch based on whether one force or another held a certain area at the end. This is an outgrowth of the Objective play, checked at the close of play.

    "If RedFor holds the base, go to Base Defense."

    "If RedFor controls the factory complex, give them 10 more Thors next scenario."

    "If RedFor controls the edge of this map, next scenario gives them the west edge as a reinforcement zone." (This is really just a selection of next scenario map, but it'd look like a scrolling map progression if the maps were designed so.)

    Multiple objective impacts could lead to a lot more variety in gameplay over the same maps.</font>
  • Element survival: Something no scenario currently depends on but could be interesting is whether or not an element or elements survive to the end of the scenario. I don't think there's even the means to track the survival of elements; the implication is they simply won't, given the fluidity of the battlefield. But without survival branches, we can't have scenarios which hinge on whether a convoy makes it across the map or whether the defenders, overwhelmed, can survive with enough forces to be reinforced.

    "For each 'truck' (unarmed Paladin) RedFor gets to Checkpoint Bravo in the next 20min, they get an extra Thor and five extra 120mm turrets next scenario."

    "At the end of the scenario, giben this point table per vehicle, each 10 points gives RedFor a 4% faster recharge on their Mercury artillery calls."</font>

A lot of this goes into making two areas a bit more flexible:

</font>

  • Pre and post scenario time: Time to get longer briefings, time to form up platoons and companies, the ability to review the events of a scenario, if only via chat with more scenario event statistics. To make the scenarios flow better, there'll need to be some pre and post scenario group comm time. Longer scenario briefings might help, too. (I'm not above ripping some format ideas off of Steel Beasts; I'm not too proud.)</font>
  • More complex scenario objectives: We need the ability to describe the things we want in XML, turning it into some kind of perverse DSL. But that's what XML was designed for, building little languages to describe what you need for a given domain.</font>

Put all this together with better command and control capabilities and things really just get better all the time.

Link to comment
Share on other sites

we definitly need pushing maps with multiple objectives that need to be achieved in a given order
I'm not so hot for a given order. That's a bit too much like the scenario designer getting too precise in telling the commanders how to achieve the ends, not just what to achieve. Probably not so useful a design technique as it might be in other strategy games, truthfully.

Now, scenarios that are designed for the human players to all be on one side, co-op, vs all bots given some inherent advantages ... That kind of all co-op setup might be interesting to tinker with.

Link to comment
Share on other sites

×
×
  • Create New...