Map balance tool: Expression of interest - I NEED YOU
Hello mappers!
I'm a GIS dude with an interest in web mapping. So what?
Well, I want to build an interactive web tool for NS2 mappers to use to help them balance their maps. Right right right, basic death heatmaps etc. I hear what you're saying. They're pretty standard (and boring)! The tool I'm putting together will deliver a more advanced ability to pick apart your map's balance data.
However, since I'm not a mapper, I need your input. How do you go about assessing map balance (methodology)? What features would you like to see?
To give you a better idea of the capability of such a tool, here's a couple possible example features:
At the moment, I'm digitising & GI modelling the official NS2 minimaps for use in a spatial database. The attributes I'm currently including in my data model are:
I'm also toying with the idea of travel networks to give an approximate idea of travel times from any one room to any other. While this is awesome, it's slightly more advanced than your basic point-in-polygon non-topological model I'm currently working with (and would take more time to make functional). It would open up some amazing toys, though.
What are your thoughts/ideas/etc?
Thanks!
I'm a GIS dude with an interest in web mapping. So what?
Well, I want to build an interactive web tool for NS2 mappers to use to help them balance their maps. Right right right, basic death heatmaps etc. I hear what you're saying. They're pretty standard (and boring)! The tool I'm putting together will deliver a more advanced ability to pick apart your map's balance data.
However, since I'm not a mapper, I need your input. How do you go about assessing map balance (methodology)? What features would you like to see?
To give you a better idea of the capability of such a tool, here's a couple possible example features:
- Identify camping hotspots by selecting a room with an unusually high density of [alien]/[marine] deaths and showing a heatmap of where (and by what) they were killed.
- Analyse starting tech point balance. If a team starts with Tech Point X, what are the kill densities of each resource node on the map for a given game period (early/mid/late)
At the moment, I'm digitising & GI modelling the official NS2 minimaps for use in a spatial database. The attributes I'm currently including in my data model are:
- Room name
- No. of doors
- No. of vent exits
- No. of res nodes
- Team spawn type
- Room type (vent/corridor/techpoint/regular)
I'm also toying with the idea of travel networks to give an approximate idea of travel times from any one room to any other. While this is awesome, it's slightly more advanced than your basic point-in-polygon non-topological model I'm currently working with (and would take more time to make functional). It would open up some amazing toys, though.
What are your thoughts/ideas/etc?
Thanks!
Comments
I remember back in alpha the dev team made a simple simulation to help adjust spawn times. This would have to be considerably more complex.
As with all (good
Perhaps I should have been more clear of the purpose of the project. I hope to provide a user interface which would generate a database query based on user input and return a visualisation to the browser. I intend to start with only a couple of features and add more as the project progresses. That's why I'd like mapper input - what would you guys prioritise?
The majority of the computing can be done within a spatial database, such as PostGIS, which have incorporated rather extensive libraries of spatial query functions into their SQL. They also provide rather nice indexing features which increase performance dramatically. The Oracle Spatial Documentation gives a decent overview that can be relatively easily skimmed.
And so, I think you should just do what you do and wait for feedback. Whatever you provide will always be an additional tool.
One thing though, and this might be difficult to implement, would be that the heatmap tells you at what distance aliens were killed. The game relies a lot on cover, line of sight, and breaking the line of sight. It is probably one of the most tangible things for players. Usually word of mouth from testers/players will tell us where there are blatant issues. But I think where aliens were killed from, would be something very useful. It would tell you where aliens can close distance and where they have more difficulty doing that. I guess where aliens kill is equally important, but for that we mostly assume they managed to close distance.
If there are areas, where either team can abuse their power. Either shooting aliens from too far for marines, or being able to get too close before you can even be seen as aliens. It would be nice to see that over many games and ensure the map is balanced locally and as a whole. If think this would prove more valuable information for NS2 than a traditional heatmap.
Maybe you could represent kills always as a pair of coordinates, with the position of the killer and killed, maybe a line/vector between these two points and a color code to tell us who won.
(edit:spelling)
It is about a programm called Echo. It delivers for example data of how much a route on the map is used and where the killing zone hotspots are. This seems to be very usefull for balance: youtube.com/watch?v=zYvMOpV2Rjs
Edit:
Bob, do you think some kind of marine:alien death ratio indicator would be enough to represent that?
I imagine you could create an isochrone map of areas with >1 standard deviation, using that as a form of 'excessive risk' indicator. Once you have these areas, you could grab all deaths within them and plot the location of the killers as a heatmap.
OTOH, a you could probably just pull out hotspots where one team gets excessive numbers of kills and analyse those.
Just starting with kill deviation mapping would be amazing - a hot/cold map that shows spots where marines get more kills and spots where aliens get more kills. Then the total deviation between the two teams for each room and for the total map - so mappers can see if these spots are somewhat balanced as there will always be hotspots for each team due to how much of a role line of sight plays. From there mappers can adjust the 'kill zones'.
Words can't explain how massively helpful that would be.
I think you see what I mean, and I get you too. Anyway, a way to visualize where distance is the factor.
Looking at that vid, any traditional heatmap would definitely give insight.
These hotspots of OTT death for one team can then be used as selection criteria on which further analysis can be based (i.e. what happens in these high risk areas).
Edit:
Also, the more I establish possible balance metrics the less appropriate a web tool seems. Simply testing balance axioms for statistical rigour would take up a lot of what spare time I have (and I'm totally willing to do that). Raster calculations, especially interpolation, can take a long time to generate so dynamic querying will be a bitch to figure out. I'm not saying it isn't doable, though!
What could be appropriate is developing a set of indices such as accessibility and openness similar to this SC2 map analyser I found. These would be interesting to look at in conjunction with outlier areas.
Does a minimap generation script exist? I'd like to look into modifying it to create height-maps. e: found it
Edit2: Re-reading Bob and DarkSeraph's points about distances and line of sight, I believe a good relative indicator of openness could be developed. Utilising Viewshed Analysis, a viewshed could be computed for each point on the map and then each cell given a value based on the proportion of the map visible when stood there (one calculated at the height of a marine and the other at ceiling height to simulate flyers).
You would expect high marine fatalities in zones of low proportional visibility and vice versa.
The one thing that would have to be incorporated would be bottlenecks. These could potentially be identified by calculating the gradient values between a visibility cell and its neighbours (areas with a high gradient going from low visibility to high visibility would be a bottleneck?) It'll be easy to check, sure enough.
I'll start compiling a methodology doc that goes into further depth as I doubt I'm explaining my ideas clearly.
Maybe you could even upload the quotations for a map. Since it should be stored with coordinates, it might be fast to add.
Simulation (e.g. no match data needed)
- Shortest distances/time for traveling between tech and res nodes for each unit/class (e.g. marine, jetpack marine, single/dual exo, ARC, MAC, skulk, gorge, lerk, fade, onos, drifter, whip) with a toggle for allowing those units to use vents (e.g. only skulk, lerk, fade) or between movement styles (e.g. crouching, sprinting, blinking, charging, etc) or by only including/excluding spawn tech nodes
- From each spawn location, how much of the map a player must move 'backwards' (e.g. away from the center axis of the map) to move to a res node
- Highlighting potential chokepoints (e.g. areas with multiple shortest distance pathways)
- Shortest distance cysting pathways from all tech nodes to all res nodes
- Highlighting vent entrances that are accessible by solo marines without jetpacks
- Areas of the map from which each tech and/or res node can be ARCd
- Areas of the map from which each tech and/or res node can be shot from a ranged weapon (e.g. rifle, shotgun, spikes, etc)
- Room/corridor height heatmap (e.g. the height between the floor and ceiling of each point of the map)
- Overlaying and highlighting problematic issues with the path meshing on the minimap (e.g. the stuff you see when you turn on nav_debug)
- Overlaying the power grid on the minimap to help see if any important areas don't have power
- Overlaying which parts of the walkable map is 'level-over-level' (e.g. walkable catwalk/vent/etc either above or below other walkable map geometry)
- Overlaying which parts of the map are visible/invisible to the comms
- Light entity heatmap
- Sound entity heatmap
- Cinematic entity heatmap
- Viewing/occlusion heatmap (e.g. how much of the rest of the map can you see from each point)
- Model entity heatmap
- Vertices heatmap (e.g. maps are made up of building faces from lines connecting vertices, so an area of high vertice density can indicate complicated geometry)
Data (e.g. match data is needed)
- Kill/Death heatmaps with the ability to filter by weapon/alien class/NPC (e.g. shotgun, skulk, sentry, etc)
- Movement heatmaps with the ability to filter by marine type/alien class/NPC (e.g. exo, skulk, ARC, etc)
- Structure placement heatmap with the ability to filter by structure (e.g. hive, armory, crag, etc)
- Castable entity heatmaps with the ability to filter by the castable entity (e.g. med/ammopacks, bonewall, enzyme, mist, scan, etc)
- Tech node stats (e.g. # of times and duration a hive or command station was built there, which number hive/cs it was, etc)
- Res node stats (e.g. # of times and duration a harvester or extractor was built, which number it was, how was it killed, how much res it produced before dying/end of the game, etc)
- Power node stats (e.g. # of times and duration it was build, how it was killed, etc)
-
Off the top of my head I can't see how you'd calculate these without simulation using AI pathfinding, a mapper defined chain of waypoints or some combination thereof.
It'd also be nice if a time frame could be specified for these data base features.
So, for example, the mapper could see where all the kills occurred between 3:00 min & 10:00 min
While the feature list Scardy mentions is definitely full of cool features, I'd say that only a few of them should be considered essential/high priority for this particular tool:
No problem
It goes a bit past use for just analyzing balance, but things such as lighting or occlusion heatmaps would be extremely useful for optimizing maps.