Tag: level design

Trenchbroom – Geometry Basics

Posted on July 2, 2026 by g.hill - Quake Mapping Jam

In this post, we’ll go through the basics of geometry building in Trenchbroom. I had originally intended to write this blog post as a complete guide that explored all aspects of the engine (viewport navigation, hotkeys, brush creation, entities, custom WADS etc.), however this felt incredibly boring and redundant as there already is extensive documentation out there presented in a much more engaging way. It also felt a little unintuitive as the best way to learn how to use an engine is not to read pages of documentation but to simply boot it up and start experimenting with it. With this in mind I’ve pivoted the blog post to focus more on the basics of Brush Geometry and helping first time users get used to the editor so as to get you started and walking (you’ll be running in no time).

I’ll be ignoring a lot of the nuances of the engine (partly as I am still learning myself, but also to avoid cognitive overload of features that might not be needed for a new user). Dumptruck_ds’ tutorial playlist provides short tutorial videos that go into more detail on each of the tools of Trenchbroom which I highly recommend watching if you want a deeper understanding of specifics. And of course the Trenchbroom 2026.1-RC3’s reference manual should cover almost anything else you could possibly want to know about the engine.

So, lets get started.

Navigating your way around the editor

Lets start by learning our way around the editor and the viewports. By default Trenchbroom loads up with a single 3D perspective view; For a brush-based map that’s built to a grid, this feels clunky as I prefer to do a lot of work on the orthographic views. So my first suggestion would be to select “view -> preferences”, and in the View tab, adjust the layout configuration to “Four Panes”. This will give you the 3 orthographic views; front, top and side. Whilst you’re here, you should also set your Theme to “Dark” mode because you’re not a barbarian. There are other accessibility settings you can play around with in this mode, and this Preferences window is where you can also edit hotkey shortcuts (which might be applicable to your workflow). I’ve edited some of my hotkeys to closer align with other more standard engines, but in this blog post, I will always refer to their default hotkeys.

Some icons in the UI are context sensitive. You will see this with the tools icons at the top that are currently greyed out. To enable those icons, select the default brush in the scene and notice the icons become selectable. You can select the icon to switch tool mode or hover over the icons to see their name and associated hotkey (you don’t need to memorise the hotkeys now as that will come with time and experience within the engine, but the sooner you learn them the quicker your mapping workflow will become). Selecting a tool will sometimes bring up a secondary row of options below (i.e. degrees of rotation snapping on with the Rotate Tool or scale factor with the Scale Tool) and these can further refine your usage of the selected tool.

Down the right hand side of the editor you the Inspector Tabs; Map, Entity and Face.

Within the Map tab you have the Layers window, which is useful for organising your work and aiding in your work flow. It sort of works like a primitive hierarchy you would find in Unity and Unreal. You can create new layers, name them and add objects from your scene into them. These layers can be locked, turned on and off and omitted from your compile entirely should you wish. You can add a new layer by clicking the little + symbol at the bottom of the layers window, and items can be added to the layers by selecting them, right clicking on the layer and selecting “Move Selection To Layer”. There’s also Map Properties and Mods windows below, however I won’t cover those in this post.

To the right of Map there is the Entity tab. This is the library of entities we can work with when making our map. This is also where we can add WAD files, a collection of textures used to texture brushes, to the project (I briefly mention how to add WADs to your project in the Getting Started blog post, so best refer there for more information if you need). The main window we’re concerned with for this blog post is the Entity Browser.

Entities are packaged up pieces of game logic that can be used to turn a map of brushes and geometry into a functioning game level. Basic entities range from weapons and item pickups to enemies, lights and triggers relays. Alone these pieces of game logic will function, but the true creative power comes from how these entities can interact with one another. I will cover entities, the creation of new entities, brush entities and how to use trigger and relays, in much greater detail in a future blog post; but for now, just know that if you want to place a simple enemy spawn, item pickup or point light, you will want to navigate to this window.

Next to the Entity tab there is the Face tab. This contains the Material Browser which holds all of the textures within the WAD files we’ve added to the project. When applying a texture to a face of a brush, we use this Face tab to select the texture we want, and how to scale, align and rotate the material when its applied to the face. Its something which is better observed through practise than text so:

Select the the default scene brush with a left click
Hold shift and left click the top face (it should be highlighted in yellow)
In the Material Browser, select a random texture
Notice how the texture has been applied to the selected face of the brush
Above the Material Browser there are tools to manipulate the material on the face of the brush
Experiment around them and see in the 3D viewport how this directly affects the look of the brush
You can Move the texture around the UV, you can scale it on the X and the Y and you can rotate it

Finally along the bottom of the editor is the console. This will output in Realtime a log of what is going on inside the editor along with any errors that might occur during your mapping experience. I won’t go into much detail here about the Console, but just know if you see a stream of red error text, it might be worth stopping and investigating what the issue is.

Controlling the Viewports

Lets get used to some basic controls in the viewports as Trenchbroom has slightly different controls from more standard engines like Unity and Unreal. Simply reading these instructions is an awkward way of learning, so I would highly recommend messing around in the editor yourself to learn the quirks of Trenchbroom and also referring to the Trenchbroom 2026.1-RC3’s reference manual for a reference on everything you can do (as there is a lot of stuff that I will be missing here).

Moving

To move around the 3D viewport, hold down the right mouse button and pan around with W,A,S,D
To speed up or down the pace at which camera moves, hold down the right mouse button and scroll the mouse wheel either towards you (to slow it down) or away (to speed it up)
Scroll the mouse wheel by itself to zoom in and out
Holding Q or X can be used to pan the viewport up or down

When working in the 2D orthographic viewports:

Panning is instead done by holding down the right mouse button or the mouse wheel and moving the mouse around
Zooming in and out uses the mouse wheel, just like the 3D viewport

Selecting

To select a brush or an entity, simply click the left mouse button on the object you wish to select
Move the selected object around by clicking and holding down the left mouse button on the object and then moving the mouse
- You’ll notice if you do this in the 3D viewport, the object is locked to the X and Y axis
- If you want to move the brush up and down along the Z axis you’ll need to hold down the alt key whilst you drag
- For this reason alone I find myself predominantly using the 2D orthographic viewports for brush creation and manipulation (perhaps its just my years of experience within Source but it just feels more natural and less clunky – your mileage may vary)
To select multiple objects hold the ctrl key down and click the left mouse button on each object you wish to select
You can also hold the ctrl key down and then click and drag left mouse button over multiple brushes to select them
- Make sure you have ctrl held down before you click and drag else you’ll duplicate the brush
To select the face of a brush hold down the shift key and select a face by clicking the left mouse button.
- Like with objects you can select multiple faces by also holding down the ctrl key
Select all objects within the scene by holding down ctrl pressing A
- Note: Only objects that aren’t hidden or locked will be selected
To deselect everything hold down ctrl + shift whilst pressing A

Creating and manipulating Brushes

The core geometry of the level is built using CSG (or BSP brushes as they are more commonly referred as). There’s no need to go into huge detail about what the brushes are, just know that they are the building blocks of your level. They can be placed, scaled, rotated. You can manipulate each of their vertexes, you can add additional vertexes. You can apply materials to each individual face, and you can even turn them into entities that can have game logic applied to them. This is what 80% of your time in Trenchbroom will be spent working with so its best to get used to them. I’ll go over some of the very basic controls and tools you need to get started:

Brush Tool (B)

Pressing B selects the Brush tool. To create a simple brush:

Ensure no other object is selected by deselecting everything either by holding Ctrl+Shift+A or pressing Esc
Hold down the Left Mouse Button anywhere in any of the viewports and drag out the shape
Whilst still holding down the Left Mouse Button, hold Alt and drag up to give the brush a bit of height (this will only work if you’re creating the brush in the 3D Perspective Viewport
Release the Left Mouse Button to create the brush

To manipulate the shape and the size of the brush we can move the individual faces in the same way:

Hold Shift + Left Click on the face of the brush you wish to move
Click and drag the face in the desired direction (Notice that the face is locked to its oriented axis)
Release the Left Mouse Button to finalise the edit

The Scale Tool (T) can also be used to achieve the same effect as above, however I personally find this to be a little more awkward than simply holding shift (but maybe you might find it a better method).

Brush Shapes

Underneath the Brush Tool icon, you’ll see a little orange cube. This can actually be clicked to reveal a drop down menu of the brush shape you can build. I won’t get into every single shape in this post as there’s a few to explore and they each have their own settings, but explore and experiment with using different shapes to see what interesting geometry you can create.

Rotate Tool (R)

This tool is pretty self explanatory, it allows you to rotate a selected brush or entity:

Select the object you wish to rotate
Select the Rotate Tool or press R
To rotate the object either:
- Click and drag the widget on the desired axis or
- Hold alt and use the arrow keys to rotate around the X and Y and Page Up / Down to rotate around the Z

Notice that some additional options have appeared below the tools bar, and these can be changed to give you more control over the rotate options:

The first is the pivot point around which you want to rotate the object
- The initial value is the centre of the brush
- 0 0 0 is the origin of the map
- or you can put your own 3 values in if there is a specific point you wish to rotate around (just hit Return when you have entered your 3 values)
In most cases however you’ll like just want to rotate around the centre pivot of the brush, and if the pivot has been placed in a position you don’t want you can click the reset button to return it to the centre
The second option is the degree of snapping you want when rotating an object
I personally would ignore the third and fourth option, but this is if you just want to have the rotation be applied a single time around a certain axis by a click of a button

Clip Tool (C)

The Clipping tool allows for the slicing up of brushes (again something better demonstrated than explained):

Create a new brush
Select the Clipping Tool by pressing C
Notice how a little orange dot has appeared and snaps to various points on the grid
Select the first point anywhere on the mesh to set the anchor point. This will determine where the slice will start
Select a second point on the mesh to specify where you want the slice to finish
- This might get a little awkward in the 3D perspective viewport, so I typically use the orthographic viewports for this

You’ll notice that one side of the slice has now turned translucent (see above). If we were to complete the clip right now, the Opaque side of the brush will remain, whilst the translucent side of the brush will be removed.

We can switch which side of the brush we want to remove by holding ctrl and pressing Return to cycle between all 3 options
- Remove Side 1, Keep Side 2
- Remove Side 2, Keep Side 1
- Remove neither side but add a new edge where the slice would be made creating two separate brushes
Once you’re happy with what slice you want to make press Return to complete the action

Vertex Tool (V)

The Vertex Tool gives us the freedom to manipulate the brushes into more interesting shapes by moving individual points of the brush. When combined with the clipping Tool this can very interesting geometry:

Select the Vertex Tool by pressing V
Notice that individual vertexes you can manipulate appear in yellow
Select one of the vertexes by pressing and holding the left mouse button
Drag the vertex in the direction you want to skew the brush
- Notice that if this is done in the 2D Orthographic Viewport, it will select all vertexes on that specific point irrelevant to their depth
- If you wish to move a specific vertex on that specific point, it must be done in the 3D Perspective Viewport

You can add a new vertex to any edge of a brush by holding Shift and then clicking and dragging the left mouse button from a point along the edge of a brush

If you wish to merge two vertexes together:

Select the first vertext
Hold Shift + Alt and click on the vertex you wish to merge it to
Notice how it merges the first vertex to the second’s location
Its important to note, that if at any point vertexes overlap with one another, they are automatically merged into one single Vertex

Edge (E) and Face (F) Tools

I won’t go into much detail about these specific tools, as they are relatively self explanatory but they allow you to manipulate either an entire edge or face of a brush. Selecting these tools will highlight a yellow point that you can click and drag.

Useful functions

Finally here are some useful little functions and hot keys that might help in your map making flow:

Isolating and Hiding Brushes

This function can be very useful when you want to focus on a small section of a much larger map as it cleans up the orthographic viewports making them easier to use:

You can isolate an individual/group of brushes by holding shift and pressing I
This will hide all other brushes allowing you to just focus on the brush(es) that you had selected
You can hide an individual/group of brushes by holding ctrl + alt and pressing A
This will hide the brush(es) you had selected
If you want to unhide all other brushes from either command hold ctrl + shift and press I

Grouping Brushes

This combines numerous brushes into a single group of brushes. To add multiple brushes to a group:

Select all the brushes you wish to add to the group
Hold ctrl and press G
Give the group a helpful name (it doesn’t have to be unique)
Notice how a purple bounding box now surrounds the group
Clicking on a single object within the group will select the whole group
If you wish to edit the group, double click the left mouse button on any brush within the group
You are now editing only the brushes present within that group
To exit a group, press esc

To remove a group:

Select the group you wish to remove
Hold ctrl + shift and press G
This doesn’t delete the contents of the group, just the group itself

To add/remove brushes to/from a group:

First select the brush you want to add to an already existing group
Right click on a brush within the group you wish to add it to
Select “Add objects to group [groupname]”
To remove an object from a group, first double click on a brush in the group
Select the brush you wish to remove
Right click on the brush and selected “Remove objects from group [groupname]”

Centring The Camera

This is the equivalent of the F key in Unreal and Unity and is very useful for re-orientating yourself when your map begins to balloon in size:

You can centre the camera on a selected object by selecting the object you wish to focus on
Hold ctrl and press U
This will focus the camera on the selected object

Hiding UI Elements

Lets say you want to purely work on geometry and want to maximise your screen space. You may want to remove unneeded UI elements:

To remove the inspectors on the right, hold ctrl and press 5
To remove the console at the bottom, hold ctrl and press 4

Conclusion

OK, I think that’s enough for now. I was very conscious about getting this blog post out before the start of the mapping jam, so there’s likely a whole handful of useful tips and tricks I’ve forgotten to write about. But the ultimate goal of this guide was to get mappers started with exploring the engine and building brushes.

Next time I’ll explore entities and turning the basic geometry of you map into something that is actually playable. Ciao

Trenchbroom – Getting Started

Posted on June 8, 2026 by g.hill - Quake Mapping Jam

In order to start building a map for Quake, we’re going to need to install Trenchbroom and get it all set up. There are countless tutorials and guides out there that you can follow, but I figured there was no harm in me adding yet another one to the internet. Most of the information here has been compiled from dumptruck_ds’ quickstart tutorial video and from the Trenchbroom 2026.1-RC3’s reference manual, and whilst this can be a somewhat awkward and cumbersome task at first, once you’ve done it, you’ll never have to do it again. For the game jam and for this installation guide, I plan on using the latest released version of Trenchbroom which is v2026.1-RC3 on a Windows 64bit OS. For those who plan on using MacOX or Linux, I’m sure installation and set up instructions can be found online with a quick google search.

Preparation

Before we get started we will need to do a little prep work:

We start by making a folder in the Root of our main Drive (it doesn’t matter what you call it, but the important thing is that it is in the root of the drive)
For me, this is my C: drive, and I’m going to name the folder QuakeDev
Inside of that QuakeDev folder we’re going to add 5 more folders:
- id1
- tools
- Trenchbroom (I name this the version of Trenchbroom I’m using)
- wads
- working

Within the id1 folder, create another folder called maps

Setting Up Trenchbroom

As mentioned in the introduction, I’m going to be using Trenchbroom v2026.1-RC3. This is (at the date of writing) the most recent version of Trenchbroom. You are free to use whatever version of Trenchbroom you desire however:

Download the latest version of Trenchbroom here
Scroll to the bottom of the git changelog and expand the “Assets” list
Find and download the appropriate zip file for your operating system (Win64-v2026.1-RC3-Release in my case)

The changelog also suggests Window users download and install Microsoft Visual C++ Redistributable for Visual Studios (a link to which can also be found in the change log). I already had it installed previously from my work in Unreal and Unity, so I can’t verify if this is 100% necessary for our Quake mapping purposes, but there’s no harm in installing it just in case.

Extract the Trenchbroom files into the trenchbroom folder you created.

Next we’re going to need to populate Trenchbroom with Quake content. This comes in the form of PAK files. Simply put, a PAK file is used to store data that will be extracted and loaded by the Quake engine (this is typically game data, entity definitions, maps, sounds etc). In order to find these PAK files, you will need to obtain a legitimate version of Quake. I personally recommend the Bethesda remaster on steam. Not only is it relatively cheap and comes with all of the official expansions but there’s a whole host of QOL changes to graphics and input options that make the game far friendlier to play in 2026).

Pak0.pak is necessary for all Quake games to run, and pak1.pak appears to be needed too if you want the full library of Quake content to work with.

Navigate to the Id1 folder in your game directory (mine is C:/ProgramFiles(x86)/Steam/streamapps/common/Quake/Id1)
Copy the following files:
- config (if this file is missing, don’t worry – config.cfg will generate the first time you compile and test a map).
- PAK0.PAK
- PAK1.PAK

Return to the QuakeDev folder you created in the previous section and paste these files into the Id1 file you created

Textures are stored on WAD files, and we’ll need these as well. Unfortunately these aren’t directly available in the Quake game directory like the PAK files, so we’ll have to source them externally. Quaddicted is a great source for all things Quake related and the WADs can be found here easily to download. Just to get things working, find and download the start WAD and put it into the WADs folder in QuakeDev.

Downloading Compiling Tools

Once we’ve made a map, we’re going to need to compile it. Ericw-Tools is the standard compiling tools for many Quake mappers and they can downloaded directly from the website. I personally went with the stable branch, however I have no reason to believe the alpha branch is any less usable (and its probably better in many regards).

Go to Ericw-Tools
Download the either the Alpha or Stable version of the compiler tools
Add a folder in your QuakeDev/Tools folder with the same version number of the compilers (mine is ericw-tools-v0.18.1-win64)
Extract the files into that folder

At this point in other older tutorials, they will suggest you download Necros compiling GUI. This offers a developer friendly GUI to run the Ericw-Tools compilers we just downloaded, however newer versions of Trenchbroom have an integrated GUI that can handle that task instead, so it makes more sense to use the internal tools rather than adding another third party software to the workflow. If you still wish to install and use Necros Compiling GUI however, dumptruck_ds’ video has a link and all the information needed to set it up). For this tutorial however I will show you the configuration of the compiler using Trenchbrooms integrated GUI.

Downloading Quakespasm

The final stage of preparation is to set up the game files that will run our map when we’re mapping and testing. Most guides (including dumptruck_ds’ quick start guide) suggest using Quakespasm. Quakespasm is a cross platform Quake engine based on the SDL port of Fitzquake. I tried to dig up some reasoning as to why you should use this over the remaster on Steam as a way of playing your maps, and the only real answer I could get is that the load times are quicker and its less prone to bugs. I might experiment with this more, but for now let just download Quakespasm.

Download Quakespasm from the official Sourceforge page
Extract all files into the QuakeDev root folder

Final Setup

Now that all of the files are downloaded and placed, lets check Trenchbroom to ensure everything is working properly and get a very basic box room made up and compiled.

Open Trenchbroom via the Trenchbroom.exe in your QuakeDev/Trenchbroom folder
Click “New Map”
Click “Open Preference” and select Quake from the list on the left
Click “Configure Engines” and make a new profile by clicking the little + button on the left
Name the Profile something useful (I called mine “Quakespasm”)

Ensure the “Game Path” points to your C:/QuakeDev folder (as that’s where we extracted Quakespasm to)
For each of the compilation tools, assign their path to the C:/QuakeDev/tools/ericw-tools/bin folder
Each compilation (qbsp, vis and light) will be in the bin folder

Whilst here you can also change the theme from system to dark in the view tab (very important) as well as adjust the layout, grid thickness, brightness, FOV (as well as a whole load of other editor options to play around with). I personally work on a four panes layout with everything else set to default.

Click OK to apply the changes close the window.
Select Quake from the list (ensure Map Format is “Valve”) and click “OK”

This will open the editor ready for you to start mapping! To ensure everything has been set up correctly, you can check the “Entity tab” in the right. Entities are game pieces we can work with in map making and they are extracted from the PAK files we added to the id1 folder in QuakeDev. If all previous steps have been followed correctly then the Entity Browser should be full of entities. If not then something has gone wrong and you should go back and retrace your steps through the installation process.

Whilst you still have the entity tab selected, we can add the START.WAD file we downloaded to give us some basic textures to work with.

From the list in the Entity tab, select the Key “wad” (this menu is context sensitive and clicking wad should display “Wad Files” in the section below the list).
Click the + arrow and navigate to your START.WAD file in QuakeDev/wads
Select “Absolute” and click “Ok”
The WAD and the directory path will appear in the box

You can see contents of the WAD file by selecting the Face tab at the top right
If you don’t see any textures, click the title “Material Browser”
Select Start.WAD from “available” and click the + icon to move it to “enabled”
Click the title “Material Browser” again to see the textures

Compiler Setup

Its now time to set up the compiler for Trenchbroom. What we’re going to do is set up a bunch of sequenced tasks to successfully compile any map we make. You don’t need to know every single detail about a Quake Map compiling process, but it does help to know the basics. Compiling is the act of taking a working map file in Trenchbroom and converting it to a file that is readable by the Quake engine (a bsp file). This typically consists of three stages, QBSP, Vis and lighting.

QBSP is the first stage and is the process that builds and calculates all of the geometry and collision data, as well as extracting needed textures from the WAD file and repackaging them into the bsp file. A map is actually fully playable with just this step, however you’ll be missing lighting and and optimisation if you were to stop here. That said; if you’re wanting to quickly test logic or geometry changes and don’t want to go through a full compiling process (which on larger maps can take some time on lower end PCs) then setting up a profile just to run a QBSP compile might be worth it to save some time.

VIS is the stage of compilation that calculates PVS (Potential Visible Set) data for the level (If you’ve ever built a map in Source, this is essentially VisLeaf) and its used by the engine to calculate which parts of the map should be visible to the player based on their location. In its simplest form, its optimising the map for the player by breaking it into chunks and calculating which chunk should be rendered at that time. This is the part of the compiling process that can take the longest depending on your CPU.

Light is often the last stage of the compiling process and it calculates lightmaps for the level using each light entity found in the bsp file.

With that out of the way, lets set up the Compiler:

Click “Run” from the top bar in Trenchbroom and select “Compile Map”
Add a new Compiler Profile and call it “FullCompile” (leave the working directory set to its default value of ${WORK_DIR_PATH})
Add the following tasks:
- Export Map
- Run Tool (this one is for QBSP)
- Run Tool (this one is for Vis)
- Run Tool (this one is for Lighting)
- Copy Files

Parameters for each task are separated by a space, expressions are prefixed with a $. Additional information on compiler parameters can be found in the ericw-tools documentation and Trenchbroom Documentation. I will explain each task of the compile process and what each parameters mean, but if you just want to set the compiler up and get started, you can simply ignore the explanation and paste the parameters directly into the text box under each task.

Export Map

File Path: ${WORK_DIR_PATH}/${MAP_BASE_NAME}-compile.map

This task exports the map file to the File Path provided. If our map is called Map1, what this will do is write a copy of the Map file called “Map1-compile.map” to our working directory, which in our case is “QuakeDev/id1/maps”. Its not immediately clear as to why the documentation suggests we do this, I can only assume its to backup and protect the main map file during compilation, as this new “-compile” version of the map is the one that is read by the compiler in subsequent tasks.

${WORK_DIR_PATH}/ – is a reference to the Working Directory of the map set in the Compiler profile. We left this as its default value which simply points to the folder which our map is saved in.
${MAP_BASE_NAME}-compile.map – is what the new map will be called. In this case it references the name of our map and appends a suffix “-compile” to the end

Run Tool (QBSP)

Tool Path: C:/QuakeDev/tools/ericw-tools-v0.18.1-win64/bin/qbsp.exe

Parameters: ${MAP_BASE_NAME}-compile.map ${MAP_BASE_NAME}.bsp

This task runs the QBSP executable file in the ericw-tools folder, and writes the bsp data to a .bsp file. The two parameters needed for this task are:

${MAP_BASE_NAME}-compile.map – the map file which will be read by the QBSP.exe
${MAP_BASE_NAME}.bsp – the name of the bsp file that will the bsp data will be written to. In this case it’s just the name of the map

Run Tool (Vis)

Tool Path: C:/QuakeDev/tools/ericw-tools-v0.18.1-win64/bin/vis.exe

Parameters: -threads ${CPU_COUNT -1} ${MAP_BASE_NAME}.bsp

This task runs the Vis executable file in the ericw-tools folder, and writes the PVS data to a .bsp file. The two parameters needed for this task are:

-threads ${CPU_COUNT -1} – this parameter goes over my head as my knowledge of CPU cores and threads is almost non existent, but my understanding is that this is explicitly telling the CPU to use the maximum number, minus 1, of threads available during the vis compile.
${MAP_BASE_NAME}.bsp – the name of the bsp file to write the PVS data to

Run Tool (Light)

Tool Path: C:/QuakeDev/tools/ericw-tools-v0.18.1-win64/bin/light.exe

Parameters: -threads ${CPU_COUNT -1} ${MAP_BASE_NAME}.bsp

This task runs the Light executable file in the ericw-tools folder, and writes the lightmap data to a .bsp file. The two parameters needed for this task are:

-threads ${CPU_COUNT -1} – see above
${MAP_BASE_NAME}.bsp – the name of the bsp file to write the Lightmap data to

Copy Files

Source File Path ${WORK_DIR_PATH}/${MAP_BASE_NAME}.bsp

Target Directory Path: ${GAME_DIR_PATH}/${MODS[-1]}/maps

This task copies the bsp in the working directory to the maps directory within the last enabled mod. This is the file that will be read by Quakespasm to play the map. I actually am not entirely sure why this is needed (and why we can’t just run the bsp file from the working directory, but without this stage, you won’t be able to play your map from Trenchbroom, so its best to add it and not ask too many questions.

${WORK_DIR_PATH}/${MAP_BASE_NAME}.bsp – the working directory of the map file
${GAME_DIR_PATH}/${MODS[-1]}/maps – the maps folder in the last enabled mod of our game directory (in this case QuakeDev/id1/maps). $MODS[] is an array containing all enabled mods for the current map. I’m not entire sure I understand what’s going on here however.

And that’s it, the compiler is set up. If you want to test and make sure everything works; save the current scene as something like “testMap” and click the Test button. A console log should be printed displaying the following:

Lets See It All Working

You’re done! Trenchbroom is ready to be used. It would be a shame however, not to end this post without seeing it all working and ensure our setup is correct. So lets make a very quick room, with some geometry, a player start, and a point light. Don’t worry about understanding any of this for now, as in the next post, I will walk you through the basics of mapping in Trenchbroom, including UI navigation, brush manipulation, texturing etc.

In the perspective 3D view, click on the cube and Hold the SHIFT key – this will enable brush manipulation
Hover over the sides and extend them out to make the brush a bit bigger (we will use this as a floor piece)

With the brush still selected, press CTRL+D to duplicate it
In an orthographic view, click and drag the new brush to the side
Resize the brush to create a wall

Duplicate the wall brush 3 more times to create 4 walls surrounding the floor piece
Duplicate the Floor and move it up to create a roof piece and seal the room (its important that the whole room is sealed, as gaps into the void will create leaks and the map won’t compile correctly)

Inside of the room we have just created, select the four walls
Navigate to the “Face Tab” in the top right and select a texture to apply to them (I went with city1_4)
Apply a different texture to the floor brush and a third texture to the ceiling

Navigate back to the “Entity Tab” and using the Entity Browser search bar in the bottom right; search for “info_player_start”
Click and drag the entity into the world (this will be the spawn point for the player)

Search the Entity Browser for “light” and drag it into the scene

Save the map, Select Run from the top bar and then select Compile
Compile the map
Select “Launch”
Select your QuakeSpasm launch profile and in the “Parameters” add “+map ${MAP_BASE_NAME}”

This will load the map you have just compiled by default. Press launch and see your very basic room in engine!

And there you have it! A functioning Trenchbroom to start mapping in! Next post I will be going into more detail as to how to use Trenchbroom and become more proficient with the tools.

Dev Blog : pl_carapace_a3

Posted on March 24, 2025 by g.hill - Dev Blog

To quote a comment I made in the “From The Vault” blog post a couple of weeks back regarding pl_carapace:

“I still have the VMF file for this map, however I don’t see myself doing any further work to it. I would rather commit that time to working on a new urban map “

Intrduction

So that was a lie

At the beginning of the year, I had been toying with the idea of making a new Team Fortress 2 map. I wanted to take something from concept, through development and ultimately release it on the Steam Workshop. I set myself a deadline of 12 months (a pretty reasonable amount of time for a side project I would work on in my spare time) and was going to make use of all the level design teachings and learnings I had acquired over the last 3 years. During January I gathered reference images and did some foundation work that all designers should do before starting a level. However when February came, I’d had already given up on the idea. I was so busy doing other things in my life that I just couldn’t commit the required energy and hours of an evening to working on a map. I hesitate to even say the project was dead upon arrival (it was dead before it had left the house).

2 weeks later I would be out of a job. I had known things weren’t looking amazing at work; we were hunting for a publisher in a economic climate where companies and investors were tightening their belts. What took me by surprise however was the immediacy of it all. I went from having a meeting Monday morning about what work I was planning to do that sprint, to being told I was to go home and start looking for new work (all within an hour).

This had given me a second wind on the urban map I had planned, and after finding the .vmf of pl_crapace for the blog post, I realised it really didn’t make all that much sense to start something from scratch. The map was there; it worked, it just needed a little love.

2 weeks later, it turns out it needed a lot of love. I’ll be honest, this update was brutal. I was working on the map ~12 hours a day, 6 days a week, and each day I felt like I was making less and less progress. This was not a sustainable way to work, however I was determined to complete the update and get it out before the end of March and I’m glad I persisted. I truly believe that I have broken the back of the work on this.

It was gruelling and tiring, and I’m certainly a little burnt out… but it was worth it and I look forward to the first playtest of pl_carapace_a3. Let’s dive into the update.

Alpha 2

I should probably talk generally about the alpha 2 version of this map before diving into the overhaul that alpha 3 went through. The map was originally made in 72 hours over a weekend in 2020; it was a payload map that took the players and the payload through an urban city ultimately ending up on a subway station. I wanted to capture the tone and aesthetic of koth_kong but in the payload game mode. I failed miserably at this! I don’t beat myself up too hard about it; creating a map in a 72 hour jam is a draining marathon, so even getting a map working and submitted is a success in my books. However I couldn’t look at the map and see it as anything other than a failure in meeting it’s original goals.

A failure in tone

I have no idea why I set the map during the day when koth_kong’s aesthetic work so well due to it night time skybox. Lights and signs pop far more effectively in a darker setting and the general tone is slightly more mysterious. You lose all of this in a day time setting and I can only assume I set it during the day for development purposes and then just forgot to change it.

A failure in theme

The layout itself feels less like a city and more like a random assortment of geometry scattered about a sandbox for players to run around in. The city skyline isn’t varied or high enough, meaning I never felt like I was actually in a larger city that was looming down on me.

A failure in gameplay

And ultimately the layout offered a few too many side paths for players to get lost in. The player focus is taken away from the cart, and so the gameplay itself suffers as a result (I actually think I might have over compensated for this in alpha 3, but I’ll get to that further down).

At the time of writing this post, the map has been downloaded 374 times on TF2maps.net and the only comment was left by a forum user, 3 years after the Jam, who really seemed like it for some reason. Huh – thanks chief!

With these problems identified, lets get working on fixing this map up!

Alpha 3

General Fixes

First thing I set about doing was changing the skybox to night time. An easy change, and it definitely took the map one step closer to nailing the tone I was looking for. I ended up going for “sky_nightfall_01” and set up the environmental lighting to reflect the skybox change. There’s a really handy resource you can find on valve’s official developer site that gives you the values to plug in.

I also randomly scattered a large number of towering skyscrapers outside of the boundaries of the map to give the effect that there was a larger city this map was situated within. Adding some variety in height and dev textures really gave the city a bit of a depth. In the future I plan on updating this to be a 3D skybox, but given my lack of experience in setting one up, I didn’t really fancy doing it at this stage.

With the easy stuff done and out of the way, I took a shot of tequila and mentally prepared myself for the hours of work ahead of me. I should note that I didn’t work on each section in this order, but it makes sense for me to talk about them in the order the players will experience them.

The rework of BLU spawn

If I could describe the start of the map in carapace_a2 it would be… underwhelming and unfocused. Of all the payload starts, this certainly was one of them. I wasn’t entirely sure what the game plan for either side was. BLU team had 4 routes upon leaving spawn:

These flanks were designed give BLU a chance of attacking a RED defence from multiple angles. The start of Payload map is often bloody as RED has had a chance to set up multiple sentry nests and can lock down choke points, preventing the cart from even reach the first point. Give the attacking team options and, with a bit of coordination, its harder for a defending team to create a fortress if attacks are coming from multiple directions. However, these alternate routes brought with them a number of issues. Namely that the focus was drawn away from the payload, i.e. the whole goal of the game mode.

The flanks were quite extreme and extensive often taking BLU team members far away from the action and deep into enemy territory. The far left path (1.) being extremely notorious for this as it has the potential lead an attacking playing all the way back to the final sections of the map without even encountering an enemy player. This would lead to some confusion as to where players were supposed to be going, and detracted gameplay from the more important areas where gameplay was supposed to be happening. It sort of feels like a company cannibalising its own profits by spreading its customers across too many products.

RED team on the other hand suffered from a lack of a defensive positions to hold. There wasn’t really a good spot for engineers to set up Sentry nests (at least not that would be useful for defending a cart push), and because of the 3 flanking routes, the defence had to be spread thin to cover all angles. Overall I didn’t like any of this layout and so decided to cut the attacking routes down from 4 to 2.

The core philosophy with this change was “keep the focus on the cart whilst offering cover and alternate routes for the BLU team”. I don’t think its perfect, but its certainly better. There are 2 routes the attacking team can take

Push the cart
Head down to the lower level that acts as a flanking route

Every other route ultimately loops round and returns itself to the track and the payload. I offered the RED team a little enclave to the left where a sentry nest could be set up (which is still vulnerable from snipers and soldiers attacking from the opposite corner). RED team also got a sniper spot above that, which could also prove useful as a safe teleport exit.

I decided to keep the building to the right, but closed off any routes that took the players deeper into the level. For RED it acted as a solid defensive position BLU team would need to flush out if they wanted to protect their rear from attack when pushing the cart towards A, and for BLU it served as some good cover for advancing. I think I might need to reopen up the building to allow players to re-join the payload track at some point (right now they are forced to exit via the lower level which isn’t great, but I’ll see how the map plays out before making that change).

I also added a bit of layered height to the area. It felt a little flat and boring in alpha 2, so this certainly makes the area feel a little more interesting. I’ll see in playtesting if this was the correct choice or not.

Capture Point A

The original capture point of A suffered from a number of issues. The first (like BLU spawn) was a lack of direction. There were multiple paths sprawling all over the area which lead to a lack of focus on where the gameplay was suppose to occur. I was offering the players too much choice, which ultimately lead to an unfocused messed. The second issue was that it lacked any visual clarity and coherency. It really did feel like a clutter of unorganised greybox cubes, scattered around in an attempt to imitate an urban city.

The new design attempts to rectify some of these problems. The flow of city feels more logical with both the building layout and the payload path following the flow of the newly added canal; taking inspiration from the Cheonggyecheon that runs through Seoul. Attacking players can cross the bridge to the other side to get cover from defensive fire, or alternatively drop down into the canal and enter from the lower level. RED team have a pretty solid spot to the right of the capture point to set up defences, although care should be given to the right as it is a good flanking spot for BLU.

The whole area has been opened up which does however bring with it some gameplay concerns. Namely that there is very little cover now for RED when they are leaving their spawn. Not an issue for setup, but as BLU are pushing closer to the point, I fear this might lead to RED getting slaughtered upon leaving their forward spawn. I’m a little concerned I made this area too open and simple, so this will be a key thing I’ll be keep an eye on in the next playtest.

Capture Point B

In an attempt to make B capture point feel a little more unique, I decided I wanted close it off. That was a stark contrast to A that now felt much more open. I want to give close quarter combat classes a chance to shine, so compacted everything in to this apartment complex. The payload now goes down under the building (inspired by the 3rd point push in pl_badwater) and both attackers and defenders can use the numerous flanking routes to get up and close to each other. I suspect Pyros and Heavies to excel here.

I removed the unnecessary underground path BLU could take to… well, nowhere. And moved the BLU forward spawn a little further up. I fully expect this to be a explosive spamming choke, but that’s by design. You’ve got to allow for it in some places.

BLU team could also get on top the rooftops of some of these buildings using Soldiers, Demo, Scouts and even creative engineers who use their dispensers to climb the wall (I even added a health and ammo pack up there to encourage it). I don’t expect RED to ever use this area, but playtesters always surprise me. Rooftop combat is something I would like to explore in future updates as it would be something that would set it apart from other TF2 maps under the Urban tag, but we’ll wait for a future update to try that out.

Capture Point C

Capture point C remains identical in terms of the payload route, however the surrounding area has had a complete rework. I opened up the route to the right allowing both the RED team to reach the upper flanking routes to defend B, but also for BLU to be able to flank once B has been capped.

The BLU forward spawn has now been moved to the end of this road (however it still only opens after C has been capped) and the route to D now has a building where the Basketball Court used to be (RIP BBall court 2020-2025). The metro station entrance now appears just after the capping of C offering some cover for defensive sentry nests should RED decide to abandon the defence of C.

Not much really to say about this section. I actually really struggled with the layout due to moving the RED spawn. I want the RED team to be able to access B with haste, but I don’t want BLU to find their way to RED spawn on the way to capping C. A one way drop makes sense, but the rear Red spawn room is underground making this a little awkward. A problem for future Graham I feel.

Capture Point D

Capture point D retains its “theme” but was pretty much built from the ground upwards. I knew I wanted the map to end in a metro station; something that has been in the original design since 2020. However the original layout just felt nothing like a metro station (except it being underground I guess). The track also went on just a little too long (It wrapped around almost 270° on itself like playing a game of Snake).

So I cut the track length by a third (having it curve off to the left instead). I rebuilt the ending to make it more believable as a metro station as well as trimmed off a couple of routes BLU could use to attack. I am a little sceptical this area will act as a good final point however. There’s limited space for RED to set up defences and the fact that BLU can just drop in from upper levels really limits the effectiveness of sentry guns. This is definitely one of those “let’s see what the playtests make of it” moments, but I do fully expect to have to rework this area in Alpha 4.

Closing Thoughts

So, how do I feel about the update? Mixed honestly. On one hand I’m super happy I updated it. I am much happier with the map, and the general flow when running around it feels much better. Its more optimised, less confusing and it even has spectator cams now (neat!).

On the other hand, I fear I might have gone too far in some directions. In an attempt to make the map feel more believable, I might have created something not entirely suitable for Team Fortress 2. I was playtesting some maps the other evening and couldn’t help but notice that doors are larger, ceilings taller and spaces typically more open. I won’t know 100% until I’ve had a few playtests however.

Regardless, the core of the map feels much better, so I am hoping any future updates with be small changes as oppose to the huge overhauls that I’ve subjected it to over the last couple of weeks. Until next time!

Projects From The Vault

Posted on February 24, 2025 by g.hill - Dev Blog

Introduction

Its certainly been a while since I last wrote about any of my work on my site; 7 years to be precise. Rereading the old development posts of CP_Nautilus was like flicking through an old photo album; each memory bringing a strong feeling of nostalgia (but you cringe at the haircuts you thought looked cool). That doesn’t mean I’ve been idly wasted these years, sitting on my hands doing nothing. On the contrary, I had intended to start up numerous development blogs regarding Team Fortress 2 maps I was working on, debriefs of Ludum Dare and GGJ projects I had participated in, rules for boardgame prototypes that cluttered the dining room table in my flat. But, unfortunately, adult life gets in the way. Its been an incredibly busy 7 years with numerous job changes, home moves, literal country moves in the case of the last 2years. The desire to write about my projects, let alone finish them just hasn’t quite been there.

Until now! What I have (like any game designer) is a plethora of unfinished projects that are now ultimately lying on an old HDD in a cupboard somewhere labelled “to finish”. Let’s be realistic, these projects aren’t getting finished. That doesn’t mean they were a waste. I had fun making them and I drew a lot of lessons from the challenges I faced, but I know these projects aren’t getting any more love from me.

What I thought would be fun however, would be go back and document some of these old projects; the context they were made in, my thoughts on them now, as a more experienced and wise developer, and generally just to give them a nice send off. This specific blog will focus on my own solo level design projects, with a separate blog being written up for all the game jams I participated in. So, without further delay, lets dive in.

CP_Nautilus

I’ve written pretty extensively about CP_Nautilus in my previous blog posts. It was my first proper TF2 map, and by far my proudest and most developed project that I’ve worked on in my spare time. It started officially during the month and a half period of unemployment in 2015 that came as a result of the redundancy from my first industry job. I was desperate to get some level design experience and Source provided incredible tools for level designers to work with.

Countless hours of every day in the week, were spent working on this project with no real idea as to what I was actually doing. I was tossing props and brushes into the editor without all that much thought or design, and would then edit until it resembled something that I liked (to be fair, my methods haven’t changed all that much over the years). I remember feeling a real of sense of cabin fever during these long weeks of portfolio work. My only real social contact with another human being being the Starbucks Barista who would consistently write “Grim” on my morning coffee (I still to this day know if this was a genuinely mistake or just a joke I didn’t quite get).

9am – midnight everyday was spent working on the map, but due to a lack of experience, that time was inefficiently used. I spent a lot of time fixing small issues that I would later go on to completely remove. Huge amount of work was wasted after the first iteration of the layout proved too confusing for playtesters and thus needed to be simplified.

I had ambitions that greatly exceeded my skills with the tools, which in principle is a great way to improve, but in practise led to a lot of wasted work in a period where I was desperate for a portfolio piece. Huge lessons were learnt during this period, however the map would ultimately go on hiatus for 3 years after only 1 iteration, as I would get another job in the industry that would eat into my daily hours.

Version 1 was very confusing to navigate and far too detailed in some areas for a greybox that hadn’t been tested

I would return to produce 3 more iterations of the design (documented in blog post a3 and a4). This time, I was far more experienced as a level designer and was more skilled with the Hammer Engine. The design was more refined, the greybox cleaner and I felt like the map was getting into a pretty good state. However I had definitely burnt myself out by the time Version 5 was uploaded to TF2Maps (the website where developers can discuss, host and playtest each other’s maps). I was still working a full time job at a game studio, so all work was being done in the evenings after I had gotten home. The momentum fizzled and ultimately never returned.

The actually VMF file for this map is lost now. In 2021 I build a new computer and stupidly didn’t think to move any files over from my previous HDD. I “think” a copy still exists on my parent’s PC back in my home town. A bit sad to think about how so many hours of work has been lost to the digital void, but some projects are perhaps best left to memory. You can still download the actual BSP file from TF2Maps however and even read the discussion thread. It was actually quite interesting for me to go back to 2015 and read where my thoughts were at the time.

After returning to the map 3 years later, huge areas were re-worked to be cleaner and lighter, as well as addressing a number of the key gameplay issues raised by playtesters

72 Hour Maps

I thought I’d lump the next 3 maps all together into a single post under the title “72 hour maps”. TF2Maps hosts regular 72 hour mapping contents. The idea being that a mapper sits down for a long weekend and works to complete a map over the course of 72 hours (somewhat similar to a game jam). This is a very taxing experience, however one that is incredibly fun.

Over that last decade I have participated in 3 of these mapping jams, submitting a map for 2 of them. It’s surprising how much work you can get down by not sleeping and living off a diet of endless coffee, however the experience often left me drained of motivation and so these maps never really got worked on after the jam had ended. If you are a level designer, I highly recommend checking these contests out as they are extremely fun and memorable experiences. And so, in chronological order:

pl_distribution [2015]

This was my first 72 hour jam and was probably the one I had the most fun with. I remember carrying my PC back from my office* on the Friday evening it was due to start, setting it up in the living room of my flat and creating the playlist that was going to keep me company for the next 3 days (*I had recently been hired as a level designer for an indie company in Dundee, but the company was running on a tight budget and lacked the money to provide me a PC so I had to use my own – those are the small little details I fondly remember of my time as a game developer in Dundee).

What I created was… something. This was my first map since finishing my initial work on CP_Nautilus, and I was keen to try out a different game mode. Payload maps are interesting and fun to play but ultimately a level designer must approach them with a different design philosophy from capture point maps.

You have a train being pushed along a linear rail so you can almost always predict where the key gameplay is going to take place Not to mention there’s additional logic required just to get the map functioning in the first place. I still remember the relief at 10am on the Saturday morning when the map was finally working and playable.

(I even took a screenshot to celebrate the occasion)

If I was to do it again, I think I’d aim to get a working version of the map playtested quicker (this seems to be a running theme with a lot of my personal projects). Had the issue of scale and pacing (two issues which ultimately would require a lot of work to rectify) been spotted a day earlier, I think I might have had the energy and determination to get them fixed. Still, I thoroughly enjoyed the experience and was proud of myself for actually submitting something, even if it wasn’t my greatest work.

Unfortunately both the VMF and BSP for this map have long since been lost (not even available for download on TF2Maps, which is a shame). I had to dig these images from an old Facebook post from 10 years ago. Maybe one day i’ll stumble across it again and will run around just to see how bad it actually was.

koth_untitled [2017]

My second 72 hour jam event wouldn’t take place for another year and a half, and this one was less successful. I think what didn’t help was they pushed the start time back from 6pm to 11pm, which meant I wasn’t able to quite get the energy from the hype I previously had in 2015 to carry me through the first night. I remember being extremely tired before I had even really begun, and it was only downhill from there.

I can’t even remember all that much, as most of the weekend was a bit of a blur for me. I do recall wanting to make something “alpine themed” and something simpler from the previous attempt in 2015. I settled on a king of the hill game mode set around a broken bridge that had collapsed over a raging river. Clearly I hadn’t got the memo from myself on creating a “simpler design”, as water in Team Fortress 2 has always been an awkward gameplay element to work with (not to mention its implementation within Source is a bit of a pain). I remember spending hours trying to get a flowing water effect to look good, as well as messing around with push entities to force players towards the edge of a waterfall. I’m always in favour of pushing the boundaries on design within games, but I feel a 72 hour mapping contest is perhaps not the best environment to do so.

There’s not too much else to say about this one. I had a full blocked out map, but never got around to actually submitting it or even playing on it. My heart just wasn’t in this one it seems.

pl_carapace [2020]

3 years later and after 5 months of COVID lockdown, I have an itch for another 72 Hour Mapping jam. This one returned to the more appropriate start time for me of 7pm and I was coming in with a little bit of pre-production work already done.

I wanted to make an urban map similar to koth_KongKing but with a payload game mode. This is a highly under utilised texture pack within the TF2 mapping community and one of my favourites. I had a rough paper layout and a collection of reference images to work with. I felt pumped! This was probably my most successful of the 72 hour jams I’ve done, as not only did I get a working level, I even managed to get a second iteration tested and committed.

Now, the final commit still wasn’t great; The urban them never actually made it anywhere into the build and there there were definitely some glaring issues with sightlines in the main area. The city felt a little nonsensical in layout and the scale of the map was still a little big. But overall a huge improvement on both the previous attempts I had made.

I still have the VMF file for this map, however I don’t see myself doing any further work to it. I would rather commit that time to working on a new urban map (but who knows what the future holds for this). You can download the latest BSP from TF2 maps.

cp_SaxtonsBooty

CP_SaxtonsBooty was a project started during the second COVID lockdown in 2020. The map started off as a King Of The Hill map with the hill being the inside of a giant skull cave. Players would approach from either side of the cave and would try to take control of the centre point inside of the skulls mouth. However this type of symmetry in the map design made some issues immediately apparent. In KOTH, designers want the fighting to occur around the Hill (hence the King Of The Hill). Once a team captures the point, they make a effort to fortify their position and then push the enemy team back towards their spawn, whilst the enemy team regains strength, builds up its ubers and prepares for a push on the main point.

When a team is approaching from the side of the Hill, this game plan isn’t quiet as applicable any more. Meaningless fighting occurs from either side and the Hill becomes something of an after thought. I could have found a way to edit the design of the map to make the theme work with the game mode, however after some rethinking, I changed it to a 2 point attack/defend game mode.

The theme of the map remained the same; A pirate shanty town, but now attackers would have to fight their way up through the town. The first point in the lower market place and the final point being inside the mouth of the skull cave. Elevation proved to be a big driving force behind the design as I wanted the attacking team to have a beautiful view of the city and the skull, as they were stormed their way up through the streets.

Credit to Janet Simeonova

My partner at the time sculpted a wonderful skull to be used for the final point and the buildings were built to look like they were constructed from old ship parts. The whole aesthetic was everything I had wanted from the initial concept, however I was running into a number of design problems with this iteration as well. Certain classes in Team Fortress 2 really benefit from height advantage; namely the Soldier, Demoman and Sniper. The elevation would allow the defending team to rain down unimaginable chaos and spam from above. My initial way of solving this was to allow the attacking team to enter most of the houses on the way up.

Attackers could use the walls and ceilings of the buildings as cover for their attack. But this opened up the potential problem of players getting turned around and lost in the maze of the shanty town. I decided to leave that as a future problem to solve and push forward with the greybox, and after a couple of weeks the map really did feel like it was beginning to take shape.

The rough concept of the changed map from KOTH to CP

I really wanted height to play a huge role in the map. This feeling of the shanty town towering down on the attackers

It ultimately would never make it to a playable state which is a shame, since I was extremely fond of the theme, atmosphere and the general direction it was taking. What’s worse is this is another VMF lost to the void. I’m certain there is backed up somewhere in a dropbox or USB stick. I would like to run around it again and see where work can be done to at least get it playable… perhaps a job for a rainy afternoon.

"Misc"

Abertay University Talk Level

This was a quick level that I built along side talk I was preparing for students at my old university. I wanted to have the slides walk through the process of level design and show off images from a consistent project to back it up. I can’t find the slides or any of the other additional materials I used, and the map was never playable, but I still have screenshots saved in my google drive.

Day Of Infamy Train Station

Whilst at the EDGE indie festival in 2017, I had a chat with the New World Interactive dev team about their game Day Of Infamy. When I found out it was built in Source, I said I would have a little play around making a level. The general idea was to build most of the level inside a giant bombed out train station inspired by Grand Central Station in Manhattan and Antwerpen-Centraal station in Antwerp. I didn’t got too far with the project, but it was fun to chat with the devs (and I did get a free T-Shirt out of the whole exchange, so overall I consider that a win).

Doom + Prodeus

At some point over the last 3 or 4 years, I had a desire to work on some old school maps. This ranged from retro games (Doom and Half Life) to newer games styled on retro predecessors (Prodeus) to the downright weird (Daikatana). The Daikatana level never materialised (the level editor was as clunky and awkward as the actual game itself), but a few afternoons were spent messing around in various other engines.

Nothing tangible to show for these, except this neat little gif I found of an underground train level I made one afternoon in the Prodeus level editor.

And that’s it. This has been a dive into a number of the personal projects I started, and ultimately abandoned over the last decade of my life. I hope you’ve enjoyed this little trip down my memory lane as much as I have. Until next time!

Dev Blog : cp_nautilus_a4

Posted on January 3, 2018 by g.hill - cp_nautilus, Dev Blog

Introduction

Like a fart in the wind, alpha 3 came and went with naught but a wrinkled nose and a mutter of “smells a little odd in here”. There were 2 playtests for a3, one that I managed to play in, the other one I did not (and it’s sods law that the one I was unable to attend had almost twice the number of players). Alas we strive on! The biggest problem was that I forgot to change the capping times from “dev” to “test”, so teams were capping points in 5 seconds as opposed to desired 15. See, I want to spend as little time as possible testing out things I already know work, so by setting the cap time to something ridiculous like 5 seconds, I can run through the map very quickly making sure everything else works. Simple… I just need to remember to change them back. And the biggest problem with something like this being an issue is that EVERY TESTER FEELS THE NEED TO TELL YOU. It’s not that the feedback isn’t useful, it’s just that you only need one or two people telling you it’s wrong for you to get the idea, and if everyone is telling you the capping time is too low, they aren’t focusing on other more important things like “map is confusing”, “This sightline is busted”, “Spies are terrible here because there’s no great ammo routes” etc – Basically stuff that I hadn’t noticed, that I could iterate on. It’s one of the main reasons you should clip alpha stages of your map. Because if you don’t, players never shut up about it, they get fixated on it and it distracts from your playtest.

Now don’t get me wrong. This isn’t the tester’s fault at all; This rather morbid smelling slip of gas is completely on me, and I know for a fact that if I was playtesting a game or a map and there was a giant Error message on my screen, i’d probably point it out too. But it does sort of soil the whole testing experience.

Alpha 3

That saiddddddd, both play tests offered me great feedback, although I sort of knew going in what one of the MAJOR flaws in Nautilus was; BLU spawn. With the Alpha 3 overhaul I did just enough to make this section playable but knew it wasn’t great, that said the minute I started properly running around it and testing it out, I realised it was worse that I initially anticipated.

BLU spawn was too close to Point A

It was far too close to the spawn for one thing and the routes were just corridors (there was no meaningful or fun combat zones that the players could actively fight in). Typically there’s an open area when BLU initially run to their death upon the spawn doors opening, followed by some connecting rooms that lead to the first point. This allows RED a chance to hold off BLU and let the time count down before inevitably having to fall back to the point to defend. Nautilus didn’t have that. Instead players could run straight from the spawn, through a few corridors and right onto the point with little to no meaningful resistance. Coupled with the botched cap time and it was safe to say that RED weren’t happy. The first port of call was to open some of the early sections of the map up even further as well as move the point away from the BLU spawn.

The lower path now lead to nowhere

Another issue which manifested itself from the redesign was that right path lead to a lower level that sort of went nowhere. It originally led to the point but after hacking apart A in alpha 3 the area seemed a little redundant. I had a thought that it would allow demos and soldiers a chance to get some height on the point, but they could do that anyway (and without damage) via the middle route. So the area was just a bit of a waste.

When BLU got to the point problems went from bad to worse for RED as the small area for the teams to fight in meant sentry guns were useless and what small defence RED had could be wiped out reasonably easily. Overall A and BLU spawn held on to too much of the original design and the end result was just a bit of a mess. And the cherry on top of all this trash was the giant sight line from RED forward spawn to the point that I somehow managed to miss. It was clear that I was going to need to strip all this out and start again.

Navigation was still a mess

Other sections didn’t fare much better; For some reason I removed the stairs out of the far side of B’s pit in alpha 3 and as such falling in there was practically a death sentence as the stairs to the left were the only way out (short of rocket jumping). Thinking back I think it might have been to make space for the huge and out of place ramp down to the lower levels of C… my bad. The main route from the final red spawn to B was also a nightmare for many not really knowing where to go. In fact navigation throughout the whole level was generally a nightmare with players frequently getting lost. This is the problem with working on something so closely for such a long time is that you’ve got the layout memorised, you could fly through it in your sleep! But hand it someone completely new and there’s a good chance that of the 3 direct routes to the point, they’ll take the 4^th and end up in the ass end of nowhere. And so once again, I picked up my hammer for we had some building to do.

Alpha 4

BLU spawnroom update

Ooft another big one, lets get too it! First I completely rebuilt the spawn room. Typically in Team Fortress 2, spawns rooms for the blue team start in a single room and then branch out of the antechamber into a much large room with multiple exists for attack. This is to prevent spawn camping and cramming everyone into a tiny room. The previous spawn room was guilty of this so it had to go. It’s still not perfect in my eyes (would ideally like it even bigger!) but it’s a start.

BLU’s spawn room got a complete makeover

And now it even has an antechamber!

From the screenshots you can also see that the lighting has changed. In an attempt to actually make the name cp_Nautilus make sense, I’ve tried to give it a more aquatic colour scheme. It’s very much in it’s experimental phase right now, but as the next few updates come out, i’m hoping to solidify the lighting and underwater skybox.

Burn it all down! And by that I mean Point A

I stripped all of the starting area out save for a few elements that I actually quite liked. So let’s start with the giant pointless middle section. It served ZERO purpose in Alpha 3 acting as a little spot for players to run down, look around, shrug and then ultimately get killed by a stray Demoman pill – fun right? I wasn’t 100% what i wanted to do with this area, just that I wanted it to be grand! In Alpha 3 the structure in front of the point felt a little… weird. It didn’t make sense; “why was it there? Why did the architect decide it was needed!? That said, I actually quite liked the structure of it and wanted to try and preserve it in some way.

The main room was completely opened up allowing more room to breath. It’s still not perfect, but it’s a huge step in the right direction

So I kept what i could and started hacking apart the rest. I drastically raised the ceiling and spread out the geometry. The old A had a very claustrophobic feel which many people complained about. These changes were designed to fix that.

I also really liked the idea of flooding the lower level. There’s something about water maps that I really enjoy, and I feel mappers are often hesitant to add large amounts of it to their tf2 maps (let alone incorporate it into their gameplay). Let’s face it, the Water Temple is the second best dungeon in OOT.

At first I was going to have a lower passage almost fully submerge the player underwater leading to a longer and more dangerous route that would appear behind the point allowing for ambushes, but felt that was maybe a bit over the top. So I instead settled for a giant overflowing pool in the main room that’s subsequently flooded the lowest level of the map up to about shin height. I was informed during playtest that if it’s too high it can negatively impact rocket jumping but no one seemed to actually experience this. A lot of people liked the theme though, so it’s definitely something i might push further.

Point A’s “fight” area was made far larger, the top passage allowed for a quick route to the point but is poor in cover so players risk getting picked off by snipers and sentry guns down the corridor. A lower route was added which connected to the main hall. This was the longest of the routes but appeared behind the point offer great ambushing potentials for spies and scouts. After watching a few games and thinking more about this route, i’m not actually the biggest fan of it and instead might have it go under the points instead in Alpha 5. The middle route takes players to the right either behind the waterfall or through the sub room. It’s very similar to alpha 3’s route, but takes a little longer.

Point A was opened up allowing for less CQC

Rebuilt RED forward spawn

That nasty sight line had to go so i moved the whole spawn room back around the corner and rebuilt it to better suit it’s new position. Someone actually complimented how it looked which was nice since it’s entirely dev brushes. I agree with this individual, it DOES look nice! Too bad it’s getting even more modifications in Alpha 5 – RIP RED forward spawn (a4-a4). Players now had to leave the spawn and follow the arrows around the corner to the point before they could defend it which made for a far more bloody capture of A than in alpha 3 (where they could all stand by the spawn door firing rockets and sniper shots at a completely exposed point).

Added a BLU forward spawn and re-added ramps at B

People were complaining that they needed to walk a great distance from BLU spawn to C after capping B, and whilst I do sympathise, I just assumed engineers would build teleports… Alas I caved to the pressure and threw one in by B point. While I was there I also made the area a little wider and re-added the ramps.

A forward spawn was added near B for BLU and the ramps made their majestic return

General fixes

Finally I fixed the capping timers along with a few clipping issues. Moved a bunch of pickups around to compensate for the new geometry changes and replaced a bunch of the crate brushes with actual props as people were complaining the off grid brush was messing with their sticky bombs.

Conclusion

And there is alpha 4! It’s been uploaded now for over a month so I’ve already watched a few playtests of it (was unfortunately down South for Christmas so didn’t get a chance to play in any =[ ). Now that the Christmas holidays are officially over I’m ready to ramp back up to speed and get Alpha 5 on the go! Lots of changes to B coming in the future; it’s holding on to too much of the alpha 2 past and must be stripped away for fresh new and more interesting ideas! Nautilus is moving in the right direction, but there’s still a huge amount of work to do!

Dev Blog : cp_nautilus_a3

Posted on December 7, 2017 by g.hill - cp_nautilus, Dev Blog

A note regarding version numbers

cp_nautilus_a1 and a2 were almost entirely identical with a2 being released a day later fixing a bunch of simple gameplay issues in a1 that should have been there on release; lack of clipping brushes on stairs, lack of nobuild brushes in grated off areas and actually adding health/ammo pickups etc – hey we all make mistakes on our first upload.

Introduction

Around April 2015 I started work on my first actual Source map. I’d always wanted to create TF2 maps; Having sunk a good 1000 hours of my childhood into the game, I figured i had the game knowledge down and as someone who wanted to move into level design it seemed only fitting that I started mapping. But prior to that, I had neither the time, knowledge nor motivation to learn how to create a map in Hammer (great for an aspiring level designer, I know).

Redundancy from my first job then hit and I suddenly had an abundance of time and inspiration on my hands (it’s surprising how the desire to not starve motivates a person). And so, out of the dust that was my first job in the industry came cp_nautilus_a2! And well… it was a hot mess. A valiant effort (so I’ve been told) for a first attempt at a map, but still a mess of brushes, meshes and level logic that sort of fuse into something resembling a TF2 map.

cp_nautilus_a2 was a 3 point Attack/Defend CP map. For those who don’t play TF2, Attack/Defend maps revolve around BLU team needing to push and capture one point after the other (usually in an linear sequence), whilst RED team set up defences and hold off at each point for as long as they can. BLU team wins if all points are captured and RED wins if they hold out until the round timer reaches 0.

I really like attack/defend style maps; they offer a certain “narrative” to a multiplayer map that’s missing from regular 5 point symmetrical CP maps. There’s a definitive start, middle and end which allows room for a designer to outline a story within the flow of the level;

“Players start on a train, they push into the station and then onto the streets, through alleys and the city square, reaching the climax and a final showdown infront of city hall”.

All you then need is the players to fill in the pieces. Anyone who’s played a multiplayer shooter has had that one game where the round timer is almost up and your team makes the Hail Mary push that wins you the game. Attack/Defence maps accommodate this narrative really well and is why, in my opinion, they are so highly rated in the TF2 community (Dustbowl despite it’s flaws is the second most played map after 2Fort and even the most hardened of TF2 players can’t tell you exactly why 2Fort is so popular as it’s a pretty terrible map all things considered).

Alpha 2

“Birth” – cp_nautilus_a2

Why Nautilus? The original theme was to be an underwater facility of some sort. As such it was dark, dank, grimy and generally an unappealing place – this would subsequently be a regular complaint the map received as TF2 is traditionally a bright colourful experience, and many didn’t think the “grittier” feel suited the style of the game. But on top of that, the map just wasn’t that great. So what made the map such a mess?

From a design perspective it was a navigational nightmare

BLU team exit the spawn from one of two exits; the left path leads BLU into either this side building or up a ramp to the upper level, whilst the right path offers 4 routes (one to the left path, one to the upper level, one to point A and one to point B). Despite the navigational signs, the flow of the right path naturally leads players to Point B which was a common issue in the first play through and the left path took the players through the building down a random side passage. Neither path’s natural flow took the player to Point A which led to many players getting lost in the belly of the map before even capturing the first point.

The lack of a forward spawn for RED meant that all defenders were also spawning at the very back of the map and needing to trek past Point C and B just to reach the initial point of combat. The layout was just too confusing for many new players and no amount of arrows was likely to help.

Straight out of the BLU spawn there were 4 possible routes for the player to take. The natural flow always took them to 4 which was the one i didn’t want them to initially take.

It was a technical mess

I’ll cut myself some slack on this one as it was my first map, but there were a bunch technical blunders that made iterating on the map somewhat awkward. The entire map was built on a grid size of 1; this is not only evidence of sloppy brushwork, but also meant even the most minor of changes risked creating a leak. Clipping brushes on the spawn doors didn’t block projectiles meaning players could kill each other before the round started. The displacements used around Point A and C were laughable (and still are in a3). Stair height and width weren’t in keeping with official TF2 standards, it all just screamed amateur, which is totally understandable (i had only been mapping for a month at that point); But fixing these problems would be a mammoth task and one i wasn’t too eager to engage upon at the time.

It was detailed too early

I made the excuse back in a2 that the reason I was detailing early was to give myself a feel for the theme and setting, as well as refine some of the layout design. In hindsight this was a terrible excuse and it subsequently hurt the map. Small detailing is fine, it makes an alpha map look a little more than just a bunch of brushes thrown around. But too much and iteration becomes difficult. I remember opening this map and being faced with an mess of brushes and meshes. It was exhausting to even look at, let alone start to make changes to.

This is way too detailed for an A1 version of a map (to be honest it’s too detailed for even a B1).

It was half finished

On the complete opposite end of the spectrum, Point C was sort of “half assed”. There were long empty rooms with nothing in them except boring geometry that served only as a way of connecting one point to another. The consistency was just jarring.

A few rooms were just boring and empty. You can definitely see the exact point of the map where i stopped caring.

Did anything go right?

Behind all this negativity however, there was actually a huge amount of positive gain from nautilus. It got me involved with the TF2 mapping community, it taught me the importance of testing early, testing frequently. I actually had a working map (which is more than can be said for future projects) and i learnt a lot about the Source engine in general. But for the most part I saw it as an unsalvageable project.

And so the map gathered dust. I found a new job shortly after the release of a2 so decided to shelve nautilus, reopening it a few times in some wild attempt to fix it, but nothing ever materialised. It served as a reminder to me as to “what not to do” when making a map and taught me a lot about the mapping development process. I would go on over the next 2 years to build a bunch new levels, only some of which getting close to a1, but nothing to the scale of nautilus.

Alpha 3

“The Rebirth” – cp_nautilus_a3

Until now baby! WOOOOOOO. cp_nautilus_a3 was uploaded to TF2Maps.com 4 days ago and we are good to spin it for another round! I can’t remember what gave me the idea to go back to this monstrosity, but i’m glad I’m did as the rework of nautilus has rekindled that drive to get a map out of the alpha stage and onto the workshop!

Oh boy where do i begin with this one;

Fixing those darn technical issues

Before any major work could begin on the layout, the entire thing needed to be moved onto a larger grid. So the previous map was moved onto a grid size of 4. I would have liked it on something larger like 16, but I went a little crazy with some of the angles so 4 will suffice for now. It is however, far more manageable than it was before which was ultimately the whole point of fixing it up. This took an uncomfortably large amount of time to change, so people take note; DON’T BUILD ON A GRID SIZE OF < 4.

The stairs and door frames were all rebuilt to the proper standardised scale, and the spawn doors were fixed to prevent those pesky bullets, pills and rockets entering the spawn rooms. The forward spawn for RED was also added and working (although for some reason it churns out a bunch of console errors that seem to have zero impact of the functionality of the spawn room… will look into that one later).

Rebuilding of Point A and C

Point A and C recieved large geometry overhauls. I tried to keep as much of the original layout as possible (building on top of trash is often better than building from scratch), so whatever geometry could be salvaged was.

Point A had the right path blocked up only offering BLU 2 choices (one to the upper level, the other to the Point) and the left path had the awkward side room stripped out now only offering the player one route to the point. It’s more linear and streamlined (some might say too linear) but will hopefully allow for an easier navigation route to point A. A RED forward spawn was added down the end of the tunnel (with a second door exiting onto the centre HUB room) that offered the defence a direct path to A. Fingers crossed players actually make it to the correct point this time!

Point A was completely rebuilt,opened up and rotated 45°

I added some giant windows and a skybox as people complained about the lack of natural lighting and replaced that horrid corridor connect A to B with a much nicer connecting room. The centre “HUB” connecting room was slightly adjusted to accommodate for the new layout changes and the whole point of A was placed at a 45° angle to offer a more visually appealing and interesting layout (I’ll touch on this later, but upon reflection I feel it was a mistake).

Point B mostly had it’s detail stripped out and the layout of the room simplified. Also added a giant ramp down to the lower level

Not much change to Point B. A an awkward ramp was ham-fisted in to connect it to the lower levels of C (this will most likely get remade in the next update) and the original connection to C on the east wall was blocked off.

Point C however, was the shining beacon that made this update for me. It’s a three tiered descent down to the control point that obvious favours attackers but from a narrative perspective It feels like a satisfying end to a 3 point attack/defend map (I’m going to make it work… somehow). The large open area and obvious height advantage to BLU offers demos, soldiers and Snipers crazy good sight lines so that’s definitely something I’m going to have to keep an eye on. More routes and cover are definitely needed to allow RED to reach some of the higher levels undamaged/detected, but its a huge step forward in the maps layout and now serves as the “money shot”.

[twentytwenty]

The final point is a 3 storey descent into the depths of the mountain

Stripped out the detail

a3 might actually look like a step backwards from a2 visually, but honestly I think it was for the best. The detail can be added back in when needed, but for now a quick pipeline that allows for fast iteration and compiling is crucial and that just wasn’t happening in a2. I’m still working on what i want to achieve with this visually, but I have some ideas that I think will work quite nicely.

Post Alpha 3

So going forward what needs doing:

Lots of play testing!

I have a plan to get at least 2 tests of cp_nautilus_a3 done before considering any changes. I know what I want to do with some parts of the map, would like some actually play time in it first before I go ahead.

More geometry changes

Point A is still a mess. I put this almost entirely down to the fact that I tried to maintain as much of the previous version as I could. I also blame the 45° angle change i made last minute. It was poorly thought through and as a result has some really weird geometry around A. Furthermore, it’s WAY too close to the first point. I’m surprised this was never brought up in the original play test of a2, but time from spawn to first contact at A is really short and needs to be extended. a4 will likely see another overhaul of this point.

Point B is going to get some more love as well. It’s a little cramped and honestly not that interesting of a combat area. I’ll likely make some small changes at first and if I’m not satisfied I might burn the whole centre section to the ground and build it from scratch… I’ll see how I feel on the day.

Conclusion

So there we have it. After 2 and a half years of sitting on my hard drive, cp_nautilus is back on the construction line and with all the ideas and experience I have accumulated from those years ready to be unleashed, I’m excited to see what the future brings.

Navigating your way around the editor

Controlling the Viewports

Moving

Selecting

Creating and manipulating Brushes

Brush Tool (B)

Brush Shapes

Clip Tool (C)

Vertex Tool (V)

Edge (E) and Face (F) Tools

Useful functions

Isolating and Hiding Brushes

Grouping Brushes

Centring The Camera

Hiding UI Elements

Conclusion

Preparation

Setting Up Trenchbroom

Downloading Compiling Tools

Downloading Quakespasm

Final Setup

Compiler Setup

Lets See It All Working

Intrduction

Alpha 2

Alpha 3

The rework of BLU spawn

Capture Point A

Capture Point B

Capture Point C

Capture Point D

Closing Thoughts

Introduction

CP_Nautilus

72 Hour Maps

cp_SaxtonsBooty

"Misc"

Introduction

Alpha 3

Alpha 4

Conclusion

A note regarding version numbers

Introduction

Alpha 2

“Birth” – cp_nautilus_a2

Alpha 3

“The Rebirth” – cp_nautilus_a3

Post Alpha 3

Conclusion

Recent Posts

Archives