Dungeon H@cks Book Review

A few months ago I was contacted by one David L Craddock, who informed me that he had written a roguelike history called Dungeon H@cks, soon to be published, and asked if I’d be interested in reviewing it for the blog. I said yes (appropriate disclosure: no financial incentives or anything of the sort), and since it seem reasonable to assume that a lot of people reading this blog would find a book about roguelikes to be the kind of thing they’re interested in, it seemed sensible to say yes! So, without further ado:

DHacks_NoLogo

The book consists of three sections: firstly a number of chapters looking at the majority of major classic roguelikes – Rogue, Sword of Fargoal, Hack, NetHack, Moria, Angband and ADOM, and their progenitor Beneath Apple Manor. It also contains a number of “Side Quests”, akin to a “Notes” section at the end of an academic book chapter where one expands on points tangential to the main discussion, but nevertheless relevant or interesting; and interviews with John Harris (of the @Play column) and Brian Harvey (of Hack). Now, I don’t think I’ve written a book review in over four years, so this is mainly going to be a list of observations, some particular interesting quotes and similarities between the stories of development, and some reflections on this slice of roguelike history (and gaming history more generally) contrasted against my own experiences of working in the genre.

Firstly, two themes seem to run through-out the book: the importance and specificity of programming languages, computer models and distribution methods and operating systems, and secondly the inspirations of the different developers and the extent to which earlier games (quite naturally) inspired those who came later. For the former, I was struck by the similarity of University background for many of the developers, particularly in Computer Science, Engineering and Physics departments in very high-ranking universities: UC Berkeley, UC Santa Cruz, MIT, Stanford, etc. While a scholarly background certainly seems to demographically persist in contemporary roguelike developers – and it shouldn’t come as too much of a surprise to us when thinking about classic roguelikes which were created in an era where it was rare for any location other than a campus computer lab to actually have, y’know, computers – I thought it was striking the extent to which the classics of the genre emerged from this environment. Ideas repeated in many of the chapters – distributing a game on a single university network, or having a computer lab with a single computer, or having campus computers where an Angband borg plays as the screensaver, etc – seem completely alien today and speak to forms of game development, distribution, and user-base creation, which were deeply historically specific. The book also discussed the links between the pre-open-source movement and roguelikes…

Stephenson believes that NetHack played a part in the open-source movement. “We predated open-source [as a formalized movement], but I do think that the fact that we made a huge amount of source code available, without charge and under a public license—an early variant of the LGPL [Lesser General Public License]—helped to promote the idea of making software available for public use without cost.”

…noting in many of the chapters the importance of making the code (or parts of the code) open to the public in order to encourage engagement from the player-base, new people being added to the development team, etc. It was also interesting to note the odd attempt here and there to make these into commercial games, and the various reasons why these didn’t come together, situated within the broader discourse of creating free software for the enjoyment of development, and the enjoyment of seeing players attempt the games, and encouraging a collaborative development process which (in most cases) is obviously anathema to the model of a commercial game.

Equally, the book discusses the inspirations of the respective developers in a lot of depth, and as someone who has only become involved in Computer Science in the last four years, it was this which appealed to me a little more than discussion of operating systems and distribution methods (which tended to dominate the earlier chapters more than the later chapters, although maybe this is a reflection of stricter computing requirements (especially with Rogue) eventually giving way to (slightly) stronger computers?). Many developers spoke of their experiences with Dungeons & Dragons and in the cases of later developers, the earlier roguelike games obviously served as inspirations. One quote from Michael Toy of Rogue fame – that “Moria is probably the closest to what I wanted to do when I made Rogue” – seems particularly illustrative in this regard. Others, meanwhile, speak of the desire for particular player experience – exploration, a sense of danger, a sense of something at stake, etc (all things I’m sure we can recognize from the roguelikes we play these days). When the book discussed the reasons behind procedural generation for the earliest games, it of course noted the value of PCG for dealing with computational constraints where you can only store a certain amount of fixed data, but it was interesting to also note the reverse of this:

Unable to ascribe more interesting characteristics to the majority of monsters [due to technical constraints], Toy and Wichman simply gave more health and stronger attacks to monsters higher up on the food chain.

PCG has obviously often been used in the past to overcome memory constraints – Elite being a perfect example, whilst I assume that far more recently No Man’s Sky does something of the sort – but memory constraints nevertheless meant that monsters in some of the earlier games had to be simpler than the developers wanted due to these same technical constraints. Indeed, we can readily see this “just give them more health” logic in so many modern games where upping the difficult simply means your foes have more health and do more damage, and this made me wonder slightly if this was borne out of an era where adding to a health/damage number was trivial, but adding to something like AI intelligence was extremely challenging? (And, indeed – is this not still the case today?)

Moving on, the chapter on NetHack had this interesting comment to make both about the famous saying about the DevTeam, but more importantly, the subsequent comment about what we would now call “simulationism” in roguelike design:

The DevTeam’s seemingly telepathic ability to predict every possible action gave rise to the acronym TDTTOE, The DevTeam Thinks of Everything. “The more options you have to manipulate the game environment, the more immersive and interesting the game is,” asserted Raymond.

Simulationism is a common topic of discussion in roguelikes (as one can see from my recent entries about the crowd mechanics in URR, both here and on the various other sites I post URRpdates) and people are often split on this – some players enjoy the complexity that a simulationist game offers and the many ways (as the above quote suggests) one can manipulate the game environment, whilst others see simulationism as an undesirable move away from “tighter” game design and towards something less focused, more expansive, and in some cases perhaps more easily exploitable. The choices of the words “immersive” and “interesting” lead me back to my own reflections with NetHack – this was definitely how I felt when I played it as my first ever roguelike. The depth of systems like polymorphing, wishing, genociding, demon summoning, etc, made NetHack feel like this complex immersive world which wasn’t just a bunch of dungeon levels laid out for the player (Dark Souls does this amazingly well – and I can’t have a blog entry without praising Dark Souls!), and in turn, it made it into an interesting experience to learn these systems and figure out how to use them well. With that said, though, there’s always a fine line between simulationism and making optimal play require a lot of grinding or farming – I think NetHack does it well in this regard, but that’s the other side of that same coin. Similarly…

There was a natural tendency for the devs to see the game from the point of view of someone who played it constantly and obsessively; thus, over time, their notion of not making it ‘too easy’ gradually ratcheted up the difficulty level to the point where you couldn’t really enjoy it casually anymore

…is the other danger of simulationism: that the inexperienced player will have a far harder time making sense of the game when it has all these complex systems doing things under the hood (see, for example, my recent piece about the demon system in NetHack). I don’t want to draw any conclusions about it here, but the book explores some of the systems in roguelikes which aren’t connected to their core gameplay loop, and offers (as above) some interesting rationales as to the inclusion of these types of system.

Another comment which stuck with me given my own game design and academic research interests was this one, about Moria:

While browsing the computer’s directory of files late one night, he stumbled upon proof that his attempts to imbue denizens with personalities was working better than intended. Manuals had been written by students describing the vindictiveness of this or that monster, and how the monster seemed to remember that players had attacked it earlier. When he approached the authors of the manuals to explain that probabilities and random numbers were pulling the strings, the students politely but firmly silenced him, insisting that they knew the monsters were truly sentient.

This, to me, seems strongly reminiscent of both Tommy Thompson’s recent work into seeing whether players can identify procedural and hand-made levels, and my own experiences with comments here, by email, and elsewhere: that players of PCG games sometimes mistake complex PCG for simple, or PCG for hand-made, or vice versa. It’s very interesting to see an older but still comparable observation that player experience assigns meaning where there perhaps is none (and can also fail to assign meaning where there is some) and the human tendency towards apophenia.

Another comment I thought was interesting was this one in the discussion of Angband:

“We want [randomized experiences] within parameters. Either there should be no chance of an encounter with, say, a great wyrm [dragon] on level 1 at all, or [the odds] should be so low that they’re basically zero. Most players will never see it. And those [odds] basically end up being the same thing. If a person dies to a super-powerful enemy once, they might complain, but as long as it doesn’t happen a lot, it’s not really a big deal.”

This, again, seems to speak to a fundamental roguelike debate, and yet seems to stop short of saying what (I think) most developers would say is the obvious solution. Should we be able to have a goblin spawn with a wand of death on the first floor? The quote above obviously argues strongly in favour of the answer being yes, arguing that this yields interesting gameplay experience within set parameters and that “basically zero” is, in essence, akin to “zero”. Now, this is something I’ll be discussing more fully I hope in the future if the secret project I’ve hinted about once or twice here comes to fruition, but I have to take the other stance: if the two are truly indistinguishable, then why not prevent those early deadly goblins, as they surely only have a negative effect on gameplay experience, the possibility for even the most skilled players to have a high win-rate, etc? I personally think that is a surprisingly big deal, and something I hope to talk more about in the future, and the book does a good job of exploring some of the rationales behind different spawn systems, out of depth monsters, etc.

I was also struck by the number of stories which involved being taught by a relative – generally a parent or older sibling – the very basics of (often BASIC) programming. Although I also had an Electron, Spectrum ZX, C64 and Amiga as a child (I don’t recall the model, but possibly an Amiga 500?) and a family friend who knew his programming pretty well, this was an experience I never had. Both of my parents are university graduates, but neither in computer science nor natural science, and I don’t have any siblings. When I was around six I attempted to get this family friend to teach me programming, but after an afternoon where I attempted (without success) to clone the excellent Exolon, I quickly abandoned the thing and felt playing games was infinitely more rewarding than creating the damned things. In hindsight, I realize I had the mistaken assumption that Phil Fish mentions in Indie Game: The Movie: that when one is young, one thinks that a game is made by just sitting down and making the game, and it is hard to appreciate what that process actually entails in a technical sense until one has actually done it. Although some of these tales were very similar, it (like the ubiquity of the University computer labs described earlier) spoke strongly to a particular era and a particular background common to most of the earliest roguelike developers, making a set of useful and important historical observations about the particular circumstances which gave rise to the genre.

The later sections of the book move away from discussing specific games and speak instead on other topics: the 7DRL Challenge (edit: since moved into its own book) and a number of interviews. These read as quite distinct to the main historical narrative of the book, and although they make a useful addition for the dedicated reader, they felt very much like a highly extended set of appendices than a separate section of the book proper. The “side quests”, however – the parts which resemble a “notes” section and offer a little bit of additional/tangential/interesting information on some other topic in the book – are very interesting, and yield a lot of amusing anecdotes and useful details on the actual experience of developing these games, some of the problems and concerns and questions, the earlier media interest in roguelikes, personal experiences with fans, etc, which I highly recommend reading.

However, a few negative points must also be noted here. Firstly, in the version I had (eBook version, a month ago), there were a few typos here and there – no more than I normally produce in a lengthy piece of work, but quite a few had clearly been missed in the editing process. That didn’t bother me in the slightest (since I’m always more generous in this regard to books that don’t come from major presses, especially since – having worked with major presses – I’ve seen the level of assiduousness and care major press editors put into every piece of writing and how much time it must take up), but I think it should be mentioned, even though it didn’t detract from my interest in the slightest. Additionally, the interviews were worth reading, but felt a little bit apart from the rest of the book, and might perhaps have made a more interesting blog post or magazine piece, or something of the sort, than a book addendum? However, these are both small nitpicks (and I am told David has sent a newly typo-free version to all publications of the book, so I assume the first point is now dealt with) which did not reduce the quality of what the work had to say.

So, in summary: an interesting read which will appeal to use intrigued by the technical specifics of early roguelikes, the design rationales, the social context of their games, their legacies, the earliest development of what we would now call the “roguelike community”, the impact of roguelikes upon games and gaming more generally, and a lot of interesting and amusing observations and anecdotes throughout. The book also spoke to a lot of debates which take place on this blog and in the roguelike (and procedural generation) community about a range of topics (many of which I’ve mentioned above), and (speaking as a sociologist) it shed interesting light on the social and cultural conditions within which the earliest games in the genre arose, and the broad levels of comparability between the demographic situations of many of the developers of that era (and the playerbase which became interested in these same games). Since this is the first book review to date on this blog and I certainly haven’t implemented any kind of formal rating system (and nor do I intend to), let’s just say: if you’re a classic roguelike fan, I recommend it. Tells us a lot about where we came from, a lot about where we are, a little about where we’re going (that only gets a small chapter at the end!), and how and why roguelikes came to take the shapes we recognize today.

Be Sociable, Share!

11 thoughts on “Dungeon H@cks Book Review

  1. I’m similarly forgiving of typos for the most part, and they didn’t detract from my overall enjoyment of the book – except in the chapter on ADOM. I don’t know if you noticed this but the game world in ADOM is called Ancardia, while the book referred to it as Arcadia every single time. That really made that particular chapter feel shambolic and amateurish, which in turn tainted the whole book. It’s still worth reading but with much greater qualification than otherwise.

    I, too, was struck by the very computer science focused backgrounds of those involved in early roguelikes. Naturally only those with ready access to computers would makes games as a hobby but it does mean that they all came at the task from a very technical perspective, which probably had lasting impact on how the genre turned out.

    • Hi, Alan,

      Thanks for bringing up this (major) gaffe. This was MY fault, not that of my editor. Believe me, I did look closely at the true name of ADOM’s setting, yet I still managed to record the wrong name. While I won’t make excuses, I do have an explanation. Some years ago I wrote several articles on the game BioShock and its underwater setting of Rapture. One of the areas in Rapture is called Arcadia. While researching and writing about ADOM, I honestly believe my brain read “Ancardia” but my fingers’ muscle memory mistakenly inserted “Arcadia.” My brain apparently glossed over the mistake yet again during the final stages of locking down names, dates, and such for each chapter, quite used to reading “Arcadia” and seeing nothing out of place.

      So, again, certainly not an excuse–I feel quite foolish for making such a novice mistake, and have taken steps to correct it–but one I hope readers can forgive.

      • It’s one of those situations where, like someone in the vein of Jim Sterling, I focus on the consumer angle. As a writer I can understand how easy it is to make an error. As a consumer, I tried to set aside that bias and approach it as I would if I had no knowledge of the tribulations of writing – i.e. “he’s got this name wrong every time, that’s ridiculous”.

        My criticism isn’t personal – I know that everyone who creates a product is doing it to the best of their ability and wouldn’t knowingly make a sloppy mistake, so I don’t hold it against you or anything. I don’t doubt your intent or sincerity. The errors are just something which I, as a reviewer and critic by nature as well as by choice, have to point out.

        • Just my only thought on this thread – I actually didn’t notice that in the slightest when I read it (I’m fully aware it is Ancardia, though for some reason the typo just didn’t register), but I appreciate the three comments! I think it’s very positive and shows a lot of good will that David has sent out new versions to the printers etc, but I totally accept your point Alan re: the original version.

          • Testers and editors, all necessary. It’s incredibly hard to look at one’s own work and fix mistakes; our brains are so happy to substitute intention memory for sight!

            I recently figured out how to produce a kindle mobi from word (at a deeper level than export & convert! It needs lots of cleanup), and I realized I’m surprised there aren’t more proofing tools out there. I don’t mean Word’s grammar correction, but more like:
            1. List of words in order of frequency. A word that only occurs a few times may just be misspelled or run two words together.
            2. Common mistakes and homophones extractor: See sentences with words like they’re / their / there pulled out of context for review. Less context means less brain override of intention memory.

            I did have fun with the Hemingway Editor a while ago: http://www.hemingwayapp.com/
            It lost me my fancy stuff but made things much more readable. (Not related to the above kindle stuff, just planned blog stuff.)

            Anyway, editing is something a computer should be able to do better than it does, and our brains are very bad at editing our own stuff! My sympathies for those who have actually gone through the process.

          • Hmm, that’s neat! I normally use friends/family for proof reading my stuff, though my personal trick is to print it off and force myself to read it through physically. It makes it feel much “fresher” and I don’t generally skim over things then.

Leave a Reply

Your email address will not be published. Required fields are marked *