There will be a point release of the SP Demo 2 fixing a lot of niggles soon.

A singleplayer demo #3 will be released in June, with at least three maps by ijed, rjthorne and gb, excellent QC and gameplay enhancements by Supa and Lardarse, and elegant engine coding by mh. It will be slick, scare your pants off, be Quake, and break the usual limits.

It will also shut up any crap about how Quake RMQ is. Most people got the picture by now anyway.

Other stuff is going on beneath the surface, and interesting things can be expected that will be good for everyone, not just us.

Greetz, gb

Beta brawl

Very early beta version of the SP Demo 2 map, e1m6rq. I showed this to a couple external testers during development to get feedback.

Notice the m0ar brutal crusher section (nail shooters), bad (and non-coloured) lighting, the completely different (and very sketchy) end (mini-thon!), the absence of the boiler room, the missing lavatrain area and the  still-original lower crusher (no power crystals yet).

The gold key section, the entire pipe stuff and the grapple points are completely missing. This version used a route that was more similar to the original e1m6. Different SK position as well. The new route (and the requirements that came with it) only existed in the TRAC and in the heads of the team.

It was recorded in March 2010, nine months before the extensively changed, polished and greatly expanded version was released in SP Demo 2. Used Darkplaces to record this, since we didn’t even have our own engine yet.

It’s quite funny to see it like that now.

Be sure to watch in 480p.

New engine release

Download the engine here and unzip the archive into your Quake directory.

Includes Linux and Windows builds. The SDL .dlls are included for Windows. Linux users please install libsdl and libsdl-net (crossplatform game dev library), every distro should have them.

This should fix the “white textures” problem.

In other news, ijed has been polishing netherworld tombs with demon saliva for the last few weeks – you can see him lying on his face before an altar of Baoht Z’uqqa-mogg in the above picture. gb could only catch a glimpse of the unspeakable horrors by invoking the fearsome power of Yadd-Tadhag, which has stained him for life.

It still gives me the creeps, dude.

SP Demo 2 has been awarded 18 of 20 points at (Review by Tronyn). We feel warm and fuzzy due to this.

How we do things

Far too many mappers and modders seem to end up with piles of unsorted stuff on their hard drives. Some can’t find certain files in a pinch, can’t easily give their mod to playtesters, forget what changes have been made where and why and at what time, don’t prepare for additional people joining the project, have maps on the brink of failing to compile or using obscure formats (Valve 220 needs to die), no .def or .fgd files for level designers, no ordered way of collecting feedback and ideas, and generally end up in an uncontrollable clusterfuck. On top of that, a lot of content is lost to disk or PC breakage – I have seen it several times in the last year alone and every time I wanted to scream “Nooooooooo!”

There are better ways to do things.

First off, it is better to work in a team than to work alone. Full stop. A team can do things that an individual can only dream about. And it can do it in a shorter time. Teamwork is key to actually getting an ambitious project released. In pro game design, a lot of people are part of making one level of a game. That’s beneficial – as long as someone has a plan and everybody is good at what they’re doing.

The most crucial things for teamwork are organisation and communication. There must be a way to distribute the content to content creators and playtesters, and relatively quickly create a release from it. There needs to be something where feedback and ideas are collected, sorted and made accessible. E-mail is not the best way to accomplish any of this. Chat is a good way to quickly and informally develop ideas, though.

RMQ uses two main tools to organize itself.

1. A central SVN repository. This keeps track of any change that is made, and archives each revision so it can be reverted to if needed. It acts as a rather safe backup mechanism – the importance of this can’t be underestimated. It allows all coders, level designers, modellers, artists, playtesters E.T.C. to access all of the mod at any time. Even if your harddisk breaks, it’s just a matter of checking out the entire thing onto your new system again.

It allows everybody to make changes without breaking stuff. It provides a directory structure for the mod from which a release can be relatively quickly packed together (a matter of one or two hours). It contains important resources like entity definition files which are continuously updated.

A new playtester simply needs to install TortoiseSVN and check out a local copy. He can then immediately play RMQ by using his local SVN copy as a gamedir.

A new level designer on the team does the same. His working copy will come with .def and .fgd files and everything needed to start mapping. Even texture wads. Documentation, even. On top of that, the SVN acts as a backup – no need to lose 2000 brushes because your PC broke. Maps are regularly checked in (uploaded). And then they’re safe.

The SVN also contains the engine. There is always a Windows and a Linux binary in the repo.

2. A TRAC system that’s used like a private forum and represents an organical, self organizing game design document. The TRAC contains close to 200 tickets. There are tickets for everything in the game, from “Ogres” to “E1M1RQ” to “Multiplayer” to “Episode meta ticket” and “Chat”. Tickets can be organized and searched. They can have images attached. They can contain bullet point lists (Wiki formatting). They can be crosslinked. They have properties like Priority, Owner, etc.

The TRAC is the heart of the project, its communication hub and its collective memory. All team members have TRAC access.

A new level designer would typically accept ownership of his map’s ticket, creating the ticket first if necessary. The episode directors have ownership of the meta tickets (Episode 1-4 and multiplayer) from which the individual maps etc. are linked.

Playtesters post feedback into the relevant tickets and pitch ideas in Chat tickets etc.

Coders have an eye on the QC Bugs ticket and the project related tickets (a demo would have its own ticket from which it is organized) as well as many individual tickets and chat.

Other communication channels are used besides the TRAC, such as an IRC channel and e-mail.

This is a print-out of the top of the ticket list; note the colors signify priority. A demo ticket will typically be top priority, next are the episode tickets and everything someone considers important (if only to remind himself, heh). This is only page 1 of 5! And many tickets have a lot of entries. The TRAC runs since the end of 2008; it was established along with the SVN when more people started to join the project. It has really paid off. And I dare say the RMQ TRAC is more active than any community forum.

The TRAC is kept private at the moment, to avoid too many people talking into our ears without really contributing anything. Imagine someone spamming our TRAC or posting insults. No thanks.

However, we have 3. A development blog for making assorted things public. You’re reading it. Via comments here, people can talk to us. Several members have blogs or websites. The IRC channel, #rmq on, is also open to everyone. And finally, most of us frequent the community boards and sometimes servers.

White textures when running RMQ?

Try running it in Fitzquake 0.85, Quakespasm, Darkplaces or FTE  then. You will miss a couple minor bits. The white texture problem seems to be connected to certain early DX9 graphics hardware – Geforce FX cards, some integrated Intels and also an ATI.

Geforce 6x and equivalent ATIs should not exhibit this problem. If your card gives you white textures when trying to run RMQ, I’d like to know about it. Simply post a comment with the card model you’re using.

EZ Installer and more

RMQ EZ Installer for Windows!

Baker created a Windows installer for the RMQ SP demo 2.

Download RMQ EZ Installer (Windows)

I don’t know how he keeps doing this kind of thing, but I hope he never stops.

More download mirrors!

There are additional download mirrors (original pack, not EZ Installer) provided by some helpful hands in the community:

Mirror 1 (

Mirror 2 (Filefront)

Mirror 3 (dfsp_spirit’s site)


A few people have made demos of their playthroughs!

Demo 1 (Monster on Hard skill)

Demo 2 (Bloodshot on Hard skill)

Awesome stuff! Videos to follow!


There is an RMQ thread at func_msgboard where things are dissected at a molecular level!

Another RMQ thread is going on at!

Most of has slept through the RMQ release so far!

Happy 2011 everybody!

Xmas presents, part 2

Now for the big, orange one.

Here is RMQ’s Singleplayer Demo 2. It contains the map e1m6rq, The Doors of Delusion. In the process of making it, we lost The Fight for Sanity but we wish you A Lot of Fun Playing It.

The demo comes with Linux and Windows versions of the RMQengine. It is the recommended engine to run this monster in, but Darkplaces and FTE might also work. Try our engine first though.

Consider using the Quake Retexturing Project textures with this map. There is an addon pack with the required custom textures, so the hi-res coverage is 99%.

The mod itself comes in the form of a PAK file as usual. I guess the long time Quake players know how to run such a thing. You should use -sndspeed 44100 on the command line, otherwise half of it will be lost on you.

Engine, QC and map source included. Updates to the Mapping Guide and .def/.fgd files soon.

“It’s gone. It’s done, Sam!”



Xmas presents, part 1

OK, the smaller one first…

RMQ Addon Texture pack for QRP

Contains a collection of high res textures meant to be used with the Quake Retexturing Project (QRP).

These are the new textures from RMQ; this version contains mostly the ones needed for the upcoming Singleplayer Demo 2. This will allow you to play RMQ with the QRP textures and not see too many “holes” where we used custom textures.

Should go well with the new QRP release. Double Xmas whammy! What a coincidence 😉

You might have noticed I use QRP textures in screenshots for a while now. Personally, I design my maps to make the best use of the QRP. I recommend you give it a try, even if you’re not otherwise a fan of replacement textures.

Usage: Pry the TGA files from the zip and put them in Quake/id1/textures (create the directory if it doesn’t exist). There are esoteric engines that expect replacement textures in different locations, but this will do for RMQengine and similar Netquake engines.


I, Mapping Robot

The map that’ll appear in the singleplayer demo is done, fully lit, and fullvised.

The engine is amazing, the gamecode is splendid. Playtesters love it. We’re practically there.

I, mapping robot, have worked several 14 hour days lately under the pressure of an imminent release deadline. I am groggy; I see brushwork when I close my eyes. My desk around my screen is covered with diverse papers that have notes scribbled on them, barely readable and striked through as I fixed each problem. I have no christmas presents for anyone. I faintly remember seeing it snow outside and even shovelling masses of snow. Yesterday I almost had to throw up after many hours of staring at the computer screen. But it is done.

I’m not the only one who is stressed out. RMQ is a clan, a hive. Some of the most talented people I ever met are writing code, making models, playtesting and recording demos, acting as mental sparring partners, inspirations and correctors via chat, mail and the outrageous TRAC system that serves as our collective memory, and a lot of other stuff, and putting in uncounted hours of their time without getting paid. I have to especially mention Supa, who created large parts of the gameplay and has to put up with an endless string of annoying QC bugs. Without her, there is no doubt that this coming demo wouldn’t be the crazy thing it is. I just put together the brushes, but she made the fat orange guy sing.

This is without a doubt the most craziest thing I have ever done and been a part of.

As for the map, it almost broke Lardarse’s quad core while trying to fullvis it. So in another few grueling sessions, practically every detail was turned into a func_wall to reduce the number of vis leafs. It went from over 12,000 to 3,800 of them. The final fullvis, which mh and Lardarse both attempted, ended up a surprise; the VIS time turned out to be a meager 4 minutes (!) after almost frying a quad core in an abusive 42 hour session before.

I think we do need detail brushes.

As if that wasn’t enough, the map compiler started segfaulting on me once I joined a 2,500 brush map snippet with the main level and thereafter started to create a lot of rather complex func_walls. After reversing some of those changes, the light program also broke down. So I had to switch first the qbsp compiler, and then the light program, and redo all of my func_walls. As a result, my lighting looks different, but OK for the demo, and my nerves are a caffeine-saturated shivering bundle of fear. Here’s a pic of the joining operation:

But we will make it.

Edit 1: mh also almost killed a computer trying to fullvis the map.

Edit 2: Due to the fact that almost half of the map has been turned into models, it brutally r*pes Quake’s model limit.

602 models exceeds standard limit of 256.



The monster section of the mapping guide is up. Like so often, we forgot to include some features, so there’ll be tweaking in the future. More stuff is going to be added to the Guide soon.