OK, im in stage of my project where i want to implement the AI of the game. basically what i want to do at this point is make the game work with out human interaction, this is like the AI will be able to handle the economy of a simple RTS game. I don't whant to implement combat neither tactics yet, just the "resource manager" at this point, but im having trouble desining the architecture of the AI. The classes I got so far ( not implemented just in design ) AIPathFinder // Takes cares of all the pathfinding AIResourceManger // Balances the villager acording to the need of resourses ( or houses ) CUnitVillager // A simple villager, has a State machine which take cares of the behavior of the villie. CResource // The resourses like Wood and food ( the only ones at this point ) CHouse // Builds villagers and can store 10 of them what else should I add to these classes? can I use Fuzzy States Machines? or what else can I use? Where can i find good documentation/tutorials/books about this topic? Thanks in advance EDIT: Points to be taken in cosideration - The Villies build the houses - The AI is responsible for building the villies as well as managing them. - The Game Starts with a house and 3 villies. - The AI will have to assing the "need" of a resource or building like wood, food, houses or villies. - The Main goal of the AI is to make a good economy or at least stable. - Im using C++ to do this at first, then I want to port it to Lua, but thats another thread [Edited by - idloco on September 19, 2006 11:36:34 PM]

The basic design looks ok.

I suggest a few more AI entities. These will be controlled by the overall AI, but are seperated for easier maintainance.

AIExplorer : This will be used to explore the map using the villagers to find and locate resources

AIGatherer : This will be used to make the villager locate the resource to be gathered and handle the gathering by queuing the villagers, finding closest base etc.

AIBuilder : This will be used for building the houses strategically when required.

I like blackboard architectures.

The Resources managers could periodically post a number of tasks depending on the current priorities. Each time a villager complete a task, he checks the blackboard, picking up his next task, taking in preference the same task he was doing before, if it exists. In the same sense, other systems can post their needs on the same blackboards, where they are picked up by the ressource manager.

The only problem I can see, is that villagers will never change what they are doing in the middle of a task, unless you specifically tell them to do so. That can also be seen as a good thing :)

Is this for the AI of the AI opponent or the AI of the human played side? it sounds like the former, just want to be sure.

A couple solutions to the former that you might want to consider:

1) Priority queue (pretty much a blackboard architecture)

Divide your production system up into different sub-systems: unit building, structure building, etc. Each system has a heuristicaly driven needs system. Each system places "orders" onto a central queue with some priority value. Higher values get priority and are processed by the queue manager first.

pros: nice central system. you can print the queue to the screen for debugging.
cons: lots of tuning of priority values and heuristics required to get a nicely functioning system


2) Dependency Tree

Organize your whole build system into a tree (you need a farm + a house to unlock the ability to construct a barracks. you need a barracks to build a soldier). Each frame look at the unlocked leaves and the adjacent locked leaves of the tree: apply a heuristic to determine the best choice for the current game state. Choosing a locked leaf means you need to build up the dependencies. If you don't have enough money, just abandon the choice, you'll repick next frame anyway.

pros: also a nice central system. you can easily change your in-game dependencies without throwing the whole AI out of whack.
cons: you're going to need to spend a lot of time working on your heuristics system (it'll require more in-game meta-data than the priority queue).



I've built the Priority Queue system and it worked very well. It did require a lot of tuning and when design decided to change build dependencies we had a lot of catch-up tuning to do which was frustrating. The latter is a system we designed towards the end of the project and did some rough prorotypes of. I'm not entirely sure how it would work in practice but I like the way the underlying design feels.

Any way you go this is a tough problem. The only thing that is definitely true is that you want to work out very simple sub-systems, the combination of which result in your "AI". Attempting to write a holistic system is just far to big a problem to solve cleanly.

An RTS AI is a very complicated beast. =)

Also, apply random choice wherever you can to avoid a very predictable AI.

-me

Quote:

Original post by Palidine Is this for the AI of the AI opponent or the AI of the human played side? it sounds like the former, just want to be sure.

Yeah is for the AI opponent

Quote:

Original post by Palidine 1) Priority queue (pretty much a blackboard architecture)

This is the type i want.

Quote:

Original post by Palidine Any way you go this is a tough problem. The only thing that is definitely true is that you want to work out very simple sub-systems, the combination of which result in your "AI". Attempting to write a holistic system is just far to big a problem to solve cleanly. An RTS AI is a very complicated beast. =) Also, apply random choice wherever you can to avoid a very predictable AI.

Yeah, thats why I only want to make the resource manager and the villager AI, i will take care of the combat later in the proyect.
About the random, thats why i wanted to use some kind of logic processing like fuzzy logic, but I don't know how to integrate it and if it is necesary.

im thinking if i use just states machines, but will make it predictable. so. any sugestions about not making the rts ai like this?

Quote:

Original post by idloco im thinking if i use just states machines, but will make it predictable. so. any sugestions about not making the rts ai like this?

The queue method i outlined used a heuristic approach.

1) for each sub-system in the Resource manager (unit builder, structure builder, farm builder) run an update method.

2) This method will start with a set of possibilities: i.e. right now because of the structures that have been built, the AI can build a soldier, a gunner or a tank.

3) Then you apply a heuristic to those choices to rank them. The heuristics often get complicated but the idea is to look at the board state and come up with little things to tweak a value (say from 0-100). You can have randomness in your heuristics, perhaps the result of a particular scorer returns a result that's vaguly random (i.e. the calculated score is 50, but you return 40-60).
At the end of this step you have something like:

Soldier(45)
Gunner(60)
Tank(33)

4) Then sort the possibilities by that value:

Gunner(60)
Soldier(45)
Tank(33)

5) now pick based on the sorted list. Randomness can also come into play here by, say, picking between the top 4 choices, or by picking randomly between any item that is within a certain score range from the topmost item.

6) put the chosen item onto the central queue which now looks something like:

Gunner(60)
Farm(35)
Barracks(10)

So now you have the choice for each sub-system on the central queue. So you then just pick the topmost item, be-it structure, unit or farm. Again the art of this system is tuning the heuristic scores such that you get the right balance of things from each subsystem into the world. It's easy to screw up a heuristic so that, for instance, the AI just spams farms and nothing else.

You'll need other logic too, to limit queue spam: perhaps each sub-system is only allowed to have one item on the queue at a time, perhaps that's a little vague too (the unit builder can have between 2-5 things on the queue at a time or whatever).

-me

Quote:

Original post by Palidine You'll need other logic too, to limit queue spam: perhaps each sub-system is only allowed to have one item on the queue at a time, perhaps that's a little vague too (the unit builder can have between 2-5 things on the queue at a time or whatever).

I'd suggest that if you're going to use this queue system, then you would benefit from limiting the number of build requests placed in the queue by any specific subsystem to a number related to the total resource committment that subsystem has requested. That is, if that subsystem has 4 requests in the queue and they total R resources, then they can only place another request in the queue if its cost, lets call it r, keeps the total cost below a threshold. So, R+r < R_max. If the request cannot be placed in the queue, then it is buffered in a First In First Out (FIFO) buffer, which supplies the queue. You get the benefit that the items in the queue can always be built and an ordered buffer of things to be built.

Furthermore, the threshold value, R_max, can depend on both game state and a fixed percentage of the current resources available. This means that you can tune a preference for production from each subsystem while allowing the ability to change this preference as the game progresses and you can ensure that subsystems don't over-commit too many resources.

Cheers,

Timkin

an interesting solution would be to use a planner of some sort to work out what needs to be built.

For example:

Stratagy: Zergling rush
Therefore: Goal: 10 zerglings in the shortest time possible.
Initial state: 3 villagers

Maybe something similar to the fear ai? (ie. using A* to "pathfind" a plan out of its current actions?)

Another possibility is a tree.

Basically you start with all the resources you have, and you move down the tree to determine just how many resources goes into each thing this turn.

For example, in the beginning, most of your resources go into mining/making farms, so those end up with say 80% of your resources, but the other 20% of your resources goes to, say, building a barracks. Now, you don't have the N food required to build a barracks at the moment, so you are "saving up" resources that will eventually go towards building it.

This would then work well with a "priority" system. (as dictated by a heuristic). Those with the greater priority get the resources split between themselves, with the other actions being completely starved.)

This would work well if you were, say, under attack, you would redirect most of your building efforts towards building millitary units, rather then, say, expanding and building a new town center further along (to take advantage of a new resource).

Actually, now that i think about it, those would be awesome in combination. You plan to determine which actions take priority, and what to spend on what, and you then use that to determine what shall be build (where to build it is another matter, which would be best solved per building).