Web-application: in-depth balance-rules info
Laosh'Ra
Join Date: 2011-12-09 Member: 137232Members
<div class="IPBDescription">for interactive use on ns2hub</div><b>What is this based on?</b>
To quickly sum it up: a script analyzes the gamecode and extracts a lot of balance-data (UWE has conveniently accumulated most of it in a few files), basically all "game rules" which are numbers. This balance-data can be used to compute new data, like how many hits a certain attack needs to kill/destroy a specific target. This was initially done with a matlab script and intended for the forum and possibly the wiki. You can find it here: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=117569" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=117569</a>.
With more than 11k views, I figure a reasonable amount of people is actually interested in this. It has worked out rather nicely so far (except a few bugs), but it could improve even further.
<b>What is planned?</b>
I've been chatting with Arga (<a href="http://ns2hub.com/" target="_blank">http://ns2hub.com/</a>) and Zeikko (<a href="http://ns2stats.org/" target="_blank">http://ns2stats.org/</a>) about a web-based application for this. My web-programming experience is quite limited, but Arga offered to take care of displaying the data on ns2hub if I manage to prepare it in a convenient way. Zeikko suggested using XML or json for this purpose.
It can take a while until everything is working and I will continue to support the existing script until it seems obsolete.
<b>So here is how it would work:</b>
-A java program extracts the data from the code (similar to the current script, but more object oriented to build a nice hierarchy and make it easier to apply changes), this will be done manually at first but it could be automatic later on
-The script will output the data as XML (or JSON) file
-The ns2hub server will process the file (PHP) so people can interactively use it
<b>What features will it have?</b>
-Everything you can see in the balance files will be covered (if it does not fit anywhere, it is put into a "misc" category)
-Checkboxes and/or buttons allow the user to filter and group the data in different ways
-Just like now, it will be quickly updated with every patch
-Most likely only few bugs as I've gathered a lot of game-mechanics-experience creating and maintaining the current script
-Possibly: Comparing values of different patch-builds
<b>What can I do to support this?</b>
Simple. Post what you would like to see and how you would like to see it!
The object oriented approach will hopefully allow many different ways of displaying the data which would allow the users to explore the data from many different perspectives and purposes.
Example: Instead of the current approach, I'd prefer to seperate the data into both races, breaking it down to structures, AI-units and player-units. For every unit etc., everything related to it can be displayed: from effective health to the various types of attacks and abilities.
One could also apply a lot of filters for more specific purposes e.g. to find out which structures you could kill with a single clip depending on weapon upgrades and maturity.
If you have any program-related suggestions on how to approach this, feel free to share them. The current idea is to implement different types of objects (e.g. an ability is different from a structure) and have a lot of tags to address the countless gamerule-exceptions (e.g. damage-types).
To quickly sum it up: a script analyzes the gamecode and extracts a lot of balance-data (UWE has conveniently accumulated most of it in a few files), basically all "game rules" which are numbers. This balance-data can be used to compute new data, like how many hits a certain attack needs to kill/destroy a specific target. This was initially done with a matlab script and intended for the forum and possibly the wiki. You can find it here: <a href="http://www.unknownworlds.com/ns2/forums/index.php?showtopic=117569" target="_blank">http://www.unknownworlds.com/ns2/forums/in...howtopic=117569</a>.
With more than 11k views, I figure a reasonable amount of people is actually interested in this. It has worked out rather nicely so far (except a few bugs), but it could improve even further.
<b>What is planned?</b>
I've been chatting with Arga (<a href="http://ns2hub.com/" target="_blank">http://ns2hub.com/</a>) and Zeikko (<a href="http://ns2stats.org/" target="_blank">http://ns2stats.org/</a>) about a web-based application for this. My web-programming experience is quite limited, but Arga offered to take care of displaying the data on ns2hub if I manage to prepare it in a convenient way. Zeikko suggested using XML or json for this purpose.
It can take a while until everything is working and I will continue to support the existing script until it seems obsolete.
<b>So here is how it would work:</b>
-A java program extracts the data from the code (similar to the current script, but more object oriented to build a nice hierarchy and make it easier to apply changes), this will be done manually at first but it could be automatic later on
-The script will output the data as XML (or JSON) file
-The ns2hub server will process the file (PHP) so people can interactively use it
<b>What features will it have?</b>
-Everything you can see in the balance files will be covered (if it does not fit anywhere, it is put into a "misc" category)
-Checkboxes and/or buttons allow the user to filter and group the data in different ways
-Just like now, it will be quickly updated with every patch
-Most likely only few bugs as I've gathered a lot of game-mechanics-experience creating and maintaining the current script
-Possibly: Comparing values of different patch-builds
<b>What can I do to support this?</b>
Simple. Post what you would like to see and how you would like to see it!
The object oriented approach will hopefully allow many different ways of displaying the data which would allow the users to explore the data from many different perspectives and purposes.
Example: Instead of the current approach, I'd prefer to seperate the data into both races, breaking it down to structures, AI-units and player-units. For every unit etc., everything related to it can be displayed: from effective health to the various types of attacks and abilities.
One could also apply a lot of filters for more specific purposes e.g. to find out which structures you could kill with a single clip depending on weapon upgrades and maturity.
If you have any program-related suggestions on how to approach this, feel free to share them. The current idea is to implement different types of objects (e.g. an ability is different from a structure) and have a lot of tags to address the countless gamerule-exceptions (e.g. damage-types).
Comments
The real challenge is providing the information in the most usable format. How do people want to view this information?
Does anyone know of something similar that has already been done?
- Number of attacks (bites, bullets, nades) to kill enemies based on you weapon level/lifeform and their armor level/upgrades
- Time to kill a structure based on your weapon level/lifeform
- Number of attacks to kill a structure based on your weapon level/lifeform
- Time till enough PRes for lifeform based on number of RTs built
- Timing scenario analysis, in which you can specify parameters like number of RTs captured, build order, number of higher lifeforms, friendly and enemy KDR to see how various marine and alien strats work (i.e. can I get JPs with only 3 RTs before aliens get fades).
- Actual match reevaluation scenario, in which you take an actual recorded in ns2stats and tweak parameters (such as RTs captured or build order) to see if the outcome would have been different.
Last two are way more involved, but would be wonderful tools to help with strategizing and understanding how the game components interact.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->- Number of attacks (bites, bullets, nades) to kill enemies based on you weapon level/lifeform and their armor level/upgrades
- Time to kill a structure based on your weapon level/lifeform
- Number of attacks to kill a structure based on your weapon level/lifeform<!--QuoteEnd--></div><!--QuoteEEnd-->
these are already done in the existing script, except the time. time is actually working too, but i have very few rate-of-fire values as those are among the few things not listed in the balance files (they depend on the animation). i'll definately try to get these values somehow, worst case would be heuristical testing in explore mode.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->- Time till enough PRes for lifeform based on number of RTs built<!--QuoteEnd--></div><!--QuoteEEnd-->
should not be a problem. could display values for the different possible teamsizes or let the user chose this interactively somehow.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->- Timing scenario analysis, in which you can specify parameters like number of RTs captured, build order, number of higher lifeforms, friendly and enemy KDR to see how various marine and alien strats work (i.e. can I get JPs with only 3 RTs before aliens get fades).<!--QuoteEnd--></div><!--QuoteEEnd-->
interesting but also a bit tricky to do. i could see this happening as a seperate application, building on this one.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->- Actual match reevaluation scenario, in which you take an actual recorded in ns2stats and tweak parameters (such as RTs captured or build order) to see if the outcome would have been different.<!--QuoteEnd--></div><!--QuoteEEnd-->
well, judging the outcome of a match is obviously very difficult as there are so many unknowns to this (e.g. individual player behaviour). the only way i can see this happening is a machine learning approach. i've already talked with Zeikko about this longer ago and it might actually happen as machine learning is part of the topic i specialized in during my bachelor.
how this would work (getting very technical now): instead of implementing some heuristic, a classifier could be trained to automatically find out which values contribute more or less to the outcome of a match (this is possible because ns2stats also provides the outcomes of the matches). the trained classifier can then be applied to give a prediction for any arbitrary input of values. i'm usually doing this for object detection/recognition in images, so finding discriminative values is not too straight forward for me here, but it'd be worth to give this a try. using crossvalidation one can even tell how good the classifier will be working: using 90% of the games as training and 10% as testing (then looking up how many were correct), shifting those 10% through to run this test 10 times.
but before we get all fancy with this, i'd like to read some more oppinions about the basic structure the web-application (as in the first post) should have: how things are displayed, how a user can interact with it.
progress so far: basic parsing is done meaning i now have a hashmap (pairs of variable names and their values) and it can deal with comments and multiple assignements per line.
<a href="http://ns2hub.com/laoshra.php" target="_blank">http://ns2hub.com/laoshra.php</a>
this is just a basic proof-of-concept to make sure there are no technical difficulties. up next is planning out the structure carefully, <b>still waiting for feedback on how this data should be organised visually / interactively!</b>
We could have a 'Skulk' page which shows how the Skulk interacts with the world around it:
List the damage and rate of fire of Skulk attacks.
Its health, armour and modifiers (Cara).
Its speed and modifiers (Cele).
How many bites does it take to kill a marine (a1-3), an exosuit, a harvester, a command station? How long does it take 6 skulks to kill a Command Station? We could let you choose what the skulk is attacking from a dropdown list, or a graphical display of icons?
I am sure a lot more than this could be done, so please let us know what you think.
Example, you select jet pack, =armory+AA+2ndCC+proto+jp research.... With an output of 110res and x-minutes of research. This would show a theoretical fastest time to research assuming amazing res flow and multiple players on hand to build.
Complex application, time with x number of res nodes. Ie time to get. Jp with only 3 res nodes....
this should not be a problem to do (although it is some work). could add options to include build-time for the structures (with an average amount of marines building it, also selectable by the user) and an overhead it takes to click the buttons etc.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->Complex application, time with x number of res nodes. Ie time to get. Jp with only 3 res nodes....<!--QuoteEnd--></div><!--QuoteEEnd-->
building on the previous suggestion, this should be easy to do.
I know logistically the more RTs you have and can control the more total res and the sooner you can be lvl3/3 with jps ..... But for a strait jp shotgun rush there would be an ideal way to go about it, armories yes take a long time to advance so if your rushing jps you should start that as soon as possible maybe at the expense of a fast 3rd rt.
Only way I see to remedy this complexity is to create an adjustable timeline where you can drop and slide upgrades to view timing and resflow. Ex: rt built at 45 sec, armory built at 1 min, second rt built at 1min 15, AA going at 2 min what's my res at 3 minutes or when does my AA finish. Alternativly if I build my 2nd rt at 45 sec too how much sooner will I have res for a proto....
so here is my approach on the structure, the internal hierarchy goes as follows:
two races are created (could add more e.g. to put things like doors in there) -> done
each race has PlayerUnits assigned to them -> done
PlayerUnits are hardcoded as strings only containing their name (e.g. "Skulk") and get a set of references to all name&value pairs (e.g. SkulkHealth,70) containing that name -> done
the pairs have a counter to see how often they are processed. this will be useful to filter the not-processed stuff into a misc category -> done
todo: the PlayerUnits will have their attributes set to the according values (Health, Armor, etc. but also Weapons/Abilities going one layer deeper into the hierarchy (todo)), everything not fitting into this template could show up as "misc information" (e.g. GorgeCreateDistance)
todo: other categories e.g. Structures (PlayerUnits and everything else walking/standing around the map is derived from an abstract Entity class -> done)
some things will be tricky to put into a category as their role is not quite clear, e.g. all the AI units/structures which can attack (some move, some don't) and mines.
still need a fancy name for this project too.
afaik these values directly depend on the corresponding animations. these can be displayed with the viewer (accessable from the launch pad) but i could not find any exact numbers there. worst case would be to get some estimates manually, but i'll rather work more on this application first, hoping a better way will turn up.
after playing around with various ideas (like multiple assignments), i changed my approach to the following:
instead of a hierarchy, everything which is "real" (has health) now belongs to the original superclass "Being" meaning there are no more subclasses such as "PlayerUnit", "Structure", etc.
instead, there is now a set of common parameters but also a string of exceptions.
example:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->Being being=new Being(races[raceIndex],"Marine",P_playerUnit,P_structure,P_AI,P_Commanded,exceptStr);<!--c2--></div><!--ec2-->
why this approach? advantages are:
-the P_ values are booleans which i can set in front of every block e.g. P_playerUnit=true, followed by all player-controlled units in the code so there is not much overhead for the default cases. -> less overhead for new entries
-unusual assignments can easily be done (e.g. hydra being a structure but also AI controlled as it has an attack) without hardcoding it somewhere deeper in the code. -> more overview
-exceptStr contains a list of uncommon exceptions (e.g. Exosuit having no health) which are seperated by markers "|" in the string. e.g. "HasNoHealth|Armorbonus=ExosuitArmorPerUpgradeLevel". writing this exception-string is easy and intuitive, deeper layers of the code allow easy search through all exceptions. -> less overhead, more overview
-every "Being" still has a set of values associated with its name and they can easily be parsed for common things such as "MarineHealth". the exceptions could also be used to manually use, overwrite or disable certain values if necessary. -> automatic and convenient for the common values, but still adaptable to inconvenient/unusual variable names
there is still a lot to do, but i figure significant changes in the approach would be worth sharing.
it will be relatively easy to add the rest of the actual content then, but there is still a lot to do:
-proper xml output for ns2hub (will have to wait till arga returns from holidays)
-many exceptions (probably the biggest part)
-commander abilities (now supported, still need to be added)
<strike>-gestate and build times</strike>
-kharaa structure maturity
-damage types
-non-player units as well as a few structures and abilities
-hardcoded tech-requirements
-adding techs
-misc variables for the races
-variables from other files (e.g. movement speed)
-rate-of-fire values (and figuring out how to actually get them)
-applying upgrades for the output (armor etc.)
as you might be able to guess, this approach is less dynamic than the original one (which detected techs etc. automatically) meaning it might require a bit more maintenance when new patches are released (only if the mechanics/rules change, not the values). but it will provide much better overview and much more information about the game will be encoded meaning it is much more viable in terms of different types of outputs/display for different upcoming applications/tools.
i wonder: should we put the kharaa's attacks and their non-lethal abilities (leap, flap, shadowstep, blink, charge, umbra etc.) in the same chart as their attacks?
what about secondary fire modes for marines (currently only rifle-butt if i'm not mistaken), should it be listed as a seperate weapon (a seperate row in the chart)?
as for the name on ns2hub, how does "NS2 Database" sound? (the program creating the xml will be called ns2balanceParser)
btw: maybe it would be useful to get the tooltips from the game itself as well. e.g. enUS.txt in the ns2/gamestrings/ folder has things like
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->ARMORY_TOOLTIP = "Automatically resupplies marines with free health and ammo. You can buy weapons here with your personal resources."<!--QuoteEnd--></div><!--QuoteEEnd-->
i wonder: should we put the kharaa's attacks and their non-lethal abilities (leap, flap, shadowstep, blink, charge, umbra etc.) in the same chart as their attacks?
what about secondary fire modes for marines (currently only rifle-butt if i'm not mistaken), should it be listed as a seperate weapon (a seperate row in the chart)?
as for the name on ns2hub, how does "NS2 Database" sound? (the program creating the xml will be called ns2balanceParser)
btw: maybe it would be useful to get the tooltips from the game itself as well. e.g. enUS.txt in the ns2/gamestrings/ folder has things like<!--QuoteEnd--></div><!--QuoteEEnd-->
Personally I'd like all the abilities for an alien to be on one card.
Secondary definitely typed as a separate weapon. If you can properly show it as associated with the original that'd be good.
I assume you've checked out how the NS1 data was presented right? Charts and tables are often good. There's the NS1 Comunity Wiki ( <a href="http://www.unknownworlds.com/ns/wiki/index.php/Main_Page" target="_blank">http://www.unknownworlds.com/ns/wiki/index.php/Main_Page</a> ) and the unofficial Manual: <a href="http://www.unknownworlds.com/ns/static/comm_manual/basic/index.htm" target="_blank">http://www.unknownworlds.com/ns/static/com...basic/index.htm</a>
EDIT: my personal use case is to look up values and compare them. So easy access to charts and tables are my primary concern. Notes on special modifiers are nice.
EDIT2: I don't care as much if you provide all calculations (i.e. time to tech to it, total DPS including reload, time to kill lifeform) as long as all the data is well laid out such that I can derive it myself quickly.
One should be a table/graph form of the basic data, with toggles to filter data for easy comparisons.
Some others should be used for visualization of others stats. For example an interactive timeline where you can place TRes spending to find optimal times to get to a certain tech/building. This would need the ability to insert into the timeline when a RT is placed and rely heavily on the DAG (Directed Acyclical Gracph) of the tech tree. Plus have 2 timelines so you can compare the two sides' tech levels. And show what happens when you spend the TRes on the players.
Another tab can be used for calculating time/bullets required to kill a lifeform. I remember this being extremely handy in NS1. Punch in Armor, DMG, and assume the player does perfect reloads. Also integrate Alien Regen over time and figure out exactly how long it takes.
A super-cool tab would be travel times on a map based on the movespeed of units. Allow players to place PGs as well to see how the map changes.
sorry, progress is very slow atm because i got a new girlfriend which takes up the majority of my free time (i played ns2 like 1-2 times since release). this does not mean the project has died though, it's just taking a lot longer than expected.
finally found some time for some minor progress: gestate and buildtimes are parsed. structure maturity is recognized but no values implemented yet. took care of fov values and extended the code for handling exceptional rules.
i sent arga an alpha version of nested xml output today and he will figure out a fitting database schema for the online part this week.