Game AI

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Game AI

      This is a really technical question about how to setup the game AI architecture...

      Right now I have a GameAIProcess which actually just generates a DoGameAI event, which is then sent to the GameObjectManager via the EventManager...

      Then once the GameObjectManager recieves a DoGameAI event, it loops through all the GameObjects and actually does something.

      Now I imagine an NPC could just have two AI states and it would probably be ok from a gameplay standpoint: an attacking algorithm, and an idle routine.

      I'll worry about the attacking algorithm later, right now I'm wondering, how to get an NPC to go through a sequence or routine of events, like walk 5 tiles east, look north, look south, walk 5 tiles west, look north, look south, then repeat.

      It seems like this could itself be a process... since the book GameCodeComplete already discusses how to link processes together with wait processes between them and each one would be sending out a game event.

      Soooo... would it be better to have a separate process for each NPC or to continue the way I'm going now with one DoAIProcess ?

      But if each NPC had its own AI process I imagine it would look something like..
      1. pick an AI state/routine based on an evaluation of the current situation
      2. if that routine is already in execution then execute the next step in it, if not, execute the first step of the appropriate routine

      Right now none of my processes directly affect any of my game systems, they just generate messages, however an AI process for a particular NPC would probably need to contain a reference to that NPC so it could actually do things right then and there.

      This is already seeming like a lot of work and I am leaning towards just have one AIProcess... But of course, if I do that I will need to create somekindof AIRoutine class for defining the steps in the routine, and index to the current point, etc etc

      Who knows... is one way any better than the other?

      The post was edited 1 time, last by JamesFord ().

    • Most likely a solution to your problem would be through the use of Finite State Machines. While I'm short on time right now, a great resource for game AI programming in general can be found in Mat Bucklands Programming Game AI by Example. It is, in my opinion, an absolutely excellent reference and it uses concepts that you should be familiar with, such as an Event System. I suggest that you pick up a copy on Amazon or borrow it from someone.

      The book can be found here:
      amazon.com/Programming-Game-Ex…oks&qid=1176960601&sr=8-1
      Feel you safe and secure in the protection of your pants . . . but one day, one day there shall be a No Pants Day and that shall be the harbinger of your undoing . . .

    • You are definitely entering a huge area that has a lot of possible answers.

      Another person to look up is Jeff Orkin, the AI programmer of F.E.A.R.:
      web.media.mit.edu/~jorkin/

      Depending on the type of game you are creating, an FSM may be sufficient, but if the game is meant to simulate complex human interactions, then an FSM might only be good for low level animation states, and you may need a more complex system for action determination that goes beyond a set of finite states.

      This is a great Gamasutra article on Halo's AI:
      gamasutra.com/gdc2005/features/20050311/isla_01.shtml

      To directly answer your question, a separate process could be good because maybe you might want to skip processing an AI once it becomes irrelevant (like too far away to matter), even though the AI still exists in RAM. You will still need some sort of central AI manager to intelligently determine which AI processes should tick and which shouldn't though.

      Here are some other factors to consider which you may or may not already be doing:

      1) Separate Thinking from Action: Most AI code in popular games separate the thinking portion of the AI from the "what the body is currently doing" portion. The idea is that thinking can be a very expensive process that takes up a lot of CPU cycles, so that process should be iterable and spread out over various cycles and perhaps not done on every tick. For instance, calculating the A* for an AI can actually be done by holding onto persistent data between cycles instead of putting all of that inside a single function with a for loop that could take huge chunk of your tick depending on the complexity of your nav grid. The true litmus test of keeping the separation clean would to be able to trivially plug player controls to an AI body without making any code changes to the AI body code.

      2) Use the event system sparingly. If you can find a way to arrrange code such that you don't need to broadcast an event and force every AI in the world to check the ID to see if it was for them or not, then do that (singlecast) instead of the broadcast analogy. It will bring event communication between your processes and game systems down from an O(n) to O(1) order of execution time.

      3) When planning your AI system, enumerate the possible situations that may come up and plan for them ahead of time. For example, a common situation is an AI on a patrol path who breaks that pattern to engage in chase/combat and then resumes patrol... all while properly responding to environmental stimuli such as pain, fear, death, and possibly ressurection or alignment changes... or maybe they get hungry and decide to order pizza instead of chase you... or maybe they get on a horse and their entire behavior model changes into another set of behaviors.

      4) It's also useful to be familiar with Design Patterns concepts. In light of point #3 in this list, you can expect your AI code to change throughout development as it is nearly impossible to enumerate all possible situations.
      en.wikipedia.org/wiki/Behavioral_pattern
      The material can be kind of dry, but truly understanding these behavioral design patterns can't hurt.

      AI is a huge topic, but a fun one. Be prepared to do a lot of research as you architect your system. There is no silver bullet.

      The post was edited 4 times, last by Kain ().

    • Yesssssssss

      reads the book (the book)

      and you will becomes one of us (one of usssss)

      yessssss. You.. you must read the book. You must!

      Other good books include the AI Game Programming Wisdom Series as well as the Morgan Kaufman book called "Artificial Intelligence for Games".
      books.elsevier.com/us/mk/us/su…HX4BH8L1E3A8PGEE3E3FG1QJ6

      The post was edited 1 time, last by Kain ().

    • Dang it I was hoping to post an impressive answer but Kain got to it before me!

      Nice answer Kain.
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • I second the notion about the AI Wisdom series. Steve Rabin (the editor) is an incredibly knowledgeable individual as well as a great teacher (he teaches here at DigiPen). Those are great books.
      Feel you safe and secure in the protection of your pants . . . but one day, one day there shall be a No Pants Day and that shall be the harbinger of your undoing . . .

    • Well I got the book!

      Amazingly it also covers lua/scripting which is another topic of interest. Probably I will just need to use finite state machines and messages for my AI system.

      One question though.. In the book a game object can send an event/message to itself with a timestamp for when to actually do it. This is useful if you know a particular amount of delay to have between events, but what if you want your AI to do something more like
      1. walk to this location 2. when you GET there, do something

      I know you do this with messages... like reaching a destination generates an Arrival message, which then causes the gameObj to continue to the next step, but, what is a good way of storing these steps, and what exactly generates and recieves the arivale messages and how does the event manager know where to send them...

      The Rest is me trying to answer my own question... tell me if it makes sense or how you would do it?

      If a GameObj has a state class reference or instance that defines its current behaviour, then in this case I want that behaviour to be a sequence of actions, but some of these actions are not instantanious, so each action needs to wait to execute for the previous to finish...

      So instead of the interface looking like:
      State.Begin()
      State.Execute()
      State.Leave()

      It might be:
      State.Begin()
      State.DoEvent()
      State.Leave()
      private State.DoNextStep()

      in State.Begin():
      ObjRef.setDestination(x,y)
      (global)EventManager.Register(this,arrivalEvent)

      in State.DoEvent(Event e):
      DoEvent(Event e)
      {
      if (Event is change state)
      change the state
      if (Event is do next step)
      DoNextStep()
      }

      Since the State is not actually moving the player just setting a destination I need something like...

      MoveObjProcess // done each loop iteration
      foreach object
      {
      if (destination != null)
      {
      calculate velocity
      set velocity
      animate/move obj
      }
      }

    • Never mind, the author of Programming AI by Example avoids doing any tricky messaging by just having "goals" or "states" polled every iteration and checking if they are done... then they don't have to be sent a message... Ah simplicity, Thats what I'll do, especially since its such a small project.

    • Or better yet, there are also AI SDK's out there, the best one I've seen so far is the AI Implant, which also issue a free Personal Learning Edition.

      (P.S. by the way, I'm completely newly registered, this is my first post.)
      If you put your mind to it, you can accomplish anything.