We'll start by collecting AI productions on action lists and behavior trees.

As humans, we always seem inclined to use our familiar solutions. We always do something in the way we know it, not in the "best" way to do it. Because this is always the case, it is easy to use outdated techniques and perform certain functions in ways that are not understood by the generations or are not as effective. Therefore, I hope that through this article and the following article to the broad masses of readers will be able to help you in programming solutions. What I want to share today is the list of actions!

The action list is a simple but powerful AI that all game developers must be aware of. Although not comparable to large AI networks, they allow for relatively complex bursts of behavior and are simple to execute. Whether you're new to AI programming or a seasoned developer looking to extend the toolkit, this article will give you a detailed overview of the action list and provide some useful examples to help you better implement the solution. Let's get started.

Past

A few years ago I began to develop the King Randall's party, in which the player will build the castle and fight to protect it against the king who is trying to destroy it. I need to create a witty AI that can target the player's castle and plan how to destroy it to achieve its purpose. It was a huge challenge for me because it was too big for me to take full account of it. So like any other good programmer, I break it down into a more manageable set of questions. The first challenge I faced at this time was that I needed to create a unit with a specific set of behaviors.

King Randall ' s Party (from GameDev)

And the fast Web search made my spirit almost collapse. As long as the search for "game AI" will appear about the planner, finite state machine, guided behavior, wizards and so on. I don't even know where to start, so I can only do what rational people do. Yes, I asked the dog of our house. Of course, it's not a novelty for me. Whenever I encounter technical problems, I will ask our dog. At this point you might think: "Jesse, you're crazy." How can a dog know a computer?! "Well, let's not take care of this first." Perhaps it contains or does not contain an illegal technology or content that appears in the university audit class.

Anyway, I'd say, "Well, Frankie, I know we have a lot of things to do with AI, but I don't know where to start." How do I create an AI framework for my game units? "Frankie's expression made me feel like a stupid person, even though my high school teacher, Mr. Francis, had told me not to ask any stupid questions." I'm pretty sure Frankie didn't think of Mr. Francis. She asked me, "Jesse, how do you usually start your day?" ”

I'll list all the things I need to do in the day and sort them based on the importance of these tasks and the time required. I answered Frankie and she said, "This is the list of actions." She told me that the action list is a list of tasks or behaviors that your game unit runs at a specific time. This is a finite state system form and can be described as a simple behavior tree with a branch. Here's how they work.

How the action list works

First you will write down all the behaviors you want your AI to have.

Action list (from GameDev)

Then you need to prioritize them. From lowest to highest.

Action list (from GameDev)

Now we need to iterate over the list to see if each action can be executed effectively. Then we will check the adhesion performance of the action, and if an item will block the subsequent action, we will exit the list. Then we'll know why this kind of obstruction is so important.

In our case, our first action "attacking the player" will only be performed when the AI is close to the player. Let's say it's not close to the player, so it checks to see if it can create a ladder in its current position, etc. until it finds an action clause that can be executed, such as hitting the door. It then executes the break code.

Action list (from GameDev)

"Obstruction" is where it starts to work. If the break occurs immediately, it will not hinder any subsequent action, and the subsequent list will continue to execute. But this is usually not the case-the action always occupies more than one frame. So in this case the break action item will call the unit. Attack (door), which changes the current state of the unit from waiting to breaking, and reverts to the true state before the door is broken.

A simple finite state machine

It sounds as if it's doable. Frankie provides a good suggestion, and the list of actions seems to suit my project very well. But I've never heard of them before, so I'm still full of questions about it--most of what I hear about AI must use a finite state machine based on transformations, which is similar to the tools used to create animations in Munity3d. You'll define some states and identify when and how they will change from one to the other. Frankie to me I explained that when you create a finite state of transition, you need to define all the states you want to have, and then you define all the transitions between these individual states. It's really going to complicate things quickly. If you have an "injury" status, you need to identify other states that can be turned into this state. If walking becomes hurt, jumping becomes damage, crouching becomes damage, attack becomes damage, etc. This is a very useful approach, but it will quickly become complex. If your AI needs are very simple, this could be a potentially unnecessary expense.

Another difficulty with transition-based state machines is debugging. When you set a stop point and look at the current state of the AI, if there is no additional debugging code, you will not be able to understand how the AI is entering the current state, what its previous state is, and how the transition takes it to its present state.

Bug in action list

As I go deeper into the list of actions, I realize that they are perfect for my execution, but at the same time I find there are some flaws. The biggest flaw comes from its greatest advantage-simplicity. Because this is an ordered list, I can't have any complex precedence structure. So if I want the "attacking player" to be in front of the "break", but after "moving to the target", but at the same time I want the "move to target" to appear behind the "break", it's hard for me to use the action list to do this, and the finite state machine would be very cumbersome.

All in all, the action list is really helpful for simple AI systems, but if you want to create a more complex AI, it's harder to execute a list of actions. This means that you can extend the concept of action lists by some means to make them more useful.

Ways to extend this concept

Some of my AI units need to do a variety of tasks-they may need to move and attack at the same time. I can create multiple action lists (game state note: A handling move, a processing attack), but there is also a problem, that is, if some types of movement can hinder the attack, and some attacks require units to stand in place, what should I do? The action Lanes will work.

The line of action is an extension of the concept of "obstruction". Based on the action line, the action project will be able to identify the specific type of action that is impeding execution and allow other projects to perform the task smoothly. Let's show this implementation further.

The line of action is only an additional method of determining action. Each action item belongs to one or more lines, and when the blocking performance becomes true, it adds the line to which it belongs, because each action has one or more lines, so they only block other actions that belong to those lines. For example, because units must be kept motionless and unable to attack when creating ladders, attacking players belong to the action line, moving to the target of the mobile line, creating both lines. Then we will arrange the order of these items, and if they are executed at the same time it will hinder the subsequent actions.

Execution case

Now that we understand this theory, we can try a real execution process. Let's start by setting up action lists and action items. For action projects I want to be able to separate execution, so let's create an interface.

Code (from GameDev)

The following is the Iactionitem implementation of the Breakdoor Action project:

Code (from GameDev)

For the action list itself I can use a simple list. Then we'll use Iactionitems to load it.

Code (from GameDev)

After that we will set up a method and iterate through the list in each frame. We need to remember that we also need to deal with obstacles.

Code (from GameDev)

Things can get more complicated if you want to use the line of action. At this point we will define the action line as a bit field and then modify the Iactionitem interface.

Code (from GameDev)

We will then modify the iterations for these lines. If the lines of the action are obstructed, they will be skipped, but the check is still normal. If all the lines were blocked, we would change the cycle.

Code (from GameDev)

Conclusion

You can see that there are a lot of things to understand. Frankie let me summarize the content from the middle school, so I came up with some key points after comprehensive thinking.

The action list is easier to create and maintain than a small transition-based state system.

They create a recognizable priority system.

There are some extension methods to handle the extended functionality.

It is difficult to find the best solution in programming. So we have to make sure that we have a variety of programming tools in our toolbox so that we can choose the right tool to solve the problem effectively in time. The final proof of action list is perfect for King Randall's party. and is it also suitable for your project?

(This article for the game state/gamerboom.com compiled, refused to any non-reserved copyright forwarding, if necessary reprint please contact: Game state)

Action lists:simple, flexible, extendable AI

by Jesse Crafts-finch

As humans, we like to implement solutions which is familiar to us. We get caught up doing things the "the" the "the"-the-know how-to-do them, rather than the ' best ' by-do them. It's easy-to-get caught up in thinking like this and as a result we end up using outdated technologies and implement Featu Res in ways the modern contemporaries don ' t understand, or is simply less effective or efficient. My purpose with this and the future papers'll be to expose readers to a broad spectrum of the solutions that'll hopefully help them in their own coding. Today I ' ll be covering Action lists!

Action Lists is a simple yet powerful type of AI the all game developers should know about. While ultimately isn't scalable for large AI networks, they allow for relatively complex emergent behavior and is easy to I Mplement. Whether you is just getting into AI programming or is an experienced industry veteran looking to expand your toolkit, TH is presentation would introduce you to Action Lists and provide concrete examples to help you implement your own solutions. Let's begin the story.

Once upon A time ...

Several years ago I was starting the development of King Randall's party, a game in which the player builds a castle a D tries to defend it against the King was trying to knock it down. I needed to create a reasonably smart AI this could look at the player's castle and figure out how to circumvent or Destro Y it in order to reach their objective–the gold pile the player is defending. This is a big challenge, almost too big to consider all at once. So-like any good programmer I broke it to a more manageable problem set. The first challenges:i needed to get the units to has a specific set of behaviors that they would act according to.

A Quick Internet search caused my mind to implode, of course. Searching for "Game AI" brought-results on planners, finite-state machines, steering behaviors, flocking, a *, Pathfindi Ng, etc. I had no clue where to start, so I did what any reasonable, rational person would do. I asked my dog. This isn ' t anything new, of course. Whenever I have a tech problem, I ask my dog. Now I know what do you ' re thinking "Jesse, that's dumb, and you ' re crazy ... What does dogs know about computers? " Well, let's just gloss over that. It may or may not be involved some illegal technology and or college class auditing.

Anyway, I said "OK Frankie–there is so much going on with AI, I really don ' t has a clue where to start. How should I go about creating a AI framework for my game units? " Frankie gave me this pretty withering look the basically informed me that I was a idiot and pretty dumb, despite what my High school teacher Mr. Francis May has told me about there never being any stupid questions. I ' m pretty sure Frankie wouldn ' t has had nice thoughts about Mr Francis either. "Jesse," she asked, "How does typically start your day?"

Well, I-write everything that I need-to-do-day-down-a-list and then-prioritize it according to how important the T Ask is and what soon it needs to being done. I explained this to Frankie and she responded "and that, are an Action list." She told me a Action list is a list of the tasks or behaviors that your game units work their A-one at a time. It is a form of the finite state system, and could was described as a simple behavior tree with a single branch level. Here's how they work. According to my dog.

How Action Lists

First you write down all of the behaviors want your AI to has.

Then your order them according to the priority. Lowest to highest.

Now we iterate through the list checking each action to see if it can execute and if it can, executing it. We then check the Actions Blocking property, and if the item is Blocking further actions we exit the list. We'll get into why Blocking is important later.

In our example here, our first action Attack Player would only execute if the AI was close to the player. Let's say it is isn't, so it checks if it can build a ladder at the this location (and should it), and so on until it finds an A Ction item It can execute such as break Door. It then executes the break Door code.

Here's where Blocking comes into play. If break Door occurs instantly, then it won't block any further actions and the rest of the list can execute. This was typically not the case–actions usually take up more than one frame. The break Door Action Item calls unit. Attack (door), which would change the unit's currentstate from waiting to Breakdoor and would return true until the door is b Roken.

A Simple Finite

Well OK. That sounds workable. Frankie had made a good suggestion and Action Lists seem like a great fit for my project. But I ' d never heard of them before so I had my doubts–most of the What I hear floating around about AI have to does with Transi tion-based finite state machines, similar to what Unity3d uses for animations in Mechanim. You define a bunch of states, and identify if and how they transition between all other. In exchange for some belly scratches, Frankie explained to me when you do a transition based finite state machine, you n Eed to define all the states your want to has, and then also define all of the transitions to and from each of the those Indiv Idual states. This can get complicated really, really fast. If you had a hurt state, you need to identify every the other state, the can transition to the this state, and when. Walking to Hurt; Jumping to hurt, crouching to hurt, attacking to hurt. This can is useful, but can also get complicated really fast. If your AI requirements ARE fairly simple, that's a lot of potentially unnecessary overhead.

Another difficulty with transition-based the state machines are that it's difficult to debug. If you set a break point and look at what the AI's is, it's impossible without additional debug code to Kno W How the AI got into it current state, what is the previous states were and what transition is used to get to the current State.

Drawbacks of Action Lists

As I dug into action lists some more, I realized that they were perfect for my implementation, but I also realized they ha D some drawbacks. The biggest flaw is simply the result of its greatest strength–its simplicity. Because It is a single ordered list, I couldn ' t has any sort of complex hierarchy of priorities. So if I wanted Attack Player to is a higher priority than break Door, but lower than Move to Objective, while also have Move to Objective being lower-than break Door ... that's not a simple problem-solve with action lists, but trivia L with finite state machines.

In summary, action lists is really useful for reasonably simple AI systems, and the more complex the AI want to model The more difficult it'll be to implement action lists. That being said, there is a few ways you can extend the concept of Action Lists to make them more powerful.

Ways to Extend this Concept

So some of my AI units is Multitaskers–they can move and attack at the same time. I could create multiple action lists–one to handle movement and one to handle attacking, but that's can be problematic –what if some types of movement preclude attacking, and some attacks require the unit to stand still? This is where the Action Lanes come in.

Action Lanes is an extension to the concept of Blocking. With action Lanes, action items can now identify specific types of action items the IT blocks from executing while ALLOWI ng others to execute without problem. Let's show this in action.

An action Lane was just an additional-determine what Action. Each Action Item belongs to one or more lanes, and if its Blocking property returns True, it'll add the lanes it Belon GS to each action have a lane or multiple lanes they is identified with, and they would only block other actions which Belo Ng to those lanes. As an example, Attack Player belongs in the Action Lane, Move to Goal belongs in the movement Lane, and Build Ladder Belon GS in both since the unit must stand still and cannot attack while building. Then we order these items, and if they execute they would block subsequent actions appropriately.

Example implementation

Now that we've gone over the theory, it's useful to step through a practical implementation. First let's setup our Action List and action Items. For Action Items I like to decouple implementation, so let's make an interface.

Example implementation of the Iactionitem for the Breakdoor Action Item.

For the Action list itself we can use a simple List. Then we load it up with the iactionitems.

After this, we setup a method that iterates over the list every frame. Remember We also has to handle blocking.

Things get a bit more complicated if you want to the use action lanes. In this case we define Action Lanes as a bitfield and then modify the Iactionitem interface.

Then we modify the iterator to take these lanes into account. Action Items would be skipped over if their lane was blocked, but would otherwise check as normal. If all lanes is blocked then we break out of the The loop.

Conclusion

So that's a lot to take in. While coding the other day Frankie asked me to summarize my learnings. Thinking about it, there were a few key takeaways for me.

Action lists is easier to setup and maintain then small transition-based state systems.

They model a recognizable priority system.

There is a few ways they can be extended to handle expanded functionality.

As with anything in coding, there are often no best solution. It's important to keep a large variety of coding tools, our toolbox so, we can pick the right one for the problem a T hand. Action Lists turned out to being perfect for King Randall ' s Party. Perhaps they would be is the right solution for your project? (Source:gamedev)

We'll start by collecting AI productions on action lists and behavior trees.