Skip to main content
GameDev.net gamedev.net
🔒 Locked

Adaptable AI module

Started by Zepee Oct 26, 2009 at 5:56 PM 20 replies 4.4k views
Original Post
Zepee
Zepee
Hey there! As my third year project I am supposed to do an AI engine, not a full one mind you, it just takes care of some parts of it. Anyway, the main aspect of the said engine, or module, is supposed to be that it is easy adaptable to any game... shall we say an AI mod that you can plug into various different existing games.. The problem is I have been doing some research and haven't been able to find anything related to trends in the structure of the AI in games. In order to make it easily adaptable (and by easy I mean, maybe you have a configuration file for the AI module, or you only have to create some Adapter classes between the original game and my AI module.. something in that line of thought) it would be quite usefull to know if there is some sort of trend in current AI engines, obviously I guess.. Seeing as I am not being very successfull in my research, can anyone point me somewhere where I could find any info regarding this? Or maybe you think knowing this sort of stuff about the game isn't necessary and you can point me to new approaches? Any info I could get on this matter would be much appreciated! P.S. If you think it there isn't actually an 'easy' way to plug such a module into different games, I consider that as a quite usefull input as well.. Probably better to change my thesis now than halfway through.. P.S.S. The module is supposed to introduce squad behaviour into games that don't have it, or override the existing (hoppefully mine would be better . Not sure if that insight helps at all, but might do...
Kylotan
Kylotan
I think AI is very domain-specific which is why you won't find anything non-trivial that is 'easy adaptable to any game'. And even if there was a fairly standard way of handling unit AI, there's no standard way of exposing that to the outside world for modification. So I don't think you'll find any of the trends you're looking for.

Possibly the most reasonable approach is to find a game with a good modding interface and a multiplayer or team-based mode, and code for that, while trying to make your logic as independent of that game's particular interface as possible.
SimonHx
SimonHx
Forgive my candour but: No chance!
You could easily spend a year just developing effective team AI for 1 game, never mind a system that would work across several games (even if they used the same engine the objectives/terrain/weapons/abilities would be too varied for a catch-all solution).
The very fact that you are asking this question in such vague terms is a bad sign!
Nice idea, but... Next!

Last year I spent a few weeks studying 'dynamic scripting' or AI scripts that change to reflect changing events in the game - ie if the barn catches fire the farmer's script changes from the 'tend farm' script to the 'put out fire' script.
If a soldier notices that more than half of his unit is dead his script changes from 'attack' to 'retreat' &c &c
It can be much more efficient if NPC scripts are as relevant as possible to the state of the game around them, so you can have more (or more complex) NPCs. Perhaps you could look at something along those lines?
alvaro
alvaro
The naysayers are probably right, but I have one constructive idea of dubious value to contribute. Hey, it's better than nothing. ;)

Many games these days seem to use behavior trees to describe what the agents do. My understanding is that they are some very limited version of scripting, but they have the great advantage that it is easy for game designers to edit them without creating messes. This makes sense: If you give them Perl, which is very powerful, they can turn the script into an unmanageable mess in about a thousand different ways. With BTs they have a much more limited way to express behavior, so they don't mess it up. Besides, BTs have graphical representations that designers might find less intimidating than traditional code.

In order to use BTs in a game you need to define actions that the agents can perform and conditions that the agents can check, which have to hook to the right place in the rest of the game. But once those things have been done, the driver that takes the BT and follows it and the BT editor are things that could be reused in many games, at least in principle.

Perhaps Alex can comment on the feasibility of something like this...
DvDmanDT
DvDmanDT
Hasn't this already been done? Not the coop part, but multigame/multiengine bot?

I seem to recall 'independent', 'bot' and 'framework' as keywords, but googling it turns up mostly IRC bots. The only game releated project I could find was omni-bot, which might be it.

Quote:
Omni-bot is an artificial intelligence(AI) controlled opponent for first person shooter games. Unlike many bots that are written for specific games, Omni-bot was designed from the beginning to exist mostly as a generic framework with which support for many different games can be made, and most of the functionality can be shared among them.


I guess it's not exactly what you were thinking about, but perhaps worth looking into?
IADaveMark
IADaveMark
If this were feasible, we would see more AI middleware packages that go beyond simple pathfinding and state machines. The problem with AI middleware as a concept is that you must often design your world around the middleware product and its hooks. Because game worlds, the data they hold, and the inputs they need, vary wildly from one to the next, the idea of having a unified middleware product that addresses them all is a stretch. Pathfinding, at least, has the common model of nav meshes and waypoint graphs. Behavior? Not so much...
Dave Mark - President and Lead Designer of Intrinsic Algorithm LLC
Professional consultant on game AI, mathematical modeling, simulation modeling
Co-founder and 10 year advisor of the GDC AI Summit<
snak
snak
What kind of games are you supposed to support? There's an engine called 'zillions of games' that can handle zillions (where zillions = a few hundred) of traditional abstract-ish board games such as tic-tac-toe, reversi, hnefatafl, etc.

Another plausible interpretation is that you need to write a basic agent framework (the sense/act cycle), but that the implementation of the act() method is deferred to each game. It would be plausible but not easy to provide a normalized packet of information to provide to the agent at each tick (nearby geometry/movement options, other nearby agents, game state such as health and ammo). This is where the adapter comes in - figuring out how to represent each game's world in the common format, and how to interpret the output of the act() method in that particular game.
Daerax
Daerax
Quote:
Original post by InnocuousFox
If this were feasible, we would see more AI middleware packages that go beyond simple pathfinding and state machines. The problem with AI middleware as a concept is that you must often design your world around the middleware product and its hooks. Because game worlds, the data they hold, and the inputs they need, vary wildly from one to the next, the idea of having a unified middleware product that addresses them all is a stretch. Pathfinding, at least, has the common model of nav meshes and waypoint graphs. Behavior? Not so much...


Hmm I dont know. I do not think that it is impossible. A certain amount of ignorance is required to continue my argument but I do not consider my position indefensible.

I am certain that a similar thing as you say for behaviour was stated for graphics engine and in particular 3d graphics accelerators. But these days people all use the same format in their graphics computation, instructions and structures by convention.

While hardcoding specifics to do with a behavourial engine type thing would be unproductive I do not see why for a start, a low level algorithm and structures library and tools for said would fail. And then as is the case with game engines, focusing as necessary on different genres. I think pathfinding has tools only because it has been such a big deal in Game AI for a really long time. Before people would worry about pathfinding and were happy to hand build or script base a Finite state machine. but as more and more complex approaches from the ML community become more common I think such a middleware will become more prevalent.

Do correct any misconceptions as I am interested in learning.
Palidine
Palidine
Your analogy to graphics ignores an important point: AI controls and sends inputs to a lot of other game systems whereas graphics is simply an output. This is a big difference.

So certainly there are successful AI Middleware packages: Kynapse, Euphoria. Various games use them (all FPSish high-fidelity games), but as pointed out, they all had to be put in place before the game was constructed. You can't just drop them in to a finished game because of the input problem.

AI is intimately connected with game design which is extremely game specific. Dealing with the intricacies of a specific game's mechanics is work intensive and non-generalizable: shooting guns is not compatible with a game where you weild swords, hand-to-hand combat is not compatible for a sniper game, triggers in different engines are different, different engines have totally different scripting systems to control the game design and the AI, different engines have radically different animation interfaces which the AI controls.

So to "plug middleware in" to an existing game you have to hook it up to all your specific game mechanics and features. That means authoring custom behaviors and interfaces to your derived behaviors or whatever the leaf-end extensible feature of your middleware is. This isn't a hot-swappable feature. And it's something that often takes upwards of several months for your AI team to put in place. Yes, your middleware can work in various games but it'll do so with a common basic architecture that the devs have to customize towards their unique features.

Additionally, you're not going to create middleware that can successfully handle very disperate genres: RTS and FPS games, for instance. The numbers of units in an RTS game require a fundamentally different basic AI architecture than you'd want for a high fidelity FPS game.

But yeah, given that you abandon hope of pluggable middleware that covers everything there are certainly ways that you can be successful.

-me
Stani R
Stani R
To paraphrase Ian Millington, there are three types of game AI: hacks, heuristics, and algorithms. I don't think we can do much about hacks and heuristics, but many algorithms should be codifiable in a project-agnostic manner. Ian's book is full of such generic algorithms and the source code is freely available at ai4g.com, so you should check it out.

Sure, games do differ a lot, but we not only conform to graphics but even to physics APIs these days, and both graphics and physics can differ quite a bit between games - it just means that the AI engine must support a wide variety of algorithms. You don't actually have to use them all.
Daerax
Daerax
Quote:
Original post by Palidine
Your analogy to graphics ignores an important point: AI controls and sends inputs to a lot of other game systems whereas graphics is simply an output. This is a big difference.


I dont know. I see graphics as both sending output and recieving input say from some animation controller thing.

Quote:
AI is intimately connected with game design which is extremely game specific. Dealing with the intricacies of a specific game's mechanics is work intensive and non-generalizable: shooting guns is not compatible with a game where you weild swords, hand-to-hand combat is not compatible for a sniper game, triggers in different engines are different, different engines have totally different scripting systems to control the game design and the AI, different engines have radically different animation interfaces which the AI controls.


Yes. And as I said hard coding specific things to do with game mechanices and game rules is counter productive. But that doesnt mean a lower level solution of data structures, common algorithms and a common format wont be useful to lay a base.

Quote:
So to "plug middleware in" to an existing game you have to hook it up to all your specific game mechanics and features. That means authoring custom behaviors and interfaces to your derived behaviors or whatever the leaf-end extensible feature of your middleware is. This isn't a hot-swappable feature. And it's something that often takes upwards of several months for your AI team to put in place. Yes, your middleware can work in various games but it'll do so with a common basic architecture that the devs have to customize towards their unique features.


I do not think that graphics engines either are plug and play any time. People spend time thinking which graphics or game engine to use and indeed some come to the conclusion that using a certain game engine might involve more work to figure out or get to work as wished and roll their own - wrong or not.

Quote:
Additionally, you're not going to create middleware that can successfully handle very disperate genres: RTS and FPS games, for instance. The numbers of units in an RTS game require a fundamentally different basic AI architecture than you'd want for a high fidelity FPS game.


Yes but if you have a base of algorithms as I mentioned above then you can more easily implement genre specifics atop this. Fork into focuses and then perhaps have all of these in a larger package to be used as required. Those requiring a lower level would simply use the bare library of algorithms. Much as is the case for graphics libraries.
Palidine
Palidine
Daerax, re-read my posts, we are saying the same thing with respect to AI Middleware. I'm just arguing against an all encompassing module that is plug-and-play which is what the OP described:

Quote:
Original post by Zepee
P.S. If you think it there isn't actually an 'easy' way to plug such a module into different games, I consider that as a quite usefull input as well.. Probably better to change my thesis now than halfway through..


-me
Stani R
Stani R
Rereading the original post, yes, it would be entirely impractical to plug an AI middleware into any already existing game - you would have to butcher each game's existing AI and spend more than half your time writing interfacing code, and even then I doubt it would make any sense or even work for half the game. But you can still write an AI middleware as your thesis if it's meant as a toolkit for future games to base their AI on. The challenge will be innovation - if you just code down well-understood techniques (like steering behaviors) then you won't really be creating any new knowledge (then it depends on whether simple knowledge synthesis is acceptable as your thesis topic - generally I believe that's not really the case for anything past a semester paper).
Kylotan
Kylotan
Quote:
Original post by Daerax
Hmm I dont know. I do not think that it is impossible. A certain amount of ignorance is required to continue my argument but I do not consider my position indefensible.

I am certain that a similar thing as you say for behaviour was stated for graphics engine and in particular 3d graphics accelerators. But these days people all use the same format in their graphics computation, instructions and structures by convention.

One massive difference is that long before 3D accelerators became established for consumer hardware and software, the algorithms they used were well-proven in software. Pretty much everything was based on either projecting polygons or tracing rays. So what we see appearing in practice tends to be what academia was able to present 10 or 20 years ago, albeit not always running in real time. the industry just took the already-solved problem and built it into hardware to make it practical for real world use.

But when you look at AI, the problems are still not solved. There are a lot of good papers but there is nothing resembling a 'standard' way to proceed, nor two standards, or any small number. There are just a lot of individual ideas for individual problem domains. And without any sort of consensus of direction - and perhaps such a consensus is impossible - there's no critical mass towards standard implementation techniques.

It doesn't help that whereas graphics is quite straightforward in terms of outcome - getting intensity values into a 2D array, primarily - 'AI' means different things to different people. On GameDev.net we tend to use it to mean the development of intelligent agents that appear within a game, as well as the use of learning algorithms within games more generally. But a lot of academic AI is geared towards the latter without any interest in being able to simulate interesting or believable characters. This further slows adoption of standard academic techniques in the practical field, because game developers have to assess a method's suitability and adapt it to their own world representation.

I think that before we come much closer to usable standards within game AI, the field will have to be broken down into smaller areas that can be more uniformly addressed and widely applied. I don't think it could never happen, just that we're nowhere near that point yet.
Daerax
Daerax
Quote:
Original post by Kylotan
One massive difference is that long before 3D accelerators became established for consumer hardware and software, the algorithms they used were well-proven in software. Pretty much everything was based on either projecting polygons or tracing rays. So what we see appearing in practice tends to be what academia was able to present 10 or 20 years ago, albeit not always running in real time. the industry just took the already-solved problem and built it into hardware to make it practical for real world use.


Hmm I dont agree with that. I think your trivializing the field. I do not think graphics is 'solved'. And most of the Machine Learning and AI stuff is 20, 30 + years old. I think thats the standard age it takes a new CS concept to mature.

Quote:
But when you look at AI, the problems are still not solved. There are a lot of good papers but there is nothing resembling a 'standard' way to proceed, nor two standards, or any small number. There are just a lot of individual ideas for individual problem domains. And without any sort of consensus of direction - and perhaps such a consensus is impossible - there's no critical mass towards standard implementation techniques.

Specific to games - that is because the academics are so seperate from the industry. There is no synergy and everyone reinvents their wheel and the field is stalled and splintered. It also doesnt help that unlike in graphics there is less prestige in working on things directly applicable to games. However that is no excuse, a lot of the stuff from robotics and machine learning in general coincide. No need for game AI to be spoon fed.

In a way game AI has always seemed to be an afterthought. Alot of game ai is laughable, though it need not be so. Generally just pathfinding and some scripted FSM. The lack of a standard is a social problem not a technical one.

Quote:
It doesn't help that whereas graphics is quite straightforward in terms of outcome - getting intensity values into a 2D array, primarily - 'AI' means different things to different people. On GameDev.net we tend to use it to mean the development of intelligent agents that appear within a game, as well as the use of learning algorithms within games more generally. But a lot of academic AI is geared towards the latter without any interest in being able to simulate interesting or believable characters. This further slows adoption of standard academic techniques in the practical field, because game developers have to assess a method's suitability and adapt it to their own world representation.


Graphics is more than filling a 2D array. thats comparing a weather balloon eyed view to a mole eyed view. In graphics there is multiple ways to do things like shadows, lighting, water, smoke, fire, sky, shading etc. Then also there might be procedural animation and generation?

AI in games is basically search, planning, constraint satisfaction and classification. There are plenty of standard techniques and approaches that can be easily adapted from research. Reinforcement Learning stuff seems very applicable. Granted they are not specific to games and are unlikely to be tailor made to fit due to the problem of prestige so there is a gap to be filled. Perhaps a Middleware company could be better placed than a games one to release papers on their techniques so a standard body of techniques could be built instead of every company reinventing their wheel and forgetting it once implemented. Creating an illusion of a difficulty in producing a standard.

Graphics and physics publish alot of papers. However there is comparatively very little for AI -formal (papers) or informal (tutorials) - which is a very closed mouth community, game AI I mean not machine learning stuff.
KulSeran
KulSeran
I think the biggest issue with making AI middle ware is that techniques to solve a problem only work if the problem space and solution space are well defined. The issue is that neither is well defined for most games. There are lots of papers about machine learning, and behavior planning, and whatnot, but it IS all just academia. Game AI is about fun, and for some subset of games (FPS/RTS) having AI that "outsmarts" your planning ability is good. For other games having AI that is really stupid, but does something interesting is better (bullet hell games).

One complaint I've heard a lot is that "complex" AI systems are not as fun/good as simple AI systems. The theory being that the more complex the AI gets, the less control there is over what it does. The F.E.A.R. Ai system limited all the AI to a common world state to make decision on for instance. Combine that with the fact that adding a new action/plan to a GOAL system like F.E.A.R. means double checking every single interaction and making sure you don't get state jitter, unreachable world state, un-exitable world states, or other edge cases that come from how all the actions interact. Having simple if/else AI on the other hand makes for entities that are easier to control, predict, and order around. While their state machines are less flexable, they make programing something like a bullet hell, arcade gallery, and platforming challenges easier. They also tend to make for more entertaining boss fights, since the explicit control gives you a better feel than the boss deciding things "adaptively".
alexjc
alexjc
Since alvaro summoned me.

I think a reusable BT library is possible, if you consider it on the same level as say, Lua. However, if you want to go beyond that you'd have to start providing pre-build leaf nodes (actions/conditions) that make certain assumptions from your game code. Also, having pre-built composite nodes (e.g. complex behaviors that reuse the leaves) is also of value if you assume a specific domain.

BTs would help make this kind of stuff possible. And as Dave said, it's not yet entirely suited to middleware providers (too risky, specialized) so as a research project it's ideal.

Join us in Vienna for the nucl.ai Conference 2015, on July 20-22... Don't miss it!
Kylotan
Kylotan
Quote:
Original post by Daerax
Quote:
Original post by Kylotan
One massive difference is that long before 3D accelerators became established for consumer hardware and software, the algorithms they used were well-proven in software. Pretty much everything was based on either projecting polygons or tracing rays. So what we see appearing in practice tends to be what academia was able to present 10 or 20 years ago, albeit not always running in real time. the industry just took the already-solved problem and built it into hardware to make it practical for real world use.


Hmm I dont agree with that. I think your trivializing the field. I do not think graphics is 'solved'.

I didn't mean that graphics itself was solved. I meant that individual problems have well-defined approaches. The future can improve on them but that doesn't make the existing approaches insufficient. eg. You could implement flat shading, then gouraud, then phong, and each would be correct as an approximation, and each better than the last. This sort of progression is possible when you have a largely fixed input (convex flat polygons with 3D coordinates) and output (rectangular 2D matrix of intensity values) representations. You have a source and a destination and people find better routes. But there are few areas in AI where you can do this.

Quote:
And most of the Machine Learning and AI stuff is 20, 30 + years old. I think thats the standard age it takes a new CS concept to mature.

The age is irrelevant, because despite being around for 20 years, these techniques have not settled down into well-understood and widely applicable algorithms, but have remained applicable to only small subject areas where the inputs are well-researched, and often fail to perform well on even similar data.

The reason why we get everybody coming in here and asking about neural networks, genetic algorithms, and fuzzy logic, are because they are perhaps the best understood and most mature algorithms for solving generic problems. Yet people in the game development field know that they are rarely well-suited to the problems we have to face. That's not to say there would be no merit in having hardware accelerated NNs or GAs but they are nowhere near as universally applicable to game technology as hardware rasterised triangles were in the mid 90s.

Quote:
Specific to games - that is because the academics are so seperate from the industry.

I don't think this is true at all. If you read the AI Wisdom books or go to conferences you will see a healthy mixture of both types. The problem is more inherent to the technology - AI is 'soft computing' and that means you're an extra abstraction away from 'hard computing' problems such as graphics, audio, concurrency, etc. You're no longer writing algorithms to solve problems, but writing algorithms to solve a type of problem. You still have another problem left over, which is that of working out what type of problem you actually have. Sometimes it's trivial - discrete states and transitions usually means a state-based search such as A* is what you want. Sometimes it's not - modelling realistic human behaviour, even under severely restricted circumstances such as combat, has no clearly preferable method or representation to use.

And again, it's not helped because of the dual meaning of AI - much AI research has absolutely no interest in creating human-like behaviour. That's not through lack of cooperation with games but with the two groups having very different aims.

Quote:
In a way game AI has always seemed to be an afterthought. Alot of game ai is laughable, though it need not be so. Generally just pathfinding and some scripted FSM. The lack of a standard is a social problem not a technical one.

The reason you always see pathfinding and scripted FSM and not necessarily much else is for the reasons I gave - these are 2 of the very rare situations where the problem domain is well understood. And where it is well understood, developers do use the standard approaches, just like they do for graphics.

Quote:
Graphics is more than filling a 2D array. thats comparing a weather balloon eyed view to a mole eyed view. In graphics there is multiple ways to do things like shadows, lighting, water, smoke, fire, sky, shading etc. Then also there might be procedural animation and generation?

You're missing my point. Of course graphics is more than filling a 2D array but that is the goal state. Everything you do works backwards from that goal state, and is made possible because you have a very well understood output representation which can be objectively measured. Believable AI not only has no well understood output representations but currently no good way of even measuring the quality of said output. (Consider the Turing Test, a blunt tool if ever there was one.)

Quote:
AI in games is basically search, planning, constraint satisfaction and classification. There are plenty of standard techniques and approaches that can be easily adapted from research.

Again, this is the problem with soft computing. These are algorithms to solve soft computing problems. But that is only the first half of the issue. The second half is finding a suitable representation for your particular problem. That part is not a solved problem. A* is only commonly used for pathfinding because we have worked out how to adequately represent a 2D or 3D world in graph format. But we don't have adequate and universal methods for representing human needs as a constraint satisfaction problem, or emotions as fuzzy logic variables, or battlefield strategy using pattern recognition. People have ideas, and some of these have worked well in specific areas and with specific representations. But that's not directly transferable in the same way that a graphics routine is directly transferable to any system that uses projected and rasterised triangles.

Quote:
Perhaps a Middleware company could be better placed than a games one to release papers on their techniques so a standard body of techniques could be built instead of every company reinventing their wheel and forgetting it once implemented. Creating an illusion of a difficulty in producing a standard.

Graphics and physics publish alot of papers. However there is comparatively very little for AI -formal (papers) or informal (tutorials) - which is a very closed mouth community, game AI I mean not machine learning stuff.

I don't know where you're getting the idea that everybody forgets what they do, and that nothing is published. There are something like 300 articles in the AI Wisdom book series of techniques used in the field and in academia. And there are numerous conferences that cover AI in games, not exclusively, but often significantly. There is a lot of published literature and I think it's just very wrong to suggest there isn't or that the community is holding back here. The issue is that a big problem still remains of adjusting well-known techniques to poorly-understood representations, and that is still some way from being solved.
alvaro
alvaro
Quote:
Original post by alexjc
Since alvaro summoned me.

Oh... I can feel the power... :)
Daerax
Daerax
Quote:
Original post by Kylotan
I didn't mean that graphics itself was solved. I meant that individual problems have well-defined approaches. The future can improve on them but that doesn't make the existing approaches insufficient. eg. You could implement flat shading, then gouraud, then phong, and each would be correct as an approximation, and each better than the last. This sort of progression is possible when you have a largely fixed input (convex flat polygons with 3D coordinates) and output (rectangular 2D matrix of intensity values) representations. You have a source and a destination and people find better routes. But there are few areas in AI where you can do this.

Maybe, I am too ignorant to know the truth of this. But I fear you may be doing the age old viewing of ones speciality being more difficult than others. I am sure they have their share of problems and may not think their sources and destinations so clearly defined. Even so there are some clear choices in AI. Especially to do with the area of supervised learning.

Quote:
Quote:
And most of the Machine Learning and AI stuff is 20, 30 + years old. I think thats the standard age it takes a new CS concept to mature.

The age is irrelevant, because despite being around for 20 years, these techniques have not settled down into well-understood and widely applicable algorithms, but have remained applicable to only small subject areas where the inputs are well-researched, and often fail to perform well on even similar data.

The reason why we get everybody coming in here and asking about neural networks, genetic algorithms, and fuzzy logic, are because they are perhaps the best understood and most mature algorithms for solving generic problems. Yet people in the game development field know that they are rarely well-suited to the problems we have to face.


I only mentioned years because you did. I think there are better understood areas in classification and optimization than neural networks and genetic algorithms which are by nature obtuse. Probabilistic Graphical Models such as bayes nets and hidden markov models are pretty mature and can allow for some interesting reasoning. Monte Carlo and markov chains may have a use for some types of strategy games. Certain games may benefit from Reinforcement learning, tabu search, simulated annaeling in place of genetic algorithms being either more robust (RL) or simpler and clearer. kNN, Decision Trees are also very well understood and may be used in place of a Neural Network. There is none of that specific to any game genre but having such a library well tested and tooled specific to games increases the available tools and range of an AI programmer which is never bad.

Quote:

And again, it's not helped because of the dual meaning of AI - much AI research has absolutely no interest in creating human-like behaviour. That's not through lack of cooperation with games but with the two groups having very different aims.


I did not mean lack of communication so much as that research is separate from being game specific, as you say. Partly because there seems to be less prestige attached to working in 'game ai', I feel. But that does not mean that the wider available research is not applicable. Just game companies probably dont have time to document their success stories in papers. Hence throttling the field with less sharing.

There is no point trying to simulate human behaviour. that is too big. Better is to get an opponent that seems smart in a way that suits the game and makes it fun, dynamic , challenging but beatable. By having more ready methods researched the field will have more possible paths in implementing this per game. Eventually per genre standards may even evolve.

Quote:

You're missing my point. Of course graphics is more than filling a 2D array but that is the goal state. Everything you do works backwards from that goal state, and is made possible because you have a very well understood output representation which can be objectively measured. Believable AI not only has no well understood output representations but currently no good way of even measuring the quality of said output. (Consider the Turing Test, a blunt tool if ever there was one.)

I think in both the measurement is soft. Is my agent smart, believable and dynamic? Is my water reflecting, refracting close enough to real life? Does my forest scatter trees or clouds drift like in real life?
Quote:

I don't know where you're getting the idea that everybody forgets what they do, and that nothing is published. There are something like 300 articles in the AI Wisdom book series of techniques used in the field and in academia. And there are numerous conferences that cover AI in games, not exclusively, but often significantly. There is a lot of published literature and I think it's just very wrong to suggest there isn't or that the community is holding back here. The issue is that a big problem still remains of adjusting well-known techniques to poorly-understood representations, and that is still some way from being solved.


I stated comparatively little. I got the first AI wisdom book and enjoyed the breadth of topics but unlike say graphics and physics the channels are much fewer. On topic papers are less than say graphics where the techniques are usually pretty straight forward applicable. This forum doesnt even have a FAQ. This is no fault to game AI but a social problem.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.