Organizing your project
The next step is to organize your project, to keep objects easy to find, and coding more simple.
Naming conventions
It's a good idea to create a naming convention, or rule, so your objects' names are a good indication of what is their role in the game.
I usually categorize my objects in these categories:
Background: a tiled background or sprite object, which makes up the scenery of the game.
Object: usually a sprite, that performs actions in the game.
Sprite: usually a sprite, that doesn't have many actions, and its main purpose is only to display an image.
HUD: usually sprite or text, is an element of the Heads-Up Display. Can be text or a life meter. Usually is static and has a layer only for it.
So when naming my objects, I will use these names to categorize them. E.g:
bgGrass: only a piece of scenery, probably wont perform any actions.
objPlayer: is an important object, the player sprite.
sprExplosion: an explosion effect.
hudScore: a text that displays the score.
Similarly, any other plugin will receive a name that is directly related to the object type. E.g:
arrayItems: an array that stores values related to items
dictKeys: dictionary object used to store key values
Note that names start with small caps, and every word after is in caps. This is a common practice in some programming languages. If you prefer, you can separate words with an underscore "_" or a dash "-". It's up to you, but the important thing is to keep it consistent through your project, so you can remember objects' names easily.
Adding folders
In C2 you can put your objects in folders. This way, when selection your objects for actions and conditions, you can easily find them in a folder that always appear on the top of the objects list.
Once a folder is created, you can drag objects into it.
Naming your families
I always find it easier to name families by starting it with the letter "a", this way all families will appear on the top of the object selection window when making new conditions and actions.
The second very important thing to do, is having a family that contains all objects. This way you can have events that affect every object, such as destroying objects that are off screen, and counting the number of objects in your game.
Naming Layouts, Event Sheets and Layers
It's also important to name these. If you name your Layouts and Events Sheets properly, you can identify them quicker when you have many of them open at once, and you will know which Layout is using each Event Sheet.
For Layouts, I usually take a simple approach of naming them what they are, e.g. "Title", "Level Select" and "Game Layout". I use a common name convention here (first letter uppercase, space between words) because layouts names are most often used as strings in expressions.
An to keep it easy to know which Event Sheet is connected to which layout, I simply add an "@" symbol before it, so they end up being "@Title Sheet", "@Level Select Sheet" and "@Game Layout Sheet".
And then we have independent Event Sheets, that we will explain in more detail later. They are used for code that is not directly tied to a single Layout. For this reason, I name them as I named the layouts, without a "@", e.g. "Movement Sheet" and "Shooting Sheet".
As for Layouts, organization helps you keep things in order (so no object appears below an object it should appear above) and to keep the amount of objects on screen low, so you can work with only the objects you need to.
I usually separate them this way:
Background: keeps background pieces, such as scenery, floors and walls.
Sprite: to hold most objects, such as the player, enemies, bullets, etc.
HUD: to keep HUD elements, such as life bar and score.
Menu: for objects that appear when you open the menu.
Debug: for objects that are part of debugging the game. Mostly text.
And if needed more than one, I just add a number after, e.g. Sprite2.