On tablet so cannot give it a go, but it was a nice read and sounds like a neat project. Apps in game engines are always cool - will surely give it a try layer.

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

% is the modulus operator - it's like "remove all of these that fit into previous value" so 4 % 3 is 1. We add to the current frame and if it goes over total frame count that gets subtracted so we never go over.

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.

On object clicked set animation frame to: (Self.AnimationFrame+1) % Self.AnimationFrameCount <== Put this in the "Frame number" field.

— - would you mind elaborating how dt helps with an "Every X seconds" condition? Because I really don't think it's going to help with that.

I'm also attaching an Extreme version with 3x the bullets so it should start to lag, and an illustration of what lag causes in this case - every gap in the pattern is a moment when an "Every X seconds" command was skipped:

Eh, since he said he likes to profile things perhaps I can sneakily tag Ashley into this and ask - what's the official solution?

Hi, all!

I have built here a slightly extreme example to try and work around something that I have been encountering - lag can make "Every X seconds" events skip, as seen here:

In a "proper" game engine the logic and rendering can both go their merry ways so these bullets would all make perfect curves. Question - is there a way to do this in C2? Can we modify this .capx so despite lag or whatever the resulting bullet patterns will be smooth with equal distances between them (and not make more lag by doing something very cpu intensive).

Ideas welcome. (Actually I should probably crank the bullets up and submit this as another performance example to Ashley - since this one creates new objects all the time).

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

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.

Not talking about event system here, delgado.