Posts Tagged ‘development’

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.

Running out of time…

March 12th, 2010 No comments

I have 42 hours remaining.  Right now I need sleep, and tomorrow I have a job to attend too.  Have scent-following working quite nicely, though the game did crash on me for no reason just now (and I don’t even know where to start looking for any bugs).  Hopefully it’ll be okay and I can start work on the traps tomorrow.  More from my devnotes:

   Update 21:29: Got the ogres moving randomly and the whole turn and time
      system as I'd like.  Also got messages for bumping into enemies
      (including some hints for bosses).  I'm still unsure of how to get the
      ogres to move in the right direction though.  Needs some hard thought!
   Update 00:47: Scent-tracker is working!  Dear Christ that took a long
      time...  Ended up far more tricksy than I expected.  Also not 100% sure
      it's working as well as I want - need more testing, though I don't really
      have the proper time.  It seems to do what it needs to do, and so now
      it's time for my chocolate reward  :)
      Also Trapper.pas now exceeds the source code length of Gruesome, which
      was previously the longer piece of code I had written (1900 lines or so).
      Still not a proper game though.

Halfway point

March 9th, 2010 No comments

Well, can’t say the game is half-finished, but in terms of real-time hours I’m around halfway through.  However I anticipate having more time than I’ve had so far on Friday/Saturday/Sunday, so hopefully all will go well.  Some notes I’ve been taking as I go along:

   9th March 18:58: Well, gave up on that message handler at around 2am.  I'm
      sure if I had more time I could get it running, but it was too much for
      my weary head and I don't have the time to sort it out properly.  For
      now I'll stick with the KISS philosophy (Keep It Simple, Stupid) which
      has always served me well.
   Update 19:42: Got my very bsic message looper worker perfectly.  I love it
      when I think up an idea and then I find it works exactly as I had
      planned... it's a rare event.  Next step - test out digging.  After that
      I'll finally get some ogres on the loose.
   10th March 01:27: Added diging and a bunch of other stuff.  Got rather
      sidetracked actually - added in the menu display for traps and the gems
      to be collected to open up new trap types.  Traps can't actually be laid
      yet though, and more importantly there's no enemies to use them on.  I
      will have zero time for coding till Thursday, and not much time even
      then, so I really hope I can get a lot of work done during the last hours
      of the weekend.  Implementing enemies may turn out to biting off more
      than I can chew...

Progress ahoy

March 9th, 2010 No comments

I have a working cave explorer thingummy going.  I can’t get message handling working well, so I’m giving up on it.  Next up is adding monsters, which will turn it into a proper game.  In my lunch break at work I wrote the following background story:

Gadzooks!  Wuggy the Warlock and his gang of ugly ogres have attacked the
tiny gnomish town of Turgylton and stolen the Gems of Power!  Now it's up
to the town's hero Toby the Trapper to venture into the villain's
cavernous lair and retrieve the holy Gem of Life.  But this is no easy
stroll down the mine - the ogres aren't just ugly, they're also big and
tough, able to squash little Toby with a single swipe!  And deep
within the dark lair Wuggy the Warlock and his fiendish friends guard the
Gem of Life with foul sorceries and terrible powers!!
Still, it's not all doom and gloom.  Toby is much faster than the big
brutes and can see better underground too (the dumb ogres can only sniff
their way around, and it's hard for them to smell anything above the
stench of their own ugly bodies!)  He also still has some Gems of Power to
create traps to use against them, and may find more along the way.  So do
you feel up to helping Toby fight these dastardly villains?!  With
Flashers and Bangers and Boomers and Blinders and much more besides you'll
explore varied random dungeons filled with dread and excitement in your
quest to help Toby defeat the wicked warlock and save his tiny town!  Let
the adventure begin!!!!!

For the curious you may also wish to see my development notes so far:

7th March 23:44: 0.0.1.  Ported code from The Lion King and Gruesome.
Includes dungeon generation of a few cave types, LOS and moving
around.  LOS should work out of the box, rest must be properly
tested and tweaked.  Many worries.
Update 8th March 02:41:  Got everything working after a lot of fiddling
and silly sleep-deprived errors.  Need to make some code adjustment to
how the last level is generated, but otherwise extremely happy with
results.  Also may wish to tweak some colour schemes, but that's not
immediately important.  Next up is message management, wall-digging
and properly implementing enemies, none of which I've done thoroughly
before.  How exciting...
8th March 20:31: No time to work on it today.  Just spent a few minutes
tweaking the map generator so that the final level is more selective
about layouts that are too spartan.  Thinking of adding something to
encourage loops in levels, but no need for it now...  Will try and
find time to get stuck into the real mechanics of the game later.
I've now labelled it 0.0.2 - it's a stable cave explorer with different
level themes, essentially.
8th March 23:55: Gonna play a little with a message handler, but if I don't
get far then I'll just give up.  It's not important enough to waste
much time on.

Anyway, on with the coding…

Once upon a beginning…

January 28th, 2009 16 comments

Hi, and welcome to “The Adventures of a Newbie Roguelike Dev”, a weblog featuring articles from a beginning game designer. I call myself a newbie because my programming skills are very poor – I have no knowledge of pointers, file-handling or OOP and have yet to implement basic game mechanics like AI, pathfinding and items. However, I have released a game, and quite a fun one at that, in spite of its simplicity (or maybe because of that). It’s called Gruesome, and you can find it here. Give it a quick try – you might just like it.

This blog will sporadically feature update and development notices about this game and others I have planned, but more importantly I intend to write a few articles about my experiences in taking up programming and game design. Aspiring developers may find it a source of inspiration, or maybe even a warning of what not to do. Experienced developers may find it a fresh take on conventional ideas. Overall though I hope it’s simply enjoyable to read, as I try to tread lightly past the hazardous pitfalls every developer must face: bugs, procrastination and over-ambition.