AI (ver1.0): Hosted by mindlace

[mindlace]

The general consensus is that although Firaxis should hire/have some wicked AI programmers, no finite group of people will be able to build an AI capable of withstanding the depredations of all CIV players.

Therefore, the AI should be script driven.
Indeed, the AI should be entirely scripts, with the Game Engine just handling environmental issues, pathing, etc.

JT has expressed a concern that this will cause instability.

The other major thread, aside from structural, is what the AI should be able to do:
Have a knowledge of geography
Have basic military competency
understand choke points
a sense of distance
intelligence increases with difficulty
distinct personalities
personalities reflect political changes
evolve to contend with your strategies.

And EnochF is freaked.

[yin26]

Mindlace,

Great to see you here! We were crying for the AI thread...

[mindlace]

(oh- please see the AI Credits post)

Bingman suggested open source, and specifically Python. I'd say it's worth looking at python, but being able to imbed C and C++ programs, etc, opens up the door for too many game crashing behaviors. The scripting needs to be limited.

Rong had some great commentary on the behavior of the AI. Here's my (re)interpretation:

The AI has 3 major areas where the event hooks are:
Govenor (whether city or reigonal (BuildingComplete))
Unit (com or noncom (move, attack, defend, suicide, terraform))
Leader (this is mostly for the computer player- handling diplomacy, etc.)
Global (TurnStart, GlobalWarming, etc)

The engine passes the values for these hooks/variables to the AI. Only Global variables are global- a terraforming unit could 'see' GlobalWarming, for example, and start raising land.

Other variables are global in definition (BuildingComplete) but local in use-
Spartan Headquarter's: BuildingComplete(recycling_tanks)

However, these variables pass into other scripts name-space in certain circumstances: pacts allow scripts to 'see' the other's building variables, same as the human. Units can 'see' the status/type of units in a city when they are near it, etc.

Then there are the 'private' variables- anything declared in the course of the script.

One thought I had is that you could let the 'leader' script run for the human faction if the difficulty level is low enough- and it would act as an advisor. Basically parse whatever decisions it made into text:

"Sir: I believe the defences at #BASENAME are weak. Shall I build a #DEFENDER?"

you could even have a 'time passes' button, and let the (sub)Leader handle the game for a few turns.

[Druid2]

mindlace,

If I'm reading your comments right, I think you're headed for trouble.

"Only Global variables are global- a terraforming unit could 'see' GlobalWarming, for example, and start raising land."

having individual units decide for themselves what they should be doing would lead to the kind of AI lack of direction that we have now.

The <u>faction</u> should look at the situation, decide which squares make sense to terraform to higher altitude, and assign the job to a unit. THEN the unit-level logic takes over: go to the site, do the terraform, etc. When done, it puts itself back into the "I'm available" queue.

[Rong]

A comment on OSxAI. I see the OSxAI idea is more about the AI architecture, how they would go about implementing a new AI model. While this thread is more about the actual AI algorithms that are going to civ3. So there is a distinction there, but not a whole lot. Anyone who is interested in AI issues should read both threads.

Our friendship is indeed a strong one.

[Ralph]

In one area the human logic is VASTLY superior to any strategy-game AI, and that is the human ability to, within a blink of an eye, filter out good and worthwhile abstract strategic choices, from the not-so-good ones.
Artificial intelligence often stinks in this respect – it often had to rely on pure number-crunching capability alone, as a poor substitute.
Just look at how long it took for IBM to create a Deep blue program that could finally beat Garry Kasparov (and that in a game with very few and simple rules, on a tiny uncovered 64 square “world”, and with no element of chance involved whatsoever).

The bottom line:

Before suggesting some rather complicated and abstract game-ideas – please bear this in mind: It is almost certain that the human player can utilise these choices MUCH more effective then the upcoming Civ-3 AI.
The more abstract and complicated some of these choices are - the harder its gonna be for the game-AI to really compete on FAIR and EQUAL terms against the human player.

Therefore we should perhaps avoid at least some of them.

[kmj]

blah. I think we should make high demands. Tell them to reach for the stars. Work their asses of and spend a good deal of cash on good ai developers.

I'm not expecting big blue or anything, but I want the ai for this game to be as good as it can possibly be.

Demand the best.

And if they fall short? Well, they will fall short of what I want. I can guarantee it. But the closer they come, the happier I am.

And I feel we should do our best to let them know that we want them to do a damn good job on the ai. The higher we raise the bar, the higher they'll try to jump, no?

[Bingmann]

I think it's important to not be too "pie in the sky" with these suggestions. Unless they are really gung-ho about an idea, the harder and more complex it is to do, the less likely it is to be undertaken. Sure, a brand-spanking-new dedicated AI scripting language would be great, but it would be a massive job, diverting resources from other aspects of the game. There's very little payoff to the company to pursue this idea unless someone high up the chain of command has a personal interest in it. Lots of work for little to no impact on the game for most of the buyers is a no-go. The beneficial impact on the game from an unknown group of AI hackers of unknown size and ability is a great big unknown which makes a large investment very risky.

That's why I propose several degrees of open-sourcing the AI, so that the designers can pick the level of commitment they can afford:

1 - Segregate the AI code into a dll and publish the source code. This takes extremely little effort on their part to do - mainly determined by how detailed they want to document the code. (All code is self-documenting, right?)

2 - Use an existing script language for the AI like Python or Javascript. If this is the approach taken from the start, then there isn't any more effort involved in implementing the AI this way. Retrofitting a script language onto existing AI would be a big job. I guarantee that some of the AI code is going to have to be in C/C++/assembler because some routines are just going to be too computationally intense that a script implementation will be too slow. These fast routines will have to be a finite set available in the main program, or provisions are going to have to be made to attach home-grown dll's to provide unlimited expansion. Pathfinding comes to mind with regards to this issue; it's going to choke in a script language implementation. There can be a default pathing routine in the program, but custom pathfinding routines are certainly a desirable AI feature.

3 - Create a new dedicated script language (and dedicated debugging tools - AI scripts are going to be too large and complex to debug otherwise). This would be really nice, but I think this is going over the top - it's just too much work.

Stability - There are always stability issues, especially in a free-for-all environment. That doesn't mean that there won't be reputable sources of stable versions of AI. Sure, getting abc.dll/abc.script from a random xyz web site might cause problems, but just because some might cause problems or crashes doesn't mean there won't be a large supply of usable ones. I guarantee any AI code that I write will be at least as stable as the code put out by the game company, especially if I use their own code as the starting point.

Script vs dll's - Scripts are not inherently more "stable" than dll's. You can make it so that scripts won't crash the program (failing silently instead - harder to catch the bugs?), but you can't make it so that scripts will work correctly any more than dll's. The main issue in scripts vs. dll's is accessibility. You pretty much need a software development environment to make new dll's while all you need is a text editor to fiddle with scripts.

Specific implementation issues (global/private variables, etc.) - This is kind of like back-seat driving. They've already made AI in the past; they know how to put it together. Unless the suggestion is a new paradigm for the game (say, switching to a client-player/server-game module), there really isn't much point. Please, I sincerely hope nobody takes this personally. As a programmer, my clients often include "suggested" implementations of features that they want; they are invariably useless because they are unaware of how the rest of the program is implemented. Anything past feature descriptions and perhaps general design principles is not helpful. In the long run, it will have very little impact on us if something is implemented as a global variable or a routine or a whatever.

AI helpers for players - This is a great idea if it works. Works really well if the players can write their own AI code/scripts. This is SMAC governors, auto-terraforming, and unit patrol/bomb/explore orders (and to some extent, Civ 2 advisors). It makes sense to piggy-back player helper AI on the computer player AI.

[Druid2]

Ralph, agreed.

I dont think it will be possible for the AI to beat a good human 1 vs 1. But the AI players are 6 v 1. *g*

All we're trying to do is to let it be as smart as we can get it to be. Certainly smarter than the imbecile that is currently "deciding" for the AI.

There have been good chess games for decades.. Good enough to give an average player a strong contest. We dont need to beat Kasparov... just Joe Average.

----------
Bingmann: one more thing Firaxis need to do if they're interested at all. Along with the open source code for the AI.dll, they need to share the data interface. What fields are stored where/ in what format, etc. So that when us "wildcatters" try and roll our own, we'll know what to look for and what to answer with.

I'm sure you know what I'm talking about.

Also, the scripting idea can wait until new dll's are written. The built-in scripts [in the existing AI code] can be replaced by the parameter-driven script files.. if/when... If Firaxis will just agree to the concept, it will be like opening a door.

btw: if they *do* agree to this, I'm going to be here, posting a notice for a new AI-programming company that would sell improved AI modules for cheap *L*

[This message has been edited by Druid2 (edited May 20, 1999).]

[This message has been edited by Druid2 (edited May 20, 1999).]

[Rong]

Bingmann,

This idea has been discussed extensively by the hard-core AI programmers on comp.ai.games. If you are really serious about this (looks like you are), you can read the archive at

<a href="http://www.gameai.com/exai.thread.html">http://www.gameai.com/exai.thread.html</a>

[Darkstar]

Greetings and salutations!

The Player(Human/AI)/Game relationship SHOULD be a client-server deal. It shouldn't matter to the GAME whether its getting the input via the Human UI Client, the Human UI Remote Client, or the AI Seperate Threaded GI (Game Interface). If someone wants to then write a script driven engine, let it. I want an API and a list of all game functions so that I can make the Game Module give me a data vision so that I write a Moronic AI that can actually re-evaluate what is going on, rather than just hit simple script triggers. But as long as the GAME API is fully exposed, it won't matter WHAT interfaces with it so long as basic programmic sanity is maintained. That lets all of us C/C++/ASM guys write what we want, while basic scripters can use the Javascript Engine that would be inevitably developed, or the Perl engine, etc etc etc. The key is encapsulating and publicizing the Game API.



------------------
-Darkstar
(Knight Errant Of Spam)

[Bingmann]

Darkstar(r) - Client/server with published API would be ideal.

Druid - I just want to make sure that at the very least, we get an AI dll & source code even without documentation. Just anything! Right now we have nothing, so even a little bit would be infinitely better, and it would require the most minimal of efforts on their part. (If we don't get even this, then we know we are being completely ignored.)

Rong - Hey, I know that thread! That's what softened my view of dll's vs. scripts - I used to think that scripts were the only way to go for many of the same reasons others have listed. It surprised me when the consensus appeared to be dll's over scripts, mainly for speed issues (most were referring to RTS games and shooter games), but they convinced me that dll's are OK even if they seem scary at first.

[Josse]

Darkstar - I like the idea of having an API, but even better would be to have a framework that allow us to write AI components that can be used together. It would be really fun to write AIs and have them competing against each other.

I have some proposals both related to AI and difficult levels. My suggestions are:
1. Do not use difficult levels. Instead the player should be able to choose what AI or other human players he wants to play against.
2. Rate players and AI like in chess. If player or AI wins increase it is rating. If the loses decrease the rating.
3. Use different AI:s that can improve either by writing better AI scripts/AI programs or by learning themselfs (I know this hard to realise).
4. A dream would that the AI:s are good enought to compete with humans without cheating and having different characteristics.

[mindlace]

DICTATING IMPLEMENTATION:
I agree. I'll henceforth stop with the script examples.

.DLL/SCRIPTING
Well... I don't have a problem with the general idea, but it seems that there are a few 'features' that would be compromised by this notion:

1. copycat- if the computer/human player wants to steal a behavior, and it's written in a .dll, how are you going to pull it off? separate files for each 'type' (units, govenor, faction)?

2. human AI use- Ideally, the human players should be able to describe, to some reasonable level of detail, the behavior of units/govenors. if you go with a 'roll your own' interface/language approach, how would a reasonably addicted non-programmer put together some scripts? Plus, I would think that being able to pop a few lines out _in_ the game would be handy- with all these differing implementations, how would you pull that off?

essentially, I agree with the notion, especially for 'faction' level behavior. I'm just not positive it's the right approach for unit/govenor behavior.

I *want* the computer players to be smarter, but I want my govenors to do things the way I want, and the same goes for my formers, etc.

[Druid2]

mindlace,

I think that the scripts we've been talking about would be like the *.txt files that are read in at the start of the game. Essentially they are data that are used by the program.

the AI.dll is a library of compiled program code that is *part* of the program that resides in memory.

So, non-programmers should be able to change the scripts... with enough documentation. And, yes, they could be screwed up enough to make the game unplayable. That's true now with the *.txt files.

The scripts would have to be details of a predefined set of logic steps. Just like you were doing before.

I think the scripts that have been outlined WILL be of use to the game, and you should continue to do it. Because: (a) if they open the AI logic for us, they'll be needed .. OR (b) if they dont, Firaxis can see some logic that we think will make for better AI.