Skip to content

Coordinating Agents with Behaviour Trees

Array ( [blocks] => specificItem [show] => [itemId] => 15158 [exactSize] => 200 [itemFrame] => none [albumFrame] => none ) Array ( [blocks] => specificItem [show] => [itemId] => 15164 [exactSize] => 200 [itemFrame] => none [albumFrame] => none )
Error (ERROR_STORAGE_FAILURE)
  • in modules/core/classes/GalleryStorage.class at line 494 (GalleryCoreApi::error)
  • in modules/core/classes/Gallery.class at line 202 (GalleryStorage::search)
  • in modules/core/classes/helpers/GalleryUserGroupHelper_simple.class at line 105 (Gallery::search)
  • in modules/core/classes/GalleryCoreApi.class at line 1876 (GalleryUserGroupHelper_simple::fetchGroupsForUser)
  • in modules/core/classes/helpers/GalleryPermissionHelper_simple.class at line 64 (GalleryCoreApi::fetchGroupsForUser)
  • in modules/core/classes/helpers/GalleryPermissionHelper_simple.class at line 39 (GalleryPermissionHelper_simple::_fetchAccessListIds)
  • in modules/core/classes/GalleryCoreApi.class at line 501 (GalleryPermissionHelper_simple::fetchAccessListIds)
  • in modules/core/classes/helpers/GalleryUserHelper_simple.class at line 76 (GalleryCoreApi::fetchAccessListIds)
  • in modules/core/classes/GalleryCoreApi.class at line 566 (GalleryUserHelper_simple::hasItemPermission)
  • in modules/imageblock/classes/ImageBlockHelper.class at line 217 (GalleryCoreApi::hasItemPermission)
  • in modules/imageblock/classes/ImageBlockHelper.class at line 93 (ImageBlockHelper::_getBlockData)
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc at line 1352 (ImageBlockHelper::loadImageBlocks)
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc at line 867
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc(1229) : regexp code at line 1
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc at line 1229
  • in ??? at line 0
  • in /home/aarmgorg/public_html/journal/wp-includes/plugin.php at line 213
  • in /home/aarmgorg/public_html/journal/wp-includes/post-template.php at line 230
  • in /home/aarmgorg/public_html/journal/wp-content/themes/barthelme/page.php at line 12
  • in /home/aarmgorg/public_html/journal/wp-includes/template-loader.php at line 75
  • in /home/aarmgorg/public_html/journal/wp-blog-header.php at line 16
  • in /home/aarmgorg/public_html/index.php at line 4
1
Error (ERROR_STORAGE_FAILURE)
  • in modules/core/classes/GalleryStorage.class at line 494 (GalleryCoreApi::error)
  • in modules/core/classes/Gallery.class at line 202 (GalleryStorage::search)
  • in modules/core/classes/helpers/GalleryUserGroupHelper_simple.class at line 105 (Gallery::search)
  • in modules/core/classes/GalleryCoreApi.class at line 1876 (GalleryUserGroupHelper_simple::fetchGroupsForUser)
  • in modules/core/classes/helpers/GalleryPermissionHelper_simple.class at line 64 (GalleryCoreApi::fetchGroupsForUser)
  • in modules/core/classes/helpers/GalleryPermissionHelper_simple.class at line 39 (GalleryPermissionHelper_simple::_fetchAccessListIds)
  • in modules/core/classes/GalleryCoreApi.class at line 501 (GalleryPermissionHelper_simple::fetchAccessListIds)
  • in modules/core/classes/helpers/GalleryUserHelper_simple.class at line 76 (GalleryCoreApi::fetchAccessListIds)
  • in modules/core/classes/GalleryCoreApi.class at line 566 (GalleryUserHelper_simple::hasItemPermission)
  • in modules/imageblock/classes/ImageBlockHelper.class at line 217 (GalleryCoreApi::hasItemPermission)
  • in modules/imageblock/classes/ImageBlockHelper.class at line 93 (ImageBlockHelper::_getBlockData)
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc at line 1352 (ImageBlockHelper::loadImageBlocks)
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc at line 867
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc(1229) : regexp code at line 1
  • in /home/aarmgorg/public_html/journal/wp-content/plugins/wpg2/wpg2embed.inc at line 1229
  • in ??? at line 0
  • in /home/aarmgorg/public_html/journal/wp-includes/plugin.php at line 213
  • in /home/aarmgorg/public_html/journal/wp-includes/post-template.php at line 230
  • in /home/aarmgorg/public_html/journal/wp-content/themes/barthelme/page.php at line 12
  • in /home/aarmgorg/public_html/journal/wp-includes/template-loader.php at line 75
  • in /home/aarmgorg/public_html/journal/wp-blog-header.php at line 16
  • in /home/aarmgorg/public_html/index.php at line 4
1

Ricard Pillosu, Lead Programmer, Crytek

Recently, the concept of Behaviour Trees has been gaining traction and was used in games like Spore or Halo 3. Crytek has adpoted and developed this technology to also coordinate different agents in complex situations. After a brief introduction to Crytek’s perspective on Behaviour Trees, Ricardo will provide examples on how this concept canbe used to simulate group tactics.

Good overview of behaviour tree workings with a nice set of examples. Looks like something worth experimenting in. There was a Q&A after which I merged in my notes.


The title isn’t too reflective of this talks content – concentrating on the concept of design of the AI, not the code.

You expect the better behaviour when the game fidelity improves graphically – from Far Cry versus Crysis. The actors in Far Cry all had the same pose, so not much expectation, while the AI in Crysis should be much better since people are jumping and so on.

The motivation for a new approach to AI was growing complexity – the new approach must deal with more info, be easier to use (debugging, tweaking), allow rapid iterations, use less hardware resources, allow coordinating AI agents – so for instance, flanking manoeuvres.

How will behaviour trees help? They are easy to understand and change, and expose the complexity in a view of actions. Setup in an XLM file.

Originally had LUA behaviours linked together – a large state machine. Need granularity of data numbers and events the engine sends to agents. EG: “You see the enemy” sets “Can_see_enemy” to 1.

Now the behaviour tree can focus on taking decisions, based on the information available (eg: our weapon, health, ammo, friends, chosen tactic, stance, armour, and if they see the enemy).

Behaviour tree nodes have two parts – condition checks and actions. Condition checks are simply if statements of conditions that need to be fulfilled. Having too many checks means you might be thinking wrong and need to expand your behaviour tree.

The other part is actions, what to do. In Crysis, normally is LUA script or a bit of C++ code to do it. If it is not a leaf node, will then work left to right on the ones under it as a way to do priorities. Halo guys said this was the best way to start then add on random selections, etc. – but didn’t need to add to this method, even though they had really complex behaviours.

Example of a soldier – the root node is empty, then work left to right – combat first – if condition of combat fulfilled, work on distance (melee/shooting/approach), then fight, if not then search if you know the enemy is around, if not searching then idle – eg; smoke, patrol.

Importantly don’t need to know what happens after you reach a leaf node – eg: going into melee (drawing your knife and attacking) don’t test anything more.

Adding in more behaviours is pretty easy – adding “being wounded” on the floor, just need to add one to the far left, over combat priority, so “if wounded” just doing wounded stuff.

Adding another – ordering around if a “Captain” (no practical value, but animations/sound) add the behaviour into the idle (far left), and in combat (far right). Same action in two places. Copy and paste the node.

Question – do you only change on knowledge changes? Do you always smoke? Yes, you constantly smoke. Can you change from smoking? If the animation ends for instance? If that’s the case, you can add an event to change the knowledge at the end of the animation.

Question – When you have deep design changes, do you alter the existing the tree or do you start a tree from scratch? Yes, we have more complex trees, but what you want ideally is one behaviour to not affect any others, such as patrolling will loop forever without input – completely reactive. Is it easy to maintain and evolve? Depends on the stage of the project – start of production is easy to do without much overhead. Good to do since you are prototyping anyway. Just do it quickly without making it perfect. Later on you can alter branches but not that much stuff.

Question – Can you do preparation animation if you havn’t decided what to do in combat? Yes, we added an example on a branch node, not a leaf – so going to combat, we draw our weapon out. Means you don’t need to put that line of code on each leaf node for combat. It is a mess however, so do it in the leaf nodes if possible.

Doing the “Captain” role based on a variable means you can change the captain dynamically when one dies to what they want the new captain to be. Beware: starts adding complexity that gets to be a large tree – eg: sniper, captain, lieutenant, etc.

Coordinating agents is the reason for behaviour trees. What is coordination? Is synchronised behaviour change between two or more agents. Need to ask not what to do – but when to do something synchronised, and when to stop too. That’s a challenge!

Crysis had a Tactic manager (not a good word Tactic, but oh well). Tactic called “Flank” – design requirements (since every designer is different!) is to have at least two candidates (one distracts, one flanks) and a maximum of 3 (one distracts, other two flank).

Where in the tree though? (The when). Lots of suggestions – such as before, after melee, before approach, under approach. Chose under shooting (so want to shoot) and before grenade (see pic).

Tactics manager managing those behaviours like Flank. So when Flank is reached, the Tactics manager says “I can flank”, the manager says “don’t flank yet, exit this node, but I know you’re a good candidate”. When a second does it, the Tactics manager can send an event to open the Flank tactic, and then execute it.

Need to monitor when it needs to change – so if one dies, the tactic manager sends another event to turn off the flanking.

With many available agents for flanking – the others might do idle or other work (random firing or something) since many games just stop too many enemies attacking the player at once, or create two flank tactics so both groups do it. If a lot, use the closest ones. Or might be some other sorting – biggest weapon, importance, etc (done by Tactic manager).

Question – Details on the Tactics manager? Does it use a tree?
No behaviour tree, just very very simple. Can only execute one behaviour at once too.

Question – Top down or bottom up behaviour?
Definitely top down, where you can have behaviours changing is important.

Question – IS it possible to do without cheating?
Yes it is possible to do it without cheating, such as using a new perception system used in the game. There is normal perception from the actor, or there is belief – knowledge from other teammates. Also memory perception – someone runs behind a wall, you remember he was there. Can achieve it by not cheating.

Question – Does it have benefit to not cheating? (such as the all knowing force in Left 4 Dead).
You can do it in a systematic way, such as knowing someone is there because they are moving behind the wall. Up to the AI designers.

Question – Behaviour trees are good for rules of engagement. However, for example, a complex tactic – guard the rear, someone go on a patrol – you don’t have in one place the representation of that.
Tactic manager has minimum, maximum candidates for tactics. For a complex thing you can nest tactics – you branch node and distributing different AI’s, is probably what you would do.

Question – Do you use this technique in Endwar?
Use a kind of order encapsulation system. Used to organise behaviour of units.

Notes: Added the difficulties of level designers not having much interaction with the tree, so perhaps adding environmental hints would be a good idea. Also it is important to give visual representations of the AI at all points. Also give hardcoded restrictions not just documented ones – and report it as it won’t work – different colours and so on.

Can also sell what the AI is thinking in 5-10M, with voice and actions. Shows off the AI.

Also having pauses – with reloading, an intentional mistake that allows the player to kill them. Maybe easier in 3rd person if the player takes cover.

95% from what the player feels – so simple behaviours can have a huge effect. AI programmers have to step back and ask what you’re giving feel to the player.

{ 2 } Comments

  1. Oh so true. While I see the point of the 5 paragraph essay (and the 5 sentence paragraph that goes into it), I do wish that more people would say, “Now that you’ve mastered the ‘rules,’ throw them away. Because they’re not rules, they’re guidelines to help us communicate. Communication’s what it’s really all about.” And communication only matters if you’ve got an idea to communicate.

  2. http://carprotection.myfreeip.me/ | July 20th, 2016 at 16:10 | Permalink

    become dangerously overheated and dehydrated while you are using: acetaminophen (Tylenol); cyclosporine (Gengraf, Neoral, Sandimmune); danazol (Danocrine); gemfibrozil (Lopid); nefazodone (an antidepressant); the antibiotics clarithromycin (Biaxin), dalfopristin/quinupristin (Synercid), erythromycin (E.E.S., EryPed, Ery-Tab, Erythrocin, Pediazole), levofloxacin (Levaquin), moxifloxacin (Avelox), ofloxacin (Floxin), norfloxacin (Noroxin), and others. Using NSAID

Post a Comment

Your email is never published nor shared. Required fields are marked *