Monday, 4 April 2016

High Frontier RPG temporarily on hold

I'm temporarily removed all access to the High Frontier RPG Google doc I've been working in, in direct response to

The current design includes rules for a number of difficult topics which I think the RPG is unavoidably going to raise. I was hoping the RPG community would be mature enough to handle these appropriately, but based on the experiences of the writer of the referenced article, I no longer think that is the case and instead any attempts I make to reify the types of topics that naturally arise when a 4 person crew is sent on a 10 year mission without any other human contact will have a negative outcome.

This article has so badly shaken me, I'm now second guessing the efforts I'm making to put a little more detail in classic TV tropes such as a multi-ethnic crew.

To people who've been waiting to play test this, I would like to apologize. I'm going to have a long think about whether or not I want to continue any efforts with this design and then how to approach or censor the topics I want to handle.

Sunday, 13 March 2016

Dear friends

Much like you, I have spent much of my life obsessed with the idea of the savory muffin - a food with a name that invokes so much possibility [1] but which inevitably ends in a dry oniony disappointment [2]. For several years now, I've been exploring the possibility of meat muffins but I've never been able to find what I've been looking for [3]

Until now.

A local cafe, hidden in an industrial zone near my daughter's ballet class, serves a risotto and chorizo timbale baked in a muffin tray and wrapped in baking paper [4]. I assumed that the word timbale completely described this heavenly dish, but a quick Google search reveals that there is an incredible world of shaped baked pasta and risottos that I was previous unaware of.

I worry constantly that I'll die not knowing everything, and a discovery of this significance this late in life lends credence to my fears.

[1] See also: Corn bread.
[2] There's never enough cheese inside the muffin to be worth mentioning. Occasionally there's enough on top.
[3] Potato top pies are the closest flavour analog I can find.
[4] They also do an amazing prosciutto, egg and caramelized onion cheese cake with the prosciutto forming the base of the cake.

Friday, 13 November 2015

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

Monday, 24 August 2015

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.

Monday, 10 August 2015

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.

Tuesday, 4 August 2015

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.

Friday, 26 June 2015

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.

Monday, 15 June 2015

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.

Saturday, 13 June 2015

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.

Thursday, 11 June 2015

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.

Sunday, 13 July 2014

UnBrogue postmortem: part 2

It has been over a year since my last UnBrogue post-mortem article, which just goes to show how much time I have spent developing this Brogue variant, which is to say, virtually none.

However, Brogue itself has had two version releases since I last finished the game, and a number of design changes have either vindicated or echoed decisions I made in UnBrogue, so I thought it worth documenting the similarities. I'm not going to be able to draw many conclusions from these, other than 'I told you so' and there's plenty of things in UnBrogue that are not in or intended to be in Brogue, but which I'd like to see preserved and playable at some future date.

The most obvious one in Brogue is that armour now affects your stealth. This was one of the original reasons for creating UnBrogue, however Pender incorporated a significant rewrite of the stealth mechanism for the Brogue release whereas I merely added a stealth modifier for different armour types. I've not played enough Brogue 1.7.4 to know how the stealth mechanics differ, but the effect was significant enough in UnBrogue that in plate armour you'd effectively end up fighting all the monsters on a level near the stairs you entered through. I'd like to think I was somewhat influential here in making a case for linking armour with stealth, although this is harder a revolutionary idea.

The second is that the dagger now has a higher backstab multiplier than other weapons - although a fixed amount in Brogue, whereas it is enchantment dependent in UnBrogue. Again, hardly a revolutionary idea, but it was one that I was criticised for by some long term Brogue players, so I had a small moment of satisfaction in seeing this in the release notes for 1.7.4.

The third is that immunities and slays now include categories of monsters rather than individual monster types. Again, Pender differed significantly here in that the categories of slaying and immunity are far broader than the ones I chose, although there are some of the same choices (jelly immunity in both versions). I'm less willing to claim any influence here, because I believe Pender already had intended to do this.

The fourth is one of the new puzzle rooms is similar in theory to a number of the puzzle rooms in UnBrogue. Again, this is because I built it from the same elements already present in Pender's game - and Pender would have noted direct inspiration in the source code.

The fifth is the addition of further weapon types. The designs are radically different (and much more inspired on Pender's behalf), and the flail is likely influenced by games like Hoplite, but it was clear that there was a need for more variety, and what I've played of the whip is especially fun.

As for UnBrogue, I'd like to fix up the last remaining bugs and release a full 1.1.7 rather than the release candidate it has been stuck at for 2 days less than a full year; however the bugs I've introduced were pretty resistant to being fixed (I can't duplicate the wand/staff crash bug) and it is likely to be some time before this will happen.

And the attraction of working on UnBrogue has weakened far faster and further than UnAngband. I think there's several reasons for this. Firstly, as noted above, a big part of the initial reasons for UnBrogue have been incorporated into the main game, even though UnBrogue has gone a lot further than just these initial changes. Secondly, Brogue has diverged in a number of systemic ways that it would probably require that I start reimplementing UnBrogue from scratch on the new code base. Thirdly, Brogue has fallen into this unusual space for me, game play wise. After playing the likes of 868-Hack and Hoplite, Brogue feels in many ways both too big a game: the early decisions are spaced 'too far apart' rather than being turn by turn, and I now find myself on autopilot through the first few levels which inevitably gets me killed on level 4 or 5. Whereas Brogue doesn't have enough strategic headroom to be a truly sprawling game that I can lose myself in (like Unangband).

That's not to say that I don't think Brogue is an amazing game. And I also would like to preserve some of the crazy ideas that UnBrogue has, to continue as a variant of Brogue moving forward. But between child rearing, starting work on Unangband again, and my other current obsessions (like play testing the 3rd edition of High Frontier), I don't see a time or a place in the short term for a new UnBrogue release.

PS: I've updated the Rogue Basin UnBrogue page and added a page on the Brogue wikia to include the links to the latest UnBrogue downloads if you are still interested in playing the game. I think it is well worth it, and I've spent a huge amount of satisfying time adding stuff. I'm especially proud of all the new puzzle room designs I was able to come up with.

Monday, 7 July 2014

The Real Roguelike Renaissance

There has been a mini-spate of 'explainer' articles aimed at easing the neophyte gamer into the world of roguelikes: both on Gamasutra ('Roguelikes': Getting to the heart of the it-genre), and IGN (Roguelikes: The Rebirth of the Counterculture). Both simultaneously praise the old school nature of high difficulty levels, permadeath, procedural generation, and point towards the emergence of the genre into the mainstream as a fresh new trend, with interviews with well known indie game developers such as Edmund McMillen (The Binding of Isaac) and Daniel Cook (Road Not Taken) as well as up and comers like Teddy Lee (Rogue Legacy), Paul Morse and Duncan Drummond (Risk of Rain) and Keith Burgun (100 Rogues, Auro).

But by pointing at successful examples of commercial roguelikes and focusing on pull quotes from current developers, both articles miss the real roguelike renaissance which predates the examples given by a number of years. Listeners of Roguelike Radio and members of the close knit roguelike community will be aware of the much more titanic shifts in roguelike development in the noncommercial space from a long spanning tradition of the big four roguelikes (NetHack, Angband, ADOM and Dungeon Crawl), through to the relative stasis of the early to mid 2000s followed by the explosive reinvention of the genre inspired by the 7DRL competition, and coffee break roguelikes in general.

I would like to trace a through line from this early roguelike Renaissance to the antecedent of almost all recent commercial roguelikes, Spelunky, which in its freeware form was a huge influence on the early successes of the Binding of Isaac and FTL, but I'm not sure whether such a path can be followed. If it is, Derek Yu would be the person to talk to, but neither explainer article includes an interview with Derek, and I don't recall him talking about whether any of the more recent games influenced Spelunky. There is a direct connection between Derek Yu and DoomRL, but I suspect Spelunky was much more fashioned by the general rise of the indie game and Derek's fondness for NetHack than his participation or awareness of early 7DRL efforts.

But even if there is no connection, it is an important part of the story that the community should be telling and a narrative that is far more interesting than the 'difficulty is in again' message that the mainstream press is perpetuating. It is also a way of including the unsung heroes of the rise of the roguelike - the authors of countless freeware roguelikes who influenced and built the platforms upon which we stand, as well as the original authors of Rogue who founded the genre.