Payload game mode

[TheMolkaPL]

git@github.com:StratusNetwork/projectares.git has implemented a game mode called Payload.

Players have to push a Minecart (known as a “Payload”) to the end of their track. There are two setups for this gamemode: Attackers vs. Defenders, and Team vs. Team. Both versions are supported with the following modules.

GitHub source: https://github.com/StratusNetwork/projectares/tree/master/PGM/src/main/java/tc/oc/pgm/payload XML documentation: http://web.archive.org/web/20181028210707/https://docs.stratus.network/modules/gamemode_payload

[Pablete1234]

I think payload wasn't implemented all that well in stratus, it was just in essence, a moving hill.

Looking at the implementation of this in games like overwatch, a few things here could be simplified, also, the docs seem incomplete or badly formated, like decay is true/false but defaults to infinite? radius defaults to "false"?

In overwatch there is no progress to capturing a payload. If several teams are on it (players inside the radius), the payload is contested and simply doesn't move. When the attacking team has players on the payload, it moves fowards (has 3 speeds, for up to 3 players being on the payload), and when no one from the attacking team is on it for a couple seconds (decay), it starts moving back slowly.

To implement this in pgm, while mantaining the possibility of symmetric maps, i think you'd do with:

• radius for how big the area should be, default about 3-5 blocks
• forward-speed how fast to move the payload
• forward-speed-multiplier value multiplied by amount of people on payload and added to speed
• forward-speed-limit limit so that only up to X amount of people increase speed.
• backward-speed how fast to move backwards (should be slow)
• decay time that the payload has to have no owners before it starts moving back
• owner the owner team for the payload. If ignored, it's a push-both-sides game.
• spawn-location Starting position of the minecart (with a rail in the position) (and other pgm-specific & objective stuff, id, name, required)

With no owner, XML must specify what end location makes what team win With an owner, it should default to the opposite end of the track from where spawn location is, being objective completion for the owner.

The "yaw" property shouldn't exist. PGM should be able to know what direction to go for each team.

If an owner is specified, that team has to be on the payload (and no player from any other team) for it to move towards end goal. If no player from the owner team is near the payload, it starts decaying and then goes towards spawn location, using the backward speed.

If an owner isn't specified, the payload is 2-way symmetric map, and only foward speed should be used. When only one team is on the payload it should move towards end location for that team, if multiple teams or no team is near payload, it shouldn't move. Could alternatively make it so minecart navigates towards spawn location at backwards speed if no team is on it after decay time.

Checkpoints should also be included, they should be filter-testable (to modify spawns) and i don't think they should be marked with a different type of rail, but rather with a checkpoint xml element inside payload. For payloads with an owner, checkpoints should not allow the minecart to move back from that point. For symmetric maps it must be able to return from a checkpoint for obvious reasons.

[Electroid]

ControlPoint needs to refactored into a generic ControllableGoal when implementing Payload. Or else they will both overlap too much with logic.

Edit: Looks like I did some of the work already: https://github.com/StratusNetwork/projectares/blob/master/PGM/src/main/java/tc/oc/pgm/control/ControllableGoal.java

[Pablete1234]

@Electroid As per the original implementation in stratus, yes, alot of the logic was overlapping. But this didn't help the gamemode at all. The only real mechanic payloads should inherit from control points (or ControllableGoal) is the "current owner", capturing/contesting times don't need to exist or be ticked.

IIRC, decay attribute in hills doesn't start a decay if it's fully captured, it only applies if partly captured, so nothing really to be reused, either the amount of players matches or it doesn't, if it doesn't for a couple seconds, it switches to a default of moving back.

[Pugzy]

I've been a long term supporter of the payload gamemode seeing its success in both TF2 and Overwatch, so was disappointed to see it flop on Stratus due to implementation/documentation and map dev support. The mode has some real potential and its core concepts can be seen in the popular 5cp maps.

So a few suggestions and ideas below.

Checkpoints

To expand on this and allow things such as filters to query the progress for spawn points etc. Some form of checkpoint goal system where you define locations along the track which when filtered will be set to true once surpassed. Setting these to have some form of lockable attribute would prevent the payload from going back further than this point.

This could also tie into proximity or some form of overtime and then the possibility to extend match lengths based on goal completion.

An example below including checkpoints.

<payloads radius="3">
  <payload id="red-payload" owner="red-team">
    <spawn-location></spawn-location>
    <checkpoints lockable="true">
      <checkpoint id="first-red">10,5,0</point>
      <checkpoint id="second-red">20,5,0</point>
      <checkpoint id="last-red">30,5,0</point>
    </checkpoints>
  </payload>
</payloads>

Or additionally including the spawn location and possible goal points in this checkpoints area too.

<checkpoints lockable="true">
  <checkpoint id="start-red" spawn="true">0,5,0</point>
  <checkpoint id="first-red">10,5,0</point>
  <checkpoint id="second-red">20,5,0</point>
  <checkpoint id="last-red">30,5,0</point>
  <checkpoint id="end-red" goal="red-team">0,5,0</point>
</checkpoints>

Kits

Another suggestion is some way to have something similar to pickup-kit and drop-kit to give players on the point effects such as healing or items whilst in range.

Mode Overlap

As Pablete touched on in his previous comment the decay attribute only counts when capturing and not once captured (which seems incorrect). It would be nice to have all the logic of a control point at your fingertips as other than the decay and region definitions there is quite a lot of useful overlap.

It may be that control points need some abstraction too. The similarity is "stand in this area, meet these requirements, do a thing".

It would be nice to get an agreed-upon format prior to attempting implementation.

[Pablete1234]

Implemented an initial version in #1059

Extended functionality (like checkpoints) are to be done if the gamemode develops (mapdevs make viable maps with the gamemode)