Many sheets and folders in a project

0 favourites
  • 15 posts
From the Asset Store
With this template you can create your own archer game and customize it however you want.
  • Now I am making my second game in C2 and I want to do the code a bit more confortable and work in the best way to do it. I have a question: I want to do folders and subfolders for layouts and event sheets... so, I am goint to work more with functions in separate sheet, global variables in separate sheet and so... can this make the game more slow?

    Thanks in advance

  • It all depends how you do it. As long as the event sheets you include don't have unnecessary evaluations every tick, it shouldn't be a problem. As onFunction events are real triggers, this will not influence the performances.

    For more intensive group of events that act only on one object, you could put them in a group and toggle activation of this group on creation/destruction of the corresponding object.

    To sum up, what you want to do is CPU friendly as long as you include only what you need where you need it.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I do this and haven't seen a problem. Remember that when you export, it compiles it together. The folders etc are just for our benifit, and for us to group, segment, whatever we want.

    I like a main eventsheet with groups and includes to other event sheets. This way i can turn on/off sections of game. I build everything in groups/sections (self sustainable groups if I can)

  • DUTOIT Guizmus Thanks!

    I want to work with the best practices I can... I get more relaxed with your advices. I want to works as you say DUTOIT, with groups and sections... As say Guizmus, I suppose is a very bad practice do not destroy what you are not using... and I think for do this you have to organize the project in the correct way... Ithink isn't easy do this for me at moment, but I will try... any advice about nice practices?

  • DUTOIT Guizmus Thanks!

    I want to work with the best practices I can... I get more relaxed with your advices. I want to works as you say DUTOIT, with groups and sections... As say Guizmus, I suppose is a very bad practice do not destroy what you are not using... and I think for do this you have to organize the project in the correct way... Ithink isn't easy do this for me at moment, but I will try... any advice about nice practices?

    I come from php programming and C# so I like OOP.

    Adivice? None, really because each has his own way of doing something - but one thing is universal - COMMENT EVERYTHING - lol. Spend more time commenting and be as detailed as you can.

    shortcut is "q" Every event hit q and write what it does and needs to work.

    Other than that. Able/Disable groups is a lifesaver

    and nothing wrong with toggle able/disable events. Don't delete until you are happy new event is better than old.

    And Bookmarks are cool too.

    Learn them and there shortcuts.

  • DUTOIT thanks!!!

    Ok then:

    *To be careful with certain events as "every tic".

    *Organize with folders and subfolders.

    *Organize and use the groups in order to enable/disable itself, saving resources and reusing in other sheets

    *Comment everything with a lot of details.

    *Use bookmarks and shortcuts.

    Nice, thanks again!!

    Pd: Sorry for my poor english

  • Folders and subfolders have exactly zero impact on performance.

  • Folders and subfolders have exactly zero impact on performance.

    Ashley thanks!!

  • Here are some advise that might be useful.

    1. Clean up

    Objects that you don't need to be there from the start, by this I mean sprite objects that would be "Units", "Bullets" etc. you should destroy at the beginning of the game. This is simply to make sure that you don't have rogue objects in your program.

    2. Precise functions

    Make as small and precise functions as possible. Even though some of these functions might seem to simple for it to make much sense.

    And example of why this is a good idea. Imagine you have a "Car" and in you code you might change the speed, so you simply as you make the game, set the speed to what ever you think would be good. This would be fine until the moment you decide that it could be fun to add, if the speed gets above a certain amount that the car should start loose control. If you add it in your code you would have to change/test for it everywhere you might change speed, if you have a function you can simply add it here and update it for the whole program.

    3. Global constants

    This can be very useful for reducing spelling errors, and to quickly change things in your game. Imagine as the above example, that you have several car objects which are categorized by a type, "Cheap car", "Normal car" and "Expensive car"

    If you in your code manually add checks if ( Car.type = "Cheap car" ) and then do something, at some point you might figure out that this weren't that good, and it should instead have been something else, then instead of having to go through you whole code, you can just update 3 global variables.

    4. Use several event sheets

    Don't be afraid of using event sheets even though you might not add a lot to them. It will really help you maintain an overview of your game.

    5. Split events and functions

    Unless you are 100% sure that an event sheet should only be used one place, its always a good idea to split events and functions, even though they work on the same object. So an event sheet called "Car events" and "Car functions" would be a good idea. You can always move functions later on, but think it good practice to just get used to splitting them.

    6. Requirements and returns

    When making functions I find it very useful to add comments above them with requirements, and potential return values. This will make it very easy later on as you move along and might forget what a function actual does when you return to it.

    An example could be like this:

    7. Bug sheet

    Make an empty event sheet, that you just use for comments. You don't include it in your program. But the purpose is as you test your game and might be testing something, suddenly notice that something else is not working as intended. Then instead of fixing it straight away, you just in you "Bug event sheet" add a comment explaining what you noticed. And if possible the cause for it. Then you can always fix it later and you wont forget about it.

    8. Quick reference function sheet.

    This can be a bit time consuming but very useful. The idea is again to add an event sheet that you don't include in your program. But you simply add function calls to it, with the required amount of parameters.

    This can speed things up quite a bit as you can just copy/paste function calls from this sheet to wherever you need them, and just update the parameters, and you don't have to remember the name or how you spelled the function name etc.

    Other than that I think the other advise are good as well.

  • NIce!!!! nimos100 a lot of material for great performance here!!

    I like the bug sheet and Quick reference sheet. I am working too with many sheets and I am doing functions of the most simple of instructions lol and the requirements and potential return values is a nice idea!

    now I Know than folders and subfolders haven´t impact in performance, but what happen with sheets?... example now I am working in a game will have 30 scenes/levels. I am working with: Functions sheet, Variables sheet, Controls sheet, Bug sheet, quick reference function sheet and a lot of more...plus 30 SCENES sheet!!!! thats a lot of sheets... or I can use only one sheet for all scenes???

    I know Guizmus said that if you works fine you include only what you need where you need (CPU friendly) but I am a n00b already... so I don't know if I must works with decens of sheets lol

    Thanks!!!

  • While nimos100 might have posted good advice, I don't believe any of it will have any measurable effect on performance.

    For a pretty much exhaustive list of the things that can actually have a measurable impact on performance, see Performance Tips. Things not on that list are generally ignorable for performance.

  • [quote:2csun37y] I Know than folders and subfolders haven´t impact in performance, but what happen with sheets?... example now I am working in a game will have 30 scenes/levels. I am working with: Functions sheet, Variables sheet, Controls sheet, Bug sheet, quick reference function sheet and a lot of more...plus 30 SCENES sheet!!!! thats a lot of sheets... or I can use only one sheet for all scenes???

    I know Guizmus said that if you works fine you include only what you need where you need (CPU friendly) but I am a n00b already... so I don't know if I must works with decens of sheets lol

    Organizing sheets sounds really easy, but it can actual cause some problems, since its not uncommon that events/functions involved several things, so where should they go, or should you make a new sheet etc.

    The way I would do it, is to think about key elements or functionalities of your game. And turn these into event sheets.

    I wouldn't add a event sheet for every scene/level in a game, unless there are significant changes between them. Like level 1 is a platform game, and level 2 is a top-down shooter etc. Otherwise you might actually make several functions that do the same.

    Instead I would do something like this, it does of course depend on the game you are making.

    1. Game menu

    Will handle everything that have to do with the main menu of the game. Maybe not all the functionalities, but the initial settings. Like making sure that variable that should be reset are so, that rogue objects gets removed. Access to Load game so the player might only be able to press this button if there actually is a save game to load. Open game settings and exit the game.

    2. Game

    Will handle stuff that have to do with the general things that have to do when the player have started the game. This can be pause game, buttons that are on the game area. etc.

    3. Game functions

    Could add Hud updating here.

    4. Player controls

    Will take care of player controls.

    5. Player functions

    This can be functions such as reducing player health, player death.

    6. Enemy AI

    Will handle enemy movement.

    7. Enemy functions

    Same as player functions, except that its for enemies.

    8. Sound

    Handles sounds.

    9. Money / Score

    If you use a advanced system, that would require converting money etc. It can be useful.

    10. Map generator

    Will handle generating maps.

    11. Map functions

    If you need to manipulate the map, like destroying something etc.

    So instead of using 30 sheets for 30 levels, you will make use of several different sheets included into the game sheet. Since all 30 levels use some kind of the same things, like enemies, player etc. These are included, so your actual game area might have 8-9 sheets included.

    That's what Guizmus meant, since there are not reason to include the game menu into the actually game area, if the player shouldn't be able to start a new game from here or include it into the enemy sheet, as it have nothing to do with enemies.

    But yeah there will be a lot of sheets, but it doesn't really matter, if they are organized so you can quickly find what you need, it will be a lot better, that messy sheets, with no comments, no groups etc. Where you will loose overview at some point

  • While nimos100 might have posted good advice, I don't believe any of it will have any measurable effect on performance.

    Ohh...my post have nothing to do with performance, its was solely meant for organization of projects. Think I missed that part from the OP

  • nimos100 Still great piece of advice for any new developer. This isn't restricted to C2, it's great coding practice and will save a lot of time to anyone going for anything big. And for the experts, it's also a good reminder !

  • While nimos100 might have posted good advice, I don't believe any of it will have any measurable effect on performance.

    For a pretty much exhaustive list of the things that can actually have a measurable impact on performance, see Performance Tips. Things not on that list are generally ignorable for performance.

    Ashley thanks for the link!

    nimos100 nice!! I am implementing in my current project many things you said here. Now I am more relax about how to approach to the work. Really great!!! Thanks very much!!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)