New Feature: Capture/Control Points

[PyroTech03]

This is a system that allows for taking and holding of territory. I've tried to detail it in a fashion that makes it flexible to use in multiple different ways. This rendition uses a ticket system as it can handle time and multiple combatants easier but definitely up to the idea of making it time based.

So here we go....

New map editor entity "Control Point" which is placed like a resource or event.

When placed you have the following options...

Image: Allow selection of appearance as a spritesheet or from a tileset.
Capture Radius: Range in tiles from the point that allows for capture. Minimum 1
Visible Radius: Range where the capture progress interface displays.
Capture tickets needed: Number of tickets needed for capture.
Tickets per second: How many tickets one player generates per second while in the zone.
Capture event: Linking to a common event that's triggered upon successfully capturing the point.
Neutral Event: Event triggered if the point is made neutral.
Owner Variable: A global variable used to set owner.
Owner Type: A drop down allowing you to choose if owner is individual or Guild.
Contested Behavior: Drop down to decide how the point behavior if contested. Choices are pause, decay to neutral, decay to previous state, or weighted.
Protection Start: How long after capture before protection starts in milliseconds.
Protection Duration : How long protection lasts before it can be contested again in milliseconds.

The owner type will take the player or guild name to set owner variable on capture.

The owner variable can then be used in conditions to decide NPC's friendless, resource access, and event access. Thus allowing ownership of the assets in or around the area. By relying on the event system, it really is only limited by imagination.

Gameplay example

Point configuration
Radius: 5
Capture tickets: 180
Tickets per second: 1
Capture event: Spawn NPC's
Neutral Event: Despawn NPC's
Owner Variable: Outpost_1
Owner Type: Guild
Contested Behavior: Pause
Protection Start: 10000
Protection Duration : 180000

Player A Guild 1
Player B Guild 2

NPC's configured to be friendly if guild name matches Outpost_1

Point is neutral

Player A goes into the 5 tile radius. Timer starts.
At 1 minute, player B enters. Timer paused.
Player B defeats A. Timer must go to neutral (1 minute) then start capture. Currently 4 minutes total to capture
Player B fully captures. Guild 2 owns. Event spawns NPC's.
Player A comes back at 5 minutes. Contests because the protection of 10 minutes hasn't started. Must fight B and NPC's. B can't attack NPC's due to configuration making them friendly.
A kills B and NPC's. Begins capture. Must tick 3 minutes to neutral (1player @1 ticket/second) . Any NPC's despawn on neutral
B returns 1 minute in, timer pauses. B dies
A waits 2 minutes. Captures point. NPC's spawn and guild 1 is now owner.
B comes back 15 minutes later. The point is protected and he can't contest it. Proceeds to be attacked by all NPC's. B can't contest the point for another 175 minutes.

Would need a new UI element like a progress bar to show capture progress.

Explanation of contest behavior types

Pause - If members from more than one side are present, capture progress stops.
Decay to Neutral - If contested by more than one side, it will still decay to neutral but make no progress towards any one side.
Decay to Previous State - If contested by more than one side, point decays to previous state. If owned and owner has someone contesting, it will decay back to owned. If owner is not present, it will decay to neutral.
Weighted - Will decay in the direction of most support. If owned and more owners present, it fills back to ownership. If more others, it'll go neutral then start filling towards the highest numbered side. Can take capture speed into account for multiple players.

===

I understand this is big. I hope it's something deemed good for the base engine so either someone would take it on or if I commission it then maybe it can be submitted then.

[xZACKYx]

I love it

[xZACKYx]

This could be anything from a multiplayer mini game to a scalable faction server, very good idea.

[WeylonSantana]

I believe it's very specific, I've played many role-playing games throughout my life, and I've seen a system like this or similar in very few games. not to mention that if we were to do something like this, to be very generic, many options would have to be created, and many other things would have to be modified, it also shouldn't be worth the cost of maintaining maintenance over time

[PyroTech03]

There's many games that do control points for territory. Planetside 2, New World, Shadowbane, Crowfall, Elderscrolls Online, Albion Online, Black Desert Online, Guild Wars 2 ,Eve Online, the new Dune MMO and Pax Dei.... Lots of MMO's have methods for controlling territory and making use of resources belonging to it.

But it can be applicable beyond that as well. There's many games that have wave clear encounters (using a single point to run the waves in a timer). Another puzzle element for dungeons.

It's a very specific feature yes. But to say it's in very few I think just means you're playing different genre of MMO's. Almost anything with a larger PvP element has something similar.

If the technical upkeep is the reason, that's beyond me so I have to take your word for it. @AlexVild (daywalker if I tagged right) has done something similar for MAO. So might be able to give insight.

[Arcondes]

Yes, is a little specific. But only a little. In fact I think we should redefine that term "very specific." Since I joined the Intersect community I have seen many proposals categorized like this (some even mine) that are not so specific. Most of us have seen it in some way in one game or another, like the case at hand now. Anyway, I agree with this, but its field of application can be expanded.

[PyroTech03]

This can be used for anything with a central component needing to be done on a visible timer. Yes, my main example is of course being able to capture/control territories. But I can see it being used to do wave based rooms where you spawn enemies, and have subsequent waves. I can see it as dungeon puzzles. It's litterally just depending on what you can do with the event system, variables, and the timer attribute. Sure, you can possibly do any of this with the current event system, but then you see a common thread of "it'll be janky" or "rough looking" to do it.

It's another tool, and I am very passionate and forward about allowing for more tools to give the developers.

And yes, there are many features that get deemed "too specific" I feel. Usually because it comes down to you can't do one a way that will make everyone happy, which if thats the goal then it's unattainable. Giving baseline that can be worked from though can go a long way. Recent examples I can think of in the past 6 months would be player shops, housing, and pets/summons. Mounts could be another in this. But those are all very different conversations not proper for here.

Thank you for coming and posting feedback. :)

[WeylonSantana]

@Arcondes @PyroTech03 (Replying to both comments here in the third comment)
In fact I think we should redefine that term "very specific."
For me, very specific would not be so applicable to all games, I see things in the source that are very specific that no intersect user has used to date (even me), but this has to do with the developers of that time, another definition of very specific is when the idea is common in games but there are infinite different ways to implement it (pets for example), which makes it unusable for the engine, leaving it open to "everyone do their own"

In my opinion, the proposed idea encompasses both definitions, I will mention some points
This is a system that allows for taking and holding of territory. - in itself this is a system that has different ways of application and I haven't seen many games use something like this(not be so applicable to all games)

This rendition uses a ticket system as it can handle time and multiple combatants easier but definitely up to the idea of making it time based. - a system that needs two other possible systems to work, per ticket or per time, another point of specificity

implementation, rules, etc - yes, this is super specific
the objective is system that allows for taking and holding of territory.

in addition to all this implementation above

• Can I create a system where I can take territories just by killing people from the enemy guild?
• Can I create a system where I can take territories just by destroying the enemy base/core?
• Can I create a system where I can take territories by performing specific tasks and the guild that accomplishes them all first wins?

I can apply this system/objective (take territories) to guilds, parties, players in pvp events, or even just being pve too, and the above implementation does not cover all these possibilities.

It's a very specific feature yes. But to say it's in very few I think just means you're playing different genre of MMO's.
You, like me, must know that the mmo itself is not limited to just big games, so listing specific games does not make the idea valid for addition to the engine that anyone will use, in fact it only proves my point: they are specific games that have the system and not all games in the genre MMO, the games listed do not represent the MMO genre itself, they are just part of it, and did all the games listed implement the system in exactly the same way as you are proposing? If that were the case then yes, the MMO genre itself would have a unique rule for implementing a territory capture system and we should do the same.

you can possibly do any of this with the current event system, but then you see a common thread of "it'll be janky" or "rough looking" to do it.
And for me this is the most important point and now I'm going to give the most useful tip when giving ideas here, this is what works for me, if you want to propose ideas for an engine, don't propose entire systems, they are usually very specific (this, pet, mount, houses, etc.), it's not because some games have that all game engines should have, take your ideas and do the process called abstraction, take the important points of what is necessary to realize the system and abstract functions from it, things that are useful and necessary for the realization of your system, I will do part of your work so you understand my point

1 - You need timers and for them to appear on the screen, so ask for a system of timers, which are increasing or decreasing and which activate some common event when reaching 0 (when decreasing) or some specific point (when increasing) and show a new window when the timer is active.

2 - You need a progress bar that appears only for those players who are competing for territory, so ask that the announcement window (when the server sends announcements or we type \annoucement) can be activated by events, which supports variable values and that may have conditions so that the server only sends to players who meet these conditions

another exemple
summon system - #2262 (the way it was formulated, yes, just complementing what already exists, to achieve the objective, no)

Wouldn't these two be very useful for you to have your system? the rest of this entire system could be carried out with events using variables, etc., and both suggestions would be useful for hundreds of other things that other devs could use, but not the other way around, the entire system will have this and the devs who won't using the system cannot use these two suggestions

When suggesting systems, see what is missing for it to be carried out and it will probably be useful for everyone too, see what is missing to complement events and the like, this way we won't need to change more than 5000-10000 lines and the review will take 2-3 months, we would need to change just a few and enter the base in a few days after sending the pr.