battleMETAL - Why Quake / Darkplaces - Part 6 - Menu Systems Layer

Click on the thingie, no wait, that thingie!

Quake was never known for its menus, in fact most iD games skip out on menus in any detail. There’s a workman-like quality to them, simple layouts and input. It also makes sense given that Quake came out in 1996, unless a game was menu-driven (like RPG’s or RTS) a game’s menu system were fairly plain. For Quake, it has all the necessary menus a player would need for an FPS. Building on DooM’s template, there are more options for graphics, and for multiplayer settings. Interestingly enough, iD did setup the code for their menu system fairly well, having console commands that can immediately bring up any particular menu.

Darkplaces however expands the capabilities. This being 2018, menus have advanced a bit since the days of 1996 and most people enjoy having a useable mouse for the menus. In Darkplaces, the source port exposes the menu entry functions to the Quake C code that modders can use. This in turn allows modders to create any and all menus they’d like to in almost any fashion they’d prefer. There are 2 layers to menus in Darkplaces, each being compiled to their own code base. The big one is called CSQC or Client-side Quake C. Original Quake, all custom code (written in Quake C) was packed into a single compiled file called progs.dat. However CSQC is packed into its own file and only used by the player’s local game of Darkplaces.

CSQC can access almost everything about the player’s game. The programmer can customize the HUD, can create their own menus, change runtime variables through the console, intercept input commands, and very importantly - define communications with the server. This last piece is helpful, this allows custom data transmission between the server and player. The coder can setup custom server-drive events, or pass specific game updates to the player for notification. Quake itself never needed to do a whole lot with this, but a mech game in 2016? Oh yes, this feature was very much needed.

The other big menu module is the specific menu layer. Quake source ports and modders never really settled on a ‘standard’ way of remaking / extending / modding Quake's original set of menus, so several options exist. One way many modders do is add the features to the CSQC described above. Another way is the menu.dat. Remember how CSQC compiles to its own file? Well its the same idea with the menu.dat code. Darkplaces looks for a menu.dat file, if it exists, Darkplaces then runs the menu code found in that file. The framework for the menu code is similar to CSQC but slightly more limited to just rendering menus and executing player input. I chose this solution for my main menus because I liked the separation of concerns that this approach offered - all the menu code is in its own folder and cleanly separated from all other code.

In summary, Darkplaces offered several flexible albeit a tad labor-intensive approaches to implementing new User Interface upgrades to the original Quake engine. I considered this sufficient at the time when selecting to go forward with Darkplaces. The available documentation on CSQC was easily found, but not the most detailed. The menu.dat code required going into the engine code to figure out how it worked. In hindsight now, despite the flexibility offered, both features actually incurred a large amount of technical debt. Newer engines handle UI systems more effectively both for the player and for the programmers.