Overkill’s new learning 5 - the full list of features
I changed my mind about what to cover today. Here is an overview of the features in Overkill’s model. I decided it was interesting to see what they are.
Yesterday we saw that features are kept in a map of maps, so names have two levels. The variable featureNames declares the top-level groups of feature names and some of the lower-level names. It looks like this (leaving out most of it):
featureNames = decltype(featureNames) {
//state feature
{"state_general_feature", {
{ "time_", { "6", "12", "20", "30", "max" } },
{ "enemyRace_", { "z", "t", "p", "unknow" } },
{ "ourSupplyUsed_", { "9", "18", "30", "50", "80", "120", "150", "max" } },
...
{ "state_raw_combine_feature", {} },
{ "action_battle_combine_state_battle_feature", {} }
};
Features that originally take on a range of values have to be made into binary features. Overkill does it by breaking the range into coarse pieces. time_ looks to be game time in minutes. state_raw_combine_feature and action_battle_combine_state_battle_feature have their lower-level names filled in by code rather than declared directly. Those last two are the majority of features.
Here are top-level names and what it looks like they cover. Don’t trust my interpretations too much. Not all features in the code end up in the I/O files. I wrote down the number of features that the code includes, but apparently some of the features are never present in actual games.
| name | # | my interpretation |
|---|---|---|
state_general_feature |
53 | Game time, map name, distance between bases, enemy race, etc. |
state_tech_feature |
7 | Overkill’s tech level. |
state_building_feature |
30 | Overkill’s tech buildings, the enemy’s tech and production buildings. |
state_economy_feature |
46 | Minerals and gas for Overkill, expansions and workers for both sides. |
state_our_army |
40 | Counts of Overkill’s static defense and units of each kind. |
state_battle_feature |
168 | Counts of enemy units of each kind. |
state_raw_combine_feature |
6723 | state_our_army crossed with state_battle_feature, that is, every combination of our units and the enemy’s, plus 3 extra features. |
action_battle_combine_state_battle_feature |
6754 | Copies of state_raw_combine_feature and state_building_feature and the one state_tech_feature feature ourKeyUpgrade_zerglingsAttackSpeed. |
We know from yesterday that the features in action_battle_combine_state_battle_feature are exactly the ones that matter in calculating the Q value—they are the ones which get the action appended to their names. The others are only along for the ride; it’s an implementation quirk that they are kept in the same data structure. A number of features seem to be declared, evaluated, learned and remembered, but never effectively used.
So if I counted right (which I question), then there are 6754 binary features in total, though it would be strange for all of them to be useful against any one opponent.
Next: How it fits into the rest of the program, for real.
Trackbacks
No Trackbacks
Comments