Static Variables

I had made the mistake of trying to use a static variable for something in the RPG course with SO’s. Does the same thing apply here? Do these SM’s share the same instance or something?

The reason I ask is I am making a Taunt state for the enemies. I want them to taunt X number of times when the player dies and then return to the idle state. So I have my checks where we set the idle state for the player death here. So I would set a static int to keep track of the taunts performed and once it reaches a certain point I just release them back to the Idle state as usual and the next passby on checking if the player is in chase range I return false.

The problem I have found is that if two enemies down me either both enemies taunt me once each or one of them sneaks in two taunts while the other is finishing an attack animation. I assume the only explanation for this is what I feared… Shared script instance. I’ve tried having the static in the BaseState (where BOTH my chase range and attack range checks are… I like the attack check there rather than in chasing in case I want to do a ranged enemy that fires WITHOUT chasing). I’ve also tried putting the static in the EnemyStateMachine as a public.

I’m also sure you’ll tell me an easier way to do this. I suppose in my Taunt state I can just calculate the clip size times the amount of taunts I want and decrement timer in Tick that exits when it should be done. Just seemed more straightforward to do it this way, especially since I’d like to be able to use the Taunt state just for random taunts from enemies in other situations.

I’m not sure I follow your state progression, but a static variable is shared. The taunt count is one variable shared by all enemies. If one taunts and then sets the count, it is set for all enemies. So, if you want 2 taunts, then enemy 1 will taunt once and set the count to 1, and enemy 2 will taunt once and add to that count to make it 2. Taunts done. If enemy 1 is still attacking, then enemy 2 will do 2 taunts and set it twice.

Yeah it seems like that would be the only explanation. Any ideas on how I can have each individual enemy engaged do the taunt state twice and then settle back into the Idle state?

This all started with me just wanting to check if they had done a taunt with a bool. Then set that bool to true so after that taunt and we recheck for attack range we skip the taunt and then perpetually will be in idle. Problem there is that the bool goes bye bye after you enter the Taunt state :confused:

Disclaimer: I haven’t done this course yet (I have it, but I’ve been procrastinating) so I’m not 100% sure what’s happening where.

You don’t want to use a static variable. I suspect you’d want a class on the enemy that you can use as a ‘blackboard’ where you can hold information that is accessible from all states. Then store the taunt ‘state’ in there. This will give each enemy it’s own set of data it can check to make decisions with. Someone that knows the course (like @Brian_Trotter) would be better at answering this, though. I’m not sure if something like this was introduced in the course.

1 Like

Interesting. That thought had crossed my mind actually. Glad that is a thing. I appreciate it!

YEP! The most ridiculous class I’ve ever written to just hold an int. But it works. I did serialize it so each enemy can have their own customizable amount of taunts (and I went with decrementing the amount, rather than counting up to a limit). I guess I could actually store a taunt name from the animator there as well to play so they could be different.

Eventually that script can turn into a more realistic class for enemies in general. Ironically, wanting Scriptable Objects for enemy behavior would break the point of this, so it will have to be separate from that but could also serve as a blackboard for it as well!

You could instantiate the ScriptableObject for each enemy. With instantiation, the SO gets it’s own playground, so to speak (except statics, statics are available to all instances, period).

I often make a Blackboard type class for just this purpose… Hint: Dictionary<string, object> makes a fantastic blackboard. The string is the key, and you cast the object as needed, just be sure to cast what it was stored as or it might break.

1 Like

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms