Page 1 of 4 123 ... LastLast
Results 1 to 10 of 34

Thread: New ideas for AI in games?

  1. #1
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25

    Question New ideas for AI in games?

    Has anyone been doing any work with AI of any sort in their recent game projects?

    AI has so many uses and doesn't all necessarily have to be all that advanced. For example you take Pong. If you want to make a single player game of pong to add a computer player you simply need to program the computer player's imposed reactions. If the ball is the to computer player paddle's right then steer the paddle right, if to the left the same.

    Of course you should then have a degree of error so that the computer player doesn't always win. Say something as simple as a delay time before the computer can make another direction change or a value that it can be off by the ball's actual location in relation to the computer player's paddle. This part is trial and error and usually requires testing, but can be quite fun to work with.

    AI doesn't really need to be any more than that for a beginner. You can go further and learn such things as path finding, state machines and as far advanced as training neural networks, but it all depends on what you need the AI player(s) to do in your game and at what level of difficulty you want them to provide your players.

    What are you guys doing with your games that may or could require AI?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  2. #2
    AI has been previously a very popular topic and in certain occasions there was even a degree that you can obtain in institutions. However, it didn't live up to the expectations and later was renamed to "Intelligent Systems" and now is an area of science that has limited applications, being more like a meta-science itself.

    In games, dealing with AI usually ends up with using one of Seach Algorithms, probability sets, Markov chains and so on.

    In my opinion, to achieve a good AI in games you need to translate expert's player knowledge into execution scheme that accurately reproduces the expert's decision making process. Of course, you can take advantage of processing power and apply search algorithms and exact physics calculations whenever possible to beat the player, something that is difficult to achieve in real-time for a human mind.

  3. #3
    I'm building the game so that there's no distinction between Human and AI controlled player. TPlayer class might have MoveTo() command so that, whichever executes it, will automatically follow the set rules of the game. For AI you can map all options it can do at the time, and then select 1 of them. Might be combination of weighted and random choice.

    In a board game you can try all those available moves (which is usually quite few), and the moves that would follow that. A scenario that leads to defeat would naturally set the weight value low, and a victory condition respectively high. In many games you can also value the scenarios "progressive weight". For example in a game where your goal is to move all pieces to opposite side of the board, then naturally scenario where sum of distances of all your pieces on board being smallest, is most valuable. Or scenario where enemy has less pieces than you may be more valuable than normal neutral state.

  4. #4
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Not in games I haven't. But in the last week I have been looking at artificial neural networks, which are indeed very interesting. The prospect of being able to implement one on todays hardware and multi-threaded concepts offers some interesting evolution in that field. However, due to how abstract it is, I've been toying with the idea of a multi-agent system which in my opinion is the better option. Something like having the game thread along with an independant AI thread that simply has a pointer to the TPlayer^.Input() function is interesting for multi-core systems.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  5. #5
    Well, I do have AI in my Boulder Dash game The Probe - the enemies have decision making as to when to turn, or go forward.

  6. #6
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    I've created and am in the process of improving generic AI components in JenJin. It currently covers techniques related to movement however I've done little on decision related AI such as state machines but have researched such techniques extensively. Currently I have various steering implementations, path finding and following, region biased constraints as well as extensive tie ins with various 'region' types in the engine (Terrain (spherical + flat), portal/indoor and voxel (think minecraft). As the engine is designed along side a WYSIWYG content tool, anything that can be visually configurable is so.

    When I grace the AI portions again (I'm currently finishing off the GL2.x support, was only ES2/GL3/4 previously) I'll finish off the event hooks and it should then be possible to code state machines with scripts. Events can be triggered from lots of different things :

    A Spatial entity entering the confines of a region
    Coming within a given radius of a fixed point or another entity
    User events specified in scripts
    etc

    You can also trigger timer style 'events' for paradigms that don't fit well with classic events IE you may want the bias for an entity to move away from another to scale with distance to that entity.

    And obviously anything that's needed that I don't add can just be hard-coded/scripted in any game client code.

    --

    I will eventually look at options for using neural-networks as I believe it's something that a lot of people would like to experiment with however, they are not for the faint hearted and how they are used is not as direct as people would imagine. They do little more than bias state machine outcomes in most games and very few use them for direct control of an entities actions.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  7. #7
    PGDCE Developer de_jean_7777's Avatar
    Join Date
    Nov 2006
    Location
    Bosnia and Herzegovina (Herzegovina)
    Posts
    287
    In my current game project the AI is simple. All entities follow a set of actions. When an action is complete it goes on to the next action in the list. Some actions have simple decision making, which can result in jumping to another action (a random chance or so) The action state is stored individually for each entity. Actions can be chained, so they are performed simultaneously (e.g. following a path, and firing projectiles at the same time, while making a decision to change paths). With time I expand the number of action types, for now it's: path following, waiting at a point, teleporting to a point, and firing projectiles, timer to go on to next action, and random chance to go on to next action (a sort of random behavior at certain points). This is sort of simple scripting with limited number of actions, and works well enough for a simple top-down scrolling space shooter. I also intend to make some actions situation aware, like projectile firing, so that the enemies don't fire too many projectiles and swamp the player. The actions are configurable to a certain extent. The most tiring part is coding all the action lists and configuring them, so I made some helper functions and predefined actions to help.

  8. #8
    Quote Originally Posted by de_jean_7777 View Post
    In my current game project the AI is simple. All entities follow a set of actions. When an action is complete it goes on to the next action in the list. Some actions have simple decision making, which can result in jumping to another action (a random chance or so) The action state is stored individually for each entity. Actions can be chained, so they are performed simultaneously (e.g. following a path, and firing projectiles at the same time, while making a decision to change paths). With time I expand the number of action types, for now it's: path following, waiting at a point, teleporting to a point, and firing projectiles, timer to go on to next action, and random chance to go on to next action (a sort of random behavior at certain points). This is sort of simple scripting with limited number of actions, and works well enough for a simple top-down scrolling space shooter. I also intend to make some actions situation aware, like projectile firing, so that the enemies don't fire too many projectiles and swamp the player. The actions are configurable to a certain extent. The most tiring part is coding all the action lists and configuring them, so I made some helper functions and predefined actions to help.
    Sounds very cool! I don't suppose you could share some code snip-its or something?

  9. #9
    PGDCE Developer de_jean_7777's Avatar
    Join Date
    Nov 2006
    Location
    Bosnia and Herzegovina (Herzegovina)
    Posts
    287
    This is the action type.

    Code:
       TEntityAction = record
          {action and it's properties}
          action, effect, properties: longword;
          {action is complete}
          done: boolean;
    
          {direction}
          vDir: TVector3f;
    
          {distance traveled, speed}
          distance, speed: single;
          {minimum duration, max duration, start wait time minimum, start wait time maximum}
          minTime, maxTime, startWaitTimeMin, startWaitTimeMax: single;
    
          along: PEntityAction; {action to be performed along with this one}
          next: PEntityAction; {action to be performed after this one}
    
          {an associated path}
          path: PPath;
    
          {an associated projectile group}
          projectileGroup: PProjectileGroup;
       end;
    This holds action data per each entity and action.


    Code:
       TEntityActionData = record
          initialized, done: boolean;
    
          distancemoved: single;
          lineardir: longint;
          actionTime, startWaitTime: single;
          timer: TTimerData;
          waitedAtStart: boolean;
    
          vPos: TVector3f;
       end;
    Here is a simple move action.

    Code:
    procedure actionMoveDistance(var ent: TEntity; var a: TEntityAction; var d: TEntityActionData);
    var
       vmMov: TVector3f;
       dist: Single;
    begin
       if(d.distancemoved < a.distance) then begin
          vmMov := a.vDir * (a.speed * oxMainTimeFlow);
          dist := vmDistance(vmvZero3f, vmMov);
    
          d.distancemoved := d.distancemoved + dist;
    
          ent.vPos := ent.vPos + vmMov;
          if(a.distance < d.distancemoved) then begin
             ent.vPos := ent.vPos - (a.vDir * (d.distancemoved - a.distance));
             d.distancemoved := a.distance;
    
             nextAction(ent);
          end;
       end;
    end;
    There is a lot more, but I think if I shown how everything works this would be one really huge post. I still need to expand this and improve the already existing code.

  10. #10
    I'm a fan of PID controllers in AIs (http://en.wikipedia.org/wiki/PID_controller) for a whole lot of behavioral aspects.
    You can slap one on top of path-finding or other combinatorial logic to make it look more natural, along with delay loops to prevent the AI from having god-like reflexes.

    You can use it to control a lot of things, from a pong bat, a tracking missile, a gun tracking the player, a monster moving across the map, a flock of targets, an airplane that doesn't cheat, etc. All the flight logic in AirBlast was done with PIDs, the AI having access to the same exact flight controls as the player, and it would use them to fly in formation, attack, evade, etc.

    You can also vary difficulty by using more or less adjusted sets of parameters

    But I guess the real advantage is that it can behave in a natural fashion, and works very well in simulated environments when things aren't "smooth" because of collisions, external events, terrain, etc (after all, it comes from real-world control feedback mechanisms).

    They're extremely simple to code, and once you're accustomed, they're fairly simple to tweak manually.

    I'm sure the vast majority of those that have ever coded a game have used (ofttimes unknowingly) at least the P, sometimes the PI variant. But when you know the theory and the limitations of PIDs, you can put them to use more effectively, and more creatively ;-)

    They're surprisingly versatile, and can be applied to various fields, not just direct "first line" controls, but also f.i. to control tresholds or other fuzzy logic parameters (and have the AI entity switch between various behaviors according to them). It's one of those very simple logic bricks that has potential for great complexity, and can "smooth" the output of more hardcore graph-based logic.

Page 1 of 4 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •