It should be something useful, new, and reasonably challenging to work on.Sorry about that, i thought you meant it could be anything which included what you said.
I have never made a new unit type, and would like to learn how, if there is a way to do that.No one has ever made a new unit type (unless you count the double turret gp as one, but that is taking only existing stuff and combining it new). Hence no one knows how to make new units. It may even be impossible or require recoding of half of the game.
Thou, just saying, I know nothing about how to go about adding a unit to the game, so I would be little to no help in that aspect.I guess, thats more or less true for most of us and probably all people who are going to participate. The people who know how to do it, didn't offer their help and if they don't change their mind, we simply cannot do it.
...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.
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:
unless you're working in pairs or something.That will probrably happen a lot.
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)
Shameless self-promotion!!!!Could you shamelessly sef promote Op2?
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.
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 toDidn't understand it that way. Besides that I have to say, thatremove the stick frstop 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!!!!!!!"
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# (http://www-cs-students.stanford.edu/~amitp/Articles/HierarchalAI.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.
// 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// 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.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.
I mean, if we want to do this thing hierarchicYou'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.
I mean, if we want to do this thing hierarchicReading 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.
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.QuoteI mean, if we want to do this thing hierarchicYou'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.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?
Strategic decisions could beQuoteI mean, if we want to do this thing hierarchicReading 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.
- 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.Quotewe'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.I believe that it can be programmed, because its after all just a system of entities (which are represented by classes)
- 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.All your base are belong to us.