Project Organisation Tips

18

Stats

2,528 visits, 3,418 views

Tools

Translations

This tutorial hasn't been translated.

License

This tutorial is licensed under CC BY 4.0. Please refer to the license text if you wish to reuse, share or remix the content contained within this tutorial.

When you're working on a small project, keeping things well organised is a good habit, but not essential. However, when your project begins to grow, and you have fifty different objects all named Sprite, you might find yourself struggling a bit. There are plenty of different ways you can organise a project to keep it under control - not just for your own benefit, but for anyone else you might show it to later down the line!

Naming Conventions

When you add an object into Construct, you can name it, or Construct will assign a name for you. The latter is great when you only have a handful of objects. But it's a good idea to quickly get into the habit of naming your objects appropriately. Otherwise you could end up with a massive list of objects: Sprite1, Sprite2, Sprite3 and so on. Not particularly intuitive when you're looking at it.

There are tons of different conventions you can use, or you could create your own - the important thing is to have something that works for you. For instance you could use snake_case or camelCase. Or you could label every event sheet with an e at the start like eMain, and every array with Arr like ArrInventory. There is no right answer, it's all down to personal preference.

Separate Event Sheets

Having one big event sheet is fine, but it can be easier to manage if you break your events into smaller blocks. For instance having one sheet to manage all of your global events, one for an inventory, one for enemy AI and so on. Take a look at Kiwi Story for an example of this in use.

Splitting out your events can help you keep track of what does what, and save you from searching through a large event sheet looking for a particular thing - especially if you're trying to track down a bug! Multiple event sheets may take a little extra planning - for example what should be available to the entire game, which mechanics need to talk to each other etc. But it might save you time in the long run!

Just remember to include your additional event sheets where you need them! And don't worry about accidentally making an include loop - if two event sheets include each other, Construct will still read both sheets, but only the once. You can include an event sheet by opening the right-click menu in the event sheet view, or by pressing the N key. There's more detail in the manual.

Comments

Comments are simply notes that you can add to your event sheet. You can add a comment from the right-click menu or by pressing the Q key. These little notes can be vital for understanding a project. Whether you're going back to an old forgotten game, or you're writing a tutorial for others to use, adding comments means you can easily explain what a specific thing is doing - right down to action level.

You can also add BBCode formatting and colour to your comments to make them easier to read, or colour coordinate them. Red could be something that you're going to remove, yellow something that needs to be refactored and so on. I've used comments to write my own todo lists and instructions on how to play a tester game. There's loads you can do with them and they can really help improve the overall ease of understanding of a project.

If you've got an empty event sheet, comments can quickly turn it into a notes sheet. This is a great way to record information while staying within Construct. If you've found an issue in your events that you want to come back to later - write the details in the notes sheet so you know what the issue is and which events are the likely culprit. Or perhaps you've been hit by a flash of inspiration for something to add to your game - jot it down in a comment for later. You can even use an event sheet as a to-do list so you can keep track of your tasks all without leaving Construct.

Groups

Event sheets allow you to place events into their own groups and sub groups which can be a great way of keeping things organised. They can be individually named and you can add a description which display in the group header. Groups can be added from the right-click menu or by pressing G in the event sheet view.

You could have a group for all of your startup related events and another for functions for example. Plus, you can activate or deactivate entire groups with the Set group active system action. Groups can also be customised in terms of colour, like comments. This is great for setting up a colour scheme so you can recognise what certain groups do very quickly - red for dialogue, blue for inventory, green for global groups... You get the idea.

Subfolders

Subfolders are a great way to organise groups of similar objects and can be found in a couple of places in Construct.

In the animations editor for example, you can create subfolders to store groups of animations. Just right click in the Animations Pane and you can add subfolders. Let's say you have one sprite that holds the animations for several characters. You could have a subfolder for each character design that contains their Idle, Walk and Run animations.

In the full version of C3, you can add subfolders to the Project Bar which is a huge help in organising a large-scale project. Subfolders can be added by right-clicking a parent folder. Remember though, subfolders can only hold items of the same type - so you can't put your layouts in with your event sheets, but you can group sprites with a spritefont for example because they're all Object Types within Construct.

Function Categories

In the same sort of vein as Subfolders, Function Categories are a simple way to make your life easier. When you create a function, you have the option of adding a category:

Now, this is completely optional, but if you add a category, the next time you need to add a function, the list of functions will be broken down into sections - similar to when you add other kinds of actions. Taking Kiwi Story as an example, without categorising functions, the Add Function dialog looks like this:

By adding just two categories (granted this project doesn't have that many functions, but it'll do for an example) it now looks like this:

Getting into the habit of categorising your functions when you make them, can really make your life easier in the long run, especially if your project grows to include dozens of functions!

These are just a few ways you can organise your project and while they may not seem important to begin with, they can really help keep a larger project under control!

  • 7 Comments

  • Order by
Want to leave a comment? Login or Register an account!
  • I completley forgot about function categories, thanks for the reminder! :)

    I have a few organisation tips on my own: I'm also a massive fan of using multiple event sheets; I have a "main" one (which is assigned to a layout) and which is also completely empty apart from event sheet includes.

    I divide the rest of the sheets into 3 subfolders: EventHandlers (and I also prefix their name, eg. eCollisions, eTimers), Functions (only for functions: eg. fEnemies, fPlayers) and Values (only for global variables: eg. vConstants, vState). Only "EventHandler" sheets have to be included in Main, since all functions and variables are available without including their sheet. Lately I've also been adding emojis at the end of event sheet names so I can find them quicker when there are a bunch of tabs open.

  • A very good article, packed with words of wisdom!

  • This is great advice, I use these methods when making games it saves you headache and confusion down the road. especially a big game project like mines. I learned this lesson the hard way and had to restart on developing scripts.

  • salutes

  • wow thank you i havent made any games yet how do you make some?