Game-specific Code in Src/Common (3rd Party Game Development)

edited 2006 Feb 1 in Developers
<i>This post was originally made by <b>danij</b> on the dengDevs blog. It was posted under the categories: Games, Version 1.9.</i>

Currently, code common to all games in <tt>Src/Common</tt> is interspersed with game-specific functionality (due, no doubt, to the difficulties of combining three different source codes). I understand that an ultimate goal is for all code in <tt>/Common</tt> to be truely common, but to reach that end requires a lot of work - hence the use of (eg) <tt>#ifdef __JDOOM__</tt> to branch the code where logic differs.

I noted recently (when begining work on a new game library) that this method of branching the logic is difficult to work with for a 3rd party game developer, as the same <tt>#define</tt>s are also used to control header inclusion (in <tt>Src/Common/*.c</tt>).

<!---more--->I think that most new games will probably begin life as modifications to an existing game (hence the logic will be (mostly) the same) but the included header files will not.

It would be easier for 3rd parties if there were two preprocessor directives - one to declare the logic and another to determine which game headers are included in common source code files. This would allow 3rd parties to quickly create a new "project" under a local copy of the source tree, making tracking changes in the offical source tree much easier.

Comments

  • When it comes to creating a new game lib, I would guess the best solution would be simply to use one of the existing <tt>__JDOOM__</tt>, <tt>__JHERETIC__</tt>, or <tt>__JHEXEN__</tt> #ifdefs. If you don't use one of those, it's effectively saying that a new branch of logic is introduced.

    A new game lib could #define its own <tt>__GAMELIB__</tt> in addition to one of the <tt>__JDOOM__</tt>, etc. defines.

    The problem with header files is that they are differently named and have different contents in each game. If the naming and contents were rationalized (even using higher-level header files that include other, game-specific header files), it would make things a lot simpler as the #includes wouldn't need to be #ifdeffed.

    In other words, a source file in <tt>Src/Common/</tt> would only include headers with the prefix <tt>gc_</tt> (Game Common), which would be located in each game lib's include directory. The compiler's include path would need to be set up so that it first looks in the game lib's include directory when compiling a game lib. The <tt>gc_</tt> headers would then include one or more game-specific headers as appropriate. The good part is that there shouldn't be need to have more than two or three <tt>gc_</tt> headers per game, grouped by functionality.
  • <blockquote>
    The problem with header files is that they are differently named and have different contents in each game. If the naming and contents were rationalized (even using higher-level header files that include other, game-specific header files), it would make things a lot simpler as the #includes wouldn't need to be #ifdeffed.
    </blockquote>
    Thats a point, that would work too.</p>
    <p>I've already reorganised the jHeretic headers into the same layout as jDoom, so once I've done the same for jHexen I'll restructure them all as per your suggestion.</p>
    <p>I'll see about revising all the games' headers into a leveled structure (similar to the engine).</p>
Sign In or Register to comment.