New Event Sheet Feature: Gated Sections

Discussion and feedback on Construct 2

Post » Tue Dec 16, 2014 8:40 am

Hi @Ashley,

I notice that a lot of my code is temporal in nature -- events that happen before or after certain conditions hold, and actions that should only happen after certain events occurred, like state machines.

I think a useful advanced (or perhaps not so advanced) feature would be to have gated sections in an event sheet. Each gates section would have a condition expression that must be true for all events in the section to trigger. It may also be possible to include event sheets into a gated section, which would mean that all events in the event sheet would only fire when the gated conditions are also met.

Like this the event sheet could have a section that is activated when the layout started, and a section that is activated when, say, the player is on low food, which is, say, an important state in the game. Etc. There could also be subsections, which add selected pre-conditions.

I think this can already be implemented with Groups while playing with activation conditions of groups in seperate event expressions. But, it would be nice to have this "out of the box"

Perhaps a simple "syntactic sugar" implementation would be to support conditions on Groups to activate or deactive them.

In a way an event sheet would then be turned into a (hierarchical) state machine in chart form.

what do you think,

Dan
B
8
S
4
G
1
Posts: 205
Reputation: 1,354

Post » Tue Dec 16, 2014 11:06 am

If I understand correctly what you are saying, you are asking for the events to work as they already do.
An event sheets is read from top to bottom, and for each event, all the conditions must be true for the action and subevents to be executed/tested in turn.

You can add include as an indented sub-event, so it will only include another event sheet if the conditions of the top level event are true.

Finally, indeed you can work your way out with activating/deactivating group, and I don't really see how else you could make it but by allowing the user to make events that are tailored for the current project she's making.
How more "out of the box" would you see/want it to be ?
New to Construct ? Where to start

Image Image

Image Image

Please attach a capx to any help request or bug report !
Moderator
B
289
S
112
G
94
Posts: 7,333
Reputation: 69,293

Post » Tue Dec 16, 2014 11:20 am

I think you are right.

With sub-events this can be done quite nicely ...

I wonder, if there is value to allow structuring more visually with Groups and activation condition of groups.

Dan
B
8
S
4
G
1
Posts: 205
Reputation: 1,354

Post » Tue Dec 16, 2014 11:29 am

Grouping your events and activating/disabling them sounds like exactly what you're after.
B
10
S
2
G
2
Posts: 73
Reputation: 1,044

Post » Tue Dec 16, 2014 11:34 am

Yes.

Now i have code like so:

on start layout => Activate Group "Group1"
condition ^ once => Deactivate Group "Group1"

So, a group of events/actions included in Group 1, are only active from the beginning of the layout until a condition holds.

I think it would be nice if an activate or deactivate condition could be entered in the group itself. Right now, the only condition available is active when layout starts.

Dan
B
8
S
4
G
1
Posts: 205
Reputation: 1,354

Post » Tue Dec 16, 2014 12:23 pm

grossd wrote:Yes.

Now i have code like so:

on start layout => Activate Group "Group1"
condition ^ once => Deactivate Group "Group1"

So, a group of events/actions included in Group 1, are only active from the beginning of the layout until a condition holds.

I think it would be nice if an activate or deactivate condition could be entered in the group itself. Right now, the only condition available is active when layout starts.

Dan


you can set the group inactive by default
B
24
S
9
G
4
Posts: 1,646
Reputation: 6,596

Post » Tue Dec 16, 2014 12:23 pm

grossd wrote:Yes.

Now i have code like so:

on start layout => Activate Group "Group1"
condition ^ once => Deactivate Group "Group1"

So, a group of events/actions included in Group 1, are only active from the beginning of the layout until a condition holds.

I think it would be nice if an activate or deactivate condition could be entered in the group itself. Right now, the only condition available is active when layout starts.

Dan


IIRC, you can also include an event sheet under a condition, which means it will be read only when the condition is met, not sure however how that works with triggers. That may help you organise things a little.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Tue Dec 16, 2014 12:28 pm

Thanks @codah,

However, in my game the user can return to a layout, and after testing, it seems that unless i reset the layout (with a reset action), the state of the group is "global" and remains as it was when the layout was left. Because of this i can't rely on the
B
8
S
4
G
1
Posts: 205
Reputation: 1,354

Post » Tue Dec 16, 2014 2:13 pm

Why would you want to activate/deactivate a group instead of just putting all those events as sub-events under 'start of layout'?

With a group you separate the events from their cause of running, and they also become delayed in time: they don't run at the same time as the 'start of layout' trigger, probably just the next tick afterwards, which can cause confusing sequencing issues. I'd definitely prefer subevents.
Scirra Founder
B
395
S
232
G
88
Posts: 24,371
Reputation: 193,762

Post » Tue Dec 16, 2014 2:33 pm

Thanks Ashley for the additional information.

In my quiz game I have in each layout "temporal" states, such as "before Quiz starts", "Quiz running", "Quiz Cue 1 Given", "Quiz succeeded" ...

I want to ensure, for example, that when the success event is detected, and hence, Quiz succeeded state is entered, no more cuing occurs. cuing is a counter (with its own states), that runs in parallel.

At the same time I want to separate out code snipplets that deal with different concerns -- hence modularize the code. I don't want for example the cuing timers to know about game states.


So best, if i can place (call back) function that the cuing code calls into a "Gated sheet section" where it can only be invoked when CurrentState<>Success.

Similarly, I would want cuing timers only to run when the game entered the "Running State", and not before -- so they may have their own states that are activated via the main game layout states.

So, all this can be done currently, but i think it would be cleaner if there are designated "sections", each with their "entry condition"

Dan
B
8
S
4
G
1
Posts: 205
Reputation: 1,354

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Darknessed and 6 guests