Programming best (and worst) practices

0 favourites
From the Asset Store
Best car suspension with spring effect and very cool terrain generation.
  • Yann

    Yes, I'm speaking having not yet finished my first project in C2, so I don't pretend to be right... in any case, I work using the "uncompressed" project (so no capx, but all the folders "exposed") and the events sheets opened in the notepad++, to speed up searches and cut&paste operations.

    In any case, probably with bigger projects I will came to your point of view, but at the moment I don't find any particular issue in projecting the workspace in this way :)

  • Jeff Skyrunner

    Yeah I'm still a bit shy as far as playing with the xml files.

    For now I just use .bat to commit some changes when I work on game series.

    I just split my event sheet into a common event sheet for the engine, and a specific event sheet for specific differences per games in the series.

  • Hi all,

    - Save a new version of the project often so you can go back if you mess something up

    Instead of doing that, use Git / SVN, way more professional, but mostly important, a bazillion times safer and manageable <img src="smileys/smiley4.gif" border="0" align="middle" /> "There is no software development without a control version system".

  • If you sit down to write you code with a pen and paper, I find the best method is to work with 'states'.

    This is because C2 runs events every tick you need to know what state the program is in at any one time. It just simplifies the workflow.

    I create global static variables with each possible state and a global variable containing the current state. I also use states for individual objects.

    So instead of activating/deactivating groups use states in my opinion.

    Otherwise all the comments above sound good.

    Having an outline on paper is certainly a good idea. Some of my best code is done in psuedo code first.

    As for global state variables. I disagree.

    * you can potentially clutter up the global variable space.

    * the state is checked every tick.

    Personally a model I'm working with is this as a design scope. Which is why i disagree with the idea of global variable based states. This is just a sample and not a literal. By enable and disable group. I am enabling and disabling the groups of functions that can be bound to a state. Where as if I'm working with state checking; the design would require an added level of that state check. This way there is no state check. it's just doing.

    every tick

    -> PLAYER.EVERYTICK

    button pressed

    -> PLAYER.ATTACK

    ----------------------------

    Ground Group

    On Function - PLAYER.ATTACK

    On Function - PLAYER.EVERYTICK

    ----------------------------

    Air Group

    On Function - PLAYER.ATTACK

    On Function - PLAYER.EVERTICk

    ----------------------------

  • Exacly the kind of topic i was looking for. I asked a similar question. You nailed some very good practice and confirmed my approachs as good ones.

    I also believe this topic, maybe as a tutorial, should be sticked somewhere.

    I found myself coding in similar fashion as Yann :)

    I see many "big names" here. Hopely some absent respected members could throw their two cents.

  • Personally I've found a way that works well for me (I think it's very similar to others mentioned here). I have a folder called "Common" where I put the event sheets shared across multiple Layouts, and another folder for each layout where I put layout specific stuff. In the "Common" folder, I put event sheets such as "HUD", "HUD - Minimap", "Weapon - Hits", "Weapon - Selection", and so on. I name it this way so that related event sheets stick together when sorted alphabetically. The name also reflects the inheritance: The "HUD" event sheet includes all the "HUD - ????" sheets, "Weapons" contains all the "Weapon - ???" sheets, and so on. In each event sheet for each layout, I just have to include 2-3 main event sheets, which in turn include all the rest. ;) I find breaking down the sheets this way keeps them all very small and manageable. In addition, it helps to easily and quickly find the sheets I need.

  • In each event sheet for each layout, I just have to include 2-3 main event sheets, which in turn include all the rest. ;)

    JoyfulDreamer You could even include all your "levels" layout event sheets into one "global" event sheet and then you would not have to include anything for each layout/"level" ;)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • This is all very interesting.

    In my opinion, it's best to use a small amount of object types. For example, there's no need to have a 'tree' and 'rock' object if they have an identical function.

    I'm interested in the alternatives for this? Isn't it easier, when building scenes, to have semantic objects for greater clarity? Don't families serve the purpose of grouping functionality?

    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.

    Totally agree with this. It would be great if we could add/remove and loop through layers at runtime and if inheritance layers made an appearance!

    As far as I'm concerned, after working on some big projects, I noticed that I was losing tonnes of time looking for pieces of code in all my event sheets.

    I agree with Jeff Skyrunner regarding event sheets. I too find the integrated search poor, so when wanting to search across multiple event sheets I use a text editor to search all xml files in the 'Event Sheets' folder. Ashley perhaps this highlights some potential search improvements :)

    Most has already been covered but I'll add this:

    I use families for any functionality. If I have an enemy, I create an enemy family, if I have a button, I create a button family. On a large project, functionality always ends up being duplicated at some point and upgrading the logic from objects to families is a pain and sometimes dangerous (despite being made easier recently).

  • This is all very interesting.

    > In my opinion, it's best to use a small amount of object types. For example, there's no need to have a 'tree' and 'rock' object if they have an identical function.

    I'm interested in the alternatives for this? Isn't it easier, when building scenes, to have semantic objects for greater clarity? Don't

    I suppose it depends heavily on the game - but object clutter is often a problem in beginner projects.

  • > In each event sheet for each layout, I just have to include 2-3 main event sheets, which in turn include all the rest. ;)

    JoyfulDreamer You could even include all your "levels" layout event sheets into one "global" event sheet and then you would not have to include anything for each layout/"level" ;)

    As long as all layouts are the same thing. In my case, not all layouts function the same. ;) The common event parts have a global event sheet for a specific subject which can be "inherited" into layouts as I need them. I think, other than families, this is one of the best things C2 has done thus far towards modular development. :) You can almost think of sheets like plugins as well, for example, to have a few sheets for different enemy behaviors, then include whatever sheet you need for a layout (for example, better AI logic for higher levels), or include all sheets, each one wrapped in a group so you can enable/disable as needed.

  • I just love creating own event sheets for stuff that requires lot of code and I use functions for the smaller stuff. I usually create level event sheet like Level_1_Code that's empty. I will then choose from my library of event sheets what that level requires, like Timer_Code, Night_Code, Rain_Code, Fog_Code. To me it's easier to find and modify things that I can easily locate with obvious names.

  • Yup ! Some of mine ... are !

    ......

    - Dump all your objects on a layout so they won't interfere with the main layout

    ........

    Cheers !

    Can you elaborate on that?   Will it help with performance?

    TY,

    Ed

  • Squirrely1

    It's a good idea to do this, not for performance reasons, but because C2 requires at least one instance of every object to be on some layout, so that it can use its initial parameters when spawning the object. Putting the objects on an unused layout is a nice way to go about this.

  • sqiddster

    TY

    So it's more for clean development and will not render a performance issue.

    Still it's cool. I can just create a blank layout and place all the flotsam object instances on that. And C2 will spawn/generate on the active layout as needed?

    Ah, I can already feel the mental relaxation I'll get from not having to look at a junkpile of objects while trying to create an asthetic.

    I'll try it.

    TY

  • I love the junkpile layout idea...I'm adding one to my project now. <img src="smileys/smiley4.gif" border="0" align="middle" />

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