Event Sheet organization

So, I was wondering what methods or personal standards everyone has regarding how they set up their Event Sheets. Obviously, certain rules within C2 apply (like the flow in which every Event is checked per tick).

But when it comes to organization, how do you try to set things up?

For example...

Do you try to keep things as condensed as possible? Do you organize related Events close together? Do you add comments to every Event or just the main ones?

What're your Event Sheet habits?

http://www.scirra.com/forum/programming-best-and-worst-practices_topic63136.html

shinkan - That'll definitely help. :) But I'm just curious about individual habits. Like, what's the logic BEHIND why everyone does things the WAY they each do them.

It's quite hard question to answer to be honest.

I have no answer for that :D

Personaly I like using different event sheets for stuff like player controls, global events etc. and groups. For me doing it that way it looks obvious and clear what is what and where to find stuff I need to change/add.

But there are many people who like to use only one event sheet and groups to organize things in it (or even use variables instead of groups).

so yeah, it's hard question :)

shinkan - I totally understand. I started using separate Event sheets, too, so I can call on them when needed. It makes it easier to see what other Events I have that are related to each other.

But your answer was precisely the sort of input I was looking for. :) The REASON behind what you do. :)

Obviously I'll be repeating a lot of suggestions from the above linked "programming best (and worst) practices" discussion, but as you're after individual habits and reasoning I'll list some of the things that are most important to me personally here, and try to briefly explain the reasoning behind them. <img src="smileys/smiley1.gif" border="0" align="middle">

1. Always be consistent. Always.

A lot of things in programming -- and using an event sheet is essentially programming -- are subjective and come down to personal preference. It's important that you choose a preference and stick to it within any given project; you should never have to wonder if a variable name is in camelCase, ALL_CAPS_WITH_UNDERSCORES, or some other style, because you should be following your own consistent set of rules for these things.

If you assign some meaning to particular styles (ALL_CAPS for constants for example) it will even help by providing additional hints when reading your code.

2. Use sensible, meaningful variable and object names.

Don't be tempted to save typing by using one character or very short abbreviated names unless there is already an established convention to do so for a particular usage.

It may be clear what you mean now, but it might be less clear if you have to read the same code again after not touching it for a year or if you find you need to hand it over to someone else to be updated.

Using proper names is also a good step towards making your code/events "self documenting", rather than having to explain what it means by adding comments -- see the next point.

3. Use comments to describe why things are a certain way or to explain unusual code, not to describe what your events are doing.

Your events already explain what they're doing, and should be quite clear if you've chosen sensible names. Comments should be used to explain why you're doing it, which may be less readily apparent at a glance.

For example, you might have an event that sets a boolean instance variable to true if a particular sprite is colliding with another. You don't need to write a comment saying that, as the event already describes it perfectly; instead, explain why you're doing so.

4. Use the functions and expressions that most clearly express your intent.

Something there will be multiple functions or expressions which produce the same result. Consider for example the system expressions floor() and int(): when applied to a number such as 4.6 both will produce a result of 4, but these functions have different purposes, and you should use the one which matches what you're actually trying to do. Again, this will help to make your code "self documenting" and easier to understand.

Hope that's the sort of thing you're after. <img src="smileys/smiley1.gif" border="0" align="middle">

jbadams - That's VERY much what I'm looking for...or close to it. The tips are great, but the specific things I was interested were the WHY - as you mentioned in #3 - people do it. Like, why does one person use separate Event Sheets while another one doesn't? And so on. But those are great and give me a lot to consider, too.

why does one person use separate Event Sheets while another one doesn't?

I think you could compare C2 to programs like photoshop.

There are some rules You must follow to make working game but how you actually use your software depends entirely to you.

I know many great artists who use dozens of layers and different brushes in photoshop to draw something and many other artist who use only one layer and one brush to do same thing.

It really doesn't matter if you are using groups, variables or include event sheets. Like jbadams said, it all comes down to personal preference. There are many path you can follow but eventually they will all end up in same place. Finished and working game ;)

shinkan - Exactly. It's those personal preferences and the reasons behind them that I'm interested. :) When either one will suffice just fine, what goes into the decision making for each person.

I like to keep all of my core gameplay mechanisms in a single event sheet, which I organise by being very liberal with groups and sub-groups. It's also where I keep my debug group, which I sometimes split off into its own sheet if it gets too big. I then use a small event sheet for each of my game's levels. I also use a separate event sheet for global variables, as those can't be neatly tucked away in a group (for some strange reason).

I find that this process forces me to make my events reusable, so in my level event sheets I basically just put in the parameters for each level, like MonsterSpawnRate or LevelTime, which is then passed along to the main event sheet. If a particular level has its own unique mechanisms, then I just put those events in the local event sheet. As soon as I find that I want to use those events in another level, I go back to them and make them suitable for reuse by changing any fixed numbers that need to be variable, and move them to the core sheet.

Otherwise, I comment for every major block of code, but this is often superfluous and I just do it to visually break up the events. I also make sure that my projects tab is well organise with groups and sub-groups, and I do my best to use families wherever possible. I'm also now starting to get into the habit of making better use of functions where it's appropriate, like for character dialogue.

GeometriX - So you like to have a very "categorical" sense of organization to your Events, but without much flipping through pages, eh?

Rhindon, yeah, that sounds about right. I'll organise major groups under initialisation, UI, player controls, enemy behaviour and so on, with sub-groups for more specific things.

Personally, I find the tabbing in C2 to be pretty chaotic. It never saves tab positions and with all the tabs on one line it becomes a chore to flip through them when you get quite a few going.

GeometriX - I hear ya. I started using groups in a similar way that I'm now starting to use individual Event sheets: to keep things isolated and uncluttered. I still have more to learn about the ins-and-outs of both uses...

The one thing that I'd definitely like to see is easier editing of the Event tabbing. Like use the left/right arrow keys to increase or decrease selected (and related sub) Events by one level. I imagine Ashley (playful hint-hint! ;) ) has thought of this and is aware of issues I'm not if this were to be tried.