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 file.

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 luagame services.

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.