Author Topic: Best Practices for Structuring a Game's Source Code  (Read 1225 times)

JAH2488

  • Member
  • **
  • Posts: 32
  • Karma: +0/-0
    • View Profile
Im currently in the process of refactoring and extending my LudumDare entry into a full game and was wondering if there was a common way of organizing/structuring code, classes, asses, etc among the flixel community (or the larger flash dev community). I've found the learning other conventions has aided my own development and wanted to ask.

Currently I have my source file layer out like this.
Code: [Select]

Src/
    -
    Assets/
            -
            Images/
            Sounds/
    Com.jah2488/
              -
              Items/
              Mobs/
    Org.flixel/...


All of my states are top level as well as my registry class.

auriplane

  • Snails!!
  • Contributor
  • ****
  • Posts: 497
  • Karma: +1/-0
  • Snails!!
    • View Profile
Re: Best Practices for Structuring a Game's Source Code
« Reply #1 on: Mon, Dec 26, 2011 »
I don't know what other people do.  I'll post my thoughts, though.

As with most things, the answer is "it depends".  If your project is tiny, flat works.  If you have a large project, you might have a hierarchy three levels deep underneath "Images"!  I'd start by making sure I've got the tools to refactor quickly.  Drop any tools like CVS that make moving files hard, and make sure anything in the source tree is easy to update.  Then, start with a basic structure and refactor as soon as it becomes apparent you need a larger hierarchy.

IOW, I want to end up with the simplest layout that works for a project, but no simpler.  Since scope tends to creep, that'll probably grow beyond what you think it should be when you start out.

That said, if you want a one-size-fits-all solution, and you don't want to refactor often, err on the side of overengineering.  Underengineering sucks.

JAH2488

  • Member
  • **
  • Posts: 32
  • Karma: +0/-0
    • View Profile
Re: Best Practices for Structuring a Game's Source Code
« Reply #2 on: Mon, Dec 26, 2011 »
That makes sense. Thanks for the input. I agree that it really does depend and I would hate to spend time fiddling with file structure instead of actual game design, but I also just wanna make sure my code is neatly organized.

I used to be a big fan of flat file structures in nearly all cases, but as I used the Rails framework (in my day job) more and more, I begin to see how nice it can be to have a predefined area for every type of file. its just less thinking you are required to do, but also keeps things "clean"

IQAndreas

  • Member
  • **
  • Posts: 35
  • Karma: +0/-0
    • View Profile
    • IQAndreas.com
Re: Best Practices for Structuring a Game's Source Code
« Reply #3 on: Mon, Dec 26, 2011 »
Just a few minor notes on the matter (and I am by no means a professional). None of these are actual "requirements", but personal practices I keep to keep code easier to manage.


Folder organization
This is typically how I organize my projects (and how most "Eclipse-based" workspaces are set up by default):
src - The source code for that specific game.
lib - All external libraries that are not specific to your game (often in SWC format for ease of use and faster compile times)
bin - Where the SWF gets compiled to. Sometimes there is a "bin-release" and "bin-debug" just to keep the debug version separate.
assets - Some people place this folder inside of the "src" folder, I place it in the top level folder, Flixel places it in the "org/flixel/data" folder. I wish there was a proper standard, but this one seems to vary quite a bit.

I'd like to emphasize something about the first two folders, "src" and "lib". The src folder should ONLY be used for code used for that specific game. For instance, I'm assuming you use Flixel for several of your projects, so keep that in a separate "lib" folder. That way, if a new version of Flixel is released, you can remove the old version, put the new version in without needing to meddle with your "src" folder. It will also make it clear to other developers which classes are your own, and which are from outside sources.

I would recommend learning how to use SWCs. That way, you don't need to mess around with folders of files each time, you instead have one bundled up, easy to move or update file. (but SWCs for me are just a personal preference)

Keep folder names all lowercase - (such as "src" instead of "Src") Some Operating Systems are case sensitive on folders, others are not. You can avoid any trouble by playing it safe and always using lowercase (but .as files still need to have the same case as their class names).

Don't use the top level namespace - Just don't do it. You may be forgiven if you have one single "Main" or "MainTimeline" class, but otherwise, don't. ;)


And a final note, worry more about your actual code convention (making sure to leave comments, logically group functions and variables, avoid really big classes) as that's what you will be staring at 98% of the time.


That's all I can think of at the moment that deal specifically with folder structure. :)


EDIT: I am so sorry, I reread your posts (I had just skim read it the first time around). I did not mean to be condescending in any way, I just assumed you were new to programming looking for beginner advice. :-\
« Last Edit: Mon, Dec 26, 2011 by IQAndreas »

JAH2488

  • Member
  • **
  • Posts: 32
  • Karma: +0/-0
    • View Profile
Re: Best Practices for Structuring a Game's Source Code
« Reply #4 on: Mon, Dec 26, 2011 »
All great tips.

I'll keep those in mind. Thanks.

I tried putting in my top level namespace, but I had some issues with Flixel finding states when they were in packages so I just moved the states up to the top level. Perhaps I was just requiring the files wrong. I'll look into it again.