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.

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?"

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 faction 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.

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.

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.

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.

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 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

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)

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.)

.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 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.

------------------
CIV3 DEVELOPMENT LIST COORDINATOR

But no matter, I want to be able to customize the AI to not send Spys against Nation with Hunter Seeker Wonder (example from SMAC).

Being able to write and code my own assistants is less important to me than improving my computer controlled playmates or find modified AI components that I can plug into my game.

I've been thinking about a "Client/Server" model of game play. Namely, the whole game runs on a Server, with its own AI, open source or not, and everyone just connects to it to play. If it's a solo game, you run the server on your localhost, and connect to it as a single, local Client. If it's a multiplayer game, the host starts the server, and everyone, including the host, connects to the server to play. Your local civ3 process becomes nothing more than a graphical client. All the actions are resolved on the server.

What does this have anything to do with AI? Well, if they open up the network protocol, then we can write autonomous clients that connect to the server and play just like a human. You know where this came from if you've ever heard of "client side Quake bots".

Benefits:

* Unlike OSxAI where you are limited by how Firaxis decides to do, here the option is in your hands. You can use your favorite language (Java, C++, Assembly), run it on your favorite OS (Linux, Mac, Be), play with different algorithms (NN, GA), save your AI data however you want (flat file, relational database, OODB), as long as your client speaks the Civ3 protocol.

* A well written, well tuned, perhaps even self-learning client can provide unlimited challenge, whether you play solo or multiplayer.

* For Firaxis, good seperation between client and server code helps maintain modularity.

Issues:

* The guy who wrote the first client should win the Turing Award. In another word, for a game of such complexity, a fully autonomous, smart client may be too hard to write. But who knows? Maybe some one out there is clever enough to pull it off. After that, it'd be a lot easier to follow the example and make minor changes.

So what do you think?

I think your client model is a very good one. Only one person, or group, would have to do the hard parts of the client once, as I understand such things. Then, if they were willing to make it open source, or provide an associated interface (or scripting language for those who don't want to go to the code level) you'd be in business. If you're lucky Firaxis will do it, if not, someone will soon enough. Good Luck with it!

I whole-heartly support your idea. I think this kind of program structure easier to implement, than a traditional (one exe) with multiplayer possibility.

Trading / giving advances to allies.

Isn't it crazy how you can give your allies computers when they haven't even discovered electricity yet?

The AI should only allow you to trade / give advances which the receiving player could have discovered at that time on his own.

You should also have more choice as to what advances you can give your allies / friends / enemies(?).

Instead of them saying we want A or B where you wanted to give them C you should have the choice of what advances they are eligible to receive ( see above) and out of your benevolence give them one of your choice.

Incidently do any other Civ players reularly give their enemies advances just to spice up the game a bit? Maybe its just my weird sense of fun......

Many have pointed out that extremely simple changes such as massing invasion forces instead of small groups of invading units would make a huge difference.

will firaxis listen?
Regarding the question of whether firaxis will implement a client/server model, open source AI, etc:


I believe that Firaxis/BR (though isn't it Sid's turn to be the designer?) will take our suggestions seriously. I think (hope) we can expect some feedback from them after the first rev. hits BR's desk.


I will make sure that the AI list, at least, requests that BR lets us know whether we're completely out to lunch or not.

But the bottom line is this is what we want to see. JT is the only one who said 'no open' and that was a qualified no. I think it's safe to say that there's a consensus that there needs to be some degree of AI customization, and the more the better.

Not all human/AI players would be civ leaders. Some could be religious leaders or corporate heads.

The Religion-civs would start "missioning" inside civs, collecting tithes and building temples/churches. The leaders would allow them because they would keep people happy, reduce crime and make propaganda against enemies.

The Corporate-civs would use trade units and industries to earn money.

Anyway, i have some suggestions here about AI golden rules:

A GOOD CIV-AI should always pursue long-term strategies (like building terrain- and city-improvements) because it WANTS to – and short-term strategies (like building military-units) because it HAS to.
Time and time again i see AI-controlled factions in SMAC doing it the other way around, and that just dont work against most advanced players.

A GOOD CIV-AI should ONLY allow wars between AI-controlled Civ´s if the human player is behind (or equal to) it in terms of POWER and SCIENCE.
If the Human Player (= HP) speeds ahead in above areas, the AI should immediately terminate all “internal” quarrels, and instead concentrating on competing with HP. By that i DONT mean that alliances/treaties with HP should be terminated, or that everyone suddenly goes to war with you. Some of the more aggressive civ´s perhaps starts a military build-up of 15-20 units against you, before launching it, while the more peaceful ones concentrates on building terrain- and city-improvements, besides upgrading their garrison-units. The latter more peaceful approach is absolutely vital for any late-game competition that goes beyond minor “controllable” border-quarrels.

A GOOD CIV-AI NEVER let its military units wandering around aimlessly just showing off their presence (VERY common in both CIV-2 and SMAC). Any mid- and late-game AI-units (when most of the map is uncovered) should EITHER be garrisoned OR engaged in worthwhile battles. Important AI golden rule.
By “worthwhile” i mean launched military build-ups of at least (= absolute minimum) 5-10 units. Often more.

And I too think mini personalities (Intelligent Agents) are the best idea yet.

1. Come up with an optimum food-arrow-shield ratio, and have settlers/engineers try to achieve it. Often I've stumbled across an AI late in the game with size 7 cities, but lots of mined hills, some of which can't be used b/c of lack of food. Or the opposite situation, huge cities with lots of trade, but lacking the shields to build universities, stock exchanges, etc. And do you ever see AIs late in the game with RR'd forests? They must "irrigate" them all into plains or something. Sometimes appropriate, often not.

2. Attack in force. Number of units should be proportional to the size of the target city, or the game era. Also, when launching an assault, the AI should use a random number to divide its force. If the random number is .70, then 70% of its attack points will go in one wing of the assault, 30% in the other. Actually, to really be done right, there should be some way to keep this ratio, generally, 75% or more. Perhaps, use two random numbers, and take the one furthest from .50. Anyway, as it is now, once you see the AI attack coming, you can denude all of your other cities, b/c that's where the attack is coming, period. It would be much tougher fighting the AI if you had to worry about an attack coming somewhere else the next turn.

3. Limit the number of fortresses, and make sure they are manned. Some kind of logic loop like--after a city has an attacker and a defender, build another defender to go into a fortress. Once this defender is started, the settler/engineer assigned to the city builds on the following priority. 1st, must have roads. 2nd, prioritize this way--special resource hill, mountain, hill, river, forest, other special resource. Finally, no more than X fortress per city radius. Perhaps, City Size/5--as the city goes from 5 to 6, build a fortress, as it goes from 10 to 11, same. And, +1 fortress if the city has a WOW.

4. No more destroyer attacks!! It works once (if that), then you build the coastal fortress, and the AI is throwing away 42 or 36 shields (deity).

Also, in all my Civ2 games, it seemed obvious that the computer player would build militaries that were 90% defensive infantry and only a few offensive units. If you crushed his offensive army, the CP would become a non-threat for a long time. If you managed to spook the computer player, they built NOTHING but defensive units, stacking them as high as 12-15 in some cities. Considering how I used to overrun their defensives eventually with artillery and especially howitzers, this is a stupid strategy. Clue the computer in that they need a balanced military. 10% offensive just ain't gonna cut it. While I like winning, being attacked effectively every once in a while would be nice.

Teach the computer to leave troops in reserve for counterattacks. I can't believe how many times I destroyed the computer's defense when I bought out (or nuked, if I was in a bad mood) the nearest border city which happened to have almost all of their offensive units. Of course, it didn't really matter since I have never seen the Civ2 CP counterattack, even in the worse situations. I had a size 25 city defended by a damaged howitzer of all things with no chance of reinforcements, and they begged for a ceasefire...

AI ministers/governors
The ministers in CIV2 were an amusing interruption of the usual chores (micromanaging cities, micromanaging units, etc.). They didn't really give any useful information, they just complained if you were not doing what they thought should be done. Who is the ruler here?

It would be better if they were able to act upon directives from you (or each other, depending on how much power you grant them) as an extra (micromanagement-reducing) layer between you and the city/regional menus. After they have been given tasks or general directives, they present you with their suggested solution(s) which you may accept/modify/decline.

example:
You have given your diplomacy minister a directive to improve relations with your neighbour.
Diplomacy informs you that your neighbours insist on a special trade relation in which they will buy weapons for food.
The ministers of trade, production and military tries to dissuade you from that course of action, because; you will lose money, your production facilities are already engaged with other orders and it is dangerous to arm your neighbour.
You instruct diplomacy and trade to make the deal anyway, but to delay the weapon shipments. Production are ordered to commence the weapon production and turn them over to military who will use them to make an attack army that can crush this insolent neighbour.

The suggestion to use heuristic algorithms is a good one.

There are many suggested the use of a script to drive the AI module. The one fatal flaw of this is speed. A worse suggestion is to use JavaScript/Python/etc. They are even slower. Maybe for those of you with boxes that run on 4 Pentium Pros (or at least 2 PIIs) don't care, but there are still those out there with low end (e.g. Pentium 166) machines. Using any sort of script will force the game to a crawl on those computers.

Darkstar suggested using an API approch so he can write his own AI routines. That's a lot of effort that does preciously little. How many of Civ3 customers have such inclinations and how many have the actual skills? Photoshop is a program that allows external plug-ins. Consider how much more it costs.

The client/server model is also silly. If you can only run one game at a time, why bother with the effort? Just slap the whole bloody thing on a Wintel box and be done with it. If the server can run multiple games at a time, it will be a lot more complicated, both in terms of code and pricing struture. Would you have things like a 25-user Civ3 server? Would the servers be sold seperately from the clients? Again, there seems little to be gained.

I think what is needed is a look at the AI
algorithms. The actual implementation doesn't matter all that much.

The AI algorithms should be modelled after top Civ players. Not just Sid and Brian but people who spend hundreds of hours with the games and can kick the computer players blindfolded.

For good tactics to emulate, they should look at the best multiplayer tactics, where AI faults do not come into play.

Yep. And so are you.

Without true AI, we have a problem of a non-learning single player opponent engine. Which once you learn the tricks, is easy to defeat. That is the problem with locking it into the code, like it is now in CivII and SMAC. It can't be modified or customized at all after they are done with updates and patches. And only those with the source can do it whatsoever.

That brought up scripts and API and what not. As in other games which are still alive. The *players* of the game are building and updating the A-non-I modules or scripts.

Then we kicked around various ideas how to do the same for CivIII. Both your ideas are the worse possible suggestions... but will probably be the one implemented.

The problem is Civ and SMAC are programmed to react to what the developers found to be most effective. But the few months development time compared to the shelf life is a small amount of time to try and get the "Ultimate" A-non-I built, and the more experienced of us *will* walk all over it as a consequence on the day its released. And they won't release a patch 1 year to 2 years down the road to correct the "bad" or "inefficent" A-non-I. They will be busy developing new games.

I mentioned API as that would be open to at least a small fraction of the players, kept speed for those concerned, be relatively easy to implement from Firaxian side, and would enable people to further extend the system by building script parsers, if that is what the community wanted.

Making the A-non-I open and scriptable from design time would trade speed for maximizing the number of players being able to customize thier play.

And that is what we are after. Customization and updating of the A-non-I.

If you don't want to waste your time with positive suggestions here, then please find another topic where you can contribute positively. We all want to play the best possible Civ3.

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

I pointed out that the AIs have some pretty obvious triggers where they change their attitude toward you--1750, 1850, space techs, launch. So I thought this would be easy to program, just eliminate these triggers if you choose "realistic" diplomacy.