dgets / d4m0b0t Goto Github PK

Telemetry data should be held in an associative array by id, not in a list. This will greatly accelerate running through that mess with every turn.

D4m0B0t is currently utilizing the global enemy_data structure for holding data regarding all enemies. Now that the EnemyData class is close to being fleshed out, it is time to begin implementing some sort of a structure of members of the new class to replace this.

The current enemy_data structure holds a key entity_object linking to each enemy. There is no need to duplicate this structure, as the EnemyData class instances will each have an id member to use for crosslinking our telemetry with the actual enemy object, already stored. This code is going to handle a lot more processing than the previous versions, so (especially being as this is interpreted) things need to have a bit of a focus on efficiency.

Seek out & replace all enemy_data references with the appropriate EnemyData and lookup their associated objects with the results of analytics.get_enemy_ships().

Create a routine that will go through the telemetry data and remove entries for enemy ships that are no longer around.

Need to start implementing the EnemyClass class within telemetry.

Breaking up the monolith for better development time across the next competition iterations.

Add a pointer to the potential target's entity id to the data structure (see also #6). Might as well just go ahead and check right away to see if the destination/target's id stays the same over a few iterations; it'll be useful as we go to see whether or not it stays the same, as a kind of 'target certainty' rating.

As can be seen in lines 105-157, in commit dd6790f, the 3 loop structures are almost clones of each other. This obviously needs to be modularized for maintainability purposes.