This Book is a Dungeon (Nathan Meunier)

As indicated in this screenshot, This Book is a Dungeon is a) a Kindle book about game development with Twine and b) the Twine-based dungeon developed as described in the book. The word “Bookumentary” makes my teeth itch a little, so I will pretend I didn’t see that. And I can’t comment on the success of this piece as a self-publishing experiment, so I’ll just talk about the first two aspects.

The book is 81 pages long, which means that the book and game together are definitely far outside the usual “I will play this in 20 minutes in my lunch break” realm occupied by most Twine pieces — though it’s written in a breezy, confident, slightly repetitive style that makes it a pretty fast read:

It’s truly rare to find me doing only ONE thing at a time. Ever. I’ll admit that my rampant ADD is partly to blame. I try to work this incessant need for chaos and spinning plate juggling to my advantage, though it sometimes bites me in the ass. I can’t ignore this one, though. The drive is too great. Plus it’s new and shiny, so off we go!

A lot of what Meunier has to say is about his emotional landscape while writing his game, how he planned the press push for it, and a little about how his work fits into his day-to-day economic reality, a topic of some discussion around indie/IF blogs as well. He mentions some of his design motivations — wanting to produce something more visual than most IF, something that provided guidance rather than just a wall of text — but mostly he isn’t going into deep analysis of specific design decisions, nor is he explaining the technical details of amending Twine to support his added features.

I’m an avid reader of fairly technical making-of pieces, so I wouldn’t have minded more discussion of exactly when he needed to resort to javascript hackery or where he found specific macros. But part of Meunier’s avowed purpose here is to talk about Twine as an accessible route into game-making, and perhaps the book wouldn’t have made that point quite as strongly if he’d started with the tech nuances.

The portions that talk about self-publishing do go into a bit more detail, about things ranging from how to take pre-orders on Amazon to the advantages of putting a free demo up on itch.io to how to write a press release. The press release sample Meunier puts in his book is slightly on the cute side for my tastes, but the email he sent me offering me a review copy was really well targeted. (I actually thought at the time not only “I should check out this thing” but “this email could stand as an example to other people trying to get me to check out their work.”) There’s some solid advice on this topic.

The book suggests that you can take your choice about whether to play first or read first, but I actually approached it as an interleaved experience — read some of the book, then play some of the game, then back to the book — and this worked pretty well for me, because Meunier starts out talking about how he built the introduction and then moves further in, so you’re not getting spoilers from page one.

What about the game? It looks like this:

It’s a dungeon-crawl executed in Twine, just as the description might lead you to expect. There’s a fair amount of moving back and forth between rooms to get to where you’re going. There’s an inventory. There are combat sequences with randomized portions. There are fetch-quests for NPCs, traps and locked doors and lightweight puzzles. Death without warning is common, and when it happens you have to restart. It’s not a roguelike — the layout of the levels isn’t randomized — but the experience is otherwise a bit old-school even in parser IF terms.

I wanted to like this more than I did. I love seeing rich world models and things that might once have been parser games produced through a more accessible medium, and though I’m not always a huge fan of pixel art, I liked some of this specific pixel art and the level map. So I was well-disposed when I started.

However, two things put me off it a bit. One: the setting goes right for the disgust-horror without much preamble, so that you’re wading through body parts and sorting jars of embalmed, worm-infested monsters within a couple of rooms of the entrance. It’s more squicky than frightening, and as far as I can tell it’s essentially gross for grossness’ sake. Meunier describes this as the “WTF vibe” in his book. I know I review lots of works with body horror here. Porpentine’s work often captures something that is both beautiful and disgusting at the same time — sharpened curves of bone, affectionate slime creatures. Tom McHenry presents the physically distasteful as a test of the player’s will to become a Horse Master. Liz England and Michael Lutz use body horror and grotesque imagery to represent something horribly wrong with a relationship. This Book is a Dungeon skips the beautiful, touching, or emotionally grounded aspects. As a consequence, I was just repelled, rather than repelled and intrigued.

Reading Meunier’s bookumentary — sorry, I don’t want to let that word go — I felt bad about having this reaction to these scenes. He writes about how much effort he put into getting them disgusting enough, and the horror he felt at imagining these situations happening to himself. But the emotional connection wasn’t there for me.

The other issue, though, is the fairness of the game design. I got killed, killed, killed, and eventually gave up. There are no save-game options I could find. The splash screen does let you jump into one of two checkpoints in the game, but solving after death is still likely to involve a fair amount of repetition. People who are more into the game’s genre might have more inclination to push through that.

Meunier’s book several times mentions the idea that the deaths are shedding more light on the world in which you find yourself. In theory, I approve; if you’re killing the player frequently, it’s worthwhile making those deaths part of the storytelling. That is not the experience I had, though. What I learned from dying was “there are arbitrary traps and monsters in this dungeon!”

This is because I didn’t have much hypothetical framework to put new information into. The dungeon crawl starts with the player being drawn into a magical book from an unknown source. It’s a portal story, but doesn’t use the portal to establish the protagonist’s character, culture, or needs in the external world. Falling into the book means that the rules and stakes of the real world do not apply, but I need some new rules and stakes to care about.

Once in the dungeon, I don’t have a clearer question than “What is going on here?” — indeed, I don’t have strong reasons to think that anything is going on here, other than randomness. So, for instance, discovering a tentacled monster in a pool does not fill in gaps about the ecosystem of life in this dungeon. It just makes me think that maybe the author read the same Rose Estes CYOA with the water weird I read as a kid. The more coherent the opening and the more the player has well-formed questions, the more likely she is to plug new pieces of information into that understanding of the world.

It may be that had I played a bunch more times, I would have uncovered a thematic unity that made sense of all this. As far as I got, it felt like random encounters for the sake of it, except without the tactical combat challenge that makes e.g. Kerkerkruip interesting.

So after a few iterations I went back and finished the book without playing any more. That was fine. I didn’t need to have played the late game to make sense of the rest of the book, which sometimes slides into self-help-umentary:

If you get anything out of reading this, I hope it’s the idea that YOU can make things happen. You can do this, even if you don’t know how. You can create something awesome. You have the power to do that. You just need to DO IT. Take the first step. Dive in. Follow through. And make it happen. You’ll survive the process, hopefully, and learn a lot along the way.

…and Meunier then goes into how many people lead dull, mundane lives because they never push themselves to do something more interesting, such as, say, writing a game.

I totally agree with the advice to write a game sooner rather than later if game design is your ambition. Waiting to get hired postpones the day that you become a game designer, and makes it less likely you’ll be hired in the first place. It is possible you’ll find out that you don’t really like it and that your dream of writing games is based on a misapprehension, and that’s okay too — at least you’ll know that and have more discernment about what you’d like to do instead. (Tabletop RPGs? Computational creativity? Novels? Something totally unrelated?)

But Meunier’s formulation feels a bit facile to me, both as psychology and as a way of describing artistic process. “Just do it!” doesn’t always work on me; if I’m struggling with a task, sometimes I need to stop and figure out first why it is making me anxious. Also, people who do not write games are often fascinating people doing fascinating other things, and after time steeped in the game industry it can be a huge relief to spend time with them.

Meunier’s book and game touch on most of the aspects of game creation — why he decided to write, what his life was like while he did so, what tools he used, how the scheduling and scoping worked, how he publicized the results. Depending on what you need to learn, the results may be useful to you. It’s also always heartening to read about someone who felt freed by an IF tool to build what he wanted to build. But Meunier digs least deeply into the topics that I find most critical, questions about the meaning of what he is creating.

Disclosure: I received a free review copy of this work.