Sit back and watch two decades of video game graphics flash before your eyes. YouTube user drloser333 has uploaded a video from French site NoFrag that unfurls the graphics of more than a dozen first-person shooters, from 1992's Wolfenstein 3 to 2011's Battlefield 3.

Did the FPS get better-looking? They have at least become way more realistic, But maybe you're more of a fan of older, more abstract styles?

Graphic evolution of First Person Shooters: 1992-2012 [YouTube, uploaded by drloser333; more details (in French) at NoFrag.com]

Having been promised for an age, id Software finally made good last week on a pledge to release a modding tool kit for its ambitious, if slightly wonky 2011 shooter RAGE.

And what a set of tools it is.

If you were hoping for a friendly system full of handy tips and giant buttons, sorry. These are basically the same tools id used to build the game themselves, and carry warnings like the fact this stuff is "not be interpreted as consumer-ready", and that it's "only for the technically sophisticated and adventurous!"

Only serious modders need apply, but then, the payoffs might be worth the toil; RAGE had a ton of potential, especially in terms of its game world, that was capped only by some repetitive action and a pretty terrible ending.

In the hands of someone other than id, with the power of serious tools, who knows...we might get a game built using RAGE's bones, but better. Or not. But hey, it's a nice day outside, given the talents of modders I'm going to be optimistic!

The tools—which are 35GB in size—are available on Steam, with an intro guide below.

RAGE Tool Kit Available Today on Steam [Bethesda]

This is a story about Doom 3's source code and how beautiful it is. Yes, beautiful. Allow me to explain.

After releasing my video game Dyad I took a little break. I read some books and watched some movies I'd put off for too long. I was working on the European version of Dyad, but that time was mostly waiting for feedback from Sony quality assurance, so I had a lot of free time. After loafing around for a month or so I started to seriously consider what I was going to do next. I wanted to extract the reusable/engine-y parts of Dyad for a new project.

When I originally started working on Dyad there was a very clean, pretty functional game engine I created from an accumulation of years of working on other projects. By the end of Dyad I had a hideous mess.

In the final six weeks of Dyad development I added over 13k lines of code. MainMenu.cc ballooned to 24,501 lines. The once-beautiful source code was a mess riddled with #ifdefs, gratuitous function pointers, ugly inline SIMD and asm code—I learned a new term: "code entropy." I searched the internet for other projects that I could use to learn how to organize hundreds of thousands of lines of code. After looking through several large game engines I was pretty discouraged; the Dyad source code wasn't actually that bad compared to everything else out there!

Unsatisfied, I continued looking, and found a very nice analysis of id Software's Doom 3 source code by the computer expert Fabien Sanglard.

I spent a few days going through the Doom 3 source code and reading Fabien's excellent article when I tweeted:

It was the truth. I've never really cared about source code before. I don't really consider myself a "programmer." I'm good at it, but for me it's just a means to an end. Going through the Doom 3 source code made me really appreciate good programmers.

***

To put things into perspective: Dyad has 193k lines of code, all C++. Doom 3 has 601k, Quake III has 229k and Quake II has 136k. That puts Dyad somewhere in between Quake II and Quake III. These are large projects.

When I was asked to write this article, I used it as an excuse to read more source code from other games, and to read about programming standards. After days of research I was confused by my own tweet that started this whole thing: what would "nice looking"—or "beautiful", for that matter—actually mean when referring to source code? I asked some programmer friends what they thought that meant. Their answers were obvious, but still worth stating:

• Code should be locally coherent and single-functioned: One function should do exactly one thing. It should be clear about what it's doing.
• Local code should explain, or at least hint at the overall system design.
• Code should be self-documenting. Comments should be avoided whenever possible. Comments duplicate work when both writing and reading code. If you need to comment something to make it understandable it should probably be rewritten.

There's an idTech 4 coding standard (.doc) that I think is worth reading. I follow most of these standards and I'll try to explain why they're good and why specifically they make the Doom 3 code so beautiful.

Unified Parsing and Lexical Analysis

One of the smartest things I've seen from Doom is the generic use of their lexical analyzer^[1] and parser ^[2]. All resource files are ascii files with a unified syntax including: scripts, animation files, config files, etc; everything is the same. This allows all files to be read and processed by a single chunk of code. The parser is particularly robust, supporting a major subset of C++. By sticking to a unified parser and lexer all other components of the engine needn't worry about serializing data as there's already code for that. This makes all other aspect of the code cleaner.

Const and Rigid Parameters

Doom's code is fairly rigid, although not rigid enough in my opinion with respect to const^[3]. Const serves several purposes which I believe too many programmers ignore. My rule is "everything should always be const unless it can't be" I wish all variables in C++ were const by default. Doom almost always sticks to a "no in-out" parameter policy; meaning all parameters to a function are either input or output never both. This makes it much easier to understand what's happening with a variable when you pass it to a function. For example:

This function definition this makes me happy!

Just from a few consts I know many things:

• The idPlane that gets passed as an argument will not be modified by this function. I can safely use the plane after this function executes without checking for modifications of the idPlane.
• I know the epsilon won't be changed within the function, (although it could easily be copied to another value and scaled for instance, but that would be counter productive)
• front, back, frontOnPlaneEdges and backOnPlaceEdges are OUT variables. These will be written to.
• the final const after the parameter list is my favourite. It indicates idSurface::Split() won't modify the surface itself. This is one of my favourite C++ features missing from other languages. It allows me to do something like this:

  void f(const idSurface &s) {
  s.Split(....);
  }

  
  

  if Split wasn't defined as Split(...) const; this code would not compile. Now I know that whatever is called f() won't modify the surface, even if f() passes the surface to another function or calls some Surface::method(). Const tells me a lot about the function and also hints to a larger system design. Simply by reading this function declaration I know surfaces can be split by a plane dynamically. Instead of modifying the surface, it returns new surfaces, front and back, and optionally frontOnPlaneEdges and backOnPlaneEdges.

  
  

The const rule, and no input/output parameters is probably the single most important thing, in my eyes, that separate good code from beautiful code. It makes the whole system easier to understand and easier to edit or refactor .

Minimal Comments

This is a stylistic issue, but one beautiful thing that Doom usually does is not over-comment. I've seen way too much code that looks like:

I find this extremely irritating. I can tell what this method does by its name. If its function can't be inferred from its name, its name should be changed. If it does too much to describe it in its name, make it do less. If it really can't be refactored and renamed to describe its single purpose then it's okay to comment. I think programmers are taught in school that comments are good; they aren't. Comments are bad unless they're totally necessary and they're rarely necessary. Doom does a reasonable job at keeping comments to a minimum. Using the idSurface::Split() example, lets look at how it's commented:

// splits the surface into a front and back surface, the surface itself stays unchanged
// frontOnPlaneEdges and backOnPlaneEdges optionally store the indexes to the edges that lay on the split plane
// returns a SIDE_?

The first line is completely unnecessary. We learned all that information from the the function definition. The second and third lines are valuable. We could infer the second line's properties, but the comment removes potential ambiguity.

Doom's code is, for the most part, judicial with its comments, which it makes it much easier to read. I know this may be a style issue for some people, but I definitely think there is a clear "right" way to do it. For example, what would happen if someone changed the function and removed the const at the end? Then the surface *COULD* be changed from within the function and now the comment is out of sync with the code. Extraneous comments hurt the readability and accuracy of code thus making the code uglier.

Spacing

Doom does not waste vertical space:

Here's an example from t_stencilShadow::R_ChopWinding():

I can read that entire algorithm on 1/4 of my screen, leaving the other 3/4s to understand where that block of code fits relative to its surrounding code. I've seen too much code like this:

This is going to be another point that falls under "style." I programmed for more than 10 years with the latter style, forcing myself to convert to the tighter way while working on a project about six years ago. I'm glad I switched.

The latter takes 18 lines compared to 11 in the first. That's nearly double the number of lines of code for the *EXACT* same functionality. It means that the next chunk of code doesn't fit on the screen for me. What's the next chunk?

That code makes no sense without the previous for loop chunk. If id didn't respect vertical space, their code would be much harder to read, harder to write, harder to maintain and be less beautiful.

Another thing that id does that I believe is "right" and not a style issue is they *ALWAYS* use { } even when optional. I think it's a crime to skip the brace brackets. I've seen so much code like:

That is ugly code, it's worse than than putting { } on their own line. I couldn't find a single example in id's code where they skipped the { }. Omitting the optional { } makes parsing this while() block more time consuming than it needs to be. It also makes editing it a pain, what if I wanted to insert an if-statement branch within the else if (c > d) path?

Minimal Templates

Id did a huge no-no in the C++ world. They re-wrote all required STL^[4] functions. I personally have a love-hate relationship with the STL. In Dyad I used it in debug builds to manage dynamic resources. In release I baked all the resources so they could be loaded as quickly as possible and don't use any STL functionality. The STL is nice because it provides fast generic data structures; it's bad because using it can often be ugly and error prone. For example, let's look at the std::vector<T> class. Let's say I want to iterate over each element:

That does get simplified with C++11:

I personally don't like the use of auto, I think it makes the code easier to write but harder to read. I might come around to the usage of auto in the coming years, but for now I think it's bad. I'm not even going to mention the ridiculousness of some STL algorithms like std:for_each or std::remove_if.

Removing a value from an std::vector is dumb too:

Gee, that's going to be typed correctly by every programmer every time!

id removes all ambiguity: they rolled their own generic containers, string class, etc. They wrote them much less generic than the STL classes, presumably to make them easier to understand. They're minimally templated and use id-specific memory allocators. STL code is so littered with template nonsense that it's impossible to read.

C++ code can quickly get unruly and ugly without diligence on the part of the programmers. To see how bad things can get, check out the STL source code. Microsoft's and GCC's^[5] STL implementations are probably the ugliest source code I've ever seen. Even when programmers take extreme care to make their template code as readable as possible it's still a complete mess. Take a look at Andrei Alexandrescu's Loki library, or the boost libraries—these are written by some of the best C++ programmers in the world and great care was taken to make them as beautiful as possible, and they're still ugly and basically unreadable.

id solves this problem by simply not making things overly generic. They have a HashTable<V> and a HashIndex class. HashTable forces key type to be const char *, and HashIndex is an int->int pair. This is considered poor C++ practice. They "should" have had a single HashTable class, and written partial specialization for KeyType = const char *, and fully specialized <int, int>. What id does is completely correct and makes their code much more beautiful.

This can be further examined by contrasting 'good C++ practice' for Hash generation and how id does it.

It would be considered by many to be good practice to create a specific computation class as a parameter to the HashTable like so:

this could then be specialized for a particular type:

Then you could pass the ComputeHashForType as a HashComputer for the HashTable:

This is similar to how I did it. It seems smart, but boy is it ugly! What if there were more optional template parameters? Maybe a memory allocator? Maybe a debug tracer? You'd have a definition like:

Function definitions would be brutal!

What does that even mean? I can't even find the method name without some aggressive syntax highlighting. It's conceivable that there'd be more definition code than body code. This is clearly not easy to read and thus not beautiful.

I've seen other engines manage this mess by offloading the template argument specification to a myriad of typedefs. This is even worse! It might make local code easier to understand, but it creates another layer of disconnect between local code and the overarching system logic, making the local code not hint towards system design, which is not beautiful. For example, lets say there was code:

and

and you used both and did something like:

It's possible that the StringHashTable's memory allocator, StringAllocator, won't contribute to the global memory, which would cause you confusion. You'd have to backtrack through the code, find out that StringHashTable is actually a typedef of a mess of templates, parse through the template code, find out that it's using a different allocator, find that allocator... blah blah, ugly.

Doom does the complete "wrong" thing according to common C++ logic: it writes things as non-generic as possible, using generics only when it makes sense. What does Doom's HashTable do when it needs to generate a hash of something? It calls idStr::GetHash(), because the only type of key it accepts is a const char *. What would happen if it needs a different key? My guess is they'd template the key, and force just call key.getHash(), and have the compiler enforce that all key types have an int getHash() method.

Remnants of C

I don't know how much of id's original programming team is with the company anymore, but John Carmack at least comes from a C background. All id games before Quake III were written in C. I find many C++ programmers without a strong C background over-C++ize their code. The previous template example was just one case. Three other examples that I find often are:

• over-use set/get methods
• use stringstreams
• excessive operator overloading.

id is very judicial in all these cases.

Often one may create a class:

This is a waste of lines of code and reading time. It takes longer to write it, and read it compared to:

What if you're often increasing var by some number n?

vs

The first example is much easier to read and write.

id doesn't use stringstreams. A stringstream contains probably the most extreme bastardization of operator overloads I've ever seen: <<.

For example:

That's ugly. It does have strong advantages: you can define the equivalent of Java's toString() method per class w/o touching a class' vtables, but the syntax is offensive, and id chose to not use. Choosing to use printf() instead of stringstreams makes their code easier to read, and thus I think it's the correct decision.

Much nicer!

The syntax for SomeClass' operator << would be ridiculous too:

[Side note: John Carmack has stated that static analysis tools revealed that their common bug was incorrect parameter matching in printf(). I wonder if they've changed to stringstreams in Rage because of this. GCC and clang both find printf() parameter matching errors with -Wall, so you don't need expensive static analysis tools to find these errors.]

Another thing that makes the Doom code beautiful is the minimal use of operator overloads. Operator overloading is a very nice feature of C++. It allows you to do things like:

Without overloading these operations would be more time consuming to write and parse. Doom stops here. I've seen code that doesn't. I've seen code that will overload operator '%' to mean dot product or operator Vector * Vector to do piece-wise vector multiplication. It doesn't make sense to make the * operator for cross product because that only exists in 3D, what if you wanted to do:
some_2d_vec * some_2d_vec, what should it do? What about 4d or higher? id's minimal operator overloading leaves no ambiguity to the reader of the code.

Horizontal Spacing

One of the biggest things I learned from the Doom code was a simple style change. I used to have classes that looked like:

According to id's Doom 3 coding standard, they use real tabs that are 4 spaces. Having a consistent tab setting for all programmers allows them horizontally align their class definitions:

They rarely put the inline functions inside the class definition. The only time I've seen it is when the code is written on the same line as the function declaration. It seems this practice is not the norm and is probably frowned upon. This method of organizing class definitions makes it extremely easy to parse. It might take a little more time to write, since you'd have re-type a bunch of information when defining the methods:

I'm against all extra typing. I need to get stuff done as fast as possible, but this is one situation where I think a little extra typing when defining the class more than pays for itself each time the class definition needs to be parsed by a programmer. There are several other stylistic examples provided in the Doom 3 Coding Standards (.doc) that contribute to the beauty of Doom's source code.

Method Names

I think Doom's method naming rules are lacking. I personally enforce the rule that all method names should begin with a verb unless they can't.

For example:

is much better than:

Yes, it's Beautiful.

I was really excited to write this article, because it gave me an excuse to really think about what beautiful code is. I still don't think I know, and maybe it's entirely subjective. I do think the two biggest things, for me at least, are stylistic indenting and maximum const-ness.

A lot of the stylistic choices are definitely my personal preferences, and I'm sure other programmers will have different opinions. I think the choice of what style to use is up to whoever has to read and write the code, but I certainly think it's something worth thinking about.

I would suggest everyone look at the Doom 3 source code because I think it exemplifies beautiful code, as a complete package: from system design down to how to tab space the characters.

Shawn McGrath is a Toronto-based game developer and the creator of the acclaimed PlayStation 3 psychedelic puzzle-racing game Dyad. Find out more about his game. Follow him on Twitter.

---

Footnotes

id's RAGE may have its fans—and I'm one of them—but even they'd admit it never really hit the heights it could, or given the developer's pedigree perhaps should have hit.

Two two things I liked best about the game were its sky (seriously, it's one of the best in video game history) and its characters, which aside from a few ill-attired ladies, was a memorable cast of post-apocalyptic bandits, scientists and fat guys.

This gallery from Duncan "Dead End Thrills" Harris shines the spotlight on these inhabitants of the wasteland, giving them the chance for a little recognition the total package of RAGE's critical and popular reception may otherwise have not afforded them.

Rage: Isolated character examples [Dead End Thrills, via Super Punch]

---

The release of Doom 3: BFG saw the disappearance of the original Doom 3 from Steam, notable for two reasons: 1) the game was rather cheap and 2) there were a bunch of mods for it. People were rightly pissed, Bethesda Softworks offered a hurried non-answer, and the whole thing looked like a cynical sales-protection strategy.

Well, OK, fine, you win. Doom 3, the original, is back on Steam. For $10. Specifically, here's the pricing:

• Doom 3 Pack: Discounted at $12.99
• Doom 3: Discounted at $9.99
• Resurrection of Evil: Discounted at $4.99

Further, Bethesda says Doom 3: BFG Edition's GPL source will be released "in the near future."

Original DOOM 3 back on Steam [Bethesda Blog]

I've always felt strangely about Doom 3. On the one hand, it was a fairly revolutionary game, graphically. The lighting was striking. On the other hand, it looked kind of gross: humans in the game were starkly lit with strange, bump-mapped faces and odd, robotic movements.

But is that a bad thing or does it add to the ambiance? Does the game's look stand the test of time, or is it a strange artifact from a simpler time? Here are some animated GIFs from the recently-released Doom 3 BFG Edition running on an Xbox 360. We'll let you, the Kotaku readers, decide.

I didn't think that Matt Wagner played video games. The veteran creator best known for psychological power fantasy epic Grendel and the down-to-earth hero's-journey narrative of Mage never really mentioned games as a pastime in the interviews I read with him. But when I spoke to him last week, Wagner owned up to losing himself inside the worlds of Doom and Quake.

You can see a bit of the aggro machismo of those classic FPSes in his latest work, a series of graphic novels called The Tower Chronicles. Drawn by Simon Bisley and due out this month from Legendary Comics— the imprint from movie production firm Legendary Pictures—the stories focus on bounty hunter John Tower, who tracks down supernatural creatures. Bisley brings his usual jacked-up, shadow-laden hyperviolence to the proceedings and Wagner says he's having a great time crafting a story for an all-new character. I talked to Wagner about the beginnings of The Tower Chronicles, what's going on with volume III of Mage.

Kotaku: I read the preview of Tower Chronicles and it strikes me as very different from work you've done before. Maybe it's because Simon Bisley is doing the art , but it seems more violent, and a little bit more visceral.

Wagner: Well, I hate repeating myself. On one level, it certainly swims in the world that I like: fantasy mixed with horror. I always tell people I'm kind of a genre masher. This has got horror, fantasy and costumed adventuring, and I squish them those elements together into a cohesive whole. But yeah, it's very visceral. As we keep going, it gets more and more so, because I get better at writing for Simon and he gets better at translating my writing. This is, in the long run, a pretty epic story storyline. It will ultimately be three books, and each book is four 68-page editions.

Kotaku: So let's talk about the origins of the project. It's coming out from Legendary, who have been known mostly as financial backers of movies, right? They've helped produce the Christopher Nolan Dark Knight movies. I think they had involvement with Brian Singer Superman movie. Very closely tied to Warner. I know Bob Shreck [who did long tenures at Dark Horse and DC Comics] is editing over there. Is he the reason you're doing this project?

Wagner: Yes, absolutely. The project originated via Thomas Tull, the owner of Legendary Entertainment. The comic book division is trying to do really great comics and develop new properties that obviously they can do something with eventually. They realized from the get-go that if you don't have a great story to begin with, you're not going to go anywhere with it. None of us are looking at this as a movie or video game pitch. We're looking at it as a comic book.

But at the same time, Thomas had an idea for a character, and he said to Bob, Find me a writer who can handle this. And he specifically said, I want somebody that's not going to be a ‘yes man.' I want somebody that's going to come in and tell me when my ideas suck.

He threw some ideas on the table. I threw some ideas on the table. And as the ideas began to pile up...he originally wanted to do this as an original graphic novel, what in the biz we call OGN. And I said, Thom, this is too big. The story we have going on here, we could tell it short, but it wouldn't have the cool resonance. And this character has the potential for so many adventures, that I want to see more of his adventures. He's a supernatural bounty hunter. So let's see him confront a whole lot of monsters, not just a couple.

So that's when we decided to do it as a trilogy. And I will say the best part about the story is the face that all is not as it appears. The main character, John Tower, is a very mysterious character. In the first volume, specifically he's really aloof. He's generally aloof overall, but he's very aloof in the first volume. I would say you're not really sure you even like him that well. But as we continue to read, and as the adventures are exposed to us, more and more of the layers of his mystery peel back, and we get to see his actual humanity and what spurred him on.

Kotaku: You said Bob brought you in on the basis that you were going to be somebody that wasn't going to be a yes man, someone who was going to say which part of this sucked. So which part sucked?

Wagner: There wasn't too much stuff that sucked, but I did say, "Narratively that's not going to work." And there was another part where I said, "OK, well that's too close to elements of things that were in Garth Ennis's Preacher." Really, my big contribution was, "Well he has to have a reason for why he does all this stuff." The more we dug into it, the more we were able to come up with a very, very driving motivation.

Kotaku: Do you have the urge to be drawing this yourself? It seems like your writing output has far outstripped your artistic output lately.

Wagner: I will get back to drawing. Most likely the next thing I'll draw will be the third volume of Mage. You know it's funny, the last several years I've mainly been writing. That was not by design. But I've still been doing a lot of cover work. I did all the covers for 30 some-odd issues of Zorro and Green Hornet: Year One. So I'm still drawing, I'm just not drawing sequentially.

For Tower Chronicles, I can't imagine anybody but Simon drawing it. This will be the longest sustained narrative he has done in years. Maybe ever.

Kotaku: I want to touch on the idea of Legendary Comics as an entity. It's easy to be cynical about a movie production company all of a sudden deciding to make their own comics, for the sake of growing their own intellectual property. How would you answer some of this cynicism that swirls around an outfit like that?

Wagner: The only way we can answer that cynicism is by delivering really hot shit product. And I think we're doing that. I can't determine what the Internet buzz is going to be. Personally, I don't give a shit. My job is to deliver the best story I can. I know I'm delivering a good story when I'm having a great time doing it. And I'm having a great time doing this.

Kotaku: You mentioned the idea isn't necessarily that this is ultimately going to become a game or a movie. But are you interfacing much with video games nowadays? I generally think I can tell which comics creators are gamers or not, and I feel like you're in the not category.

Wagner: Well, not anymore. [Laughs] I have been a video game player and I find them perfectly engaging when I'm in that sort of mood. Generally, I just find these days I'm so busy telling my own narratives that I don't have much time to get involved in the narrative of a video game. It's certainly not like a novel or a movie. You get into a video game, it can take you weeks to get through the damn thing.

Kotaku: When you were at your heaviest consumption, what were you digging especially?

Wagner: I typically like the first person shooters like Doom and Quake. Those kinds of games are informing to some degree what I'm doing in Tower. Because he's confronting monsters. Certainly it's not the same sort of experience because the delivery system is different. Going from page to page is nowhere near progressing from level to level. But, still, I tend to like the first person shooters that have a point and a narrative. I think the last one I really liked was Doom 3.

Kotaku: Any other games that you remember fondly?

Wagner: A couple of the Star Wars Jedi games were pretty good in the narrative department as well. Yeah, the Jedi Knight games and Jedi Academy I thought were pretty good. They're a big adventure that come to a big final moment.

Kotaku: Would you ever want to see Grendel or Mage turned into a video game?

Wagner: I think Grendel lends itself more to a video game than Mage does. But unlike some of my contemporaries, I'm not really a purist. If somebody wants to adapt my stuff, I'm perfectly happy to see the pitch. If it intrigues me enough, I'm good to go

Kotaku: What would you say about John Tower in terms of comparing him to the other characters you've worked on? Because one thing I think people respond to in your work is that you manage to tackle this intersection of the personal and the iconic really, really well. In Grendel, it's this kind of demonic, psychological obsession that takes hold of people and, with Mage and lead character Kevin Matchstick, it's the idea of the reluctant hero and destiny kind of destroying all of his personal life.

Wagner: I'd say the same is true here. If you have the strength of mind, well I'm doing it again. It's what I said to Thomas in our first meeting, "We can have all this great shit, and Tower can confront all these great monsters, but we have to give a damn."

In every one of Clint Eastwood's movies there's always an element of humanity that runs through his aloof, tough-as-nails characters. In Tower, that gets exposed little by little as the story goes along. I'm a big one for not spilling your guts right away and there it is. I want to be teased all the way through a narrative until a really good payoff.

Kotaku: You mentioned the third volume of Mage. Dare I ask what's going on with that?

Wagner: Honestly, John Tower knocked it off schedule. I thought I would have been working on Mage at this point, and then Tower came up. I'm always looking for a challenge. I have never worked with somebody like I'm working with Thomas on this. It just seemed a good creative opportunity, a good professional opportunity. And Mage is always there for me.

Unlike anything else I ever worked on, I try not to think of that too much. I don't write anything down. I don't do any thumbnails. I don't do any script. I sit down with blank pages and I let the story take me where it's going to go. And that's not to say that I don't have notes and ideas about what I'd like to do. But it's very much kind of a Zen journey for me, unlike everything else I do where it's more premeditated, it's more structured. Mage is very much an experience of discovery. So I know when I get there it's gonna be just as fresh it's always been for me.

Kotaku: Do you feel like you've said everything you've had to say with Grendel as well?

Wagner: We'll get back to Grendel. Right now, what's happening with Grendel is we're publishing a collection at Dark Horse. They're big, fat omnibus editions. So, for the first time, the entire saga is collected in chronological order. Back in the ‘80s when I was first doing Grendel and recreating the character all the time, we were always changing the format a lot. That seemed like a strength at the time, but now that the market is so saturated, that's not a strength, it's a weakness.

People look at it and they figure, "Oh, this is too much shit scattered all over the place. I don't know where to start." So now we're offering it up in again, a chronological format that is very regularized. That's going to take two years of publication for all of that to come out.

Kotaku: In terms of digital stuff, are you going to be moving towards that format? What are your thoughts on digital comics and the way that's changed the landscape?

Wagner: It's just technology. It doesn't matter to me one way or the other. It's still just visual storytelling. I still draw in pens and inks. Whether it's published in an iPad or published in a book doesn't really matter to me at all.

Well, not just for you. Fans of Wasteland, RAGE, Borderlands or any other game set in a post-apocalyptic desert are more than catered for at Wasteland Weekend, which will be held in the Mojave Desert at the end of the month.

While originally conceived as a Mad Max-inspired event, it's since taken on wider influences, as you can see by the Fallout-esque trailer the organiser's have released.

Note that by themed party, I mean themed party: people dress, hang out and act as though we're already past the end of the world, with the weekend full of stuff like apocalypse-appropriate live music, modified cars and burlesque performances.

Wasteland Weekend [Official Site, via Laughing Squid]

Paul Steed, an artist whose video game career spanned design, publishing and even console development, died unexpectedly, according to The Jace Hall Show. Steed was perhaps best known for work on Wing Commander and Quake and also for controversies arising in his time ad id Software.

Steed was most recently the executive creative director of Exigent, a 3D art company he founded. Prior to that, he had worked for publishers such as Atari and Electronic Arts, with Microsoft on the Xbox 360, and at id. He got his start at Origin Systems as an illustrator for the Wing Commander series and had credits on other games such as Privateer and Strike Commander.

At id, he worked on Quake and Quake II. According to John Carmack, id's co-founder, in 2000 Steed was fired (over Carmack's objection) in retaliation for his insistence on working on what would become Doom 3, a project then opposed by two of the firm's co-owners. Steed also was notorious for releasing the "Crackwhore" player skin for Quake II, a model apparently intended as a tribute to a clan by that name but controversial for its name and appearance. Steed also was noteworthy for giving the keynote speech of Game Developers Conference 2008.

Jace Hall called Steed "a close friend" and "simply one of the first cutting edge low-poly 3D modelers to ever exist in the industry." The circumstances of Steed's passing are unknown. Steed is survived by his wife and children.

Goodbye Paul Steed [Wing Commander Combat Information Center]

Quake, Video Game Industry Legend Paul Steed has Passed Away [The Jace Hall Show]

Image via Wing Commander Combat Information Center

Here are some fresh QuakeCon screenshots from Doom 3 BFG Edition, a remastered version of Doom 3 that will be out in October for PC, PlayStation 3, and Xbox 360.

Although developer Id has promised that they're all working full-force on Doom 4, we might not see much of that for a while. So at least we'll get a little bit of Doom this year. A little bit of pretty-looking Doom.