Archive

Posts Tagged ‘design’

Flood-filling for Procedural Wizardry

December 4th, 2012 Comments off

In case anyone is not a Temple of the Roguelike regular, I highly recommend reading through this thread discussing floodfill applications.  It includes simple code examples, discussions of problems/alternatives, and practical ideas on how it can be used for good content.  All excellent brainfood for anyone looking to use one of the best algorithms in the procedural design toolbox.

Procedural Tips

November 23rd, 2012 1 comment

So there’s a cool article on IndieGames.com now with tips on using proc gen elements in your game.  Maarten Brouwer of procedural platformer Cargo Commander goes into some great details about how to use procedural content beyond just having random elements, but really going into making it balanced and interesting to the player.  Very similar to what I wrote about a few days ago in making the program design the levels, not just randomise them.  Go read the article – it’s got some great insights and practical advice.

A big “but also” I’d add is relating to his first point on not worrying about connectivity.  Worry about connectivity!  Floodfill is a miracle tool that can ensure everything is connected, whilst also being a golden technique for procedurally generating content in interesting ways.  It can be used to make 100% solvable lock-key puzzles for instance.  It can determine the optimum point to place enemies and items, and inform the AI about the right way to behave in that area.  It can detect dead-ends, which can then be removed, looped up, or transformed into something interesting for the player.  Best part about floodfill is it’s quite a simple algorithm at its base, easy for any basic coder to learn.

Some take the attitude that 100% connectivity isn’t important. Personally I think if a human designer would never make such a level, why should an AI designer? There’s no excuses in design faults like this, no matter how much you brush them over. There are a wealth of procedural tools out there to help overcome any design problem, it’s just a matter of using them right.

The Thoughts of a Procedural Level Generator

November 14th, 2012 4 comments

So earlier I blogged about how procedural is so cool and rad, etc, whilst also bemoaning that there’s not enough detailed procedural generators that tie different elements like monster and item placement together.  I’m as guilty of this as anyone else, partly because it’s so much quicker to use simple algorithms, but also I guess because people don’t expect any better.  Well, let’s have a look about how a good dungeon generator might think through the creation of a level:

1. Huh? What? Oh goodness, I oversleep()ed and now I have to crank out a dungeon level. Well, let me think, should I have a theme? Yes! And what should the theme be? It’s deep in a dungeon and there’s not been a forge level yet, so I’ll make one of those, yes? Active forge? Yes. Will there be a dominant monster type? Yes. Population? Orcs. 60% dominance.

2. Okay, let me think openly about the general shape.. .. .. .. .. My, that’s a lot of noise/BSP tree/cellular whatsits! I’ll shape that up here with some heightmaps / room space allocation / edge smoothing / whatever else. Ah, that looks much nicer now! Any extra decorations to shape I want for now? No, it’s good as is.

3. Hmm, better check it all connects together. Got a lovely floodfill for that… And whilst I’m at it I’ll check there are no lengthy dead ends by adding a heightmap to the floodfill and connecting up some of the maxima. Can’t be having our avid adventurers backtracking all the time, after all…

4. Should I have a river? Nah… Lava? Sure! Let’s spill it in the east side, let it burn down some walls, go under this corridor (now a bridge over lava) and carry on south-west. Island in the lava? Okay, and I’ll place a special item there for adventurous types to fawn after. Enemies in the lava? Sure, I’ll throw some fire drakes in. They have a lovely ranged attack they can use on anyone crossing the bridge.

5. Might put a small vault in the north of the level. Keep things connected as it’s placed. What monster type? I’ll follow the orc theme and choose some orc assassins. Artifact reward? Nah. Large gold pile? Sure. Trapped entrance door? But of course…

6. Since it’s a forge I’ll make a large central room into a forge room, with a forge inside and some relevant materials. And an orc weaponsmith, and some goblin slaves. Nearest room will be stockroom. I’ll make it 40% armour, 30% weapons, 30% consumables.  Artifact? Okay, medium grade. And a second low grade too. I should definitely place a guardian here – a nice big troll in fact. Doors to this room are locked – I’ll put the key somewhere else on the level which is definitely accessible from the entrance stairs (ah, floodfill, I love you so).

7. Any other special rooms? An altar in the west will suit. Include some scrolls. And a rabid orc priest. Followers? No, but we’ll give him a pet. Fantastical creature? Sure! We’ll make it a griffon. And I’ll throw in some griffon babies too. Aren’t they cute?!

8. Hmm, there’s a dead-end room in the west.  Any chance of a special item for here? Sure, a special potion. In a trapped chest. Guarded by… mages. Path to the dungeon entrance from here is to the north, so I’ll position them in a defensive formation near the door there, with a healer behind them.

9. Now, in the other rooms we’ll place some orcs and a couple of other creatures, with no more than 2 being higher than base level. We’ll give one of them a wolf pet as well. And in one corridor we’ll put an archer – everyone likes archers in corridors, right?  And a trap there too, but we’ll let the archer know not to trip over that. And we’ll have the archer carry a nice bow and dagger.

10. All done now! As a final touch I shall christen this level “Corpsefire Forge”.  Bon appetit, adventurer!

Looks very involved, yes? Kind of like the thoughts a real designer would go through? But that’s the point really – you want something almost as good as hand-made content, but with on-demand infinite generation and variety.  It needs some coding together and a good pool of input values.  The coding is not so hard as you might think – everything above has been done before to some degree in open source games, so at a push you could copy paste this generator together.  But the hard examples to draw from are a lot more work if you don’t want the same few combinations popping up over an over again.  I guess this is partly why big roguelikes are so popular – the larger content pool allows for greater variety in random encounters.

Some day I’ll make a cool generator like this.  Honest  ;)

Hate Random, Love Procedural

November 14th, 2012 5 comments

As roguelikes and games with roguelike mechanics get more mainstream success I’m seeing a bit of backlash against what is termed “too much randomness”.  I’ve seen a lot of this directed against FTL, but also against The Binding of Isaac and complaints of it in the latest X-COM.  Yahtzee wrote a good article on the topic earlier this year, and Craig Stern recently wrote in great length about the failings of random mechanics.  But I think it’s vital that we distinguish between randomised content and procedural content, as although there is some overlap the end implementation can have very different effects on play.  And for developers it’s important to understand the role of procedural generation, and why it’s not the same as “just random”.

I’ve always hated random mechanics in games.  Missing a weak enemy twice in a row because you got a bad dice roll can really ruin the feeling of a game.  Plus some developers seem to think having the ability to run thousands of dice rolls means they should have insanely complex systems that require intense study on a turn-by-turn basis to assess the probabilities.  If you need Wolfram open to figure out how many attacks on average it takes to kill that monster then likely the battle system is badly designed…

Chaos Plane in ADOM

This is random…

Dice rolls were popularised with D&D, where rolling that d20 and praying for a 17 or higher was part of the tension and the fun.  But a good DM knows that letting the dice rule the game is not so fun overall.  When role-playing you don’t want to be thinking about numbers all the time, and random chance can get in the way of a well-designed campaign.  The essential element of unpredictability should come from the imagination of the players.  However this history of dice in Dungeons and Dragons has made its way into many RPGs, with a lot of fantasy roguelikes in particular using numbers and dice ranges lifted straight from the Player’s Handbook.  Whilst drawing inspiration from their favourite sources they also blindly copied over these poor features.

I don’t want to get too much into why I hate randomness, especially when the two articles linked above go into plenty of detail.  If you’ve played Risk you probably know all the reasons.  Go play Small World instead and you’ll see how much more fun a deterministic system can be.  Feeling in control means you don’t feel cheated by the system, and you properly respect the winner for their skill in attaining victory.  Importantly in single player games a deterministic system means you have only yourself to blame for failure, and you are forced to learn to be a better player instead of blaming the game.  Instead of thinking “I’ll get lucky next time” you think “I’ll make better choices next time”.

I do sometimes use randomness in games though.  It has its place in providing variety, and in also giving the player the option of taking a risk on something.  Usually in my games when an option is open with random chance it’s a high risk, high reward decision; it’s part of my philosophy that power always has strings attached.  But when present it’s usually entirely optional – the default action is the deterministic one – and the chance of failure is made clear.  Another good (or at least acceptable) application of randomness is in providing bonuses instead of failures.  The assassin’s 1 in 4 chance of paralysing an enemy in Dungeons of Dredmor for instance.  You know you can’t rely on it, and you always feel good when it kicks in, yet it doesn’t dominate the play.  But I’m very much against randomness overshadowing the outcome of player choices.

So why do some games make heavy use of randomised results?  To stop them being linear puzzles, predictable from the very get-go.  To prevent you feeling secure in what’s going to happen next.  But this is where procedural content generation comes to the fore.  And it’s important to both consider how it creates content for the player, and for how that content changes over time (AI).

It should be stated loud and clear that procedural does not equal random.  It tends to use a random seed, yes, but it builds upon that intelligently to produce *interesting* content instead of just random content.  A perlin noise map is very different from a procedurally structured forest map populated with enemies, items and quest goals.  Your level generator should be more than just a form of terrain mapping – it should be its own AI, a designer following a ruleset with some random initialisation to produce varied content.  The rules and design it follows should produce intelligent and interesting content for the player that goes far beyond simple random patterns.

Jeff Lait's Smart Kobold

…and this is procedural – Jeff Lait’s ‘Smart Kobold’ with intelligent content arrangement

However if one does procedural content badly then it can degenerate into pseudo-random levels.  Unfortunately a lot of games using procedural techniques use them weakly.  Dungeon generation is separate from monster placement, which is separate from item placement, and monster and items tend to be spread randomly across the level without consideration for the player experience.  This is really not taking full advantage of what a well-designed procedural generator can do.  Of course writing such a generator is far from trivial…

But even poorly implemented procedural content is better than pure random.  It sets limits to ensure the game is completable, that the challenges can be overcome or avoided.  Floodfilling to ensure dungeon connectivity for instance, or restrictions on monster spawning to prevent them appearing next to the player – simple touches that make a big difference, removing the chance of perceived unfairness from the game.  A procedural generator provides a more structured experience, with patterns that the player can come to recognise and take advantage of / game.  It ends up forming part of the game rules that the player is working with and against, an integral part of the play.  And of course there’s the element of surprise – the turning round the corner to find something you haven’t prepared for, and thus having to react to the circumstance in novel ways.  This is different from a string of random misses in a random battle system, as it doesn’t take away any sense of entitlement and still leaves you feeling in control of whatever situation arises.

Procedural over time is another area that’s under-developed.  AI is a big part of this – mobile units that react to the player’s actions and present their own challenges.  These can introduce the complexity of interactions that normally other players add to a game.  Good AI is also tricky, but even simple behavioural patterns can create the components for emergent complexity.  What there really isn’t enough of though is procedural changes in the level over time.  A dungeon that reshapes itself, that reacts to your presence or the movements of enemies, can create an engaging environment to explore and forces you to constantly reassess your tactical surroundings.  A few examples of this are the ice levels in HyperRogue, the sand dungeon in Tales of Maj’Eyal, and the rather crazy dynamic levels in my own UNSTOPPABLE.  There can be more detailed control of content over time, like the famed AI Director in Left4Dead, and I’m hoping we’ll see even more novel stuff in future.

PCG for me has always been about crafting a player experience that is fun, engaging, and of course different every game.  Randomness, on the other hand, I find is rarely fun or engaging, and often ends up feeling very samey over time. One game of snakes and ladders feels very much the same as any other, and if you keep staring at perlin noise maps they quickly lose their novelty.  A really detailed procedural system can not only generate compelling content, it can also react to a player’s actions, crafting a uniquely tailored experience which only that player will ever see.  Achieving that is far far better than a string of natural 20s.

Don’t Ask What, Ask Why

June 20th, 2012 11 comments

As geeky online people we tend to get caught up in definitions a lot. I’ve done it plenty in the past, and will likely get into pointless debates about it in future. But ultimately I do think definitions aren’t very useful, and trying to lay out your own definitions is futile. Definitions are made by communities and groups over time, not by individuals, and tend to mean different things to different people. And they change greatly over time. Arguing over definitions is usually about arguing what to exclude from a particular group, and is ultimately always a negative affair.

Keith Burgun recently made an article on Gamasutra about the need for a definition of “game”. It follows on from a previous article. Both are good thought pieces, but I don’t find them very useful overall. Because I’m not so interested in the Whats, I care more about the Whys.

Why do people play games? Lots of people have different motivations, and some like unique combinations, but there has been a significant amount of research done into this which shows there are some main groups. From my own previous readings and personal thoughts these are:

  • Ludism – The rulesets and logic behind game interactions. On a primitive level this is puzzles, but on a more complex level this is about ambiguous choices. This is what Keith is primarily interested in I feel, and me too – roguelikes are all about these base gameplay interactions, often cutting out all other elements entirely. But many games are very light on ludism, presenting only one choice or making the choice obvious – a problem made by real-time games which rely on reflex rather than choice. If videos games want to have ludic appeal then I think they should look more at board games, which have had tremendous focus on this area of interest for a long time. One of the most important elements of a ludic game is score, as this is a direct reward piece for ludic success. Many games will replace abstract score systems with gold, loot, experience points or other measures of success.
  • Aesthetic – What looks, feels and sounds good. As an entertainment medium games can give us fantastic interactive stimulus that can be engaging all on its own. Something like Proteus is a beautiful example of an almost pure aesthetic game. Note I still call it a game – it has choices and interactivity, but the “reward” for gameplay choices is an aesthetic one, not a ludic one. Aesthetic is a big reason why AAA games are so successful, but the indie games movement has helped push new aesthetic ideas into the foreground, especially in breaking away from the idea that more realistic is better.
  • Narrative – A story, or sense of a story, with progression and change over time. Many play the likes of JRPGs just for the stories, with the interactive nature of the medium helping them feel more immersed. But games needn’t have traditional linear or even character-based narratives. The space for game narratives is very open and unexplored, but there are many obstacles to doing it right. The domination of conflict-based games is one problem, as is the prevalence of linear, single-solution games which don’t push the idea of interactive narrative very well. Plus traditional narrative techniques like dialogue or textual exposition don’t work well in games. Narrative exposition should come from the gameplay itself, and this is where I hope future focus will be.
  • Exploration – The freedom to find new and interesting things is a big motivator for many people to play games, especially those with huge, open worlds like Skyrim. Geographic exploration is one part of this, but there are also things like SpaceChem which appeal to the experimental mind. And it needn’t be epic – check out Small Worlds as a lovely little exploration piece.
  • Creativity – The ability to make and modify to your own ideals. Minecraft is obviously the current king here, but it has been around for a long time in various simulation games. It can scale from small tinkering to mass creation. Creativity is often its own reward in a game, and one can marvel in the results of one’s own making. But in some the act of creation can produce ludic tools or can be tied in with exploration.
  • Social – A vastly expanding element of play, social interaction can be a big motivating reason to play games. Drawsome is almost purely a social game, for instance, and helps push the idea that social interaction needn’t be split into the just competitive or cooperative. Real interaction with real people has its own special appeal, and being able to play with others (especially friends) can change the nature of a game.  Sometimes an otherwise dull game can become much more engaging when you can play with others (see Diablo).

There are probably other reasons people play games, and new areas will be invented in future, and of course in each there are a wealth of different styles that variant groups will prefer. But when designing a game you should know which of these elements you want to appeal to, and to what extent, and how you want to reward these impulses. It’s also important in advertising your game to show where the appeal lies. These are the reasons people will be attracted to your game, and why they’ll keep playing.

Roguelikes, as I said, tend to be about the ludic appeal, with interesting choices dominating the gameplay. Some have elements of narrative, exploration or creativity too, and a few even have nice aesthetics (and I don’t just mean graphics). I’ve not seen a good social roguelike yet, but I’m sure that’ll come in time.

Finally, on the “What vs Why” consideration, I must also rail against the persistent questioning of “What is a Roguelike?” Far more important is “Why is a Roguelike” – why do we play them, and why are they fun? I’ll maybe write about that another time.

Tags: ,

The Autoexplore Rot

June 12th, 2012 11 comments

There’s been some interesting discussion on rgrd about designing for non-roguelikers. Lots of polite disagreement, which is always good for throwing up some interesting ideas :)

In the thread I talked a little about the “rot” of autoexplore, and I’d like to espouse my views a little more. DCSS introduced “autoexplore” a while back – press a hotkey and the game will explore the dungeon for you until something interesting pops up (an item, a monster in sight, different terrain, a trap, etc). This was in response to Crawl’s large and fairly empty levels. The interesting content was so lightly packed that it became boring scouring the dungeon for monsters. The autoexplore function they implemented is in a way a quick hack, but in actual fact the procedure they use is insanely complex. Yet it’s still a hack – it’s sweeping the real problem under the carpet, and automating what should be interesting gameplay.

Your movement and position is of vital importance in a roguelike. How you approach a door in ADOM determines what sorts of trap might be set off. How you you enter a room can decide whether you’re leaving yourself too open to archery, or if you’re giving yourself enough view to use your own ranged attacks. To have the game decide these things for you automatically removes a level of tactical choice and depth from play. And furthermore it takes the whole tension out of exploration, meaning you no longer worry what might be behind the next corner or just beyond your field of view. That tension of the unknown that makes roguelikes so compelling disappears. Instead you end up playing as if in a one way corridor, bashing enemy after enemy without thinking as much about the tactical space or your positioning. The exploration becomes the equivalent of progression through Golden Axe.

Quicktime events are a good comparison for this. They were introduced into mainstream games after people complained that long cutscenes weren’t interactive enough and they didn’t feel like they were playing the game. So companies starting throwing in a basic interaction element to patch things over, without addressing the real issue that cutscenes in games are so out of place – a boring cinematic when we could be having a fun interactive experience! The sad thing is gamers have come to accept this as standard, and to expect it even. The real problem will now never be addressed.

It’s equally saddening when I see certain Crawl players demanding auto-explore in other games, or proclaiming that they can’t enjoy another roguelike because it doesn’t have auto-explore (yes, this really does happen a horrible amount). Their mindless exploration tool has become a crutch they cannot play without. The effort of thinking where to move each turn is suddenly far too overwhelming! ToME4 has now implemented auto-explore as well, instead of focusing on the real problem of the levels being too large without enough density of content. I’m worried that this will become a bad trend.

BORING GAMEPLAY SHOULD NOT BE REPLACED WITH AUTOMATION! I’m not sure if that can be emphasised enough. Tedious gameplay needs addressed at the root. Otherwise why have a game at all? Why not just play a slot machine like Diablo? If there’s an element of the game that the players don’t enjoy then find ways to prune it or change it to make it more interesting.

Some fixes for the auto-explore problem:
– Smaller levels, so there’s less backtracking
– Looping levels with many connections between nodes
– Densely packed monsters
– More varied rooms, dungeon features, vaults
– Linear levels, such as a 80×10 map requiring you to move from the very left to the very right; you still have a procedural environment, but it essentially removes the exploration component instead of automating it
– More variety between levels so dungeons don’t feel samey or predictable
– Higher rate of monster regeneration so you always feel pressured
– Effective food clock or similar “push” to make every turn matter
– Interesting rooms, full of traps or themed monsters or special floor tile effects, so every time you open a door there’s a wealth of possibilities lurking behind
– No maze levels. Seriously, who the hell likes maze levels?!

These are just a few ideas, I’m sure others can think of more. And give some thought to those few poor Crawl players who can’t live without auto-explore any more – they are doomed to never enjoy games again!

Tags:

How to Design for Non-Roguelikers

June 6th, 2012 7 comments

For some this article is irrelevant – they only care about existing Roguelike players touching their games. All fine and well, but I’d like to see more people enjoying all the great games we have around, and in particular I have a goal of making the first truly accessible ASCII game. Er, wish me luck :/

One problem though – the interface. I’ve watched hardcore gamers try out Broken Bottle (which is considered to have a good interface for a Roguelike) and they’ve not been able to figure out how to move, or how to leave the first level. All the assumptions we have about the interface are completely null to them. It’s immensely painful watching someone try to play your game and being so unfamiliar with the controls that they move at a snail’s pace, and have such trouble with even movement that they fail to see the rest of the depth of play.

Well, here’s some points I’ve come to learn about making roguelikes more accessible for non-roguelikers. Most centre around interface, but there are some design considerations too. Feel free to post more in the comments.

4-way movement
Ooh, I can hear the traditionalists grinding their teeth already… But every time I introduce a new person to roguelikes they fail to grasp the ability to move in diagonals. Years of d-pad or arrow key use has made them think purely of the cardinal directions. Also it’s hard to get 8-way movement to work nicely on a laptop, whatever crazy shift+direction scheme you might invent (and don’t even *think* about forcing vi-keys on players). WASD and arrow keys are all outside gamers can cope with. So stick to 4-way, and let the monsters only move 4-way too. It feels weird at first but you’ll get used to it. Just make sure your dungeons are 4-way connected! There are some tactical things to consider around this as well, such as pillar dancing on two squares and creating choke points more easily, but these are design elements that can be overcome.  Similarly you’ll find ranged combat needs nerfing or visual radius reduced to cope.

An alternative is hex, with QWE/ASD for the 6 directions. I’ll be trying this with Rogue Rage, but I’m not sure yet how well it’ll work. But from a technical point of view hex is the ultimate for all games ;)

Mouse control
Easily and quickly move to another part of the map (with appropriate interruptions for damage or spotting a threat), and right-click for contextual menus to quickly choose available interactions with enemies and items. Or right-click could fire a missile weapon. Mouse control makes a game hugely more accessible without hindering the game’s complexity. ToME4 is a complex game that can be comfortably played with either mouse or keyboard, or a combination. Tooltips also help convey detailed information quickly without forcing the player to read through manuals or help files – most players never read help files or manuals.

Gamepad support
Many players like to plug in an X-Box 360 controller. Make sure your game can be played on few enough buttons for this to work. You don’t have to directly support the input device – there are keyboard mapping programs out there for that which gamers know how to use.

Auto stairs use
A stairs should be treated like a wall square you can see through. Enemies can’t walk on it, items can’t drop on it, and once you bump into it you change level. This removes the need for < and > keys (why are they even separate keys?) without removing any tactical depth. Means stairs need space around them (can’t be in corridors) or need to be in-set in the walls (see Dungeons of Dredmor, where stairs use is made obvious to the player), and player should be placed adjacent to the stair tile when put in a new level. Makes a big difference to new players when they don’t even have to think about using the stairs, it’s just natural.  Moving into stairs to use them should be as natural as bumping into doors to open them or moving into monsters to attack them.

No controls requiring shift/ctrl/alt
One reason to get rid of the stairs command… Tell a player to press < and he’ll press the , key, and then wonder why it didn’t work. In a reduced command set there’s no reason to use upper cases or keys on the shift line. Besides, on international keyboards these can be in different places, so might screw up your input in other regions. Stick to simple lower case letters or symbols easily accessible. And don’t over-rely on mnemonics – those who aren’t native English may struggle to understand q for quaff.  Better to have commands grouped together in one part of the keyboard (but at a distance from the movement keys).

Use standard controls from computer RPGs
I for inventory is the big obvious one. C for character is also oft-used. Generally the less you have to use the better, but when you want to use keys think of what are the standards outside the genre as well. H for help is probably more standard than ? for instance. W for Wear will confuse many roguelikers, never mind those with little experience.

Pop-up text hints
Both for interface and for gameplay, though you might want an option to turn it off. Especially at the start of the game you should have some text briefly showing the commands. It could be as easy as arrows around the character showing the move key for each direction as a quick lesson/reminder, or a small bar at the bottom of the screen saying “Arrow keys to move, F to Fire, P to Pick up items, H for Help”. But during gameplay this can be useful too, especially when introducing new features or content. If you don’t have auto-stairs use then walking over the stairs might provide a message “Stairs down to Dungeon level 3, press space to descend”. Similar for walking over items (how to pick up), or when picking up items (how to see inventory or equip). Seasoned players might not even notice these messages when they’re used to seeing them, but new players will really appreciate this help.

With ASCII it’s hard to tell what new enemies are, or how powerful they might be. So how about first time an enemy type shows a piece of text appears to say “Crikey, a raging bulbosaurus!” or something similar. Bosses might have more dramatic description to denote their importance.

Space as contextual action
Multiple key commands is useful for fidelity of action, but in 90% of situations there is only one action that can be performed. So let’s use the biggest key on the board for it. Stairs? Space to change level. Item on ground? Space to pick up. Trap? Space to disarm. Door? Space to open/close. There’s situations where this won’t work, but the exceptions shouldn’t get in the way of what would be a much smoother experience for most of the game.

Don’t rely on the game log
People don’t read it, especially if you fill it with lengthy text of “A misses B, B critically hits A” etc. Have characters flash red when hit, or have pop up text above the characters showing damage amounts.  Quick, simple feedback for common actions.  Keep the players eyes on the game area, and don’t make them have to pick through small text to find what’s important.

Easy Inventory system
Don’t give the player some weird custom inventory with containers and different commands for each slot.  Don’t limit their space too much either.  Players want freedom and ease of use.  Look at how professional games do inventories.  Roguelikes aren’t alone in using inventory mechanics yet so many have failed to learn any lessons from decades of game design.  For easy to use inventory systems check out ADOM or ToME4, or better yet try to innovate something simpler.  Items can be such a core part of many roguelikes that you should give very careful thought to how you’ll use them and how the player can access them easily.

Clarity of mechanics
Don’t hide important stuff from the player and hope that they’ll get it.  Make sure your mechanics are clear and understandable.  You may have coded a cool system, but if people don’t know what’s going on they won’t understand the subtleties and won’t stick around long enough to enjoy it.  This is where watching someone play your game is important.  Without giving them advice watch how they interact with the game elements and see how easily they grasp what is going on.  Don’t think you can get by on the Nethack style of “players will learn over many years” – you are not making Nethack, nor should you be.

No cheap deaths
By cheap I mean impossible to prepare for.  This is especially frustrating early game.  Challenge is good and fun, but unavoidable impossible obstacles are not.  Traps are the worst for this.  Don’t do traps unless they’re interesting.

Tutorial zone
Not many people bother with tutorials, but if they’re having a hard time learning a game it gives them something to turn to.  Powder, ToME and Dredmor all have good examples of tutorials to teach specific mechanics.  Note that in all 3 you can die in the tutorial – an important lesson to learn in the tutorial as well.

Amusing/entertaining death
Death is bound to happen, and some people find it frustrating.  But you can soften the blow by adding a touch of humour.  Dredmor has its famous line of “Congratulations!  You Have Died!”  Limbo has over the top death animations to keep people engaged after many deaths.  Think of other ways to make the player laugh, like putting in tortured death screams from the character, or throwing up a short randomly generated story of how the world fell apart after the player’s death.  Put out a hook to get the player back in for another game, instead of leaving them feeling bitter and twisted.  It doesn’t need to be humorous – you could have random game tips relevant to the death, or small lore revelations.

Quick restarting
Make it easy for the player to start again, such as a “Restart Same Character” option on the death screen that repeats the character creation with the same options as last time.  “Restart Random” is a good option to have too.  Generally your creation menu should be slick and fast anyway, otherwise people will get bored of it on the 100th playthrough.

Small levels
Can help quite a bit, though isn’t necessary.  Don’t waste the players time exploring big empty spaces.  Have everything densely packed in small levels.  Makes it easier on display too, reducing the needs for a minimap.  4-way movement helps with this a bit – it makes the areas effectively twice as big for play moves, letting you pack monsters and items in a tighter screen space.  Smaller levels feel quicker to get through, and don’t seem so tiresome to replay after death.  Easier for new players to take in as well.

Permadeath optional
Okay, I don’t really like this, but it works well for Dungeons of Dredmor.  In it permadeath is on by default, but you have the option of turning it off.  Mentally it sets the player thinking that this is the right way for the game to be played, rather than feeling like it’s a crazy design flaw.  And they can be proud that they didn’t untick that box, letting them embrace the mechanic rather than be annoyed by it.  It’s important to teach that permadeath is a positive thing, not an unfair and punishing difficulty.