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.
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.