Orx Config best practices/style guide

edited June 2012 in General discussions
I was hoping we could get together and create a best practices/best style guide for Orx config. Maybe something we could put as a wiki page?

Good organization of config .ini files is important in a larger project.

I'll start. Here are some things I do that I have found helpful for organizing the config.

- Use Hungarian notation for the section types. For example, call the sections [O-<name>] for an object, [G-<name>] for a graphic, [FXS-<name>] for an FXSlot, etc.
- Split the section types into different files. graphics.ini, strings.ini.
- Split game objects by scene. levelobjects.ini, titlescreenobjects.ini, sharedobjects.ini
- Indent two spaces for the objects that are part of a ChildList of an owner object
- New one, testing now: If I have a base object that's inherited and extended by a lot of child objects, I don't specify position in the base object. Every child object specifies its position explicitly (avoids confusion when reading the sections).

Any comments on the above? Any other tips that others have found?

Comments

  • edited June 2012
    acksys wrote:
    I was hoping we could get together and create a best practices/best style guide for Orx config. Maybe something we could put as a wiki page?

    Sounds like a great idea!
    - Use Hungarian notation for the section types. For example, call the sections [O-<name>] for an object, [G-<name>] for a graphic, [FXS-<name>] for an FXSlot, etc.

    I go with hungarian too but postfix instead of prefix. No real reason beside a matter of taste I think.
    - Indent two spaces for the objects that are part of a ChildList of an owner object

    Not sure I understand that one. Probably too tired. :) Do you have a short example?
    - New one, testing now: If I have a base object that's inherited and extended by a lot of child objects, I don't specify position in the base object. Every child object specifies its position explicitly (avoids confusion when reading the sections).

    As I use ScrollEd for most object placements, I don't specify any position at all beside groups of objects for relative child positioning.

    Also good to know: when your game is done, you can collapse all the config into one file and even encrypt it using orxCrypt. Makes a neat & clean release "package".
  • edited June 2012
    Indentation example:
    [Owner]
    ChildList = Child1 # Child2
    
      [Child1]
      ...
    
      [Child2]
      ...
    
  • edited June 2012
    Hi,

    The config module is used by orx to describe user data handled by orx, as showned in CreationTemplate.ini.

    But, maybe some users on this forum didn't realize that this module can be used to describe your own data, with your Key/Val. It's very very usefull to store/parse/load custum data. So, I just add this information here ^^
  • edited June 2012
    Good point! I discovered this through experimentation, but it's not so obvious from the docs this can be done. If we get to making a wiki page, it would be a good thing to add.
  • edited June 2012
    Mmh, I tried to point that out through all the tutorials I wrote but I guess it might not have been visible enough.

    But yeah, it's a key info to convey, for sure.
  • edited June 2012
    Any other points?

    A bit OT: Based on the feedback so far, my next Scroll tutorial will need to cover ScrollEd. Just as soon as I take the time to figure out how map loading works in Scroll..
Sign In or Register to comment.