Give me some time until this is finished

Welcome to the QuakeC programming introduction. This article is intended for people who have their fair share of experience in other programming languages like Java or C/C++. As you know, there is already the QuakeC reference guide which gives you an overview of the language used in server-side and client-side quake code. You will actually need to read that page at some point. Anyways, this page will provide the following information:

• How to get the compiler for the server-side and client-side QC
• How to use the compiler, what files it creates and where these files belong
• An easy way how to get a current build of an (unmodified) DarkPlaces engine
• Introduction to working with SVN using Eclipse and Subclipse
• Introduction to the CodeBlocks IDE that allows not only syntax-highlighting but also navigating through the code, as well as autocompletion
• Tips and tricks for staying up-to-date with your own probably massive code-changes, tips for merging conflicted code, and saving your work in modular patch files

To summarize this page: It explains how to setup an environment in which you can efficiently develop SVQC (server-side QC) and CSQC (client-side QC).
Keep in mind that this page does not provide coding tutorials. Some of these may be created another time at another place.

From the programming perspective, Nexuiz consists of two parts:

• The game engine (also called “engine”, “DarkPlaces” or “DP”)
• QuakeC byte code, which is run in a VM (virtual machine)

The game engine provides the capability to run a dedicated (console-only) server as well as acting as a client (which you use to play the game). As you know, DarkPlaces runs on Windows, Linux and Mac systems. To achieve that, the developers have to do quite a bit of work, as they'll have to use different APIs for accessing the hardware that Nexuiz interacts with (such as the keyboard, mouse, joystick, soundcard...), as each operation system provides different APIs for that purpose. This is the reason why all the game-specific logic, e.g. the program code of the game modes, weapons, items, etc. is not written in the engine, as this would mean to write it in the language of the engine, and would also mean that you have to compile the whole engine each time you do a change in the game code.

Instead, the game logic is implemented in its own language, QuakeC, which is compiled by its own compiler, in our case FTEQCC (FTE QuakeC Compiler). The compiled code generated by FTEQCC gets into a file which is the placed inside the data dir of Nexuiz. When you launch the engine, it will look for that file and run the compiled code which is in that file in a virtual machine. This has three advantages:

• Compilation is fast, as you compile the game code only
• You will get byte code which means that your game code is platform independent (as long as the engine which interprets it is able to run on the platform)
• There are defined “interfaces” that allow you to interact with the engine. Can raise the security of the code.

However, it also has disadvantages:

• QuakeC is a derivative of C, thus it has the disadvantages of C (no OOP, working with zillions of global variables and functions only)
• The compiler is not a standardized C compiler but maintained by a single person. Thus, the compiler has several bugs.
• QuakeC code performs much worse than compiled C code
• QuakeC not that functional as C, you often to call functions of the engine (because the engine has the functionality or the function would simply be much faster when implemented in the engine). For this you call these “interfaces”. Actually, these are called built-in functions (more about them comes later)

For compilation the FTEQCC needs a file called progs.src which basically contains a list of all .qc and .qh files (note the intended similarity to .c and .h files). FTEQCC then compiles all these qc and qh files after another and puts the result in a .dat file. Remember that I was talking about 1 file that is interpreted by the engine? In fact, you actually need 3 of these files (and you also need to run FTEQCC 3 times while you specify a different progs.src file each time):

• SVQC (server-side Quake code): This is the game code run on the server, it's usually the code where most parts of the game logic is implemented (because it is the server that controlles the game, not the client). The progs.src file you specify is the one in /data/qsrc/server . The resulting file is called progs.dat
• MenuQC: This is the menu code. The menu is actually written in C. Yet it is compiled using FTEQCC. The progs.src file you specify is the one in /data/qsrc/menu . The resulting file is called menu.dat
• CSQC (client-side Quake code): Since Nexuiz 2.4.2 DarkPlaces contains the CSQC extension which allows the developers to create code that is run on the client only. The coding is similar to SVQC, it is written in QuakeC. CSQC is used for things that would otherwise have to be customized by the server for each client, e.g. notification events, an intelligent HUD system, or simply things that actually were clientside before, but done completely in engine code.
  The progs.src file you specify is the one in /data/qsrc/client . The resulting file is called csprogs.dat

All 3 dat files need to be placed in the data directory of Nexuiz, as the engine expects them to be there.

Another note: FTEQCC also creates a lno file for each dat file. For Nexuiz these lno files are not important or needed. In case that you distribute a mod you created, you won't have to publish the lno files, only the dat files.

TODO: Explain general purpose of buildsystem, where to get it, create a file mirror somewhere.

TODO: Create a down-sized build.bat that only builds FTEQCC and DP engine including SDL version.

TODO: Someone else has to do the linux part!

TODO: Introduce Eclipse+Subclipse Plugin. Alternative: TortoiseSVN (what about Linux?)

TODO: Introduction to CodeBLocks, explain the features of it. Explain known bugs.

TODO: Link to the article in this wiki. Some explanations.
TODO2: Explain how to access built-in functions.

TODO: Explain the common tasks that come with the usage of SVN and the fact that you likely changed (a lot of) code:
- Updating SVN by using Team Synchronisation feature of Subclipse to prevent conflicts when updating
- Creating patches to backup your work, keeping your work modular.