Results 1 to 7 of 7

Thread: Clean code is *good* code...

  1. #1

    Clean code is *good* code...

    I've been developing games in Delphi for a few years now, and I've really enjoyed that experience. However, I find that as my projects grow bigger, my code is becoming more and more unwieldy. In fact, I've quite a few recent projects because of the clutter that my code was becoming, and was just too difficult to maintain.

    I keep all of my code in one file. I realize that this is bad practice, but I was taught Delphi in that sense, and I'm having trouble adjusting to making a multiple-file project with Delphi that is properly organized. Arg.

    What I'm looking for is some advice regarding code structure. What's the best way to layout your project in files, and classes and procedures, etc? Any tutorials located on the matter would be appreciated as well.

    Thanks!
    Game-Dev Journal: http://skirmish.dreamhosters.com/devlog/

  2. #2
    Legendary Member cairnswm's Avatar
    Join Date
    Nov 2002
    Location
    Randburg, South Africa
    Posts
    1,537

    Clean code is *good* code...

    All my game consist of a single form that has various looks to it (Intro, Game, Game Over etc). The form and the drawing routines for each game state are kept in a single file.

    I create a second unit for in game objects. (Occasionally this is more than one unit). In this unit I keep the class declarations for each object in the game - this is typically a Map/Board Class, An Objects Class, an Item Class and a Person class. All this is stored in a single unit though I often move the Map class and Cell (squares) classes into another unit.

    If my game uses a lot of external type communication - encryption, web live etc I create a Data module to put it into.

    Common stuff used in all my games gets its own unit - High Score Lists for example.

    Thats the way I do it - I'm busy on a set of tutorials on game programming templates - but I'm only half way with number 1 of 14.
    William Cairns
    My Games: http://www.cairnsgames.co.za (Currently very inactive)
    MyOnline Games: http://TheGameDeveloper.co.za (Currently very inactive)

  3. #3

    Clean code is *good* code...

    A few words on this matter:

    1) Delphi is great when it comes to object oriented programming. So it's always a good idea to encapsulate a lot of stuff into objects. Like for example all the graphics routines, sounds routines, the routines for loading data files, etc.

    2) Put code that you think you will have to change a lot into a DLL.

    3) Put constants in an extra Unit.

    4) Comment your code well

    5) Follow the Object Pascal style-guide

    6) Procedures and functions are your friend.
    Ask me about the xcess game development kit

  4. #4

    Clean code is *good* code...

    The following is the way I organise my code:

    Create an object-oriented set of classes and put each class into its own, separate file (perhaps more than one per file, but that's usually ill-advised except for very small classes).

    Next, create a unit that has various global constants, if you're using any. There should be a unit that declares different, common types if required. Use a unit for common utility functions if required.

    I create a folder hierarchy - one called "source", and one called "data".

    The source folder contains extra folders ("temp" for .dcu files, "utilities" for extra tools like editors you write, and directories for sub-sections (e.g. Input, Sound, Network, etc.)).

    I set the .dcu files to be compiled into the temp directory (keeps things a mite cleaner). This is available under Project Options, Directories/Conditionals, "unit output directory". Keeping your .dcus separate makes things much easier.

    I keep my code inside the "source" folder. I use the Project Options, Directories/Conditionals, "output directory" to specify that the exe should go into the parent directory ("..\"). This ensures that the exe is easy enough to find and run - it won't have any crap surrounding it.

    The "data" folder contains actual game data (levels, graphics, sounds, scripts, etc.). You can create a sub-directory hierarchy here if you want (I do), although the intention is simply to ensure that the data is separate from the source code, which is separate from the main executable.

    Make sense?

    I'll try to post a better explanation later, and I'll also link to an example project when I get home. It's time for lunch now though
    "All paid jobs absorb and degrade the mind."
    <br />-- Aristotle

  5. #5

    Clean code is *good* code...

    Thanks a lot all of you for your input! Especially Alimonster for the tips in keeping the project files organized.
    Game-Dev Journal: http://skirmish.dreamhosters.com/devlog/

  6. #6

    Clean code is *good* code...

    just to expand on it

    i use nearly the same method as alimonster except mines layed out like this. ill use my game as an example

    Code:
    C&#58;\Projects\racer\
         ... Bin - holds the exe and game data
    
         ... Code - holds the project dpr and things
    
             ... directx - holds main headers
                 ... dx8_framework - dx8 specific stuff
                 ... dx9_framework - dx9 specifics
    
             ... opengl - opengl header and texture loader etc
                 
             ... modules - my codes here &#58;&#41;
    
                 ... input - keyboard.pas, wheel,pas &#40;includes ffb code&#41;, main.pas&#40;controll assignments etc&#41;
    
                 ... gfx - all files for gfx engine, renderer loader etc
    
                 ... sound - all things for sound &#58;&#41;
    
         ... DCU - unit output
    i find that the more organised the folders the easier it is to get to a procedure

  7. #7

    Clean code is *good* code...

    The project I am currently working on (not a Delphi project, it's C++, but project organisation is more or less language independent) has approximately 300-350 source files plus corresponding header files. That's just the game itself. The multi-platform engine has yet another pile of source and header files plus a middleware layer that has another 60-odd source files plus header files. Now think of maintaining those source files in several different projects for different platforms (VS.NET 2003 for PC and Xbox, CodeWarrior for PS2 and CodeWarrior for GC).

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •