I want to make several changes to the tree's layout which were not done
originally because of a number of reasons which either do not any longer
or will not soon matter anymore. I do _NOT_ want to do this before
release since that would simply hold up the release several weeks and we
are all itching to call this thing stable.
The current CVS archive looks like this:
twilight
|-- debian
|-- doc
| `-- olddoc
|-- gamecode
| `-- progs
|-- include
|-- nq
|-- qw
|-- qw-server
`-- tools
There are a number of strengths to this system. First of all, it's very
simple. There is no real need to try and navigate the tree. If something
is not where you expect it, there aren't many other places it could be,
and that's a good thing. Also, it's pretty simple to add to the current
system. The gamecode directory is perhaps inappropriately named, but at
this stage it could change to "gamedata" with no ill effects (not even the
loss of old revision information at this point) to accomodate data which
we expect to ship with the engine. The docs and tools directories are
aptly placed. Generally, it's the right track I think.
Here are the steps I think we should follow in order to improve on the
strengths of our current codebase and resolve the weaknesses:
1. Move twilight/qw-server into twilight/qw.
Having the two in the same directory could be done today if we wanted
to, that much need not wait for release. Putting a server into the
client ala NQ would have to wait though.
2. Create twilight/baselib. FIXME: better name?
A place to put mathlib, strlib, console, cvar, cmd, bspfile, common,
and all of the other things which were classically used by both the
engine and the tools. The code here should be built into a static
library for the engine to link, but we should not discount making it a
dynamic library in the future.
3. Create twilight/renderer.
Here we'll place all of the shared stuff necessary for the client's
rendering. Starting with all of the gl_* files, more or less. They
should lose their gl_ prefix probably when they move. I'm not sold yet
on the idea that that vid_sdl belongs in here, but I'm not really sure
where to put it really.
4. Create twilight/sound.
Currently, there is not much to Project Twilight in the form of sound.
Only a handfull of files. But if we add support for more kinds of
music such as mp3, Ogg Vorbis, etc, I believe it will make more sense
to give these things a place of their own.
These directories should be as free of outside dependencies as possible.
Clearly most of them will depend on "baselib" and just about all of them
will depend on SDL for certain. Headers for each module should move to
that module. That'll mean more include paths in the engine, but it also
means that the modules themselves will be more bite-sized. The exception
to this is of course baselib, whose headers should live in the shared
include directory we have now, possibly a subdirectory of that even
waiting for the day that these headers will actually be installed on the
system.
The result should look like this:
twilight
|-- baselib (or whatever)
|-- debian
|-- doc
| `-- olddoc
|-- gamecode
| `-- progs
|-- include
| `-- Twilight
|-- nq
|-- qw
|-- renderer
|-- sound
`-- tools
The last thing I want to do, and probably not until after our second
release, is move the twilight directory to twilight-classic so we can move
on, break compatibility, and do cool things. Obviously that's way off in
the distance, but I thought I'd mention it since I have already made the
Debian package scripts work that way.
Comments? Suggestions? Thwacks for really lame design choices?
--
Joseph Carter <[EMAIL PROTECTED]> Free software developer
<elmo> unclean: err, the admin team do not control the archive, that's the
ftp cabal
<elmo> get your cabals right, damn it :-P
PGP signature
