OK, HERE WE START (ENGINE CONSTRUCTION DEBATE)

[rein]

so, independly on what we decided (2d/2.5d/3d), we MUST start to write ANYTHING (as i see, everything goes in a way of using opengl in 3d env, so my engine is useless here - almost everything would need to be recoded), before whole project die. Let's start off by choosing compiler:
IMO without doubt the BEST one is MSVC

Than we need to arrange coding style rules to avoid mess. This one I'm going to present is one of the most clear I've seen and I'm using it for a long time:

GENERAL FILES STRUCTURE
File header - each file must begin with a logo or some information about program it belongs to
Separate code blocks (includes, definitions, implementations, externals) with sth like this:

Code: Select all

//-------------------------------------------------------
//      Includes
//-------------------------------------------------------

Every wider comment describing functions or classes may look like this:

Code: Select all

/*
**              FunctionName
**              ----------------
**              Here we put info about what does the function do
**              @ param name_of_parameter            : description of parameter
**              @ param ... etc
*/

EVERY public (and private at best) function must have a profound desription - the same for classes


VARIABLE AND TYPES NAMING
global variables should have a type shortcut at the beginning:

Code: Select all

int            iVariableInteger;
BITMAP*        bmpBitmapObject;
char*          chString;
unsigned long int ulArray[];
tStructure     sStructure;
cCLASS         cClass;

NOTE: do not use "underline" ('_') to separate words, better use big letters at the beggining of every word ( not iNumber_of_all_tiles but iNumberOfAllTiles )

For structures and classes: each typedef structure name should begin with t and rest same sa in variables. Classes should begin with small c and the rest in UPCASE(tTile, tVehicleParameters, cGAME, cOBJECT )

member variables should begin with m_ and rest same as is other variables ( letter defining type and the rest) - that will prevent doubts whether the variable is a member or global one


MAIN PROGRAM STRUCTURE
whole game architecture should consist of few general objects:
GAME class, ENGINE class, RENDER class, CONFIG class e.g.

Program begins with:
Initializing cGame object (reseting all variables)
Initializing cEngine object (install input devices and create basic game window, init Renderer)
Load necessary configuration (beginning video mode, setting up paths to all .ini files, load menu and cursor)
Set appropriate screen res or window size
Load and run main menu
Init cMap object, load/generate the map, load all terrain textures and put them into cTileset, then load game objects (structures, vehicles, additional stuff like shaders)
Game loop
Destroy Game object with deinitializing all others, clean up memory issues

That's the basic architecture I think

With defined uni-style we can safely enlarge on main objects construction= GAME and ENGINE

I'm listening to suggestions and/or total critique

[Peter Dobrovka]

Well, this seems like the good old Hungarian notation. Always a good choice.
The architecture seems to be alright, too.

But MSVC?
This compiler is crap on the square but maybe you are right that it is still the best of all crap.
But there is one problem: it costs lot of money. Why not use the free GCC compiler that Hajo uses for simutrans?

Peter

[rein]

I've chosen msvc because of it's organisation routines: class inspector, many configuration possibilities...
but it doesn't matter anyway, code is always in txt files, so any compiler can be good with specified setup first

[orudge]

IMO without doubt the BEST one is MSVC

However, as the plan is to make the game portable, that is irrelavent really. The compiler depends on the platform. We should make it so that we can build it on Win32 with more or less any compiler (eg, MSVC, MingW32, maybe Borland C++, etc).

In general, I agree with your post though. I also think we should define a coding style. Personally, I use the following style:

Code: Select all

int main(int argc, char *argv[])
{
   int i;

   while (i < 20)
   {
      printf("i = %d\n", i);
      i++;

      if (i == 10)
         printf("half-way there!\n");
   }

   printf("The End!\n");
   return(0);
}

We should try to use one coding style and stick to it though - we don't want a mess of different coding styles.

[rein]

ok, i see
As for coding style, only few very useful additions:

Use spaces after '(' and before ')' - trust me, even if there's only void inside the function parameters part, also on both sides of '='

Code: Select all

cMap->Set( "My Map", 128, 128, "greenland" );
iArray[ counter ].m_sNext = &iArray[ ++counter ];
if ( !cGame->Initialized )
        return 0;

use more empty lines, it can only help!

in definitions and macros use only UPCASE

Code: Select all

#define MAX_ROTATIONS                        32
#define TILEX                     ( cTileset->m_iTileWidth )

every header file must begin obviously with pre-processor term:

Code: Select all

/* program info / logo */
#ifndef __FILE_H__
#define __FILE_H__
...
#endif//__FILE_H__

do not create one header file which includes all remaining ones, that is used next by every .cpp file - better write in all .cpp list of includes that are necessary instead of single huge one, so the building will go faster

Code: Select all

#include "headers.h"       // BAD
/*****************/
#include "map.h"            // GOOD
#include "tileset.h"
#include "misc.h"
...

if you modify ANYTHING in already existing code, you MUST make very detailed notes about what did you change and why it was necessary (and how to iclude it in other's source copies)

ok, that's it i think, if something comes into my mind, i'll add it here
now let's concentrate on GAME/ENGINE object structure (what functions are needed, what variables)

[Lilman424]

So basically this topic...is about how to make the source code more understandable......right?

[SHADOW-XIII]

I don't agree with MSVC ...
better is get some free compilers like GCC or ...
you can get BCB6 Personal (I have one from magazine) ... Personal edition allows you to release your stuff without any charge ... I think BCB6 will be the best ... but it is only my opinion (btw. BCB6 also have great organisation)

[Hajo]

I don't agree with MSVC ...
better is get some free compilers like GCC or ...

Why not write it in style so that it can be compiled with both compiler types? So every developer can choose his favorite system.

It's possible.

c.u.
Hajo

[SHADOW-XIII]

hmmmmm dunno

[Hajo]

hmmmmm dunno

I could put Simutrans as an example. Some of the developers use MSVC, some use gcc.

c.u.
Hajo

[orudge]

Use spaces after '(' and before ')' - trust me, even if there's only void inside the function parameters part, also on both sides of '='

Urgh, no, please, I hate having spaces around the functions. However, certainly have spaces before and after operators (ie, "iVar = iVar + iVar2" as opposed to "iVar=iVar+iVar2").

[orudge]

Why not write it in style so that it can be compiled with both compiler types? So every developer can choose his favorite system.

Yes, that's what I've been getting at all long - we should make the game as portable as possible.

[rein]

uh, can we start? or we'll finish at compiler choice and coding style

it's obvious that source must be as portable as it can be, but there aren't any strong differences beetwen compilers, use whatever that can only build it all and won't let you stray in file/structure tree.

[uzurpator]

Have you at least agreed what the tile shape would be? (Tringle or square?)

[rein]

tile shape? we don't even know what library/engine to use. As for now OpenGL seems to stay, but until we get up to map structure we need to go over the program framework, step by step.

[Hellfire]

Shouldn't you first write some documentation?

Split the engine into separate modules (for example the UI and game core I suggested to you before), and design the interfaces between them. Then, the various modules can be written, if necessary by different persons, but always following the documents you have written before.

[Hajo]

Shouldn't you first write some documentation?

Split the engine into separate modules (for example the UI and game core I suggested to you before), and design the interfaces between them. Then, the various modules can be written, if necessary by different persons, but always following the documents you have written before.

IMO before you design your need a domain analysis. Write a document that lists all required featres and all optional features.

Then, once you know what to do, write a design document how you want to do it.

Then start the implementation. Hmmm ... actually, you should write a test suite before the program itself, once the design document is complete.

OTOH I didn't do any of those for Simutrans and it works anyways ... I have a test suite, though. Well a small one. That was no joke.

c.u.
Hajo

[Hellfire]

Hmm yes that's basically what I meant.

[Hajo]

Hmm yes that's basically what I meant.

The question is how 'professional' this project shall be.

You could also take a look at extreme programming (XP)

http://www.extremeprogramming.org

They do less analysis and design before they start programming, but have measures throughout the process to ensure high quality nevertheless. XP is said to be particularly suited for projects with 'moving targets' i.e. frequently changing requirements.

c.u.
Hajo

Topic locked, really old moot (12112006).