Any plans to include Enum as an instance var type?

Discussion and feedback on Construct 2

Post » Mon Jul 01, 2013 6:24 pm

Let's say you had an instance variable called state that can represent three states: HIDING, CHASING, or ATTACKING. Without Enums, the best approach is to use a Number for this variable, and then declare global constants in the following manner: HIDING = 0, CHASING = 1, ATTACKING = 2. Now you can use these constants in your code with full control over them in case things were to change.

That works fine for one object, but now consider you have 15 different objects with different state values. That's a lot of global constants and can make things very unclear in the code. This issue could be eliminated if we had an Enum instance variable type. With an Enum, every state would be self-contained and it could be easily referenced in the code.

Is this planned for a future release? If not, why not? Instance Enums would be handy ex. intelligent enemies (hiding, chasing...), characteristics (sharp, smooth), etc.
Image
B
10
S
3
G
2
Posts: 196
Reputation: 2,053

Post » Mon Jul 01, 2013 6:28 pm

What if we allowed constant instance variables? Then you could have Player.ATTACKING, Player.CHASING as well as Enemy.ATTACKING, Enemy.CHASING etc. without spamming your global variables.

Alternatively you can just use strings like "attacking", "chasing", "hiding" etc. Javascript takes this approach, and while it's susceptible to typos, it works surprisingly well and has the added convenience you don't need to do anything to define a new enum.
Scirra Founder
B
403
S
238
G
89
Posts: 24,653
Reputation: 196,143

Post » Mon Jul 01, 2013 9:16 pm

Constant instance variables (or 'instance constants'? :p) would be terrific in their own right. Even so, I think traditional 'Enums', for me, excel at 2 important things that make them especially worthwhile compared to other approaches:

1. Forcing a single choice. An enemy can't hide and attack at the same time. In code, instead of having to specify a priority order, one could simply select 'State.HIDE' from the list and call it good - super clear and less prone to buggy logic - like using a Boolean instead of isTrue and isFalse vars (hopefully no one has ever done that). Plus, the idea of a neat little drop-down in the C2 user interface when testing against an Enum really excites me.

2. Less prone to typos. True that Javascript enums are just strings, but I guess there's also the possibility of using the Object.freeze method to seal a property into an effective Enum, eliminating the typo issue. I feel like in many cases in JS games, this would be more desirable than using dynamic JS enums. Likewise, in C2 having an Enum in many cases would be preferred to using strings or constants.

All in all, I think Enums would be an awesome addition to have down the line, but I see why this wouldn't be an immediate priority because there are a handful of alternate approaches.Dalal2013-07-01 21:19:58
Image
B
10
S
3
G
2
Posts: 196
Reputation: 2,053

Post » Sun Nov 23, 2014 10:21 am

Ashley wrote:What if we allowed constant instance variables? Then you could have Player.ATTACKING, Player.CHASING as well as Enemy.ATTACKING, Enemy.CHASING etc. without spamming your global variables.

Alternatively you can just use strings like "attacking", "chasing", "hiding" etc. Javascript takes this approach, and while it's susceptible to typos, it works surprisingly well and has the added convenience you don't need to do anything to define a new enum.


Hi Ashley.

Yes you can use strings, but enums would be really nice because you can set them with integer values, and it is nice to code with enums, because it is much easier to read and you make fewer mistakes.

So I would love to see enums in construct.
And codecompletion on function names, so you dont make typing mistakes with function names :-)
B
5
S
1
Posts: 59
Reputation: 493


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 6 guests