dgets / nightMiner

Halite III Bot - rewriting Halite III bot from scratch with better project structure plans
6 stars 1 forks source link

Fix the 'wandering while mining' issue #27

Closed dgets closed 5 years ago

dgets commented 5 years ago

Ships are wandering far too much after they've gotten their initial distance, and still have halite available on the cell that they're currently occupying. This is burning unnecessary halite in a few different ways. I'm currently handling log analysis. However, before that's completed, here are a few of the different areas that may be applicable in core_processing.Core.primary_mission_mining():

dgets commented 5 years ago

Checked the first conditional and, while there were some bugs to find that have increased bot efficiency, and logging improvements to be had, this does not seem to be the primary source of the problem.

I have managed to identify one case as where the bots slip into the WTF code. It looks like, if their halite_amount >= 900, and the current cell has no halite available, that was happening. So I've got that fixed, and will be pushing it shortly. NOTE: It seems that this has eliminated the WTF entries in the log file of a full, 400 turn game.

dgets commented 5 years ago

I'm thinking that there may, indeed, be something wrong in seek_n_nav.Nav.scoot(), as you can see in the following log snippet that, before scooting is supposed to be completed, after turn 004 the ShipHistory conditional tests and/or cell's halite_amount cause it to qualify to fall into randomly wandering in turn 005. It then returns to scooting in turn 6...

Applicable log snippet:

INFO:root:=============== TURN 003 ================ DEBUG:root: - me.get_ships() dump: [Ship(id=0, Position(22, 16), cargo=0 halite )] DEBUG:root: Making sure turn (2 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 scooting to Position(24, 19) DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame INFO:root:=============== TURN 004 ================ DEBUG:root: - me.get_ships() dump: [Ship(id=0, Position(22, 16), cargo=5 halite )] DEBUG:root: Making sure turn (3 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 scooting to Position(24, 19) DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame INFO:root:=============== TURN 005 ================ DEBUG:root: - me.get_ships() dump: [Ship(id=0, Position(23, 16), cargo=0 halite )] DEBUG:root: Making sure turn (4 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 randomly wandering DEBUG:root: - ship.id: 0 ShipHistory-->ship ID: 0, location: Position(23, 16), destination: Position(24, 19), turnstamp set: 1, secondarymission: Missions.in transit, primary_mission: Missions.mining DEBUG:root: - ship.id: 0 ShipHistory after processing-->ship ID: 0, location: P osition(23, 16), destination: Position(24, 16), turnstamp set: 4, secondary_miss ion: Missions.in_transit, primary_mission: Missions.mining INFO:root: - ship.id: 0 one step at a time... DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame INFO:root:=============== TURN 006 ================ DEBUG:root: -* me.get_ships() dump: [Ship(id=0, Position(23, 17), cargo=0 halite )] DEBUG:root: Making sure turn (5 <= 318) INFO:root: - processing ship.id: 0 DEBUG:root: - ship.id 0 in primary mining conditional INFO:root: - ship.id: 0 scooting to Position(24, 16) DEBUG:root: - spawning ship DEBUG:root:Killing from history for reassignment: [] DEBUG:root:Killing from history due to ship 8-x: [] INFO:root: - updating frame

This game is definitely going to need some more in-depth analysis. It would probably help to add debugging output for the MapCell's current halite_amount, since that's used in the applicable conditionals as well.

dgets commented 5 years ago

After a bit of log analysis, it doesn't seem to matter what the primary mission is before it starts randomly wandering. In the log there is a transition from scooting to this state, as well as mining. It would really help to have a script to parse the logs for these transitions.

I believe it's pretty imperative at this point to add the contents of the MapCell to the debug output.

dgets commented 5 years ago

There is also an issue in seek_n_nav.StartUp.get_initial_minimum_distance() that is causing some issues here. IE destination is not properly set, nor was the profitable direction utilized before. Fixing those issues now.