Outpost 2 Coding 202: Part 0

[Sirbomber]

Haha, maybe Coding 303 will be a rewrite/sequel.

Anyways, looks like people wanna do the AI.  I'm a little concerned that this may be a bit out of reach, but hey, gotta try, right?

What do people think about this tentative schedule:

• Analyzing the map: Finding chokepoints, nighttime areas (if day/night enabled), mining beacon locations, obstacles, optimal base locations, and enemy bases.  This stuff will be important later, if we want the AI to not drive into cliffs and defend properly.  We'll test this on standard maps, but if people can make some custom ones with some really difficult features, that would be helpful.
• Situation analysis: Figuring out what the AI has access to (units, structures, ore, food, power, morale, population) and what it needs.  This will require it to look at the big picture; for example: if the AI needs Scientists, than it needs a University.  That University needs power, scientists, and ore.  If it needs power, build a Tokamak.  That Tokamak requires ore, as well.  Check the mining situation.  Do we have a mines, Smelters, are cargo trucks?  If not, these take top priority (since if we can't rebuild these we can't get any more income).  Anyways, don't know why I bothered writing all of that now...
• Situation response and non-combat management: Now that the AI knows what it needs to do, how is it going to go about doing it?  If it has multiple goals, how should it decide which goals are more important, and how can it adjust priorities as the game changes?  This section will focus on base construction (what needs to be built, determining building placement, and building tubes as needed), structure management (idling structures and assigning scientists to research as the situation calls for), mining management (surveying mining beacons, building mines and smelters in optimal arrangements, and managing cargo trucks as needed), repairing structures, and whatever other stuff it turns out we need that won't be covered by another topic.
• Basic Micromanagement: Handling units in army-to-army combat.  Dividing units into separate groups.  Handling offense and defense.  The AI will need to effectively make use of the weapons and units it has, kite enemy armies if necessary, and exploit the "extra" range of ESG/Acid Cloud.  If the AI knows it has no chance of winning a fight, should it retreat to join up with stronger forces, or sacrifice that army to buy enough time so it can build up more forces back home?  Depending on how much time we want to devote to this, we can give the AI better micromanagement than a Korean Starcraft player on speed.  Of course, I think we all want the AI to play by the same rules as a human player, so maybe we should limit what it can do.
• Advanced Micromanagement: Sneak attacks, feints, misdirection, and any other subversive tactics.  Attacking through the backdoor, getting the enemy to split their forces, making effective use of day and night, maximizing the effectiveness of EMP Missiles.  Also important: defending against all of these tactics.
• Research and tech progression: Based on the situation, what should the AI research right now?  What types of combat units and weapons should it be building based on what it can build, and what the enemy has?
• Winning the game: Putting everything we've done together so that the AI can play the game effectively, compete and cooperate with human players, play by human rules, and have a decent shot at winning.
• Special cases and "bonus goals":
  • Land Rush
  • Space Race/Survivor
  • Nobody cares about Resource Race or Midas
  • Team combat: Interacting with allies and enemies.  Accepting and using units received from a trade.  Cooperating with and syncing up attacks with allies.  Accepting basic commands from allies.
  • Dealing with disasters
  • Managing morale
  • Adjustable skill level
  • Be able to be loaded into any map, taking the place of a human player.
  • More to come?

Feel free to comment/complain/nitpick (in Hooman's case) as needed.

[CK9]

...We'll test this on standard maps, but if people can make some custom ones with some really difficult features, that would be helpful....

Look no further than here!  Remember the one map I had started working on that was just too big to work?  Two of the the corners had semi-mazes made of cliffs that could be used to test the pathfinding.  All I'd need to do is copy them to a smaller size and fill in the gaps.

No matter which project is chosen, make sure to make a tentitive scheduel.  Without a deadline, most people have a tendancy to put things off indefinately.

[Sirbomber]

Fair enough.  Okay, we're going to start with Map Analysis on Wednesday.  I'll kick off the discussion by posting what kind of information I think the AI will need, and then the rest of you will join in on the discussion with your own thoughts.  Part of the discussion should probably be about ways we can divide the work among ourselves.  After two days, we'll figure out who's doing what and get to work (try to be reasonable here and don't bite off more than you can chew).  I'd like to be done with that in about a week, so let's give ourselves until the 13th.  We can then take another week, if needed, to fix any lingering problems and make a few improvements, but I really would like to move on by the 20th.

In summary:
Start date: 4/6/11
Discussion ends by: 4/7/11
Tasks assigned by: 4/8/11 (begin work here)
Goal date: 4/13/11
Deadline: 4/20/11

[TH300]

I think, that plan is too ambitious.

And your schedule looks somewhat reasonable, but could be improved:

• Map analysis will be needed and it is not the worst idea to start with that.
• I suggest that situation analysis only means to find out whats going on. You seem to want to put resonse in there and that may mess everything up. So, I suggest, to have code that finds out how many armies the ai has, how strong they are and how strong the opposing enemy armies are; how much ore mines the ai has and how many smelters (with cargo trucks) each mine has (and calculate the overall ore "income"); how many convecs the ai has; how many and which structure kits are in the sfs' strorages; even how many colonists the ai has...
• Situation response (I'd rather call it "decision making") should be where the ai decides what to do (including research). The "how to do" is part of the "what to do". There are several possible approaches to this and since it is the core part of our ai, we should put serious thoughts into this before writing any code.
• Micromanaging tanks would be nice, but since we'll have lots of other things to work on, we shouldn't care about it too much.

And lets follow a design pattern like the Waterfall model. Its not the best pattern, but it is simple and will give us better results than using no pattern at all.

Right now we didn't even agree on requirements that the ai shall fulfill. So, lets start with those: The bare minimum would be to have a LoS ai that is capable of winning on any map against any player. I'd personally aim towards a LR ai, because it wouldn't add much additional code and would ensure a useable code structure (whereas, if we start with a LoS ai, it could turn out, that turning it into a LR ai would require serious rewrites). Furthermore, it is probably wise to be aware of the additional goals, that you listed, during the design process.

I'll add my thoughts on decision making later.

[Sirbomber]

The bare minimum [requirement] would be to have a LoS ai that is capable of winning on any map against any player.

Wait, you mean the AI is supposed to try and win?  I thought it was supposed to waste all of its ore on SULVs and Solar Satellites and then cause that weird acid trip bug from Swarm. :rolleyes:
 
Anyways, that big list I posted was actually intended to be the requirements the AI will need to function well (notice that one of them is in fact win the game).  I mean, that's why I spent an hour and a half writing it out.  Though yeah, research could be moved into decision making (what I called situation response; couldn't remember the phrase I was looking for when I wrote the list).  That's just how I do it (since the techs I get and the order I get them in are pretty much set in stone) but we probably don't want the AI behaving that way.

And yeah, I know we're being too ambitious, and I know the schedule is tight.  But I don't want this to stagnate, and we can always push deadlines back as needed.

As for "working on LR first", I don't think that would be best, and I don't see it requiring any significant rewrites if we start on LoS.  We could just have some way of detecting game mode or starting units and assign it a few extra LR-specific goals at the start of the match (specifically, find good ore and build the base before the BM, if any [which raises the question of how we'll assign AM/BM to the AI, but we'll tackle that when the time comes]).  Anyways, if you could list some of the concerns you have more specifically, that would help.



Last thing, and I mean this in the best possible way: if you're going to work on this I need you to remove the stick fr stop taking everything anybody says 100% literally.  When I say "If we need power build a Tokamak" I don't mean "STOP EVERYTHING YOU'RE DOING AND BUILD THAT TOKAMAK RIGHT NOW!!!!!!!" so much as "that's just one more thing the AI needs to consider doing to achieve its goal".

[evecolonycamander]

so basically the whole concept of this AI is to actually have it almost function as a human player and not a dynamix AI. one that functions well enough to be a 'cut & paste' project allowing us n00bs to effectively make the crappiest map and having it be almost instantly playable with the bare minim of edits(x,y cords, Plymouth vs Eden start units, ect.).

am i off here as to the ultimate goal?

[jcj94]

*Slaps ECC*

.. Did you not read the
WIN
under the AI list?

IMA FIRING A mediocre employee.

[Sirbomber]

No.  At the bare minimum, all the mission designer would have to do would be to include a library and call some kind of "InitAsAI" function.  The AI will be able to take care of itself from there.  If we're going to do this, let's do it right.

That said, in a perfect world, this thing would work so well that we could hack an "Add AI Player" button into the multiplayer setup dialog and play a few rounds with it.  But who knows if we'll actually get to that stage.

[Spikerocks101]

Should we get our own forum for this? Also, are we going to have regular times we meet on the IRC to discuss such things? I don't know much about project design, so I'm just fallowing.

[jcj94]

What do you mean our own forum?
I can see our own main topic (like the Outpost 2 Coding), but a whole new forum?

I'll be available to work over spring vacation next week.

 

[Sirbomber]

He means a sub-forum dedicated to the Coding tutorials, kinda like how we have the AI Programming sub-forum inside the Programming sub-forum.  And that's really not up to me.

Anyways, arranging meeting times on IRC for the entire group will be impossible.  We'll keep discussion in the topic for the most part, unless you're working in pairs or something.

[jcj94]

unless you're working in pairs or something.

That will probrably happen a lot.

I work with ECC and TH300 on the IRC a bunch, so I can just talk to them for guidance/ info/ YOUR DOING THAT WRONG YOU'LL BREAK THE GAME!! stuff.

[CK9]

He means a sub-forum dedicated to the Coding tutorials, kinda like how we have the AI Programming sub-forum inside the Programming sub-forum.  And that's really not up to me.
 

Nor me (despite my promotion, lol)

Wouldn't this fit within the AI Programming sub-forum anyway?

[Sirbomber]

Well, it's a tutorial first and a project second, so not really?  Besides, if we were to get our own sub-forum, we'd probably want the 101 stuff thrown in there as well (and locked, at this point).

[CK9]

K, I'll talk to hacker about it (I think he's more likely to respond in the mod/admin section)

[jcj94]

Shameless self-promotion!!!!

Could you shamelessly sef promote Op2?

Anyway, I agree with bomber on the new sub-forum.  About moving the coding tutorials would be fine, but make one that people (like subbed and ECC and I) can post our maps to that WON'T be used for discussion, for as we go through the tutorial.


Can't wait to get this GAI Started!
 

[Arklon]

About moving the coding tutorials would be fine, but make one that people (like subbed and ECC and I) can post our maps to that WON'T be used for discussion, for as we go through the tutorial.

No, nobody is going to go out of their way to do something just for you just because you're unwilling to figure out your own way to organize your progress and so you demand that others do so for you.

[TH300]

As for "working on LR first", I don't think that would be best, and I don't see it requiring any significant rewrites if we start on LoS.  We could just have some way of detecting game mode or starting units and assign it a few extra LR-specific goals at the start of the match (specifically, find good ore and build the base before the BM, if any [which raises the question of how we'll assign AM/BM to the AI, but we'll tackle that when the time comes]).  Anyways, if you could list some of the concerns you have more specifically, that would help.

The best way of implementing LR would be to give the ai the ability to build up everything from a few vehicles. Even a mere LoS ai will need that ability, since it is possible that its base is destroyed or it has to relocate. So, technically, if we create a good LoS ai, we'll automatically get a LR ai. I just find it more organized to start it as LR ai. Even if we don't want this functionality, the ai must be able to build up new bases, so we'll have to write code that finds a base location and thats the hardest part of making the ai LR capable.

Last thing, and I mean this in the best possible way: if you're going to work on this I need you to remove the stick fr stop taking everything anybody says 100% literally.  When I say "If we need power build a Tokamak" I don't mean "STOP EVERYTHING YOU'RE DOING AND BUILD THAT TOKAMAK RIGHT NOW!!!!!!!"

Didn't understand it that way. Besides that I have to say, that
1. I have no way of knowing what to take literally and what not and
2. we have to write everything up clearly as soon as possible. Otherwise we won't be able to collaborate.

Thats why I repeated the obvious requirements. It has to be clear. So, again:
- able to win LoS/LR against any player
- plays with the same rules as human players
- can be integrated into any mission
- It is probably a good idea to make a list of situations that the ai shall be able to handle
- EXTRA: expand the multiplayer protocol to allow adding of ai players to existing maps

Did I forget anything?

To help us get started, I wrote up some thoughts. The first part is about ai quality. Although some of it may appear obvious, I want to be sure that everyone knows what to consider. So, I'll post it anyway. The second part is a suggestion for decision making.

Introduction
============

This document is a (more or less) random collection of thoughts. Its aim is to discuss how to judge an ai's quality and how an ai should work (in my opnion) to make it high quality. Although this may require talking about technical details of decision processes, that's not the primary concern of this document.
Note that it is assumed that the ai plays fair, i.e. it plays under the same conditions as a humand player, with the same amounts of resources, the same resource demands and the same knowledge.


Part 1: judging an ai's quality
===============================

Criteria
--------

The first that comes to mind is the ai's overall strengh, its ability to win games against experienced players. This should describe itself. Since an ai shall be a challange for strong and for weak human players, it should be at least as strong as the strongest player with the option of weakening it if desired. It is assumed that there are enough ways for weakening and it is thus a good idea to begin with creating an ai as strong as possible.

Another thing to look at is predictability. Outpost2's default ai's (if you dare to call them "ai") are pretty predictable which allows human players to exploit known weaknesses and thus makes the ai weaker alltogether. But a preditable ai is also less fun to play against, because it will always, in each game make the same decisions and the player will eventually get bored. Hence an unpredictable ai should be preferred over a predictable one. It is worth considering, though, that even human players are sometimes predictable if they make optimal decisions and the opponent is smart enough to anticipate those decisions. Here we have a little conflict with the goal of making an ai as strong as possible and it seems to be the best compromise that an ai should be unpredictable only to the point where more random behaviour would make it considerably weaker.

What does this mean?
--------------------

It is obvious that a human player fits into that pattern and hence an ai should be like a good human player. It should be capable of making plans, reacting to enemy actions, deciding who to attack, etc. It should be capable of finding a good base location in land rush games, building its base in such a way that an exploding advanced lab won't defeat it, doing research in an order that helps accomplish its goals, building extra ore- or military bases, micromanaging combat vecs and much more.


Part 2: How to achieve good quality
===================================

People may argue that they know better or that the great game "xy" does it the way "yz" and hence "yz" is the best way of doing it or scientists have found the best solution already. So let me tell you that these are just ideas which are open for improvement. Of course you'll have to explain why your solution is better.

The resource based approach
---------------------------

This is merely a scheme for organizing decisions. It is independent of how decisions are finally made. So, how does it work? As a human player I don't go, see that I want to achieve X, which requires me to achieve Y, for which I need Z and so on. That approach requires much thinking, because I have to resolve all dependencies the whole way to where I currently stand. For an ai this would mean much computing, less speed and much complication.

As a human player I see that I have an unused cargo truck and a smelter+mine where it could be used. No thinking required to figure out where the truck will go. When I have spare common metals and my armies are currently strong enough to keep up with all my enemies, I spend metals on expansion, because expansion ensures winning. Expansion is everything that increases ore production or population growth. Even if I don't have enough workers/Scientists to operate the new buildings, its good to have them before the colonists are available (just imagine how something could blow up one of your smelters and you have another one already built). Also, if I have spare workers and an ore production higher than what I need, I may idle a smelter and activate a consumer goods factory. When I have spare scientists I assign them to research. I know which research topic will boost which goal. Not much thinking required. When I have a convec with an Agridome and food stores are diminishing, I build the Agridome next to an operational building. If I have a convoy that is capable of building a base and building a base is judged as appropriate, I build a base at the best location that I can find.


Making decisions
----------------

This part is the most complicated one and it has so many possible solutions that I'm still unsure, whats the best.

I recently read about "Hierarchical AI". It is a way for both, collecting information of whats going on and making decisions. It works much like the military in the real world. Since I don't want to write more than neccessary, I am just poiting to http://www-cs-students.stanford.edu/~amitp...rarchalAI.html#.
A possible hierarchy for Outpost2 could be at the top the "ai commander" with the goal to win the game (or whatever we want it to do), below the (mostly independent) bases, below the armies that belong to the bases. Of course there will also be armies that don't belong to bases and there will be exchange of resources between bases. For some structures it matters where they are built (e.g. DIRTS, smelters), for some it doesn't (nursery, agridomes). I am not yet sure, which instance should decide about the operation of which structure type.


Particular decisions
--------------------

We'll need code that makes the following decisions:
- Finding a base location
- finding build-locations for single structures
- (micro-)managing armies
- building defence lines
- chosing research topic
- idling buildings / distributing colonists
- metal usage
The list is probably incomplete and we should complete it before starting coding. Note that the list has to fit to the "resource based approach", unless we want to do something different.

[Sirbomber]

You say that you don't think "I need X to do Y to do Z" and that's true, most human players probably don't think that way (not consciously, anyways).  Unfortunately, most of your ideas operate under the assumption that the AI works like a human.  It's great that you and I can see an empty Cargo Truck and have it start mining, and you have no idea how much of a luxury it is to just be able to think "build this new Agridome next to another building with a tube connection".  But have you actually given any thought as to how the AI is going to figure out, "I have an idle truck and a mine and smelter to stick it on" or "the Agridome can go here and be connected to the tube network"?

Finding trucks (not actually code):

Code: [Select]

// Iterate through all AI Cargo Trucks
while (more trucks to look through)
{
    // Check status
    if (truck isn't in use)
    {
        // Now iterate through all mines
        while (more mines to look through)
        {
            if (Common Ore Mine)
            {
                // Iterate through all the Smelters "attached" to this mine
                while (more smelters to look through)
                {
                    if (Smelter has less than 2 trucks on it)
                    {
                        assign truck to this mine and smelter
                        record truck so we can restart it if it gets EMP'd
                        update Smelter/Mine truck count
                    }

                    if none found, do nothing?
                }

            }

            if (Rare Ore Mine or Magma Well)
            (repeat Common Ore Mine/Smelter code)

       } // done looking through mines

    } // if truck isn't in use

    if truck is in use, do nothing

} // end search

Code: [Select]

// Search for new building site connected to tube network
// Iterate through ALL buildings
while (still more buildings)
{
    // Check if they have a tube connection
    if (curBuilding.HasTubeConnection() )
    {
        // Check if there's room for this building
        // Low priority: Make sure the buildings are aligned and look pretty.
        if (space for this building)
        {
           Add building to build queue and assign a priority
           Reserve this location so that other buildings won't take its space
        }

    } // if tube connection found

} // done looking through buildings

bool HasTubeConnection()
{
    // Apparently it's unlikely we can make an ASM hack to do this, so...

    // Check around the building for tubes
    Get building's x/y dimensions and origin in terms of the top left corner

    // Use that data to check every tile around the building ("footprint" tiles)
    for each footprint tile
    {
        if (tube)
        {
              // Check NESW for more tubes until we hit a building.
              // If that building is a Command Center, return true.
              // Otherwise, continue checking for more tubes/buildings

        } // if tube found

    } // while still checking footprint tiles

    // If we get here, we couldn't find a tube connection
    return false;

} // end tube connection checker.  This reeks of recursion, so there's probably a better way, but I'm not good enough at this to think of it.

I appreciate your effort, but you're only concerned with the end result; what the player will fight against.  This is useless right now.  Before we can even think about that, the AI will need to understand the rules of the game and be able to play by them.  There will come a time for that document you're writing.  But that time is not now.

[Hidiot]

I'm pretty sure we'll want to AI to be modular.

So for instance: first we want to make it know how to build a structure, then we want it to know how to place the kit, and then we want it to know how to build a base (place a kit relative to its other buildings)

[Sirbomber]

Maybe we're using different definitions of the word, but what does that example have to do with modularity?  Do you mean we should be able to easily change the rules it uses for (using your example) building placement?

[TH300]

I appreciate your effort, but you're only concerned with the end result; what the player will fight against.  This is useless right now.  Before we can even think about that, the AI will need to understand the rules of the game and be able to play by them.  There will come a time for that document you're writing.  But that time is not now.

You are right: The AI needs to be able to play by the rules of the game. The "Particular decisions" section of my document was meant to tackle this. But I think that we should have the structure of the whole, before we start coding one part. I mean, if we want to do this thing hierarchic, we'll likely want code that does search for a building location in a given base. We need classes that represent a base (and other instances in the hierarchy). Everything has to interface with those classes.

My plan is to do a class diagram of everything before we do any coding other than prototyping. We don't have to, but if we don't, we may have to redesign the whole thing a few times.

[Sirbomber]

I mean, if we want to do this thing hierarchic

You're the only one who's even mentioned that "AI Commander" thing.  I've glanced through the document.  Just looking at the "topmost-level" of decision making, the thing would have to be self-aware (and I for one will not be responsible for the robot apocalypse).  Also, the author hasn't even attempted to implement that.  It's all theory.  And we're just a team of amateurs doing this for learning and for fun.  Not going to happen.

The real problem here, TH300, is that you want this to be your project.  You're trying to get us to do things the way you want them done.  This is a tutorial first, and a project second.  We need to work on things in small, manageable chunks, starting off easy and working our way up to the big stuff.  Yes, this approach means we're going to have to deal with all kinds of problems later on.  There'll be a lot of extra work tying it all together and fixing the bugs that will inevitably arise when we do that.  But I'm not going to apologize for that.  If you can't handle working as a part of this team, then I think you need to step aside and let us get work done.

Part 1 will be posted within the hour (probably going to need an extra 30 minutes or so since I had to write this out).  I hope to see you there.

[Arklon]

I mean, if we want to do this thing hierarchic

Reading that Hierarchal AI article, what it proposes seems incoherent, particularly the part about the "AI commander" making abstract, strategic decisions. It proposes very little in the way of HOW the AI will "look ahead", process "what-if" scenarios, etc., and it seems to me that in order for it to do that you'd be looking at something that'd be more along the lines of true AI, which would be unfeasibly complex for this project.

we'll likely want code that does search for a building location in a given base. We need classes that represent a base (and other instances in the hierarchy). Everything has to interface with those classes.

And how is it going to know what "a base" is, how is it going to know how, when, and where to make new "bases", etc.? It seems to me that you're thinking about this from a "it'd be totally cool if the AI did this!" perspective and not from a realistic, programming perspective.

[TH300]

I mean, if we want to do this thing hierarchic

You're the only one who's even mentioned that "AI Commander" thing.  I've glanced through the document.  Just looking at the "topmost-level" of decision making, the thing would have to be self-aware (and I for one will not be responsible for the robot apocalypse).  Also, the author hasn't even attempted to implement that.  It's all theory.  And we're just a team of amateurs doing this for learning and for fun.  Not going to happen.

Yes, its all theory. But all theory is any other approach that you present to me, even if it has been done already, unless you give me the source code of an existing implementation its all theory for me.

The real problem here, TH300, is that you want this to be your project.  You're trying to get us to do things the way you want them done.

As long as my ideas make sense, I see no problem with that. If my ideas don't make sense, I expect you to give better arguments than "its all theory". I have made programs from "its all theory".

This is a tutorial first, and a project second.  We need to work on things in small, manageable chunks, starting off easy and working our way up to the big stuff.  Yes, this approach means we're going to have to deal with all kinds of problems later on.  There'll be a lot of extra work tying it all together and fixing the bugs that will inevitably arise when we do that.  But I'm not going to apologize for that.

This may work, but it doesn't motivate me. I have written so many unmaintainable programs, because I didn't design them properly. I don't want to produce another piece of s***. If we do this how you want, we'll end up doing it once, producing something that we won't want to continue working on and then starting new, using the experience from the first try. That will repeat until we decide to design the thing properly before we start coding. ("will" means here that I see a chance of this happening of above 90%)

If you can't handle working as a part of this team, then I think you need to step aside and let us get work done.

Wait, if I debate your suggestions I cannot work in a team, even though you are the one who wants to end the debate?

Tbh. I had seen that coming: several people have several ideas of how to do it. I do currently not feel like pushing my ideas through. But this means, that if you want to do things that look too stupid to me, I'll loose motivation and help less. Don't worry, this point is still a bit away. Regardless of this, I enjoy programming more if I am working on a new, interesting algorithm that no one implemented before. Give me the chance to make algorithms, otherwise I won't be motivated and hence be less productive. And thats not any decision that I make, its my nature.


Reply to Arklon's post:

I mean, if we want to do this thing hierarchic

Reading that Hierarchal AI article, what it proposes seems incoherent, particularly the part about the "AI commander" making abstract, strategic decisions. It proposes very little in the way of HOW the AI will "look ahead", process "what-if" scenarios, etc., and it seems to me that in order for it to do that you'd be looking at something that'd be more along the lines of true AI, which would be unfeasibly complex for this project.

Strategic decisions could be
- army A is facing enemy army B and is inferior. Hence it needs to be reinforced. Thats not at all difficult: there will be data structures that represent single armies (of the ai; for human controlled armies, we'd have to create some heuristic to figure out which tanks belong to an army - something that we'll need anyway)
- in base C the only structure factory got destroyed. Produce a new one a the base with most available capacities and send it to base C.
- the enemy is advancing quickly in military research, we shouldn't fall behind and thus we focus on military research.
- food stores are diminishing, thus we build an agridome in any of our bases.
I cannot thing of any example that we couldn't implement. And we don't have to do the "look ahead" and "what if" parts. I agree that those are a bit out of range. I merely want the hierarchic structure.

we'll likely want code that does search for a building location in a given base. We need classes that represent a base (and other instances in the hierarchy). Everything has to interface with those classes.

And how is it going to know what "a base" is, how is it going to know how, when, and where to make new "bases", etc.?

- What a base is? - the ai simply keeps track of which buildings belong to which base when building them. If two bases are close together they may be treated as one base. The point is that each base will need certain structures to defend itself. If the next vehicle factory is miles away it won't help much if a base is under attack.
- When to make new bases? - when more resources are needed or when it makes sense to defend a bottleneck in the middle of the map or when more space is needed....
- Where to build new bases? - depends on what the base is for. A mining base will be built where good beacons are found, a strategic base will be built where the position is easily defendable. That may be hard to figure out, but we'll need that anyway.

It seems to me that you're thinking about this from a "it'd be totally cool if the AI did this!" perspective and not from a realistic, programming perspective.

I believe that it can be programmed, because its after all just a system of entities (which are represented by classes)

We can make programs which model parts of the real world. Object oriented programming gives us that. One condition is, of course, that the model doesn't contain too many details. But this is given, because Outpost 2 itself doesn't contain too many details.