Wednesday, April 28, 2010

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.