An Experimental Fork

Request new features or present your ideas.
User avatar
norfenstein
Mantis
Posts: 64
Joined: Sat Aug 18, 2012 1:00 pm UTC

An Experimental Fork

Postby norfenstein » Mon Sep 07, 2015 12:25 am UTC

In the interest of talking less and playtesting more, and because it seems like a hard sell to get anyone else interested in the value of removing features, I went ahead and hacked together eight changes that I think might make the game more fun.
These might sound alarmingly drastic, but the code actually exists now so we can try them instead of debating them.
And I made each one toggleable with a cvar so they can be tested individually or all together (they'll all default to on, which is what I recommend starting with).

  • x_freeUpgrades - When set to 1 all unlocked classes/weapons/upgrades can be purchased at no cost, as discussed here, with one wrinkle: I didn't want dretches and rifles to be useless, or light armour to ubiquitous, so I bumped up the momentum unlock thresholds for everything that wouldn't normally be free. At the beginning you'll be stuck with rifles and dretches until your team earns some momentum. When set to 2 upgrades are still purchased as usual, but the free fund timer is shortened (by default, controlled by g_freeFundPeriod) from two minutes to 30 seconds, and is the only way to get funds (kills yeild nothing but momentum). The idea is, as long you're not dying too frequently upgrades are still effectively "free".

  • x_simpleMomentum - Momentum is only awarded for killing enemy players and enemy spawns. I also doubled the default value of the existing cvar g_momentumBaseMod (from 0.7 to 1.4) to hopefully make momentum accrual take about the usual amount of time.

    My theory is that momentum doesn't need to be so complicated and hard to understand -- if you reward the actual core objectives of the game then everything else that's helpful gets indirectly rewarded too. Also, when used with x_freeUpgrades this makes momentum more fully take the place of funds.

  • x_noCamping - This reduces the fund and momentum rewards for players in sight of and close to any of their structures. The default range is 1000 units, changeable with the cvar x_campRange. The fall-off is linear, and the effect stacks with multiple structures.

  • x_unlockedBuildables - All buildables are unlocked from the start.

    My thinking is that higher momentum phases should be mostly about offense but structures are more about defense. And that builders don't get much fun out of waiting for their teammates to accrue momentum (and don't want to just spam badly placed structures to get it themselves).

  • x_buildAnywhere - This removes the power/creep restrictions on where structures can be built. If set to 2 instead of 1, it also lets you build without a reactor/overmind and keeps structures from deactivating without them.

    This is meant to make building less tedious by requiring fewer "obligatory" structures, and to make forward bases more viable by not giving them all a weak point.

  • x_buildPointPools - Makes build points work like in Tremulous (a team-wide pool, with points from destroyed structures returning slowly), with drills/leeches increasing a team's maximum build points. By default (changeable with x_buildPoints) teams start with a max of 75 build points, or the sum value of the map's starting structures if that's higher. Queued build points return 1 per 8 seconds like in Tremulous (changeable with x_queueTime). Resource-generating structures by default (changeable with x_rgsValue) raise a team's maxiimum build points by 24 when operating at 100% efficiency (they still cost 4 build points so the best you can net is 20 per drill/leech).

    The goal with making build points recoverable instead of infinite but nonrenewable is to make their acquisition simpler to understand and building in general less stressful and more open to experimentation.

  • x_noStamina - Removes stamina. Sprinting does nothing and humans can jump all they want. To compensate, human base speeds are reduced to 85%, 80%, and 75% for light armour, medium armour, and battle suits, respectively. These are changeable with x_larmourSpeed, x_marmourSpeed, and x_bsuitSpeed.

    My reason for this is that stamina isn't fun -- for either team. Removing it means one less thing for new players to learn and remember.

  • x_simpleLocationalDamage - This changes human locational damage regions to be x1 from the front and x1.5 (changeable with x_backStabMod) from the back, where "back" is 120 degrees and both regions reach top to bottom. Setting this to 2 instead of 1 also makes more alien attacks do locational damage (the primary arc of the marauder's zap, goon pounce, and tyrant trample).

    I don't think vertically stacked locational damage makes sense for melee attacks -- you can pretty much just target whatever you want at close range. And Unvanquished's damage regions are unnecessarily complicated. Front/back locational damage is both simpler to understand and more tactically interesting (don't let aliens flank you!), and there are fewer attacks that don't make sense with locational damage.

Things I didn't get to:
  • If we wanted a "soft sudden death" with x_buildPointPools, the rate of queued build points returning could gradually slow down over time.
  • With x_simpleLocationalDamage attacks coming from above should probably also get the "backstab" modifier, but the way damage regions currently work you can't actually take the direction of the attack into account and I didn't want to just have a sliver of vulnerability at the top of a human that a very accurate alien could target from below.
  • There might be a reason to prefer a non-linear fall-off to x_noCamping's penalty.
  • If x_buildAnywhere 2 is kept, then reactors, repeaters, and overminds should be removed (their ancillary functionality could be moved to other structures). If x_buildPointPools is also kept, then default reactors/overminds in maps should be swapped with drills/leeches. If x_buildPointPools and x_buildAnywhere 1 is preferred, then reactors/overminds should behave like drills/leeches (possibly providing all of the base points provided by x_buildPoints) so that builders won't always want to place a drill/leech in their starting base first thing every game.
  • I feel like suicides and teamkills should lower momentum with x_simpleMomentum but didn't bother implementing it.
  • I think I need to change RGSs to queue the build points they grant, to avoid abuse. The way queuing works doesn't let you replace an RGS to get its payload instantly, so I think it's all right. It is rough not seeing anywhere in the UI how many points are queued, though.

Playtesting caveats:
  • Don't change these mid-game. Some of them will work, but others can fail in subtle ways (or will always fail until a map load).
  • There are probably bugs.
  • Don't use bots, they won't know what to do.
  • Do not expect these to be balanced when playtesting, though the extra cvars can be used to adjust things if my default values end up being disruptive during playtesting.

Hopefully we'll be able to try these out in the next scheduled game on Sunday September 13.

EDITS: Added something I didn't get to, and the caveat about bots.
Last edited by norfenstein on Fri Oct 09, 2015 7:05 pm UTC, edited 5 times in total.
User avatar
Ishq
Project Head
Posts: 1138
Joined: Tue Mar 06, 2012 8:32 pm UTC

Re: An Experimental Fork

Postby Ishq » Mon Sep 07, 2015 12:35 am UTC

I do think a lot of these changes will make the game a lot more fun and am excited to help test these out next week. I will post my feedback next week with my thoughts. Hopefully the players who come to the devgame next week can chime in about what they liked/disliked so we can experiment further :)
User avatar
lamefun
Tyrant
Posts: 367
Joined: Mon Jun 04, 2012 10:29 am UTC

Re: An Experimental Fork

Postby lamefun » Mon Sep 07, 2015 7:04 pm UTC

Please add these:

  • x_noMoreCoolStuff - allow the aliens to evolve near their own structures regardless of the enemy proximity (the reasoning should be fairly obvious).

  • x_relaxedBuildTimer - allows buying a weapon / evolving with the build timer active. I mean, what does the total inability of builders to defend add to the game other than making low player count games and forward base maintenance more annoying?
User avatar
norfenstein
Mantis
Posts: 64
Joined: Sat Aug 18, 2012 1:00 pm UTC

Re: An Experimental Fork

Postby norfenstein » Tue Sep 08, 2015 11:53 pm UTC

I coded these in the fastest, hackiest way possible just to be able to test them. Something like aliens always being able to evolve in their bases probably doesn't need much testing -- we either want it in the game or not (though we'd have to define what qualifies as a "base") -- and if we do it probably shouldn't be me implementing it.

And is letting builders instantly switch to being attackers something a lot of people want? I don't see the potential fun. :confused:
User avatar
Ishq
Project Head
Posts: 1138
Joined: Tue Mar 06, 2012 8:32 pm UTC

Re: An Experimental Fork

Postby Ishq » Wed Sep 09, 2015 12:46 am UTC

I suppose it is fun for the builders in that they can help instead of helplessly swiping attackers until they die or their build timer finishes.
User avatar
GORE
Dretch
Posts: 37
Joined: Thu Mar 12, 2015 5:17 pm UTC

Re: An Experimental Fork

Postby GORE » Sun Sep 20, 2015 8:31 am UTC

I believe at least some of your mods could work. How and when do you play?

Also, possible to add respawn or downgrade to builder (if full health and no near enemies) as alien without loss of points?
User avatar
norfenstein
Mantis
Posts: 64
Joined: Sat Aug 18, 2012 1:00 pm UTC

Re: An Experimental Fork

Postby norfenstein » Sun Sep 20, 2015 6:40 pm UTC

We should be trying it as part of today's regularly scheduled development game at 20:00 UTC.
User avatar
GORE
Dretch
Posts: 37
Joined: Thu Mar 12, 2015 5:17 pm UTC

Re: An Experimental Fork

Postby GORE » Tue Oct 06, 2015 11:03 am UTC

lamefun wrote:Please add these:
  • x_noMoreCoolStuff - allow the aliens to evolve near their own structures regardless of the enemy proximity (the reasoning should be fairly obvious).

I agree. Possible to add?

Also add cvar for allowing dretches to kill turrets/rockets.
User avatar
kharnov
Granger
Posts: 1851
Joined: Tue Mar 06, 2012 10:54 pm UTC
Clan: GT
Location: New York City

Re: An Experimental Fork

Postby kharnov » Wed Oct 07, 2015 10:20 pm UTC

In case this is of use to anyone:

Code: Select all

<tool8> can someone help me with server? I cant get my norf cvars to work
<tool8> i have built unvqx and run daemonded with experimental gameplay cvars x_* but they dont work
<`Ishq> Oh?
<`Ishq> Why not?
<`Ishq> Are you loading them?
<`Ishq> If you build from source, you need to make sure you specify the correct vm.sgame.type at command line so they are loaded
<`Ishq> Unless you plan to make modifications
<`Ishq> Just use the dev server vms
<`Ishq> http://dl.unvanquished.net/pkg/dev/mod-devserver_2015-09-27-0001.pk3
<`Ishq> If you just want to play wth x_* cvars
<`Ishq> Just use the pk3
<tool8> oh its that easy
<`Ishq> Load it iwth -fs_extrapaks mod-devserver
<`Ishq> si
<`Ishq> super easy
<`Ishq> future of unv
User avatar
norfenstein
Mantis
Posts: 64
Joined: Sat Aug 18, 2012 1:00 pm UTC

Re: An Experimental Fork

Postby norfenstein » Fri Oct 09, 2015 7:16 pm UTC

Added x_freeUpgrades 2. Free upgrades were surprisingly well-received, but it occurred to me that it would ultimately require every class/loadout to be basically equal in power (like a traditional class-based game, such as Team Fortress). I'm theorizing that we can retain the benefits of free upgrades without giving up flexibility in power levels by time-limiting stronger classes/loadouts.

Return to “Ideas & Suggestions”

Who is online

Users browsing this forum: No registered users and 1 guest