Idea discussion: List, enums & more for built-in Functions

1 favourites
From the Asset Store
Template for scrollable list, fully documented in comment and video
  • you could do MyEnum.Choice

    piranha305 Yes, that's what I thought. The dropdown list as on OPs screenshot will not work, as you can't enter expressions into it.

    So you type in "MyEnum." followed by dot into any parameter field in any dialog, and the list of values will drop down. This will be consistent with how other expressions work in C3.

    Also, what will happen if the result of the expression is an invalid number (not member of the enum list), or infinity/NaN/string etc.?

  • That depends you can have a constant value that means none, normally -1 or just convert it to default value and log a warning? all those little things have to fleshed out? also what would something like this really buy you? the same effect can kinda be accomplished with an empty object type and instance variables?

    it would be nice to be able to reference the enum as the integer value but also the name, and there should probably be a set of ACES around handling such a structure? another question is can this data be modified at runtime? or is it just a static list of values?

    there is also another idea for this since they are pretty similar (just where) maybe they could be merged construct3.ideas.aha.io/ideas/C3-I-207

  • FWIW I think this is actually a pretty complex feature to implement which will involve a lot of work, and meanwhile there are already what I'd consider to be decent workarounds. If we go as far as "first class enums" where it's added as a general data type, some of the complications I can foresee are:

    • Creating some kind of enum editor which creates a new enum type
    • Creating some kind of convenient place to store enums in a project (would it be part of the Project Bar for example?)
    • Much of the engine assumes types are a fixed list of "number" and "string" (and maybe "boolean" in some places too) - so a lot of code across the editor and engine would need upgrading to manage a variable list of types that depends on the particular project at hand
    • People will certainly want to convert both from enum to value (e.g. enum to string) and value to enum (e.g. string to enum) and use expressions, otherwise it's worse than the workarounds - but then how does that look? There would need to be more expression features to handle this, and possibly more UI upgrades to the editor to handle this when entering parameters and such
    • As with most event sheet accessible features, there will need to be ways to add, edit, delete, replace and refactor enums - e.g. suppose you want to replace enum1 with enum2, how does that work? How do you make sure events stay valid when these kinds of references change?

    Meanwhile what I'd recommend for now is adding an object with a bunch of instance variables. For example if you add a sprite called "ColorEnum" with instance variables RED, BLUE and GREEN (corresponding to the strings "red", "blue" and "green"), you can do things like call a function passing ColorEnum.GREEN. They can be extended at any time, the values can be edited easily, renaming already automatically updates all references in the event sheet, you can still use expressions, you can use the existing "replace object" mechanism to swap it for something else, and there's no need for all the time-consuming design, implementation, user interface updates, engine upgrades, on-going maintenance, and general edge-case problem solving associated with a significant new feature.

    So I have to ask, compared to that workaround, is it really worth it? I'd argue the opportunity cost is too high, and with our limited development resources we'd be better off working on something else, or perhaps adding minor features to smooth the workflow of the workaround case (e.g. perhaps by adding constant instance variables).

  • Ashley I agree with you, you can get kinda close parity with enum behavior by having an empty plugin like sprite and adding instance variable, not really sure how constant instance variables would work unless the object in question is a singleton. (if you have multiple instances, you would have to pick one to get its corresponding value). another thing that is also concerning most of the existing plugin come with extra functionality which might not be needed. if the work around is the preferred choice, it should be its own object type (not associated with sprite, which has has rendering/world properties etc), that should also allow for modifications if you wanted to expand upon it in the future. kinda of like the journey of the function plugin, it was a separate plugin for a long time until it became a first class citizen of then engine.

  • kinda of like the journey of the function plugin, it was a separate plugin for a long time until it became a first class citizen of then engine.

    I'd really want to avoid going through that again. Replacing a major feature with a different and not entirely compatible one is a painful transition to go through for both us and many users. It also leaves us supporting both indefinitely, as there are always too many remaining projects using the old feature to justify removing it. It's much better to get it right first time wherever possible. The only reason we didn't with functions was it was designed in a hurry in the early years of C2 with many shortcuts deliberately taken, and the replacement was so much better (and so many people were asking for improvements) that it justified all the pain and awkwardness of going through a replacement.

  • > kinda of like the journey of the function plugin, it was a separate plugin for a long time until it became a first class citizen of then engine.

    I'd really want to avoid going through that again. Replacing a major feature with a different and not entirely compatible one is a painful transition to go through for both us and many users. It also leaves us supporting both indefinitely, as there are always too many remaining projects using the old feature to justify removing it. It's much better to get it right first time wherever possible. The only reason we didn't with functions was it was designed in a hurry in the early years of C2 with many shortcuts deliberately taken, and the replacement was so much better (and so many people were asking for improvements) that it justified all the pain and awkwardness of going through a replacement.

    We all know this proposal about the global sprite with instance vars acting as an enum (by all I mean, people working with Construct for quite some time now) but as you mentioned it is a workaround. It works very fine, and sometimes is enough, but how about new user experience? This isn't something new users can get that easily, and when I first started Rhythmy over two years ago now (as an example) I had no idea this could be done and just assumed that enums/lists just weren't a thing (and in some way, they're not as this is a workaround

    if the work around is the preferred choice, it should be its own object type (not associated with sprite, which has has rendering/world properties etc)

    If my proposal would require too much work, maybe this could be a solution, because it makes no sense to make an empty global "sprite" to make a static enum? (and for new user experience, even less)

    But maybe looking forward to an official solution like this, that won't require a massive rewrite of the engine as you mentioned, because that definitely won't be possible with the current ressources you guys have, maybe this can be a solution that won't require an insane amount of work, and improve overall workflow.

    And that way, you won't be "erasing" or forcing replacement for people that were using the old workaround, because as it's a workaround, it would still be possible, but you're giving the opportunity to have it supported more "officially"

  • Is there anything actually wrong with just using instance variables? If not, given there's 10 years+ of other features on the suggestion platform, isn't our time better spent on something else? That's what I mean by opportunity cost.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Is there anything actually wrong with just using instance variables? If not, given there's 10 years+ of other features on the suggestion platform, isn't our time better spent on something else? That's what I mean by opportunity cost.

    Well that's up to you to decide, my goal here was to make a talk on having this kind of variable type in functions, to have a better workflow, but you said it will require a major rewrite of the engine, so I guess there's no way this is going to happen. But the fact that, this workaround is to me, pretty much unknown is an issue, since this is a very important of regular coding, and there's no official plugin supporting it right now, which is hard for new user experience (if you get my point)

  • It's not a hard no, it's just that with limited resources and hundreds of feature requests, it's important to get priorities right. And so far it seems that maybe just a tutorial or something pointing out that you can do this might suffice.

    I'm not sure it even deserves its own plugin type anyway. For example if you have an Enemies family, it seems convenient to have the EnemyType enum as instance variables on Enemies itself, so you can do things like Enemies.Monster and Enemies.Alien instead of having to make a whole separate plugin type for that (and a plugin that, as far as I can tell, does absolutely nothing except enable instance variables, which is confusing in its own way).

  • There is in fact such plugin - Globals:

    construct.net/en/forum/extending-construct-2/addons-29/plugin-globals-120736

    It's basically just an empty object for storing instance variables. It was made as an alternative to global variables, but can also be used for making enum lists.

  • dop2000 you beat me to it... I was just going to suggest having Empty Objects for things just like that.

    Although the one thing I like about enums is being able to loop through them dynamically with a 'For Each' member of the list. Currently there is no: 'For Each Sprite instance variable'

  • jobel I just found that chadorireborn's plugin collection includes full version of Globals plugin. It does have "For each variable" event, and "Set variable by index" action.

  • For me for Globals, I create a JSON object and then add objects and values to that. You can create 'globals' on the fly using this. The main issue is that there is no centralized 'list' of all the globals (unless you load them via file and don't add more entries during runtime.)

  • dop2000 good to know! although I'm always nervous using 3rd party plugs. I already use some of Rex's and sometimes I half-expect them to break! If I had time I'd learn to make them myself...but there's not enough time in the day, just working on games is incredibly time consuming nvm tools...

    Mikal that's great. Instead of JSON I use Rex's CSV plugin to basically make a database that I globally update throughout the game. This allows me to make any kind of "perpetual" world that restores itself between layouts. It's pretty great.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)