This year is the tenth anniversary of Quake Matrix. Quake Matrix was a mod for the original Quake, based on the film The Matrix, in which I contributed to the level creation. Starting as a small project among school friends, we went on to have considerable success, featuring on the popular (at the time) PlanetQuake website, and receiving thousands of downloads.
Today I’m going to look back on Quake Matrix, and what we learnt while developing the mod. You’ll have to excuse this post for not being particularly usability/UX focused, but it was the early 2000’s – games usability didn’t exist back then… (jokes!)
Quake Matrix
Quake Matrix was led by Flax, a friend from my secondary school. As a method to learn games coding, he created a small mod for Quake that slowed down time, and allowed wall running, inspired by the film The Matrix. Impressed, I wouldn’t leave him alone and practically forced him to let me create a website for the mod, and start creating themed maps.
The website, and an alpha version of the mod attracted more attention, both from real life friends and from internet acquaintances. The full mod team included Flax as the code, myself as Head Mapper, Random creating some amazing character models, and Lame, Predator, QMD and Doom providing additional levels (as well as a few other contributors).
The last version of the mod we put out included 21 Maps, 9 new weapons, custom power-ups, sounds, skins, enemies and models as well as a wide range of matrix inspired abilities such as wall running, backflips, slow motion, jumps and locational damage. And much, much more!
What went well
There are a number of aspects of the mod’s creation that went really well, and are important lessons for future game development.
The mod benefitted hugely by Flax’s strong design vision and his ability to implement the features he imagined. By having a working alpha to show people, there was little risk of project stagnation and we managed to attract some dedicated talent. Having something playable from the start overcame a common issue in mod development where a team is formed, create some sample skins of an AK47, and then never get anything playable created, causing the members to get bored and move on.
By acting as the lead coder, Flax was also able to accurately scope his ideas, and ensure that the things he wanted to see in the game were feasible. Because he wasn’t just an “ideas man”, the amount of unrealistic features were limited, and time wasn’t wasted!
A huge benefit to the success of the project was the range of strong talent attracted to the game. In particular, the models by Random were (and still are) very impressive:
Random's Quake Matrix Models
Also we were lucky to have QMD work with us, who created some fantastic maps. I guess that’s why they call him Quake Map Designer.
QMD's map of his apartment
What could be improved?
There are a few key findings from the development of Quake Matrix which can be applied to future games development.
Perhaps due to the game’s inception as a project among friends, there was little in the way of quality control on the maps and assets, leading to a wildly variable level of quality. In particular, the contrast between some of the maps made by QMD (above), and those made by me were completely different, not just aesthetically, but in the level of polish. Through the establishment of a more strict (and skill-based) hierarchy, it would be possible to avoid this in the production of a final product.
The second issue with Quake Matrix is the same as affects most mods out there. After 3-4 years of development and incremental releases, the majority of what could be done for the game had been completed, and the project ran out of steam. This was perhaps exacerbated by the age of the Quake engine (we started this project for Q1 around the time of Q3’s release), and the release of NeverWinter Nights, which killed any chance for productivity among the team! Perhaps the mod was finished? Or perhaps there is a lesson here about keeping up motivation through player feedback and setting milestones.
Conclusions
Some of the best moments during the development of Quake Matrix were when we heard about people playing it across the world, and getting in touch through the website or IRC. It also functions as a strong portfolio piece of the team members, having delivered a completed project (despite the old engine and relatively small scope!)
For internet historians, the original site has been rehosted here: http://www.quakewiki.net/archives/qmatrix/ . Also, some of the team still hang about on Quakenet’s IRC, #qmatrix. It’s quiet most days, but hang around and you’ll catch someone! And maybe get a launch date for version 0.6…
Well this brings back memories. I stumbled upon this for the first time today and it prompted some thoughts so I hope you don’t mind if I add them here.
Things that went well
It’s worth emphasising how incredibly simple it was for a beginner to get started with Q1 mod making at the time. The time between the initial whim of downloading the QuakeC source and running around the start map with a souped up machine gun or a 50ft jump was probably less than an hour. There were also a lot of beginner friendly tutorials around. The features implemented in the first few versions of Quake Matrix were largely decided by what Inside3d had tutorials for. If it had been harder to get into there is a good chance I would have given up in frustration long before the initial prototype was done.
Another factor that helped with getting the project off the ground was the community of friends you had who were interested in helping out (or possibly your proselytizing to said friends). I think that, besides you, Roachie and I, everyone who contributed prior to 0.5 was someone you already knew on IRC (Cortex, Lame, EvilAsmo).
Perhaps the most significant contribution towards anyone actually playing the mod was coverage by Planetquake. On the day we were made featured picture on the PQ homepage we were getting more page views every 2 minutes than we had received in the entire previous year.
Things that could have been done better
Direction and project management were weaknesses. It was great that everyone got to build whatever they felt like making but it also meant that nobody was ever sure what exactly we were going to end up with or how it was going to fit together. I remember writing the final feature and map list for 0.5 on the same day we pushed it out. I think with a better communicated vision of where we were going and what we wanted the end product to look like we could have continued to have people work on what they felt like doing, but also had it tie together more closely in the end.
Our recruitment and induction process could have been better (which is to say, we could have had one). We were keen to take on anyone who had an interest in joining us, but didn’t ever provide much in the way of direction or guidance. For people who already knew what they were doing this was good as there wasn’t anything we could have done besides get in the way. However I think we missed a few opportunities to bring people on who were less confident or self-motivated but would have improved the project (for example: we never had a musician but I remember talking to someone who was interested for a while, although nothing ever came of it).
Factors contributing towards a stalled project
Part of the reason that nothing much happened after 0.5 was the way we scheduled the release. As we didn’t have a well defined view of what 0.5 was going to look like we simply released when everyone had either run out of ideas or run out of motivation. Unsurprisingly these didn’t suddenly reappear the next week. Because the 0.5 release dragged on for so long there were people who had completed work a long time before but had yet to have anyone outside the team look at it. I think the immediate feedback of a shorter release cycle would have helped keep momentum up.
By going for so long without thinking about how things were going to fit together we managed to back ourselves into a corner. Version 0.5 felt like a showcase of cool ideas we could put into a game, but it didn’t feel like a completed game. I don’t think there was anyway we could have turned what we had into something that felt like a complete game without cutting and redoing things and wasting a lot of work.
From a technology point of view I think we had reached the limits of what we were able to do with me as sole programmer. The limitations of QuakeC were sometimes frustrating but they did force us to limit the scope of our ambition to things that were basically accomplish-able. When we started looking at engine modification for 0.6 a lot of the features we wanted to implement were quite obviously beyond my competency to complete at the time.