TECH DEMO: Variable Teleport Costs

16

The present package is a system for dynamically adjusting the time and energy cost of teleportation with respect to distance.

variable_teleport.png

  1. Energy cost scales quadratically* according to teleport_dist^2.
  2. Time required scales logarithmically according to log(teleport_distance), with a minimum time equal to UnitBlueprint.TeleportDelay.
  3. The above two values are displayed in a reticle adjacent to the teleportation cursor. When multiple teleporting units are selected, the energy displayed will be equal to the sum of the individual costs of all units. The displayed time will be the individual maximum among the selected units.

Technical implementation includes the externalization of the teleport cost function to lua/shared, allowing access by the sim and the ui, and a reticle class in controls/worldview.lua with an eye towards future applications.

Github here, mod version in attached zip file.

Quadratically, not exponentially.

hands raised at the point of a gun You got me! I knew I missed something!

log time and quadratic energy cost sounds like a very smart starting point for balancing teleport cost.

Homeworld-like teleports! Neat!

log time and quadratic energy cost sounds like a very smart starting point

And even if they're not a good ending point, you can easily put in whatever cubic/quadratic/exponential/piecewise/crazy bullshit you like!

Also has full backwards compatibility with mods with a "UseProportionalTeleportCosts" blueprint value (any blueprint without it uses the old algorithm). Changes are on the github but not reflected in the zip file.

Looks pretty good (though i'd use the e and time icons 😆)
Also I think log time scales too slowly, if you want the current 25 seconds for long 600 unit teleports (approximately ln(x)*4) then a 300 unit teleport still takes 23 seconds. maybe sqrt would be nicer? then it'd be ~17 seconds for 300 units or maybe even make it linear, so teleporting is basically just walking really fast 😂. Though that's all just balance adjustments.
At least the UX seems to be good, so that part should be cleared up.

Yeah don't come after me for the actual cost functions, they could not be more placeholder 🤸 (though I liked the idea of short jumps being energy efficient, and long ones being time efficient, or vice versa).

E and time icons is a great idea. I put this together because it looked like major changes to teleport were on the table and I figured it would potentially give the balance team more wiggle room, so I'll put off diving into any more cake decorating for now.

@clyf yeah let's wait till the balance team decides if they want this or not.
Was just putting this out there before people go "but now it teleports crazy fast" or "the text looks super ugly".
To get in line with the current balance change for teleport, the cost/time should go up very fast for longer ranges (to bascially soft cap the teleport range), so probably (truly) exponential cost and linear time would be a good starting point for beta.

We could ask what kind of behavior we're looking to reward/disincentivize.

Are we trying to keep the ACU from getting in there, or is making it harder to escape more important? How does energy cost and time required interact with those two? My hipshot is high energy crushes both, while time is mostly relevant to the latter.

Should we open up the possibility for a series of short hops? Gotta keep in mind that a short, fast hop will hard counter many snipe patterns. (Should the minimum tele time be shorter or longer than the time it takes for a strat bomber to circle around and drop another bomb?)

Might be cool if you put on a error effect where it doesn't telle you exactly where you clicked making telle more risky. The father away the higher chance your a little off.

Similar to the campaign where that uef guy is teleported to the wrong side of the map.

@veteranashe That sounds like a decent way to combat telesniping, tbh.

I kinda like the idea of teleport allowing commanders to play a lategame without sitting in a pond! (Ie, as a potential, albeit expensive, defensive measure.) I'm clueless what it would do for high-end balance, though!

@veteranashe

Most of that is downstream of the backend on this, but a CEP decal is possible.

I'm imagining a telemazor ACU making a quick "short hop" jump from the left side of a base over to the right side of a base

It would make it easier for a telemazor ACU to maneuver to look for new (less-defended) targets or to chase down escaping ACUs, especially because they can fire the lazer while the teleport is happening

it would also mean any time an ACU started to teleport away, you wouldn't know how much time you have to blast it with bombers before it disappeared, unless you knew where it was going

It might also make it easier to just teleport away to get under shields if there's a snipe attempt (or to teleport between two bases to avoid a snipe attempt).

All of this seems like it would be more interesting than the current system.

I like this! Looking forward to it.
But, I have one tiny concern:

Will there be a "floor" or "base" value for teleportation (timer) so a unit does not teleport around and cause gimmicky gameplay?

IE: Teleportation is at a minimum value of 10 seconds at short-range and can reach a maximum
value of 25 seconds at max-range.

This would also avoid weird interactions as can be seen in the "Black Ops ACUs" mod that basically lets the ACU teleport around every second, making for a really absurd situation by jumping around with short-range blips.


~ Stryker

( ͡° ͜ʖ ͡°)

@ComradeStryker

Time required scales logarithmically according to log(teleport_distance), with a minimum time equal to UnitBlueprint.TeleportDelay.

😉

To answer your question in more detail, the following is the "the goods" as far as calculating cost is concerned:

if bpEco.UseVariableTeleportCosts then
        -- New function here
        -- energy cost is dist^2
        -- time cost is natural log of dist
        energyCost = math.pow(dist, 2)
        time = math.log(dist)
        
        -- clamp time to teleDelay
        if time < teleDelay then
            time = teleDelay
        end
else
        -- original cost function executed here
end

You can add any combination of minimums, maximums, blueprint modifiers, range modifiers, or some crazy thing I could never even imagine, if it suits you.