Hot answers tagged

10

Nearly all AI systems out there are "hive mind" already. Consider, the AI knows where every unit is, what every unit can see, what each unit is doing and has control over their actions. Most any RTS AI is already functioning like a hive mind. You may be over thinking your implementation, since it's already very common. Search around for AIs that are ...


7

I don't have an answer to your specific question, mostly because I don't believe there is an answer. The simplest application of fuzzy logic in an FSM would be allowing multiple states, rather than a single state, and using probability to determine behavior. In this light, it's a question of whether or not an extra level of AI sophistication is appropriate....


4

If you call coroutines this way they will be executed in order, one after another. You should fire them up with StartCoroutine(Aiming()); public IEnumerator Aiming() { yield return StartCoroutine(LoadBow()); yield return StartCoroutine(DrawBow()); aimStates = AimStates.Aim; } ...


4

Instead of having the FSM pointing to the character instance straight on, you could have it pointing to a unique ID representing that character. The characters would be registered in a singleton manager class. When the character dies, you simply mark it as deceased (in the singleton manager). Later on, when (and if) the FSM reaches a state in which it ...


4

Whether you need a publish/subscribe pattern or not depends on when your data changes. If it does so during the lifetime of the interested objects, and if those objects need to know (and react) immediately, then publish/subscribe certainly is the right thing to do. If you do not need immediate notification, just store a direct or indirect reference to the ...


4

You have a couple choices here, you just haven't realized it yet from trying to shove round things into square holes =) 1) You haven't really defined all your states yet. Flee and Fire are independent states, adding a FleeAndFire state is the traditional way and well respected. By specializing states like this you get great control over what your actions ...


4

Animation clips are best described in plain-old-data, as you've done in your first XML snippet. You can make this by hand, or export to it from an art package. Either way, you're probably going to want to create a pipeline that takes it from a human-readable intermediate format like XML and puts it into something that's nice and quick to load. The next step ...


3

Add a method public IEnemyState CreatePlayerReactState() to the Enemy class. For one enemy, have it return a DefenseState, for the other enemy, return an AttackState. You can implement that by creating two subclasses of Enemy with different implementations of that method, or by adding a private variable to Enemy which says how it reacts to the player. Then, ...


2

I've always done it with function pointers and ints or enums for states. Granted, the state machines themselves are written in native code. Why do you want to make a language to specify your state machines?


2

You could use the observer pattern. The observer-pattern in a nutshell: There are Observers (like your AI enemies) and Observables (the objects they target) Each Observer can register itself to one or more Observables Each Observable keeps a list of those Observers who registred on it When an important event happens in an Observable (like its death or its ...


2

One option is as Nathan's comment, just identify when and where the values need to be cleaned up and do it manually there. If you implement callback on the edges of a FSM rather than just the nodes, meaning chunks of code that are run on transition, then you can have a specific implementation of an edge from any of the Tree states to Idle allowing the idle ...


2

The character should have a single state machine. Animations should be controlled by the character state so they don't need their own character-specific state machine except as part of a generic animation system. Status variables (health, ammo, invincibility timer, inventory, etc) are part of deciding which state to transition to but not state machines in ...


2

For reference: I found a thread where somebody wants to adapt FSM behaviour into an BT as well, that contains some hints and a simple example in the first posts of how to do it. But I don't think you want to use it for things like this statue. Like you see in your given example and the graph you draw to show it: It is extremly simple to design interactions ...


1

I would probably try and keep everything that changes the agent's attributes with the agent (decreaseHealth) and split the involved behaviour into several FSMs (animation, combat, etc). IE: the agent has a method getHit that is somehow called when the agent gets hit (by the physics system, other agents, fireballs, etc). Other FSMs can register to be ...


1

In my opinion it is perfectly fine to model the behavior with a FSM. Oftentimes we create inferior models with cluttered if-statements like suggested in the comments. But the FSM is not the problem. To me it seems like you are experiencing jittering movement because your AI ship is always just at the border between "too far" and "close enough". Think about ...


1

Since you asked to expand on my first part, here it is. Currently, under states you save all your states, regardless of the relation between them, but we can clearly see that you can group them up to make it more organized. So, this: StateComponent = { states = { walking_left = {set_animation("walking_left")}, walking_right = {...


1

I think that you should keep each individual "state" separate. For instance, if you have an enemy that will chase after the player if it sees the player, it will start following and running. If you had an enemy that only tails the player, it will start following, but not running. The code might look like this in pseudocode: class enemy{ private: bool ...


1

Alternatively, you could try to restructure your code so there are a few different State categories that are set independently, like Stance, Movement, IsDazed, etc. Also, you could make a State/SubState system where the SubState provides more detail on top of the general State.


1

I'd organise it similarly to what you described. Pseudo-code: enum totalStates = {STATE_1, STATE_2, ..., STATE_N}; totalStates state = totalStates.STATE_1; void Update() { switch (state) { case totalStates.STATE_1: // update STATE_1 break; // ... other states ... } } bool initState(totalStates newState)...


1

I would suggest creating a new class just for holding the data if you are sure that the data belongs to multiple classes. Otherwise you can face tight coupling issues.


1

Unless there's a specific reason you'd need (want) to process the data in a State you should probably stick to Ashley's own EntitySystem. Without you yourself expanding the functionality of State, EntitySystems are for sure more flexible, as in you can tell it to not process the system, you can do something when it's added / removed etc. Also the ...


1

When designing AI, you usually have behaviour for every possible situation while the character is alive. Even when they are just standing around, you usually want them to play some kind of animation, and of course wait for triggers to transition to another state. In many cases, the final (accepting) state defines the logic of the character dying (or the ...


1

You could set a boolean for example to false before yield and then after the time had passed set it back to true and then just use if statement to check if the boolean is true/false. What about efficiency, I think there's not much of a difference. From what I understand the delay from coroutine affects only something you change before and after the delay so ...


1

The main difference is that with classes you can store information that only applies to that state in the class itself, whereas with function pointers you need to store it "somewhere else", hopefully in a closure or possibly in the main object using an associative array/map/dictionary. In a programming language with closure support the difference is much ...


1

If you built an FSM for the player entity you should have at least 2 different states or more. With only one you lose the point to have a FSM. Also you'd better think to states as conditions/moods/actions that the entity is actually doing. With this I mean that a state is a collection of properties values, while blinded and paralyzed are simply boolean ...


1

What if implementing the HSM with a stack of states for each entity you have in the game? public final class StateStack { private List<State> states = new List<State>(); public void PushState(State newState) { states.Add(newState); } public State PopState() { State topmostState = null; if (states.Count &...


1

Good question, but really the answer is that FSMs are pretty non-scalable by design. You can consider your question arising from the fact that a FSM is by nature ad-hoc and hard-codish. Usually a FSM is chosen to describe a simple and specific behavior. If you wish to do something more scalable alternative methods are going to be favorable. I'd say this is ...


1

Most games which are more complex use a scripting language to script world interactions. Certain situations in the game can trigger scripted events (interacting with NPCs, killing a certain enemy, stepping into a certain area, picking up an item...). When such an event is triggered, a function from a script file is executed, which in turn calls back some ...


1

I would break something like this up into slots and actions. For example, you would have a legs slot and an arms slot for your robot. Different actions take up different slots, so you can layer actions on top of each other. Here's a simple example: Slot | Action -----|------- Head | Shoot Arms | Shoot Legs | Flee As you can see, the Shoot action takes ...


Only top voted, non community-wiki answers of a minimum length are eligible