This is something I’ve been pondering as well. It’s probably too much to hope that Blizzard will release the Starcraft source someday. That might be a terrible idea anyway, given the fact that the community is still going strong, not to mention the professional-level competition gameplay. Having the source would make certain kinds of cheating possible. You couldn’t get free money or anything like that, but you could make it so that the interface shows you information which should be hidden from you. You’d be able to see (but not attack) fully cloaked units, start with the map explored, see what resources your foe has, and other information along those lines. Basically you couldn’t make a hacked client to let you do anything you couldn’t normally do, but you can make one that would let you know what you shouldn’t.

Still, the idea of competitive AI programming is really compelling, and moreso if we’re talking about doing it with a game where humans can join in. Sure, you could write your own platform designed to let programs fight it out in some arbitrary manner (and there have been many systems like this in the past) but the whole thing doesn’t really get interesting until it has to face a human being. I think an interesting idea would be for a game designer to devise their own scripting language (probably some C++ flavored thing, but whatever) that allowed anyone to write AI modules and share them with others. Non-programmers could download new AI packs if they want a new challenge. Introduce some sort of global rankings system and we can see which AI packs fare best against the userbase and which ones people enjoy playing against. It would keep the game fresh and new, even for people who stick to the single-player experience. Actually, it would turn vanilla Human vs. AI play into a sort of proxy Human vs. Human. It would be some sort of new form of multiplayer, going against someone else’s AI.

And now, let me construct my fantasy system and how I think it should work:

To keep it fun for human players, the system ought to be restricted so that the AI can’t know things that a human wouldn’t know. You don’t want to ever worry that the AI you’re playing against is a “cheater”.

There should also be some sort of limit on how fast the AI can issue commands. It’s not very fun fighting an AI that can control eighteen individual units and have them all doing different things at once. “Selecting” units should be free for the AI, but issuing a command to the group should only be allowed at certain intervals. This will encourage AI programmers to “group” units the way humans do. Sure, you can have half a dozen Ghosts attempt to run in and lock everything down, but you won’t be able to give them those unique orders faster than once every other second, and while you’re doing that you’re ignoring units elsewhere on the map.

The AI programmer should have to put up with the same unit behavior that humans do. If Battlecruisers tend to drift away, get distracted and end up chasing peon units on their own, then the AI coder will need to tolerate and deal with this as well. This also means that AI coders get to benefit from the built-in unit pathfinding and foe selection without having to write their own.

The AI programmer should have access to everything a human does. Rally points, formations, unit stances. I would even argue that making these choices should be free. (Not count against the AI limit on commands issued.)

While the AI must deal with fog of war like any human, I wouldn’t want to restrict them to only “seeing” a single screen of data the way a human does. Sure, it would make it more fair if the AI could only be “looking” in one place at a time the way a human does, but it would also make AI coding a lot more complex.

You’d need some way to limit the CPU cycles the AI is allowed to suck down. You want to be able to play against several AIs at once without slowing things down, so you want to strongly encourage speedy, efficient code. Even on modern machines it’s pretty easy to slow things down if you start doing heavy-duty a statistical analysis on a battle between dozens of units.

I imagine you’d have functions in your AI script: Things like: new foes coming into view, units being injured, new units coming under your control (produced), units dying, units activating special abilities, and so on. The game would call these events as they took place, and this is how the AI would “see” the world. The default AI that ships with the game would be built using this system, and would be the example program that new coders could use to teach themselves about the system. Ideally, AI scripts would be shared in plain text format, thus enforcing a system of open source.

If someone put out a game like this, within a few months the game would have unparalleled AI. The combined work of many fans, sharing their efforts over time and seeing their attempts pitted against the community at large, will rapidly achieve what no in-house AI coder could hope to do on their own.

This would be incredibly cool. I would probably buy this game and spend all my time creating AIs with different parameters and then setting them up against each other and never actually control a faction myself.

While great in theory, such coding will always have inherent limitations, chief among them being lack of true cognitive ability and problem-solving. As such, only a “brute force” method of AI work (where it considers many, MANY different possible actions) will no abusable weaknesses.

Even then, there will still be ways a human could deceive the computer, behaving in ways that give the AI only certain viable choices while building the perfect counter for those choices.

I agree that it would produce better AI than we get now, but I strongly expect it would be incrementally better, not revolutionary or orders-of-magnitude better.

Personally, I think a game with better pathfinding and more efficient troop movements (both because of better pathfinding and other issues, such as proper unit interactions between fast and slow units or large and small units, etc) would be a better first step.

Now, I’m not sure about teams, or any advanced communication between bots – but the general idea is to write AI logic for a robot (by subclassing a Robot object iirc), given some built in operations such as rotateGun(angle), shoot(), rotateRadar(angle), scan(), getDistanceToFoe(), moveForward(), moveBackward(), turn(angle) – well… you get the idea.

Once you write your AI you can add a bunch of robots to a simulation and watch it play out.

There was a similar program (and no doubt many others), but the nice thing about this one is writing in a vaguely understandable language. Others I have tried included learning some form of obscure vm assembly.

Well, I hope this was vaguely related, but a step forward would definitely be extending to include team based systems with communication… that would be waay cool :-)

Rather than limiting the number of orders that an AI can give, why not do this in levels:

1) An AI for each unit, that could understand what other units it was grouped with, what was around it, and what its strategic orders were.

2) An AI to do the strategic things: group units, build stuff, and give orders.

You could let the human players also write, download, and use AIs for the first category, which would hopefully eliminate most of the micromanagement and reduce or eliminate any advantage the AI would have by being able to click as fast as it wants on the strategic level.

Civ IV has an extremely rudimentary system like this. You can change out certain values in XML files to change the behavior, preferences, and advantages of rulers, races, units, etc. And it does make a difference, I’ve changed some values to extremes, and extreme behaviors came out.

Back in the day there was P-Robots and C-Robots, basically robot scripting games where you used Pascal or C to program a robot and pit it against your friends or other robots you built. It was really popular back in the bbs days, and I still think about it sometimes when I see old Pascal or C code. That may be what robocode is based on.

I suspect that the sort of “cheating” that you mention here (and in your earlier post on Stardock) is necessary to overcome the inherent stupidity of AI by contrast to a real human player.

This is only a guess (and I’d love to see it tested by someone designing a game system along the lines which you propose, Shamus) but I strongly suspect that a system which limited AI to the level of control possible to human players would prove incapable of producing a decent obstacle to even a moderately talented human player.

AI cheating, in other words, is a necessary evil which makes up for the intuitive capacity of the human brain — a capacity which from the AI perspective is itself a form of “cheating”.

Now this is something I’m qualified to talk about. I went to GDC in February and heard Soren Johnson, the director of Civilization IV, talk about how his team implemented, among other things, the AI in that game.

First of all, the AI doesn’t know the identity of any of the things you can make in the game, only their properties (defined in XML). So user-made objects will always work. It doesn’t know to “build a spear guy now,” but instead it thinks “I need some defense. This one has a good balance between attack and cost; I’ll take it.”

Second, the AI was implemented as a DLL, rather than a static part of the executable. This means that it’s possible to drop in a DLL of your own and switch out the AI without revealing the source code of the game.

Third, some time after the game’s release, the AI’s source code was released as well. Since then, players have written their own AI replacements.

2 second delay is weak. with group numbers, one can control up to about 10 units individually at high speed by hitting a number to select with the left hand, and clicking where they are to move to. perhaps limit their activities in a different way, like forcing the ai to use a viewport the same way a human does. Introducing a delay when the viewport is moved would better simulate human play.

edit: also, controlling 3 at high speed is easy, the player’s left hand can remain still. with 10, they must move their hand, so diminishing returns on ai hotkeys would be needed.

edit2: I’ve just realised, cpnventional RTS ai tries to simulate an enemy force as used in the single player game. what you’re considering is an actual ‘bot’ as thought of in games like quake. Bots in FPSs are supposed to play as much like humans as possible, wheras previous AI techniques had simply tried to be a competent opponent.

“Sure, you can have half a dozen Ghosts attempt to run in and lock everything down, but you won’t be able to give them those unique orders faster than once every other second, and while you’re doing that you’re ignoring units elsewhere on the map.”

Releasing the source doesn’t make the sort of cheating you describe possible — it’s already possible. Back when I was playing Diablo 2 and Warcraft 3, maphacks were in common circulation, and I don’t see any reason to assume Starcraft’s any different. If the data’s in memory, the game can be modified to display it.

The only way to prevent that kind of cheating is either rigidly control what information the client has, or control the hardware in use. I assume the serious tournaments do the latter.

All you need to do it hot key them and cycle through them while using the keyboard hotkey. :D

BAM!
That falls on the same vein on how the Computer CPU on Starcraft instantly uses the scanner thing that connects to the CC. think of pressing Space to get to the action, pressing 1 ( hot key for scanner ) then the scan hotkey, press the button, and watch those DT’s get slaughtered.

It masses units, bombers and ect, drops nukes intellectually, though the bots CAN “cheat” but thats for those pro players that think that they can handle it.
Though the above massing and stuff, is limited to what “game” thats being used, as Spring is a engine made to run games, so most AI’s have to be tailored for the game. you can even set them up to learn. :D

I love this idea, but I’d go one step further: I’d make the Unit AI open-source as well as the strategy/player AI. I would love to be able to code up my own solution to unit pathfinding and enemy targeting.

It would make the programming of the player AI a little more complicated, though. The AI player would have to be flexible enough to use ANY player-created Unit AI as well as the default one built into the game. They would still get to have this behavior “for free”, but they would not be able to rely on an in depth knowledge of how it will perform in any given situation.

I’d love to see this work, but I do agree that in limiting the AI to being only as good as a human, you’ll probably be making it far too weak. As I understand it, most AI need some kind of cheat programmed into them in RTS to work properly.

Nice idea, Shamus.
Essentially you are talking about an AI API built into a game. The API would only provide methods for accessing information and issuing commands in the same way a player can. Basically this is the way I’d see it shaping up:
Real-time strategy games aren’t really real-time. They just have so many “turns” per second that it seems real-time to the player. The API would provide the AI with a chance to act once every so many “turns”, say roughly 2 or 3 times per second.
On the AI’s “turn” it would be provided with all information available to it: the visible/explored/fogged map, the position, health and current command of every controlled unit, and the position/direction/activity of ever known enemy unit/building. The AI module would then be required to return orders for its units to the game.
The API should provide for a memory cache that persists between “turns” so that the AI can keep track of things like last known position of an enemy unit, planned ahead actions, etc. This cache would for storing of complex data and be large enough so that the AI can “remember” whatever it wants (within reason, perhaps cap it to some arbitrary number of megabytes).
To restrict the AI you could do a number of things.
1) Restrict detailed information about enemy units. Perhaps limit it to viewing detailed information to X number of units per turn. Only give the AI information that the user can determine based on viewing the animations (i.e. don’t tell the AI what the worker is building, only that it appears to be building something). Basically the standard info provided would be: Unit Type, Position, Direction of movement, simplified action (it’s attacking my unit #7, it’s not attacking, it’s building something, it’s moving, it’s using a special ability, etc). Just the things that a player can see at a glance. More detailed info like exact health, energy, morale, etc. would require asking the API and would be restricted to some number of requests per turn.
2) Restrict the number of orders issued per turn. The API could provide the AI with a “command queue”. The AI could add and remove orders from the queue as many times as it wants during its turn, but only some number of orders will be carried out in between its turns. This would allow the AI to “change its mind” or prioritize from one turn to the next before the order actually gets issued. Orders would take the form of: Unit X, action. For example, Unit 4: Goto this location, Unit 5: Attack target X, Unit 6: Start construction of building type Y at X location, etc. Details like path finding could be left to the game or the AI could micromanage the movement if it wanted to but no more effectively then a player could.
3) Restrict the AI’s time. If the AI is spun off as its own thread then the game could restrict the amount of time the AI has to work. At the end of the time limit then the game will take whatever is in the command queue and stop the AI. This would be tricky. I’m not exactly sure how this would work, especially since different computers will process the AI module faster then others. Then you also have the problem of gracefully shutting down the AI without it corrupting its cache. But you still can’t just let the AI run indefinitely, it’d cause hiccups in the game.

There are a couple of tricky bits:
1) The scripting language will need to be fairly robust. It must be capable of doing some decent level of math or at least the API must supply methods for determining distance between units, time to target, etc. It must be capable of some decent level of organization either fully OO or at least allow for arrays, structs, etc. Some C language flavor (c#, java, javascript) would do the job. The language MUST use managed memory.
2) In order for the AI to accomplish anything in a reasonable amount of time the code must be compiled. In order to maintain portability and sharing amongst the community then the AI modules would be kept in plain text, but would be pre-compiled by the game when the module is loaded (make sure you don’t have any syntax errors before you share your script…). Or perhaps the game could include a compiler as part of the API tools and modules could be distributed with both the compiled module and source code. Perhaps some sort of development environment could be provided with a debugging mode that would allow you to establish a “test” map and step through your AI module code.

You know, I don’t see the reason why those restrictions have to be there. Let there be a global world ranking thing, and let there be an infrastructure for players to upload their AI scripts or whatever.

Allow them to do anything they want with the AI code, even letting the AI be a heinous cheater if they decide it should be.

Just let the potential downloaders know that in some way (maybe tag individual entries with “this AI sees what you are doing”, “this AI has no command limitations” or whatever).

It’d give players quite a feeling of accomplishment if they beat a Cheaty Bastard AI, at any rate; and if the AI isn’t any fun, it’ll get ranked down, thus letting the market correct itself.

Civ 4 also includes a modable API, and its been done once (for Civ 4 vanila).

The problem is that writing a good AI is very, very hard — so hard that you are looking at investing 100+ hours, maybe much more than that in coding alone, not to mention the repeated cycle of “tweak the code, run the game, play for 4 hours, find a bug, tweak the code.” This is made all the worse by the fact that you are almost certainly never going to make an AI that can challenge /you/ (as the developer) — since you developed the AI from the ground up, you know exactly where it is weakest and therefore have an enormous advantage.

Note that it a full fledged AI makes it all but impossible to restraing the AI to “human play” — for example, the AI will never lose track of a unit during play (especially when the screen is busy) and will be able to calculate odds on the fly in a way that a human never could (“Given x friendly units and y hostile units in a straight up combat, for example.”)

This of course just one entry, and with time the file could get rather large. But with modern database technology the information could be accessed rather quickly. The objective of this would be that over time the AI could piece together which units would fight well again enemy units. In the example 3xU-003 would be 3 Marines assuming the AI is playing Terrains. The AI would know that it has fought 4xU-110 (4 High Templars) with 3xU-003 (3 Marines) and 2xU-008 (2 SVCs). The AI would also know that he has lost type of fight 6 out of 8 times (2/8). Along with it the AI would know that the total cost of lost units in the past was 1700 Minerals.

Assuming that Minerals had a 1:1 strategic value (strategic value would be determined as such C/R*A=V where C is the Current amount in stores/bank, R is Remaining amount on the known map, A is the rate of Accrual or the rate the AI is collect that resource, and V is the strategic Value) and using the formula (((Win/Lose)/L_U_Cost)-L_U_Cost)*Strategic_Value=Chance the chance of this particular battle would -1275. Of course the high the chance the better the deal and the AI would know this and fight according to this data.

Also, one could add in rule sets such as deception and such for example. If the AI knows that you haven’t been near it’s base yet and you encounter this particular set up while on patrol it would be set for example to add 10000 to it’s chance if it were to move in a direction not it’s base when fleeing, or to fight in such a way that would not reveal it’s base. Or say it could add 15000 to it’s chance if it ran toward a mutual enemies base if it knew where one was.

Wow, I don’t think I have ever written anything this long and geeky before…

Theoretically, such a program wouldn’t have to be a part of Starcraft at all. In theory, a program could be written that examined the screen (the way that a human does), simulated mouse button and key presses (the way a human does), and so forth – thereby being forced to use the exact same interface as a human. It’s hard to see how you could be any fairer than that. Assuming you don’t have the program examine raw memory it couldn’t cheat any more than a human could – and if it played well, it might even pass a simplified Turing Test (“play two games against different opponents; now tell me which one was the human?”).

Robocode does allow for multi-bot teams to be created. I think there is a main bot that you have to keep alive for the team to keep going.

There are a few others. They were created for the ACM International Collegiate Programming Competition. They are written in Java and free.

CodeRuler:The game pits rulers against each other in a series of matches. A match consists of up to six rulers competing with each other. Each ruler starts a match with one castle in a random location on a finite two-dimensional grid of squares, with the same amount of peasants and knights as the other rulers. The task of a ruler is to give orders to its peasants, knights, and castles.http://www.alphaworks.ibm.com/tech/coderuler

CodeRally:Players develop a rally car and make decisions about when to speed up, turn, or slow down based on the location of other players or checkpoints, their current fuel level, and other factors. Each player can test their car locally against a number of sample rally cars.http://www.alphaworks.ibm.com/tech/coderally

CodeInvaders: The spaceship class allows each player to control his ship’s thrusters and weapons. The ship can move around to collect energy, attack opponents, and bring energy back to its home planet. Points are awarded for different actions, and the player with the most points wins

While I agree on the non-cheat rule, Shamus, I think we should allow the AI to control as many units it can, as quickly as it can. We want to develop the badassest AI possible, and throw them at each other to see how they kill each other (oh my god.. are we monsters?)

Off course, such limitation could be used. You know, it’s like Bridge Builder: you have bridges that are ranked as “clean” bridges (nothing breaks) and the other ones. You could use specific categories to keep the AI that uses less AI-ability to win and simply more good tactics, and use classifications (Nethack-like challenge awards) to compare them, as opposed to “pure beasts”, with no rules about their creation.

It will simply challenge the best players in the world to play against those pure beasts. It will end up either in incredible Man Vs Machine duels, or merely in Machine Vs Machine matches. As someone up there said, creativity of an adaptable and intelligent mind will always win (personnally, I say it remains to be seen).

You actually can edit the AI for Starcraft already. I forget the details because I haven’t done Starcraft modding in years, but somewhere in those mpq files there are scripts for the AIs. There was even an editor for them, although it was kinda buggy.

However, these scripts were pretty limited. You have almost no control over the actual units, so it’s mostly a matter of what to build, when to attack, and when to expand.

Assuming you don’t have the program examine raw memory it couldn’t cheat any more than a human could – and if it played well, it might even pass a simplified Turing Test (”play two games against different opponents; now tell me which one was the human?”).

Well, you’d need to add code to make the AI call you a mexican jew lizard (or something), too.

Just on a side not from what Zereth said… Last year I worked on a project for university that took the form of a network game of cluedo.

We wrote the server and then decided to keep the AI separate – essentially the Player interface was extended by both the user and the AI classes. This meant we restricted the AI to use only that information which was broadcast to every other player. It also had access to chat functions, so the guy writing that code added in taunts. If the AI made a correct guess or was incorrectly identified as the suspect it would send some random abuse to the other players :-D

GAZZA: In robocode you write a Robot program that takes the following form:

a set of methods that ask questions about the environment: Can I see another robot? How far away is that robot I see? How far am I from a wall?

a set of methods that control the robot: turn, forward, back, rotate turret, rotate scanner, shoot.

a set of methods that handle events: what do I do when I get hit? What do I do when I see a robot? What do I do when I hit a wall?

You can write s SimpleRobot where you have a single run loop – it might consist of go forward, turn right, go back, shoot.

You can alternatively subclass an AdvancedRobot which let’s you take advantage of some more advanced controls. You could also write separate threads to handle scanning and movement for example – to free you from the limited ‘run loop’ technique.

As martin said it does allow for multirobot teams (I played around with this briefly last night). A nominated team leader might spy a robot. Instead of shooting he can broadcastMessage(otherRobotLoc) to his team. You can then write logic for Drones (the team robots) which will need to listen for messages and decide what to do. E.g. BlindShooterBot might turn to face the given coordinates and commence firing. OtakuBot might turn and start moving towards the robot. (Or maybe BodyguardBot would see which way the robot is moving and get in front of it – sacrificing himself to keep the leader alive).

It’s worth a look – the program is much more mature now than the last time I checked it out. Anyway, sorry for the double post.

I did dabble a bit in AI in NeverwinterNights, particularly with an evolving AI. The main problem I ran into was the time it takes to test it. So I suggest that if you had such a game, a non-graphic test option would be useful. Free from human response times and interaction, and the need to compute graphics, it would run a lot faster and could be tested easier.

It must be capable of some decent level of organization either fully OO or at least allow for arrays, structs, etc. Some C language flavor (c#, java, javascript) would do the job.

Comments like this drive me crazy! I HATE C; it’s syntax is awful. C itself (and C , to a mildly lesser extent) is a terrible language with no real safety features, basically glorified assembler (Pointer arithmetic??!??!! The entire point of higher level languages is to do that stuff for you!!)

You want the ability to use arrays, structs, etc? Well, let’s see, that narrows it down to… um, essentially every higher level language in existence!

There’s nothing special about C, or at least, nothing special in a GOOD way.

The only special thing about Java is that it was implemented properly across multiple platforms – that could be done with any language.

That said, a C-family language is probably still a good choice… like Windows, it’s not anything like the best, but it’s what most people have and are familiar with. sigh.

There actually is a competition of this sort, at least in small scale. At the University of Champaign-Urbana in IL every year, there is a Computer Science convention called Reflections/Projections. One of the events at it is a 24-hour programming competition called MechMania (with all the mountain dew you can drink) wherein teams of 3 from various colleges across the country compete to design an AI for a specially constructed tactical/strategy game that the event organizers spent all year designing. The AIs, when the time is up, are pitted against each other in a tournament.

I did it 2 or 3 years ago (I was not really much of a programming member of my team; I did strategy stuff), and our code was actually mourned when it lost because we had fun making enemy units blow their own allies up. Sadly, we hadn’t tested our code against code not our own, so a single fatal flaw in our strategy that caused all of our artillary units to lose artillary duels was not caught. We didn’t win any of our tournament rounds with the unit deficit.

Actually, I was picturing something similar to Javascript. Loosely-typed with managed memory. Even though I despise loosely-typed languages JS would be easy to write a compiler for and would be an easily accessible language for all of the aspiring AI programmers to work with.

Again, I agree with Cadamar – You certainly wouldn’t want AI coders to have to juggle pointers and the like. I’m no fan of JS either, but I think something along those lines would be the Right Tool for the job.

Actually, you could probably get a better tool if you were willing to go out and make a whole new language just for this job with its own syntax and rules, but the learning curve would probably suck the fun out of it and defeat the entire point of the project.

I like your ideas Cadmar. I instead of limiting the number of AI turns per second, though, I’d recommend something either like command types or weighted command values.

With command types you’d have groups like building management, repair, combat, construction, etc… You’d let the AI have a certain number of each type of action over the course of (say) 5 seconds. You could have unlimited commands for “inspect unit health” but only two commands for place building and a couple of attack commands.

That might work, but in times when there aren’t a lot of things to do other than combat or building, the AI would just sit idle waiting for the next turn.

Instead, I think you just give the AI an allowance. Say they get 1000 points to spend, and each action has a specific weight attached to it. Some things will be free, and others will cost more points according to what is fair and how long it might take a player to accomplish the same action.

For me, the idea of this exercise is to get the AI to be better at strategy, and not just make up for a lack of intelligence by being faster at everything. If it were perfectly balanced the AI would be able to get the same amount of “work” done in a turn as a human. In the background, not costing them points, the AI should be “thinking” about its strategy within whatever CPU limits are ascribed by the game engine.

To make the AI “tougher” without making it smarter, you can increase it’s allowance or lower the CPU time restrictions.

Most people won’t remember, it was built by Camelot Systems who were the creators of top notch customization software for starcraft. I believe they decompiled and reverse engineered everything, building programs to let you more easily edit everything. A lot of their projects were left semi-done or not as mature as they dreamed, mainly because the main programmer King Arthur got hired by Blizzard to work on the customization software for their upcoming game Warcraft III.

Spring, a remake of Total Annihilation, has an AI API interface. In fact, each AI is it’s own program (DLL) that is loaded into the game at start.

Callbacks are sent to the AI every tick, and for a variety of events such as unit finished, enemy unit appeared, unit finished commands, and so on and so forth.

The AI is no permitted any information the player wouldn’t have and, due to the odd way resources are set up (various metal extractors/converters, windmills, solar panels, geothermals, and everything goes in and out in realtime), even resource gathering and organizing can be a real bear.

Worse yet, the game interface allows the player to load a different set of units each time, so the AI even has to be able to figure out what’s available and sort through the various units and see what is good for each purpose.

To make AI competition interesting, you need to limit the computational resources available to AIs operating through the API.

There was a Mac game back in the late 80s — “SPECTER,” I think — where an AI was given basically a “next move” register and a timeslice. Whatever was in the register when the time expired was its next move. This allowed AIs to use available time to progressively refine their moves, without requiring AIs to use some particular cycle-counting framework to ensure fairness.

Some games (not RTS) the problem is to make the AI fail believably. If you’re not looking for “the AI that can beat any other player (AI or Human)” then being too much better than the human opponent is ‘not fun’ for the human.

Should the above game get made, I’d be interested, but I’d need to run across a reference here or maybe one of 3 other places – I’ve disconnected myself from much of the advertising out there.

The RTS Supreme Commander does have a very open and mod-able engine. It even has a mod manager. The game provides a lot of core files written in Lua script. New and better AIs can and have been written for it.

Functions affecting the AIs behavior based on available information like described in the OP also can and have been written.

If you’re interested in trying it out just pick up a copy of Supreme Commander.

For more info check out the gpgnet forums. There is an AI mod section. The Sorian AI mod is generally considered the best. Sorian even wrote a how to write AI guide.http://forums.gaspowered.com/index.php

Digging up a very, very old thread to let you know that OpenTTD (open source Transport Tycoon port) has done exactly this: the NoAI framework is an API and scripting language to build user AIs, which then play both against eachother, and against/with humans. It’s great fun to play around with. A company in the Netherlands even organized a contest, which some friends and I won by playing as dirty as AI-ly possible :)

Probably the best examples of this I’ve found are an old game called Omega (no link, since it was on the NES) where you would code the AI for a single tank. You had a very limited amount of code for your AI and you’d pit it against test AI to get more room for it, as well as upgrades to your tank’s armor/weapons/etc.

Even more interesting, and a much better example would be the fanmade Spring, a more graphically advanced, purely skirmish-mode version of Total Annihilation from Cavedog. Originally, the game -had- no management-level AI, and at beta mainly used constant-patrol units and random spawning. However, all current AI is downloadable and player-made, and there have even been a couple ‘AI Showdowns’ in the past.

Figured I’d mention these two, even if I’m posting in something waaaay back in the archives. I’d say I was bumping, but blog posts don’t work like forum topics.

It is a recent development. The first tournament was apparently held no more than half a year ago.

The application seems to work almost exactly as you described, providing the AI only with data the player would know, and indeed requiring a separate instance of Starcraft for it to “play”. It is perfectly possible to pit AI against AI, as well as a human player.

This is pretty much a programmer’s wet dream, as far as I can tell. It’s just sad that only now something like this emerges, when SC1 scene is nearing its natural death. Makes an already extremely small niche even more so. Still, it may enjoy some short-lived popularity.