State Machine: Best way?
-
@Deeeds I think so.
For the sake of organization, I hinted that you should separately figure out the attributes and then separately calculate what they mean.
If you are looking for efficiency, you should just trash the attributes and the ifs, so as soon as you figure out a state you can just execute it. This would be confusing for you, though, and it would be hard to add on to.
-
@GameCRAZY Please speak to me like I'm stupid, ignorant and childishly impulsive... and have a short attention span, understand little and know even less.
I'm not good with hints. Literals are much easier ;)
@Deeeds Okay, but do you understand what I mean?
-
@Deeeds Okay, but do you understand what I mean?
@GameCRAZY No. I'm not good with hints.
-
One option would be with the attributes:
(insert some type of trigger, or a load of behaviors)
Set attribute__state(insert some type of trigger, or a load of behaviors)
Get attribute__state
If = 0...
If = 1...
If = 2...
Another option would be without this defining type of thing:
(insert some type of trigger, or a load of behaviors)
(do the same thing you would do if the attribute would be equal to 0)(insert some type of trigger, or a load of behaviors)
(do the same thing you would do if the attribute would be equal to 1)...
You can create the illusion that you are using states, or even think of everything in terms of states, but you would not actually be creating these states. You would just execute them exactly when you would usually.
If the user is switching some type of dial, just manually change what the user is doing each time, and don't actually use attributes.
I would also consider something like this:
(do the same thing you would do if the attribute would be equal to 0) (behavior off)
(do the same thing you would do if the attribute would be equal to 1) (behavior off)
(insert some type of trigger, or a load of behaviors)
(behavior on__state 0)(insert some type of trigger, or a load of behaviors)
(behavior on__state 1)...
You get the idea.
I would consider all of these setups for different situations.
-
One option would be with the attributes:
(insert some type of trigger, or a load of behaviors)
Set attribute__state(insert some type of trigger, or a load of behaviors)
Get attribute__state
If = 0...
If = 1...
If = 2...
Another option would be without this defining type of thing:
(insert some type of trigger, or a load of behaviors)
(do the same thing you would do if the attribute would be equal to 0)(insert some type of trigger, or a load of behaviors)
(do the same thing you would do if the attribute would be equal to 1)...
You can create the illusion that you are using states, or even think of everything in terms of states, but you would not actually be creating these states. You would just execute them exactly when you would usually.
If the user is switching some type of dial, just manually change what the user is doing each time, and don't actually use attributes.
I would also consider something like this:
(do the same thing you would do if the attribute would be equal to 0) (behavior off)
(do the same thing you would do if the attribute would be equal to 1) (behavior off)
(insert some type of trigger, or a load of behaviors)
(behavior on__state 0)(insert some type of trigger, or a load of behaviors)
(behavior on__state 1)...
You get the idea.
I would consider all of these setups for different situations.
-
@GameCRAZY Now I know why your hints were making no sense.
This makes even less sense.
I don't have a quarter of the knowledge or insights into hyperPad you're assuming I do.
@Deeeds What is it you are not understanding?
There is nothing crazy going on here, whatsoever.
Do you know how attributes work at all?In the 2nd example, I am not really making any states or anything. I am just skipping straight to the action.
In the 3rd example, I am just turning state behaviors on and off.
-
@Deeeds What is it you are not understanding?
There is nothing crazy going on here, whatsoever.
Do you know how attributes work at all?In the 2nd example, I am not really making any states or anything. I am just skipping straight to the action.
In the 3rd example, I am just turning state behaviors on and off.
-
@GameCRAZY No, I don't think I know how Attributes work, at all. I thought I did, until I read your answer above... then I figured I don't know what I don't know.
@Deeeds Attributes might as well work like Labels, you know how those work right? You can set them to a value or text and you can get them. First you have to actually give your character an attribute, which works similarly to adding a Tag to an object. When setting/getting an attribute, you should be able to enter the key name for the attribute, but I’d just press the Dynamic and change it to the other one. I can try send screenshots if you need.
-
@Deeeds Attributes might as well work like Labels, you know how those work right? You can set them to a value or text and you can get them. First you have to actually give your character an attribute, which works similarly to adding a Tag to an object. When setting/getting an attribute, you should be able to enter the key name for the attribute, but I’d just press the Dynamic and change it to the other one. I can try send screenshots if you need.
-
@Aidan-Oxley @GameCRAZY have either of you tried using Attributes lately?
I just created 2 different ones, and then searched for them in a getter, in the predefined list.
But that list is empty. So something's broken.
@Deeeds, is the behaviour selecting the same object that has the attributes? And also, you have to actually set the attribute through the editor for it to show up on the list, not through a behaviour; it's like setting a tag.
I think GameCRAZY is describing if you want something to happen immediately when the state changes, but I'm assuming you're setting the state for later use. I think set/get attribute with a bunch of ifs is the best way for this, until we get something like switch statements.
-
@Deeeds, is the behaviour selecting the same object that has the attributes? And also, you have to actually set the attribute through the editor for it to show up on the list, not through a behaviour; it's like setting a tag.
I think GameCRAZY is describing if you want something to happen immediately when the state changes, but I'm assuming you're setting the state for later use. I think set/get attribute with a bunch of ifs is the best way for this, until we get something like switch statements.
-
@Jack8680 Do you mean the Scene Editor setting of attributes is required before they're initiated in the Behaviour Editor, where they're created, edited and utilised?
If so... WHY?
@Deeeds Attributes work by setting a certain attribute of a certain object, each attribute of that object is given a key, which is then used to get and set Attributes. You can either use Predefined keys, or you can use dynamic keys where instead of selecting a key you type it in (this allows for the creating of new keys while the project is running).
-
@Deeeds Attributes work by setting a certain attribute of a certain object, each attribute of that object is given a key, which is then used to get and set Attributes. You can either use Predefined keys, or you can use dynamic keys where instead of selecting a key you type it in (this allows for the creating of new keys while the project is running).
-
@Aidan-Oxley Yes, I got all that, the first 3 times.
The problem is... they're not working in the Behaviour Editor.
@Deeeds How are they not working? First you actually have to give the object an attribute key and default value. Best way to do this would be to just find the attributes tab when selecting the object in the scene editor, then press the plus button. After creating an attribute, if you select the object in get or set attribute, the attribute should come up in the Predefined list.
-
@Deeeds How are they not working? First you actually have to give the object an attribute key and default value. Best way to do this would be to just find the attributes tab when selecting the object in the scene editor, then press the plus button. After creating an attribute, if you select the object in get or set attribute, the attribute should come up in the Predefined list.
@Aidan-Oxley Why in the Scene Editor?
They have no use in the Scene Editor.
Why this extra round trip out to the Scene Editor to "create" something that's already been created?
What am I missing from understanding what these things are?
-
@Aidan-Oxley Why in the Scene Editor?
They have no use in the Scene Editor.
Why this extra round trip out to the Scene Editor to "create" something that's already been created?
What am I missing from understanding what these things are?
@Deeeds for predefined, create them in the scene editor, for dynamic creat them in the behavior.
-
@Aidan-Oxley Why in the Scene Editor?
They have no use in the Scene Editor.
Why this extra round trip out to the Scene Editor to "create" something that's already been created?
What am I missing from understanding what these things are?
@Deeeds said in State Machine: Best way?:
@Aidan-Oxley Why in the Scene Editor?
They have no use in the Scene Editor.
Why this extra round trip out to the Scene Editor to "create" something that's already been created?
What am I missing from understanding what these things are?
You do it in the scene editor because you're giving a specified object it's own attribute or property.
Think of it like how each object has it's own mass. You can adjust the mass right from the main editor with out having to use a behaviour. The attributes are designed so you can do this same quick change with any custom parameter you create.For example, say you create an attribute that defines the difficulty of an enemy. You can duplicate this enemy, and quickly change the difficulty with out going into the behaviours and changing anything there.
The ones you create inside the behaviour editor under "dynamic" are generated at runtime.
-
@Deeeds said in State Machine: Best way?:
@Aidan-Oxley Why in the Scene Editor?
They have no use in the Scene Editor.
Why this extra round trip out to the Scene Editor to "create" something that's already been created?
What am I missing from understanding what these things are?
You do it in the scene editor because you're giving a specified object it's own attribute or property.
Think of it like how each object has it's own mass. You can adjust the mass right from the main editor with out having to use a behaviour. The attributes are designed so you can do this same quick change with any custom parameter you create.For example, say you create an attribute that defines the difficulty of an enemy. You can duplicate this enemy, and quickly change the difficulty with out going into the behaviours and changing anything there.
The ones you create inside the behaviour editor under "dynamic" are generated at runtime.
@Murtaza Yes, I get the functionality, the purpose and their reasoning for existence.
What I don't understand is the limited design of their operability.
If I'm in the Behaviour Editor, where I must be to initially create and attach an attribute to an object, why can't I finish its creation and setting up, utterly, thoroughly and completely in the Behaviour Editor?
Why do I need to roundtrip out to the Scene Editor to complete the process? This is arbitrary restriction, and not necessary for ANY OTHER property, all of which can be adjusted inside the Behaviour Editor.
Take your Mass example, as an example.
I don't need to go out to the Scene Editor in order to access that property, I can do it in the Behaviour Editor with a Get and Set of the Mass.
I think the problem is the conflation of Set attribute with Create Attribute. For the sake of clarity, ease of use, separation of tasks and a sane workflow etc... perhaps there should be a "Create Attribute" behaviour and Set and Get.
-
@Murtaza Yes, I get the functionality, the purpose and their reasoning for existence.
What I don't understand is the limited design of their operability.
If I'm in the Behaviour Editor, where I must be to initially create and attach an attribute to an object, why can't I finish its creation and setting up, utterly, thoroughly and completely in the Behaviour Editor?
Why do I need to roundtrip out to the Scene Editor to complete the process? This is arbitrary restriction, and not necessary for ANY OTHER property, all of which can be adjusted inside the Behaviour Editor.
Take your Mass example, as an example.
I don't need to go out to the Scene Editor in order to access that property, I can do it in the Behaviour Editor with a Get and Set of the Mass.
I think the problem is the conflation of Set attribute with Create Attribute. For the sake of clarity, ease of use, separation of tasks and a sane workflow etc... perhaps there should be a "Create Attribute" behaviour and Set and Get.
@Deeeds If you use Set Attribute with a dynamic key and give it a name, when the behaviour is run and that key doesn’t exist yet it, will create a new attribute with that key. Predefined is just another option for games where you don’t want to dynamically add new keys, but you just want the key to be there from the start.
-
@Murtaza Yes, I get the functionality, the purpose and their reasoning for existence.
What I don't understand is the limited design of their operability.
If I'm in the Behaviour Editor, where I must be to initially create and attach an attribute to an object, why can't I finish its creation and setting up, utterly, thoroughly and completely in the Behaviour Editor?
Why do I need to roundtrip out to the Scene Editor to complete the process? This is arbitrary restriction, and not necessary for ANY OTHER property, all of which can be adjusted inside the Behaviour Editor.
Take your Mass example, as an example.
I don't need to go out to the Scene Editor in order to access that property, I can do it in the Behaviour Editor with a Get and Set of the Mass.
I think the problem is the conflation of Set attribute with Create Attribute. For the sake of clarity, ease of use, separation of tasks and a sane workflow etc... perhaps there should be a "Create Attribute" behaviour and Set and Get.
@Deeeds There is no problem. None.
Stop making stuff out of nothing.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login