NullBot goes through big refactoring

[aubergine]

Wow, how do they do that? Is that all hand-crafted or is there some tool for doing that? Looks awesome! Do you have infos on how they did it?

[Duha]

Wow, how do they do that? Is that all hand-crafted or is there some tool for doing that? Looks awesome! Do you have infos on how they did it?

Looks like it: docco
http://jashkenas.github.com/docco/

upd:
python version (pycco) works in that way

[NoQ]

I'll allow myself to write a little essay on adaptation. Well, i'm writing this mostly for myself, cause i need some clarity in my head before proceeding.

Currently the NullBot3's adaptation mechanisms allow gathering information on usefulness rating of certain components in current game situation.

1. propulsions, classified by movement scopes (ground, hover, air).
2. propulsions, classified by weakness to certain weapons (tanks, cyborgs, defenses, vtols)
3. bodies, classified by dominating armor class (kinetic, thermal)
4. weapons, classified by roles (anti-tank, anti-personnel, anti-structure, anti-air).
5. weapons, classified by damage class (kinetic, thermal)

Some of this data is inaccurate, but it isn't relevant to the today's topic. In the original NullBot only 4. and partially 1. was available.

Based on this data, NullBot3 needs to make an adaptive decision formulated as a single game object template: a tank design, a cyborg template, a vtol design, or a defensive structure, or a research item, to produce or build right now at that particular moment.

You may say it's easy: just pick the best propulsion, the best body, and the best weapon. But in fact we can't choose those independently, for there are many restrictions imposed:

• Sometimes the desired weapon class, body class or propulsion class is unavailable. For instance, weapons of anti-tank role (rockets, or maybe cannons) are unavailable for quite some time in early game. Or you may have not yet researched hover propulsion. In this case it is unobvious whether you can proceed by making the second best decision (eg. using machinegun as an anti-tank weapon until rockets are available, or prefer to keep upgrading machineguns instead of researching flamers from scratch simply because your enemy switched his tanks from new paradigm bodies to collective bodies) or you need to stop and reconsider the very choice of producing a unit (eg. on a hover-only map you'd prefer to wait for hovers rather than fill your base with wheeled or tracked tanks).
• Sometimes components just won't match. For instance, you may believe that leopard body is better than scorpion body for your VTOLs (since it provides faster reload due to decreased weight, and also has the same armor and only slightly less hp), but you can't put heavy bombs on it, because they will fly too slowly. Sometimes some sorts of weapons are unavailable in form of cyborgs or VTOLs (for instance, a pure rocket player will never had anti-personnel VTOLs or cyborgs), but available as tanks and defenses.

Thus, here is a question: does anybody have any idea how to write a clean and readable code for making this sort of decisions? What sort of algorithm should be used for making it?

My current idea is as follows. First of all, we throw all absolutely unbreakable restrictions into a single checker function: isValidOption(option). Then, we start with an option of all components being independently best in their category. Then we start a breadth first search on an oriented option graph (the Hasse diagram of the partially ordered set of all options, with "better than" as its order) where options are vertices, and arcs are coming from independently-better options to options that are one level worse in one component: for instance, from the (twin AG, panther, tracks) option there will be arcs to (AG, panther, tracks), (twin AG, leopard, tracks) and (twin AG, panther, halftracks). We only proceed our search until all options in our BFS queue are valid; if a certain option we have just pulled out of the queue is already valid, then we don't proceed with searching through it (for it will only lead to worse options), but store it in a separate "result array", which will ultimately contain all maximal valid options. Once the search is completed, we choose the best of the valid options presented by the search (taken from the "result array") via a certain rating procedure (most likely, options that are farther from the search origin will be valued less).

[aubergine]

You probably also need some sort of temporal latching in there as well. Otherwise you'll end up with a complete mixed bag of units, defences and research.

[NoQ]

I'm not yet sure whether to consider tanks, buildings, structures, and researches separately or simultaneously ...

[J.Vaughan]

Few thoughts aloud...

First, I'm assuming this is a complete rewrite of NB post-3.1 master?

Also:

I'm not yet sure whether to consider tanks, buildings, structures, and researches separately or simultaneously ...

If I'm following correctly, wouldn't simultaneously be the hardest to code but most realistic option? For instance, if the AI finds that a player is going wheeled, manta bodies wouldn't it make sense to build both flamer tanks and flamer bunkers around his base? I might be following wrong...

Just an idea, not a suggestion:

Also in previous nb personalities you have research paths and play style dependent on each other. Have you considered defining a play style (e.g. tank rush, truck rush, mixed, turtle) and then defining research paths/the rest of the personality as a subset of that play style?

You could use the same subsets of paths for the different play styles, paths could change but usually play styles dont change in mid game (because if they do, its usually already too late.)

[NoQ]

wouldn't simultaneously be the hardest to code but most realistic option?

The decision of eg. tanks vs. research will have to be made anyway, it's just on what level it is to be made that i'm not sure of. Either first decide that we want tanks and then run the fancy maximal element search, or run the fancy maximal element search in a bigger scope that will include both tanks and research items.

paths could change but usually play styles dont change in mid game (because if they do, its usually already too late.)

I think it's just the opposite. If your rush fails, you can transition to a regular game, while still enjoying some economical advantage until your rush force is completely eliminated. But it clearly makes no sense to switch to cannons when you researched rockets with a few upgrades already.

[aubergine]

You also need to take account of the human player issuing !nb chat commands