Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.


Full-On code-less Menu systems

the first thing that popped in my head is a full-on menu-system. let me try to clarify it using the rules:

1. Currently, there's 100 ways of coding your own menu, even if it's a simple toggle or transition.
2. it's not necessarily a problem, but it's the opposite of what Construct is advertising: no code.
3. It would make the basic steps of getting the menu's and the logic behind them up and running without even getting started. this is especially important for new players or pro's who've made 100 apps already. Construct already provides the logic behind basic animations and effects like switching layout and it might be easily implemented similar to things like the platform behavior.

it would be nice if a global UI and the likes are more simplified and code-less this way. if only, like the platform behavior, to quickly prototype. it is after all exactly what Construct wants right?

I Know this is a subject with wide variations, but i'm talking about the basic menu systems.
opening and closing a small dialog box would be the tip in my sample. 

i'd like to have the option to insert menu items like how you create new sprites etc, but instead add the properties you'd expect from a very basic menu like layout transition dropdown. 
it's just for prototyping but it would probably save quite some time (since it just works by default)
And it's a lot easier for the new users too.
Very simple apps could potentially use the basic menu's as a permanent use similar to the platform behavior which you'd write yourself for the final version.
It also saves you some code which is then a little more organized. (again, useful for new players).

if you think about it, Menu's are the very basic things you'd build, (reminds me of editing dvd menu's). but a code-less development app doesn't do it..

and after 20+ apps, i personally got a little tired of spending hours on menu's when they eventually get abandoned..  -it's probably just this little detail that bugs me lol.

  • LolindirLink Anonynoise
  • Apr 5 2017
  • Need more detail
  • Apr 6, 2017

    Admin Response

    This sounds like an interesting idea, but it's not clear from this how it ought to be solved. Do you want some dedicated events? A behavior? A special plugin? If so what would the features of the plugin be? Which properties, conditions, actions and expressions would it have? What would it draw? How would it avoid being a cookie-cutter feature and work in a general sense for many kinds of games and styles? We think these questions need to be better addressed before we consider it further.

  • Attach files
  • Alex HW commented
    April 05, 2017 14:19

    I was going to suggest this too.
    One concern I have is that I'd like the graphical side of it to be either very flexible, or perhaps separate from the actual menu controls. 
    For example, you may want to have objects in the game interact with menu systems. So there should be ways of invoking menu actions, etc. Also, menu actions should be able to invoke other events, like if you select a menuitem it might cause a trigger to fire, etc. If a menu closes or opens.. if a menu is showing or not.. etc..

    I've implemented my own menu systems, and a feature that handles a lot of that could definitely be something helpful.

  • Alex HW commented
    April 05, 2017 14:21

    also, I forgot to mention.. it would be nice if you could setup the menus dynamically so that you can change what menuitems there are available during gameplay. Because you may have situations that require enabling or disabling menu choices, or the menu choices could be based on other things, etc..

  • Alex HW commented
    April 05, 2017 14:22

    For example with dialog systems, often there are different choices based on the dialog tree and if you have accomplished certain tasks, etc.. it'd be nice to be able to add/remove menuitems, etc.. 

  • skymen commented
    April 05, 2017 14:56

    The only way I can see this nicely done would be a separated menu editor that would be used to put many widgets that would have 3 states: Normal, hovered, clicked, and have basic features like linking menus together, and more advanced ones likes get "on hover" or "on click" conditions, and be able to simulate hover and click, as well as being able to load different menu layouts.

  • skymen commented
    April 05, 2017 14:57

    For more advanced stuff, just use sprites, and coding. You cant make an advanced code less menu editor. That's not possible, and will never cover every possibility.

  • skymen commented
    April 05, 2017 14:57

    For more advanced stuff, just use sprites, and coding. You cant make an advanced code less menu editor. That's not possible, and will never cover every possibility.

  • Guest commented
    April 05, 2017 14:59

    There's dozens of libraries for creating menus. Wouldn't it be better to find a way to use those, rather than reinvent the wheel? 

  • Aekiro commented
    April 05, 2017 17:30


    I guess you're talking about the ones made of html ? the disadvantages of these are:

    1-they are always on top of the canvas (like the current inputbox), so having a sprite on top of an html-made menu is impossible.

    2-they won't work with wrappers like

    3-they are not as fast as webgl rendered sprites (not sure)

  • Guest commented
    April 05, 2017 17:52


    There's no rule that they have to be created on top of the canvas. That's just the quickest way to add them. The only things that have to be on top are things that webgl can't render on the fly like svg.

  • Aekiro commented
    April 05, 2017 20:04


    Interesting, so how would you go about porting one of those UI libs to construct besides just laying them on top of the canvas ?

  • Jerbens Jarman commented
    April 05, 2017 22:50

    I've seen some plugins that add these features, but sadly they are still in early alpha. official support would certainly be handy

  • Guest commented
    April 05, 2017 22:56

    @Aekiro You would have to port any calls for graphics to what Construct can use using the sdk, as well as create functions for triggers, events etc. Not saying it would be easy. It does give a framework however.

  • Pixel Metal commented
    April 05, 2017 23:16

    I don't think this really exists in any available game engines. GUIs can vary so widely in games that I doubt there's a solution that would work in all cases.

  • Riv Hester commented
    April 06, 2017 01:02

    I frankly can't see this being flexible enough to be useful for more than a handful of games. This stuff seems simple enough to do with sprites and events already.

  • Alex HW commented
    April 06, 2017 01:42

    Even if it doesn't cover all cases, a generic system that people can build off of would still be nice to have.

  • Rablo Games commented
    April 06, 2017 08:43

    This is a +3 for me. Would really make life easier. I would like to make 2 further suggestions for it:

    1. The menu should be able to use LiteTween-like appearance and disappearance for its items
    2. Integrating a pause function automatically when a menu opens should be possible

    This would be a big gain of time for any game!

  • oosyrag commented
    April 06, 2017 16:02

    The underlying problem is that there really are hundreds of ways of implementing a menu, so any plugin/object/behavior that is flexible enough to account for the variety of approaches would be not much different than putting one together through events now.


    I think templates and tutorials are a more suitable solution for this.

  • Mike Foster commented
    May 20, 2017 15:29

    I think this would definitely be a great addition to the engine!

  • The_Shit_Hawk commented
    June 30, 2017 02:01

    "menu" would be a cool option, sort of like how you have the drop menu setup. you could input a number of buttons, with a predetermined max, with a selection of layouts, such as all on left, all on right, all centered, split left right, etc. could also have a sprite sort of behavior or tiled background behavior on the menu background so as a user could import either textures or background images for the buttons and menu layout. while i see this being useful, i feel like it would be better as a template rather than an in game item. as they initially said, theres 100+ different ways to code a menu, and it really wouldnt minimize the actual amount of events as youd still have to say, on menubutton1 pressed, goto layout 1, onmenutbutton2 pressed, goto layout 2, etc.

    a problem with that being the stock layout, is that if somebody is using the free version they might not have access to the extra layouts (maybe something to offer to liscensed members as incentive to buy?) 

    personally, i like to put menus off in the corner where nobody can see them, and use a combo of disable scrollto1 and enable scrollto2 etc, to change the position of view. granted you need a rather large layout size,and tetsing and editing requires a lot of zooming and panning,  but it does the trick. 

    this is why i think it should be a template rather than a built in feature. could maybe make a 'submit as template' option in arcade, where user submissions are reviewed over time, and if chosen, are categorized and used as base templates for users. i understand you can purchase extra capx and project files through the marketplace, and the forum is very nice for things like such, but i feel it would give users who want to spread their knowledge a place to collectively submit things, clearing up a bit of repetitiveness in the forums as well as growing the arcade/scirra community.

    Creating Categories, would further enable this feature, as you could have a category dedicated to Menus, and the plethora of ways in which one can personalize them to fit their exact needs. granted, if you have a menu category you then need to think of other categories, but im sure a post to the community can give you more than many. You could then custom tailor versions of construct, whether it be for Web page building as was originally intended, or for gaming, mobile apps. standalone apps, powerpoint presentations, or whatever else you can bring yourself to imagine/create.

    In closing, i feel it is a viable idea,but maybe not something to throw in as a function but more of a template as it adds to future possibilities. granted, just because the function is there, doesnt mean i have to use it if i dislike the way its laid out, so putting it directly into the program isn't necessarily detrimental, but it does become another button to scroll past.