Things I Hate About Roguelikes Part 4: Bog Standard Dungeons

On our previous episode, we covered bad controls. I’ve yapped enough about annoying gameplay. Now it’s time to talk about theme. Or more properly the lack thereof.

First, what do I mean by “theme”? It doesn’t have to be a message or even a concept in the same way we view a theme in literature, though video games certainly do tend to have those.  I’m not setting the bar that high.

Most of the time when people mention theme in the same sentence as video games, they simply mean setting.

Darkest Dungeon. Care to guess at the theme?

Setting is a huge part of it sure, but there’s also the aesthetic, the music, the lore, the names and descriptions. It’s the consistent application of all those things in a game that comes together as a cohesive whole to make you feel something, especially when that feeling is distinct from what you get in other games.

With that definition in mind, I ask what theme do the classic roguelikes have? The answer is they don’t really have themes at all.

The three cardinal sins of theme

There are three particular ways in which roguelike themes end up being bad or nonexistent.

  1. High Fantasy is the vanilla ice cream of video game themes

The vast majority of CRPGs and roguelikes in particular have a generic high fantasy theme that throws at you all those familiar, recycled tropes that we know and love.  I’m talking elves, orcs, goblins, dwarves, trolls, hobbits, and of course dragons. This is the baseline. The vanilla ice cream of video game themes.

The lineage of all this high fantasy stuff is painfully obvious.

Tolkien -> Dungeons & Dragons -> Adventure -> Rogue -> roguelikes

  • Tolkien heavily influenced Dungeons & Dragons
  • Tolkien heavily influenced Colossal Cave Adventure
  • Tolkien heavily influenced Rogue (by way of the aforementioned)
  • Tolkien heavily influenced NetHack

And so on and so on for the next 30 years.

“You Hob-bit my whole shit” – J. R. R. Tolkien (presumably)

Each successor in the chain obviously took a great heap of inspiration from the ones that came before.  Some went further by just pilfering the terminology directly.

Dungeons & Dragons had hobbits, ents, and balrogs until it had to change the names. Rogue famously had the rust monster and floating eye, Dungeons and Dragons monsters which had to be replaced with the aquator and ice monster. Some games seemed to have dodged the copyright issues. NetHack retains the rust monster, floating eye, hobbits, nazgul, balrog, and on and on.

Tree of roguelike evolution

Several roguelikes were even named after Tolkien!

  • Angband and Zangband
  • TOME (originally: Tales of Middle Earth)
  • Mordor
  • Two games named Moria

And a bunch of games just called “DND”.

I’m not saying Tolkien is bad. Like vanilla ice cream, Tolkien is very good. It’s the monotony that is killing me. Tolkien was inspired by Norse, Germanic, Slavic, and Greek mythologies; religion; classic and modern literature; epic poems; language; opera; personal experience; and the horrors of war. So we took a richly detailed, deeply complex, epic fantasy universe and boiled it down to generic elves, dwarves, and orcs.

Let’s try ripping off somebody else for a change, eh?

Another knock off isn’t going to feel fresh to anyone on the planet. Middle Earth has inspired thousands of games and books. Lord of the Rings and The Hobbit are some of the top grossing movies of all time and there’s even a TV show in the works. God knows why anyone would want to see more after watching Peter Jackson remake the same movie 6 times. Anyway…

2) The kitchen sink is kind of disgusting

Adding content to the classic ASCII roguelikes was dirt simple. All you needed was to choose a letter. Half the monsters in Rogue don’t even have special abilities! Talk about easy. In time, a huge number of monsters started to become a selling point for roguelikes.

All of Rogue’s monsters

First, Rogue had to have exactly 26 monsters. Hack had over 50. NetHack has hundreds. Slash’EM has thousands of monsters.

Where you going to get all those fantasy creatures? And how are you even going to fill out the rarer letters like Z, X, Q, and J? There’s really not that many distinct monsters to pick from in Tolkien’s universe. So most roguelikes start with high fantasy as the core and then keep piling on a hodgepodge of assorted monsters and myths from wherever they can be found.

The only thing standing between you and the Amulet of Yendor

That’s how you end up with Zombies, Xerocs, Quaggas, and Jabberwocks.

We usually call this “everything but the kitchen sink”, but then again NetHack actually has a kitchen sink too.

Simply put, stuffing everything you can imagine into a game with no rhyme or reason does not make for a consistent theme.

3) No such thing as halfway goofs

When I’m playing a roguelike, I want to feel like I’m going on an epic adventure. Whether playing the hero or (more traditionally) the dastardly rogue, a certain level of seriousness aids the immersion.

Ninety five percent of the time, this is actually pretty well achieved. I get to fight wraiths and giant spiders and orc captains. Even with no graphics, decent enough enemy descriptions let your imagination fill in the void naturally. The pure insanity of classic roguelike difficulty turns the screws until the dungeon itself seems like the oozing, cavernous maw of some giant horror.

And then, because roguelike, you get this bullshit.

A toenail golem? Are you !%$*@# kidding me?

Some roguelikes are more guilty than others on this front. DCSS and NetHack only occasionally wander into goofy territory.

The source for NetHack’s Keystone Kops. It’s an open question if silent, black and white slapstick comedy translates well into ASCII, but here we are.

PRIME has monsters ranging from daleks to chestbursters, green killer tomatoes, cheerleader ninjas, and high ping bastards.

Finally, Slash’EM Extended is the worst:

  • xof (that’s fox spelled backwards)
  • 50+ kinds of dogs
  • “dwarf on crack”
  • Parry Hotter
  • 9 kinds of “prostitute” enemies
  • A bunch of other sexist crap I don’t want to even mention

Yes, I am a humorless killjoy. If you want to do humor, go big. Make the whole game comical like Dungeons of Dredmor. For me, 5% goofy leaves the entire game feeling goofy.

Good examples of theme

Plenty of roguelikes do have fascinating themes and I love it.

  • Unreal World: a real world Iron Age setting
  • Cogmind: really unique sci fi
  • Hieroglyphika: set in Egyptian underworld, completely devoid of text
  • Sproggiwood: inspired by Finnish mythology
  • Haque: cool glitch fantasy aesthetics and chill vibe

Hell yea

As much as I’ve hated on games based on Tolkien, I’ll admit Sil sounds fascinating because it “dispenses with many generic fantasy tropes” and “stays true to the writings of Tolkien”. And Darkest Dungeon, mentioned early, creates a fantastic theme by doubling down on the dungeon setting and finding what makes it truly interesting.

Even the roguelites I mentioned at the beginning of this series (Binding of Isaac, Nuclear Throne, and Spelunky) all have great themes and consistent aesthetics, which I’m sure contributes to their success in no small part.

I theme, you theme

Lukewarm high fantasy, the kitchen sink, a sprinkling of goofy nonsense? That’s what I’m calling the bog standard dungeon. I think we can do better. Here’s how low the bar is:

You don’t have to make up a whole universe from scratch.  There is so much material to work off when choosing a theme for your game. Countless ancient cultures and mythologies, historical settings, public domain books. I think my game, Golden Krone Hotel, has a pretty neat theme. But you better believe I stole a lot from Dracula, Romanian mythology, and vampire lore in general.

I’ve spent a great deal of this article complaining that roguelikes need to stop copying from a particular tabletop fantasy roleplaying game from the 1970s.

You know the roguelike with the coolest theme ever? It’s Caves of Qud of course.


Ok we’re done here

Go make cool roguelikes and go play cool roguelikes.

If you want to check out Golden Krone Hotel, it just had its biggest update and is on sale for 50% off.

Should My Next Game Be Top-Down or Side-Scrollling?

I’ve been chewing on the idea for my next game for a bit. “IDEA?!?” you say? It might seem silly to be here throwing out my idea at you (when ideas are generally considered worthless). But Ryan Clark says the right idea is super valuable and I find that pretty convincing.

The game is called DUSK BELT and it’s set on a tidally locked planet. The basic concept is that one side of the planet is constant day, making it a blistering hot desert. The other side is an eternally dark frozen tundra. In between is a narrow temperate zone where most of civilization resides. Your goal is to get to both “poles” and presumably fight some bosses at each one, which of course turns the thing into a survival game but one with an interesting duality. In half the game, you struggle with heat, exhaustion, and thirst. In the other, you struggle with darkness, cold, and hunger. Ignore the hard science realities of such a place and consider only the abstract version I’ve described above. Even with that little setup, it seems to me to be a damn cool idea!


I’ve wanted to make a big survival game for a while. Survival games* always bug me in that, they’re fun until you get to a baseline of comfort and then the challenge typically disappears. Surviving the first 10 minutes in Minecraft is hectic, but once you have a 3×3 dirt house you’ve mostly solved the shelter issue. The other thing is that I like survival on the go. I like the idea of exploration and making due with what you find on your travels. For me, it helps to have a goal, particularly in the form of a physical destination you’re trying to reach. Most survival games are about plopping down and exploring only the nearby area. My first game jam game, still probably my favorite, explored these ideas. The game gets progressively more difficult as time goes on and the only way to win is to travel a really long distance in a certain direction. I want to explore that further.

*I keep saying “most survival games” do this or that. I’m sure I’m not particularly well versed in the genre, so am happy to take recommendations…

Beyond that, survival is just a mega popular genre. I’ve lost track of how many word clouds and graphs I’ve seen with survival and crafting crushing steam. My last game was a traditional roguelike and it while it was well received among its audience, to a first approximation nobody has even heard of it. Traditional roguelikes are a niche among niches. I would argue that most people don’t know the genre itself even exists as a separate thing. It’d be cool to try something with a bit more appeal to your average gamer.

The “least useful” slide from Mike Rose’s talk Let’s Be Realistic: A Deep Dive into How Games Are Selling on Steam

Beyond survival aspect, I also want to mix in some combat. I imagine it’ll be a lot more interesting exploring the pitch dark side of a planet if creepy monsters are out to get you. I haven’t thought about this too deeply, but I’m leaning towards a roguelite metaprogression that drives the game. I would love to make a game that was as fun as Rogue Legacy or Dead Cells in that aspect. Of course, I’m sure many fans of my last game which had zero metaprogresssion will be turned off. Again, I face a harsh reality that 99.9% of gamers absolutely hate starting over from scratch.

Top-down or side-scrolling?

I initially assumed the game would be a big open world, top-down game. It seems so obvious. Survival works very well in top-down. It makes the scale of the world seem huge and gives you plenty of space to explore. It gives you a chance of actually getting lost, which is totally my jam. For the combat, I could take cues from games like Nuclear Throne.

Then I got stuck on something surprising: the art. I need to come up with an art style that allows me, a single (not artistically inclined) developer with little time, to crank out art assets. I’d like to try something other than pixel art for once. The obvious choice after that is to hand draw and animate top-down characters in 4 or even 8 directions. Ugh, no thanks!

I kept landing on the following style of art: draw characters from a profile view, draw their appendages separately, connect them all together with a skeletal system, and then get free animation by rotating everything. I’m sure there’s a name for this, but I have no idea what it’s called. It seems to be used in a lot of games though. I know it’s used in One Hour One Life (the developer has some interesting stuff to say about survival too), but I also see it in games like Limbo and Pinstripe.

For one, this allows assets to be produced really fast. Draw characters facing one way and you get the other direction for free. There’s no need to animate things by hand. And then you have the really cool stuff: having detachable/replaceable appendages or a full skeletal system (by that I mean an actually skeleton underneath the normal sprites).

There’s just one problem with that art style: it looks kind of janky in top-down. You don’t get an “up” or “down” direction and even if you drew those directions separately, they couldn’t rotate/animate in the same way. It looks a bit weird in the top-down One Hour One Life, but that seems acceptable given the odd art style. If you add vehicles (ships/cars) or large monsters, the problem is exacerbated. In a side-scrolling view, however, this kind of art works perfectly. Your character only ever needs to face left or right.

Oh no.

It might be weird to be debating this fundamental choice about the game. Shouldn’t I know that already? But the core ideas of the game are about the setting and survival, not the perspective. They could be applied in lots of different ways. So then I started reviewing the pros and cons of each style…


  • +Fits survival nicely
  • +Allows for huge scale and getting lost
  • +Produces an easily understandable “map” of the world
  • -Profile art looks really janky
  • -Circumnavigating a spherical planet is harder to achieve


  • +Profile art works great
  • +Background/foreground assets can be easy to make (silhouette style)
  • +Jumping and platforming is fun out of the box!
  • +Circumnavigating a spherical planet is easy
  • +A ton of hugely successful indie games are platformers
  • -Widely claimed to be a “saturated” genre
  • -I have no idea if survival and platforming mix

That last one is the big sticking point. Platforming games can have verticality, but the ground is always there as a reference point. Getting lost (unless it’s in a sprawling cave system) seems impossible. Side-scrolling games tend to have smaller scale. It’s hard to imagine the player having any difficulty tracking down vital resources in a tiny space.

One idea I have is to make the distance you can travel left to right absolutely vast, but enable the player to traverse large distances with a vehicle. You could travel at great speeds for a while, but then be forced on foot when periodically running out of fuel. Is that boring? Does any of this make sense? Who knows!

Sorry for the stream of consciousness, but that’s where I’m at. Super early stages, but I’m excited about this idea.

I need to either accept the weirdness of my chosen art style in top-down or figure out a way to make survival work with a side-scrolling perspective.


Things I Hate About Roguelikes Part 3: Terrible Controls

This is a 4 part series on annoyances I have with roguelikes. Last time we covered Identification.

In my first article, I asked why traditional roguelikes aren’t nearly as successful as action roguelites. I found a reddit post asking a similar question: why is a super difficult game like Binding of Isaac so popular anyway? Here’s the top comment:

Despite its difficulty it was accessible. Load it up, hit play, everything you need to know is written on the floor of the first room. Despite this, it has depth, skill and replayability…

There’s a ton of sense in that answer. If I had to sum up all the problems with traditional roguelikes in one word? Accessibility. And there’s nothing that epitomizes that inaccessibility better than really terrible controls. This isn’t going to be a long post because my point is simple: let’s stop making games with shitty controls.

Move over Martin Luther

How bad is this control situation? Am I exaggerating?

Nethack has 95 separate key commands. NINETY FIVE. Try writing that on the floor.

It’s not just that there are so many commands, but also many of them require multiple keys. Many require you to remember the difference between lower and uppercase. Many are known standards among roguelikes, but will appear completely arbitrary to a newb (like . for rest).

Contrast that with Binding of Isaac. As you saw earlier, it has 10 keys. Practically speaking, you only need to remember 4 things since groups of keys like WASD can be memorized as single units.

Basic controls in Golden Krone Hotel

It’s a well known rule of thumb that humans can store about about 7 items in working memory. If your game has about that many controls (as BoI does), the game supports a pick up and play style. You can start having fun immediately. If it has dozens and dozens of controls to remember, it’s going to feel more like cramming for an exam. The learning curve is going to be painful. And when I say “learning curve”, I’m not even talking about achieving mastery and learning to avoid the many sadistic and brutal ways games like Nethack will insta-kill you. Learning controls, at least enough to be able to move around and perform common actions, is table stakes for actually playing a video game.

Back in the dungeon again

Learning isn’t the only problem here either. Since they take so long to master, roguelikes are often played over the course of many years and with long breaks in between. This is how I played DCSS over the last decade. I’d decide to jump back in, get utterly obsessed with it for a few weeks, and then drop it for months. Whenever I returned to after a long absence, I struggled to remember the keys for things like picking up items, casting a spell, or showing the religion screen (g, z, and ^). This is a pretty common experience.

Use it or lose it

Learning (or remembering) the most common controls is one thing. It’s a hassle, sure, but you gotta do it.

That’s a lot of keys.

The more insidious problem is all those rarely used commands. Those keys I couldn’t remember in DCSS? You don’t strictly need them to play the game:

  • g: Most useful items are picked up automatically
  • z: Many kinds of characters can survive the early game without reliance on spells or abilities
  • ^: It’s possible to ignore most of the menus most of the time

On the other hand, every key has a purpose. If it didn’t give you a better shot of winning, it probably wouldn’t be in the game:

  • Some helpful items are not picked up automatically by default and require a manual keypress
  • Not using abilities/spells is a common pitfall for new players that gets worse later in the game
  • Menus like Religion or Skills expose a lot of important details and choices

What ends up happening is I play with a small subset of the keys available. I occasionally get curious about other commands and hunt down the corresponding keys, but the next time I open the game I forget about them because I haven’t had enough practice. Thus, with whatever roguelike I’m playing, I usually find myself playing a fraction of what the game has to offer. Forgetting to use abilities, spells, projectiles, etc. Failing to squeeze all the resources out of my environment. Ignoring the consequences of my statuses and mutations. It’s Burden of Knowledge all over again. I suspect many roguelike neophytes are afflicted by the same problem and it’s partly why they find the genre so impenetrable.

Moderately sized packages

The goal should be pretty obvious. Fewer keys.

I understand if you’re skeptical. After all, roguelikes do have a good deal of stuff going on. Don’t you need a plethora of keys to deal with it all? Not necessarily.

I’d say the most important thing in a roguelike is movement and positioning. Attacking monsters, running away, dodging traps, opening doors, falling through shafts. These are all things that are already done with just the movement keys. Everything else is up for negotiation. And I do mean everything.

One of my proudest accomplishments during 7DRL was making a game that only uses 4 way movement. Here’s the things you can do in DUMUZID with just 4 buttons:

  • Move around
  • Attack monsters, sometimes instantly killing them if performed properly
  • Take portals to other floors
  • Pick up spells
  • Cast spells
  • Carve pieces of yourself off of… yourself
  • Activate score runes
  • Pray

I use this example to demonstrate what’s possible, to stoke your imagination, but of course not every game has to be as minimalistic. All I’m saying is keep your mind open and don’t assume the way it’s been done before is the right way to do it.

Here are my specific recommendations on controls:

1) The best key is no key

There’s a saying in the programming world: The best code is no code. If you can solve a problem without actually writing code, that’s zero bugs, zero debugging, zero maintenance.

Likewise, it’s ideal if you can design an in-game action without creating a new command for it. It means less space hogging up the help menu, fewer things to memorize, and a softer learning curve.

When possible, do things automatically. Auto-pickup is a great example. It really ruins the flow of a run when I have stop exploring the dungeon to pick up something. If it has a possibility of being good, the game should pick it up for me. If it’s useless trash, I question why it’s in there in the first place. Yes, implementing an auto-pickup system can impact the rest of the design. I think it’s worth considering the overall design just to get the controls right. Golden Krone Hotel has auto-pickup on everything. If you pick up gear and it’s better than what you have, you equip it automatically. Otherwise that item is immediately turned into gold so you can buy better stuff later.

Another creative example is found in Brogue. Most games require a separate keypress for taking the stairs, but Brogue’s maps are designed in such a way that walking onto a stair tile is all you have to do to descend.

2) Remove the kitchen sink

It’s simply ridiculous that roguelikes often use the whole alphabet. Why have  separate keys for taking off armor and putting it on? Why two more keys for putting on rings and taking them off? When I see these kinds of controls, I have to assume the developer wanted to make their game as esoteric as possible. There’s no need for so many damn keys to manage your inventory because a single well-designed inventory screen could accomplish the same thing!

I have gripes with SoTS, but at least its inventory is nifty

There’s usually a dozen keys to interact with the environment. For example: > to go down stairs and < to go up. The funny thing is I’ve never been on a tile that gave me the option to go up and down. So why have two separate keys? In Golden Krone Hotel, I have a single “contextual action” button that lets you perform all kind of actions.

3) 4-way is A-OK

I expect this to be the most controversial point but here goes. If you want to make a more accessible roguelike, at least consider going with 4-way movement. It has its own interesting tactical consequences, but more importantly it’s accommodating for laptop users who don’t have numpads. Many newer roguelikes focus on 4-way movement: Cardinal Quest, POWDER, Dungeons of Dredmor, and The Ground Gives Way. In my own game, I waffled a bit by eventually allowing 8-way movement to be an option but I still have 4-way as the default. I’m glad both camps are happy.

Yes, there are vi keys and the argument is always that “you get used to it.” Bollocks. You can get used to anything given enough time, like riding a backwards bicycle. That doesn’t mean it’s optimal or worth your time to learn. If it works for you, great. For everyone else, I’m cautious to take design cues from a program that millions of users can’t figure out how to quit.

If you’re going to force 8-way movement on laptop users, consider a more reasonable setup like QWEADZXC.

4) One menu to rebind them

There’s not much to say on this one. All games should have rebindable keys. Some people won’t be able to play your game without it.

5) Full Mouse

Making your game fully playable with only the mouse is really important these days. Not only will some players want to play the entire game with mouse, but it’s also a good fallback for anyone still learning all the controls.  Besides, many actions like examining tiles, looking at tooltips, or aiming a projectile become much easier with mouse.

At the same time, roguelike veterans are used to playing with only keyboard. Be careful that you don’t accidentally make your game require both mouse and keyboard. I’ve fallen into this trap occasionally because it’s much easier to implement menus with clickable buttons rather than keyboard navigation.

6) Keypress hints

Though you should support mouse, it’s likely that keyboard shortcuts will turn out to be much more efficient. It doesn’t have to happen right away, but games should gently guide players towards being fully adept at keyboard play.

Sproggiwood’s controls are near perfect. My only gripe here: it’s not immediately clear whether 3 or 1 is the shortcut.

The best way to accomplish this is a keypress hint attached to every button. The button is there as a fallback, but the keypress hint is a constant reminder that a more efficient option is on the table.

Press z to clean up this mess

How did we get here anyway?

When Rogue was released, there wasn’t much else going on. Video games were still in their infancy and so were user interfaces in general (Graphical User Interfaces weren’t even a thing yet). Using every letter of the alphabet (whether for monsters, levels, or controls) seemed more like a feature than a bug. The bar was low and gamers didn’t have much of a choice. What were they going to do? Go outside?!?

Today’s gamer has a mind boggling number of choices (4000+ games released on Steam just last year) and a shortage of patience. If roguelikes want a snowball’s chance in hell of competing, we’ve got to do better. Controls aren’t the only thing that need to be improved of course, but they’re the first barrier to entry for new players. To be fair, most of my gripes in this post have been with older roguelikes (which I really enjoy playing). Newer, commercial roguelikes have gotten much better in this area, but I still see a lot of room for improvement.

Join us next time when we talk about Theme.

Things I Hate About Roguelikes – Part 2: Identification

This is a 4 part series on annoyances I have with roguelikes. Last time we covered Burden of Knowledge.

Today I want to talk about Identification systems. In many roguelikes, particularly the older ones, the items you encounter in the dungeon are not easily identified. While inexperienced adventurers can tell when they’ve picked up a scroll, the meaning of the cryptic symbols on it are not immediately obvious. Items can be identified in a variety of ways and once identified, any items of that type are known for the rest of the game. Using items that are unidentified can often save your bacon, but they can also be very dangerous.

Before I start complaining, a hypothetical example is in order.

Imagine you’re a new player who wants to try one of those rogue-likes everyone’s been talking so much about. You fire up Dungeon Crawl Stone Soup. After a few minutes, you’re near death.

Things look hopeless, so what do you do?

Fortunately, you’ve already scooped up 3 kinds of potions, 5 kinds of scrolls, and 2 pieces of jewelry. They’re all unidentified, so you don’t have the faintest clue what magical effects they could have.

Whatever. You click on the first item in your inventory. It turns out to be an invisibility potion. Good call.

Huh? Despite being invisible, it looks like the monsters are still attacking you. The potion also caused “magical contamination”, which negates the effect of invisibility. You die.

Why do we fall, Bruce? So we can learn to pick ourselves up…

So you roll a new character and quickly get into another bad situation. This time you encounter Grinder, a deadly early game “unique” monster. You decide to quaff a random potion again.

This time you get lucky! Your stack of three unidentified potions turns out to be Potions of Curing. These potions heal you, but for a tiny amount. Chugging all three isn’t enough to stop Grinder’s damage. You die.

You make one more character: an Octopode Assassin. Maybe sneaking past the the monsters might work better. Despite your best efforts to stay hidden, a pack of gnolls sees you on Floor 3.

You think you’ll try using scrolls this time instead of potions. Your first scroll makes a large bang. It’s a Scroll of Noise! More monsters will be coming soon, so you need to do something fast. One more scroll remains in your inventory. You read it. It’s a Scroll of Immolation. You die a fiery death.

Hopefully the numerous problems with identification are obvious from this example.

It’s yet another instance of Burden of Knowledge.

There are 28 kinds of potions in Nethack and 20 kinds in DCSS. Likewise, there are a large number of wands, scrolls, rings, weapons, etc. When you pick up your first potion and consider taking a single sip, you now have a HUGE learning problem ahead of you. In order to fully understand the consequences of this one action, you need to already understand several dozen items. Of course new players don’t go through the trouble of learning all that. They just treat the outcome as a total crapshoot. Maybe they roll the dice, but maybe they don’t…

It encourages hoarding

One of the hardest lessons to learn about roguelikes is that you must use your damn items. It’s very common for new players to die with full inventories. Part of this can be explained by item identification. When each unidentified item could be one of 20 things and half of those things are bad, the risk of using items appears too high.

It’s a common strategy to accumulate unidentified consumables until you have several of each kind. That way, you can identify a stack of items by wasting one and still have the rest identified and ready for future use. Players using this strategy may eventually stop hoarding items, but they ignore items and the item identification system completely until mid-game.

It causes learned helplessness

After watching many roguelike Let’s Plays, I’ve noticed that new players are very susceptible to learned helplessness. A couple bad (or even neutral) outcomes can convince a player to avoid certain systems altogether. When someone is new to a game, they’re constantly constructing mental models of all the systems in a game (most of which will be incorrect). They’re trying to deduce whether a particular strategy is good or bad on the fly. A few bad numbers from the RNG might give them the wrong impression.

And in the previous examples, it’s not even that the items were all bad. Curing was a great potion, but not very helpful in that situation. Invisibility didn’t help and the reasons are not going to be clear to a new player. Noise isn’t particularly bad, but it sure didn’t help. Immolation just sucked.

For a new player, there is no way to predict any of that is even a possibility. What’s worse is that, even after the outcome, most players (tending not to read the message log in detail) will barely understand what happened. They might swear off of using unidentified items completely, figuring that it’s more likely a newb trap than a useful strategy. Later, when they desperately need consumables to survive, they may not use them.

For experienced players, it’s a solved problem and a boring one at that

In Episode 30 of Roguelike Radio, guests discuss identification systems. I find myself nodding along with Keith Burgun:

For most people, these systems tend to come down to either it’s totally clear and it’s obvious what the item is or it’s completely random what the item is. Even if there is all this information that you could be using, it’s not clear enough… It’s very hard to make this system either not like completely solved or completely random.

Keith gives the example that in DCSS your biggest stack of potions is almost certainly a Potion of Curing or Potion of Heal Wounds (together these make up 38% of potions generated). Once you learn that, you’re rarely surprised. The vast majority of the scrolls and potions in DCSS are beneficial and the dangerous ones hardly pose a problem if dealt with correctly. Veteran players will know to find a quiet corner of the dungeon, rest to full HP, and ID items by wasting one of each type. As I’ll get into later, this zero-risk scenario is anathema to how a good ID system should work.

Admittedly, the system in Nethack is much more fascinating (for novices at least). Items can be far more powerful. You might come across a Scroll of Genocide that lets you wipe out an entire race of monsters or instead a Scroll of Punishment which weighs you down with a heavy ball and chain.

Are we having fun yet?

There’s also a bazillion ways to identify items. For example, dipping an Amethyst into a potion will turn it into a Potion of Fruit Juice if it was a Potion of Booze and thus identifies both kinds. Interesting idea, but the problem is it’s just another spoiler. Experienced players will know a bunch of these tricks, but those methods become both uninteresting and tedious. The worst offender is “price identification.” Since items have various prices and shopkeepers don’t have any problems with identification, you can often ID something by checking its sale price. I’ll let the Nethack wiki explain (emphasis mine):

The sell price will normally be half the “base price” of the item (one third the “base price” if you’re wearing a dunce cap, a level 14 or lower tourist, or wearing a shirt with no armor or cloak over it), but there is a 25% chance that you will only be offered 3/4 of the normal sell price (3/8 of the base price overall). You can get around this by repeatedly dropping an item and refusing to sell it, until you have been offered two different prices for it.

Finally, the topic of cursed equipment (forcing you to wield subpar gear  for extended periods) only needs a brief mention: it’s a hassle. After running out of ways to identify/uncurse items, you either avoid unknown gear altogether or you accept that some of your playthroughs will be dragged down by long periods of passive penalties. In Brogue, however, you can automatically identify items by wearing them for 1000 turns. Oh. Super.

Throwing the baby out with the Unholy Water

Many newer roguelikes remove identification completely including Cardinal Quest, Dungeons of Dredmor, IVAN, and DoomRL. Notably, TOME4 kept a bizarre vestige long after its identification system was made moot: players start with a Scrying Orb that can be activated an unlimited number of times to identify items.

Here’s the thing. Despite disliking the implementation of such systems, I actually like the idea of identification in theory.

More than anything else, having unidentified items makes the dungeon seem more mysterious, more magical. It emphasizes that the dungeon is dangerous, that you’re not running through a kiddie fun house. The dungeon isn’t meant for you. You’re no hero. You’re not storming in there at the beginning of the game with a +10 flaming sword. No, you’re a scared little thing, trying your darnedest to survive by scraping together whatever you find in the trash. That’s what roguelikes are all about to me.

A Broughlike, not a roguelike (so I have no complaints).

Of course, there’s also real gameplay benefits to identification. Getting down to your last hitpoint and then saving yourself with some unidentified item feels amazing. The bad outcomes are equally important though. Quaffing weird potions in the middle of bad situations can also result in a bunch of hilarious deaths. And that’s something truly special about the genre. Earlier we saw that standard ID systems discourage you from taking such risks and that’s really the thing I don’t like.

Rogue, That One

The most convincing defense of ID systems has come from John Harris. He pushed back strongest in that Roguelike Radio episode mentioned earlier. And he also wrote an excellent article on identification in Rogue. Harris explains the backstory behind having unidentified items in the first place. Like most things in early roguelikes, it comes straight from Dungeons & Dragons. That’s followed by a little story about “Rodney” that helps explain why the system in Rogue is so great. I encourage you to read the entire article if you have time.

That post had a huge influence on me when I was designing the ID system in Golden Krone Hotel. I was particularly inspired by Harris’s criteria for what makes an identification system good. I won’t list all 9 recommendations, though I did find most highly convincing. Here are the ones that resonated the most:

  • There must be bad items as well as good ones. Without bad items, the system loses a lot of its charm.
  • Bad items should be useful, at least in certain scenarios. Otherwise they’re just junk.
  • There should be a lot of items so that identification isn’t solved too early. The items generated in a single run should be a fraction of what the game offers.
  • The game must be hard enough that winning requires the player to use unidentified items in desperate situations.

That last point really stands out as the most crucial feature of a good ID system. Ideally, players would not want to waste their items. No quaff-IDing in a corner to safely reveal an entire inventory. It’s much better instead if a roguelike encourages players to use items in combat.

So how to achieve it? I’ll talk about what I did, but I’m not saying it’s the best solution or it solves all the problems with identification. All I’m saying is let’s try something different. There’s got to be some happy medium between throwing away identification completely and doing the same old thing we’ve been doing for 35 years.

After much ado, something surprisingly simple

As soon as I read Harris’s article, an idea popped into my head and I left a comment on the post saying as much:

While reading your article I had an idea: perhaps on the description of each unidentified potion you can see that is 1 out of 3 possibilities (and maybe that number changes depending on your character’s intelligence). This might give you more interesting decisions rather than feeling like you are rolling a 20 sided dice each time you quaff.

The way I implemented that idea is pretty straightforward. I decided to make all the consumables potions. Intelligence doesn’t factor into how many possibilities there are. Though I considered different possibility counts, 3 seems like the best option (offering enough complexity, but limiting how much information is presented). There’s 40 potions in the game, though you’ll only see 26 in any given run. People I told the idea to were initially worried that laying out 3 possibilities would make for a cumbersome interface, but putting the information in tooltips seems to works fine.

There are a few nuances to implementing the system. Though it’s not strictly required, I “bundle” potions in groups of 3. So in the above case, the bundle consists of Honey, Antidote, and Blink Potion. If I had all 3 of these potions and tried examining each, they would all yield identical descriptions.

To avoid price identification, I make all unidentified potions have the same super cheap price. That also has the benefit of encouraging players to buy and use more unidentified potions rather than pricier identified ones.

The most complex part is automatically deducing potion identities for the player. Some potions only have noticeable effects in certain cases. Let’s say I’m currently a vampire, I’m poisoned, and I quaff the above unidentified potion. It has no effect. Logically, we know it has to be Honey because Honey is the only potion of the 3 that would have no effect in the current situation (vampires aren’t sated by it). So the game would then identify the potion automatically.

If, however, I was not poisoned before quaffing, there would be no telling if it was Honey or Antidote. Neither would have an effect. That kind of potion would remain unidentified. Having potions that are not always guaranteed to be identified on the first use is one of Harris’s other recommendations. It adds a little depth to the system, so that players can think strategically about the best time to try identifying stuff.

Importantly, I’ve made sure all bad potions have utility if used properly. Conversely, many good potions can be bad if used at the wrong time. The above bundle is a good example. Aether is really powerful if fighting monsters that only do Physical damage, but could be game ending otherwise. Combustion is one of those classic “seems purely bad” potions, but can push enemies away from you in addition to damaging them. Nostrum is similar to Aether; you’ll have to decide if the healing is worth the subsequent vulnerability.

Live and quaff, friend

This system is only a tiny tweak to the status quo, but it changes everything. Knowing the worst thing that could happen upon using an item discourages hoarding and instead encourages you to use it in the middle of battle. I can’t say that I’ve fixed hoarding completely, as it’s truly one of the most hardwired behaviors you’ll see in new roguelike players.

The 3-possibilities system once and for all fixes the problem with Burden of Knowledge. There’s no need to consult a wiki if the game tells you what’s possible in a few short sentences. New players actually have a chance to make strategic decisions about what  they’ll use instead of it being a crapshoot every time. At the same time, experienced players don’t get to sidestep identification by using some obscure tricks. They still have to deal with it like everyone else.

If you know of any really interesting identification systems, let me know about them in the comments. Next time we’ll be talking about a staple of the roguelike genre, awful controls.

Things I Hate About Roguelikes – Part 1: Burden of Knowledge

I love roguelikes. Traditional roguelikes. Turn based, grid based, punch-you-in-the-gut roguelikes.

The complexity, depth, and emergent gameplay in these games rival any other genre out there. The heavyweights like Nethack, Crawl, and ADOM can be played for years without mastering them… or sometimes without a single victory. And in the last decade, roguelikes have proven beyond all doubt how valuable their ideas are. Despite being a genre invented in 1980, new games are constantly borrowing roguelike ideas and even the name itself.

And yet we haven’t seen a big adoption of traditional roguelikes. Roguelite action has done gangbusters of course. Games such as Binding of Isaac sell millions of copies. Nuclear Throne and Spelunky aren’t too far behind. But where’s our Binding of Isaac? Where’s the turn-based dungeon crawler blowing up the Steam charts? Clearly, permadeath is something many gamers are willing to stomach. Games like Civilization are proof positive that they enjoy turn-based stuff too.

I’d argue that there’s nothing inherent in the structure of traditional roguelikes that is holding them back from mainstream success. It’s simply that, for the most part, the genre is still stuck in the 1980s. I’m not the only person that thinks that.

This series is about 4 pet peeves I have when it comes to roguelikes. They’re things that not only annoy the hell out of me, but that I suspect might be at the heart of why the genre lags behind. I’m going to give examples of games that either solve or exacerbate the problems and share my tiny attempt at improving things with my game Golden Krone Hotel.

Before we start it’s important to point out, you know, this is just like my opinion, man. Some of the things I hate are literally the very features other people love. I think that’s OK, considering the huge variety available in the genre.

Burden of Knowledge

It’s no fun playing a game without knowing the rules.

Sure, there’s something to be said for the joy of discovery. But when you’re playing to win, not knowing the rules and not understanding the mechanics fucking sucks.

Ever been introduced to a board game by a friend who knows the game well? Ever had that friend suddenly “remember” an obscure rule halfway through (right after they’ve taken advantage of the rule)? There’s nothing more frustrating!

Burden of Knowledge1 is when game rules are so opaque that they’re nearly impossible to learn by just playing the game. Instead, you have to spend time outside of the game learning how to play the game… assuming you can find the information you need at all.


I tried to get into Dungeons and Dragons in college and it just didn’t click for me. At the same time, I was playing a ton of Magic the Gathering. I later realized these games are polar opposites when it comes to learning. With each, you have to learn a few rules to get started of course. Later on, however, the way you learn diverges dramatically.

When someone needed to learn a spell or pick a feat in Dungeons and Dragons, they often stopped the game for 30 minutes to skim the player handbook and decide what to do. The basic rules of the game are over 100 pages! You have so many choices at any given moment of the game. The problem is that understanding all those choices requires a lot of reading.

Contrast with Magic the Gathering. Even though the game has a lot of depth, you only have to deal with a handful of choices on each turn. When your opponent plays a new card you’ve never seen, something magical happens. You read the words on the card and figure it out in seconds.

In comparison to tabletop games, videogames actually have it pretty easy. They can simulate entire worlds and have the player learn on the fly just by mashing keys and seeing the result. In theory, we should never have to read rules while playing a computer game. In practice though…

Spoil Story

If we’re talking about polar opposites in the roguelike world, I can’t think of a better pair than Nethack and Dungeon Crawl Stone Soup. Nethack is notorious for it’s reliance on spoilers. In Nethack, there are dozens of ways to instantly kill yourself. Conversely, if you know the right secrets you can use ridiculously powerful abilities for free (like preventing monsters from attacking you). My first experience with Nethack was trying and failing for 10 minutes to get out of the very first room because I couldn’t figure out how to open a door. Let’s just say I’m not a fan of this approach. If you are, more power to you.

20+ ways to insta-die in Nethack

On the other hand, DCSS takes a stand against spoilers. Check out this tidbit in the “philosophy” section of the Crawl manual:

Things ought to work in an intuitive way. Crawl definitely is winnable without spoiler access. Concerning important but hidden details (i.e. facts subject to spoilers) our policy is this: the joy of discovering something spoily is nice, once. (And disappears before it can start if you feel you need to read spoilers – a legitimate feeling.) The joy of dealing with ever-changing, unexpected and challenging strategic and tactical situations that arise out of transparent rules, on the other hand, is nice again and again.


It’s not that there are no surprises to discover in DCSS. There definitely are. The Abyss anyone??? Rather the surprises are discoverable simply by playing the game. If you play very carefully, you have a reasonable chance to deal with any surprises on the fly. Remember the plethora of instadeaths in Nethack? There’s only two kinds in Crawl: starvation and falling into water/lava. In both cases, the game gives you ample warning that things are about to go belly-up.

Burden of Knowledge goes way beyond cheap deaths and big spoilers. There are tons of things to learn. What does this monster do? What does that spell do? Where do these stairs lead? What options do I have available on this turn? The amount of material you have to figure out in a big roguelike must add up to a few college courses (which might explain a lot for some of us). And that doesn’t even cover all the basic stuff (like what red bars signify in games) we take for granted.

So how are we going teach players all that stuff? Here are some common techniques. I’ve ordered them by their proximity to the ideal method, actually playing the real game.

The 6 Circles of Roguelike Learning Hell


Tutorials are great for quickly learning the basics. On the plus side, you are playing the game… sort of. It’s a stilted, challenge-free, and dead end version of the game, but at least you’re playing that version instead of reading a wall of text.


Hints are like mini-tutorials. A minimal amount of text presented in-game at exactly the right time you need the information.  You do have to read, but you do so right in the middle of playing. Hints should be made unobtrusive as possible, preferably with an option to turn them off completely.

Modal hints force the player to read them, but are sometimes needed to convey crucial information.

Tooltips & Descriptions

The third circle isn’t that bad: on-demand information delivered in game that (hopefully) obscures very little of the screen. Tooltips help you quickly learn the UI. Good descriptions greatly reduce Burden of Knowledge regarding mechanics. It’s particularly useful when monster descriptions tell you what kind of spells, resistances, and attacks to expect.

Message log

Messages logs are a weird holdover from text adventures. Most modern games have too much going on too fast to even support a log, but the pace in roguelikes sort of allows them to work. A message log is a safety net for understanding. If the game fails to explain something visually, it can always go in the log and you don’t even have to stop playing to read it.

The utility of the message log is what makes it so dangerous. It’s very tempting to just dump stuff in the log instead of doing the very hard work of making it clear what’s happening on the play field. Even worse is that the log explains events after they happen. For small effects, that’s alright. For instadeaths, it doesn’t tell you anything until the game is over and you’ve potentially lost 20 hours of your life.

Help menus & manuals

To a first approximation, nobody reads help menus. As a designer, you absolutely cannot expect people to do it. Hopefully, the pattern is clear enough: the further removed from the game you are, the less enjoyable the learning and less likely someone is to seek out the information. In some sense the help menu is in the game, but you’re definitely not playing while you read it.

Wikis & guides

Abandon hope all ye who enter here. Because if you alt-tabbed over to a wiki, you have indeed given up on all hope of the game teaching you how to play.

Don’t get me wrong. On many occasions, I’ve been grateful for detailed wikis. But that’s really only after the game has hooked me for good. If I try out a new game and get stumped, I’d rather dump it than go read an essay about the difference between Flails and Polearms. Now consider your average steam user who has no idea what a roguelike is and stumbles across one.

Learning through level design

The above techniques are not all bad. If all roguelikes had good tutorials, hints, and tooltips, the genre would be dramatically more welcoming for beginners. I’ve added these things to Golden Krone Hotel and the game has clearly benefited. I have tooltips on every single button and UI element, detailed descriptions, a small hint system, and I developed a pretty neat little tutorial.

Still, I can’t help but feel we could do a lot better.

Let me hand it off to this Sequelitis video, which explains things so much better than I can:

Also check out How I Got My Mom to Play Through Plants vs. Zombies. This video by the designer of PvZ is a masterclass in teaching new concepts to players. The learning curve in PvZ is so damn good that, when development was completed, they completely replaced the Help menu with a joke:

Anyway, the theme of these two videos is that games shouldn’t have separate tutorials. People don’t like to read and they really don’t like to be forced to learn. In my experience, many players would rather struggle for hours not understanding stuff than spend 10 minutes in a boring tutorial.

Instead a game should present the player with a series of challenges with increasing difficulty such that an “aha moment” is inevitable long before the real difficulty comes.

I actually tried this with early versions of Golden Krone Hotel. You would encounter a high level foe in a narrow hallway at the start of every game. The only way to advance was by exploiting the main mechanic, killing vampires with sunlight. It did work as a teaching tool and it made people feel very clever. But it also forced experienced players to waste time whenever they started a new run and it sacrificed part of the procedural generation on the first floor.  I removed this inline tutorial years ago and never thought much about it.

After recently watching the above videos, however, I was desperate to once again incorporate a “blended tutorial” into my game. It’s not an easy goal to accomplish within the context of a roguelike. You don’t want to bore the player by forcing them to repeat the same content again and again. I was stumped until I thought back to the most polished roguelike I’ve ever played and it hit me…


Yet again we have two polar opposite roguelikes, Caves of Qud and Sproggiwood. These wildly different games are in fact made by the same developer, Freehold Games!

Caves of Qud

I love this game so much, but the user interface is a nightmare for beginners. Chalk it up to a short attention span or a lack of patience, but I’ve had a very hard time getting into the game. The help menus are good and a “Ten Things You Should Do When You Start To Play” section is nice, but playing the game itself can be quite bewildering.

When you start up Caves of Qud, this is the sidebar staring you in the face. There’s over a dozen incomprehensible stats. As far as I know, there are no tooltips to explain them. If some of these numbers get big, you’re in real trouble (my favorite being T for Temperature). There’s also a bunch of cryptic symbols on the left. Even words like Verdant confuse me. Qud make Jeremiah feel dumb.

Here’s the Abilities menu. First, recognize that a new player doesn’t even know this is a thing they can get to. Once there, you’ve got to manually bind all of your abilities. Meanwhile, you don’t get a description of exactly how the abilities work. I guess they were explained during character creation, but I often roll a random character and don’t see that.

To be fair, it does seem that Qud’s UI is slowly improving and there’s a lot more coming on the roadmap.


Sproggiwood on the other hand has a beautiful interface.

  • Every possible action you can perform (including wait!) is on screen somewhere
  • A magnifying glass icon lets you examine any of your abilities
  • Despite seeming rather sparse, a good deal of information is represented: the minimap, the duration of the character’s invisibility, XP, and the level/cost of each ability.
  • There are keypress hints on every button (more on this later)

Sproggiwood also has a delightful tutorial. This is how it should be done. Mandatory, but short. Not even labeled a tutorial. Valuable on it’s own and not a slog (the tutorial is very funny).

So Sproggiwood helped me figure out what to do: jam the tutorial right on the start of my game. When the tutorial is over, it jumps straight into the regular game and when the player dies, the next run skips right over the tutorial.

Which is better?

Obviously, it’s easier to make a simpler UI if the game is simpler. It’s easier to reduce Burden of Knowledge if there’s simply less to learn. Sproggiwood fits this description, but so do many of my favorite roguelikes: 868-HACK, Hoplite, and Auro. And to some extent, so does my game.

But my point isn’t to only make simpler games. Caves of Qud, even with all its flaws, seems like the more successful game because of its complex systems. Just check the Steam reviews: 85% positive for Sproggiwood vs 99% positive of Caves of Qud. My point is let’s strive for the best of both worlds. Games as deep as Qud, but as easy to learn as Sprog. That’s not an easy task, not at all. But the payoff could be huge.

If you want to see how well I accomplished my goal of reducing Burden of Knowledge, check out the latest update to Golden Krone Hotel. And join us next time when we talk about Identification systems.


[1] As far as I know, the term Burden of Knowledge was popularized by designers at Riot Games. All in all, that’s pretty hilarious considering League of Legends is a game with about 700 abilities, of which a great portion are indicated by similar glowing/flashing effects.

How I Learned to Stop Worrying and Love Prefabs

The level generation in Golden Krone Hotel has kind of sucked for a while.

For the 7drl version, I wrote a quick and dirty level gen system. It could make connected rooms and hallways, true, but the results were really kludgy looking. Rooms would overlap each other willy nilly. Hallways would be ridiculously long. Sometimes the levels would be much too small. They also tended to be very boxy (due to a very naive sunlight implementation).


Later I swapped in ROT.js map generation algorithms and for a time things seemed rather decent.

There were still a few quirks with the ROT.js maps though. Way too many hallways for one. The hallways often looped in on themselves and players were well aware of it. Dead ends appeared too often. And of course, using a simple level generation algorithm produces a bunch of samey levels.

The last straw was when I took screenshots of each level. At first, I thought the result was pretty cool. But the more I looked at it (and compared to the amazing diversity of maps in DCSS), the more I hated my crappy level generation.

Kind of samey

Prefabs to the rescue.

OK, so it was clear I would need a new level generator. I had been hearing tons of chatter about “prefabs” (hand crafted map components). Josh Ge has a bunch of posts on them and I found this talk by Jim Shepard particularly great.

So maybe the time was right to finally start utilizing them. Hmmm… prefabs sounded cool but damn complicated. How would I design prefabs and how the hell would the algorithm fit them into the rest of a level? Was this huge detour into rewriting a working system even worth it?

Spoilers: it was.

Let’s go over all the benefits that were realized by incorporating prefabs. Then we’ll cover how it works in detail.

It helped massively with the tutorial

Tutorials are sort of a nightmare. You have to plan for every contingency, every single way the player could screw themselves. It’s not impossible to have a procedurally generated tutorial, but I certainly wouldn’t try it. Instead the tutorial is one giant prefab.

Levels are less boring

My main goal was simply to make levels less boring. That was pretty easily achieved by having rooms that extended beyond rectangles: triangles, diamonds, crosses, circles (no worries, rectangle fans, we still got you covered). Even better than generating new room shapes is creating interesting encounters like a monster closet or a room with pits surrounding an item.

Branches actually feel unique

Branches play a very important role in roguelikes: breaking up the monotony of regular floors. To give players a proper break, it’s vital to make branches feel distinct from the regular dungeon and from each other. There are many tools to distinguish branches: monsters, music, floor and wall tiles. I was using all those, but without distinct map styles, branches in Golden Krone Hotel were still feeling too much like palette swaps of regular floors.

Now the Pharmacopoeia has circular chambers. The Greenhouse has flowerbeds and fountains. The Graveyard has a sensible and cool looking entrance to the Mausoleum.

I have a powerful tool for controlling the theme, pacing, and drama

In my favorite roguelikes, branches are more than an extra scoop of content. They each have a central challenge that has to be solved. At the heart of that challenge is usually a special boss monster(s) and a special area to house them. Basically we’re talking about a set piece.

A good example is the Vaults in DCSS. As you climb down to the last level, you find yourself surrounded by dozens of vault guards standing in formation and a bunch of other high level baddies. Sometimes you’ll try to run away, but the staircases will be sealed off. It’s not just cool gameplay. This encounter in Vaults:5 actually makes it feel like you’re in a vault.

Creating such a scenario is much easier with prefabs. They let you precisely control the space (determining tactics), monsters, bosses, and environmental dangers. Even the torch light can be controlled. Here’s some examples of set pieces I’ve created using prefabs (mild spoiler warning by the way):

The boss room in the Mausoleum. It’s wide open, which is dangerous because the boss spawns more vampires. On each corner is a twisting hallway to a room filled with treasure.

The central room in the Gallery. It’s a big, rectangular room with “display cases” on both ends. It’s actually possible for the Gorgon Queen to blast open those cases on accident. Along the perimeter of the room are columns, very useful for breaking line of sight with the boss.

Floor 10. You approach Fane and find him enveloped in darkness. You can have the whole conversation this way, with your character in the light and his in the dark. METAPHOR MAYBE? On both sides of you are torches, which can be lit simultaneously if you desire. Interestingly enough, torches are never generated that close together normally because it creates an ambiguity in which to light. I’m so damn happy with the dramatic flair this scene adds.


One last bonus: mazes are easily generated using a single tiny prefab. And yes, the game will eventually have a maze!


“Text files are nature’s most perfect fruit.” – Jim Shepard (Dungeonmans)

The process

  1. Load prefabs. Each prefab is stored in a plain old text file. Make a connection object for each “*” found, saving its relative location and directional facing.
  2. Generate “auto-rooms”. Since the entire generation is now dependent on prefabs, I generate a bunch of rectangular floors and save them as if they were real prefabs. I’m sure there’s a better way to do it, but this works. Other shapes could be generated this way too, but are more difficult to get right.
  3. Grab the level configuration. With this last release, I finally found all the scattered configuration code and put it into level config files. Super useful!
  4. Pick a starting prefab. The starting prefab will often be the important “set piece” of a branch, though any ordinary prefab can also be picked if none is specified in the configuration.
  5. Place the prefab on the map.
    1. The classic ASCII symbols like #.~> (wall, floor, water, stairs)
    2. ? for “don’t care”. Usually ends up being a wall (the default tile type), but this allows flexibility in overlapping prefabs.
    3. 0-9 can map nicely to 10 values without needing 10 case statements. I reserved these for floor type. For example, in the greenhouse, the default floor is grass, but I also mix in stone walkways and flowerbeds.
  6. Randomly pick a new prefab from the list of prefabs defined in the current level config. And also pick one of the existing prefabs on the map to connect to.
  7. Starting from a random connector, extend a hallway out. First the hallway is made as long as desired and then scaled back incrementally until the prefab fits on the end of it. It’s possible for hallways to be 0 length, if the level config allows for that. If it doesn’t fit, just scrap this hallway/prefab and move on.
  8. Jump back to step 5. Keep going until enough prefabs have been placed on the map or we’re timed out.
  9. Now that all the prefabs are placed, we want to enable more connections to minimize backtracking. There are three types of connections made:
    • Any connector that is flanked on both sides by floor can be made into a floor or door.
    • If two connectors face each other, a hallway can be dug between the two.
    • Two perpendicular connectors can meet through a L-shaped hallway.

A few remnants from the old system still remain. Some of the levels are generated using the old algorithm, just to increase the overall variety. Finally, many levels are expanded by randomly placing down rooms over the existing ones in order to make the levels more open (and more dangerous).

All in all, the minimap is looking quite different these days.

7 Reasons Save Systems Are Garbage

I like making small games. I’ve never even thought about a save system and no one has ever asked for one.

But Golden Krone Hotel is getting bigger than other things I’ve made. I’ve been surprised by how long some runs take players. It only takes me an hour to beat the game (and usually 10 minutes to die a horrible death), but some players were reporting 5 hour runs. Lots of people were asking about saves.

Sure, let’s write a save system. How hard can it be?

1) It seems easy, but it ain’t

Find all the state in your program, save it, and then reload it again. Seems easy. But if you try to do this late into a project as an afterthought (as I did), you’ll almost certainly forget how much state is actually in your program.

That’s because the better you get at writing encapsulated code, the more you’ll shelter yourself from the complexity horrors lurking inside each abstraction. You’ll forget about how much stuff is going on behind the scenes and how tedious it would be to track all of it down.

But track it down you must. Writing a save system is like getting a take home exam that requires a perfect score to pass.  If you load one thing incorrectly, your game will malfunction in subtle ways or, if you’re luckier, crash spectacularly.

2) It’s coupled to every part of your game

By definition, the save system has to have its fingers in all your program’s many pies. The only exception is temporary state that can be easily reloaded. For certain types of games, that may be a pretty big exception: think of Super Mario Bros. where only a few numbers needed to be saved (current level, number of lives, etc.).

For a roguelike with permanent levels, however, there’s a lot of stuff. My game has roughly 15 levels with 40×40 tile maps. That’s 24,000 tiles, not to mention:

  • Monsters
  • Items
  • Learned spells
  • Learned abilities
  • Potions
  • Status effects
  • Player stats

Floors in Golden Krone Hotel

Every level currently in Golden Krone Hotel

It’s easy to get tight coupling between the save system and all those different modules, which can make the code very brittle.

Now if you’re smarter than I am, you would think about how to centralize all your state at the beginning of your project. Josh Ge describes such a method and it sounds pretty great (though I’m still thinking about it would be properly implemented in a language like JavaScript):

All objects are stored in allocated memory pools and accessed via handle/ID (in other words, I don’t use pointers), so when you save the game, regardless of how many references there are to objects, all you have to do is save the memory pools and reload them when starting up again–bingo any references are still intact, cyclical ones and all. (I’ve got plenty of cyclical references and don’t have to worry about them getting out of whack.) It’s a really powerful idiom; learned it from one of the old Gems books.

On the bright side, revisiting almost every line of my project helped me clean up a lot of dead code. 😑

3) Debugging it is a nightmare

Halfway through this save endeavor, I realized it would be much easier to save parts of my game by recursively visiting objects and their properties.

Save functionThe bulk of the work is done by this one function

Automating that work was a big win, but it makes debugging pretty awful. I would regularly crash the browser (having never received a useful error message, I’m guessing it was through many a stack overflow).

Some bugs were hard to reproduce too. One required multiple save/loads before showing up. Others only arose when interacting with rare in-game items.

4) Circular dependency hell

“Experience keeps a dear school, but fools will learn in no other.” -Benjamin Franklin

Yup, that’s me. I often have a hard time accepting a design pattern until I feel the same pain that instigated the design pattern in the first place. Well, save systems provide the pain.

I’m fond of circular references, despite many people considering it an anti-pattern. A tile needs to know what monster is standing on it and a monster needs to know what tile it is standing on. So what? Well here are two big problems.

First, if you recursively visit an object/array and all its descendant properties (and some of those properties are circular) you are guarandamnteed to get stuck in an infinite loop. You can bail out of such recursion by keeping track of which objects you’ve visited, but then you skip saving certain things. The essence of the problem is that pointers just can’t get serialized and deserialized.

Again, this would be solved by Ge’s solution described earlier. What I came up with is also a handle system, just one that’s constructed on the fly solely for the purpose of saving. Whenever I encounter an object, I store it in a map. If I encounter a direct reference to that object again, I replace that with an indirect reference to the object map instead.

The second issue is rebuilding the objects. Going through this process helped me understand a lot about dependency injection. The problem is summarized quite simply:

Foo(Bar b){
    //do stuff

Bar(Foo f){

I can’t construct either of these objects before the other. There’s no way to square this circle.

The answer is to create separate functions that do the work of the constructor and can take in circular dependencies (it’s fine as long as we’ve first constructed the objects). I name these methods finishWiring and during loading it’s easy to find out which objects still need to be wired up.

5) Fast, good, cheap. Pick any NaN

Several painful trade offs are involved in a save system. I started out with saves about 30MB each, which seemed pretty high.

I was able to get the saves down to 7MB through a few optimizations, but like any other optimization, it caused readability to go down. Save files got down to just 300KB after compression. That’s definitely a number I can live with, but compression (I used this LZW library) takes a few additional seconds and that sucks.

6) It can make your code worse

Several of my optimizations produced some rather ugly code as a byproduct:

  • I had to mark temp variables that I wanted to totally avoid saving. I did this by preprending variable names with an underscore.
  • I removed default values of variables when those defaults were 0, false, or null. Fewer variables on each object means fewer things to save, but much more confusion.
  • When creating my object maps during saving, I compressed the property names of all objects using base 62 (using a-z/A-Z/0-9 as digits). It saved a good bit of space, but made debugging much harder.

I’m also considering generating levels on the fly so that early saves are tiny, but that will introduce more complexities to the level generation.

7) You’ll wonder if it’s even worth it

In the depths of debugging this mess, I often questioned if this was really worthwhile. These thoughts popped up regularly: How hard is it to just leave the window open? Is it really such a burden to carve out an hour to play the game?

It’s hard to maintain motivation in such times. I could just scrap the whole thing and pretend like it’s not a big deal.

But then I thought about a discussion I once had with a developer at a conference. He was asked by his players to introduce saves and he refused. He almost seemed offended that they would ask and gave all sorts of weak justifications against it. Thinking about how I play games and about my response at the time (“is that really rational… or is it sour grapes?”) made me realize that saving is something players deserve, even if it’s a huge pain.

Feel free to tell me about how much you love writing save systems in the comments. And if you want to see how my system turned out, check out the latest update to Golden Krone Hotel.

Making a Title Screen

Golden Krone Hotel is nearing release on Early Access and it’s gonna need an honest-to-goodness title screen. I think I’ve come up with something pretty cool, so here’s a post showing how it was done.


click to embiggen

I’m often overwhelmed when I see big pixel art pieces. I hope breaking it down step by step makes it seem a little less intimidating. The thing about pixel art is it’s very procedural. Much of the work behind making pixel art is just following a series of simple procedures (proper outlining, anti-aliasing, shading, etc.) I don’t consider myself an artist in the slightest, but I’m usually able to get some OK results by just following the right steps and having some patience.

A little context

During game jams, I typically just slap some stylized text on a plain background. Here’s Golden Krone Hotel’s old title screen:gkh-original

I’m happy with the creepiness factor (all accomplished with a little CSS magic), but it’s otherwise pretty  boring. I needed something that establishes the setting, theme, and style of the game all at once. Dumping text on the screen doesn’t do that.

I got slightly more elaborate during the Greenlight campaign:


Obviously, I made that rather quickly. It is closer to the end goal. Let’s be honest, I’m basically trying to evoke thoughts of “Dracula’s castle.” This image establishes the theme and setting (a creepy tower), but it doesn’t look very professional.

I decided to follow the same idea going forward but with the the whole thing completed fleshed out. No silhouettes. No MS Paint moon. I wanted to leave room for animating it all, so I knew the following layers were needed:

  • Background
  • Clouds
  • Moon
  • Mountains (multiple layers)
  • Cliffs and path
  • Castle
  • Logo

A lot of work, but I slowly chipped away at it over several weeks.

Putting in constraints

First things first. At the beginning, it’s a good idea to decide on the resolution of the final piece. I looked up the display resolution of SNES and arrived at 256×224 (which I later expanded to 400×224 to match wide screens). It’s not that I consider my game to be “retro”, but people will often label any 2D pixel art game retro anyway. Why fight it? Besides, constraints are super helpful. That’s already about 90,000 pixels, each of which I have to make a conscious decision about. If I tried to draw a piece at the resolution of my monitor, 1920×1080, now we’re talking 2,000,000 pixels.

Also a note on colors. I’ve been using two techniques recently for picking colors and I’m loving the output.

The first is blending between two colors.

The second is manually shifting the hue (towards either yellow or purple) and saturation as you change the lightness of your color scale.

Humble beginnings

Besides a few scribbles of the basic shapes (mostly fitting into a big ass triangle), here’s the first thing I drew:



I outlined the major shapes of the hotel, which has also functioned as a cathedral and a castle in the game’s backstory. My goal was to demonstrate the height of the hotel and to simultaneously make it feel sprawling (so there is plenty of room for many floors and branches). There’s a bit of symmetry but I also wanted to break that up.

The sketch didn’t look amazing, but at least I had a nice method for coloring the stones of the castle: creating a bunch of 4px tall stones, trying to avoid them looking too perfectly rectangular, and adding a tiny bit of highlight here and there. Adding some occasional darker shadows in the cracks between stones gave it some more depth.

Here’s the castle after continuing the stones and adding an elaborate stained glass facade:


One of the hardest parts was settling on a method for detailing the roofs. Sometimes pixel art is just trial and error until something looks right. I tried all sorts of diagonal roof tiling, but it kept looking awful. I settled on a simple horizontal tiling with alternating dark/light lines.



And here’s the final version. I added a few details such as a sloped wall, a portcullis, statues, and stairs. I also added a second background tower on the right to give the whole place more depth and really tiny doorways to try to establish the scale. Otherwise, it was just a tedious process of filling in the remaining stones and roofs using the same procedure I had already figured out.finished-castle

At this point, I decided to sketch out the rest of the piece. I wanted a giant, clearly unrealistic moon.


Then it was onto finishing the mountains. The back 2 layers aren’t that complicated. The farthest has a single color and the middle one only has two. The foreground mountains are a little more detailed.

The home stretch


I’ve never been really great at mountains. I found this image really helpful to use as a reference though. I chose the light source to come from the left (which maybe sort of makes sense with the off center moon?). Basically, that means a bunch of little pyramid shapes that are mostly lit only on their left sides. The shapes obscure each other and have their own little cracks and details. The right side of each peak is mostly left with the darkest color and almost no detail. That was a little hard to live with at first, but those big open areas of solid color work really well.


These cliffs were really challenging! The process boils down to drawing little vertical protrusions/ridges that stick out from the bottom of each cliff. As I finished off the cliffs (and started looking at reference photos), I also tried jamming a bunch of almost-square rocks together and that worked great. As you look further down the cliffs, they start to lose the highlights and the shadows dominate until it’s a solid color just like the mountains.


Even with clouds, the sky was going to need a bit of detail. A few years ago I would have tried a big gradient but that that can look really bad. I looked at a few pixel art works that depicted night skies and noticed a recurring pattern: layered, bubbly clouds with very low contrast between each layer. If you’re not looking for it, it’s difficult to see these details in the final piece. Yet they’re truly necessary.


Moon time. It was obviously helpful to look at photographs of the moon. I noticed a few details:

  • Huge dark splotches
  • Lots of craters big and small
  • Lighter starburst patterns


Humans are pretty bad at generating random patterns. I didn’t think I could do those dark splotches justice. Thus, I turned to a nifty feature found in most graphic programs: difference clouds.


Besides the features described earlier, I also shaded the moon and added dithering between some colors. Gray was only a starting point by the way. Colorizing an image in tools like GIMP is really easy. I tried out blue, purple, silver, and even blood red. A bright yellow, almost washed out, ended up looking the best.


I was not looking forward to drawing clouds at all. Clouds are weird.

I had to study a lot of reference images to figure out what was going on. And it’s surprisingly hard to find good photos of clouds at night. Finally, I realized something important about shading clouds. When the sun/moon is directly behind the clouds, they don’t have highlights around the edges because that’s the direction of the light source. They look brightest there because the clouds are thinnest there. So that’s logic I tried to use. I initially had highlights on the bottom of each cloud too, but I removed them so that overlapping clouds would blend together better.


Final touches

I certainly needed to come up with a cool logo. Since Dracula is set in the late 19th century, I googled for “19th century signs” (I have absolutely no idea if any of these are actually signs made in the 19th century):


Anyway, one thing most of these signs have in common is curved text. I drew curved guides and lined up the text to fit them. Then, the “Hotel” fit nicely in the pocket below the rest of the text. There was still the work of manually adjusting the features of each letter to line up flush with the guides, but I was able to do that with the pen tool.


I thought about making detailed gold lettering (like the Shovel Knight title screen), but fuck it. I was getting a bit lazy at this point and, anyway, doesn’t the Street Fighter II logo look awesome? So I put a orange-yellow gradient on it, a black outline, and a prominent shadow for readability. Done.


The last step was animating everything. I’m not sure if it’s clear or not, but the idea is that we initially see a timelapse (the moon rises and the clouds move fast) while the camera approaches the hotel. I wrote a little code to randomly place the clouds and move them across the screen at different speeds. I wrote a little more code to move everything into its final position. All of it was pretty simple.

The art is scaled in integer multiples (e.g. 2x, 3x, never 2.5x) to maintain the crisp edges. Depending on your aspect ratio, either the top/bottom or left/right edges of the screen can get cut off, especially if that ratio diverges far from 16:9. However, there’s never any black bars or other such nonsense.

So there you have it. I hope that’s helpful for somebody. Let me know what you think in the comments.


Project Update and Conversation Display

I haven’t updated the blog in a while, but don’t worry! I have been quietly plugging away at the game.

Since my last post, I’ve rounded out the spells and potions (for a total of 20 spells and 40 potions). I’ve added a revolver, shops, chests, water, noise, damage indicators, and a boatload of other features I honestly can’t even remember.

I did experience some slowdown around 7drl. In case you missed, I made a pretty crazy game about time travel called The Only Shadow That the Desert Knows. I also wrote a blog post about it (on my other blog) and it hit the #3 top post of all time on /r/roguelikedev. 😀

Nearing the finish line

To add some more transparency to the development, I’ve created a list of public milestones.

As you can see, I only have a few more things before I want to release on Steam Early Access. Mainly they have to do with polishing up the remaining parts of the UI. And of course, doing a ton of balancing and testing. If you’re interested in playtesting, let me know!

This week I’m working on conversation display.


Right now, you can talk to any vampire or human in the game (provided you’re the same form at the time). The implementation of the dialogue has not been great though. Lines of dialogue got dumped into the message log and most people ignored it.

So I decided to make conversations more prominent and to give them that cool typewriter effect you see in old RPGs.

There are a few steps to achieving the typewriter effect.

Streaming characters

Obviously, the characters come out one at a time. That’s easy. The hard part is preventing weird line break behavior (visible in the video below). Words at the end of the line often jump to the next line as they run out of space. If only we could give words the same width even before they’re fully revealed. Luckily, that is easily achieved by displaying the yet-to-be-displayed characters as non-breaking spaces. Yup, it’s our old friend:


Note that this method is only guaranteed to work with monospaced fonts.


I create the shortest sounds I could on Bfxr. At first I thought multiple noises would be needed, but one seemed to work the best.

When to play the beeps? One option is to play on every character, or at least every non-space character. That seems to be the approach in this video. What I did instead was only issue a beep when the ascii code of a character is odd. The end result achieves several things:

  • Reduces the rate of beeps to avoid them all bleeding together
  • Avoids beeps on whitespace for free (ascii code: 32), which makes sense
  • Gives text a rhythm that is analogous to actual speech
  • Produces deterministic patterns of beeps, so repeatedly viewing a line gives the same rhythm

The effect is pretty damn cool if I may so myself.


Tightening up the Graphics on Dungeon Floor 3

This post is about how I improved the graphical features in a simple HTML5 game. I did so by, among other things, adding a 2.5D perspective. But more importantly it’s about how I optimized the performance of said graphics. If you’ve ever written a 2.5D game engine, you probably know exactly how to do this. If not, read on!


Last year, I entered the Seven Day Roguelike challenge with Golden Krone Hotel, a game about killing vampires with sunlight. It was well received, despite being completely 2D and having lo-fi pixel art and no animation. What can I say? The roguelike community doesn’t expect much when it comes to visuals.


This year, I decided to turn Golden Krone Hotel into a polished, commercial game. To appeal to a wider audience (one not content with ASCII graphics), I felt that the following features were needed:

  • 2.5D perspective. Game objects that can obscure other objects behind them, producing an illusion of depth. Tall entities (e.g. big monsters)  to emphasize the depth.
  • Smooth movement between tiles
  • Animated torches and spells
  • Previously seen tiles, which appear desaturated (common in roguelikes but I didn’t have it originally)
  • Increased visibility radius and fullscreen display

To reiterate, Golden Krone Hotel is an HTML5 game. It runs in JavaScript and is rendered in the canvas, which is known for being…. well, not as fast as one would like. To make matters worse, I’m distributing the game with a library called NW.js. For reasons I don’t quite understand, executables that come out of NW.js take a noticeable performance penalty compared to the same app running in Chrome. Ouch.

HTML5 nw

In 2014, this was no problem. That version was very easy to render. I only had 121 tiles on screen and they only needed to be rendered when the player moved.

The 2015 version was much more complex and slooow. I now had to render over 3 times as many tiles. I also needed to do it 60 times per second. To make matters worse, I was relying on some costly composite modes. Even on my gaming desktop, the performance wasn’t great and I knew it’d be much worse on older computers.

First let’s talk about how the new features work.


The primary thing required for 2.5D is to render your objects in order from back to front (top of screen to bottom of screen). Not a big deal, right? Then things get dicey. You can’t just draw all of your floor/wall tiles and then draw all of your monsters on top. That wouldn’t allow walls to be in front of monsters, defeating the purpose of 2.5D. Instead you must group objects (walls, monsters, spells) into rows and draw the rows in order.

A single row

Smooth Movement

It sounds easy on paper. When a monster moves to a tile, you assign them to the new tile, but you also draw them with a corresponding (x,y) offset. For example, moving 1 tile to the right produces a (-1,0) offset. Decaying the offsets to 0 automatically slides the monster around.


  • The player’s offset needs to be added to the camera itself, so the camera isn’t jerky.
  • In the naive approach, monsters going around corners appear to take diagonal shortcuts. To fix that, you’ll need arrays of offsets that decay one at a time.
  • When you add in the 2.5D perspective, you can no longer draw a monster in the row where it ends up. When I tried it initially, monsters moving vertically would get hidden behind floor tiles. Woops! The solution is find the maximum Y coordinate a monster reaches in an animation and draw in that row instead.

The root of all evil


I went as long as possible without obsessing over performance, but at some point I realized I simply can’t ship a game this slow. Tuning the performance of my game was a slow process filled with confusion, frustration, and self doubt. But I’m happy with the end result and I learned some things along the way:

  1. Always determine where you need optimizations. It’s too easy to focus on the wrong parts, the parts that will never help you. See: Amdahl’s Law
  2. Always verify that your optimization worked. It feels good to come up with some clever trick and move on, but sometimes you’ve actually made the program slower.
  3. Remember that optimizations are tradeoffs. You lose debuggability, readability, and valuable development time. You damn well better get something good in return.
  4. Small mistakes (like forgetting to swap out some test code), can totally murder you. This happened to be me several times. It’s hard to detect without profiling because the program still behaves correctly.

To summarize: Never make assumptions. Profile, profile, profile.

The quickest way to profile is to use in-browser tools like Chrome’s profile tab. However, it can be difficult to interpret the results. When that fails you, you can get a better picture by writing your own profiling code. is pretty great for this.

Onto the optimizations:

Separate rendering into two buckets: animation and turn

Objects that are animated need to be rendered every frame. Objects that only change when the player takes a turn, such as the minimap, only need to be updated once per turn. Maybe the distinction is completely obvious, but it took me a while to conceptualize it and then hunt down all the bits that were being rendered too frequently. This separation is the single most important performance enhancement that I made.


Tiles don’t change during turns, but they do move every frame while the player’s position is being animated. The solution is to drawn them onto a buffer (i.e. an off-DOM canvas element) and just move the buffer around as needed. Besides the main buffer, there also needs to be buffers dedicated to previously seen tiles (one per level). And as mentioned earlier, both of these need to be split up into rows.

Tile caching

There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton

Over the years, I’ve noticed that caching is used absolutely everywhere to make things fast. Unfortunately, caching can be complex and can cause all sorts of weird behavior. Computer thrashing? Web app not functioning properly? App icons missing? Maybe blame caching. It’s an interesting thought experiment: if computers and networks were infinitely fast, computer programs wouldn’t just be faster; they’d also be much simpler to write and more reliable.

So it goes without saying this solution was a bit painful.


The motivation here is that rendering a tile requires several expensive draw operations, yet most tiles look alike. I save each fully drawn tile (again: a canvas element) to a plain old JavaScript object and I give it a key based on its properties. This works, but is indeed very tricky.

Scale the canvas instead of images drawn onto the canvas

Well, I sure do feel stupid about this one. Golden Krone Hotel uses small tiles, 16×16 pixels, which are typically scaled up 300%. The smart way to accomplish the scaling is to draw everything at 1X and then scale the canvas through CSS. The dumb way (what I did at first) is to scale while drawing to the canvas. This is actually much more complex. It resulted in some nasty bugs whenever the player resized the window because now I had all these improperly sized canvas elements sitting around.

Why did I do it the hard way to start? Well, for decades there has been no good way to tell browsers to use nearest neighbor scaling on pixel art; this is absolutely hilarious considering both how widespread pixel art games are and how dead simple the nearest neighbor algorithm actually is.

2015 and this is still a problem


So I used canvas property imageSmoothingEnabled = false to get crisp pixels on canvas draws. Now, I’ve decided to switch over to the CSS property image-rendering: pixelated. Of course, It still doesn’t work in all browsers and it only showed up in Chrome this year, but that’s good enough for me.


In the new version, I added neat looking fog of war, but it was quite slow. I tried to optimize by making fog buffers. I was ripping my hair out trying to figure out a way to update a buffer without redrawing the whole thing. Fog tiles overlapped, so for each piece of fog removed, I had to redraw all its neighbors.

Fuck my life

I finally got it working, but then realized the buffers actually made things worse, since each buffer was the size of an entire level and the fog was animated as well. The buffers were so huge that they would make my entire app crash on startup. So I cut fog out entirely and I don’t miss it. Now I get these creepy vampire eyes instead.


No rendering in steady state

When the player idles for a while, the only objects still animating are torches (at 10 frames per second). Someone suggested that rendering only at 10fps during those times would save on laptop battery life. It’s a great idea, so I did it.


I’d seen some indications that using WebGL might improve performance. I decided to use PIXI.js to utilize WebGL. The cool thing about PIXI is it auto detects WebGL support and falls back to canvas rendering when not available. The requirement to run a local web server was a bit of a pain though. I’m no stranger to running local servers, but I really appreciate the simplicity of popping open an index.html file and having things just work.

I also spent several days freaking out over how PIXI and NW would interact before realizing it would work fine out of the box.


Golden Krone Hotel has a performance issue that most roguelikes don’t have: dynamic lighting. Torches, spells, monsters, and rays of sunlight each produce their own light. Each light source can visit up to 400 tiles while distributing its influence. This occurs every turn and when the player rests, I have to simulate 50 turns at once. So in order to appear snappy, the game has to perform a few 100,000 tile visits/calculations in a split second. Achieving that seemed hopeless.


Failed solution #1: precalculate the influences of each light on each tile and then add them together. Sounds nice, but when you do the math it’s roughly the same number of calculations.

Failed solution #2: don’t simulate light sources that the player can’t see. Doesn’t really help because the player can see light from torches as far as 20 tiles away. If you have to calculate everything in a 20 tile radius, well, that’s nearly the whole map.

Failed solution #3: memoizing distance calculations. I thought 3 exponential calls would be slower than performing an array or object property lookup. I was wrong.

After many weeks of handwringing, the solution popped into my head: only calculate the differences between turns! I keep track of all current light sources, all previous ones, and the differences. If a light is missing from the previous list, I add its influence to tiles. If it’s missing from the current list, I subtract. I have to reset lighting whenever a door is opened, but beyond that it’s pretty simple code. I couldn’t believe how effective this change was. It took the average rest time from 1s to 100ms.


I made significant improvements in the performance of Golden Krone Hotel, but if I’m being honest here, some of the approaches just didn’t pan out. WebGL rendering and tile caching in particular resulted in little or no improvement. Tile caching appeared to be a winner early on, but that was before other changes superceded it.


One of my inspirations for shooting for a commercial release was Lost Decade Games, makers of A Wizard’s Lizard. These two guys have built a reputation on creating a surprisingly successful HTML5 game. They even have a regular podcast, which I would listen to every week. I’d smile and then cringe when I heard the cheesy opening which included a reference to the “arcane arts of HTML5.” One day I turned on the podcast and the opening which they had been using for 100+ episodes had changed. No mention of HTML5. They were switching to Unity because of performance reasons. Sad face.

Would I recommend HTML5 and NW.js for shipping games? If you already know JavaScript, sure, it’s a good option. But if it the game is at all complex, be ready to optimize.

If you enjoyed this post, why not check out Golden Krone Hotel on Steam Greenlight?