battleMETAL - Why Quake / Darkplaces - Part 3 - 3D Rendering

Putting Stuff on-screen...

I understand that a lot of this content might be dry for readers who aren’t big into the nuts and bolts of game programming, and I’m sure that this probably doesn’t go deep enough for people who do. That said, I’m almost through this topic and I feel it needs to be typed out for context and for my own reference.

Keeping with the theme of why Quake/Darkplaces, this post will shift over to the rendering aspects of Darkplaces that merited looking into the engine. Darkplaces increases the types of 3D model file formats that can be used in-game, expanding from Quake 1’s thoroughly ancient (by 2016) .mdl format. Darkplaces can use .obj, .md2, .md3, .ase 3D model formats and their higher poly-counts. battleMETAL was never going to be a graphical powerhouse that could challenge modern games. I had the desire to make a game where graphics were clean enough that players could understand what they were looking at without being able to make super lush models.

The .md3 model format suited the project’s needs fairly well. MD3 is Quake III’s model format, which is from 1999. It's interesting to see what only 3 years of difference between Quake 1’s MDL and Quake III’s MD3 makes. MD3 can hold more detail, can something like 256 skins for a model file, and can have different textures for different models in the file. The MD3 format’s animation data is vertex based instead of bone based. MD3 was design by John Carmack for Quake III, so its footprint over a game network is incredibly low. Animations aren’t exactly a high priority (as we’ll see when I break down how I made the mech models).

Quake’s paradigm for adding models to objects is also fairly simple. Almost every object you see on the screen, in-code, is a thing called an entity. An entity is an abstract concept in game design, being a root-object of sorts from which all other objects inherit from. An entity in Quake can only ever have 1 model associated with it, which is given to the entity with the code command setmodel(). Once an entity has a model, there is functionality to affect the rendering of that model. Code can make the model partially visible, or invisible, glow with color, etc. So even if an entity has a mode, the game coder can dictate when that model should be visible. Another benefit is that an entity’s model can be changed quickly to something else entirely or removed if needed as well.

Now why does this matter? From where I sit, Quake lets the designer manage the game’s assets in their own way. Modern game design dictates that assets must be loaded into the entire development kit of the specific engine that the developer is using. There are benefits to this top-down approach, such as uniformity of design process when maintaining a project across a larger team. It also allows developers to move from project to project with familiarity of the tools. However, for battleMETAL and its one-man-army of me, I didn’t need such a heavy-handed approach. Quake allows me to manage assets as needed, adding or removing models at the code level, or even updated models in the file folders.

The last set of positives for Darkplaces is that the engine also provides tools for realtime lighting and shadows. Older game engines generally do not have this feature due to system limitations. ‘Realtime’ lighting is shorthand for saying lighting is dynamic as objects move around the game world as well as lights turning on and off. It also means lighting is more realistically represented when being projected from a source. Lighting in 3D computer graphics is its own Lovecraft-ian world that I won’t get into here, and you can find better explanations of it elsewhere. For Darkplaces, Levels can have light entities, and entities themselves can give off light. For battleMETAL, the Darkplaces lighting system is ‘good enough,’ providing enough detail to look good and allow for design aesthetics but also performant and manageable.

A neat tool that Darkplaces has is the ability to modify lights in a game level in real time using a series of built in commands. These changes are then saved to a specific file, ‘<map name>.rtlight’ which the game will load every time that map is opened. The advantage of this tool is no need to have to rebuild or recompile the map to test different lighting styles. The file is a plain text file with coordinate data, which also means the file can be copied and reapplied to other levels, or the same level. An example would be having a map transition from day to night, or a building’s lights turn on after being initially off.

The looser, bottom-up design of Darkplaces features put less emphasis on mastering a specific development environment and more on designer-based preference for their own tools. Engines like Unreal and Unity have lengthy tutorials for the various all-in-one tools they provide. For someone who doesn’t know these tools, the time required to learn them inhibits game design and the iterative testing of the project. Eventually I will give these a shot because they have their own pros and cons, but for now, I didn’t want to feel like I was fighting the tools too much….and yes we will see how I would eat this words in a buffet of hubris over this series of posts.