Getting started with abstract AI to govern NPC behaviour, before translating it into a game

Started by
2 comments, last by wodinoneeye 7 years, 4 months ago

Hi all,

Firstly, from the look of the other posts in this part of the forum - most of you are operating on a way higher level of expertise than me when it comes to AI. I know none of the terminology and am new to it, so treat me as a layman!

I have recently started learning about GameMaker at a very basic level, (making coloured blobs move around on screen when cursors are pressed). I have gradually worked up to a basic isometric game where a player moves his blob around a simple single screen maze - avoiding other 'enemy' blobs that are on a pre described linear up-down style path. Simple stuff.

I have even experimented a little with blobs that chase you when you get close and them - but then abandon the chase when you get far enough away again (I know, right).

Gradually, I am getting to grips with the GML code side of things, so I got thinking about planning a much more sophisticated AI.

The code instructions I have used so far are pretty simple, and only govern crude NPC chasing behaviour - but could be applied to a more complex actions.

This got me onto a new train of thought, what If I put together a flow diagram (for lack of a better word) of 'if-x-is-y-then-do-this-action' style commands that is based on a core set of variables that I guess you could call the 'character'.

The variables (for the sake of this post, lets say each variable is a value of 1-100) in question would basically be anything, from physical attributes (video game staples like 'strength - 50' etc...) to things that are more abstract (one idea that I had would be a variables that govern what motivates the character - for example: 'desire to find food - 20' 'desire to make a shelter - 70').

The idea would be that the flow diagram that would govern the decisions that the AI makes would constantly refer back to the character attribute figures in order to influence its behaviour. For example:

- Enemy attacks

(If aggression stat is less than 15, go to the stage in the flow diagram/algorithm that governs behaviour while fleeing).
(If aggression stat is between 15 and 75, fight back until enemy is subdued)
(If aggression stat is more than 75, fight back until enemy is killed).

Basically, the idea is that once the behaviour flow diagram is assembled - NPC's core identity could be either carefully tailored by adjusting the 'character' figures. These could even be randomised (within certain parameters) to add variety to the NPC's in a game.

I also though that it would make sense that certain actions/results of decisions made by the NPC's could work in reverse and have an impact on their 'character'. For example, if an aggressive NPC constantly retaliates with heavy violence but is overpowered x amount of times - this could gradually lower the aggression stat so that they become more wary.

I'm basically just thinking aloud - I assume that to most of you, this is just a very vague description of how things are already done. Sorry if this is the case.

Am I on the right lines with my thinking?

My end goal is a behaviour system that has an initial 'stat input' system for each NPC. This will allow me to then just turn them loose in an RPG and see how they interact with each other - this could even form the basic premise for a very simple eco-system sim?

I'll elabourate on this after sleep and coffee.

TJ


Advertisement
The flow graph is fine. That's basically a set of edges in a finite state machine, which is the core building block of a very large percentage of AI systems in games of all sizes.

But what's the point of the stats?

Is it to fine-tune behaviors? Because the behaviors will be emergent (which may not necessarily be what you want) given how incredibly difficult you as a designer are going to find tweaking a multitude of arbitrary numbers.

Is it to make enemies behavior realistically? Because players aren't in the slightest going to know or care if your NPC has an aggression of 74 or 75.

Your AI should be simpler, predictable (when you want it to be) or composable (when you want emergence), and very easy to read. An angry NPC should _just be angry_, not have some complex combination of Aggression+Strength-Wisdom*Shoesize. If something makes an NPC angry, there should be a clear "X made Y angry" feedback and then an obviously angry NPC.

The subtlety is lost on the player. They don't know what the "character" of your NPC is. They care about how every little micro action might affect the NPC, and typically get annoyed even when big actions affect NPCs in undesired ways. They aren't seeing your clever algorithm and don't appreciate its workings. They're just seeing an unreadable and unpredictable NPC that keeps reacting and doing things that they don't want or expect.

From a design perspective, you also want fewer variables with fewer discrete states. A nice big boolean IS_ANGRY flag is very easy to write, to test and QA, and to choreograph in animations/art so the player knows what's going on. A bag of floats going through a complex fuzzy evaluation graph is much harder to write, damn near impossible to test, and that much harder to animate.

Sean Middleditch – Game Systems Engineer – Join my team!

If you aim to trigger stuff based on values, you can use a propper utility system.

http://www.gdcvault.com/play/1021848/Building-a-Better-Centaur-AI

http://intrinsicalgorithm.com/IAonAI/2013/02/both-my-gdc-lectures-on-utility-theory-free-on-gdc-vault/

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
Author of the book, Behavioral Mathematics for Game AI
Blogs I write:
IA News - What's happening at IA | IA on AI - AI news and notes | Post-Play'em - Observations on AI of games I play

"Reducing the world to mathematical equations!"

If you are genericising this logic then you want some table based data to be provided to the if x<nnn then do X else if x<mmm then do Y else if x < ooo do Z else do A decision making. Then you can have other code adjust the table for nnn,mmm,ooo to match circumstances/situation for each object making that decision (and even the X Y Z A action options). The adjustment to the table doesn't have to be made EVERY cycle, only when things change sufficiently (potentially eliminating ALOT of AI situation/criteria calculations being done too frequently).

--------------------------------------------[size="1"]Ratings are Opinion, not Fact

This topic is closed to new replies.

Advertisement