[q2x] Refactorization

[Nick Trout]

> -----Original Message-----
> From: Brian Hook [mailto:hook_l at pyrogon.com]
> Sent: Wednesday, November 05, 2003 12:25 PM
> To: q2x at icculus.org
> Subject: [q2x] Refactorization
> 
> For my first pass of refactoring, I'm going to at least try to fix
> some of the naming nomenclature.  I'm with Nick on this, it is pretty
> confusing.  Unfortunately, the differences are still pretty subtle.
> 
> QSHARED -> used by EVERYTHING, generic utility stuff
>
> QCOMMON -> shared by "native" components, like server/client, but not
> game DLLs
> 
> QGAME -> shared between server-side game and server
> 
> I can't think of really good names for the above that are clear and
> concise.  The best I can think of:
> 
> QSHARED -> QUTIL
>
> QCOMMON -> QCORE
> 
> QGAME -> QGAME
> 
> Prefixes would be adjusted, e.g. QU_*, QC_* and QG_*

I'd suggest that the current naming convention, "Q_" is sufficient, and
more intuitive than "QU_", i.e. everything in Quake uses "Q_" functions.
Since the header is well grouped, and the "q_*.c" files well named,
there is little confusion in finding the function implementation
matching the declaration in qshared.h. If "common" is renamed then it
makes "shared" less confusing, but since "shared" contains utility
functions it makes sense to call it "qutil" (and it contains mostly
project level reusable code). So, I think we just need to rename the
library. Q2X contains all of the knarly startup code etc.

The engine sitting on top of any common utility code is pretty Q2
oriented. There is a lot of hard-coded behaviour in there and it would
be difficult abstract a very different game out this code. So, there
seems little point trying to abstract generic client server architecture
or other libraries. To that end I'd suggest the names: "QCORE",
"QCLIENT" and "QSERVER" with QCORE containing as much common code as
possible.

In time most of the QSERVER code will migrate to Lua and the client and
server libraries will become less dependent on Q2 nomenclature and
objects; everything will be more data driven. Once all of the objects
have been migrated it will be easier to abstract a cleaner client-server
engine which could handle different types of game, however the
technology of Quake is fairly directed at interior games and so there
would seem little point. 

Since the code will be migrating to Lua this brings into play the Lua
binding, where will this live? I think Brian mentioned that he didn't
want Q2X to become dependent on Lua alone (from the depths of my
scattered memory!), rather that it should be possible to embed other
languages. If this were the case perhaps we need client and server
binding libraries? 

My own opinion is that this would just confuse matters and you are
better off putting the Lua binding in the client and server code. If we
want to add another language at a later date the Lua binding could be
refactored. From experience I don't know why you'd want to do this as
Lua is incredibly flexible, efficient and more than adequate for the
usage of this project. I'd also be interested in moving all of the Q2
config stuff over to Lua, e.g. cvars etc.

Nick