Thursday, July 5, 2012

Episode 40: Designing for Non-Roguelikers

Welcome to Roguelike Radio episode 40. This week we talk about Designing for Non-Roguelikers, based on some recent discussion on RGRD. Talking this ep are Andrew Doull and Darren Grey.

You can download the mp3 of the podcast, play it in the embedded player below, or you can follow us on iTunes.

Topics discussed in this episode include:
- Darren's blog post and the RGRD discussion (inc much debate
- The horrible experience of watching non-roguelikers try to play your game
- 4-way vs 8-way, and the design considerations that come with the decision
- Darren's love of hex
- Stairs as bump-to-activate
- Contextual support
- Balancing coding time between UI and features

Tune in next week for discussion of Score Systems. Also many thanks go out to Ryan Boyd for editing this episode - Ryan will now be joining us as audio editor for the show, hopefully resulting in a leap of quality and faster releases!


  1. Just to note, I would really *really* like to see some extra ideas to add to the ones already suggested, instead of just debate over the existing ones :P

  2. I imagine you are thinking of suggestions that are beyond the obvious? By which I mean: To appeal to non-roguelike gamers you'll need the following 3 things.

    1. Graphics and Minimum animation (see Cardinal Quest for bumpy little animation that works well).
    2. Sound and Music.
    3. A totally mouse driven interface.

    Games like Brogue have #3, but the only games that have seemed to appeal to the wider audience have had all three. I'm thinking Cardinal and Dredmor here mostly.

    But then there is Dwarf Fortress. Don't ask me to analyze where in the hell that monster fits in to the scheme of things. That game blows holes in any simple (useful) model I can concoct.

    ToME and mods of Nethack have these things as well. Has ToME gone mainstream you think? Should we be looking to it as a good example?

  3. I'd like to apologise for the very last minute and under prepared nature of this episode. We had to come up with a topic on the spot, when my scheduling of the planned topic (which will be the next one) fell apart.

  4. First of all I'd like to thank Darren for unintentionally providing me with the mental image of Buckminster Fuller as the star of 80's sci-fi show Buck Fuller in the 25th Century, which made me spit coffee accross my desk.

    Regarding 4-way vs 8-way: personally I much prefer the 'feel' of 4-way movement but I think that 8-way movement is one way (though not the only way) of adding greater tactical depth. However I think that both (and indeed, grid movement in general) are really just symptoms of the major thing which I suspect throws off new roguelike players. That being: the fact that roguelikes are turn-based, which is pretty much unique to the genre for single-player, single-character dungeon-crawler games. Certainly there are other genres which use turns, but usually in a very different way - the discrete time steps are much larger, for example - and so use game mechanics and a control paradigm which are actually pretty different. So, I think for roguelikes you need to get into a headspace that is wedged somewhere in-between-and slightly-off-to-one-side-of those required for 'normal' realtime and turn-based games. If you can get a player there they will probably be able to overcome whatever UI atrocity you're trying to inflict on them, but I think most of us devs (being totally used to it) underestimate how difficult that can be for new players.

    I think there's a slightly separate question as to how you get non-roguelikers to even look at your game in the first place and I'll be buggered if I know the answer to that one, but I rather suspect that ASCII doesn't really help there. For all of the supposed benefits of ASCII it's rather strange how every other genre of games in the entire universe switched to using actual pictures of things the second the technology became available.

    1. Even Rogue switched to tiles as soon as it became an option, so it's only us strange spawns that have limpeted to ASCII.

    2. Besides tradition there is a very good reason for ASCII. None of which have anything to do with mainstreaming a game.

      First and foremost it's easy to do, facilitating single developer games. Next it expands exponentially the ease of creating a massive monster/item list. Lastly it lets the player imagine the objects, tapping into the creative mind of the player.

      When you find yourself going "oh fuck oh fuck" when the red 'D' shows up you know exactly what I'm saying.

    3. I totally accept that there are development advantages to ASCII (although with practice I find I can knock out a new 32x32 tile in about 10-20 minutes, so it's not a massive overhead and it makes a nice little head-clearing break from programming), but I'm not so sure I buy the gameplay ones. Personally, when I'm playing an ASCII game I'm not thinking "oh fuck, it's a red dragon!" I'm thinking "oh no, it's a red D". If there are engagement advantages I suspect they only kick in once you've been playing for so long that you've completely internalised the symbology of the entire monster list. Possibly I'm just creatively stunted, though!

  5. Hey nice new website, me like!

  6. Just to nit pick you example Andrew:

    Cardinal Quest has since fixed that problem in several ways:

    1. the healing spell recharges with xp not with turns passed.
    2. if you spend more than a few turns not uncovering previously unseen tiles and/or with a monster in sight a new 0 xp monster will spawn nearby.

    1. You know I was wondering about that Ido. I figured you had a 'hurry up' baddie but wasn't positive.

      The whole 'infinite loop' issue with 4 way movement may be largely overblown. When is there ever just one baddie, with the exact same speed and move choices as the character, who only does melee?

      And here I thought i wasn't going to engage in the 4 way debate. Lol.

    2. Right, I think it's basically just a possible pitfall, and one that is fairly straight forward to find game - design fixes for.

    3. Ido: I hate to nitpick your nitpick, but I was careful/lucky enough to be using the past tense when I was talking about Cardinal Quest ;)

      Thanks for the clarification.

    4. You guys have discussed 'hurry up' mechanisms a lot on RLR. Food clocks, ghosts, etc. All of these, if implemented properly, are effective at reducing/eliminating scummy behaviours like pillar dancing and grinding. However, one thing that hasn't been talked about much is the negative consequences of such mechanisms.

      How does one implement a food system in a game with non-linear branching dungeons? Backtracking seems to be incompatible with food clocks. Sure, you could argue that backtracking itself is a design flaw but I don't see any way around it if you want a non-linear dungeon. That is, unless you make your dungeon a directed acyclic graph. That may be an interesting idea to explore in future games!

    5. Just a thought. You could have food sources be more realistic to allow for backtracking. The easy one is eating monsters, which crawl has. But crawl also has random fruit lying on the ground and loaves of bread. You could replace random "loot" food with actual plant life. So instead of only seeing an apple once, perhaps there is an apple tree that you can harvest from every so many turns, with a long enough period in between so you cannot sit by it, but can grab from it again on your way back.

    6. Crawl does it and it fails at its purpose. The point of a food clock is to keep the player moving forward. If the player can find ways of harvesting/hoarding food without leaving the area, the system fails. If there is more than enough food for the player to skip some and backtrack to it, the system fails. A proper food clock gives you only enough food to continue moving forward (with a small amount of wiggle room).

      Brogue has a working food clock. The only way to keep getting more food is to continue downward into the dungeon. If you hang around you are guaranteed to starve. This is fine in Brogue because there are no branches so backtracking is unnecessary.

  7. Regarding early deaths. You need to start the game off hard and challenging or it won't be interesting. In a genre rife with restarts, being able to windshield the first couple of levels can be a flaw.

    I like what Frozen Depths does. Advanced players can skip ahead. I find this a more than acceptable work around. The beginning is a tutorial but not actually listed as such.

  8. I think your comment about inventory is under-emphasized. Lots of roguelikes use inventory management as a key game mechanic forcing you to decide what is most important to you. It's not a fun mechanic and forces lots of complicated interactions that take the player out of what feels important to the game. If you can design the game without inventory management, I think you end up with a much more approachable game.

    I've got a few to add. These are more extreme, and I certainly don't mean to imply all roguelikes should do this, but I think doing them helps clarify things for non-roguelikers:

    1. Ditch the verb-object interface.
    Roguelikes are the only genre of games I'm aware of that uses this. It's very confusing for new players. Most games act in the opposite order: object-verb. In Shiren the Wanderer, an object may have many verbs associated with it. When you select the object, you are presented with a list of appropriate verbs. You select a verb to act on the object. This interface means objects can't have hidden verbs. However, they can still have hidden properties. In Shiren the Wanderer, a magic pot may cause an effect when an item is placed in it. The user knows that the verb for placing things in the pot exists, but they don't know what the effect of placing a specific item in the pot is.

    2. Give items all exactly one verb
    While driving your item interactions as object-verb rather than verb-object helps, reducing all objects down to a single verb helps even more. It also removes one level of interface between the player and the action they want to perform. It is more similar to what a player expects from an object in most RPGs. There is still a lot of complexity you can derive from single use items. Item to item interaction and item to monster interaction can still hold secret properties. You can reduce ALL your item verb commands down to one single use button.

    3. Pickup or use items upon stepping on them.
    If you can eliminate the need for inventory management in your game, then you can allow players to automatically pick up items when standing on them. This cuts another command out of your list and plays into the "bumping into things to interact with them" premise. Items that are used upon stepping on them (like many of the items in DoomRL) are also great. They add a tactical element of timing when you want to step on the item. They also allow players to draw enemies back to an item so the player can step on it to power up for the fight (much like the big pellets in Pac Man).

    4. Normal (EASY) and Hard difficulty
    This one may be more personal preference, I'm not entirely confident in it. I think AFTER you've made your roguelike, you should go back and attempt to create an easy mode. In this mode, players should feel like they can really dig in (maybe a few floors deep) before meeting their first potential demise. They should be able to beat your game in about 5 attempts. In game, you should name this difficulty NORMAL and you should name the difficulty you designed the game for HARD. Players who are looking for and enjoy a challenge will gladly replay your game on a higher difficulty, whereas players weaker of heart (or who just plain suck at games like I do) still have a way to enjoy a limited version of your game. They'll still have plenty to learn over 5ish sessions and have the opportunity to leave your game on a positive note.

    Alright, after all that, I'm going to shamelessly pimp the roguelike I'm working on because it's goal was to target a less roguelike-savy audience.

    1. I think that inventory management is an important part of roguelikes. Allowing you to just hoard as much stuff as you want rewards grinding, and allows the player to make the game much easier while also making it more monotonous. I do see how it can be off-putting for beginners, but this is where making your game short really helps. If you know you're going to spend 10+ hours with a character, it really sucks having to discard an item that looks useful. But when you expect to be playing a new game with everything reset in 20, 30 minutes then it's not such a big deal. You know you'll have chances to try lots of different things very soon, and the perceived loss of missing the item is much smaller.

      As for other things you said:

      1. Ditch the verb-object interface.
      Roguelikes are not the only genre of games that uses this. Many old-school PC RPGs like Ultima used this, and the adventure genre is filled with them. The reason is because when you're using a keyboard, it allows you to do things much quicker and more smoothly than having to navigate a bunch of menus once you learn all the keys. But it is very difficult for a beginner to learn, and especially bad because roguelikes aren't always consistent on what keys to use for what commands.
      On a side note, I think that once voice recognition technology advances enough we will see verb-object interfaces make a comeback, because they are much better suited for that.

      2. Give items all exactly one verb
      I think if you have a mouse-based interface, two verbs can work (one when you left click, one when you right click), but for the most part I agree. Having lots of different uses for items can be fun for advanced users, but it's too much for a beginner.

      3. Pickup or use items upon stepping on them.
      This one, I'm not so sure of. If you have a mouse-based interface, picking up items by clicking on them is the obvious choice--but you certainly shouldn't be picking up items because you are passing over them to get to another spot you clicked on. And it's a bad idea with keyboard or mouse control. The problem is that while it can streamline picking up items you want, it makes it easy to fall into pack-rat behavior, and it's annoying to autopickup stuff you don't need. Actually, Nethack has this option on by default (doesn't Rogue as well?) but it's usually a good idea to turn it off. Not only because picking up items can sometimes be bad (even fatal!), but because your inventory soon gets cluttered with crap you don't need.

      4. Normal (EASY) and Hard difficulty
      You have to be careful with this, though, because most roguelikes are boring without permadeath. I think that one of the things about permadeath that we want to preserve is that it gives real consequences to your actions. You can't just do something over and over until you get it just right--you have to live with the bad choices you make. So it's important to make sure that there are significant consequences to getting killed, even in easy mode.

      Your roguelike, by the way, does do a good job of streamlining things for beginners from what I've seen. And it looks like you've cut down items to the point where there really is no inventory system, and every object is worth picking up, so autopickup works for you. I don't think there's anythin wrong with your approach, but I do think it's still possible for games more complex than yours to appeal to non-roguelikers.

    2. I agree on a lot of your points. For the Easy mode, I would suggest still using permadeath because I think it's a necessary part of roguelikes, just easing up on the difficulty a bit.

      WRT inventory management, I think you can get a lot of the interesting game mechanic elements without having a limited inventory. To my mind, the most interesting element of a limited inventory is best represented in DoomRL where one of the biggest strategic elements is choosing which items to put in your inventory from the many you find on the floor. But shops present this same choice, and are capable of limiting the player just as much assuming your gold system is well balanced. Also, presenting it as a shop has a more positive psychological angle. Instead of "What am I giving up?" you think "Which will I gain?". The one loss I can see is that a limited inventory compels players to use items and without it a player may be a packrat until he dies. Hopefully if your game mechanics are clear enough, the player will know he can't just store up items without using them and expect to survive.

    3. Rogue uses inventory very well, I think. It has just the right balance of letting you carry around a good number of items, but you have to pick and choose.

      In fact, I think a polished version of Rogue (with attractively animated tiles, a good interface, variable difficulty, and some well-done tutorials) could be a great beginning game for non -roguelikers.

  9. I remember my early days with both Civ and then again with Nethack, and 'discovering' diagonals in each. With Civ I pig-headedly tried to stay with arrows for a while because I'd acclimatised to it. In Nethack it's likely your first antagonist will be a grid bug, which could reenforce a bad assumption. Monsters after that could seem to have an unfair 'special power'. Nasty UI.

    You can do four-way without obvious compromise with a profile approach like fuel, red rogue or spelunky, because you assume gravity.

    So - the problem with arrow-movement from above is the issue of navigating in what Darren calls here as Manhattan distance. Hex suffers from the same problem, it's just watered down. Eight-way has the issue, reduced further.

    I sketched away on graph paper while listening to this, and couldn't find a uniform tiling more accurate eight-way. So I think there's still a lot to recommend about eight-way but it's interesting to be reminded that you've got to get your users on board.

    Some ideas for this:

    * Don't support the arrow keys, at all. When people try to use them, urge them towards the keypad.

    * Actually, don't use the keypad, because it doesn't work on laptops and has numlock complications. Use qweadzxc instead.

    * Put a little game-intro in, and get the user to do something that requires diagonals (e.g. cross a chasm, do a dance, a simple sokoban trick).

    * Make all actions accessible via space bar menu, but have clearly-documented key-bindings in those menus for players who want to use them.

    On graph, I played with some uniform tesselations with fewer options than four-way. The zelda triforce shape can be done with three consistent arrow keys. Yuck. You could have just a line-based roguelike with left and right. Or an 'only forward' roguelike. Like Duke Nukem Forever. Heh.

    Interesting to think that we should avoid distinguishing between the capitalised and uncapitalised versions of keystrokes. I've never thought of that but it's a great idea. Avoids the capslock problem too. I remember a lot of games (e.g. Elite II) where you needed to '-' to decrease something, but shift+'=' to increase it. That's an annoying habit.

    Good episode, thanks guys.

  10. A couple of ideas for doing 8-way movement with just the arrow keys:

    1) Like pretty much every realtime game does - i.e. by combinations of arrow keys to move diagonally. All this would require is a mildly more sophisticated bit of input handling to deal with the fact that it's hard to press two keys exactly simultanously. For example: if a key is tapped then move immediately (i.e. on release). If it is held then wait a fraction of a second to see whether a second key is pressed before moving. Granted, this is not ideal because it introduces a small pause, but in a turn-based game this isn't really all that big a deal and it's better than making the arrow keys effectively redundant anyway. Games with animation, like Cardinal Quest and Dredmor, force you to wait for the movement animation to complete before the next turn anyway, and nobody seems to mind all that much.

    2) Tank-like (or Resident-Evil-like) controls. So, your character has a heading and pressing left or right rotates you by 45 degrees (perhaps at a cost of only half a normal turn) while up and down moves you forwards and back. Needs to have the game designed around it a little more but would be great for games where you have a directional field of vision and predominantly fight with missile weapons.

  11. Regarding traps:

    I've implemented partially visible traps with doling out extra experience points for disarming them blind (and penalties for spamming the disarm option).

    It's turned the traps game into a lot of fun. Searching every few steps isn't optimal any more as you're not getting ahead of the experience curve. You just do it to clean up a level. Generally I find myself treading carefully and looking for dart guns (which you can make visible only with LOS).

    It would be interesting to see how people would implement this in a non side-scroller. I'm sure walls could reveal a dart gun and then you would start searching for the pressure plate - instead of search spam all the time because of fuck-you-invisible-traps.