The best way to use event sheets?

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

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.

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

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.

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

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

Refeuh , do you have an exemple of this usage?

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.

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

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.

frcol

Sorry for the delay ! 'Hope this is still useful -

The goal being to maximise reusability, I see mostly 2 scenarios. I work with the assumption that all levels follow roughly the same structure in terms of logic, but require some amount of customisation for gameplay events. I've highlighted the difference between the two approaches, where dynamically generating function names can be useful

1. Lots of levels (layouts), each pointing to a specific event sheet

The shareable bits are all demoted into a shared event sheet, which is included in all the levels event sheets. For a multiplayer game, the structure becomes something like (example) :

Shared ES :

• Common (host/peer) init
• Host-specific init (creation of peer objects, spawn and scale enemies to numbers of players, etc.)
• Host-specific entity management (collision, behaviours, damage, etc.)
• Host-specific gameplay triggers & callbacks (e.g. "Call PlayersDead()" when all players are dead)
• Peer-specific init
• Peer-specific entity management (reacting to objects being created, etc.)
• Peer message processing
• Common (host/peer) logic, if any

Level ES

• Set level options : enemy types, scaling of spawners, etc. whatever is relevant to the gameplay and has been factored out
• Include the shared ES
• Implement the logic for the triggers : "on PlayersDead()" (some levels might force you to restart from the beginning, some might let you continue where you died, etc.)

Here, we always call the same functions, and let the level-specific ES provide the implementation

2. Lots of levels (layouts), each pointing to the same event sheet

We still want to provide custom implementation for specific triggers on a per level basis, but the same event sheet is used as entry points by all the levels. We can't call the same trigger functions anymore, but we can generate names dynamically :

Main ES :

• Set level options : enemy types, scaling of spawners, etc. whatever is relevant to the gameplay that can be tweaked
• Common (host/peer) init
• Host-specific init (creation of peer objects, spawn and scale enemies to numbers of players, etc.)
• Host-specific entity management (collision, behaviours, damage, etc.)
• Host-specific gameplay triggers & callbacks (e.g. "Call LayoutName & "_PlayersDead()"" when all players are dead)
• Peer-specific init
• Peer-specific entity management (reacting to objects being created, etc.)
• Peer message processing
• Common (host/peer) logic, if any
• Implement the logic for the triggers, using specific layout name : "on DeathStar_PlayersDead()", "on StarField_PlayersDead()" etc/ (some levels might force you to restart from the beginning, some might let you continue where you died, etc.)