Meaningful complexity
Pointless
because they're more accessible. The first play is more enjoyable. And
players that have a good first impression are more likely to come back
and play again.
However, complexity produces a gameplay experience that's more likely
to be enjoyed after a number of plays and deaths. This is, of course,
essential to a game with permadeath. The game must be replayable. I've
called this post "meaningful complexity" because I've tried to suggest
ways in which the game can be complex without sacrificing
accessibility and intelligibility.
1. Item usage commands, ie throw, quaff, zap, activate, etc.
Interesting things surface when all items can be used in multiple
ways. For example, potions can be thrown, quaffed, or their energy can
be absorbed to grant the character MP. Wands can be thrown, zapped, or
likewise absorbed to grant MP. This approach is better the more
integrated it is, as many commands applying to as many objects as
possible, without being ridiculous.
2. Player choices. Some games, like Crawl, make the choice of class
and race into a different gameplay experience, for example a mummy and
a troll produce a different game. An assassin and a mage produce a
different game. If a game has 10 new skills and spells to choose from
each level up, the choice should lead directly to a different gameplay
experience. Make all other choices randomly.
3. Inventory management. Durability, large inventories, and
encumberance can make inventory management into a time-consuming
chore. One solution is to reduce the inventory to core, essential
items. The player has to choose what is most likely to be helpful, and
then eliminate the items that are not chosen, so the player doesn't
feel penalized for not creating stashes to transport items back and
forth between a safe place and the action.
4. Item materials. If an item has a material, it should have some
unique relevance in combat, for example werewolves can only be hit by
silver weapons. Also, if each item material has its own pros and cons,
the choice seems more relevant to the player's experience, as opposed
to the materials hierarchies in many games, where a certain material
is better than other materials in every way.
5. Body parts. Body parts can be a real drag if a slight blow to a
crucial body part effectively ends the game. Players should have the
option of making a sacrifice, such as using a limited item or spell,
to heal mortal blows to crucial body parts.
6. Monster variety. Having a large variety of monsters is great, but
only if there is significant difference between each monster type. The
fascination of a small number of monsters that need very different
strategies to defeat outweighs the glamour of thousands of monotonous
monsters types.
My conclusion is that complexity can be frustrating if it doesn't have
some proportional relevance in the game world. Another problem is that
when complexity is combined with random elements, the chance of
creating an unwinnable scenario grows logarithmically. Also, if
complexity is not intelligible, it can steepen the learning curve
dramatically.
Numeron
> I like playing RL's that are built around the concept of simplicity
> because they're more accessible. The first play is more enjoyable. And
> players that have a good first impression are more likely to come back
> and play again.
> However, complexity produces a gameplay experience that's more likely
> to be enjoyed after a number of plays and deaths. This is, of course,
> essential to a game with permadeath. The game must be replayable.
Its possible to have simplicity and complexity in a roguelike at once
through balance. For the first area/few levels etc, the choices can be
simple and limited along with the item drops and monsters. By the time
the player has learnt all about everything that can be done with the
section, they should be good enough at the game to progress to the
next complexity level, where they are given new things to make it
exciting again. Those who first get into the game are happy because
its simple and straightforward, and those who get far in the game are
happy because they are constantly given new things to try out.
With roguelikes its difficult though because most of the extended
commands and features need to be there from the start so that their
existance actually makes sense (ie its silly only allowing a player to
start #dipping once they reach level 5).
-Numeron
Pointless
wrote:
>
> Its possible to have simplicity and complexity in a roguelike at once
> through balance. For the first area/few levels etc, the choices can be
> simple and limited along with the item drops and monsters. By the time
> the player has learnt all about everything that can be done with the
> section, they should be good enough at the game to progress to the
> next complexity level, where they are given new things to make it
> exciting again. Those who first get into the game are happy because
> its simple and straightforward, and those who get far in the game are
> happy because they are constantly given new things to try out.
>
> With roguelikes its difficult though because most of the extended
> commands and features need to be there from the start so that their
> existance actually makes sense (ie its silly only allowing a player to
> start #dipping once they reach level 5).
>
> -Numeron
Also it's makes early game boring for advanced players. Maybe it's
possible to have a persistent world like in Dwarf Fortress, but it
gets more complex the farther the player gets into it?
Numeron
> Also it's makes early game boring for advanced players. Maybe it's
> possible to have a persistent world like in Dwarf Fortress, but it
> gets more complex the farther the player gets into it?
Actually, this reminds me of those console fighting games where you
can unlock new characters once you've completed certain challenges.
Perhaps it might work if once you've done certain things in the game
new spells, items, monsters and soforth unlock and could become
present in every game from then on? a perfect haven for boundless
easter eggs :D
-Numeron
Billy Bissette
news:3b88a0ac-1bfc-41e9...@b30g2000prf.googlegroups.com:
> With roguelikes its difficult though because most of the extended
> commands and features need to be there from the start so that their
> existance actually makes sense (ie its silly only allowing a player to
> start #dipping once they reach level 5).
Entirely theoretical and not something I'm suggesting, but:
First code the command display screen to only show "available"
commands. Or perhaps show all commands, but all unavailable ones
are greyed out.
Second, bring commands into the game in some sort of order. The
most basic would be to bring them in the first time the player picks
up a related item. However, you could also design your game so that
certain items don't even show up until certain points in the game.
For example (if you don't have town shops that sell them), wands
might not can appear until dungeon level 3, scrolls on dungeon level
2, staves on dungeon level 4, etc.
Optionally, a colored command display screen could make the
distinction between commands that haven't come into play yet and
commands that will not come into play for the current character.
A warrior that hasn't found a wand will have the "use wand" command
greyed out, while "cast magic" might be dark red to show that he'll
never be able to use that command.
Simplifying and unifying your command set can also help. Fewer
unique commands means an easier job for the player learning them.
(Particularly early in a game, where a player has to constantly
refer to the command display just to find out how to use or do what
they want.) For example, a decent amount of Angband's key commands
could be combined into a single "use object" command. While this
won't ever happen with Angband, it could be done in a new game.
So maybe you'd have a game where you had a "use" command along
with "drop" and "throw." When you first find a potion, the game
tells you that you can drink(use) it for an unknown effect on
yourself, or throw it for an unknown effect on a target. Find a
wand, and it tells you that you can use it to fire an unknown
magical attack at a target. Or whatever.
Ido Yehieli
>
> Simplifying and unifying your command set can also help. Fewer
> unique commands means an easier job for the player learning them.
> (Particularly early in a game, where a player has to constantly
> refer to the command display just to find out how to use or do what
> they want.) For example, a decent amount of Angband's key commands
> could be combined into a single "use object" command. While this
> won't ever happen with Angband, it could be done in a new game.
I find it hard to understand why this is not standard, because
gameplay-wise there really is little to no difference between
quaffing, zapping, using, fueling, reading, etc..
-Ido.
Paul Donnelly
Presumably because it is presumed to be helpful to have a set of
inventory filters within easy reach, and because having two ways to
access the same feature would be poor interface design. Granted, the
concept could use some streamlining.
Ido Yehieli
>
> Presumably because it is presumed to be helpful to have a set of
> inventory filters within easy reach, and because having two ways to
> access the same feature would be poor interface design.
Why is having 2 ways to access the same feature be poor interface
design? For example, is being able to use both 'h' and the left arrow
to move left a bad interface design?
-Ido.
corremn
Tutorial features work best. Either in-game like in crawl or a
separate tutorial side game like in POWDER ( i think powder has one).
Paul Donnelly
> On Sep 26, 8:31 am, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>>
>> Presumably because it is presumed to be helpful to have a set of
>> inventory filters within easy reach, and because having two ways to
>> access the same feature would be poor interface design.
>
> Why is having 2 ways to access the same feature be poor interface
> design?
Because it interferes with habituation.
>For example, is being able to use both 'h' and the left arrow to move
>left a bad interface design?
>
> -Ido.
It's on the dodgy side, yes. But since there are several competing
standards, each with dedicated fans, I don't see any way to get around
it.
Pointless
wrote:
> Ido Yehieli <Ido.Yehi...@gmail.com> writes:
> > Why is having 2 ways to access the same feature be poor interface
> > design?
>
> Because it interferes with habituation.
>
> >For example, is being able to use both 'h' and the left arrow to move
> >left a bad interface design?
>
> > -Ido.
>
> It's on the dodgy side, yes. But since there are several competing
> standards, each with dedicated fans, I don't see any way to get around
> it.
I'm a big fan of activating hotkeys from the help screen. For example,
the player can press "?x" instead of just "x". It allows the player to
learn the hotkey, but since the same key needs to be pressed, it
doesn't interfere with habituation. I'm sorry if I keep mentioning
this, but I would really like to see this feature in a lot more RLs.
Help should be a menu where players can see all the choices available
to them as well as make the choices.
And there's no problem with implementing all the movement key sets
because a person that uses one isn't going to use another one. And if
they do, they're pre-habituated, so there's no problem.
Ido Yehieli
> Ido Yehieli <Ido.Yehi...@gmail.com> writes:
>
> > design?
>
> Because it interferes with habituation.
>
Please explain. Having to ways to do something doesn't mean the
player won't choose one way and stick to it, it just means different
players will choose different ways to stick to.
Ido.
David Damerell
>2. Player choices. Some games, like Crawl, make the choice of class
>and race into a different gameplay experience, for example a mummy and
>a troll produce a different game. An assassin and a mage produce a
>different game. If a game has 10 new skills and spells to choose from
>each level up, the choice should lead directly to a different gameplay
>experience. Make all other choices randomly.
Or nonexistent.
The other thing here is not to drown the novice in options they don't
understand. Crawl's tutorial helps out here by familiarising the novice
with three plausible race/class combos.
>silver weapons. Also, if each item material has its own pros and cons,
>the choice seems more relevant to the player's experience, as opposed
>to the materials hierarchies in many games, where a certain material
>is better than other materials in every way.
On the other hand, an ordering of material quality is a good thing in
games with a long equipment optimisation/improvement game, like Angband.
It also can reduce the identification problem - the material (and
workmanship) of an item might be immediately apparent, and a generous
designer might guarantee that no-one is making magic poorly-crafted bronze
swords...
>5. Body parts. Body parts can be a real drag if a slight blow to a
>crucial body part effectively ends the game. Players should have the
>option of making a sacrifice, such as using a limited item or spell,
>to heal mortal blows to crucial body parts.
Or skip body parts altogether. Combat crapshoots in a typical roguelike
(permadeath, many combat encounters) don't work, and the first thing
anyone does with a body part system is to make 5% of hits head hits for a
squillion points of damage.
Having said that, here's an idea; body parts, but only temporary
afflictions from criticals on them. Most hits would just be hits, but a
subset would have an explicit location - a head hit would daze you for a
few turns, a leg hit slow movement, an arm hit temporarily disable use of
weapon/shield. That would make for flavourful combat, but the temporary
afflictions would be pitched at a similar difficulty to other temporary
status effects imposed by monsters - a nuisance, but just an unexpected
nuisance to respond to with clever play.
>fascination of a small number of monsters that need very different
>strategies to defeat outweighs the glamour of thousands of monotonous
>monsters types.
In particular, when you think of a new kind of monster and contemplate
adding a fire/cold/water/air/energy/light/dark/nexus/cheese flavour, step
away from the keyboard. Once you've got four kinds of elementals you're at
quota - stop. (Also, some games - not to be all squee POWDER - make the
elementals genuinely different, not just four different colours of
speedbump).
--
David Damerell <dame...@chiark.greenend.org.uk> Oil is for sissies
Today is Sunday, September - a weekend.
Billy Bissette
4b035c...@d70g2000hsc.googlegroups.com:
To me, yes. But I'm one of the people that believe Roguelikes are
too often pointlessly overloaded on key usage. Adding a general "use"
key binding to an interface that has ten different specific use keys
isn't a solution, it is just more key clutter.
Movement keys are a stickier issue. I never liked letter key
movement, even before keyboards started coming with number pads.
Number pad is easier to learn, but there are still machines where
number pad movement isn't a viable or even possible option. And
arrow key can't do decent diagonals.
Billy Bissette
9448-f63...@2g2000hsn.googlegroups.com:
It has been debated more than once on the Angband news group.
Beyond "We just like it that way," it mainly boils down to an
inventory filter and a safety feature.
Being an inventory filter is obvious.
It is considered a safety feature because it can catch at least
some mistakes made by shifting inventory letters. I'm not fond of
that claim because it isn't perfect protection. (If you have two
wands and your inventory shifts, then you'll either get a fail or
zap the wrong wand.)
Macro usage figures in somewhat as well.
I think the whole Angband system could be retooled to a general
"use" command while maintaining safety features and inventory
filters, but it would be work and most people are happy with the
current system anyway. Personally, I'd probably run with a
general "use" command and allow key binding commands that add
filtering. So you could bind "q" to "use [potion]" if you really
wanted to. Or even bind it to filter only certain potion types.
(Actually, my ideal system is rather a bit more complex.)
Pointless
wrote:
> In particular, when you think of a new kind of monster and contemplate
> David Damerell <damer...@chiark.greenend.org.uk> Oil is for sissies
> Today is Sunday, September - a weekend.
STOP RIGHT THERE! *feverishly codes a cheese elemental into his
project*
Darren Grey
> Simplifying and unifying your command set can also help. Fewer
> unique commands means an easier job for the player learning them.
> (Particularly early in a game, where a player has to constantly
> refer to the command display just to find out how to use or do what
> they want.) For example, a decent amount of Angband's key commands
> could be combined into a single "use object" command. While this
> won't ever happen with Angband, it could be done in a new game.
I played an online roguelike recently that uses a unified key system -
the 'e' key is used for equipping items, using items, spellcasting
(which is all from scrolls), etc. It worked rather well, and was
absolutely necessary with the real-time gameplay. Requires a unique
and simple inventory system though.
--
Darren Grey
Paul Donnelly
One might hope it would happen that way. Even if it does, when does
the choosing phase end, and the sticking phase begin? How much time
has the player wasted fiddling with different approaches that could
have better been spent mastering a firmer interface? Will the player
even play the game that much?
Paul Donnelly
> On Sep 26, 11:29 am, Paul Donnelly <paul-donne...@sbcglobal.net>
> wrote:
>> Ido Yehieli <Ido.Yehi...@gmail.com> writes:
>> > Why is having 2 ways to access the same feature be poor interface
>> > design?
>>
>> Because it interferes with habituation.
>>
>> >For example, is being able to use both 'h' and the left arrow to move
>> >left a bad interface design?
>>
>> > -Ido.
>>
>> It's on the dodgy side, yes. But since there are several competing
>> standards, each with dedicated fans, I don't see any way to get around
>> it.
>
> I'm a big fan of activating hotkeys from the help screen. For example,
> the player can press "?x" instead of just "x". It allows the player to
> learn the hotkey, but since the same key needs to be pressed, it
> doesn't interfere with habituation. I'm sorry if I keep mentioning
> this, but I would really like to see this feature in a lot more RLs.
I hadn't seen you mention it before, but it's a good idea.
Ido Yehieli
It's all a numbers game - the question is what do you gain more from -
having both the general use key and the specific filter keys and make
the player choose or have just one and get the disadvatages mentioned
above (i.e. selecting an approach that is either better for advanced
user or for novices but for both).
-Ido.
Paul Donnelly
You apply yourself to figuring out an approach that will work better
for both, such as the help system Pointless suggested, filters that
are integrated with the "general use key" system, or something
entirely different that I haven't thought of. And if you want to do a
really good job, you get some guinea pigs together to find out
empirically which of those is the best choice.
Personally, I think having filters is unnecessary when you've got a
fairly small, sorted inventory, but YMMV.
Trying to implement two parallel UIs, one for beginners and one for
experts, is the worst design decision of all. Now you've set up a
situation where new users become expert at using a system not designed
to be good in the long run, and they have to drop every habit they
have learned and learn a whole new set if they want to play the game
fluently. But actually doing so would require unearthly discipline --
what kind of person can just drop their interaction habits to learn a
new set? What's going to happen is that they'll reflexively use the
newbie controls much of the time, learning the expert controls much
more slowly than they would have had they simply learned the expert
controls from the start. Throwing them into a newbie ghetto during
their formative phase was not a favor.
Ray Dillinger
> Movement keys are a stickier issue. I never liked letter key
> movement, even before keyboards started coming with number pads.
> Number pad is easier to learn, but there are still machines where
> number pad movement isn't a viable or even possible option. And
> arrow key can't do decent diagonals.
I pay attention in dungeon generation to ensure that no diagonal
movements are ever required to negotiate an opening.
One of the game options is "laptop mode" in which neither you,
nor the monsters, can move diagonally. This is supposed to make
it "fair" that you're choosing to limit yourself to orthogonal
movement only.
The gameplay difference was supposed to be fairly subtle, but it's
not really. It makes the game definitely harder because you can't
specify diagonal directions for opening doors either, and that
puts you in more direct line of fire from beasties beyond doors
when you open them. This becomes particularly relevant when the
beasties in question have ranged weapons and the room is big;
you may be in direct line of fire of, say, ten as opposed to two
if you open the door head-on.
I could iron out the differences by changing creature AI so
beasties with ranged weapons stupidly block each other near
doors by crowding close, or a couple of other things, but I'm
more likely to drop "laptop mode" entirely, and use numbers
entered from the top row of the keyboard for diagonal movement.
Looking at keystrokes through ncurses, my game can't tell the
difference anyway.
Bear
Ray Dillinger
> I think the whole Angband system could be retooled to a general
> "use" command while maintaining safety features and inventory
> filters, but it would be work and most people are happy with the
> current system anyway. Personally, I'd probably run with a
> general "use" command and allow key binding commands that add
> filtering. So you could bind "q" to "use [potion]" if you really
> wanted to. Or even bind it to filter only certain potion types.
I'm of the opinion that both the noun, and the verb, in a sentence
are important, and things can and should have many possible uses.
I like having a rule that you can see invisible creatures when
looking through (as opposed to wearing) an invisibility ring
for example, or having potions that can be thrown, drunk, lit,
poured, used as sling ammo, or used for dipping other things in.
A "use" command makes sense in a simpler game where there's only
one thing you can do with a given item.
Maybe I should consider inventory-subset selection commands though,
especially since inventory is limited mainly by weight and volume
rather than slot. Characters who collect small useful things can
have a huge inventory, and filters can be useful.
Bear
Billy Bissette
$742e...@news.sonic.net:
What about Shift or Control + arrow keys for diagonals? Not
perfect, but it is at least an option. Unless you're already
using those for things like running or sneaking or whatever.
Ray Dillinger
> Ray Dillinger <....@sonic.net> wrote in news:48dd8622$0$33597
>> One of the game options is "laptop mode" in which neither you,
>> nor the monsters, can move diagonally. This is supposed to make
>> it "fair" that you're choosing to limit yourself to orthogonal
>> movement only.
> What about Shift or Control + arrow keys for diagonals? Not
> perfect, but it is at least an option. Unless you're already
> using those for things like running or sneaking or whatever.
Once again; I'm using ncurses. I can't tell the difference
between arrow and shift-arrow or control-arrow. I could use
a "local" IO function, but then the game wouldn't play over a
telnet/ssh connection.
Bear
Ido Yehieli
>
> Once again; I'm using ncurses. I can't tell the difference
> between arrow and shift-arrow or control-arrow.
Yes you can, look at the md_readchar function Nicholas Kisseberth's
mdport code (among other places, you can find it in CryprRover:
http://code.google.com/p/cryptrover/source/browse/trunk/mdport.c?spec=svn31&r=31
- look at the last function).
-Ido.
Thomas E. Dickey
ncurses can only use the data in the terminal description, which gives
a list of the escape sequences (characters) sent by a key.
Some terminals (such as xterm...) can send different sequences,
and ncurses can return a unique code for them. That's an extension
(no predefined codes such as KEY_CTRL_DOWN), but is available at
runtime, e.g., using key_defined() and define_key().
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Inuga...@gmail.com
Are you talking about TwilightMMORL? It has a basic MMO setup, where
inventory is maintained in one place and often used commands are
placed in easily recognizable keys ('e' for equip from roguelikes, F#
keys for skills from MMOs).
I actually think having a "rebinding" option or a command menu (press
0 to open up a 1-9 menu for commands and categories of commands) would
simplify many things for the player.
Key rebinding isn't necessarily used in roguelikes because playing a
RL doesn't require reflexes (which requires a convenient location of
keys). Currently players have to learn where their keys are at, rather
than binding their own combination of keys to commands they're most
comfortable with.
Command menus were originally implemented through scripts to make
quick and easy communication in situations that are less than prime.
It's often associated with the FPS genre. It's relatively easy to
understand, press a key to open/close the menu (let's take 0 for
example) and then other keys would select choices in that menu (1-9).
Options bound to 1-9 are usually associated with categories (Items,
Skills, Say), menu navigation and commands (opening up certain menus
like the inventory, equip, zap, cast, stats, prayer pages in a
roguelike). Currently, players need to memorize what command is at
what key instead of pressing a simple combination of numbers with a
visual aid on screen. If you want an example, I'd suggest Urban Terror
and check out its radio commands (pretty simple) and similarly Counter
Strike (buy menu and radio commands). There was also several sets of
scripts for Q3A that let the users access hundreds of console commands
through alot of bind manipulation.
Ray Dillinger
> On Sep 27, 10:18 am, Ray Dillinger <b...@sonic.net> wrote:
>>
>> Once again; I'm using ncurses. I can't tell the difference
>> between arrow and shift-arrow or control-arrow. I could use
>> a "local" IO function, but then the game wouldn't play over a
>> telnet/ssh connection.
[The last sentence was clipped. I've restored it for clarity.]
> Yes you can, look at the md_readchar function Nicholas Kisseberth's
> mdport code (among other places, you can find it in CryprRover:
>
I invite you to inspect the code, or test Cryptrover over a
telnet connection. In no case does this function allow
distinguishing shift and control versions of keypad keys while
using a telnet connection. While this is a good job of
maximizing portability and will work on many different kinds of
(local) consoles, telnet does not in fact send different
characters for left, shift-left, and control-left, so there
is no distinguishing them over a telnet connection.
And preserving playability over telnet/ssh is important to how
I want to use the game - hence I lose nothing by using ncurses.
Haven't you ever noticed that, eg, emacs, loses its control-
direction and shift-direction commands when you're using it
over ssh/telnet as opposed to using it locally? This is why.
Bear
Numeron
> One of the game options is "laptop mode" in which neither you,
> nor the monsters, can move diagonally. This is supposed to make
> it "fair" that you're choosing to limit yourself to orthogonal
> movement only.
>
> The gameplay difference was supposed to be fairly subtle, but it's
> not really. It makes the game definitely harder because you can't
> specify diagonal directions for opening doors either, and that
> puts you in more direct line of fire from beasties beyond doors
> when you open them. This becomes particularly relevant when the
> beasties in question have ranged weapons and the room is big;
> you may be in direct line of fire of, say, ten as opposed to two
> if you open the door head-on.
Not just this but the ability to pillar dance without a pillar. If you
have 4 free tiles in the centre of a room and you are the same or
greater speed than the mob who is next to you, you can simply move to
the diagonal tile next to them, they move next to you, move to
diagonal next to them, they move next to you, etc... I find it an
important part of how I play POWDER.
-Numeron
David Damerell
> To me, yes. But I'm one of the people that believe Roguelikes are
>too often pointlessly overloaded on key usage. Adding a general "use"
>key binding to an interface that has ten different specific use keys
>isn't a solution, it is just more key clutter.
On the other hand I think the inventory - select potion - quaff this potion?
interface idea isn't a bad one.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is First Brieday, September.
Soyweiser
wrote:
> Quoting Billy Bissette <bai...@coastalnet.com>:
>
> > To me, yes. But I'm one of the people that believe Roguelikes are
> >too often pointlessly overloaded on key usage. Adding a general "use"
> >key binding to an interface that has ten different specific use keys
> >isn't a solution, it is just more key clutter.
>
> On the other hand I think the inventory - select potion - quaff this potion?
> interface idea isn't a bad one.
> --
> Today is First Brieday, September.
Basically there are two different approaches that would work imho. The
action - item approach (verb first) or the item - action approach
(noun first).
The first one is like nethack, you first select what you want to do
(dip for example), then you select what you want to do it with (Dip
the potion.) With an optional step if your what allows for different
or multiple targets (Dip the potion in the moat).
The second is that you select the item first. View the inventory,
select an item to use (potion), and a list of allowed options for this
item is shown (quaff,dip,throw,wield,read,drop etc).
(There is also a third option, and that is to do away with all this
item complexity, weapons can only be wielded, armor worn, potions
drank, scrolls read, and nothing else. Then you would only need the
use key for all these usages. But that would be a Diablolike, and not
a roguelike, it would fail the complexity factor from the Berlin
definition. And it would make a roguelike a lot less interesting
imho.)
The benefit of the action first approach is that you can still allow
innovative item usage without cluttering the GUI. When you normally
choose the 'wield' action, you get a list of items that you can
normally wield, with the possibility of wielding additional items that
are not normally wielded as an advanced action. For the newbie it is
good to see at first only the short list of items that are normally
useful to wield (Weapons only). While the advanced player can also
wield different items for additional effects (wielding a potion for
example.) The difficulty of course is how to teach the advanced option
to the newbie.
To solve this you could also have a use option that shows all the
possible actions (This is the same as a command menu mentioned by
inugami, above, 'use'->select action -> select item). But this will
clutter the GUI. (And to quote the great philosopher James Hetfield
"cluttered GUI Bad, Beer Good").
The benefit of the second approach is that it is a lot easier to learn
(which may not be easy to use in the long run). A new player is
instantly told which actions are possible. But this could create
either a gui overload (all possible options are shown), or would
provide spoilers (The lamp with the rub command is the magical lamp).
I think this could be solved by some sort of extended actions option.
Normally it shows only the default options (select food->
drop,eat,smell,throw,extended actions) and selecting extended actions
shows all other actions that are possible.
--
Soyweiser
Soyweiser
> <snip>
> drop,eat,smell,throw,extended actions) and selecting extended actions
> shows all other actions that are possible.
>
> --
> Soyweiser
Somehow I failed to see the much larger topic about this subject.
Sorry.
--
Soyweiser
Radomir 'The Sheep' Dopieralski
Soyweiser wrote:
> The benefit of the second approach is that it is a lot easier to learn
> (which may not be easy to use in the long run). A new player is
> instantly told which actions are possible. But this could create
> either a gui overload (all possible options are shown), or would
> provide spoilers (The lamp with the rub command is the magical lamp).
> I think this could be solved by some sort of extended actions option.
> Normally it shows only the default options (select food->
> drop,eat,smell,throw,extended actions) and selecting extended actions
> shows all other actions that are possible.
It's very important to make the interface easy to explore without
having to read the manual. The verb-noun approach is bad at this,
but there is a number of techniques that greatly imporove it. One
such technique that I've seen in action -- and liked very much --
was displaying short hints about possible actions the first time
you were in a situation to use them:
There is a pink potion lying here [press g to pick it up]
You pick up a pink potion (c) [press q to quaff it, press d to drop it]
What do you want to quaff? [press space to cancel]
c) pink potion
Cancelled
There is a longsword lying here
You pick up a longsword (d) [press w to wield it]
What do you want to wield? [press - to go empty handed]
b) mace (weapon in hand)
d) longsword
You are now empty handed
There is a down staircase here [press > to descend]
Note how each message also contains the names of the objects
involved, and their inventory slots.
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
"Whenever you find yourself on the side of the majority,
it's time to pause and reflect." -- Mark Twain
David Damerell
>>On the other hand I think the inventory - select potion - quaff this potion?
>>interface idea isn't a bad one.
>action - item approach (verb first) or the item - action approach
>(noun first).
Thank you, Captain Obvious.
--
David Damerell <dame...@chiark.greenend.org.uk> Kill the tomato!
Today is First Gouday, September.
Darren Grey
<n...@sheep.art.pl> wrote:
> It's very important to make the interface easy to explore without
> having to read the manual. The verb-noun approach is bad at this,
> but there is a number of techniques that greatly imporove it. One
> such technique that I've seen in action -- and liked very much --
> was displaying short hints about possible actions the first time
> you were in a situation to use them:
>
> There is a pink potion lying here [press g to pick it up]
> You pick up a pink potion (c) [press q to quaff it, press d to drop it]
> What do you want to quaff? [press space to cancel]
> c) pink potion
> Cancelled
> There is a longsword lying here
> You pick up a longsword (d) [press w to wield it]
> What do you want to wield? [press - to go empty handed]
> b) mace (weapon in hand)
> d) longsword
> You are now empty handed
> There is a down staircase here [press > to descend]
>
> Note how each message also contains the names of the objects
> involved, and their inventory slots.
That is extremely good I must say - what is it from? Could easily be
worked into a tutorial mode of the game, or separate flags for each
action that make the message only appear once across the whole
player's experience (with an option to turn it off of course).
--
Darren Grey
Paul J Gans
>On Sep 26, 7:29 am, Billy Bissette <bai...@coastalnet.com> wrote:
>>
>> Simplifying and unifying your command set can also help. Fewer
>> unique commands means an easier job for the player learning them.
>> (Particularly early in a game, where a player has to constantly
>> refer to the command display just to find out how to use or do what
>> they want.) For example, a decent amount of Angband's key commands
>> could be combined into a single "use object" command. While this
>> won't ever happen with Angband, it could be done in a new game.
>I find it hard to understand why this is not standard, because
>gameplay-wise there really is little to no difference between
>quaffing, zapping, using, fueling, reading, etc..
Yeah there is. When you are playing rapidly it greatly increases
your chance of hitting the wrong key(s) and thus getting some really
interesting unintended results.
;-)
--
--- Paul J. Gans
Paul J Gans
>> On Sep 26, 8:31 am, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>>>
>>> Presumably because it is presumed to be helpful to have a set of
>>> inventory filters within easy reach, and because having two ways to
>>> access the same feature would be poor interface design.
>>
>> Why is having 2 ways to access the same feature be poor interface
>> design?
>Because it interferes with habituation.
>>For example, is being able to use both 'h' and the left arrow to move
>>left a bad interface design?
>>
>> -Ido.
>It's on the dodgy side, yes. But since there are several competing
>standards, each with dedicated fans, I don't see any way to get around
>it.
I'd say that there are several competing keyboard designs and as
a result it is a feature.
I use the arrow keys at home and the letter keys on my laptop. It
has become quite automatic.
But in general I agree with you. The numeric keypad keys are a
special case.