• Advertisement
Sign in to follow this  

A bit of help with a behaviortree tree.

Recommended Posts

I'm currently testing out behaviortree's with the LibGDX AI library. I have read a lot about behaviortree's past couple days but it's hard to get clear how I need to build the tree for my specific scenario. I'm looking to use a behaviortree for a Rimworld like game where the players units are not directly controllable. In the first place I'm wondering if I should have a single big tree for the complete AI or many smaller tree's, for example a separate tree for:

  • Moving an item
  • Building a building
  • Crafting an item
  • Resting when sleepy
  • Eating when hungry

In the examples I have seen they all talk about a "single job". Like entering a building, GoTo -> Open Door -> GoTo -> Close door. But what if I need to check if I have the keys on me? And I need to check a lot of these variables.

When A unit is Idle I'd like him to maintain his primary needs if he has access to them. If his needs are satisfied enough he can take on certain jobs like building walls or crafting items. I have a a lot of different jobs but jobs like building or crafting items are relatively the same with a different outcome so I could probably make a abstract job for that, it helps but I will still end up with a really huge tree though.

Another issue I'm facing is that when tasks are running, and something more important pops up (enemy spotted or some kind of emergence task) the unit should stop it's current task and act accordingly to the interruption. So since the task is running I need to do those checks on each runnable task then returned failed/cancelled and further down the sequence I need to do another check for these interruptions and handle them accordingly. I have briefly read into dynamic branches, not sure if GDX AI supports this but adding a behavior to the tree to handle an interruption seems a good idea. These dynamic branches also opens the opportunity to hold behaviors at the jobs and once a unit accepts a job it inserts that branch into it's own tree.

I hope I'm clear, it's hard to explain and get a global view of a complex behavior tree. I have read several times that behavior tree's are very easy to understand and implement. Well, that might be the case for those small tree's I find everywhere. On the other hand I might be over complicating things.

Edited by menyo

Share this post

Link to post
Share on other sites

Generally, each character has everything in one behaviour tree, and that is responsible for choosing and executing whatever they are doing at that time. Some systems (e.g. Unreal) allow you to factor out subtrees into different files for convenience and modularity. It looks like LibGDX AI offers something like this too with the 'include' concept. But the top-level view is the same - one character is executing one tree at all times. My advice is to start with one single tree, and factor bits out later as necessary to keep it manageable.

Regarding checking conditions and decision making, it's sometimes easier to reframe the problem. A behaviour tree provides 2 key features:

  1. The ability to try a series of things in priority order until it finds one that it can carry out. (This is a Selector node.)
  2. The ability to perform several things in order until one fails. (This is a Sequence node.)

Additionally many systems offer some sort of Conditional node or Decorator system to add extra conditions on in a modular way.

Pretty much everything you want can be expressed by some arbitrary combination or nesting of the above (and often there are several alternative approaches). For example, for your "enter a building, but only if the character has keys", might start as a simple Sequence, GoTo -> Open Door -> GoTo -> Close door just you said. But you could add a Decorator on that sequence which is "Fail if doesn't have keys", which means the character would attempt the next action after that Sequence instead. (That could be a 'Find Keys' task of some sort.)

Regarding the concept of being 'idle', that basically refers to a low-priority state - and therefore that would be the last node of a Selector. It would only execute if more high priority nodes under that same Selector - e.g. a "Combat" node - fail (e.g. because you have a decorator that says 'Fail if there's no threat', or you simply make the Combat task fail if there's nothing to fight).

The need to be able to interrupt a task when circumstances change is obviously important. A naive behaviour tree system might evaluate the tree every frame/update in order to ensure that it's always up to date, and in such a system you would just use the conditionals or decorators as normal, and higher priority tasks would be picked in Selector nodes whenever they apply, as normal. However, many behaviour tree implementations don't want to re-evaluate the tree all the time as it's quite inefficient, and they ask you to explicitly specify the conditions under which the tree is re-evaluated when a task is ongoing. In the LibGDX AI system this appears to be the role of the 'dynamic guard selector'.

Note that each behaviour tree implementation is different, so it's often hard to translate a concept from one style of BT to another style until you're sufficiently familiar with both.


Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By GytisDev
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Descent
      Wow what a wild game by GalaXa Games Entertainment Interactive. Play now... it's really fun but IF you have epilepsy then don't play. It does not feature flashing pictures, but there is lots of animated stuff that might get ya. Anyway, 4 levels, 2 endings, insane action, BY INFERNAL. Please play it, right nao! Also , nice midi music composed by me is in the game.
    • By Armantium
      Killing Floor 2 has the best dismemberment/gore system by far.
      No other game comes even close; how enemies react, segmented body parts depending where you shoot them, how dead bodies react, etc.
      Is there an easy-to-set up system, but with scaled down features, for the Unreal Engine 4, while still offering the same visceral physicality?
    • By GameDev.net
      This is an extract from Practical Game AI Programming from Packt. Click here to download the book for free!
      When humans play games – like chess, for example – they play differently every time. For a game developer this would be impossible to replicate. So, if writing an almost infinite number of possibilities isn’t a viable solution game developers have needed to think differently. That’s where AI comes in. But while AI might like a very new phenomenon in the wider public consciousness, it’s actually been part of the games industry for decades.
      Enemy AI in the 1970s
      Single-player games with AI enemies started to appear as early as the 1970s. Very quickly, many games were redefining the standards of what constitutes game AI. Some of those examples were released for arcade machines, such as Speed Race from Taito (a racing video game), or Qwak (a duck hunting game using a light gun), and Pursuit (an aircraft fighter) both from Atari. Other notable examples are the text-based games released for the first personal computers, such as Hunt the Wumpus and Star Trek, which also had AI enemies.
      What made those games so enjoyable was precisely that the AI enemies that didn't react like any others before them. This was because they had random elements mixed with the traditional stored patterns, creating games that felt unpredictable to play. However, that was only possible due to the incorporation of microprocessors that expanded the capabilities of a programmer at that time. Space Invaders brought the movement patterns and Galaxian improved and added more variety, making the AI even more complex. Pac-Man later on brought movement patterns to the maze genre – the AI design in Pac-Man was arguably as influential as the game itself.
      After that, Karate Champ introduced the first AI fighting character and Dragon Quest introduced the tactical system for the RPG genre. Over the years, the list of games that has used artificial intelligence to create unique game concepts has expanded. All of that has essentially come from a single question, how can we make a computer capable of beating a human in a game?
      All of the games mentioned used the same method for the AI called finite-state machine (FSM). Here, the programmer inputs all the behaviors that are necessary for the computer to challenge the player. The programmer defined exactly how the computer should behave on different occasions in order to move, avoid, attack, or perform any other behavior to challenge the player, and that method is used even in the latest big budget games.
      From simple to smart and human-like AI
      One of the greatest challenges when it comes to building intelligence into games is adapting the AI movement and behavior in relation to what the player is currently doing, or will do. This can become very complex if the programmer wants to extend the possibilities of the AI decisions.
      It's a huge task for the programmer because it's necessary to determine what the player can do and how the AI will react to each action of the player. That takes a lot of CPU power. To overcome that problem, programmers began to mix possibility maps with probabilities and perform other techniques that let the AI decide for itself how it should react according to the player's actions. These factors are important to be considered while developing an AI that elevates a games’ quality.
      Games continued to evolve and players became even more demanding. To deliver games that met player expectations, programmers had to write more states for each character, creating new in-game and more engaging enemies.
      Metal Gear Solid and the evolution of game AI
      You can start to see now how technological developments are closely connected to the development of new game genres. A great example is Metal Gear Solid; by implementing stealth elements, it moved beyond the traditional shooting genre. Of course, those elements couldn't be fully explored as Hideo Kojima probably intended because of the hardware limitations at the time. However, jumping forward from the third to the fifth generation of consoles, Konami and Hideo Kojima presented the same title, only with much greater complexity. Once the necessary computing power was there, the stage was set for Metal Gear Solid to redefine modern gaming.
      Visual and audio awareness
      One of the most important but often underrated elements in the development of Metal Gear Solid was the use of visual and audio awareness for the enemy AI. It was ultimately this feature that established the genre we know today as a stealth game. Yes, the game uses Path Finding and a FSM, features already established in the industry, but to create something new the developers took advantage of some of the most cutting-edge technological innovations. Of course the influence of these features today expands into a range of genres from sports to racing.
      After that huge step for game design, developers still faced other problems. Or, more specifically, these new possibilities brought even more problems. The AI still didn't react as a real person, and many other elements were required, to make the game feel more realistic.
      Sports games
      This is particularly true when we talk about sports games. After all, interaction with the player is not the only thing that we need to care about; most sports involve multiple players, all of whom need to be ‘realistic’ for a sports game to work well.
      With this problem in mind, developers started to improve the individual behaviors of each character, not only for the AI that was playing against the player but also for the AI that was playing alongside them. Once again, Finite State Machines made up a crucial part of Artificial Intelligence, but the decisive element that helped to cultivate greater realism in the sports genre was anticipation and awareness. The computer needed to calculate, for example, what the player was doing, where the ball was going, all while making the ‘team’ work together with some semblance of tactical alignment. By combining the new features used in the stealth games with a vast number of characters on the same screen, it was possible to develop a significant level of realism in sports games. This is a good example of how the same technologies allow for development across very different types of games.
      How AI enables a more immersive gaming experience
      A final useful example of how game realism depends on great AI is F.E.A.R., developed by Monolith Productions. What made this game so special in terms of Artificial Intelligence was the dialog between enemy characters. While this wasn’t strictly a technological improvement, it was something that helped to showcase all of the development work that was built into the characters' AI. This is crucial because if the AI doesn't say it, it didn't happen.
      Ultimately, this is about taking a further step towards enhanced realism. In the case of F.E.A.R., the dialog transforms how you would see in-game characters. When the AI detects the player for the first time, it shouts that it found the player; when the AI loses sight of the player, it expresses just that. When a group of (AI generated) characters are trying to ambush the player, they talk about it. The game, then, almost seems to be plotting against the person playing it. This is essential because it brings a whole new dimension to gaming. Ultimately, it opens up possibilities for much richer storytelling and complex gameplay, which all of us – as gamers – have come to expect today.
    • By GreenGodDiary

      Solved: didn't think clearly and realized I can't just compare the cross-product with 0,0,0.  
      Fixed by doing this:
      float3 originVector = float3(0.0, 0.0, 0.0) - v1.xyz; if (dot(cross(e1, e2).xyz, originVector) > 0.0) { //... } I'm trying to write a geometry shader that does backface culling. (Dont ask me why)
      What I'm doing is checking the cross-product of two edges of the triangle (in NDC space) and checking if it's facing 0,0,0 .
      The problem is when I compile I get this error:
      this is i guess because if it isn't facing us, I dont append any verts to the stream. I always assumed maxvertexcount implied I can emit as few verts as I like, but I suppose not.
      How do I get around this?

      Shader below:
      struct GS_IN_OUT { float4 Pos : SV_POSITION; float4 PosW : POSITION; float4 NorW : NORMAL; float2 UV : TEXCOORD; }; [maxvertexcount(3)] void GS_main( triangle GS_IN_OUT input[3], inout TriangleStream< GS_IN_OUT > output ) { //Check for backface float4 v1, v2, v3; v1 = input[0].Pos; v2 = input[1].Pos; v3 = input[2].Pos; float4 e1, e2; e1 = v1 - v2; e2 = v1 - v3; if (dot(cross(e1, e2).xyz, float3(0.0, 0.0, 0.0)) > 0.0) { //face is facing us, let triangle through for (uint i = 0; i < 3; i++) { GS_IN_OUT element; element = input[i]; output.Append(element); } } }  
  • Advertisement