The best way to use event sheets?

Discussion and feedback on Construct 2

Post » Sat Jan 10, 2015 11:38 am

I'm developing a game that would have 100+ layouts for different levels, but I'd like to use a single event sheet on them all. That would mean that this event sheet would probably get around 200+ events.

So the main question is - is it better to have 1 event sheet for general options and include it on a multiple layout event sheets (with the Include Event Sheet) with specific options for different levels or just have 1 major event sheet for all layouts (what I plan to do)? How would this and would it at all affect the performance of the game? Don't you think that it'd be kind of impractical if something has to be changed and we have to go through all the event sheets? Plus the UI of Construct will be permanently filled with tabs.

E.g. If I have an HTML 10x10 table and I want to make every cell to hold a text of a hex color number and a background with the HEX color I can either go and do that with 100 CSS classes or just dynamically read the HEX and apply the style with JavaScript, if you know what I mean :)
Ba-dum Tsss!
B
11
S
2
G
1
Posts: 45
Reputation: 757

Post » Sat Jan 10, 2015 12:37 pm

Well really its up to you. Do whatever feels most comfortable. There will be no difference in performance either way. I created a 100 level game with just one event sheet.
B
50
S
16
G
9
Posts: 1,098
Reputation: 11,237

Post » Sat Jan 10, 2015 2:06 pm

Personally I'm going for a hybrid system where I'm putting everything that can be shared into a single event sheet that deals with as much as possible (solo setup, multiplayer coop setup, entity logic, spawners, triggers, gameplay, etc.) with settings to be specified by each scene, and a callback-like mechanism for scene-specific events

Each individual layout logic becomes very simple and looks like :

- apply scene settings (scrolling speed, gameplay flags, etc.)
- include the generic event sheet
- deal with function triggers, e.g. "on PlayerDied()", "on EnemiesDestroyed()", etc. that are called by the generic sheet

This requires abstracting the structure of each scene and making it follow a similar-ish pattern
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Sat Jan 10, 2015 3:58 pm

All event sheet code gets combined into a long .js file on build, so it makes no difference how many event sheets you have. Like Spongehammer says, do whatever you feel is more organized. I do short event sheets for individual layouts to control things specific to that layout, like bg animation for instance. Little things that I don't need cluttering up my more general-purpose event sheets.
B
39
S
16
G
6
Posts: 543
Reputation: 7,619

Post » Sat Jan 10, 2015 4:08 pm

@Refeuh that seems to be the more organized way to do it (even though using groups can make the events sheet neat as well), and if you have layout count in the vicinity of 10 that's fine, but on a larger scale it seems the more practical way to put everything in a single sheet. And in the case that this does not compromise the performance of the game (thank you @ErekT for clearing that out) it's like... why do it otherwise at all?

The only downfall I've encountered is that there is no option to perform event on specific layouts, but with a bit of trickery it can be done. Something like naming layouts "Level1, Level2, Level3, etc.", getting the current layout name, storing it in a global variable and comparing that variable to the layout name:

On layout start:
var CurrentLayoutName = LayoutName
if CurrentLevelName == "Level1" -> do events on this layout in particular
Ba-dum Tsss!
B
11
S
2
G
1
Posts: 45
Reputation: 757

Post » Sat Jan 10, 2015 4:32 pm

Alternatively, you call also call level-specific functions by building the function's name dynamically using the current layout's name and some naming convention.

Insert a few of these at key points of the event logic (layout start, layout end, player dead, enemies dead, etc.) and you have a fairly flexible system. You can fill in the bits for levels that require it
Image
Game Producer & Independent Developer - http://raphaelgervaise.com
B
24
S
9
Posts: 237
Reputation: 2,232

Post » Sat Jan 10, 2015 5:19 pm

@Refeuh , do you have an exemple of this usage?
B
18
S
4
G
1
Posts: 143
Reputation: 1,868

Post » Sat Jan 10, 2015 7:46 pm

NicotineLL wrote:@Refeuh that seems to be the more organized way to do it (even though using groups can make the events sheet neat as well), and if you have layout count in the vicinity of 10 that's fine, but on a larger scale it seems the more practical way to put everything in a single sheet. And in the case that this does not compromise the performance of the game (thank you @ErekT for clearing that out) it's like... why do it otherwise at all?

The only downfall I've encountered is that there is no option to perform event on specific layouts, but with a bit of trickery it can be done. Something like naming layouts "Level1, Level2, Level3, etc.", getting the current layout name, storing it in a global variable and comparing that variable to the layout name:

On layout start:
var CurrentLayoutName = LayoutName
if CurrentLevelName == "Level1" -> do events on this layout in particular


I recommend on using group activation/deactivation in order to apply specific sections of logic to a specific layout

For example:

Name groups Movement_0 , Movement_10 , Movement_20, Movement_30 etc. for the movement mechanism you want to use on different levels (Movement_0 for
levels 0-9, Movement_10 for levels 10-19 etc.)

Add global varLevel (use a number, not text! It is a lot easier to use a number for a mathematical condition that generalizes a usage rule, rather than creating a name condition for each and every layout). Make sure that this variable update as the layout changes

On the common event sheet - on start of layout - add an action that disables all these groups (to disable the group that was active on the previous layout):
On start of layout > System > Repeat (number_of_groups) times > set group "Movement_" & loopindex*10 deactivated

and an activation action that enables the appropriate group:
On start of layout > System > Set group "Movement_" & floor(varLevel/10) activated

This way, adding a new group for new levels only takes a change on number_of_groups value on the disable action, and naming the new group correctly. The group will follow the rule you have defined.

You may use a simplified condition for a single group that should work only on a specific layout:
On start of layout > If varLevel=55 > system > set group Special_55 activated
else > system > set group Special_55 deactivated

BTW - this method would work either on a single or multiple event-sheet structure.
B
12
S
3
Posts: 104
Reputation: 1,655

Post » Sat Jan 10, 2015 8:30 pm

@MaorKeshet that seem like over-complicating things a little. For example how do you plan to apply your system with the following conditions:

- layouts are selected at random (random levels)
- not every layout is a level (we have a menu layout, objects layout, etc.)

And come on, it's not the worst thing selecting stuff by name. Look at jQuery - the whole library is built on this principle and it has been the first choice of web developers for years :)
Ba-dum Tsss!
B
11
S
2
G
1
Posts: 45
Reputation: 757

Post » Sun Jan 11, 2015 12:12 pm

NicotineLL wrote:@MaorKeshet that seem like over-complicating things a little. For example how do you plan to apply your system with the following conditions:

- layouts are selected at random (random levels)
- not every layout is a level (we have a menu layout, objects layout, etc.)

And come on, it's not the worst thing selecting stuff by name. Look at jQuery - the whole library is built on this principle and it has been the first choice of web developers for years :)



This method would work the same way when randomizing the layout. Randomizing is actually a lot easier with numbers.... I think that the little extra time that would take to generalize a rule (or to set a unique layout rule) is very beneficial down the road. I use this method for many different purposes: for example, to test different versions of a specific game module ( I can run the very same game mechanics with a completely different "enemy generator" by only changing varEnemyGeneratorVersion on the game's settings).
Group activation/deactivation makes things very tidy, and you may use it in a similar when even if you insist on using names.
B
12
S
3
Posts: 104
Reputation: 1,655

Next

Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 10 guests