Temple of The Roguelike Forums
Announcements => Other Announcements => Topic started by: Skeletor on October 29, 2009, 01:53:44 PM
-
I love roguelikes and I like to play them, not only the major ones but also the smaller, uncompleted, abandoned ones. I think it's very satisfying to learn how to immers and adapt to new world logics and create tactics to compete with a new challenge every time I start to play a new roguelike.
The only problem that sometimes keeps me away to start to play a new game is control keys: every roguelike seems to have a different key set!
So everytime I know I have to print a page with all the keys and then learn again how to interact with a keyboard in a new world (but performing the same actions).
And if this is a little-medium problem for me (a roguelike lover), this is a bigger problem for people who know and like only one major roguelike; those persons may be fully unincentivied by this problem and consequently kept away from other games. Even from other major roguelikes, because if you take for example Doom Rl, Ivan, Adom and Angband you'll notice that they all have very different keyset. Two friends of mine love, love, love adom but never played other roguelikes, and I think it's just for this problem.
In my opinion, a very important thing for the whole roguelike community could be to create a general standard about control keys for the commands present in almost every roguelike (take stairs, get item, equip, inventory, attack ranged, pass turn, dip item, skills..).
A sort of "esperanto" between the major games keyset.
Not something to follow strictly (even because some roguelike has some actions that don't exist in others), just something to know and can be really, really useful for the gamers, the developers, and the roguelike community itself.
-
A sort of "esperanto" between the major games keyset.
[irony]
Move by hjkl, and a generic "u"se key for all actions ;)
[/irony]
I'd like more unified keyboard settings, too, but I'm afraid this will not be done. The games are different, and people are different, so it won't be possible to find a good common denominator?
-
Maybe a multiple standard could be created.
Like 3 or 4 main sets (very similar to major games).
Maybe not all developers, but some for sure would be happy to adeguate to the standard and then having more people who play the game they are going to create.
-
I think a discussion will be interesting. Particularly since there are a few design philosophies, which dictate some of the commands.
One structure is "verb item", where people select first what to do, and then, which item to do it with.
The other is "item verb", where you first select the item and get your choices limited to the actions that you can actually do with this item.
Looks very similar, but has a few differences.
Keyboard driven roguelikes almost always use the "verb item" scheme. Mouse driven games almost always use the "item verb" scheme. The reason seems to be mostly that mouse actions are "click on item", while keyboard actions are "enter command".
Beyond this point, a discussion can help to identify common actions.
Does a wand have to be "a"imed, or is rather "z"apped at something? It'd be interesting to get a list of common actions in roguelike games, also interesting to see if there are common control structures. I think particularly NetHack is rich in the amount of usages of items.
-
Step 1: Start from laptops and such as the baseline, as they don't necessarily have all the tricks afoot that desktop keyboards do.
Step 2: Copy, in large part, how the Fushigi Dungeon series approach things---only faster/better since a PC of any stripe shouldn't be as boxed in as the input on a gamepad outside of Analog use or some such which only a few employ.
Side step: Fear not the blasted directional keys! They are an obvious choice for movement in 4 directions, what with the little arrows on them and all.
-
I think people are different, and for that very reason RL developers are different. Those whose come from Angband will think that it is logical and a standard in roguelikes to (a)im a wand, while others will think that (z)apping is a standard thing you do with a wand. All have their reasons and no standard would be possible.
A decent roguelike should have a key (say, "?") which lists all the available keypresses on a single screen (or several screens is one is not enough). (I don't remember a roguelike which does not have that. Well maybe some require several keypresses instead of one, but it does not matter.) This is more comfortable than a printout IMO. And even I have to check this screen, say, 5 times for each action, and each time I use an action which I almost never use, this is still a very small factor in learning a specific roguelike. In each new roguelike, you also have to learn which monsters are strong and which are negligible, what is the way to restore your hit points, how to explore the world effectively, etc.
Are you sure that there are really people for whom this is a problem? Surely some people never learned to control anything with complex key commands, and that will stand as a barrier between them and roguelikes... but those who have learned one complex keyset, love one roguelike, and don't think it worth it to get into another roguelike just because it has a different complex keyset?
ADOM has configurable keybindings, and it would be possible to create a set of keyconfigs for it (default, Nethack-like, Angband-like etc.) I suppose it would be in general better to have configurable keybindings in roguelikes, and have a repository of keyconfigs. Of course it won't help if you like another keylayout design philosophy than the designer.
-
I think that just as long as pressing '?' at any time immediately gives you the instructions for the key set, and that they're presented in at least a relatively intuitive manner, it's not too bad.
Every game should support the arrows and the numeric keypad for movement, as well as one set of movement keys on the "letter" part of the keyboard for laptop users. The hjkl thing is probably the best way to go just because it's the closest thing to a consistent standard we have, even though I personally find it really unintuitive.
-
The hjkl thing is probably the best way to go just because it's the closest thing to a consistent standard we have, even though I personally find it really unintuitive.
The Vi editor defined them, and computers were really quite different that time ... like 30 years ago: http://en.wikipedia.org/wiki/Vi
Edit: More info http://en.wikipedia.org/wiki/Hjkl#HJKL_keys
-> for use on an Lear-Siegler ADM-3A terminal, which places arrow symbols on these letters
Amazing what Wikipedia knows :)
-
My thing is...why is there so many keys to learn when you can use a generic 'u'se key for a lot of them. Or, maybe even a 'e'quip key for all equipment. I know there is probably more to that under the hood, but I'm not a programmer. This is about the only thing that bugs me.
-
My thing is...why is there so many keys to learn when you can use a generic 'u'se key for a lot of them. Or, maybe even a 'e'quip key for all equipment. I know there is probably more to that under the hood, but I'm not a programmer. This is about the only thing that bugs me.
There is no good reason for this, IMHO. The only sensible explanation I ever heard, was that since eg. scrolls and wands produce different effects, it makes sense to separate the commands. As the player learns what kinds of effects are connected to the "read" and "aim/zap" commands respectively, this might save a bit of time. (Ie. not having to sift through your entire inventory every time you want to activate your favourite wand)
Personally, I feel that in most instances it's appropriate to use a less complex command set. Of course it depends on the overall design of the game, but I just find it annoying to constanly have to break the game flow to check ridiculously big lists of random commands, because I can't remember if rings are "w"orn or "p"ut on or "f"itted, or what do I know.
Addressing the first post, that's a neat idea, and I could see how it might benefit the genre if there was actually a semiofficial standard that many games shared. But I don't really see how it could happen as a willed effort. People are just bound to make solutions they themselves find the best. I know I wouldn't adher to a standard. Sure, there's tradition, like how you potions are (q)uaffed in many games, but these kinds of things evolve organically, and are difficult to force. I think this idea would be slaughtered at rgrd, for instance.
As always,
Minotauros
-
its 2009, we are no longer even forced to use keyboards, because of the benefits of the mouse. Im trying to build a mouse only interface for my project Rail, I think its a bit more intuative, though harder to code.
Side step: Fear not the blasted directional keys! They are an obvious choice for movement in 4 directions, what with the little arrows on them and all.
I have done this in my games, but every time I wonder if its the right thing to do. When I was younger, the first roguelike I ever played was Castle of the Winds (an exceptional game), and for a long time I couldnt get past the first cave area because of a diagonal corridor, the top level is always the same map. I never realised you could move diagonally because the arrow keys working for movement led me to believe they were the only method of movement... In a regular roguelike with regular shaped dungeons, a player new to roguelikes may never realise because they are often never actually forced to move in those directions.
I think that just as long as pressing '?' at any time immediately gives you the instructions for the key set, and that they're presented in at least a relatively intuitive manner, it's not too bad.
Agreed.
Are you sure that there are really people for whom this is a problem?
There is no doubt that the interface of roguelikes are the main slopes of the difficulty curve, but with a keyboard only interface often there is little choice but to make it complex. Roguelikes are complex games. Then again the kind of person who cant surmount that obstacle is probably not the kind of person suited for roguelikes anyway...
-
My thing is...why is there so many keys to learn when you can use a generic 'u'se key for a lot of them. Or, maybe even a 'e'quip key for all equipment. I know there is probably more to that under the hood, but I'm not a programmer. This is about the only thing that bugs me.
I see no reason to separate "wear" and "put on", like Crawl does. The logical differences between armor and jewelry are too small to justify two different commands. You also are not supposed to carry a huge lot of these (if you did, splitting it in half would be worthwhile).
Different commands for "read", "quaff", and "zap a wand" are more reasonable (first, they partition the large set of scrolls/potions/wands into smaller ones; second, scrolls, potions and wands are mostly used for different purposes), but that distinction is not necessary.
But "wield" and "throw" have to be separate commands, since you are able to wield/throw anything. (Crawl gives reasons to wield strange things, not sure about throwing. Adding wield/throw to the generic use would mean that either you lose the ability to wield strange things, or are always asked whether you want to wield or to use another way.)
What I would do to improve Crawl keyboard interface is: unify "wield" and "put on" into one command, and add the generic "use" command which would select the default action, without removing the specific "read" command and friends. It could even perform "wield" for weapons and "throw" for missiles (although this is a bit risky, since it would hide the ability to wield anything, just like arrows hiding the diagonal movement in Numeron's example. Not really that bad in this example, but, if you want to have multi-use items, like e.g. Mjollnir in Ragnarok, which can be either wielded as a weapon or zapped as a wand - a person using the generic use command would be likely not to notice one of these uses, while in Ragnarok, Mjollnir just appears by default both in "wield" and "zap" lists, so you will probably notice sooner or later).
its 2009, we are no longer even forced to use keyboards, because of the benefits of the mouse. Im trying to build a mouse only interface for my project Rail, I think its a bit more intuative, though harder to code.
More intuitive, maybe, but much less effective. Pressing 'zq' to zap a wand labeled by 'q' is less intuitive than selecting "zap" from a menu and the wand from a list (or the other way around), but it is roughly 10 times faster, and you don't even have to look at the screen or the keyboard. The benefit of mouse is that you can avoid the very unpleasant keyboard scrolling, but in most cases keyboard also has its ways to avoid that in ways that are more comfortable to those who use them than mouse scrolling (except they are surely less intuitive).
-
don't force anything, just give player the options. When CNC starts you can choose wasd, vi or cursor configuration.
-
(although this is a bit risky, since it would hide the ability to wield anything, just like arrows hiding the diagonal movement in Numeron's example.)
That brings me to think of something else I've been pondering lately. In my game, I let the player "bump to attack", of course, out of old habit, and because it's an economic implementation of the presumably most-used command. But several weapons need to be explicitly activated in certain situations. Spears attack from a distance, sledge hammers take down doors, etc. So I've been considering disabling bumping by default (it can already be toggled on/off). Expanding bumping so that you start mining if you bump into a wall whilst wielding a pick ax, for instance, seems iffy, and still doesn't solve the problem that some players are probably never going to realize that pole arms can attack from a distance. What do you guys think about disabling bumping? I guess the main issue is that attacking would demand two key strokes (command+direction). In a system with facing, I'd be less reluctant.
As always,
Minotauros
-
I could see with bump disable even without mouse support. Attack key, then if a general, non-special attack, a little flashing cursor outline to place with movement keys on the target within whatever range is legal, then attack key again to initiate.
-
My thing is...why is there so many keys to learn when you can use a generic 'u'se key for a lot of them. Or, maybe even a 'e'quip key for all equipment. I know there is probably more to that under the hood, but I'm not a programmer. This is about the only thing that bugs me.
I'm split on this one. On the one hand, there's no reason why the command for putting on your gloves needs to be different from the one for putting on say, a ring. With that said, in some cases it can be better for keeping the number of key presses needed for any given action down, or for avoiding presenting the player with an inconveniently large number of options when they only need to choose from a few specific things.
As an example of the latter, I support using 'r'ead for scrolls and 'q'uaff or 'd'rink for potions. They're mechanically similar, sometimes even identical, but they're also items that the player tends to carry a lot of. If they weren't separate, then every time you'd press 'u'se you'd get 50 options of every potion, scroll, wand, staff, etc in your inventory, and you lose more time finding and picking out the one you need from the large list than you'd lose from just learning separate commands. For things like wands and staves where the player generally only carries a few though, I think it's dumb to use separate commands.
I'll use my own project as an example of limiting key presses. In my game I'm working on, there are separate buttons for using 's'kills and 'm'agic, even though they're mechanically almost identical (the main difference being only that skills use stamina and magic uses your magic energy).
Despite being almost the same thing, I'm separating them, because I'm shooting for about 26 of each - one for each letter key on your keyboard. If they were unified under one key, I would either need to have the player cycle through two pages to see everything, adding an unnecessary key press to the action, or I would have to expand which keys are used for skills to number keys and beyond - making it far more complicated to memorize everything than just remembering 's' for skills and 'm' for magic would be. With the way I have it, you only need to press two keys to use any non-directional ability, or three for ones that need to be targeted. Some commonly used abilities will have their own specific key, so you only need one or two key presses to use them.
I really don't like the way, say, ToME handles it, where you press 'm' for magic, then you have to choose whether to cast a spell or store a spell or whatever, and then you have to choose a book, then a spell within that book, and then finally you have to press a key for what you want the spell to be cast on. That's five key presses for an action that takes a single turn, and it's something you'll need to do all the time. I consider mages to be unplayable in that game unless you learn how to make spell macros for that reason, and of course, learning to do that means that you have to spend even more time figuring out the controls and how it's all done.
-
A Standard could be defined, and the developers would decide whether or not their game is compliant...
-
I like the idea of some kind of standard, but a standard doesn't need to be strict. It could include different options, like "Either use 'u' or enter for all actions or use 'q' to drink, 'w' to wear, etc. etc." I personally like extremely simple interfaces and menus, but others like a lot of keys being used. Perhaps the standard could provide an option for either style? We could even provide an option for developers who have access to GUIs and such.
-
Maybe a good way to start this work could be to create a table with all the keys of every possible action in major roguelikes.
Something like this:
ADOM Nethack Angband Crawl IVAN Doomrl
attack ranged t etc..
change tactic F1-F7
character info @
clean ears E
close door c
controls list ?
dip !
drink D
drop d
engrave [N.A.]
kick k
pick up item ,
pray _
read r
reload [N.A.]
use wand z
use U
wipe face F
Obviously first of all we should decide what roguelikes are enough "major" to be taken in consideration.
With the table we could immediately see which keys are the same for the most major roguelikes and create a general standard where those major roguelikes action/keys would 90% fit.
Just my 2 cents, I don't know! :-)
-
I think a chart of what keys major roguelikes use has actually already been made but I can't find it.
The movement standard that I'd most prefer is the directional keys for movement. You can easily get diagonals by holding down two keys, and it would cut down on some of the initial barriers to learning how to play.
-
You can easily get diagonals by holding down two keys, and it would cut down on some of the initial barriers to learning how to play.
This is pretty poor form IMO, and while implementing it is possible, it would be too easy to accidently move orthagonally while trying to go diagonal.
-
You can easily get diagonals by holding down two keys, and it would cut down on some of the initial barriers to learning how to play.
This is pretty poor form IMO, and while implementing it is possible, it would be too easy to accidently move orthagonally while trying to go diagonal.
Historically, whose bright idea was it to NOT go with an 8 direction pad waay back when in keyboards standards land? Really, they need to be smacked in the back of the head since this would've made so many things that much simpler.
-
Maybe a good way to start this work could be to create a table with all the keys of every possible action in major roguelikes.
Something like this:
I did such gigantic chart some years ago... may be I must give a look to my old computer...
-
Great!
-
There was something like this .... ah here
http://roguebasin.roguelikedevelopment.org/index.php?title=Preferred_Key_Controls
And here
http://groups.google.com/group/rec.games.roguelike.development/browse_frm/thread/c4ebcb235cc275dc/?pli=1
-
There was something like this .... ah here
http://roguebasin.roguelikedevelopment.org/index.php?title=Preferred_Key_Controls
And here
http://groups.google.com/group/rec.games.roguelike.development/browse_frm/thread/c4ebcb235cc275dc/?pli=1
Ahh, handy! I've started work on a new roguelike recently, and the dilemma of key layouts has been bothering me for some time now. This should come in quite handy, especially the first link. :)
-
There was something like this .... ah here
http://roguebasin.roguelikedevelopment.org/index.php?title=Preferred_Key_Controls
And here
http://groups.google.com/group/rec.games.roguelike.development/browse_frm/thread/c4ebcb235cc275dc/?pli=1
As a player, this looks pretty good to me. It also looks easier to learn for first time players too. I have had many friends wonder how in the world I can remember what keys do what when most of keys on the keyboard are used.
-
Historically, whose bright idea was it to NOT go with an 8 direction pad waay back when in keyboards standards land?
Actually the 4 arrow keys are a younger addition to the pc keyboard than the numpad, the original pc keyboard had the latter but not the former:
http://upload.wikimedia.org/wikipedia/commons/8/85/IBM_5150_Keyboard.jpg (http://upload.wikimedia.org/wikipedia/commons/8/85/IBM_5150_Keyboard.jpg)
-
Historically, whose bright idea was it to NOT go with an 8 direction pad waay back when in keyboards standards land?
Actually the 4 arrow keys are a younger addition to the pc keyboard than the numpad, the original pc keyboard had the latter but not the former:
http://upload.wikimedia.org/wikipedia/commons/8/85/IBM_5150_Keyboard.jpg (http://upload.wikimedia.org/wikipedia/commons/8/85/IBM_5150_Keyboard.jpg)
Bah, but the Numpad is a confusing beast what with its numbers, and Home, and Pg Dn and the like---there's no mystique to the beloved arrows. :P
-
I'm naturally frustrated with roguelike controls for the sole reason of the Numpad. Most if not all roguelikes heavily rely on it with no way for me to rebind it. Me being a Notebook User, thus have to rely on using really obscure keyboard shortcuts to temporarily activate a simulated Numpad which of course overrides other keys, walk diagonally, deactivate it again to do an action, reactivate it yet again and... wash, rinse and repeat.
When I dabbled in Processing for a bit, I used something different. I had the Control Key tilt the Arrow Keys by 45° counter clockwise. While holding Control, pressing the Up Key would move the character up/left. The right arrow would move it up/right, etc. It worked for me and felt intuitive too. If it was suggested already, sorry, still do it, implement it, stop shunning Notebook Users :P
-
I had the Control Key tilt the Arrow Keys by 45° counter clockwise. While holding Control, pressing the Up Key would move the character up/left.
This is something I also thought. I have an idea of using ctrl+arrow up/down to move southwest/northwest and alt+arrow up/down to move southeast/northeast.
-
What about just processing the command after no keys are pressed? So pressing top would allow me to add the right key, after the buttons are released my character moves up-right ?
But in most roguelikes i've got additional difficulties... use of hard coded scan codes !!! My layout has a way different mapping, Numpad e.g. : (plain) 123456789 (shift)♦♥♠♣€6✔✘9 (capslock)↔↓⇌←¦→↕↑⃗
-
But in most roguelikes i've got additional difficulties... use of hard coded scan codes
Yes, developers should be aware of that. I noticed that SDL's standard keyboard codes work only with US keyboard layout, but you can use unicode codes to get the correct match with problem keys.
-
An interesting discussion... For the most part, I agree with many points in this discussion. The key (pun intended) points as I understand it:
* Using a generic key to "verb" and object is generally not viable - This would select too many objects from a player's pack to be useful. The idea of having a key allocated to each action creates a better user interface with only a select number of objects that verb applies to.
* For the most part, redundancy in commands can enter a game, probably from a historical perspective. Nethack with the wear and PutOn commands are a good example. However the problem once again becomes the use of a command that is too generic.
* Directional input - While "laptops" have been mentioned as the "minimum" requirement, the primary limitation is in the diagonal movement. Keypads are useful as they are a discrete entity on the keyboard, and it is difficult to hit the wrong key when using specifically setup direction keys.
As a general rule of thumb, you want to allow a player to perform actions with the least input possible. I think one problem not really discussed is tying an action to a specific set of objects. For example, "Read" being tied to only scrolls and spells. What if you could also "Read" other objects such as potions (such as reading the label on the potion). Thus when a player presses "r" to read something, they are given the normal menu, but can opt to read any other object as well. This opens a whole new level of gameplay, whereby more complex objects can exist, with complicated user interaction.
This is why in Interhack I have isolated the user interface from the actions performed. Anyone can write the interface however they like, yet the core game engine will not change. When defining the user interface, you set it up such that a physical action performed by a player (such as pressing a key or clicking a mouse button), leads to a message being sent to the server containing the relevant information. The ACTION was "read" and the object ID was YYY. Combine this with objects that can choose what actions to respond to, and you end up with some unique gameplay.
As such, I can code a potion, that has a label, which when read will give some clue for something else in the game. Or add an action "Study" - and the more an object is studied, the more it may reveal. Thus an archaeologist may be more skilled at studying objects, and may discover more.
Of course taking this path adds all sorts of complications to the game engine. And lets not get started on first person and third person perspective of verbs and generation of messages... :)
-
First off: I support digits as movement keys. I figure it's best to let 12346789 be reserved for 8-directional movement. Lots of newer laptops have numpads, and even if they don't, you can add a numpad on your USB port. Finally, if that's a problem, you can still type digits on the top row of the regular keyboard. I thought that would be annoying, but once I got used to it I don't have a problem using a game that way.
I also think the arrows should be supported for 4-directional movement.
Generally speaking I don't want to use keyboard keys for movement; especially not eight of them. I want those keys for commands.
A generic 'use' key for all items is not compatible with items that have multiple uses, and since I want the complexity of items with multiple uses, I will not be supporting a generic 'use' key. There are games for which it's appropriate. Mine's not one of them.
I use a natural language in which the verb in an imperative sentence precedes the object, so verb-object seems to me like a natural way to give commands to the computer. But speakers of other natural languages will probably have different opinions.
I think that a good interface saves the player from making boring keystrokes whenever possible. For example repeating an attack you've already made once should not take more than one keystroke unless you've run out of that kind of ammo or charges or mana, you've had that weapon or wand or whatever taken away, the target has died or fled out of targeting range, or something else has happened that means you can't exactly repeat it anymore.
-
First off: I support digits as movement keys. I figure it's best to let 12346789 be reserved for 8-directional movement. Lots of newer laptops have numpads, and even if they don't, you can add a numpad on your USB port. Finally, if that's a problem, you can still type digits on the top row of the regular keyboard. I thought that would be annoying, but once I got used to it I don't have a problem using a game that way.
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.
I also think the arrows should be supported for 4-directional movement.
I agree with this! But I hate hjkl controls! I've never been able to use directional keys that were laid out in a straight row. Even when I was a kid using the Apple 2gs I could never work it. IMO, pl;' or l,./ would be better keys than hjkl. Ideally, I'd love to use wasd, but those are all the most useful keys!
A generic 'use' key for all items is not compatible with items that have multiple uses, and since I want the complexity of items with multiple uses, I will not be supporting a generic 'use' key. There are games for which it's appropriate. Mine's not one of them.
How often are you going to want to eat a scroll or read a potion, though? Personally, I prefer the simplicity of a single use key, since 90% of items naturally have only one use. But, even for items that do have more than one use, you can still have a single use key which brings up a menu of options on how exactly to use the given item. Menus are good, they work well and people seem to like them.
I think that a good interface saves the player from making boring keystrokes whenever possible. For example repeating an attack you've already made once should not take more than one keystroke unless you've run out of that kind of ammo or charges or mana, you've had that weapon or wand or whatever taken away, the target has died or fled out of targeting range, or something else has happened that means you can't exactly repeat it anymore.
I think a good interface is simple to learn and remember, and quick to use. I like minimalistic interfaces.
-
How often are you going to want to eat a scroll or read a potion, though? Personally, I prefer the simplicity of a single use key, since 90% of items naturally have only one use.
Well, for a lot of people a lot of the enjoyment they derive from nethack is due to creative "eat a scroll" type of solutions.
But I agree that menus are more discoverable than just having a ton of key bindings.
-
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...
-
hjkl-controls ...
I think the most sensible solution (that I know of, anyway) is to default-enable movement by keypad, arrows as well as hjkl, and allow players to configure their own keybindings if that is desirable. It seems like the closest we'll get to having our cake and eating it too.
Concerning edible scrolls and readable potions ... I agree with the sentiments expressed by Elig. Proponents of big command sets often mention the possibility of complex item interaction. That may be so for Nethack, which I haven't really played, but classics like Crawl and ADOM, at least, have way too complex command schemes for what you can actually do. For most RLs, striking the balance between "generic use command" and "a gazillion commands for superspecific situations" is easier said than done, however.
Maybe we could learn from old adventure games in this department, ie. employing "use A with B" to provide complex item interaction, as well as throwing in a few generic commands (throw, give, push/pull).
By the way, a game with edible scrolls would totally rock.
As always,
Minotauros
-
I think the arrow+some control key is working quite nicely. I find it quite intuitive to use shift with left/right arrows to move northwest/east and ctrl southwest/east.
I also made ctrl and alt affect up/down arrows which give the same result, but with left side (ctrl) and right side (alt) keys changing up/down move.
-
Just a note, but if you decide your game works fine with four-directional movement, your problem is solved because the arrow keys are all anyone needs in that case and pretty much every interesting device has them. Before you spend too much sweat on numpad vs. vikeys you should at least consider that option.
The main drawback to the number pad for 8-directional movement, as people have pointed out, is laptops without a number pad. But there's a simple workaround. I mapped the digit characters, rather than the numpad itself, to movement commands. So, if you want to play on a laptop with no numpad, you can -- you just have to use the top-row numbers as direction keys. This is not great, but the alternatives, as I see them, are worse.
Eight lower-case letters for the vikeys, out of only 26, considering that lower-case letters are the easiest commands to enter, is too big a price to pay. And if the vikeys don't make sense to me on a US keyboard, imagine how much nonsense they make to people on other keyboard layouts. The number keys are at least consistent in layout from one keyboard to the next.
-
Alas there are too many die-hard vi-fanatics... Laptops are a big problem for roguelikes though. Only easy solution is four directions only. One thought I came up with before is using 789/UIO/JKL (the capitals) so that you have an effective numpad with the caps lock on. Enable &*( as alternatives to 789 and you have move with the Shift held. Only problem is that on some keyboards the three lines are somewhat out of sync and the directions feel less natural.
With regards to generic use vs specialist commands, why not have both? Simply make the generic use command perform the default action for that item type (drink potions, read scrolls, equp armour, wield weapons) whilst retaining specialist commands for times when you want less inventory scrolling or when you want to do something odd. I imagine many players will use the generic use button 95% of the time.
-
Just another thought on complex key bindings: I don't actually believe that complex item interaction needs a complex interface to work. But the developer will have to get imaginative in new ways. Some examples:
Let's say you want a "Jerome and the lion"-like encounter in the game: A monster/animal with a thorn stuck in a paw. The point is for the player to relieve the beast, who might become some kind of helper. You would add a prefix to make the beast stand out (something like "angry lion" instead of just "lion") and a unique description mentioning the thorn. In a game with a complex key set, you can add a proper command for the situation, something like "Ctrl-P" for "pull out small things that are stuck in bigger things". In a simpler interface, you'll have to emulate the action in a different way. One solution would be to decide that any action that heals the lion results in a message that describes how you remove the thorn and gain a friend for life. Based on current stats and equipment, the player might want to hurl a healing potion at the critter, or apply a first aid skill, etc.
Edible scrolls: In a complex interface, trying to eat a scroll will almost invariably result in a "You can't eat that"-message, but a few special scrolls may be edible. Discovering an edible scroll will of course be a kick, but it may not make up for the hundreds of fruitless efforts to apply every possible verb to every possible item. With a context menu, it becomes less grindy, but also less interesting. Choosing the scroll from your inventory suddenly gives you two options ("eat" or "read") instead of the usual single option ("read"). Obviously, most players will originally intend to read the scroll, but opt to eat it instead, since the possibility is there. Finding an edible scroll may be fun in itself, but the thrill of discovering a hidden property, solving a puzzle, is lost. A more elegant solution might be to add special cases where you can turn something into an edible object. For instance, let's say there is a baker in the village, with a patch of sourdough in his house. Dropping or throwing the scroll into the dough means that the next bread you buy from the baker will have some magic of the scroll, if applicable. This adds a tactical element, as the baker may not take lightly to people dropping random stuff into his precious dough, etc. It also adds a gamble, since baking stuff that's usable, but not edible, will incur a loss, as the item is destroyed and the bread is ruined.
There is also always the solution of adding special objects to perform special actions. That may be klunky in some instances, but it definitely has its uses. For instance, without an "inscribe" command, you might not be able to inscribe the dungeon floor with your sword, a magic staff etc. for special effects. But the developer can add something like a "magic chalk" to inscribe other objects with, spawning a different kind of subgame. The possible complexity is still huge, if the same rune can yield different effects when inscribed on different kinds of objects. "Frost" rune inscribed on "wind" staff yields "ice storm", etc.
So you see, a simpler interface is always better ;)
As always,
Minotauros
-
Just another thought on complex key bindings: I don't actually believe that complex item interaction needs a complex interface to work. But the developer will have to get imaginative in new ways. Some examples:
Maybe it was just me, but none of these examples seemed to illustrate anything about "I don't actually believe that complex item interaction needs a complex interface to work"
So you see, a simpler interface is always better ;)
I unfortunately, am not seeing :-\
-
Maybe it was just me, but none of these examples seemed to illustrate anything about "I don't actually believe that complex item interaction needs a complex interface to work"
I think I second that sentiment. These examples were all cases of substituting situational complexity for interface complexity. The problem with that is that situational complexity does not favor creativity; it only favors memorizing and repeating the developer's creativity.
The interface is supposed to let the player do whatever s/he wants to do in order to solve game problems. If a player has thought of eating a scroll, s/he shouldn't have to try to figure out how to get an excessively simple interface to let him/her do it. 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.
These are not flexible tools for solving new or random problems; these are merely puzzles to be solved once. The solutions would just find their way into a spoiler file, and that would be the end of it.
So you see, a simpler interface is always better ;)
Hmmm, no. The simplest interface is the one on a screen saver, and a screen saver is not much fun because you can't do anything. 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. The interface should be complicated enough that the player can command the character to wear things; complication beyond that point is unnecessary and therefore bad.
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
-
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.
-
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
-
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...