As far as I'm concerned, I don't like working with too many layout or event sheet.
I only duplicate event sheet if a part of my code needs to be reused in more than one event sheet (which rarely happens)
OR
If I'm making a series and I have a common part and a variable part. This way I can use .bat files to always keep my common part in sync with the series (of course using the save as project for everything)
I use groups where most people use tonnes of event sheet. To organize code.
And sometimes, because it's easier, I use activation/deactivation. But I don't like it too much since I'm never quite sure I won't rename a group and then break these actions at some point.
Anyway the advantage of groups over event sheets to me, is that you can do
- a rightclick > collapse all to have a better view of all the part of your code and quickly access them.
- you can be more descriptive with a group (like what it does and then in description I often put a list of the function definede inside that group)
- it's easier to read than tab names when there's a lot of them
- it's also easier to do a search on all your events if you only have to search one event sheet. For instance, if I want to see where a function is called (because I want to add or remove an argument), I just type the name of this function in the search bar and I can quickly access all the references.
Now as far as code goes:
- I put everything under functions. This way I always know and control when a part of code is executed and I avoid most problematic ordering issues. The only things I don't use functions for are:
- things that should happen or be evaluated every ticks
- things under triggers (on click, on key press, etc) though I often call functions from there like "Button: on click -> Function: Call Button.action() with action an instance variable containing the name of the function to call.
- I use global variables sparringly. For the same reason. If you modify global variables in two different areas of your game, you have to always keep track of when things happen. It's asking for trouble. Also polluting the global scope is a pain (too much thing in combobox menus)
- Instead of global variables, I use a lot of static local variable. They behave the same but since they are scoped I'm sure they are modified only inside their limited scope.
- I avoid like plague what is called "magic numbers". A magic number is any number you use in an expression. There are two reasons I avoid them:
- first, they doesn't mean anything by themselves. What does 1.73 means? Nothing.
- Second, they may change during your development. For instance if you have a grid based game and at some point you find out that the size of the grid is wrong, you'll have to change all the expression where the width and height are used.
- I use constants a lot! Mainly to define most magic numbers. This way I can do Global constant number MY_HEIGHT = 1.73. I even do something like TRUE = 1 and FALSE = 0 and I also name array indexes like X_ = 0 and Y_ = 0 (the underscore is here because I often use x and y as temporary local variables)
- Constants can be global since they can't be changed. But using local constant can be a good idea since you limit global scope pollution.
- I always write my function in subevents of the "on function" event this way they collapse more nicely, and I add a little comment on top explaining what argument they take and what they return (if it's not obvious). This way I can forget how they are implemented (abstraction).
- I use only one "on start of layout" event and I put it on top of the event sheet. Rarely in a group.
- I agree with squiddster, I try to use as less object types as possible. For instance I use only one Button object and I do what I explained above "Button: on click -> Function: Call button.action()
I talk more about my practices in my C2 Channel by the way. I'll soon start a RPG series where amongst many other things, I'll show you how I handle the problem described by sqiddster:
"Have your layer setup fleshed out before making the first level of a game with many layouts. It's incredibly boring to mirror layer changes across 50+ levels. (@Ashley this seems something the engine could well improve upon.)"
Which is something I try to avoid, it's too hard to anticipate all the layer you'll need, you kind of lock your development too early in my opinion.
I fell into the "mirror layer changes across 50+ levels" trap.... Never again! Yann2013-02-08 05:16:17