As long as I don't see ANYTHING concrete from the gamedesign part, there's little use in discussing what we can build. But the naming conventions etc. is nice. I use my own conventions on personal projects but it doesn't differ that much.

It's possible to list the core modules we will need. There are thigns we need anyway, like:

[see below]

keep it coming. I'll transfer this list to the Brainstoring Etherpad right now...

edit: I won't add more units here. it just spams the thread. Placed everything in the Etherpad now.

-special effects module
-level controling/highscore control
-puzzle/riddle module

EDIT: tutorial module (or name it help module)

if it's not involved in the level controling module, then:

-saveing/loading module

Thank you for your guide lines and your doxygen toolbox.
Your naming conventions is not that strange - to be honest, it is very similar to my style. Well, try to survive without naming convention in a winapi based project... if you know what I mean.

About the modules.
Some modules like the menus, option screens and maybe key assignment (if you mean the visual aspect) depend on the style of the game.
Panels can slide in, fade in or simply appear.
Animation? It is undefined if we need 2D anims or full 3D.

I don't want to prototype a game prototype and throw the few hours per week away following a moving target.
We need to define game development related things, cut them into modules and assign them to the developers.

This is just my opinion and maybe there are different ideas about the next steps.

I fully agree on that.

With the module list I intended the following:

We don't know whether it's 2d (sprites) or 3d (models), but we do know we will need animations. So we should have a unit dealing with all animation stuff. The exact content is not known yet, as it depends on decisions which way to go.

But it is possible to split the code into parts for better overview.

I think that we should start with 3D stuff; we've got built-in collision detection that works fine with it. Creating models and animating them shouldn't be a problem; we can use placeholders at the beginning and buy and replace them later (if needed).

A view with ISOMETRIC flag set should deliver a nice 2D view of 3D stuff when setup correctly.

See Joozey's Key Perilous as example. It uses the ISOMETRIC flag to fake a 2.5d isoemtric landscape. Full 2d is just a different viewing angle.

==> It should be no problem to use 3d and all advantages the engine gives us this way without losing the possibility to have 2d look.

Sure, that's what I was thinking.

Don't be fooled, collision detection was the biggest bother in Key Perilous. My own 2D collsision detection is way more reliable . But you don't hear me complaining when doing 3D. Just stating the facts.