Opinion: Your Thoughts On Groups Versus Event Sheets

0 favourites
  • 12 posts
  • Just a general question which may boil down to be nothing but a trivial matter of preference...but I'm curious as to any insight about the inner-workings of C2 and/or how and why people choose to use Groups or separate Event Sheets when organizing events for specific portions of their games.

    In my 2-3 years of fumbling my way through learning to make the most of C2, I've adopted the habit of using Groups to better organize and find sections I've already put together. I've also learned a while back about referencing Event Sheets in other Event Sheets...again, to help me section off and more easily find specific portions of my game (ie: an Event Sheet for player/character controls and one for enemy behavior and still another for level-specific characteristics, etc).

    As I stated, this may be a trivial matter where it really doesn't matter in the slightest which is "better", but I'm ignorant on this detail. Is there perhaps a performance advantage to using Groups or separate Event Sheets over the other? Or is it strictly a matter of organization preferences? (I also know that having specific Event Sheets for Layouts is also another key point, but I'm not concerned about that presently.)

    Just looking for input and maybe some new knowledge I didn't have before. Thank you!

  • For what it's worth, I put events and included event sheets inside groups that are enabled/disabled depending on the stage of the game. Just to minimise unnecessary condition checking of things like player mode etc. That way a check for a bunch of collisions and player modes associated with swimming or whatever don't need to be checked for and discounted every tick.

    I doubt there's a difference in performance between using one or many event sheets, because after compilation they are all blended into one file anyway.

  • Colludium - THAT is actually a very good idea. Running faster is running faster!

  • I always seem to use one big event sheet that is well organized into groups. I've never heard of any difference between the performance of one event sheet versus many. The most important thing seems to be how the groups are organized so you can use the debugger profiler to see what resources they are using or to enable/disable them as needed.

  • I use both equally so..hm. I typically have eMain which includes ePlayer, eEnemies, eCollectibles, eHUD, eSaveData, eGlobal, and so on...and inside those sheets I have groups to further organize things like specific player abilities, certain enemy AI, components of the HUD, types of save data, etc.

    Everything is compartmentalized and very easy to find this way. Only drawback is function references, for example, can be difficult because they span multiple sheets. Solid naming conventions and the search function help there though.

    I don't think there's any difference in using one or the other...ultimately everything is put onto a single 'sheet', no? If you're really worried about it Collodium's method is good practice. Could be a pain to manage some things though.

  • I truly appreciate the input. Thank you, everyone! Any other suggestions or ideas? Send 'em my way!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • My workflow is very similar to I use event sheets (but with "[ES] sheet name" prefix so I can better see in the tabs what is where) for major stuff and then groups for minor things. It really helps you know what is where.

    Just to add two cents about functions. I learned to organize functions in a "per sheet" way. For example if I have something like [ES] Inventory, then all functions related only to the inventory will be placed on very same event sheet on the bottom of all events so I alway know where to find what I'm looking for. And functions that needs to be accessed from multiple event sheets I always place in [ES] Global Events sheet, which is always included in all important event sheets like [ES] Main Game or [ES] Level something.

    As of the performance, well if you have 50 disabled groups or 50 events that basically do nothing then there is no difference. The trick is to learn how to use only what you need to use. Like for example if you on Level 1 then you don't need events from Level 10 to be running every tick. This is a bit obvious and idiotic example, but people tend to forget about that little details.

  • I truly appreciate the input. Thank you, everyone! Any other suggestions or ideas? Send 'em my way!

    Think your way of doing it is fine, and the other people uses as well. The only thing C2 is really missing when it comes to organisation of projects, is that you could "Ctrl+Click" a function call and it would jump to that function in whatever event sheet it was defined. Scrolling through so much code when doing larger projects looking for functions, it would save SOO much time.

  • nimos100 - Let's hope Ashley [Calling Ashely! Heeeellloooo, Ashley! ] implements this soon or later in C3 when that rolls out. That's definitely a great idea!

  • I also prefer the "event sheet per function" approach. I use seperate event sheets for controllers, animations, sounds, etc... and I put the events into groups on these sheets. In the last step, I include these sheets into a main sheet. Using speperate main sheets for the stages of your game for optimization is also a good idea

  • Colludium - THAT is actually a very good idea. Running faster is running faster!

    Yes! I totally agree. I use that technique mostly for traps and puzzles in each section of the game - if the player is somewhere else then the groups of associated code are disabled. To make all of that work, like others have posted, I have event sheets for: E_player, E_effects, E_enemies, E_traps, E_common, E_LayoutX - and most of the group enabling/disabling takes place in E_traps, E_enemies and the event sheet specific to the current layout.

    It's the same philosophy for turning off work for other behaviors - but doing that might earn you bigger dividends. For example, I turn off particle objects if they are far away from the player. That lets me add a LOT of particle objects without loading up the cpu by making it have to track thousands of particles that cannot be seen. When I introduced that little trick to umbra during dev of level 2 the cpu utilization went down by 10%! So, depending on what your events do, enabling/disabling groups may not make any discernible difference to a game (but could cause you a bit of pain setting it up) whereas managing off-screen behaviors might be worth giving more attention to (I just do it out of caution so I don't later find I have to go back and try it).

    Regarding the code groups - the way I imagine it is that it enables you to block off great swathes of code by setting a single boolean. That boolean will be checked each tick - so each disabled block of code will add a small but relatively insignificant burden to the work the cpu has to do each tick.

  • glerikud - That sounds about what I do, too, right now. I'm still learning how to refine my own processes. Such as what the best way to group things would be when, for instance, an event would be legitimately put on a player or enemy Event Sheet.

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