I notice that you didn't actually answer my question. Do you compile
the "engine" code with a C compiler or with a C++ compiler?
Oops, sorry about that.
I use a C++ compiler (Borland Builder in this case).
If you're using a C++ compiler then you're really programming in (a
subset of) C++. If your concern is smaller code, it makes probably
sense to use a subset of C++, but there's no particular reason that
subset has to be C-compatible. And if your system as a whole depends
on C++, there's little point in maintaining portability to systems
that don't have C++ compilers.
The "engine" of the game processes user input (the functions that
actually fetch that input are not portable and outside of the engine),
updates the game object (if necessary) and sends messages to the
players (the actual sending of the messages is performed by functions
invoked by function pointers and those functions are also outside the
game engine).
There are, basically, only two functions that are invoked from outside
the engine : ProcessMessage() and InitializeGame(). The whole engine
acts like a black box (you put stuff in and stuff comes out of it),
it's message driven.
This will all be done in C (freestanding) for maximum portability.
But this is not enough to have a running game implementation. There
are other functions necessary to make a working implementation of the
game, besides this engine. This involves communication with the player
(pipes, TCP/IP, direct, etc.), file management (saving games,
recording moves, loading maps), memory allocation (for the game object
itself and some workbuffers), the GUI (a very simple one to begin
with), etc.
These things are not portable (heck! you can't even clear the screen
with conforming C or C++ ;-)
I'll first make a simple application out of all of this (to test the
gameplay itself) and then proceed to make a little game server (a kind
of daemon) which can handle a lot of games simultaneously and gets
user input over the network (so that different AIs on different
machines can fight each other).
But my working game implementation will be all windows. Someone else
might take the "engine" (which is the portable core of it all) and
make a Linux implementation.
The only part that needs to be highly portable is the "engine" and
therefor it is written in C (freestanding). It doesn't really matter
in what language the other parts are written. They're not portable and
the engine doesn't need them. The engine is like a black box, it
communicates by sending and receiving messages in a simple char array
and it gets a pointer to a game object from outside.
Now, the reason why these non-engine parts are written in C++ is not
so much because of the language itself but because of the compiler
that has some neat extensions that will ease development of the
non-engine parts.
These components, however, are wrapped in classes so I have to program
in C++ if I want to use these components (one of my all time favorites
is the TStringGrid, I use it for almost everything
The engine itself I could just as well develop on a C compiler. But I
think of it as easier to add some units (as Builder calls them) rather
than link object files or even libraries (especially in the case of
Builder, I don't even believe it can handle COFF
and it makes
debugging easier since I need the whole game to conveniently test the
engine.
