Separating Game Mechanics -- "sheep from the goats"
Game Flow -- the game states
"I don't do that! I write everything down in every Event Sheet", you retort. But are you following the D.R.Y concept? (i.e.: Don't Repeat Yourself) Did you follow -- what everyone else seems to do -- and write just one Event Sheet per Layout? The Construct Gaming Framework family naturally follows the "Single Web Page Application" (SWPA) architecture -- a game with a "Splash" scene, a "Main Menu" scene, a "Game Won" scene, a Game "Lost" scene, and perhaps a "Leader-board" scene or a "Credits" scene. Folks tend to write "Events" that are directly associated with its visually displayed "Layout". That's a smart move for small casual games. Yet, as your "game seedling" grows, what then?
Having one big event sheet has its disadvantages that I've hinted about already. Wouldn't it be easier to manage your project(s) -- anticipating their growth -- if you wrote your Game Mechanics into smaller "Event sections" dedicated within their own Event Sheets? For example, have one event sheet that manages all of your "Global Event Variables", another sheet just for "inventory", Player(s), antagonist(s), and one for your "Artificial Intelligence (AI) Bots" etc. Consider what this author is doing ... it's brilliant!
Consolidating Common Tasks
Using Construct as a Component Manager -- "Objects Linking to Other Objects" (OLOO) Copyright © 2014-2022, Stephen Gose. All rights reserved.
As you can see from the pictures above, I'm suggesting that you use Construct as a "Component Manager". Game Mechanics (those "Event Sheets") are tailored to specific activities -- sprite's "Position", "Movement", triggered "Events", User Interface (UI), and collision "Physics". The Game's visual Mechanisms (those items placed in the "Scenes, Layouts, and Layers") use only those "functions" that are needed. The advantage to this method is once it is written you can use it in ALL your game projects across ALL your game genres! You're writing "DRY" (Don't Repeat Yourself) Construct Projects.
But don't take only my word for this recommendation. You'll find that, for the past few decades, game developers are using "Entities and Components" in game design. Apple's Game-Play Kit plainly states, (quote) "The Entity-Component design pattern is an architecture that favors composition over inheritance. To illustrate the difference between inheritance-based and composition-based architectures, consider how you might design an example "tower defense" style game, with the following features ... ". It's a wonderful feeling to discover after 20 years that other prominent game developers are thinking along the same patterns of "game prototype development". Read what Apple Game Development says about OOP in their section guides:
1) "Inheritance-Based Architecture Hinders Game Design Evolution" and;
2) "Composition-Based Architecture Makes Evolving Game Design Easy".
Splitting your Game Mechanics Rules, Logic, and Data among "event sheets" can help you track "what does what to whom", and further saves you from searching through a single huge "engorged event sheet" looking for a particular plugin or nasty software glitch! Multiple event sheets do take some planning -- for example, what should be available to the entire game, which Game Mechanics rule, logic or data needs to communicate with each other, and when. ( This is shown "how to do this easily" in the "Code-less Game Construction" Book Series. ) Doing this saves you time, in the long run, on game updates, upgrades, and "selling White Label" and customized versions!