Idea for a future construct

  • I don't like it. It's just a more limited UI for defining logic which is normally determined by events. Whether you have a movement, oscillation or just a clamp, often you don't want it to apply all the time. So you need to be able to turn it on and off or adjust the parameters in events based on other custom logic in the game. So you will have a bunch of events to modify all this stuff anyway. Now you have fragmented your logic between this UI system and the event sheet. If you went as far as to extend the flowchart system to do everything events have, I see it as an inferior system, since you have your logic spaghetti-fied in to 2D (whereas events are a 1D list, just going down the event sheet), which makes it very difficult to determine the sequence of things, which is an essential part of the game logic.

    The current way allows you to apply, enable/disable and modify behaviors from the event sheet, where it is more or less all done already, with full flexibility to customise the logic and parameters, and it's all kept in the same place (no fragmentation).

  • I don't like it. It's just a more limited UI for defining logic which is normally determined by events.

    I would say - not logic, but behaviour - the logic is still in events, you either turn it on or off or adjust settings, just like behaviours. In fact these are basically behaviours, just with more freedom of interaction and visibility.

    Whether you have a movement, oscillation or just a clamp, often you don't want it to apply all the time. So you need to be able to turn it on and off or adjust the parameters in events based on other custom logic in the game. So you will have a bunch of events to modify all this stuff anyway. Now you have fragmented your logic between this UI system and the event sheet. If you went as far as to extend the flowchart system to do everything events have, I see it as an inferior system, since you have your logic spaghetti-fied in to 2D (whereas events are a 1D list, just going down the event sheet), which makes it very difficult to determine the sequence of things, which is an essential part of the game logic.

    The current way allows you to apply, enable/disable and modify behaviors from the event sheet, where it is more or less all done already, with full flexibility to customise the logic and parameters, and it's all kept in the same place (no fragmentation).

    The point here is that you would be able to do all the same things, but not fill your event sheets with, basically, non-events like: Set setting A to this, Setting B to that, Setting C to that, etc. If there was an event sheet command that basically brought up the behaviour panel the same as it is in the editor and you could just adjust the values and it automatically would leave only the affected ones then there would be no desire for something like this. As is I would say there's plenty of "event spagetti" just to set up some mildly random or reliant things.

    This is basically the same visual approach of events applied to maths, which could be quite useful for some (and probably a good deal faster than typing formulas every time). Doing a spawn object and knowing it will have a random rotation, size, opacity and promptly move for an amount of time and then fade out seems like a good approach without needing to add variables, extra events, accessing behaviors, etc. Being able to create an "independent" self-sufficient object that just works seems like a fairly "Construct" thing to me.

    I realize it's once again a question of approach - have seen it before oh so many times. But thank you sincerely for taking the time to reply and state your stance on something like it.

  • Somebody

    This reminds me of Unity's visual scripting... Animations, Triggers, etc. There is a 2D asset collection that uses these same methods. It works quite well, though as mentioned here it can get really confusing to see what is handling what. MMMMmmm Spaghetti!

    That said, I have to agree that the current event system is more like writing code. Which I feel helps when wanting to get more advanced with game making. Plus it's organized.

    Perhaps a system that combines the event sheet with this would be nice. Like double clicking on an event row would expand view to give you more 'visual' control, then when done you could collapse it back down to the regular event sheet view. Keep organization and structure... Just some thoughts...

    PS from a UI guy... This looks really nice for some quick WIPs

  • Somebody

    Perhaps a system that combines the event sheet with this would be nice. Like double clicking on an event row would expand view to give you more 'visual' control, then when done you could collapse it back down to the regular event sheet view. Keep organization and structure... Just some thoughts...

    Somehow I feel like most readers (including Ash) just threw a quick glance over it, didn't read the text and made some assumptions. What you say is how this is meant to be - this is a setup - you set up some rules in a nice, visual way - and whatever you do in the event sheets obeys these rules. If necessary you can change them, if not they just work from the get go - keeping the event sheet cleaner and leaner and let you work on your game logic, not endless setup of things.

    PS from a UI guy... This looks really nice for some quick WIPs

    Thanks, I would say your art is rather nice and that robot game looks great - hopefully there's a playable something soon

  • Ashley can you improve these?

    Not everything is customizeable.

    Pathfinding behavior i can't reduce the time.

    When i use turret behaviour i can't get the variables for rotation.

    Gamepad: i can't get variables axis and trigger buttons.

    Mouse variables.

    Things i need for isometric projection.

    Sample capx:

    (about isometric)

  • Somehow I feel like most readers (including Ash) just threw a quick glance over it, didn't read the text and made some assumptions. What you say is how this is meant to be - this is a setup - you set up some rules in a nice, visual way - and whatever you do in the event sheets obeys these rules. If necessary you can change them, if not they just work from the get go - keeping the event sheet cleaner and leaner and let you work on your game logic, not endless setup of things.

    Totally agree.. and the quick reads are pretty common actually lol

    Thanks, I would say your art is rather nice and that robot game looks great - hopefully there's a playable something soon

    Thanks! I appreciate that. Hopefully soon. I have been planning for a pre alpha game test... I'm holding off for another Node release :/ I have a jank issue that I'm not 100% sure is Node or a loop running to often. So I have been polishing art work in the meantime.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I would rather have a pop up window with all object details nicely listed so all is in one place, and self extending textarea for variables.

  • The point here is that you would be able to do all the same things, but not fill your event sheets with, basically, non-events like: Set setting A to this, Setting B to that, Setting C to that, etc. ... As is I would say there's plenty of "event spagetti" just to set up some mildly random or reliant things.

    You talk it down, but the thing about events is you can reference arbitrary variables, functions, other events, other actions and so on - in other words, custom logic. The system you've shown as I see it only supports a very, very small subset of the "anything goes" capability of events. Want a variable time for the timer? Want a trigger to enable/disable? It looks like you'd be straight back to events. So this is a lot of work for something which is only useful some of the time.

    Anyway as far as feature requests go, this appears to be just another way of doing what's already possible via events. Generally I prefer to work on feature requests where it's not yet reasonably possible to achieve the request by any other means. That actually increases the scope of what you can do with Construct 2.

  • I really like how in C2 you can click an object in the object toolbar while just the events are open, and have all the properties there for you.

    What I would like is the ability to pick an instance in that, and change the individual existing objects setting.

  • You talk it down, but the thing about events is you can reference arbitrary variables, functions, other events, other actions and so on - in other words, custom logic. The system you've shown as I see it only supports a very, very small subset of the "anything goes" capability of events. Want a variable time for the timer? Want a trigger to enable/disable? It looks like you'd be straight back to events. So this is a lot of work for something which is only useful some of the time.

    As said this would be useful for setting things up - and as said it is totally a question of approach - for example, I would, for example, like to make a jungle scene with vines and all sorts of little bugs and animals and so on - everything nicely animated and alive and yet background when it comes to gameplay - with a system like this I set everything up it never enters the event system which stays clean and ready for the gameplay logic.

    "Oh, but you can use groups and global variables, etc" you say - yes, you can - by annoyingly going through the event system - and then you have a hundred global variables on top that you cannot group or minimize and you cannot scroll up or down quickly because pg up/dn and any other keys do nothing. And every time you want to work on your gameplay the unnecessary global variables from your background stuff pop up in autocomplete. But sure, you can do it that way... well, HAVE to do it that way as is.

    Anyway as far as feature requests go, this appears to be just another way of doing what's already possible via events. Generally I prefer to work on feature requests where it's not yet reasonably possible to achieve the request by any other means. That actually increases the scope of what you can do with Construct 2.

    Well, it's not even a feature request, more like thinking out loud what would be neat. And I think this would be.

  • > You talk it down, but the thing about events is you can reference arbitrary variables, functions, other events, other actions and so on - in other words, custom logic. The system you've shown as I see it only supports a very, very small subset of the "anything goes" capability of events. Want a variable time for the timer? Want a trigger to enable/disable? It looks like you'd be straight back to events. So this is a lot of work for something which is only useful some of the time.

    >

    As said this would be useful for setting things up - and as said it is totally a question of approach - for example, I would, for example, like to make a jungle scene with vines and all sorts of little bugs and animals and so on - everything nicely animated and alive and yet background when it comes to gameplay - with a system like this I set everything up it never enters the event system which stays clean and ready for the gameplay logic.

    "Oh, but you can use groups and global variables, etc" you say - yes, you can - by annoyingly going through the event system - and then you have a hundred global variables on top that you cannot group or minimize and you cannot scroll up or down quickly because pg up/dn and any other keys do nothing. And every time you want to work on your gameplay the unnecessary global variables from your background stuff pop up in autocomplete. But sure, you can do it that way... well, HAVE to do it that way as is.

    > Anyway as far as feature requests go, this appears to be just another way of doing what's already possible via events. Generally I prefer to work on feature requests where it's not yet reasonably possible to achieve the request by any other means. That actually increases the scope of what you can do with Construct 2.

    >

    Well, it's not even a feature request, more like thinking out loud what would be neat. And I think this would be.

    I'm sorry, but you must be doing something wrong then. You can make events for background animations on separate event sheet, and use local variables set to satic, and only one global variable trough which you set types of backgrounds.

  • Yeah, one could do it like that, but the event navigation issues are still present abd you would still need to set everything up "by hand".

    It's not a revolutionary mega feature, but rather an idea on furthering "easy to use visual game making".

  • As said this would be useful for setting things up - and as said it is totally a question of approach - for example, I would, for example, like to make a jungle scene with vines and all sorts of little bugs and animals and so on - everything nicely animated and alive and yet background when it comes to gameplay - with a system like this I set everything up it never enters the event system which stays clean and ready for the gameplay logic.

    I'm not sure I get your point. A lot of behaviors already work just fine without any events at all. For example you can apply the Sine behavior to a bunch of objects and they all become animated and alive, with no event involvement at all. So you can already get that with the existing behavior system. Then if you want to add some kind of logic to that, then I think events are still a better way of doing that.

  • I like it. Looks like Unreal Engine 4 stuff with nodes.

    But I am okay with Ashley, Events are easier. Just don't forget to use the Groups at your own advantage.

  • Ashley

    Can we have timeline animation in the editor ? Basically we can do animation like tween, move,scale and etc by just using timeline or animation feature like

    http://booty5.com/booty5-1-8-7b-out-now-flash-style-animation-brought-to-html5-developers/

    http://booty5.com/html5-examples/timeline-animation/index.html

    Since godot has it and also booty5 just added it into their open source editor.

    I hope this will be added in C3

    TQ

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