UnBrogue Correspondence

"I just want to offer my thanks for making the variant of Brogue, UnBrogue.
Brogue itself pales in comparison to UnBrogue. Brogue, to me, has become no longer enjoyable.

The addition of the items with their new powers makes for a variety of new situations, the sacrificial altars make for a good tradeoff, and the shields, even when cursed, make for an entertaining run with deflections and defense.

I've also made it further in UnBrogue than I have in any other roguelike, to floor 22 (jumping through to floor 23 made it crash, for some reason), but even that run alone made for an interesting set of stories - After a particularly grueling fight against a Lich, having lost levels in my leather armour (-6 due to acids) I turned down a corridor to see a Dragon. Each of its blasts of fire were deflected by my tower shield, and I slew it with a +8 Cleaver.

All to the tune of Elegia by New Order, it made for a fairly intense few moments.

Or that time I was held by a Bog Monster and beaten and thrown darts at by Centaurs until I died, while China Girl by David Bowie played made for an entertaining end to a character.

Long story short, it's a game that has rekindled my interest in games.

Also, I used to follow your blog, ASCII Dreams for quite a bit, but due to other circumstances haven't been keeping up with it too much.

Thanks again for the game."

-- An UnBrogue player

"Firstly: thanks for the great email.

Secondly: apologies for any or all crashes and bugs.

Thirdly: I hope I really haven't broken Brogue for you. UnBrogue was designed in part as a crazy palate cleanser for people playing Brogue. But I don't have the time to maintain it at the quality level Brogue is at, so I'd hate to take you away from a high quality game for a largely experimental mod.

I'm glad you're enjoying yourself so much though."

-- An UnBrogue developer

Unangband 0.6.4c released

It looks like I'm just going to have to bite the bullet and acknowledge I'm unable to compile Unangband for OS/X. If anyone is running an old enough version of OS/X to include the Quickdraw library headers, I'd love to host a compiled version of this release.

### Bug Fixes ###

- Allow monsters to use their ranged attacks (Fix thanks to Alexis Scheuer).

- Fix monster toughness descriptions (Fix thanks to Alexis Scheuer).

- Prevent Witchblooms spell description crashing the game.

- Allow Saruman to appear in ruined Hobbiton (Fix thanks to gold dragon).

- Prevent friendly uniques from being invulnerable to enemy attacks (Reported by Ashkir).

 You can download the release over at the Unangband home page.

Review: Dungeon Hacks and One Week Dungeons

There’s a subgenre of science writing – books like the Hacker Crackdown and the Newtonian Casino – which I dove into during my early twenties, which told the human stories of the development of the Internet and the communities that grew in and around it. In print form, there would usually be an insert of coloured photos of white, bearded, earnest, awkward looking men – because tragically by the mid 80s computer scientists are almost always white and male - in brown corduroy flairs and tucked in yellow buttoned breast pocket shirts standing around a computer or in a computer lab, alongside the computer hardware itself; reading the same stories on the World Wide Web you’d navigate through man pages, and pre-Geocities website designs to marvel at the crazy lengths early programmers would go to to exploit the hardware and operating systems of the time.

Dungeon Hacks falls into this same subgenre, and while it is a capital-I Important writing about the history of the development of roguelikes, it is never vital. David Craddock tells the stories of the creation of many foundational works of the genre, but he fails to bridge the gap between games over twenty years old - for which he has sourced a broad range of developer interviews and pieced together a highly readable story - and how these weird infinities coax their players to dedicate years, even decades to mastering them.

Mr. Craddock’s research is impressive, and he has taken full advantage of the willingness of roguelike developers to talk about their games to record numerous anecdotes as well as documenting the important relationship between Rogue and the Unix curses terminal. Unfortunately Dungeon Hacks doesn't make the case for why someone outside the roguelike community should care about this history, simply pointing to procedural generation and permadeath as if these explain all the elements which elevated this ghetto genre to indie darlings.

By placing the developers on a pedestal, Dungeon Hacks understates the contributions of the wider community of players and fans who freely give their time and energy towards the games – the communities formed around Hack and the Angband development team being two notable exceptions. To take one example, John Harris, whose words the book concludes with, is labelled as a historian. This misstates John’s importance to the genre: he is a historian insofar as any enthusiastic amateur who spends years writing about a topic as a labour of love is a historian, but he is not a historian in the sense that he has not received any academic recognition or financial compensation for the work he does.

If you are at all interested in the roguelike genre you need to buy Dungeon Hacks for insight into the early days of roguelike development. But sadly, that's the limit of my recommendation: it is not a cross-over work that will explain the genre's deep appeal to the outsider, and I am perhaps unfairly judging it on this criteria.

Where Dungeon Hacks is scholarly and historically focused, its companion volume One Week Dungeons is journalistic (in the literal sense that it forms a week’s diary of eight would be developers) and dramatic. Originally written as a coda to Dungeon Hacks, it has the vitality and relevance that Dungeon Hacks lacks, as it documents the frustrations and successes of these idealistic attempts to write a complete roguelike from scratch in 168 hours. Each developer’s tale is deeply personal, satisfying and thrilling, and the story of Joseph Bradshaw forms its unexpected human heart.

Dungeon Hacks and One Week Dungeon are both available from Press Start Press. I was provided early drafts of both books and complementary copies as a part of this review.

http://www.press-start-press.com/dungeon-hacks.html

http://www.press-start-press.com/one-week-dungeons.html

High Frontier Kickstarter complete

The High Frontier 3rd edition kickstarter has finished, with a final tally of 2,244 backers pledging USD $180,942 to get a copy of the game.

This means I'm going to be published with a board game developer credit for the 3rd edition of High Frontier Interstellar, a solitaire game which re-uses most of the High Frontier components, which funded as a $36,000 stretch goal.

It is fair to say the Kickstarter campaign funding exceeded anyone's expectations. It is also generated a lot of only over a beer stories, as I was heavily involved both in front of and behind the scenes as self-elected community manager. If you're in Sydney, feel free to buy me a beer some time :)

I'll continue blogging just as soon as I get some time to do so. There's some follow up work to the campaign that I'm busy on.

High Frontier Interstellar design notes - part 3 (Inspiration)

(Start with parts one and two).

I don't consider myself a game designer because there are two things I haven't done which are central to game design: a) come up with an original game concept, and b) iterated on a design based on feedback from play testers. Game developer feels like a better fit, because I've taken an existing design and tweaked it, and I'm happy with being able to do this for High Frontier Interstellar because as a solitaire game I can be the sole play tester and be confident the game works.

Recruiting other play testers, especially for board games is a complex exercise and at the moment my 3rd edition Interstellar play testing components are a Frankenstein mess of the base game, 2nd edition expansion, a poster map ordered through Zazzle, a spreadsheet allowing substitution of unused 2nd edition cards for new 3rd edition cards, a hand drawn fuel strip, and a memorised list of changes to the poster map. Then I have to get other people to somehow play the game this way...

So instead of play tester feedback, I'm relying on intuition. And this leads me to a complex idea I want to explore here: that there are ideas that are somehow inherently better than others - in fact, it is possible to find the best possible solution to solve a design problem.

To be clear:- I'm not saying that the new edition of High Frontier Interstellar is the best possible game about crossing the unimaginably huge gulf between the stars. Instead, given the numerous small design problems I identified while playing, I attempted to find the 'local maxima' - the rule change that solved the problem with the minimum complexity and maximum thematic value. And it feels to me like I've been able to find these maxima - which makes me wonder why these exist at all.

To take a concrete example: in the 2nd edition, Biotechs could only perform two operations - and each operation was exclusive to one of the two possible starship configurations in the game (Beehive and non-Beehive). Biotechs ended up feeling not very 'Biotech'-like - they lacked thematic punch and flexibility.

I experimented with modifying the Biotech promote ability to allow them to (only) promote cards in the vats:- which ended up both too powerful and less interesting (it trivialized avoiding Alzheimer's). But this solution remained in my variant because it was the best I could up with, but ultimately unsatisfactory.

I needed a better answer - something that fitted the idea of a powerful ability but with a significant drawback. And it's the process of finding that answer that intrigues me.

During the hectic 'week of development' that resulted in 90% of the changes to the game (between the 2nd edition & variant rules to 3rd edition that emerged), I typically would confront each problem in sequence - either to develop a temporary patch (like the Biotech vat promotion idea) or to return to the problem plus temporary patch and find an ultimate solution. This would take roughly 20-30 minutes of examining the problem in my head, trying several other 'obvious' fixes and looking at why these wouldn't necessarily work. I'd end up focusing on one fix that I'd repeatedly try even as I'd forgot, then remembered why this fix wouldn't work. This would sometimes be followed by a sudden flash of insight which would reveal the 'local maxima' fix which would be somehow related to the solution I had fixated on, but addressed all the issues I'd thought about - if it was the first time I'd approached the problem, I would end up trailing off with the 'good enough for the moment' patch instead, and move onto another problem - perhaps documenting (via email or Google docs) why this solution was acceptable but didn't quite address the whole problem.

The next time I develop a project like this, I'm going to keep a developer diary to track this sequence more closely - because often the interval between the temporary fix and the ultimate solution would involve a period of sleep or exercise, where my unconscious mind would have the opportunity to chew the problem over before regurgitating the need to look at the problem again. I say that because the second time examining possible solutions would still need a period of reflection before finding the answer and it is not clear to me in retrospect whether this unconscious process was delivering the answer to me in a hidden form or simply giving me more ways of approaching the problem.

Not all problems took this form:- there is also a design process more akin to traditional brainstorming which feels like the unstopping of a dam to let the reservoir fill up the contours of an empty valley downstream. This occurs when I'm working on more of a blue sky or blank slate design space: such as the Extended Operations expansion to Interstellar I may release at some point where I came up 3 new professions and new operations for each existing profession in a relatively short space of time. There's also what feels like a line by line editing process, which usually correlates to a literal line by line editing of the rules, where a rule is expanded on, clarified and tuned to handle all the cases that could eventuate while playing.

It's this 'line by line' edit process that is more likely to reveal problematic rules:- but also the most likely to create problematic rules in the first place. This is because this editing is local rather than holistic, so that errors can creep into the game where 1 section of the rules says one thing where another part of the rules is operating on a different set of assumptions.

As for the inspired rules that just feel right, I'm not even able to always completely articulate why they are the correct rule. Take the final solution to the Biotech issue:- I ended up leaving them unchanged from the 2nd edition except to give them a new operation Wet Nano Lab with the text ‘Discard a Graveyard card from the game to perform a Science or Engineer Op’.

I can't explain definitely why this is the best solution. It meets the criteria of powerful ability with a drawback, and the thematic crunchiness I was looking for. It has the great side effect of allowing a get out of jail operation from either of the two most powerful careers in the game, and the drawback is significant enough that it is going to be used sparingly except in desperation (the Graveyard is used as a resource counter to limit the number of children your starship may have). But why of all of the possible design space in the game, is this ability the right one? I can't answer that on any level other than instinct.

(And my all time favourite game design technique worked perfectly again: if you ever have an equation that sort of does what you want, but isn't working, reverse the equality e.g < becomes >; or vice versa. Here it made fighting Hostile Goo a far more interesting proposition. I love it because it is so completely nonsensical but surprisingly effective).

In the next part, I want to talk about the multiplayer Interstellar game.

High Frontier Interstellar design notes - part 2 (Motivation)

(Start with part one).

There are several reasons for developing a 3rd edition of High Frontier Interstellar. The first one is simply mechanical - a number of additional cards need to be incorporated into the game from the core 3rd edition High Frontier. The impact of these additional cards is mostly positive, in that they make existing cards more useful, but there are some 3rd edition cards which are extremely useful in the base game which are terrible for Interstellar (Project Valkyrie being the most notable example), and several robonauts are added which are lightweight and do not need supports, which makes 3rd edition Interstellar easier in many ways.

The second reason is much more out of this world. Huge advances have been made in the field of exo-planet research since the 2nd edition was released. We know now that it is extremely unlikely that a gas giant orbits Alpha Centauri, whereas this was incredibly likely in the 2nd edition. There's also some nearby systems of interest which appear to have planets around them which were not included in the 2nd edition map and Pawel Garycki provided a number of suggestions which Phil adopted. And finally, Ruslan Belikov, an exo-planet astrophysicist specializing in nearby star systems was able to assist with creating a more realistic model of exo-planet searches which unfortunately had to remain an optional rule due to the record keeping required - a 1d6 roll for each exoplanet search needs to be retained until the system is explored. Ruslan would also have liked the planetary types terminology used to be updated to match what researchers in the field use, however Phil Eklund decided against this.

The third reason is the 2nd edition of Interstellar is a game with a number of quirks and flaws which I don't believe were identified during the original play testing. I ran into one fairly early on when I began playing the game: it is possible to have passengers that are effectively immortal because they cannot be killed by ship event rolls. These are not the only hazard which you can encounter during your journey, but they are the hardest to manage, and having immortal passengers is a significant advantage. While I decided to keep immortals (with Phil's blessing), the rules as a whole needed significant work to clarify exceptions and unusual cases. One example was how to handle robots which accumulated stress from mutinies, which previously had no consequence. In the 3rd edition, you want to avoid stressed robots where ever possible because of the extremely dangerous 'Pod Bay Doors' event roll.

Having an immortal crew highlighted another problem: there are a large number of patent decks which are almost never used in the game. High Frontier has various patent types such as generators, reactors, robonauts and so on, most of which are included in Interstellar. However the only circumstances in which you're forced to draw from these decks is if you lose a radiator to a ship event roll. If your starship engine doesn't require a radiator (and a number of designs do not), you'll never need to research anything except robots and robonauts, which can be consumed to produce factory cubes, which can then be used to improve the configuration of your starship (using a Nano-reconfigure Hull operation). My variant rules added a complex set of risk rolls which would only occur if the starship had no alert engineer: it wasn't until I came to revise this for the 3rd edition that I realized I could replace them with a much simpler and elegant single risk roll that acted almost exactly like a glitch from the High Frontier game.

Another issue I ran into was handling what I termed 'conservation of mass'. I've written more about this in the final rules, but essentially the issue was the rules as written meant that any time a card was decommissioned, the starship lost irreplaceable mass, except that the mass could be replaced by patching your radiators. And because the written rule wasn't replicated onto the poster map, the way it tended to be played was the reverse - you could freely 3D print cards from your hand, and so every time you completed a research operation you added mass to the starship for free. To address this, I ended up deciding that cards in your hand count include the mass stock needed to 3D print the cards and using a graveyard to track mass needed to support colonists produced by parenthood or bioengineering (except on beehive star ships). Factory cubes then become an input needed for research, effectively acting as a fungible mass commodity on the star ship which I could use in several circumstances.

But the key motivation I had in designing my variant, which has survived albeit with numerous changes in the 3rd edition High Frontier rules, was a redesign of the process of acquiring breakthroughs - game changing technologies unique to Interstellar. The best approach to acquiring breakthroughs in the 2nd edition of High Frontier is to make your crew scientists and hope they survive their old starting age of 5 turns (60 years) to research what you need. This is extremely dependent on luck, with little choice on your part, but is pretty mandatory, because the breakthrough roll needed 2d6 < Age, where most of your passengers never survive past age 4-5.

Paradoxically, the second best approach to acquiring breakthroughs was to make all your other science capable colonists Domestics instead of scientists. Domestics are good at having children while they're young and surviving Alzheimer's using their self-promote ability. Since they are unaffected by cancer, the other age based killer, and can remove their own stress, the domestic career is arguably the best way to preserve a passenger to an age old enough to make it worth switching to scientist. And if you do have an old enough a scientist, they were capable of making every breakthrough in 2 turns.

So I rewrote the breakthrough research rules with two key elements in mind: 1) it must be worth attempting breakthroughs while a young scientist, and 2) breakthroughs should require more work but be more consistently achievable. The final design has you choosing one of two breakthrough paths: one which has a lower rate of success but accumulates more data disks every time you attempt it (where a data disk has an equal improvement to aging your scientist one turn), and one with a higher rate of success but which accumulates less data disks. Almost by happenstance, I ended up tying breakthroughs to the ship politics for this latter approach. Phil had coloured two of the four original breakthroughs the same colour as two of the five possible ship politics. Since I wanted more breakthroughs to make it less likely you'd accumulate all of them each game, I ended up designing two more breakthroughs and recolouring one of the originals. Now, you can research the breakthrough that matches your ship's politics with the greater chance of success (2D6 < Age + Data Disks, instead of 3D6), although if your scientist is young, you're probably better off taking the less likely approach because it doubles the disks you accumulate.

A key effect of these changes is that passengers have much more to do in the 3rd edition than the second edition. Previously, you'd just need to have engineers 3D print themselves and robonauts to act as Spacewalkers to keep the ship's Bernals promoted as they moved through the local interstellar cloud (LIC). If you didn't need radiators, and had enough fuel to accelerate and decelerate during the trip, that would be the only requirement, provided you had sufficient points of passengers in the vats and a habitable world as a destination.

Now, you can build an on ship economy by having your engineers produce factory cubes using robonauts and having scientists consume these cubes to research more robonauts or complete breakthroughs. You also need alert engineers to also 3D print replacement parts for cards lost to glitches. Business passengers can facilitate these functions in a lot of ways, particularly saving you from having to send promoted passengers back to school, as well as replacing lost scientists or engineers in emergencies. Biotechs and domestics can act as almost secondary classes because of a significant design change I made: the number of operations a passenger performs is equal to the number of careers they have - both being limited to two per passenger (with promoted passengers capable of having two disks of the same career). I did this because I kept losing track of which passengers had perform which operations, and so tracking operations using career disks becomes a natural way of playing the game, with an accompanying two fold improvement in the speed the game can be played at. Previously I would have to write up a game as I played in order to have any chance of playing correctly: you can see one example of such a transcript here.

In part three, I muse on the interplay of design and patterns.

High Frontier Interstellar 3rd edition design notes - part 1 (Introduction)

I have a bad habit of writing variants to games - as you may have noticed. Usually these amount to nothing (my Civilization board game variant), but occasionally they result in large design documents (my Civilisation Revolution expansion) or actual implementations (Unangband, UnBrogue).

My High Frontier Interstellar variant rules have made the jump from the design document phase to implementation, and hopefully will be included in the upcoming Kickstarter. Phil Eklund, the designer for High Frontier, had seen me active on the forums and liked some of the design suggestions I had made. He contacted me on April 18th this year with some comments in the Google document to the effect he was looking at including my variant rules in the 3rd edition of High Frontier, and that I had a week (!?!) to play test the finalized changes and come back to him with additional feedback and recommendations.

The actual development process has run through to the 13th of June as I've made minor tweaks and clarifications to the rules, although the vast majority of changes were made during that initial week. I've got an email from Phil dated the 24th where he's obviously worked late at night to include my rule revisions into the poster map available on Zazzle.

High Frontier Interstellar is primarily a solitaire game (with two highly experimental multiplayer rule sets in the 3rd edition) which uses the components including patent cards from the main High Frontier game, but has its own rules and map board available for purchase as a poster (be sure not to buy the postcard size version of this poster by accident). It achieves this by reusing statistics, symbols and some rules from the High Frontier patent cards, along with a small number of additional card features highlighted or surrounded in green to indicate they are specific to or also apply to the Interstellar rule set (piloting and terraforming symbols, starship engine thrust and fuel consumption figures and some robot colonist special abilities.)

Thematically, Interstellar is the shot for the stars following the colonization of the solar system modeled in the High Frontier game. You are responsible for managing the crew and would be colonists as they travel in a star ship fraught with risks: each 12 year turn you roll a ship event dice which indicates what risks each passenger career suffers - with up to 4 out of 6 face rolls causing a potentially deadly risk for some careers. You can minimize risks and suspend aging by putting passengers into the vats, but they're otherwise careerless while in the vats so don't get any actions, and have to go to school for 12 years when they exit the vats to earn their new careers (with the attend risks of a ship event roll).

Each passenger with a career can perform one or two operations each turn: the career counters indicate which actions they may select from, the symbols on the cards indicate which careers they may learn at school, each career comes with its attendant ship event roll risks and a list of operations it may perform. This is summarized in the career track on the poster map in a graphical form, part of which is below:

The risks show here are Alzheimer's (the head symbol), Gray Goo (the biohazard symbol), Mutiny (the gun symbol), Accident (the falling man symbol), and Cancer (the crab symbol). A passenger who has both a scientist and business career is guaranteed one of these risks every turn, as any ship event roll made has a matching dice face next to one of these two careers, and all of these risks could potentially kill the passenger. The operations these careers can perform are listed to the right.

A typical risk resolution is Cancer. Roll 1d6 < the card's Age (number of turns in the game) and the human passenger dies, except if you've successfully researched the Cure Cancer Breakthrough, where you get to roll 2d6. Given that you rarely have more than one alert scientist on the ship, and the difficulty of succeeding at finding this cure is also dependent on their age, you can see how deadly Cancer can be if you are unlucky enough to roll it.

High Frontier Interstellar is a game about balancing risks. There are high risk careers like scientists, and space walkers, business and engineering, and low risk careers like pilot, and domestics, and biotechs, but the careers are there primarily to manage the accumulating risks of age, stress, political differences in the crew, technology run a muck and the comparatively easily managed risks of micrometeroids and the local interstellar cloud (LIC) your starship passes through, to keep your pilots alive long enough (or to have pilot babies) so you are able to stop the star ship successfully when you get to your destination.

In part two, I look at some of the motivations for doing significant development for the 3rd edition.

Powering up

It has been a long time since I've posted here. That's not to say I haven't been busy: I'm active on Twitter, perhaps too active, but feel free to follow me there; I've been involved enough in the upcoming High Frontier 3rd edition (planned for kickstarter in the next month or two) to have earned a developer credit on the 3rd edition of High Frontier Interstellar which is a poster based game using the High Frontier components; I've hosted some Roguelike Radio episodes recently; I've publicly committed to writing a book on roguelikes, provisionally titled Killing Letters, which I'll be talking about more once I have it written and working through the publication process (probably a self-published ebook); I'm thinking about a high concept but deeply personal science fiction media podcast modeled on Hardcore History; I have a roguelike design I'm convinced is going to be amazing but is going to take a lot of work; I've started enjoying television (Person of Interest, Hannibal, Orphan Black) - both binge watching and taking my time.

Then there's being a parent.

I have to be careful to avoid over promising of course: I'm years overdue on a trivial bug fix Unangband release because getting the build stack redone takes longer than I have the time to do in a single session so it never gets finished.

But this post is to give you a heads up that there will be at least two, if not three, long form pieces coming up in the short term. I've promised to write a book review, I want to write a development focused post on what I've done to change High Frontier Interstellar and to talk about the difference between design and development from my perspective, and an economic analysis of gaming vs gambling.

And I'm hoping that'll get me interested in blogging more frequently again.