Add proper round-based gamemode support

[lefckntea]

Add proper round-based gamemode support

There's been a few maps that explored round-based gamemodes in the recent past, like Sunstroke CP and Duels: Basilica or Duels: Riot
In all of these maps once you capture the objective of the map, all players are tped back to spawn for the next round
All of these maps also face the issue of entities like items or arrows not being cleared which, if abused, completely breaks the map. Examples being teams stacking arrows&gaps from prior rounds or just overall increase of everyones arrows cause more and more arrows that were missed are stuck in walls for you to pick up.

Note that these are only conquest maps so anything that includes blocks would absolutely not work the way these maps were made
Not to mention that the sunstroke xml is overall really weird and the way hill decay works makes some gameplay problematic

I propose some way to define rounds in xmls, how the next round starts and what on the map resets. options being items, other entities, blocks , objectives. So you would be able to choose if blocks placed on the map reset or not.
In the case of hills (which currently can kinda reset) it should be a better option than decay and captured-decay. it should just fully be based around if a round has ended or not for the objective to reset.

Then the option to determine if rounds are blitz/ if you can respawn during a round should exist.

Also you should be able to define when the next round starts. If thats only via an objective being captured or in the blitz case when only one team is alive so they dont have to go on completing the objective when they already killed everyone.

[OhPointFive]

This is now generally possible with actions, triggers, and variables, but round-based XMLs are a bit of a mess. I thought I'd note down an idea for a simpler approach. I'm not strongly in favour of this particular approach but I do think we should do something.

Concept Example

<stages repeat="true">
    <stage 
        id="waiting-area" 
        duration="10s" 
    >
        <spawns>
            <spawn team="blue" kit="empty-kit" region="blue-waiting-spawn"/>
            <spawn team="red" kit="empty-kit" region="red-waiting-spawn"/>
        </spawns>
    </stage>
    <stage
        id="in-game"
        win-condition="is-team-winning"
        points="1"
        on-end="clear-items"
    >
        <spawns>
            <spawn team="blue" kit="game-kit" region="blue-gaming-spawn"/>
            <spawn team="red" kit="game-kit" region="red-gaming-spawn"/>
        </spawns>
    </stage>
</stages>
<filters>
    <stage id="in-waiting-area" stage="waiting-area"/>
    <stage id="in-game" stage="in-game"/>
</filters>
<actions>
    <end-stage id="end-stage-action">
    <win-stage id="win-stage-action" stage="in-game">
</actions>

Concept Details

<stages> attributes

• repeat — if, after the last stage ends, it should begin again at the first stage.

<stage> attributes

• id — a unique identifier
• on-start — an action ran on stage start
• duration — how long until the stage automatically ends
• on-end — an action ran on stage end
• end-condition — a dynamic filter that ends the stage
• win-condition — a dynamic filter that ends the stage and gives points to whichever team satisfied it
• points — how many points the team that satisfies the win-condition gets
• lives — optional - if lives are limited how many lives you get
• spawns — a spawns block that specifies where people spawn during the stage

<stage> filters
These just filter whatever stage is active.

<end-stage/> action
Ends whatever stage is currently active, or if a stage is specified, only ends that particular stage.

<win-stage/> action
Team or player scoped, wins whatever stage is currently active, or if a state is specified, only wins that particular stage.

Motivation

I'm pretty sure this is all do-able via actions and filters, but current stage-based maps have messy and complex XMLs. It's basically impossible for someone new to XML to understand, and still pretty hard for people like me or mame to be confident there's no XML bugs. Adding new, fairly simple features to a stage-based XML is nontrivial.

It's also not at all clear, from reading Moonshine's XML, for example, how the map works at all. I'm not sure if "understandable XMLs" is a goal of PGM but I think it's a nice feature.

If we added something like this, new XMLers would probably be able to understand and even write XMLs for round based maps, and experienced mapmakers wouldn't have to spend so much time on them.

[Pablete1234]

I think round-support makes sense on a PGM level, however i dont see its implementation being anything alike to the concept you proposed.

While i understand the motivation of "making complex features more accessible" i feel it fails at that.
Im not convinced that monshine's xml will become significantly simpler in an extent that is able to justify this (pretty complex) implementation