Q2X is a fork of the icculus.org Quake 2 code base (http://www.icculus.org/quake2/).
The goals of this project are fairly simple, in some ways very sedate
and in others very aggressive.
The code base will be modified with an emphasis on making it
maintainable, readable, portable, compatible and
extendable. In many ways this means a wholesale revamping of the
file structure, including renaming and moving files around. This is
not going to be a patch, this is a pretty radical departure from the
original code base.
The ultimate goal is to to rekindle some interest in the mod
community, ideally by attracting new mod developers through the use
of a scripting language (as opposed to pure C) and by supporting new
file formats such as PNG, TGA and ZIP.
Q2X will be easy to maintain. This means that files and identifiers
will be named and placed consistently. There will no longer be an
anarchistic mish mash of functions with names like AngleVectors,
vectoangles, and Weapon_Think.
Files and functionality that are obsolete or that can be removed have
been. Specific support for hardware adapters such as 3Dfx or
Rendition has been removed. The software renderer will also likely
be removed. All assembly code has been removed. If a system's
default hardware OpenGL driver cannot run Q2X, that is too bad. The
IPX network protocol support has been removed.
The directory tree has been lightly revamped so that system specific
elements are placed in a subdirectory beneath their subsystem. For
example, the SDL specific parts of the client will be in
src/client/sdl and the SDL specific parts of the ref_gl will be in
src/ref_gl/sdl, as opposed to just dumping everything in /src/sdl.
It is our intent that Q2X can act as a high quality foundation for
learning game programming. In keeping with this, the code will
hopefully be cleaned up and commented in the process of our other
changes. The changes to make it easier to maintain will also
facilitate its readability.
Q2X will be portable to all reasonable platforms that support SDL.
Q2X is also dependent on posh.h (http://www.poshlib.org/) so that sized types
and DLL exports can be implemented trivially without requiring
external .def files or a Q2X specific compiler/platform configuration
Binary compatibility with existing assets and modifications is
extremely important, however source code compatibility is not a goal.
Ideally the Q2X client will be able to load a standard Q2 mod (e.g.
the single player game) and execute.
In addition, Q2X will be able to use existing Q2 assets (PCX, WAL,
MD2, etc. in the form of pk2 pak files).
Quake2 was a very easy game to modify by writing new game API shared
libraries in the C programming language. Unfortunately this worked
against a lot of potential modders since they had limited access to
programmers and programming tools.
To address this Q2X will implement a Lua extension module (luagame)
that "thunks" between the Lua scripting engine and the main game.
This module acts exactly like a standard Quake2 game DLL (i.e. it
supports the existing game API exported interface) but executes Lua
scripts for the game logic itself.
The Lua scripts themselves will have only limited access to the
underlying engine through the use of Quake3-style system traps, which
If we get around to it, a Q3 style client-game interface (cgame) will
also be implemented, allowing for more robust user interface and
presentation enhancements on the part of a modder.
In addition, support for new file formats will be added, including integration of the PhysicsFS file system abstraction layer (http://www.icculus.org/physfs/.) File formats such as JPG and ogg will be supported.
Finally, and this might be a pipe dream, it would be nice to get a
reference set of unencumbered assets so that those that wish to
experiment with mods do not have to find a copy of Quake2 in order to
have a set of base assets. The necessary assets that would be
required are a font, some basic HUD graphics, a reference map with
wall textures and a reference character.
In the process of cleaning up the engine and adding features, there
are some features we have very little interest in pursuing.
Specifically, enhancements to the graphics engine and changing the
base language to C++/Java/C#/whatever are not priorities, and are
tangential distractions at best.
That said, the renderer will likely be cleaned up, optimized and
extended in some areas, but radical new technologies will not be
introduced, especially if they break compatibility with the current
assets. Possible exceptions to this exist, such as introducing a
skeletal renderer, but by and large improving the graphics engine is
not a focus.