If you're a C++ programmer or you have a good working knowledge of
OpenGL or real-time games programming and would like to contribute
code, contact the project admin
with a brief description of what you
know how to do and what you'd like to do. Be sure to check out
the ground rules
Don't feel like you have to
be a super-robo-coding-wizard or anything, this is my first game or 3D
project, and the first time I've started a C++ project from scratch.
Even if you're not a coder, we definitely have a need for the
- 3D modellers and animators for vehicles, structures, "splash"
screen movies, etc.
- 2D graphic artists for skins, terrain tiles, hud/game screen
- Ideas and concepts for game features (vehicles, weapons,
defenses, terrain/battlefield features, missions, campaigns, etc.)
- Writers for fleshing out a game world, producing pieces of short
fiction, defining the history and politics behind the fighting
- Documentation/playtest - it's almost holy writ that programmers
hate to document. :) If you'd like to contribute but aren't
technically inclined, help with user manuals, FAQs, HOWTO's,
etc. would be welcome.
- Playtesters for when we actually get a usable game. Before we
go GA, I definitely want to try to get a broad range of platform
exposure to fish out any portability bugs.
If you have any other skills or talents that you think would be
useful, let me know and we'll see if we can fit you in somewhere.
As a veteran of large programming projects, I can tell you from
experience that consistent coding style is more important than any
particular style's merits or flaws. The following are guidelines that
I'd like anyone contributing source to follow for new code.
Note: It's okay to leave legacy code (i.e. code reused from another
project or source) alone if it's relatively readable.
- C++ source extension:
- C++ header extension:
- C source extension:
.c Should only be used for
- C header extension:
- Member Attribute:
- Static Attribute:
- Accessors for member:
- Accessor for singleton class:
- Local or Parameter:
- Constant or macro:
- Class name:
Dos and Don'ts
- Graphics Data Format:
- Music Format:
- Sound Sample Format:
And the rest...
- DO comment your code - a sentence or two for each
class and for each non-trivial method and member. You don't have to
go nuts--the code should speak for itself if it's cleanly written--
just make sure somebody will be able to figure out what some code you
wrote does six months from now.
- DON'T use hard tabs - most *nix programs and utilities
use a default of 8 columns for tab expansion, which is way too much
for indentation of code (not to mention the fact that if anyone has
different tab settings, the code will appear all screwed up.) Most
editors should allow you to use "soft" tabs (expands to spaces
- DON'T use public class attributes - Make all attributes
private and reference them through get and set methods.
- DO put one major class per file with the file named after
the class (i.e. class
SomeClass should be in
helper classes may be combined in with the source file for the class
- DON'T use macros where constants will do -
const variables are just as efficient with a good compiler and
are much friendlier to the debugger. NEVER use macros in
place of functions - use inline methods instead.
- DO use your own judgement - I'm not going to be some kind
of style Nazi poring over everyone's code with a pair of tweezers and
a blowtorch. If you really need to violate a coding guideline, just
document that you did it and why.
- DON'T use C++ like it was C with classes. C++ is its
own language with its own paradigm for programming. In particular,
stay away from C style dynamic memory allocation (*alloc/free).
As far as indentation and bracing goes, use whatever you're comfortable
with for new
code that you're responsible for. Personally, I prefer
3 space indentation. When you're editting other developers' code, keep your
modifications or additions consistent with the original author's style.