Team members, please discuss anything that has to do with programming here.

I think we should flesh out the game idea a bit more before the development starts.

Pushing the game design document and adding details about the audience (who should buy the game/play the game), the main characters in the game, the environment (where and when),...

These are important questions for the gameplay, controls, game physics,...

Is it a story based game?
Is a arcade mode possible? (depends on the audience)

No - these are no pure programmers questions, but they don't fit into the other categories alone either.

Is it possible to make regular geometry that isn't a wmb or model respond to code by selecting one of its flags in properties? I created a level whose certain geometry I wish to fall when the user presses a button, but I'm hoping I can save the step of building this geometry separately then reinserting it into the level.

If you want to interact with things in this engine, it has to be a separate model. You have to assign an action to the entity in order to use the custom flags (flag1-8) in WED. Otherwise there would be no way to query the flags in-game later.

I have my own template project going on. Among the features are a configurable state manager, an inventory and a control setup manager.
I still need to work out some things and improve the flexibility. I don't know if parts of it are useful for this project, but if it is not urgent (means not before march) I'm willing to contribute some of the templates.

Code is built up modular, so inclusion into any project is easy. Lite-C is required, though.

Thank you, this would be great.
Do you like to post some code samples that can be used for a kind of "coding style guide"?

This would ensure that we have the same naming convention, etc.

Well I have my own coding guidelines. If I find some time I can of course illustrate why I'm naming things like I do, but I'm not sure if everyone would be ok with this.

Wenn es zu abgefahren ist, sollten wir davon vielleicht doch lieber Abstand nehmen... War nur so ne Idee, weil du wahrscheinlich die größte Code-Basis zur Verfügung stellst.

Haha... guter Witz. Ich komm seit Jahren zu nix mehr

-----------

Ok I'll try to sum up my naming conventions.

Variable prefixes:

vec - VECTOR
ang - ANGLE
pan - PANEL*
txt - TEXT*
ent - ENTITY*
fnt - FONT*
view - VIEW*
bmap - BMAP*
par - PARTICLE*
snd - SOUND*
(note that engine objects are always pointers, so I did not use a further 'p' prefix to mark it as pointer)

c - char
f - float
i - int
l - long
v - var
s - struct
p - pointer
pp - pointer to pointer
pf - function pointer

e.g.
vTemp would be a var.
psData would be a pointer to a user defined structure
panDisplay would be a PANEL
vecTemp is a VECTOR
pvecTemp is a VECTOR*

Global variables always get a module prefix consisting of 3-10 capital letters.
<unit>_xxx: global variable which may be accessed by other units (should be avoided)
<unit>__xxx: global variable which is only used in the module wher eit was defined.

e.g.
LIST__vNumEntries: global var of the module 'LIST'. Not to be used outside the LIST module.
LIST_vReady: project global var defined int he module 'LIST'.
iParameters: local int variable. This naming may also be used for struct elements.

Function can either be global as well as local. They follow pretty much the scheme for variables above:
<unit>_xxx: interface function to other units
<unit>__xxx: module internal function

e.g.
LIST_getEntries(): interface function ready for use in other modules
LIST__process(): some internal function which must not be used in other modules

Core variable/function names (resembled by 'xxx' in the rules):
Are always CamelCase.

e.g.
vCamelCase
CAMEL_camelCaseFunction()
CAMEL__psCasedCamelCase


Example from my side: http://firoball.de/stuff/toolbox_manual/list_8h.html

If you like it, feel free to use, otherwise: no problem.

If there is more interest in this, I can also sum up some of my core rules for writing readable code.

My Code is modular, this means syntax is not so important as everything is exchanged via functions.
So you would end up having some template subfolder with all my crap inside and simply use the provided interface functions.

But at the moment I'm not set for the team anyway, as I cannot guarantee free time until march.
So maybe instead it should be discussed which code parts are already there from people able to work on the project right away.