• Loiosh (Jason Steele)     Project Admin
  I'm a 31 year old software developer living in the Dallas-Fort Worth Metroplex in Texas (USA). In the past I've worked in the embedded telecomm industry doing real-time C and server-side Java. My current job is as a real-time embedded C developer for a optical telecom startup.

  Big Iron is my first open source project, my first game and my first major C++ project. I'm doing this partly as a learning experience and partly because I was a big Starsiege nut and it doesn't appear that Sierra is ever going to release a new version again.

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 first.

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 following:

• 3D modellers and animators for vehicles, structures, "splash" screen movies, etc.
• 2D graphic artists for skins, terrain tiles, hud/game screen design, etc.
• 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.

Files

• C++ source extension: .cpp
• C++ header extension: .hpp
• C source extension: .c Should only be used for legacy code
• C header extension: .h

Identifiers

• Method: someMethod()
• Member Attribute: m_some_member
• Static Attribute: s_some_member
• Accessors for member: class->getSomeMember() and class->setSomeMember(val)
• Accessor for singleton class: SomeClass::getInstance()
• Local or Parameter: some_variable
• Constant or macro: SOMEMACRO
• Class name: SomeClass

Data Formats

• Graphics Data Format: PNG
• Music Format: MOD or MP3
• Sound Sample Format: AU or WAV

Dos and Don'ts

• 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 immediately.)
• 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 SomeClass.cpp and SomeClass.h. Auxilliary helper classes may be combined in with the source file for the class they assist.
• DON'T use macros where constants will do - static 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).

And the rest... 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.