First, are there any AI protoyping tools available online. I was thinking of something along the lines of GameDev Arena (if anyone remembers that) where you can program your AI implementations, then attach your AI script to an agent/bot and then a 2D simulator will run your scripts and show you the effects of your AI routines. If there're any that come to mind then please list them. I've so far found GD Arena made by the creators of this site, and another one called J-RoboCode made by some guy in IBM. Second question is about AI game development in the industry. Is it true that there is efficiency problems and an AI programmer usually has to wait til at-least some basic engine software is ready before s/he can start testing out his/her AI implementations? And that this wait can be anywhere between a month and even a year? Thanks.

Well, yes, you can't test AI until you have at least some details of the engine it is running on (i.e. what data/methods are available to the AI code, what core language and what scripting language you are using, how much memory/cpu time is available for AI), and probably not until there is an alpha of the engine itself.

If the AI coder is lucky, the studio is merely upgrading a previous engine for this game, and they can begin prototyping on the old engine, but I would think this situation is rare.

If the studio is licensing an engine (such as Doom or HalfLife) which already exists, the AI guys might be abvle to prototype directly, but likely they have to wait for basic engine modification to be finished, and for the basic tools to be created.

As a follow-up on that question, I'm curious about something similar:

Do you think it's feasible, or even possible, to create some sort of AI-engine within which an AI-coder can create his/her code which can then be plugged into any game engine? Just like how there's physics engines.

I think this sounds like the AI would have to be run in a seperate thread, much like how the physics engines work. This would also require the new-generation game engines to be built to accept input from that AI-engine. Just like how you build games dependant on physics to accept input from a certain physics engine.

If possible, I think the advantages would be:
1. Possible for the AI coder to begin development of AI even before the game engine is completed.
2. Sharing code with other developers becomes easier, as well as re-using code from your old projects, without any (much) porting.
3. Finally there's some sort of standard to follow even for AI coders.
4. Possibly, advanced AI creation would be made easier by the emergence of AI development tools.

What do you think? Just a silly idea? No real benefits?

- All behold; DirectAI 3.0!! Kneel! =)

Quote: Original post by NQ
Do you think it's feasible, or even possible, to create some sort of AI-engine within which an AI-coder can create his/her code which can then be plugged into any game engine? Just like how there's physics engines.
- All behold; DirectAI 3.0!! Kneel! =)

It is a nice idea, and deserves some thought, but the basic problem is the same as any other AI solution:
There is no generic solution to AI. While almost any game can use a physics engine, and all physics engines model the same types of behaviour, almost every game (and certainly every genre) uses a different approach to AI.

For instance, RTS (like StarCraft, Age of Empires, etc.) tend to use path finding AI (A* perhaps), whereas a flight sim/space sim uses a navigational AI (possibly swarmed as well), and there is no real way to abstract those two.

Quote: Original post by NQ
As a follow-up on that question, I'm curious about something similar:

Do you think it's feasible, or even possible, to create some sort of AI-engine within which an AI-coder can create his/her code which can then be plugged into any game engine? Just like how there's physics engines.

Im doing just that right now on my free-time. Im currently testing it with the Torque engine. All game logic is in the Torque demo, all AI behavior logic is in a script file, and the AI engine is in a separate DLL.

The AI engine is basically for Agent decision making. The bulk of the work in AI is not in the AI engine however, it is in defining the behaviors correctly. Im just hoping that with a solid AI engine, developpers will be able to focus on the important part.

When making a game, isn't the most tedious part of the AI implementation the "tweaking" phase? Cause if it is, then wouldn't a protyping tool come in really handy? If the interface between an artificial agent and the engine can be standardized, then a simulator of a sorts can load in scripts and simulate the behavior.

I'm thinking a small 2d grid where you have 3 types of tiles (wall, window, empty). And then attach a script to a number of bots and let the simulator take over from there to see the results. The bots would have different functionality such as health, ammo, power, etc... Bots would be able to communicate (text boxes). Infact, I'm sure it would even be possible to generically load in a bots capabilities from a bot configuration file or something.

After you get satisfactory results you can just copy paste the ai scripts into your game and attach them to characters/enemies/whatever. I can see how they'd require a few changes, but the basic algorithms and structure of the scripts would remain the same right?

Someone must've thought of something like this by now...

You don't need to prototype the AI in the actual engine but you do need to know the design of the game for which you are making the AI. You can make a prototype of the game, and prototype you AI in that environment. If you really want to you can architect it so that you can just plug it into you main game with a little bridge class or something.

It's actually a really nice way to develop the AI especially if the final game engine is under heavy development. Having a nice prototype environment also really helps design get moving on tweaking the mechanics of the game while the graphics dudes are getting all their 1337 effects working and such.

You can basically use whatever for a prototyping environment. At work I use an openGL hobby engine i developed years ago as my prototyping environment. Mainly because I fully understand it and can hack stuff out quickly. Other people use flash or java or whatever they are good at doing. The idea is to try out AI design ideas, not necessarily to develop final AI code. Generally when we move over to the actual engine we scrap all the prototype code and come up with cleaner algorithms to implement the design the prototype solidified.

Either way you will always end up with a really long tweaking process at the end of the project. No matter how "solid" your prototype ideas are there are always some major mechanics added/removed to/from the game in the final months; it's just how the process goes.

-me

I guess I must be lucky, cause in the past ~5 years, I've always worked with "mature" engines that were ready to use as soon as I got on the project.

I believe most teams will licence known engines (think unreal) and you can get working as soon as your build is ready.

Not that I believe that a prototyping tool would be useless, but most of the gameplay mechanics are too much game logic dependant / data dependent, and it would be a waste of time to work on a separate tool to emulate what you'll have to do anyway with the real engine.

A team that puts an AI programmer to work when there's not even a renderer (unless the said programmer is not working on gameplay, like the lucky ones who end up writing nav mesh generation / pathfinding, etc...) has a major problem.

And by the way, even if having a prototype first _can_ and probably _will_ help your designers, be warned that these kind of persons ALWAYS change their minds :P

Just my two cents hehe

All the input data has to be pretty much the same that comes from the games mechanics (map data format, events, available actions, object attributes, etc...).

You would hope that the game mechanics get nailed down pretty early(at least in data interaction spec form). The AI has to be adjusted when significant changes are made to data value balances (and of course if the structure of the data itself changes or new attributes). The general behavior patterns still can be set up (and test scenarios planned/run) and provisions made for tweakings of the game mechanics (which may happen up to the momement it gets released -- and into the patch cycle).

Having to write an engine emulator (game mechanics especially) would not be fun and there is usually enough work to do programming the AI itself. A symbolic graphics mechanism might not be too hard (and might actually be more useful/ present situational info easier than the full 3D presentation).

I'd say the idea of an AI engine has been thrown around quite a bit around AI programmers. Personally, I've thought about it too. But when it all boils down, the truth is, there is no fixed solution to an AI problem. Well, some do, like pathfinding. Some don't, like most everything else. AI isn't like physics that is completely deterministic. In some ways it is fairly static, in others, it is highly dynamic. And then there's the advance stuff, which is a totally different story.

Take for example, a GA. If you're a graduate student studying evolutionary computation, you would have at least coded up a GA 5 times and maybe in two different programming languages. The truth is, its never the same with different problems. There are general parameter setting guidelines, but there's always a hell of alot of tweaking going on. I'd say on a usual GA implementation, 30% of the time is spent coding, 10% spent debugging, and 60% spent tweaking.

I've coded up the particle swarm optimizer like more than 10 times to date and it somehow always takes me at least 3 tries to get the code running properly and then another 10 tries or so to make it get a good feasible solution.

I guess its kind of like every AI programmer's dream and nightmare for a perfect AI engine. It'd mean a easier time for us, but then it also means we might lose our job importance. But then, like we learn in EC, "there's no free lunch." Putting two good things together probably won't get you something better.