Project(?): creating a standard for keyboard controls in roguelikes

[Bear]

As an example of a fairly complex object, consider a staff.  Now, the basic "usage" of a staff in my game is as an enhancement for spellcasters.  You never actually "use" it, as such.  You have it wielded while you cast spells, and your spells or spellcasting are affected by it. 

But different staves have different effects.  Some increase the range of your spells, some reduce the mana cost of spells in a particular element or school, some enhance the rate at which your character recovers mana, some negate the hunger penalties that some races get from casting spells, some reduce your casting times, some increase the area of effect or the damage of attack spells, and so on.  It's very deliberate on my part that there's a combinatorial explosion of different possibilities with different spells.  Each type of staff gives a magician a different set of abilities that the player can use to deal with unexpected situations in ways that differ from the ways available in other runs. The player might have to think about that, and I think that's good.

But a staff is also a weapon.  If you have the staff, rather than a sword or something, wielded when you hit something, then you're hitting it with the staff.  If someone hits you while you have a staff wielded, then you're parrying, guarding, or blocking (as appropriate) with the staff.  So a staff can have a weapon enchantment too.  Or, more likely, instead.  And weapon enchantments are fully as varied as staff enchantments and staves can have most of them.

And that's the "normal" set of uses for staves.  But there's also command to Fire a ranged weapon, normally used with wands, bows, crossbows, and things like that which carry ranged attacks.  And there's a Throw command which means you're flinging whatever you have wielded. And so on.  Assuming you know how to "fire" a wand, there's no reason you can't do both of those things with a staff. 

I'm no fan of the "different verb for each object type" thing seen in some roguelikes, but I'm a definite fan of the "different verb for different actions" model that allows any action to be applied to any object. 

The interface failure I have to guard against is the case where a newbie repeatedly beats goblins to death with his "wielded" bow, while not realizing that he's only "wearing" (ie, in a scabbard) his sword.  Or throws his sword at a wolf while he has the rocks he intended to throw in a pouch on his belt. Angband users have this problem when they beat things to death with their shovels.

Bear

[Ex]

A lot of netbooks don't have numpads, and although it is easy to buy one, it's very convenient to have SOME way to move without a numpad. I've been thinking about using unused keys like p[] l;' and ,./ or some other combination, but I've never actually tried it.

p[] l;' may be laid out in a non ortogonal schema on international keyboards, it may not make sense in a spanish one like mine, for example... plus some language may have trouble reading those special keypresses, probably...

This is very true, and I would imagine it's even a problem with other key combinations. I suppose the best thing to do would be to let the player bind the keys himself. I wonder why more roguelikes don't allow this.

[AgingMinotaur]

Sorry to bump thread. Just some comments on chooseusername's and Bear's rightful slaughter of my previous post

I was hoping to come off as at least slightly ironic when I said:

So you see, a simpler interface is always better

Obviously, finding the solution that fits a particular game is ideal, and there's nothing wrong with a RL having a fairly complex command set. For instance, I happen to find Rogue's interface quite nimble, even if it laid the ground for too-complex key bindings in later RLs. So, if you want edible scrolls in your game, it's more than acceptible to provide an Eat command. (But why separate commands for eating and drinking!? (Sorry, I mean "q"uaffing, of course))

Having the scenario with a baker is forcing a player to make a subgame out of overcoming an interface problem, and it isn't even a fun subgame.  It's just a scenario that will wind up in a spoiler file.

I agree, not a fun subgame. Still, if including a few edible items out of the hundreds or thousands of things that will otherwise just return a message: "You can't eat that." isn't a very elegant solution either. It'll still make it's way into a spoiler file that you have to eat the scroll of foo instead of reading it. People will have to either code dive or grind to find your easter eggs. When someone discovers that a certain item can be eaten/worn/whatever for an interesting effect, and that relies on a complex set of commands, the "rational" response would be trying every command on every item, as in a failed puzzle game. Can I wear the rune-engraved sword? Can I eat it? Can I read it (No? Then what are the runes for)? Can I aim it? Write with it? Etc.

I think that unnecessary complexity is a problem, but then we have to decide what is unnecessary.  A good example of unnecessary complexity in a roguelike game, IMO, is separate wear/remove commands that apply to clothes, jewelry, and armor.

We certainly agree on this point, and I think this debate would be much less needed if we just started to cut down on redundancies like these.

Still, there is the problem of how to handle special situations, that fall outside of the sane command set you have in place. You'll have to scrap some genuinely good content ideas, unless you want painfully specific commands (ADOM's "clean ears", "wipe face", and "handle" springs to mind) or rely on treasure, guaranteed or not (eg. putting wax in your ears is a bad idea unless you have found a pack of q-tips). As a rule of thumb, I prefer puzzles or subgames, but of course only if they are interesting in their own right, and if regenerating them in procedural environments provides some sort of variation in between games (again, ADOM springs to mind, with the carpenter quest).

As always,
Minotauros

[Kalantir]

Didn't read the entire thread but... here's what I think.

Standardized control in roguelikes would be ideal, but as stated before, it's not very likely to actually happen.
So, for this reason, we should be thinking outside the box.  A few roguelikes currently support remapping the controls to (almost) whatever the player wishes.  This is good practice imho.  However, the problem is, remapping the controls usually involves editing (or creating) a file and swapping controls around until you find a configuration the game likes(eg. No key is mapped out to more then 1 command).  In addition to being tedious and frustrating, its also not a very good solution.

I don't know if most roguelike devs are just too busy or just don't know how handle file i/o, but it appears to me that allowing the player to remap the keys from in-game is not only the obvious solution, but trivial to implement as well.  Upon exiting the options screen, it merely has to save the keymappings (along with any other options) to a config file.  Problem solved.  Everyone wins!

Although, I do not think that standardized control are THAT important, it certainly would be nice if I could just load up the game and get started without getting bogged down by help files.  For this reason, I deem movement controls to be the most important.  There seems to be a huge split in the roguelike community about numpad vs hjklyubn vs arrow keys.  The easy solution is, support all 3!  It's not that hard.  Seriously.

Other then movement controls, I rarely find myself being annoyed at the controls chosen for any given roguelike.  However, inventory management generally seems to be more complex then is necessary.  Have any of you played Astral Tower? http://lordarchibald.republika.pl/main.html  Although a very incomplete game, he had the right idea as far as inventory goes(Although I admit I think he OVER-simplified it).  An more specific example of why I think inventory management is Nethack.

Observe the following Nethack commands:

(P)ut on
(W)ear
(w)ield
(R)emove
(T)ake off

They all do different things(technically), but they also could be reduced to a single command.  Even commands like quaff, read, zap, etc could also be simplified down to the same command easily enough.  If there is a legit reason to make it a separate command, then don't hesitate to do so.. but don't make it it's own command just because you can.

Anyways, that was just my 2 cents...