Final report

Coding period is over and here is a quick overview of what parts of proposal got done, which didn't and what will be done in the future.

What was done

python support

• python can be used to create AI in daneel-ai
  

MTSec AI

• should provide a challenge to moderately skilled players
• phase three and a half according to the proposal
  

simplified writing AI for new rulesets

• simple how to guide with code samples
• code generator for python
  
• a lot of ruleset independent helper functions

What wasn't done and why
automatic ship/weapon design

• one ship designed proved to be superior, so there was no need for other designs
  

automatic optimisation

• all code is there, but battles take way too long for automatic optimisation

What is yet to be done (after GSoC)

• difficulty settings (easy, medium, hard)
• limit micromanagement to appear more human
• files for single player mode so this AI with difficulty settings can be used in single player mode
• saving state of AI so the game can be saved and AI used in scenarios
• use new MTSec orders
  
• test as many human players as possible
  

Weekly report - coding 12

This week I've written a guide how to code AI using daneel-ai and python. This should help all new developers to get started quickly with AI coding without worrying about libraries and protocol. A few last changes were done to the code generator. All proposal goals should now be complete. There is only one thing in the proposal that needs to be done: Party!

This week:

• everything was checked
• guide written

Next week:

• party (as specified by the proposal ^_^ )

Weekly report - coding 11

This week I spend most of the time getting well. I also done some AI battles to make sure SmartAI behaves as it is supposed to (and it does). Some time went into brainstorming so there will be series of posts with ideas how to improve daneel-ai, tpserver, tpclient and mtsec in the next couple of days. Pencils down date is getting closer so next week will be spend writing how-to guides and other documentation.

This week:

• SmartAI behaviour testing
• brainstorming

Next week:

• how to guide for writing AI using daneel-ai
• additional comments in the code
  

Full AI battle video

A video of two SmartAIs battling for 71 turns.

Weekly report - coding 10

Sorry for posting this report so late but I had fever for the last couple of days. I'm still a bit sick so I won't be so productive for another few days.

This week I found a workaround for the issue 126 and there was nothing left preventing me from doing lots of AI battles, so I did. I found out that after cca 30th turn SmartAI takes a long time to make decisions (more than 5 min) so optimisation was a must. I managed to speed it up using caching of some heuristics computations. It now takes up to 3 minutes on my computer which was downclocked to 800MHz because of overheating problems. Most of the action in AI battles happens in the first 30 turns, then even if one player outnumbers the other one by far it takes another 40 turns for the battle to end (video will be posted). In my opinion this is too long and can become boring for the players. I will discuss this with my menthor. I am also a bit concerned that SmartAIs ability to micromanage might have to be limited so it doesn't have too big advantage over a human player.

This week

• workaround for issue 126
• lots of AI battles
• optimisation of SmartAI code
• using caching for some of the computations

Next week

• smarter decisions what type of ship to build (attack or colonisation)
• discuss ways to make battles faster with Alan P.
• make sure SmartAI is not too difficult to play against for a human player
  

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
  

Status report

Since all of my reports so far were only about what I was doing and not about how things are done and why. I'm going to write a longer report about this.

MTSec not as documented

When writing my proposal I was expecting that some there will be some bugs in MTSec and that some parts might be implemented different than it said in the wiki, but now I know it's a lot different. Here is a list of things that are different than in the original documentation (I've already updated some parts of it).

• Armour

  • does not affect combat in any way

  • ships have way different values of armour than you would expect from documentation

• Resource mining

  • is not implemented

  • resource values never change, no mater how many production points are left unspent

• Weapon production

  • to produce a weapon you need 1 production point for ever component (1 for hull and 1 for each unit of explosives)

  • this means you can use the strongest explosives in every weapon

• Combat

  • when taking over a planet the planet is simulated as two scouts (without any weapons), so ships with weak weapons cannot take over planets

Stupid AIs

RushAI, CommandoAI, GreedyAI and BunkerAI all use the same stupid AI base. Because of some bugs there was more development time spend on stupid AI base and it got way more complex than planed. It uses 6 parameters to specify its exact behaviour, but the principle is always the same:

1. start building an army (ships and weapons for the ships)

2. colonise other planets but leave ships to defend your planets

3. when the army is big enough attack the enemy, but leave some ships to defend your planets

4. ships without weapons return to friendly planets for restock

5. in case the attack force becomes too small retreat

6. repeat

WaitingAI

It ends its turn as soon as it downloads all data. Obviously a bad opponent, but useful for testing as there is no need to end turns using tpadmin-cpp.

RandomAI

Randomly chooses orders for fleets and planets that don't have orders. For planets there it chooses from doing nothing, building a fleet form a predefined design or building weapons from a predefined design. For fleets it chooses from doing nothing, colonising (when on an neutral planet and the fleet has the ability to colonise), attack an enemy planet (if the fleet caries any weapons), move to a friendly planet and move to a neutral planet. In case the fleet is on a friendly planet with weapons it load the weapons and doesn't give any other orders. This is not a strong opponent but is very useful for fuzz testing the server and has used to discover 3 bugs, the downside of this kind of testing is that it is hard to find short steps to recreate a bug.

RushAI

Uses the stupid AI base. Uses small ships and weak weapons but a lot of them. An attack wave consists of 10 ships and retreats when there are only 3 ships left. At first this tactic looked promising but for reasons long unknown RushAI wasn't able to take over an enemy planet no matter how many ships it gathered. It turned out that planets have undocumented defences. RushAI was also meant to quickly spread across the galaxy colonising other planets, but since colonisation is not functional this hasn't been tested.

CommandoAI

Uses stupid AI base. Attacks with big strong ships and powerful weapons. It attacks as soon as there is an unit available and doesn't retreat at all. CommandoAI was able to beat all other stupid AI opponents. Colonisation would have been slow and the absence of it was probably a great advantage for CommandoAI.

BunkerAI

Uses stupid AI base. Build big ships and powerful weapons, but doesn't attack at all. It was not meant to win but to prevent the enemy from wining by building an impenetrable defence. Colonisation would have been slow if it worked. I was actually surprised when CommandoAI was able to beat it, since they both used the same ship and weapon designs.

GreedyAI

Uses stupid AI base. Builds small ships with weak weapons. Does not attack but was meant to colonise as fast as it could. It was meant to try to colonise so fast that the enemy wouldn't be able to take over all of its planets. But since the colonisation wasn't working it was useless.

MultipleAI

Randomly chooses every turn to behave like one of the other stupid AIs that use the stupid AI base. This was meant as a smarter version of RandomAI.

SmartAI

It was developed from stupid AI base. It functions mostly in the same way but uses different ship design for colonisation and attack ships. Attack ships are scout fitted with a lot of alpha missile tubes so they can fire a lot of missiles at once. Weapons used are alpha missiles with 1 unit of antimatter explosives. In this configuration one attack ship is capable of destroying up to 20 enemy ships and it's cheap to build. It also makes no sense to send more than one unit at a time to attack. Ship and weapon production has also been optimised so it builds as many units as possible with as little production points going to waste as possible. Only attack ships count as potential guardians of planets. Colonisation of other planets should be rapid if it starts working. SmartAI was able to beat CommandoAI (when there weren't server errors) so it has achieved its goal (in the current state of MTSec).

Weekly report - coding 5

This week a tactic for SmartAI was chosen by analysing stupid AI battles and MTSec implementation. SmartAI was coded and tested a bit. It won all battles against stupid AIs (when there were no server problems). Colonisation is still not in an useful state (can not build on colonised planets), but the SmartAI behaviour code is prepared for when it will work.

This week:

• analysed stupid AI tactics
• chose tactics for SmartAI
• coded SmartAI
• did battles between SmartAI and stupid AIs
• wrote a long report on the state of MTSec and my AI decisions so far
  

Next week:

• start including heuristics into SmartAI
• more AI battles
• general SmartAI improvements
• hope colonisation gets fixed
  

Weekly report - coding 4

This week StupidAI base got separated from RushAI and newly coded CommandoAI now uses the same base. StupidAI base can also be used as a base for SmartAI (latter breaking compatibility). Issue 97 was fixed today (thanks to llnz). First AI battles are now possible. Hopefully bugs won't interfere too much and AI battles will bring some meaningful data. I am currently a bit behind schedule (due to various bugs) but it is nothing to worry about.

This week:

• Base for SmartAI finished
• CommandoAI finished
• attacks with one strong ship at a time
  
• Issue 97 fixed (thanks to Lee Begg)
  

Next week:

• AI battles (finally)
• find out if one tactic is superior
• start coding SmartAI with hardcoded behavior rules
  

Weekly report - coding 3

Biggest achievement this week is a workaround for issue 97 and a bugfix for the colonisation module problem. Fixing the colonisation module bug revealed a new bug that causes the server to crash (but should be easy to find). Also a lot of code for helper functions was written. Number and types of weapons a ship can carry can now be calculated from design data. Code was written for loading fleets with the type of weapons they can carry and automatic design of weapons. RushAI can now handle all ship designs and can provide these ships with the right weapons. It can now serve as a base for SmartAI.

This week

• weapon helper functions
• a lot of helper functions for designing, loading, identifying and designing weapons
• RushAI is now able to command ships of all designs (not just the prepared ones)
• loads all ships with the right amount and type of weapons
• workaround for issue 97
• does not fix the issue but so far it looks reliable
• mentor fixed the colonisation module bug
• lead to a discovery of a new bug
  

Next week

• fix newly found bugs
• Stupid AI battles
• finish turning RushAI into a base for SmartAI
• fuzz test the server a bit
  

Weekly report - coding 2

This week the RushAI was made a bit better again. It looks like it will be able to serve as a base for SmartAI. Hope all the unplanned smartness of RushAI won't make SmartAI look bad in battle results.
RandomAI was also started and is almost finished. It chooses its actions randomly from a set of predefined actions. This set depends on the state of the fleet or planet (example: fleet without weapons cannot attack). This AI could also provide a simple stress test for the server and for fuzz testing (let it loose and wait for something to break).
Issue 97 still hasn't been fixed. Also designs with colonisation module cannot be used so no planets can be colonised and enemy planets cannot be defeated. This prevents gathering any data from AI battles.
I am still on schedule but not really ahead of it any more.

This week

• more unsuccessful bugfixing (issue 97 still there)
• most of the code for RandomAI done
  
• randomly chooses from a set of available actions
• set of actions depends on state of the fleet or planet
• RushAI a bit more advanced
• better choice of fleets to attack with
• first AI battles
• only RushAI vs. RushAI
  
• showed that it works
• no real data because of the behavior was limited by the bugs (no colonisation, enemy planets could not be taken over)
  

Next week

• incrementally make RushAI smarter so it could server as a base for SmartAI
• try to fix issue 97 and 108
• real AI battles (if bugs permit)
  

Weekly report - coding 1

This week 2 days were invested in trying to find a cause for issue 97 but with little success. The rest of the time was spend working on RushAI (one of the stupid AIs), which is now more advanced than planed but had very little testing due to some blocking bugs (issue 97 and 108). When finished RushAI could be modified in a short time to become CommandoAI, GreedyAI and BunkerAI (these are the rest of stupid AIs).

This week

• unsuccessful bug fixing
• RushAI is now more advanced
• but mostly untested
• a lot of helper functions were written
• mostly for getting information about design properties and resources

Next week

• finish RushAI
• test RushAI
• reuse RushAI code to make CommandoAI, GreedyAI and BunkerAI
• first AI battles

"Weekly" report - pre coding 2

The official coding period is starting and my reposts will be posted ever week from now on. I've also scheduled weekly meetings with my mentor.

I know my way around the client code pretty well by now. I've ran into some bugs on the server side and I hope they will get fixed soon enough. I'm currently using an older version of the server (MTSec branch) to avoid some of the bugs.

Python support was planned for next week but is already finished. The python code generator wasn't even planned but it's finished and it works better than expected. I hope other people will find it useful. I've already started programming stupid AIs so I'm at least a week ahead of schedule (hope it stays that way).

This "week":

• generated and tested code for MTSec
• and fixed minor errors
• learned how to manipulate designs in code
• added design adding functionality to helper functions
• started work on stupid AIs
• currently only rush AI and waiting AI

Next week:

• finish 4 (out of 7) stupid AIs
• study MTSec rules more closely

"Weekly" report - pre coding 1

Since this is the first report I will list things that were done until now. Some were done before the accepted proposals were listed and some even before the proposal was written so everything is not listed in the proposal.

Since the coding period hasn't officially started I won't write reports every week but on a weekly-ish basis.

Before writing the proposal I started work on MiniSec AI code. Using TP04 libraries in daneel-ai was not a part of the proposal but I thought it would be a good thing to do to prepare daneel-ai for future rulesets and server versions.

Until now:

What was done:

• better error handling on connection errors
• using TP04 libraries instead of TP03 libraries
• this will insure better compatibility with future rulesets and server versions
• found a way to add AI code written in python
• in a way CHR code can be used for preprocessing and support for AI code already written is not broken
• added files for MiniSec
• uses python for AI
• bot behaviour is scripted (just some simple actions)
• uses generated order code
• helper functions for writing AI in python
• can be used for many rulesets
• order code generator
• gets order information from server and generates all code needed to start writing AI code in python
• tested on MiniSec

I also ran into a blocker bug. The client (python client and daneel-ai) freezes after you colonise a planet in MiniSec, so no AI code can be written until this is solved.

Next "week":

• get rid of the blocker bug
• generate code for MTSec and test it
• use tpsai AI logic in daneel-ai for MiniSec
• try to make AI code that beats tpsai in MiniSec

The proposal

Short short version

Add support for writing AI code in pure python to Daneel-ai. Write AI code for MTSec ruleset. Simplify the process of writing AI for new rulesets as much as possible.

Short version

Since human players are not that easy to find every ruleset should have an AI opponent one can play against. MTSec is a ruleset that is stable and doesn't have an AI opponent so extending Daneel-ai to support it would make it the dominant AI client.

While working on the AI for MTSec I would try to simplify the process of creation of AI for new rulesets as much as possible (through extended functionality and tutorials/documentation).

Currently AI logic is meant to be written in CHR syntax, I would like to add a simple way of coding AI in python only so future developers could write pure python AI if they choose (and some things are just easier that way).

Long version

To gain players single player mode is a must and for that AI to play against is a must.

For future AI coding (for new rulesets and for scenario mode if/when it's implemented) daneel-ai is a great framework but needs to be extended beyond rule-based AI and made more friendly. With this there will be more possible ways to code an AI and reduced development time as protocol and client libraries will be hidden as much as possible so developers can focus more on the AI itself.

My MTSec AI will provide fun gameplay for beginners and more experienced players. It's behaviour will be highly customisable and could be changed to provide a challenge for every player. There will also be a number of simpler AIs that could be used as a base for specialised AI players (perhaps for scenarios or something similar).

As an added bonus, my development and AI battles should give the server a good workout and will result in a great number of bug-reports.

Daneel-ai expansion outline

I plan to expand daneel-ai to support coding AI in pure python. Support for CHR will stay untouched. There will also be a possiblity to combine CHR and python AI.

The process of writing AI code will also be simplified. Many helper functions will be added so the AI writer won't have to worry about calls to the client library as all the functionality for giving orders and getting facts about the state of the universe will be kept in these simple and well documented functions.

Also there will be many helper functions for writing code for new rulesets such as order discovery.

MTSec AI creation process outline

This is how I plan to create my MTSec AI. It starts simple and gains complexity step by step. Progress is measurable. Will be coded in python.

Phase one (Stupid phase)

I plan to build a few simple and stupid AI that each represent one type of behaviour. They will serve as a base for my smart AI and will be used to measure the progress by battling my smart AI against them (there will be more than one stupid AI and they will all be set to harm only the smart AI in a primitive co-op manner).

List of current AIs:

• waiting AI (does nothing)
• random AI (randomly chooses actions)
• rush AI (attacks with lots of cheap units)
• commando AI (attacks with a few strong units)
• bunker AI (doesn't attack but builds strong defences)
• greedy AI (doesn't attack but tries to take over as many planets as possible)
• multiple personality AI (changes behaviour to one of the other stupid AI every couple of turns)

When they are build they will be battled against one another to see if one tactic prevails.

Phase two (Hard-coded phase)

I plan to build a smart AI that combines the basic behaviours (already coded for stupid AIs). Balancing between behaviours (when to attack, when to expand, when to defend) will be done by hard-coding simple rules. Ship plans will also be hard-coded.

At this stage the smart AI should be able to beat all of the stupid AIs (hopefully even in very unfair battles).

Phase three (Heuristics phase)

In this faze I plan to replace the simple rules that drive the smart AI with more complex heuristics (battle prediction, evaluate how endangered each planet is). I also plan to build a more advanced ship planer that takes into account available resources, ships already built and known enemy ships.

At this faze I can change the behaviour of the AI by setting numeric parameters such as aggression, tenancy to build large (or small) ships, defensive requirements before expanding further.

All the parameters and heuristics will be tuned so the heuristics driven smart AI beats the hard-coded smart AI with high certainty. It should also be able to beat stupid AIs in very unfair battles.

Phase three and a half (Optimisation phase)

In the remaining time I will further fine tune the heuristics and parameters manually and if time permits automatically (optimisation techniques that could be used include hill-climbing, genetic algorithms). I will probably be using hill-climbing as it is one of the easiest to code. Number of turns before wining and number of stupid AIs that it can beat would be the main indicators of progress.

Phase three and two thirds (Humanification phase)

If there is still time left I will try to make a few sets of parameters that will make the AI play in specific ways, which would create more or less challenging AIs (easy, medium, hard) and some that have "personalities" (camper, zerg rush imitator, chicken, kamikaze).

Main goals

This will get accomplished.

• you will be able to code AI in pure python using daneel-ai
  • all or most of the client code will be hidden by simple functions to give orders and get facts about the universe
  • a working MTSec AI will serve as a proof that this was completed
• working MTSec AI
  • should be some fun to play with for a moderately skilled player
  • should give newbies some beating
  • completed faze three (at least) of the development will serve as proof that a relatively complex AI was achieved

Bonus goals

This are some of the good side products of my work. I won't focus on this but it will happen.

• AIs (stupid and the smart ones) can serve as a way to test tpserver-cpp (or any other server if it implements MTSec)
  • this could come handy for stress tests and fuzz testing as there should be no problems in running dozens of stupid AI at the same time
• bug reports, lots of bug reports
  • I plan on reporting everything that I find wrong with the client and especially the server
  • in case I would have to have something fixed yesterday I will attempt to fix it myself

Timeline

I have no vacation planed and will work 40 hours/week. I do however have 2 exams and will work about 30 hours the week before each exam (exam dates not known yet). I will be on IRC almost all the time and will probably work in the evenings too so I can stay in contact with developers from Australia and New Zealand (been there btw).

Pre coding

• April 26: PARTY!
• April 27 - May 23: Community Bonding Period
  • playing a lot of MTSec against everyone and everything (try to find some advanced tactics)
  • heavy brainstorming
  • tinkering with MiniSec AI
  • although this time is meant for community bonding I'm sure I won't be able to keep my hands off the code and will try to get a head start

Coding period

Phase zero

• May 24 - 30:
  • get basic python AI support into daneel-ai (simplification and helper functions will come later while coding AI)

Phase one

• May 31 - June 6:
  • coding stupid AIs
• June 6 - 13:
  • coding stupid AIs and testing them
  • first AI battles

Phase two

• June 14 - 20:
  • code smart AI base
• June 21 - 27:
  • code rules for smart AI
  • AI battles (at this point smart AI should beat all stupid AIs)

Phase three (and above)

• June 28 - July 4:
  • coding heuristics into smart AI
• July 5 - 11:
  • optimise heuristics and behaviour parameters for smart AI
  • AI battles (at this point the new smart AI should beat the old smart AI)
• July 12 - 18:
  • mid-term evaluations
  • automatic optimisation of heuristics and behaviour parameters for smart AI
  • AI battles to see the results of the optimisation

Buffer time

If something goes wrong it shouldn't set me back more than this (or so I hope). If nothing goes wrong this will be the time for some more optimisations and work on phases above three and writing guides and documentation.

• July 19 - 25:
• July 26 - August 1:
• August 2 - 8:
• August 9 - 15:
  • pencil down
  • finishing documentation and guides
  • add more comments to the code if needed
• August 16:
  • another PARTY if successful

After GSoC

I will finish any work I have started (probably automatic optimisation) and continue to maintain the code and fix bugs if any are found.

If I get lucky I might also get to write my graduation theses about it, this would probably mean more work on the AI and that can only be good for TP.