Game Object Script to store information, then carry out actions...

Sorry for the tortuous title but it's hard to summarise what I want - easy to describe.

I have a game object that checks six variables and depending on which variable is set, an action is carried out.

Each variable can be set from other game object scripts. However, there is a possibility that more than one of these variables can be set at once, which would cause the the game to behave unpredicatably.

Would I'd like to do is somehow remember the variable states, and then have the actions carried out sequentially, resetting each variable after the action.

is this doable? Is it normal? Is there a standard code for this kind of thing?

By the way these variables aren't flags, but carry important data.

Cheers
/jason

 

You'll have to store these values in an array as they come in then. The you will have to work with that array
to determine which value to use.

 

As Koyima said, you'd have to change the structure of your system.

I'd create an arraylist of instructions. Then I'd have an AddInstruction() method that added a new instruction to the list. In the Update method, I would loop through the instructions, carrying them out in order, then clearing the arraylist.

I'd probably use an enum for the instructions, but a string would work, too.

 

Thanks guys. I was thinking of an array. Can you point me to any examples? It will take a few seconds to carry out one instrucion, after which, the next in the list can be carried out. So I suppose as soon as the action begins, it can be wiped from the list.

 

Not off the top of my head.

 

Here's a simple example. I queue up 'actions' (these are things that might get done complexly), in a FIFO (first in first out) queue. On update I get the next action, and act on it until it's complete. All my actions follow the IAction interface for ease.

Code (csharp):

1.  
2. public class SomeBehaviour : MonoBehaviour
3. {
4.  
5.     private IAction _currentAction;
6.     private System.Collections.Generic.Queue<IAction> _queue = new System.Collections.Generic.Queue<IAction>();
7.  
8.     public void AddInstruction(IAction inst)
9.     {
10.         _queue.Enqueue(inst);
11.     }
12.  
13.     void Update()
14.     {
15.         if(_currentAction == null)
16.         {
17.             if(_queue.Count == 0) return;
18.             _currentAction = _queue.Dequeue();
19.         }
20.        
21.         _currentAction.Tick();
22.         if(_currentAction.Complete) _currentAction = null;
23.     }
24.  
25. }
26.  
27. public interface IAction
28. {
29.     bool Complete { get; }
30.     void Tick();
31. }
32.  

 

Excellent. Thank you for that example. I see you're using C#, whereas up to now I have been using UnityScript, although it seems straightforward enough to follow. I notice a lot of the more advanced programmers and examples in scripting are in C#,

/Jason

 

Why do you use leading underscores, as in _queue and _currentAction?

 

It's just my coding practice that I picked up when I started programming.

Private fields get leading underscores. This way when I'm reading my code I can know, just from reading, that I'm accessing a private field local to this object.

I've seen other practices from other people... this one just stands out a lot to me visually.

_name - local private field
name - variable in the local scope
Name - interface member name (method/class/struct/property name)
__name - protected field (very seldom used, I consider them smelly)
IName - interface

single character vars - variable in local scope representing numbers, and ONLY numbers, for math. This way my math looks like algebra, which I prefer, coming from a math background.

all multi-word names use camel-notation: ThisIsMyName.

all my fields are private/protected, and I use property get/sets to access them. Except for in unity when writing a MonoBehaviour. Because they require public fields for the inspector... I will use public fields ONLY there, to which I still give a leading underscore.

I also always use 'this' if accessing a local property or method (but not private field as the underscore denotes that). This way I know that I'm accessing a local interface member as opposed to a class/struct identifier (both of which get uppercase leading characters)

 

Thanks for explaining. It's good to have some ground rules like that - good habit to get into early on.