Author Topic: Domination  (Read 28062 times)

bob0

  • Posts: 80
  • Turrets: +11/-9
Domination
« on: August 10, 2010, 06:57:00 am »
(http://superpie.org/patches/domination/ - patches for revision 2 and newer are in below post)

The primary aim of domination is to fix camping.  It works by rewarding players who don't stay in their base when it isn't necessary and capture "domination points".  The goal is to put campers at a disadvantage to those who are rewarded for capturing domination points, which can only be captured by leaving their base; and to "eliminate the 'Sudden Death' hack".

Domination points, also referred to as control points, are entities that can be built by a construction kit during devmap mode.  When the layout is saved, the control points that were built are contained in the layout.  When that layout is loaded with the level, the domination points are spawned in the same positions they were created.  Whenever zero domination points exist, gameplay is unchanged.
(It should be noted that there is currently a quirk with point building: when you select a point ghost, all the buildables and points will appear to disappear, and will remain in that state until you cancel the blueprint ghost of (perhaps another) point.)  In the future, mappers should be able place domination points directly in their map, as they can with any buildable (work has already been done to place location entities in older maps that originally did not have them).

Domination points can be captured by members of either team by running over them.  In non-instant domination, domination points take time to recapture.  Each player of a team has equal weight; multiple players will capture a point quicker.  With the current settings, humans capture in non-instant domination slightly faster than aliens.

Control points can currently affect some things (gameplay is the same otherwise: a team wins by destroying the enemy team's spawns and players):

Code: [Select]
// better or worse by 50% * scale
#define DOMINATION_ALIEN_BP_SCALE         0.95f
#define DOMINATION_HUMAN_BP_SCALE         0.6f
#define DOMINATION_ALIEN_BPQUEUE_SCALE    1.0f
#define DOMINATION_HUMAN_BPQUEUE_SCALE    1.0f
#define DOMINATION_ALIEN_FREEFUNDS_SCALE  1.5f
#define DOMINATION_HUMAN_FREEFUNDS_SCALE  1.0f
#define DOMINATION_ALIEN_BUILDTIMER_SCALE 1.0f
#define DOMINATION_HUMAN_BUILDTIMER_SCALE 0.75f
#define DOMINATION_ALIEN_HEAL_SCALE       1.0f
#define DOMINATION_HUMAN_MEDI_HEAL_SCALE  2.0f
#define DOMINATION_HUMAN_MEDK_STARTUP_TIME_SCALE 2.0f
#define DOMINATION_POISON_DMG_SCALE       0.5f
#define DOMINATION_POISON_TIME_SCALE      1.0f
#define DOMINATION_BOOST_TIME_SCALE       1.0f
#define DOMINATION_POISON_CLOUD_TIME_SCALE 0.9f

#define INSTANT_DOMINATION_ALIEN_BP_SCALE                0.95f
#define INSTANT_DOMINATION_HUMAN_BP_SCALE                0.6f
#define INSTANT_DOMINATION_ALIEN_BPQUEUE_SCALE           1.0f
#define INSTANT_DOMINATION_HUMAN_BPQUEUE_SCALE           1.0f
#define INSTANT_DOMINATION_ALIEN_FREEFUNDS_SCALE         1.5f
#define INSTANT_DOMINATION_HUMAN_FREEFUNDS_SCALE         1.0f
#define INSTANT_DOMINATION_ALIEN_BUILDTIMER_SCALE        1.0f
#define INSTANT_DOMINATION_HUMAN_BUILDTIMER_SCALE        0.75f
#define INSTANT_DOMINATION_ALIEN_HEAL_SCALE              2.0f
#define INSTANT_DOMINATION_HUMAN_MEDI_HEAL_SCALE         2.0f
#define INSTANT_DOMINATION_HUMAN_MEDK_STARTUP_TIME_SCALE 2.0f
#define INSTANT_DOMINATION_POISON_DMG_SCALE              0.5f
#define INSTANT_DOMINATION_POISON_TIME_SCALE             1.0f
#define INSTANT_DOMINATION_BOOST_TIME_SCALE              1.0f
#define INSTANT_DOMINATION_POISON_CLOUD_TIME_SCALE       0.9f

They can be temporary disabled by setting the scale values to 0.


[Domination point D captured by aliens with a few tubes around it]

I expect and hope that most of these will probably be disabled or removed, especially the more obscure ones; and that every setting will at least be changed.  These values were chosen rather arbitrarily; I have not been able to test much because of lack of players.  In hindsight, it changed more than it probably should have, and I don't remember why the human healing settings were set so high.

An idea that I've wanted to try is that queue time is to make the only setting affected by the number of control points captured the BP queue, where, perhaps, the BP return rate could be increased or decreased linearly completely by 100%; in other words, if the enemy has all the points captured, the camping team's queue would not return any points at all, and the team would be rewarded for going out of their base and capturing points even if they aren't building at the time since they'd get their points back; in addition to the small amount of funds awarded for capturing a point (even less in instant domination; this setting can be changed in the Domination section of tremulous.h); it is hoped that it is enough motivation to deter campers and punish them so that staying in their base and not capturing points will be to their disadvantage.  A team whose players never leave their base even at the more inactive times will be more vulnerable to attack, assuming that the other team doesn't also camp in their base and instead captures the control points.  But there is a problem: if the aliens lack resources; perhaps because either they've used them to attack the other team or the game has begun; they will be unable to fight against a camping human team, even though they can't get build points returned from destroyed buildables, because the aliens aren't able to destroy them without funds.  A solution is to make control points affect funds: a static one-time reward for the individual player who captured the points, and a faster free fund rate for the more aggressive team.  A balance is needed (which these current settings clearly lack; this will hopefully change): if the effects are too much, games will be too fragile end too quickly, as teams will be less able to defend their base when they really need to, which is when the enemy is attacking.

There are two settings of Domination (besides its being off completely when no domination points are spawned): instant domination and non-instant domination.  Either setting may eventually be removed.  Some servers might enable changing this setting on map-change by vote.  Instant might be appropriate for smaller games, and non-instant otherwise; but I haven't played enough to be sure.  A possible idea is to make capture time proportional to the size of each team (which might even make unequal team sizes fairer).

Layouts that contain domination points but are otherwise identical are traditionally named "dom", but the name of the layout is not important.

I've attached a patch that contains, in addition to the models, source, configs, etc., very untested "dom" layouts for the following maps:
Code: [Select]
1984b4               cruz-b2      niveus            transit
ancient_remains_1-0  fap          outpost_p4_beta4  tremor
arachnid2            gloom2beta2  procyon-r1        uncreation
atcs                 karith       sectorb17         utcs
atcs3                metro-b1-2   sokolov-1.0       utcsb2
atcszalpha           nano         temple            veddak-final
atcszalpha-b2        nexus6       thanatos_b3

Sudden death is disabled in domination!

A few other minor things to note: When a point is captured, it behaves as a free repeater with its own zone for the team who captured it (this behaviour can be changed in the future if there is ever a need).  It is also forbidden to build a reactor or overmind too close to a domination point, because if a team's base is too close to a point, then they will be able to camp it with the aid of their base, defeating the purpose of domination for that control point.  There might be a need for a more elaborate method to prevent building in areas too close to domination points (perhaps the reactor/om must be visible from the point).  Of course, every map has areas that are more advantageous to build in than others, which the enemy team should make an effort to avoid; but it shouldn't be too easy for a team to build a too advantageous spot.  In non-instant domination, buildables currently have a small weight, so repeaters or eggs can be built near a point (not directly in the center of it) or other buildables if there is outside power to help capture it, making building more fun.  If buildables have been built near an already captured point, the point will recover faster when the enemy fails to clear it completely.  In instant domination, buildables also have a small amount of weight, further adding to the benefits of building.  But in instant domination, it's a little bit different: the buildables will need to be built somewhat close to the point (and, once again, not right in the center) to make an effect; if they are too far away, a player can walk over the point without having to destroy your buildable, and then it will be unpowered or blow up without alien creep.  The distance for buildables can be changed for balance, and their weight can even be disabled completely.  The current short distance keeps them from being too obtrusive or obnoxious.

In the future there might be "timer" functionality in which a timer starts from an arbitrary setting and something happens when it reaches 0, such as the reactor/om being destroyed, the team losing (not fun in my opinion), or something; the timer might or might not be reset.  At the present, nothing extra special happens when your team has all the points captured besides the settings mentioned earlier (which should already have a big impact, for the better).

Repeaters were originally a special case for build point zones.  Instead of also treating domination points specially, I've generalized the BP zone code.  The new "zone" flag defined in the buildableAttributes structure is set to true for repeaters and domination points.  The cvars "g_humanRepeaterBuildPoints", "g_humanRepeaterBuildQueueTime", and "g_humanRepeaterMaxZones" have thus been renamed to "g_zoneHumanBuildPoints", "g_zoneHumanBuildQueueTime", "g_zoneAlienBuildPoints", "g_zoneAlienBuildQueueTime" (all four of which were originally two settings not split by team), and "g_zoneMax".

These cvars and commands have also been added:
g_instantDomination: Instant domination setting.  This can be set in "server.cfg" for an initial setting.
g_nextInstantDomination: "callvote instant_domination" sets this; its value is checked on map load, g_instantDomination is set to that value if it isn't empty, and g_nextInstantDomination is cleared
g_disableDomination: If this is set, domination points won't be spawned.  Layouts that contain domination points can still be loaded, but the domination points won't be loaded, so gameplay will be unchanged by domination.
g_disableVoteInstantDomination: Enable or disable calling a vote to change instant domination setting on map-change.
g_zoneHumanBuildPoints: Number of build points that a human BP zone will provide to the human team (this value itself could be changed based on the number of points the team has captured, depending on the balance settings).
g_zoneHumanBuildQueueTime: In ms.
g_zoneAlienBuildPoints: Number of build points that an alien BP zone will provide to the alien team.
g_zoneAlienBuildQueueTime: In ms.
g_zoneMax: This setting primarily exists for memory management, and usually shouldn't be changed.  It should be reasonable high; the default is 512.  This doesn't prevent new buildables from being built; it caps the number of allocated zones.
callvote instant_domination 0: if g_disableVoteInstantDomination is not enabled, call a vote to turn instant domination off for the next game (still needs to be added to the UI)
callvote instant_domination 1: if g_disableVoteInstantDomination is not enabled, call a vote to turn instant domination on for the next game (still needs to be added to the UI)
Settings for "g_humanRepeaterBuildPoints", "g_humanRepeaterBuildQueueTime" and "g_humanRepeaterMaxZones" should be changed in server.cfg, since they've been renamed.

The effectiveness of the placement of the points in these layouts has not been able to be determine, and most of the newer ones have not been extensively (or much at all) tested, so suggestions and contributions are, of course, welcome.

Thanks Risujin, for the original implementation and idea.  I've since ported it to be compatible with the most recent code and rewrote and cleaned up a lot of it.

Update: Settings have been updated (most disabled):
Code: [Select]
// better or worse by 50% * scale
#define DOMINATION_ALIEN_BP_SCALE                        0.4f
#define DOMINATION_HUMAN_BP_SCALE                        0.25f
#define DOMINATION_ALIEN_INV_BPQUEUE_SCALE               2.0f
#define DOMINATION_HUMAN_INV_BPQUEUE_SCALE               2.0f
#define DOMINATION_ALIEN_FREEFUNDS_SCALE                 2.5f
#define DOMINATION_HUMAN_FREEFUNDS_SCALE                 1.5f
#define DOMINATION_ALIEN_BUILDTIMER_SCALE                0.0f
#define DOMINATION_HUMAN_BUILDTIMER_SCALE                0.0f
#define DOMINATION_ALIEN_HEAL_SCALE                      1.0f
#define DOMINATION_HUMAN_MEDI_HEAL_SCALE                 0.0f
#define DOMINATION_HUMAN_MEDK_STARTUP_TIME_SCALE         0.0f
#define DOMINATION_POISON_DMG_SCALE                      0.0f
#define DOMINATION_POISON_TIME_SCALE                     0.0f
#define DOMINATION_BOOST_TIME_SCALE                      0.0f
#define DOMINATION_POISON_CLOUD_TIME_SCALE               0.0f

#define INSTANT_DOMINATION_ALIEN_BP_SCALE                0.4f
#define INSTANT_DOMINATION_HUMAN_BP_SCALE                0.25f
#define INSTANT_DOMINATION_ALIEN_INV_BPQUEUE_SCALE       2.0f
#define INSTANT_DOMINATION_HUMAN_INV_BPQUEUE_SCALE       2.0f
#define INSTANT_DOMINATION_ALIEN_FREEFUNDS_SCALE         2.5f
#define INSTANT_DOMINATION_HUMAN_FREEFUNDS_SCALE         1.5f
#define INSTANT_DOMINATION_ALIEN_BUILDTIMER_SCALE        0.0f
#define INSTANT_DOMINATION_HUMAN_BUILDTIMER_SCALE        0.0f
#define INSTANT_DOMINATION_ALIEN_HEAL_SCALE              1.0f
#define INSTANT_DOMINATION_HUMAN_MEDI_HEAL_SCALE         0.0f
#define INSTANT_DOMINATION_HUMAN_MEDK_STARTUP_TIME_SCALE 0.0f
#define INSTANT_DOMINATION_POISON_DMG_SCALE              0.0f
#define INSTANT_DOMINATION_POISON_TIME_SCALE             0.0f
#define INSTANT_DOMINATION_BOOST_TIME_SCALE              0.0f
#define INSTANT_DOMINATION_POISON_CLOUD_TIME_SCALE       0.0f
« Last Edit: October 09, 2010, 04:10:12 pm by bob0 »
bob

Demolution

  • Posts: 1198
  • Turrets: +157/-64
Re: Domination
« Reply #1 on: August 10, 2010, 08:37:13 am »
Hah, so you were actually working on it all this time. Hope to see people playing it. :)

Clan [AC] - For all your air conditioning needs please visit: http://s1.zetaboards.com/AC_NoS/index/
my brain > your brain.
and i am VERY stupid.

Aelita

  • Posts: 742
  • Turrets: +147/-34
Re: Domination
« Reply #2 on: August 10, 2010, 09:32:50 am »
Awesome! Is there a server up?

Demolution

  • Posts: 1198
  • Turrets: +157/-64
Re: Domination
« Reply #3 on: August 10, 2010, 10:53:44 pm »
When GPP was released bob had a server up, but it hasn't shown up lately.

Clan [AC] - For all your air conditioning needs please visit: http://s1.zetaboards.com/AC_NoS/index/
my brain > your brain.
and i am VERY stupid.

UniqPhoeniX

  • Spam Killer
  • *
  • Posts: 1376
  • Turrets: +66/-32
Re: Domination
« Reply #4 on: August 10, 2010, 11:55:57 pm »
Domination would be great, but if this is basically the Risujin's implementation/layouts, it won't work IMO.
These are my ideas on how Domination should be implemented:
Up to 4 Domination Points (like in Risujin's layouts) means a team only needs to control up to 2 (or maybe only stop the other team from capturing those 2), which is too easy, and allows a team to camp with little effort. There should be at least 6, preferably 8 per map, requiring a team to defend ~3 areas (unless they camp, in which case other team gets 3x the DPs).
Having 1 in each usual base location and assuming that RC/OM will always be at a DP means you don't have to limit the ability to build RC/OM near a DP (since 'near' would probably be a spherical area reaching through walls and could also affect building in adjacent rooms).
Even ATCS can fit 4*2 DPs (1 in either side of either base, 2 in bunker, 2 mid tunnel), splitting teams in 2 (front and back path) and requiring buildings to be spread out more.

Making capture time depend on team size is a great idea tho.

And yes, captured DPs need to give a steady income of funds to avoid draining the aggressive team with extreme camping.

Preferably also 20-40 BPs (depending on campability of the location; would mean amount is not controllable by a cvar) usable near that DP, so it can be secured and a single good player in the camping team can't capture many DPs as quickly. Considering RC/OM would usually be at a DP, default BPs may be reduced. Default BPs should be usable anywhere, tho this requires the ability to choose what is powering a buildable.

Crava_Loft

  • Guest
Re: Domination
« Reply #5 on: August 11, 2010, 12:07:35 am »
[deleted]
« Last Edit: August 11, 2010, 01:05:58 pm by Crava_Loft »

bob0

  • Posts: 80
  • Turrets: +11/-9
Re: Domination
« Reply #6 on: August 11, 2010, 05:26:38 am »
Domination would be great, but if this is basically the Risujin's implementation/layouts, it won't work IMO.
These are my ideas on how Domination should be implemented:
Up to 4 Domination Points (like in Risujin's layouts) means a team only needs to control up to 2 (or maybe only stop the other team from capturing those 2), which is too easy, and allows a team to camp with little effort. There should be at least 6, preferably 8 per map, requiring a team to defend ~3 areas (unless they camp, in which case other team gets 3x the DPs).
Having 1 in each usual base location and assuming that RC/OM will always be at a DP means you don't have to limit the ability to build RC/OM near a DP (since 'near' would probably be a spherical area reaching through walls and could also affect building in adjacent rooms).
Even ATCS can fit 4*2 DPs (1 in either side of either base, 2 in bunker, 2 mid tunnel), splitting teams in 2 (front and back path) and requiring buildings to be spread out more.

Making capture time depend on team size is a great idea tho.

And yes, captured DPs need to give a steady income of funds to avoid draining the aggressive team with extreme camping.

Preferably also 20-40 BPs (depending on campability of the location; would mean amount is not controllable by a cvar) usable near that DP, so it can be secured and a single good player in the camping team can't capture many DPs as quickly. Considering RC/OM would usually be at a DP, default BPs may be reduced. Default BPs should be usable anywhere, tho this requires the ability to choose what is powering a buildable.

The idea of more domination points sounds interesting, but I only have models for A-D, which Risujin made, and I'm not familiar with any model manipulation programs.  But updating the layouts is one of the simplest things to do for Domination, fortunately (just devmap, build and layoutsave with a qvm that includes domination).  Removing the Reactor / Overmind restriction certainly does indeed seem appealing; but I do believe that, with proper settings, even <=4 domination points has a big impact on camping already, even if more points might fix the problem further.  Another thing to think about is a team's ability to build around captured points, because they act as repeaters.  It might need to be disabled to prevent players from being able to build anywhere.

Making free fund rate entirely tied to control points (which should probably be done by rewriting the existing free fund code) and capture time are also interesting ideas, but I also need specifics: what are some good default values to try initially, and how should the system work?
« Last Edit: August 11, 2010, 06:46:39 am by bob0 »
bob

bob0

  • Posts: 80
  • Turrets: +11/-9
Re: Domination
« Reply #7 on: August 11, 2010, 06:38:33 am »
Awesome! Is there a server up?

It's almost up now, and it hasn't been thoroughly tested.  I expect that I will have it working by two weeks from now (I'm going to be quite busy for these weeks; afterward I plan to test it and idle on it while I read).  Superpie has been hosting and paying for it.
« Last Edit: August 11, 2010, 06:49:52 am by bob0 »
bob

Toma

  • Posts: 55
  • Turrets: +2/-6
    • The rs clan im in
Re: Domination
« Reply #8 on: August 11, 2010, 07:33:13 am »
1.2 or 1.1?

jez

  • Posts: 130
  • Turrets: +4/-2
Re: Domination
« Reply #9 on: August 11, 2010, 08:08:59 am »
Making free fund rate entirely tied to control points (which should probably be done by rewriting the existing free fund code) and capture time are also interesting ideas, but I also need specifics: what are some good default values to try initially, and how should the system work?

The obvious way of doing it would be to simply make the rate of free funds proportional to the number of domination points controlled. If each team controlls and equal number of points, then it makes sense to supply the usual number of free funds (1 evo/225cr very 2 mins off the top of my head?). If the ratio it 75-25, then the leading team gets 50% extra, and the trailing one 50% fewer free funds.

Assuming the OM/RC is built by a dom point, a team will never really have less than 1 point, so will be unlikely to have no free funds at all.

Demolution

  • Posts: 1198
  • Turrets: +157/-64
Re: Domination
« Reply #10 on: August 11, 2010, 04:45:21 pm »

Clan [AC] - For all your air conditioning needs please visit: http://s1.zetaboards.com/AC_NoS/index/
my brain > your brain.
and i am VERY stupid.

UniqPhoeniX

  • Spam Killer
  • *
  • Posts: 1376
  • Turrets: +66/-32
Re: Domination
« Reply #11 on: August 12, 2010, 03:08:21 am »
The ability to build around the points is fine if 'around' = 'the same room'. Unfortunately that can't be done with a simple radius. Amsterdam Unlimited server has implemented domination (although it's not properly tested nor balanced afaik) where specs can create, name, move and manipulate box (push/pull any face) and sphere (change radius) shaped capture and build areas. Radius of capture spheres in the layouts I made was 60 gu, and the center was ~32 gu above ground.

The capture time should be about... 20 sec if 1/6th the team is capturing it? So (3.33 * team size / amount of players capturing). If there are players from the other team there too, they should be able to slow/stop it. Buildables should also slow/stop other team from taking over the DP, maybe have weight 1/2 that of a player, but I don't think buildings should help a team capture it faster.

There may be problems with deciding what is powered by the DP and what by RC/OM, and what happens when the DP is lost.

jez: IMO the team with 75% of DPs should have slightly more then 1.5x freefunds per 2 min.
Maybe "((captured / total DPs) * 2) ^ 2" ?
(( 6 / 8 ) * 2) ^ 2 = 2.25, or 1 evo per 53 sec, 7 of 8 = 3.0625, or 1 evo per 39 seconds, 8/8 = 30sec...
Or "^ 1.5" instead?
« Last Edit: August 12, 2010, 03:10:15 am by UniqPhoeniX »

bob0

  • Posts: 80
  • Turrets: +11/-9
Re: Domination
« Reply #12 on: October 09, 2010, 07:07:15 pm »
Domination patches since revision 2


I've made some adjustments.  Most significantly, there have been issues with the way control points are captured.  When gradual mode is enabled, it takes time to capture control points.  But I've received numerous complaints, and have observed myself, that waiting inactively at points tends to make the game drag and become slow-paced; these observations were made in smaller games, but I think that the problem would still exist, at least to a smaller degree, in larger games.

The alternative is instant mode.  In instant mode, the slow-paced-ness of capturing is fixed because players don't need to remain inactive at points.  But points can be changed too quickly.  There isn't a warning before a team loses build points.  They are difficult to secure.  It seems to be that, at least in a smaller game, instant domination is better, but it's still unsatisfactory to me.

I wanted to try a solution that fixes both problems: players can capture domination points as usual by moving over them, but they can start capturing just by walking over it once, and the player will then be free to choose whether to stay and defend the point from an enemy, or continue to anywhehere else at alanywhere else.  The game won't become as slow as 1.2 development is often perceived to be, points won't change too rapidly and unpredictably, and, most importantly, camping should still be fixed (with the right layouts and settings, of course).

I've tested this mode for a small while, and it seems satisfactory to me.  (Remember that in this mode, players aren't always forced to leave a point once they start capturing it; by leaving a point they risk losing control of it.)


I've also changed the parameters that domination affects:
Code: [Select]
#define DOMINATION_SCALE_BP(team)              (DRERP(team, 0.8f, 1.5f))
#define DOMINATION_SCALE_BPQUEUE_PERIOD(team)  (DRERP(team, 2.0f, 0.5f))
#define DOMINATION_SCALE_FREEFUND_PERIOD(team) (DRERP(team, 1.5f, 0.4f))

I haven't had much opportunity to test these values, but I hope to test these settings more and improve them.

This means that a team that hasn't captured any points will have 0.8 * their BP, which is 80 for humans; that a team's number of BP is unaffected when the points are captured equally; and that a team has 50% more BP when it has every point captured (remember that it still takes time for a team to use those BP).  This also includes build points for repeaters.  More significantly affected is the BP queue, which can be twice as fast or slow depending on how many points they have captured, which is also affected by their "campiness" (and skill).  It is also important to give a team enough resources to fight back against a winning team, so a team's freefund period is affected by control points, and individual players will also be rewarded with funds for starting capturing a point if and when it is captured completely.

Teams need motivation to leave their bases when it's not necessary to stay in them and capture points, and the points need to give enough advantage to help an aggressive team sufficiently against a heavily camping team, and they need to not be enough to make games end too quickly from small attacks (the determining of which seems to be at least a bit subjective).  Of course, it will take more than just being aggressive to win; skill is also advantageous, as it should be.

Individual players are still rewarded for capturing a point (still only the first client to start capturing a point is rewarded).


There is also a problem with the current ATCS dom layout.  It contains only two points, A and B.  B is located in the middle of the tunnel, and isn't much of a problem; but A is located on the top of the bunker, making "jet-camping" much more of a problem than it already is in ATCS.

Here are some alternatives that fix this issue and which I haven't tried yet, each with their own downsides:
1) A can be positioned inside in the middle.  Symmetry isn't lost, and neither team can build inside the building (while the idea described below isn't implemented), fixing a flaw: humans can build the reactor in the middle of the inside, preventing aliens from entering and the humans from exiting (but still giving humans and buildables room to shoot at the aliens), forcing the humans to camp and the game to be quite boring once their base is settled.
2) B can be made the only point, A.

Alternatively, I can incorporate F50's version of the jetpack into the domination server (in addition to domination; the domination patch will still be separate from the jetpack patch) to fix the problem  of jet-camping altogether.


Since the second revision of domination, I felt that aggressive teams should be rewarded with free funds more frequently.  This setting has been updated since:
Code: [Select]
#define DOMINATION_SCALE_FREEFUND_PERIOD(team) (DRERP(team, 1.6f, 0.25f))

so that a team who has every point captured will be given free funds every 30 seconds and the camping team will be given free funds about every 3 minutes.

The domination server at the moment only has the maps for which dom layouts exist.

Domination would be great, but if this is basically the Risujin's implementation/layouts, it won't work IMO.
These are my ideas on how Domination should be implemented:
Up to 4 Domination Points (like in Risujin's layouts) means a team only needs to control up to 2 (or maybe only stop the other team from capturing those 2), which is too easy, and allows a team to camp with little effort. There should be at least 6, preferably 8 per map, requiring a team to defend ~3 areas (unless they camp, in which case other team gets 3x the DPs).
Having 1 in each usual base location and assuming that RC/OM will always be at a DP means you don't have to limit the ability to build RC/OM near a DP (since 'near' would probably be a spherical area reaching through walls and could also affect building in adjacent rooms).
Even ATCS can fit 4*2 DPs (1 in either side of either base, 2 in bunker, 2 mid tunnel), splitting teams in 2 (front and back path) and requiring buildings to be spread out more.
This idea does seem appealing, as well as as be less restrictive on where a team can build; but I don't have models for the points beyond D.  Risujin's four models can be found in a data package.  When >= 6 points is typical, building might be more interesting, but they should probably not be as giving as they are now (perhaps smaller range or fewer BP).  I would love to implement this to try it once the models are available.  At least 12 (up to L) would be preferable, but I'll probably implement this once there are 8 (up to H) models.


Robin Lee Powell, the owner of the Lojban server (http://lojban.org/), has been kind enough to host the domination server as long as it's not too resource intensive.  The server should be running soon.
bob

Aelita

  • Posts: 742
  • Turrets: +147/-34
Re: Domination
« Reply #13 on: October 09, 2010, 07:34:27 pm »
[snip]
I've also changed the parameters that domination affects:
Code: [Select]
#define DOMINATION_SCALE_BP(team)              (DRERP(team, 0.8f, 1.5f))
#define DOMINATION_SCALE_BPQUEUE_PERIOD(team)  (DRERP(team, 2.0f, 0.5f))
#define DOMINATION_SCALE_FREEFUND_PERIOD(team) (DRERP(team, 1.5f, 0.4f))
[snip]

I read your whole post, but I kept reading DRERP() as DERP(). :(

UniqPhoeniX

  • Spam Killer
  • *
  • Posts: 1376
  • Turrets: +66/-32
Re: Domination
« Reply #14 on: October 10, 2010, 07:22:45 pm »
Good to see this hasn't completely died :)
The amount of BP should be adjustable for each DP while making the layout, since some DPs will likely be in safer locations, or closer to other DPs (like on small maps). On ATCS with those 8 DPs each could give ~20 with RC/OM giving 80-100. Having half the DPs should not mean having default BPs, since you need outposts.

For now, can't you just reuse the A-D models (until new models are available) so proper layouts can be made & tested? Or add a name to each DP (the room name usually) and same on HUD, you could do it with 1 model. Ofc adding a name & BP amount can't be done with ckit, how about just a console command? Could even be used by specs.

Still I think a method for changing what powersource something uses is needed unless you want to make DP BPs usable anywhere like RC BPs or implement some system for managing what is powered by what. Same way could be used to temporarily disable a building (to enable another) if a powersource is lost and something important is left unpowered.
How exactly to implement this tho? Some command (togglepower?) that players can bind to a key, and simple console message for what the current powersource is?

IMO the gpp build queue works fine against campers as long as the other team has funds and I don't see why the team with more DPs needs a faster build queue. Maybe each DP should just have it's own (relatively) fast queue and that's it.

About capturing: IMO the player should stay at the DP to capture it... With what settings did people complain about it slowing down gameplay?

On that ATCS layout if you move DP 'A' into the bunker & if humans build RC to block themselves inside bunker, what will stop aliens from killing the RC? If you add at least 2 more DPs to default bases, then there is no way humans can keep RC up for long at that place, especially at as2.

IMO accelerating jetpack with fuel would be awesome, making the game more fun for everyone (and over long term would remove the mapping limitation of no high/large open areas).

... anywhehere else at alanywhere else...
lolwut

bob0

  • Posts: 80
  • Turrets: +11/-9
Re: Domination
« Reply #15 on: October 13, 2010, 01:06:50 am »
Good to see this hasn't completely died :)
The amount of BP should be adjustable for each DP while making the layout, since some DPs will likely be in safer locations, or closer to other DPs (like on small maps). On ATCS with those 8 DPs each could give ~20 with RC/OM giving 80-100. Having half the DPs should not mean having default BPs, since you need outposts.
Implementing this is possible, but I don't see why the added complexity is worth it.  Why shouldn't points distribute the same amount of power (besides, of course, changing based on how many points a team has captured)?  This would also mean more effort for layout and map designers, and I don't see how this would help.

Quote
For now, can't you just reuse the A-D models (until new models are available) so proper layouts can be made & tested? Or add a name to each DP (the room name usually) and same on HUD, you could do it with 1 model. Ofc adding a name & BP amount can't be done with ckit, how about just a console command? Could even be used by specs.
I could, but it would be difficult to differentiate between points when they are being attacked (most significantly), and it might cause difficulties with communication, at least when the same letters are located in the same area, which should be avoided by layout designers.  On the other hand, trying this with more points does seem appealing.

Quote
Still I think a method for changing what powersource something uses is needed unless you want to make DP BPs usable anywhere like RC BPs or implement some system for managing what is powered by what. Same way could be used to temporarily disable a building (to enable another) if a powersource is lost and something important is left unpowered.
How exactly to implement this tho? Some command (togglepower?) that players can bind to a key, and simple console message for what the current powersource is?
This has always been handled, since I wrote the code for the new repeater behaviour which enables repeaters to provide their own energy from the reactor.  The reactor is chosen first if buildables are within range.

Quote
IMO the gpp build queue works fine against campers as long as the other team has funds and I don't see why the team with more DPs needs a faster build queue. Maybe each DP should just have it's own (relatively) fast queue and that's it.
It does, but it weakens camping teams even more and helps aggressive teams attack.  A team that is aggressive most of the game can handle a few relatively short periods of defence.  I'm not certain what the value should be, or even if will stay, but I would like to test it.

Quote
About capturing: IMO the player should stay at the DP to capture it... With what settings did people complain about it slowing down gameplay?
After playing some games, I believe that not requiring players to stay at points seems is one of the most important changes.  This is especially important when there will be many points; requiring players to stay at each of the many points to capture it would really make the game drag.

Quote
IMO accelerating jetpack with fuel would be awesome, making the game more fun for everyone (and over long term would remove the mapping limitation of no high/large open areas).
I actually did try F50's patch, but turning on my jetpack usually caused me to be teleported to somewhere in the void, with my speedometer showing lots of digits, and gradually but quickly lose my health until I died about two seconds later.  The CP's were annoying and unnecessary, and so was the malfunctioning when a player was moving faster than some point (which seems arbitrary and unnecessary to me); but otherwise it seemed good.
« Last Edit: October 13, 2010, 01:55:52 am by bob0 »
bob

F50

  • Posts: 740
  • Turrets: +16/-26
Re: Domination
« Reply #16 on: October 13, 2010, 03:55:29 pm »
I actually did try F50's patch, but turning on my jetpack usually caused me to be teleported to somewhere in the void, with my speedometer showing lots of digits, and gradually but quickly lose my health until I died about two seconds later.  The CP's were annoying and unnecessary, and so was the malfunctioning when a player was moving faster than some point (which seems arbitrary and unnecessary to me); but otherwise it seemed good.

Teleported? I'd love it if you could give me a demo of this, that is not something that makes sense to me.

The malfunctioning is mainly to prevent a dodge+jetpack combo, which is similar to the dodge strafe jump that people were complaining about earlier in GPP. How the heck you're getting that fast without trying to exploit dodge is beyond me. If you feel the malfunctioning threshold is too low however, I might see if I can raise it a little bit.

If you're interested in using it, I am more than happy to make a few changes. If the CPs are annoying, I'll remove them.
"Any sufficiently advanced stupidity is indistinguishable from malice." -- Grey's Law


UniqPhoeniX

  • Spam Killer
  • *
  • Posts: 1376
  • Turrets: +66/-32
Re: Domination
« Reply #17 on: October 13, 2010, 05:14:33 pm »
Good to see this hasn't completely died :)
The amount of BP should be adjustable for each DP while making the layout, since some DPs will likely be in safer locations, or closer to other DPs (like on small maps). On ATCS with those 8 DPs each could give ~20 with RC/OM giving 80-100. Having half the DPs should not mean having default BPs, since you need outposts.
Implementing this is possible, but I don't see why the added complexity is worth it.  Why shouldn't points distribute the same amount of power (besides, of course, changing based on how many points a team has captured)?  This would also mean more effort for layout and map designers, and I don't see how this would help.
Because different locations require different amounts of effort to capture/defend (especially BPs needed to reasonably secure it) and give different benefits based on distance to enemy etc, thus the locations have different values.
Quote
Quote
For now, can't you just reuse the A-D models (until new models are available) so proper layouts can be made & tested? Or add a name to each DP (the room name usually) and same on HUD, you could do it with 1 model. Ofc adding a name & BP amount can't be done with ckit, how about just a console command? Could even be used by specs.
I could, but it would be difficult to differentiate between points when they are being attacked (most significantly), and it might cause difficulties with communication, at least when the same letters are located in the same area, which should be avoided by layout designers.  On the other hand, trying this with more points does seem appealing.
If each point had a name that was shown on HUD instead of the letter, there would be no difficulties differentiating them, and players that don't remember what location each letter corresponds to can also figure it out more easily if they at least know the map.
Quote
Quote
Still I think a method for changing what powersource something uses is needed unless you want to make DP BPs usable anywhere like RC BPs or implement some system for managing what is powered by what. Same way could be used to temporarily disable a building (to enable another) if a powersource is lost and something important is left unpowered.
How exactly to implement this tho? Some command (togglepower?) that players can bind to a key, and simple console message for what the current powersource is?
This has always been handled, since I wrote the code for the new repeater behaviour which enables repeaters to provide their own energy from the reactor.  The reactor is chosen first if buildables are within range.
But for example when you have RC area covering a DP area, and you build at the DP, then those buildings would use RC power, and if then you want to use those RC BPs elsewhere, you'd have to replace those buildings and then rebuild them.
Quote
Quote
IMO the gpp build queue works fine against campers as long as the other team has funds and I don't see why the team with more DPs needs a faster build queue. Maybe each DP should just have it's own (relatively) fast queue and that's it.
It does, but it weakens camping teams even more and helps aggressive teams attack.  A team that is aggressive most of the game can handle a few relatively short periods of defence.  I'm not certain what the value should be, or even if will stay, but I would like to test it.
Well testing is fine of course, but I think it will add unneeded complexity and perhaps make the game TOO volatile and making comebacks nearly impossible. A more aggressive team doesn't necessarily have to win ASAP, the point is to keep the game dynamic and fun. If the campers DO come out, they should still have some chance.
Quote
Quote
About capturing: IMO the player should stay at the DP to capture it... With what settings did people complain about it slowing down gameplay?
After playing some games, I believe that not requiring players to stay at points seems is one of the most important changes.  This is especially important when there will be many points; requiring players to stay at each of the many points to capture it would really make the game drag.
Well that doesn't answer my question tho. In a previous post I said IMO it should depend on the percentage of the team present (3.33 * team size / amount of players capturing: 30sec for 1 player of 9 in team capturing it, 10s for 3/9 players, this does seem excessive tho, maybe 2 * instead?).
Wouldn't simply speeding it up be enough (just asking, haven't played enough domination games really)? Considering how much faster aliens are i think they will usually capture more points at start and keep control of more unsecured points especially if they don't have to wait at each DP. The longer it takes, the more equal the time required by either team to get to a point + capture it, tho it could simply take a bit longer to capture for aliens. Also capturing points alone is not supposed to be really fast, especially if you got lots of teammates doing nothing.

About the jet: wouldn't simply capping the speed and slowing down when going faster be better then malfunction?
« Last Edit: October 13, 2010, 05:23:43 pm by UniqPhoeniX »

bob0

  • Posts: 80
  • Turrets: +11/-9
Re: Domination
« Reply #18 on: October 14, 2010, 03:17:37 am »
Because different locations require different amounts of effort to capture/defend (especially BPs needed to reasonably secure it) and give different benefits based on distance to enemy etc, thus the locations have different values.
I still don't see why that makes it necessary to arbitrarily set each individual point to a number of BP.  Different locations are more difficult to capture, and that can make them more important to pay attention to, adding more strategy to the game.  Different places in maps are better than others for bases (even for different teams) and require different minimum amounts of BP to be stable, and there aren't any special volumes in which arbitrary values of BP are chosen (which would require a lot of effort from map designers; admittedly, the effort required for setting values for domination points is much less, in comparison).  It's not necessary to guarantee that every point can be well secured by a team.

Quote
If each point had a name that was shown on HUD instead of the letter, there would be no difficulties differentiating them, and players that don't remember what location each letter corresponds to can also figure it out more easily if they at least know the map.
This seems to be a good idea, and I intend to have that implemented in the future, when I have time and get around to it (even if the models are already available).

Quote
Well testing is fine of course, but I think it will add unneeded complexity and perhaps make the game TOO volatile and making comebacks nearly impossible. A more aggressive team doesn't necessarily have to win ASAP, the point is to keep the game dynamic and fun. If the campers DO come out, they should still have some chance.
I understand your point, and you might be right, but I want to test the setting in games before I change it.  With the current settings the game shouldn't be too volatile and change too quickly, making a team able to suddenly win when they are suddenly aggressive after camping for a long time and come-backs very difficult; but only testing will confirm that.

Quote
Well that doesn't answer my question tho. In a previous post I said IMO it should depend on the percentage of the team present (3.33 * team size / amount of players capturing: 30sec for 1 player of 9 in team capturing it, 10s for 3/9 players, this does seem excessive tho, maybe 2 * instead?).
Wouldn't simply speeding it up be enough (just asking, haven't played enough domination games really)? Considering how much faster aliens are i think they will usually capture more points at start and keep control of more unsecured points especially if they don't have to wait at each DP. The longer it takes, the more equal the time required by either team to get to a point + capture it, tho it could simply take a bit longer to capture for aliens. Also capturing points alone is not supposed to be really fast, especially if you got lots of teammates doing nothing.
Larger games are often played on larger maps and more scattered.  A team can already capture a point faster when multiple players are near it.

I've played many games in which players had to stay at points with different capture speeds.  Frankly, they became somewhat unexciting because most of the time nothing happened when players captured points.  When the capture speeds were too quick (closer to instant domination), the games were too volatile.  A point is, of course, very vulnerable when a player chooses to leave it, and it can be reversed immediately by the other team.  Since humans are less mobile than aliens, they take less time to capture points (the difference is even larger when a captured point is being attacked).  I would like to invite you to play some games on the current domination server; unfortunately, my schedule's somewhat busy in the very near future.


Teleported? I'd love it if you could give me a demo of this, that is not something that makes sense to me.
I'll search in my archives and post hopefully soon.

Quote
The malfunctioning is mainly to prevent a dodge+jetpack combo, which is similar to the dodge strafe jump that people were complaining about earlier in GPP. How the heck you're getting that fast without trying to exploit dodge is beyond me. If you feel the malfunctioning threshold is too low however, I might see if I can raise it a little bit.
That's understandable, and I was unaware of that.  However, I think a more elegant solution would be to simply prevent players from starting their jetpack during a dodge.  Dodge-jump was fixed in a similar manner, preventing players from jumping right after a dodge, instead of capping the speed of players.

Quote
If you're interested in using it, I am more than happy to make a few changes. If the CPs are annoying, I'll remove them.
I would like to incorporate it into the domination server once it's functional and polished a bit.  The CPs seem inappropriate for this.  If they're really that necessary, the UI (and making it optional with a cvar, as most of the UI already is) would be much more appropriate, but adding to the UI is not essential yet at this point.  The pounce and luci bars would probably serve as a sufficient paradigm for jetpack fuel.
bob

UniqPhoeniX

  • Spam Killer
  • *
  • Posts: 1376
  • Turrets: +66/-32
Re: Domination
« Reply #19 on: October 14, 2010, 03:32:45 pm »
I still don't see why that makes it necessary to arbitrarily set each individual point to a number of BP.  Different locations are more difficult to capture, and that can make them more important to pay attention to, adding more strategy to the game.  Different places in maps are better than others for bases (even for different teams) and require different minimum amounts of BP to be stable, and there aren't any special volumes in which arbitrary values of BP are chosen (which would require a lot of effort from map designers; admittedly, the effort required for setting values for domination points is much less, in comparison).  It's not necessary to guarantee that every point can be well secured by a team.
I don't think it will add more strategy to the game if every game everyone focuses on the same 'awesome' DPs, and wants base in that one 'right' location. The mapper only needs to balance the points to the best of his ability, it doesn't have to be perfect. If the DPs can be placed in radiant, adding keys (like BP value) to it will be easy. The amount of BP is a very easy way to balance the value of each location IMO.

bob0

  • Posts: 80
  • Turrets: +11/-9
Re: Domination
« Reply #20 on: October 15, 2010, 01:36:19 am »
I don't think it will add more strategy to the game if every game everyone focuses on the same 'awesome' DPs, and wants base in that one 'right' location. The mapper only needs to balance the points to the best of his ability, it doesn't have to be perfect. If the DPs can be placed in radiant, adding keys (like BP value) to it will be easy. The amount of BP is a very easy way to balance the value of each location IMO.

The location of every control point can already be controlled.  Domination points should never be  very difficult to attack.  Like forward bases, they should be weak enough.  Some locations are easier to defend and require less BP than others, but they should all be reasonably attackable.  Each point has an equal affect on the game's parameters.  Why is it necessary to try to make each point equally defendable?  How does it help solve camping or imbalance?  In addition, if BPs are arbitrarily chosen, bases can be moved to a point that normally offers less energy or nearer to them (or several points) to secure them more easily.  Domination points will make some locations more advantageous for a team to build in, and some less.  Let's use procyon-r1 as an example.  In a map as large as that, 10-18 points might be expected (once I implement your suggestion).  A team can usually build two turrets around each point that they have captured, which does require a bit of effort from the aliens, but should always be killable.  If some points, perhaps the ones in more open areas, provided the same amount of buildpoints, it would be a bit easier for players to recapture it.  If a team is low on funds (usually for a reason), they would probably focus on points that are easier to capture before they aim for the ones that are more difficult to capture, but the activity of players seems to make much more a difference in the difficulty of capturing a point than the number of buildpoints it provides.

Since domination points shouldn't be too difficult to recapture; if there is an advantage, it seems to me to be too insignificant to be worth the effort, if I'm not missing anything.

This leads me to bring up another potentional issue: dretches can't destroy those turrets, but default humans can destroy alien buildables.  The point of building around points is (besides more motivation and benefits to a team) is to help keep the game from being too volatile and them the points changing too quickly by securing it, and the time it takes to capture a point already serves that purpose.  I am considering disabling the repeater behaviour for control points altogether.  If it isn't insignificant, it be possible that this "issue" might be balanced out by other factors.
bob

UniqPhoeniX

  • Spam Killer
  • *
  • Posts: 1376
  • Turrets: +66/-32
Re: Domination
« Reply #21 on: October 16, 2010, 01:04:11 am »
This is not directly to help eliminate camping (just having "map control = lots more funds" should do quite well), but to make game flow more varied if both teams are aggressive, to make people consider different tactics/base locations and to eliminate the obvious ones.

The locations of DPs should depend on the map layout, for example if there are lots of paths, more DPs should be placed on path splits so as to keep the total amount of paths a team (that knows how to use tactics) has to defend down to 3-5 (which IMO should be sufficient to make it possible for a team to recapture a DP camped by at most 1/3rd - 1/5th the other team by focusing their attack). Having too many paths to defend would probably make the game more chaotic and make teamwork and tactics much less important, since you'd have "rush as much as fast as possible" (because most DPs would be too lightly defended even in the best case) instead of "rush that DP so we can stop defending that other location, and push forward" (which requires planning and coordinating several squads). Not that I'm hoping people will instantly learn teamwork, but those that do should be able to use it :P

I'm not asking for making DPs overall stronger or anything, I'm just asking to let the mapper balance the layout as much as possible. There isn't much point in capturing a weak DP that you can't defend as easily, especially when the other team has the lead in funds. Otherwise people would mostly focus on the same parts of the map, reducing variety.

You are supposed to be able to use RC/OM BPs at DPs anyway, so you don't need to move your base just to defend a DP better.

ULTRA Random ViruS

  • Posts: 924
  • Turrets: +4/-101
    • ZdrytchX's reference website
Re: Domination
« Reply #22 on: December 19, 2010, 04:00:57 am »
Looks like you spent a lot of time coding all this. Well done! Where can i play it?

CorSair

  • Posts: 430
  • Turrets: +14/-0
Re: Domination
« Reply #23 on: December 23, 2010, 06:13:26 pm »
Old....

As far as I know, server should be up in GPP, known as Domination or something similar (Ain't been there for long time.)

F50

  • Posts: 740
  • Turrets: +16/-26
Re: Domination
« Reply #24 on: December 24, 2010, 09:39:53 am »
Quote
If you're interested in using it, I am more than happy to make a few changes. If the CPs are annoying, I'll remove them.
I would like to incorporate it into the domination server once it's functional and polished a bit.  The CPs seem inappropriate for this.  If they're really that necessary, the UI (and making it optional with a cvar, as most of the UI already is) would be much more appropriate, but adding to the UI is not essential yet at this point.  The pounce and luci bars would probably serve as a sufficient paradigm for jetpack fuel.
[/quote]

The UI now exists, and the other problems should be fixed, although I still don't know how you teleported with it.
"Any sufficiently advanced stupidity is indistinguishable from malice." -- Grey's Law