Forum Replies Created
- AuthorPosts
+1, especially:
Also, I have dozens of ground pound games that I can play if I want that βvery weakβ kinda limiting feel. I was really hoping that Overload would provide something more unique.
FWIW, I’m strongly in favor of mandatory turn rate limits at least as an option for custom games, if not mandatory. Setting aside concerns about a “level playing field” across input devices (i.e. even if only mouse+KB were supported), I’d want matches with turn rate limits. For me, 6DoF combat is all about space and positioning, and turn rate limits are critical for making your position matter.
The unblurred slo-mo in the video looks so cool though! Would it be enough to just lock the trajectory (rotational and translational) while the weapon wheel is up?
That sounds like a bug to me?
purple and red accents!
Overload runs great on my Asus laptop with a GTX 960m gpu running arch Linux. You just gotta make sure you get a machine with optimus and set up bumblebee to turn off the GPU when you’re not using it or battery life will be atrocious.
Sounds cool! Will the visual customization be just colors or swappable parts?
+1 for CTF π
Yes, they look so cool! Multiple endings… π π π
Also, what are operators?
A histogram just divides a measurement into bins, and counts how many runs appear in that bin. For example, you could count how many runs you have where shredders averaged between 20 and 40 damage.
Unfortunately, we actually cannot compute average damage per bot, however, because we do not know how many bots spawned: we only have how many we killed. Those are not the same number.
Average damage per bot also has the downside of having an idiosyncratic scale. What counts as a high damage? You have to compare to other bots to set the scale, and the scale could vary by player (some take less damage overall) and run (longer runs have higher damage values because players gather more armor, but then drop as armor spawns decrease and bot spawns increase). Damage index always has an anchor at 1: larger values mean the bot dealt more damage than is justified by the reward, and smaller values dealt less damage than is justified by the reward.
Damage index is also more useful if we do start scoring by points. The danger/reward trade-off will change, but averaged damage is insensitive to this trade-off. With damage index, however, we can just replace proportion of kills with proportion of points.
I propose a stat for tracking bot difficulty, which we could call its damage index. It is a ratio of two terms that are computed from the stats of a single run. The first term is the proportion of damage received from that bot, as a proportion of the total damage received from all bots. The second term is the kills of that bot as a proportion of the kills in the run. For example, if 10% of the damage a player receives comes from harpies, and 20% of the kills in the run are harpies, then the damage index for harpies in that run is 0.1 / 0.2 = 0.5. The idea is that hard bots deal more damage and provide fewer kills.
Yoshimitsu was kind enough to share his run stats, so I’ve included histograms of damage index for the two of us in build 100+, broken down by pilot and also collapsed. Notice that the horizontal axis is on a log scale, so a constant distance corresponds to a constant ratio in damage index. We see that Reavers, Tritons, Phantoms, and Guardians consistently have a damage index over 1, while Goblins, Gorgons, Gorgons var, Golems, Harpy var, and Ogres (but not Ogres var) consistently have a damage index under 1. More interestingly, Hydras and Shredders seem to be fairly evenly distributed around 1, but with a larger variance, suggesting that their difficulty is more sensitive to the map and/or bot mix.
As we accumulate more data, it will be interesting to study how the damage index varies with other run variables.
–EDIT: these graphs all use Insane difficulty, collapsed across maps.
Wow, this looks great! The ship models look so much cooler when they’re not just exploding π
I don’t think adding a point-based scoring system is a good idea.
- It’s impossible to come up with appropriate point values for bots; bots with reflex are probably more dangerous in confined maps like caverns than in open maps like hive, for example, but it would be weird to have different point values for different maps (and unsustainable for community maps). Any system of point values would still make some bot combos more desirable than others for a particular map, difficulty, play style, …
- There’d still be an incentive to fish for: getting invuln right before an ambush or triple superbot; having more goblins spawn right behind you than tritons; getting a cloak and homing bots in the same map; …
Ultimately, I think the desire for a point-based scoring system comes from a desire for the challenge mode leaderboards to be competitive in a rigorous way, but I think this kind of competitiveness is the wrong criterion to optimize for. As long as they list the max score rather than average, pilots who play more will have an advantage over and above their actual skill. The leaderboards are a fun way to provide a goal across runs, but they’re not a serious comparison of pilot skill.
I think a better criterion is to make each run as fun as possible. While that includes keeping the difficulty relatively consistent (which they have been doing by tweaking the spawn system), it doesn’t include awarding more points as a consolation prize: I’d rather not get two reaver ambushes in the first 100 kills at all than die on the second one and see that I got a lot of points for the first one!
Woops! I was still playing the old build. Disregard for now.
I saw this issue again last night on Pipeline; I don’t know if you’ve worked on it yet π
- AuthorPosts