Weekly report - coding 9

This week a lot of time went into playing around with colonisation (now that it works). Although the server crashes when you attack multiple planets at once (issue 126), I was able to prove that running away (colonising but not attacking) is a viable tactic in MTSec (see blog post with video) and that my heuristic for colonisation works as planned. Some work was also done on providing visualisation. There is now a simple way to get images for every turn and a video of the whole game so you can see what is going on in an AI battle. There was also a minor fix so you can now use daneel-ai in single player mode again and a lot of added comments.

This week:

• SmartAIs use of colonisation tested
• it works well and is very useful
• trying to outcolonise the enemy is proven as a viable tactic
  
• visualisation of gameplay
• image for every turn
• video of the gameplay
  
• added a lot of comments
• every helper function is documented
  

Next week:

• automatic optimisation if issue 126 gets fixed
• heuristic for deciding what type of ships to build (colonisation or attack) instead of weighted random
  

SmartAI demo and visualisation of the colonisation heuristic

Since a picture is worth more than thousand words and a video is worth even more I present you with both.



In this video you can see an AI battle between two SmartAIs. Red one only colonises and green one only attacks. It proves that outrunning (actually outcolonising) is a possible tactic in MTSec.
It can also be seen that the red player tries to avoid colonising planets close to the green player because they are more endangered.




Colonisation heuristic is visualised here. Small red squares represent enemy planets and the green square represents the fleets current position. Brighter means better for colonisation. It takes into account the distance from the fleet and distance from the nearest enemy planet.

Idea 1: splitting/merging fleets

Splitting fleets is present in almost all rulesets and it would be practical if you could split fleet A into fleets B and C and then give further orders to B and C without wasting a turn for splitting.

Possible solutions:

• Server side:
  After sending the split order to the server for fleet A you update universe data and get data for fleets B and C. The only feature that needs to be added to the client in this case would be auto-updating after certain commands (split and merge).
  
  pro:
  split procedure can be complex,
  also provides basic support for non-turn based rulesets,
  results of the split are visible immediately
  con:
  update after every command (updates could be made in batchs)
  
• Client side:
  Split order is execute on the client side and sends this information to the server along with other orders.
  
  pro:
  no need for extra updates from the server,
  results of the split are visible immediately
  con:
  client side scripting language should be specified (so all clients can execute this type of orders)
• Multiple order queues:
  After giving the split order to fleet A you add orders for the remaining ships (fleet B) to the same queue and orders for the rest of the ships (fleet C) to another order queue.
  
  pro:
  probably the simplest solution to implement
  con:
  an unintuitive way for the player,
  results of the split are not visible immediately
  

Weekly report - coding 8

This week there was some work on the way SmartAI attacks, heuristic now adds penalty points for each ship that is already attacking that planet so the attack becomes more distributed and the order of fleets is not important any more. Also some code was prepared for automatic AI battles. It is meant to be used for automatic optimisation of AI in the future, but now it just starts battles and keeps track of who wins battles. Colonisation is now supposed to be working so I will experiment with it a lot next week.

This week:

• improved attack code
• more distributed attacks
• improved heuristic score
  
• code for automatic AI battles

Next week:

• experiment with colonisation settings for smartAI
  
• retest stupid AIs now that colonisation is working
  

Weekly report - coding 7

This week heuristics were added for choosing a planet to return to after an invasion, enemy strength calculation and choosing which planet to attack. Attack ships don't need to be fully loaded with weapons now (so we can start attacking quicker). Game over is no properly recognised even with more than 2 players. Enemy ship type guessing will son be implemented. Also some refactoring was done (mostly making game facts global) and minor bugfixes. Colonisation still isn't fixed so AI battles are pretty boring.

This week:

• heuristics for choosing a planet to return to after an invasion (or when weapons run out)
• heuristics for determining the strength of an enemy (at a certain location)
• heuristics for choosing which planet to invade
• game over now recognised with any number of players
  

Next week:

• finish enemy ship type guessing
  
• optimising heuristics
• probably more heuristics
• if colonisation (or anything else) gets fixed a lot of testing
  

Weekly report - coding 6

This week SmartAI code has been under heavy refactoring . A lot of code has been rewritten to efficiently use 2 separate ship designs (one for attacking and one for colonisation). Also fleets with more ships are now split into smaller fleets (until there is only 1 ship in each fleet) so each ship can be controlled separately. Heuristics for determining which planet to colonise has also been added. My mentor agreed to fix what is broken, implement what is missing and document what is implemented differently.

This week:

• code refactoring
• good use of 2 designs
• splitting large fleets
• colonisation heuristics
  

Next week:

• add remaining heuristics
• try to find good colonisation strategy if it gets fixed