Game Development Status 8/28/11
Doing some work on the prototype for PIC-Guam today. I did an hour yesterday; trying to build some momentum. I am implementing a prototype AI.
Today I had to refactor some code pertaining to movement footprint generation in order to reuse it in the AI.
My first approach to this AI is brute force. I am traversing the phasing unit list, generating all possible attacks permitted by the movement footprint. For each possible attack (firing unit in hex X versus target unit Y) for a unit, create a new allocation (list of such attacks) containing that attack and recursively call the allocation method for the next unit. As an allocation is completed (by adding an attack for the last unit in the list), concentrate the attacks in the allocation so that all units attacking the same enemy unit participate in the same FireCombat. Then evaluate the allocation by summing average fire combat results for each attack. The top N allocations are kept, and the actual allocation is randomly selected from among the top N allocations. During movement phases, the selected allocation also determines unit movement: each unit is moved to the
This will produce a very large combinatorial explosion, especially for the full order of battle. The questions are whether it will work in the first place for the small Orote scenario, how slowly it will run, and whether the results are any good.
I can reduce the processing and memory requirements of this brute force AI in several ways. I can pre-calculate the movement footprints and attack footprints for each of the phasing units. I can sort those movement/attack footprints by descending size and reorder the unit list accordingly, minimizing the number of nodes in the notional graph of partial allocations. I can also prune the movement footprints by accounting for overstacked hexes and removing allocations from consideration that exceed a threshold. I think I can also remove allocations that result in very few attacks (for the US side). For the Japanese side I may have to increase the difficulty by min-maxing to select the most casualties inflicted versus the least casualties incurred within a subsequent phase or two. Also, the Japanese side will need to constrain their movement in order to fully occupy the current generated FEBA line.
I'll eventually have to add some additional code to split out a certain number of Japanese engineers to create fallback defensive works. I'll need to control movement of AAA units with separate code as well in order to reduce the effects of US air.
Doing some work on the prototype for PIC-Guam today. I did an hour yesterday; trying to build some momentum. I am implementing a prototype AI.
Today I had to refactor some code pertaining to movement footprint generation in order to reuse it in the AI.
My first approach to this AI is brute force. I am traversing the phasing unit list, generating all possible attacks permitted by the movement footprint. For each possible attack (firing unit in hex X versus target unit Y) for a unit, create a new allocation (list of such attacks) containing that attack and recursively call the allocation method for the next unit. As an allocation is completed (by adding an attack for the last unit in the list), concentrate the attacks in the allocation so that all units attacking the same enemy unit participate in the same FireCombat. Then evaluate the allocation by summing average fire combat results for each attack. The top N allocations are kept, and the actual allocation is randomly selected from among the top N allocations. During movement phases, the selected allocation also determines unit movement: each unit is moved to the
This will produce a very large combinatorial explosion, especially for the full order of battle. The questions are whether it will work in the first place for the small Orote scenario, how slowly it will run, and whether the results are any good.
I can reduce the processing and memory requirements of this brute force AI in several ways. I can pre-calculate the movement footprints and attack footprints for each of the phasing units. I can sort those movement/attack footprints by descending size and reorder the unit list accordingly, minimizing the number of nodes in the notional graph of partial allocations. I can also prune the movement footprints by accounting for overstacked hexes and removing allocations from consideration that exceed a threshold. I think I can also remove allocations that result in very few attacks (for the US side). For the Japanese side I may have to increase the difficulty by min-maxing to select the most casualties inflicted versus the least casualties incurred within a subsequent phase or two. Also, the Japanese side will need to constrain their movement in order to fully occupy the current generated FEBA line.
I'll eventually have to add some additional code to split out a certain number of Japanese engineers to create fallback defensive works. I'll need to control movement of AAA units with separate code as well in order to reduce the effects of US air.