Author Topic: Roguelike standards  (Read 8927 times)

chooseusername

  • Rogueliker
  • ***
  • Posts: 329
  • Karma: +0/-0
    • View Profile
    • Email
Roguelike standards
« on: September 14, 2010, 09:48:48 AM »
Working on my roguelike, I find myself wanting not to have to make arbitrary decisions that would make my game differ simply through randomness, compared to other roguelikes out there.  To me, there is great value in some specification that lists the standard choices made in implementation.  By adopting these, or keeping as close to as possible, to these, a game author could make their game more approachable to players.

Just to be clear on what I am referring to.  Take @ for example, it is as far as I know, the standard symbol for the player character.  Is there a page somewhere listing guidelines for choosing symbols, for standard kinds of objects, monsters and other things which may be encountered?  Is there a page somewhere listing guidelines for choosing keys to map to actions?

Do people even consider having a baseline standard which developers can choose to keep close to, to be of value?

Etinarg

  • Rogueliker
  • ***
  • Posts: 424
  • Karma: +0/-0
  • Idea archivist and game tinkerer.
    • View Profile
    • Gedankenweber Blog (German)
Re: Roguelike standards
« Reply #1 on: September 14, 2010, 11:42:16 AM »
For the ASCII symbols I had started a discussion some time ago:

http://www.roguetemple.com/forums/index.php?topic=1260.0

You might find a few answers there.

Skeletor

  • Rogueliker
  • ***
  • Posts: 579
  • Karma: +0/-0
  • villains ftw
    • View Profile
Re: Roguelike standards
« Reply #2 on: September 15, 2010, 02:59:13 PM »
.. and concerning a standard for keyboard controls in roguelikes I started this thread:

http://www.roguetemple.com/forums/index.php?topic=575.0
What I enjoy the most in roguelikes: Anti-Farming and Mac Givering my way out. Kind of what I also enjoy in life.

Ancient

  • Rogueliker
  • ***
  • Posts: 453
  • Karma: +0/-0
    • View Profile
Re: Roguelike standards
« Reply #3 on: September 16, 2010, 05:24:03 PM »
There was much research done on keys in RL games.

RogueBasin has information about common keys:
http://roguebasin.roguelikedevelopment.org/index.php?title=Preferred_Key_Controls

There is huge key list compiled by Bear:
http://groups.google.com/group/rec.games.roguelike.development/msg/fd59ac5a4a57b920?

See also Robson's script:
http://iceyboard.no-ip.org/rlkeys/rlkeys.php
Michał Bieliński, reviewer for Temple of the Roguelike

Hypatian

  • Newcomer
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Roguelike standards
« Reply #4 on: September 17, 2010, 08:14:52 AM »
I'm in the early planning stages of a new project, and have picked up a bit of inspiration from Brogue. I definitely don't think you could call its keys standard, but what they *are* is very nicely streamlined.

I know some people like the "every key does a different thing, and different kinds of items require different verbs" style, but I would still recommend taking a look at this kind of more minimalist option as a base.
« Last Edit: September 19, 2010, 11:21:23 PM by Hypatian »

chooseusername

  • Rogueliker
  • ***
  • Posts: 329
  • Karma: +0/-0
    • View Profile
    • Email
Re: Roguelike standards
« Reply #5 on: September 19, 2010, 08:59:12 AM »
Thanks for the replies people, this was very informative.  I give you a 9/10 signal to noise ratio, which is consequently lowered by this post.

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Roguelike standards
« Reply #6 on: September 27, 2010, 05:15:10 PM »
Implementing commands turns out to involve some thinking about fundamentals.

First there are keystrokes.  If you're going crossplatform, there's actually a lot of craziness under the hood in getting keystrokes.  Getting a consistent return value when the user presses a key, across variables of locale, operating system, keyboard mapping, function keys, characters, curses implementations, (especially wide or unicode curses), network connections (telnet/ssh remap some keys) etc, turns out to be surprisingly hard.  And it creates alias groups.  For example, the KEY_ENTER function key code, the newline character, the carriage return character, and the carriage return/linefeed combo are all possible returns when someone presses the "enter" key depending on various craziness.  You want your Input_GetKeystroke function to return exactly one of these things and you want to prevent commands from ever getting bound to any of the others.  So there needs to be an abstraction layer over keystrokes.

While you're abstracting over keystrokes, you want to give each key a human-readable name which you can use in your help system.  For ordinary graphical characters, you can use the character as the name.  But beyond that it gets harder.  Curses provides names for function keys, but they're not suitable for interfaces intended to be used by the public, nor do they localize with language settings.  Then you have nongraphical characters, such as tab, backspace, space, and return.  Some of these are part of alias groups, but some (such as tab) are not.  So you have to be able to give each key or alias group a name that tells the user how to enter it. 

Okay, now you have to make a decision.  Is a command just a code path, or can it be stored in data?  I recommend going with the data option.  That gives you the ability to create a set of menus, and switch menus with a single command.  It also means the help subsystem can just "read" the keystrokes and commands out of the current menu, so it'll never ever get out of synch.  So, you find a way to represent the command (maybe an integer, maybe a code pointer plus parameters) then you build menus, which are sets of keystroke-to-command bindings, then you implement context-sensitive menu switching. 

Then you decide your key-to-command mappings.   There are four interesting cases to cater for right out of the box.  Numpad movement, wasd movement, vikey movement, and arrow-only movement are all popular, and their partisans are fiercely opposed to switching.  If you abstracted menus (that is, commands-as-data and sets of command bindings) you can support all four.  Let the game come up in your preferred mode, and then have a command for the user to just switch to the other modes. 

Maybe you want to include a way for the user to make his own mappings, or maybe you put that off for the next version.  If you do include a way to remap it, you have to make sure that commands can't get "lost" or become impossible for the user to refer to. 

Or maybe you're making a 7drl, in which case you just let yourself be satisfied with a switch statement.  :-)