mirror of
https://github.com/dcs-liberation/dcs_liberation.git
synced 2025-11-10 14:22:26 +00:00
5ad57d2878
Ported the existing docs, but the real goal is getting the docs for campaign version moved here, as well as the manual. RTD will have an "edit on github" button that'll keep this accessible to players, but it'll be much easier to keep docs up to date while developing features if it's part of the code base.
180 lines
6.3 KiB
Markdown
180 lines
6.3 KiB
Markdown
# Turnless Campaign
|
||
|
||
This outlines a path for us converting Liberation from turn based into a
|
||
turnless campaign game like BMS.
|
||
|
||
## Hard problems
|
||
|
||
### We can't simulate combat
|
||
|
||
We can't feasibly simulate the details of combat, nor can we generate a mission
|
||
mid-engagement. The mission editor does not support generating aircraft
|
||
mid-maneuver, or with any SA.
|
||
|
||
To avoid that problem, instead of simulating the combat we put the group in a
|
||
"freeze" at the moment the engagement begins. Any frozen groups are spawned
|
||
wherever they were frozen so simulation can be deferred to DCS. Each freeze will
|
||
have a deadline for completion, at which point a simple strength-based
|
||
autoresolve will take place.
|
||
|
||
After a frozen engagement is resolved (whether in sim or automatically), if the
|
||
mission objective has not been achieved a mission abort will be evaluated.
|
||
|
||
### We don't know where the roads are
|
||
|
||
We don't know where the in-game roads are, so we can't precisely simulate the
|
||
location of convoys as they move, nor the amount of time they will take to move
|
||
between bases.
|
||
|
||
Time can be solved by just having the campaign designer encode the travel time
|
||
in the campaign. The ME will estimate it for them so it’s simple to do. Spawn
|
||
locations cannot be made precise, but we can have campaign designers define
|
||
several waypoints along the route and spawn the convoy at the most appropriate
|
||
one.
|
||
|
||
### SAM engagement zones are huge
|
||
|
||
The large threat zone of many SAMs would cause most of the map to be a frozen
|
||
engagement.
|
||
|
||
To avoid that, SAMs will not cause frozen engagements, but will be simulated at
|
||
a basic level. Each SAM will track a group, and when in range will periodically
|
||
“shoot”, and those shots will have a chance to kill an aircraft in the targeted
|
||
group.
|
||
|
||
## Systems that need to change
|
||
|
||
### AI Commander
|
||
|
||
Theater state tracking for the HTN becomes much more complicated since it needs
|
||
to always be able to replan based on pending plans. This shouldn't be too bad
|
||
since RndName's PR did similar and the plan to continue that should work here.
|
||
The commander needs to learn to abort missions that are no longer viable.
|
||
|
||
### Transports
|
||
|
||
With turns gone, transports can longer move one link per turn. See the entry in
|
||
"hard problems" above. To begin with we can pick an arbitrary time per link and
|
||
just always spawn the transport at the origin regardless of where they ought to
|
||
be.
|
||
|
||
### Turn based systems
|
||
|
||
A number of systems that act in a number of turns become time based:
|
||
|
||
- Runway repair
|
||
- Unit delivery
|
||
- Weather changes
|
||
- Pilot replenishment
|
||
- Income
|
||
|
||
Procurement could be made simpler if we do away with cash in favor of fixed
|
||
replenishment rates.
|
||
|
||
### Front line advancement
|
||
|
||
Front line combat is happening continuously so we need to simulate its movement
|
||
and losses on the front line.
|
||
|
||
### Mission generation
|
||
|
||
The mission generator needs to be able to generate aircraft in specific
|
||
locations, with partial fuel, and possibly with some weapons expended.
|
||
|
||
### Mission result processing
|
||
|
||
Last known positions need to be recorded, as do weapon inventory and fuel
|
||
states.
|
||
|
||
### UI
|
||
|
||
Frozen combats need to be immutable to the player.
|
||
|
||
Missions in progress need to be made cancelable.
|
||
|
||
The map needs to show the locations of in-progress missions, including frozen
|
||
engagements.
|
||
|
||
There needs to be a UI to examine frozen engagements.
|
||
|
||
## Roadmap
|
||
|
||
This roadmap is ordered so that we can attempt to make this change in phases
|
||
that may take more than a single release. It is not focused on providing the
|
||
best gameplay experience ASAP, but on being able to approach this gradually
|
||
rather than freezing all other development or branching and a painful merge.
|
||
|
||
### Front-line progress rework
|
||
|
||
Add auto-resolve for the front line, adjust progress estimates based on stances
|
||
and not just kills (an enemy in retreat is less likely to be killed, but still
|
||
gives up ground).
|
||
|
||
### Add play from first-contact option
|
||
|
||
Add simulation of the mission from the start of the turn up to the first
|
||
engagement. Generate the mission from that point.
|
||
|
||
### Add fuel expenditure estimation for travel to start location
|
||
|
||
Adjust fuel quantities at the start of the mission to account for travel.
|
||
|
||
### Add UI to display simulation to first contact
|
||
|
||
Before removing turns, add play/pause buttons to the game that will simulate the
|
||
mission up to the first engagement. Once play is pressed no changes may be made
|
||
to the ATO.
|
||
|
||
When the turn ends it behaves like the normal end of turn. The ATO is reset and
|
||
the new turn is planned.
|
||
|
||
### Add mission abort option for players
|
||
|
||
Add the option to abort flight and packages for players. The AI won’t use this
|
||
yet but it will be needed once engagement simulation is added.
|
||
|
||
### Add simulation for frozen combats
|
||
|
||
Allows play to proceed through engagements. The AI will abort missions that are
|
||
unlikely to succeed after each combat is resolved.
|
||
|
||
### Estimate fuel/weapon use simulation for frozen combats
|
||
|
||
Improve behavior for groups that have completed an auto-resolved combat by
|
||
estimating their fuel and ammo use. This could be used to check if the mission
|
||
should be aborted.
|
||
|
||
### Add player options to create new packages after pressing play
|
||
|
||
Allow players to create new flights as the mission simulates. This would be the
|
||
most effective way to add intercept missions.
|
||
|
||
### Make planning real-time
|
||
|
||
Make the AI planner periodically reevaluate missions to add to the ATO. It will
|
||
still plan as many missions as possible up front so that the DCS side of the
|
||
mission can run as long as possible, but it could make use of aircraft that had
|
||
aborted or returned.
|
||
|
||
### Time-based systems instead of turn based
|
||
|
||
Move the systems that are currently based on turns to be based on duration. Each
|
||
turn is assumed to be six hours since there are four turns in a day.
|
||
|
||
### Time between turns based on mission duration
|
||
|
||
Change the turn duration to be based on the length of the mission played.
|
||
|
||
### Track end positions of aircraft, remove turns
|
||
|
||
If we can track the status of missions after the simulation ends we can continue
|
||
where we left off. Do that, and remove the concept of turns.
|
||
|
||
### Track ammo/fuel status of aircraft at the end of the mission
|
||
|
||
Improve post-simulation realism by tracking the ammunition and fuel spent.
|
||
|
||
### Add turnaround times for landed aircraft
|
||
|
||
Once aircraft returning from a mission land, a timer starts to track the
|
||
turnaround time before they'll be ready to redeploy as opposed to being instant. |