Immersion in roguelikes
Radomir 'The Sheep' Dopieralski
== Immersion in roguelikes ==
Created 2007-01-07
I'm not a fan of elaborate menu-based interfaces for roguelike games,
especially ones operated using the cursor keys or mouse, and I've said on
various occassions on this newsgroup. In search of better solutions I've
analyzed what it is exactly that makes the menus so awkward, at least for
me? Apart from obvious "mechanical" flaws that make it harder to habituate
and memorize the menus, there seems to be something "artifical" in them
that feels jarring during the game.
And then I realized: The Cursor!
There is something magical in the way we can project and channel our
attention and focus it on an abstract object on our screens, basically
**becoming** it for the duration of performed task. Even when editing text
or selecting something from the menu -- we are the cursor, the cursor
marks out "location" in the artifical environment, allows us to explore
it, and also acts as a proxy to channel our god-like user powers and
execute commands. We can "ride" it pretty much we would ride a bicycle --
awkward and slowly at first, but as we learn, we stop to even notice it --
it just feels natural.
There are, however, several prerequisites that need to be met before the
cursor can become an extension of our bodies. Anyone who ever worked over
a low-bandwidth telnet/ssh session, or just a very slow computer, knows it
-- the **cursor has to listen to you**. Always. No matter what. If it
"skips" your keypresses, if it does something else than you ordered it to
do (for example, as a result of misplacing your hand on the keyboard and
pressing wrong keys) -- then it's like falling off the bike. It's an
unpleasant sensation, like hitting a wall where there should be door.
Extremely annoying. Even when for some reason the cursor cannot execute
our command, it must at least "say" it -- by blinking, by beeping,
anything.
Another prerequisite is that we should always be able to anticipate the
result of a command, or -- when the command fails -- why it did so. This
is visible in some "smart" system that have "do the most obvious thing"
button, when there is a disagreement between the user and th system about
what's "the most obvious". This is also visible when there are modes and
you make a mode error -- this again feels like falling off the bike, or
being "thrown out of the application". How can something become an
extension of your body, when it has a life of its own?
Finally, the last prerequisite: "there can be only one". There can be only
one active cursor at a moment. This is sometimes tricky and not
immediately obvious -- as the cursor can change its shape and function,
our "channeled soul" can jump between several incarnations of the cursor
-- but ultimately, we can "posses" only one of them, and we have to do it
"directly". Using mouse to press buttons to move cursor is totally
uncomfortable and resembles carrying a bicycle on your back morethan
riding it.
Now, do you see why the menus (the "modern", cursor-based ones) are so
evil? They rip you from the game's world, and teleport your soul from the
avatar you was controlling to some abstract cursor living in a dead world
of clean-cut menus and dialogues, shaped into an antiseptic tree
structure. As you play and the game becomes more complicated, you spend
more and more time in this nightmare world of interface, returning to the
beautiful and interesting world of game practically only to move your
avatar a few squares, where you can fall in coma again and explore the
menus.
Of course, the "abc" menus are not so great either. They have an advantage
of not displaying any cursor explicitly -- so that there is a chance that
your mind won't make the jump. Alas, your mind is not taht easily fooled!
If there is **anything** suggesting "position" in the menu -- for example,
if the menu itself is scrolled or multilevel (you can "enter" its items)
-- this will trigger the "cursor" perception, even when the cursor is only
imagined and not displayed on the screen.
So what can be done? Obviously, avoid menus and other uses of cursors (for
argetting, for example), have at most one-level menus displayed on the
same screen where the main view is (switching screens is also perseived as
moving around). Try to make most actions use direct manipulation of the
in-game objects. Easy to say, eh?
I will give an example -- a "dip" command present in some roguelike games.
It's pretty complicated, as it requires selecting at least two items --
hard to do without a second menu. Now, how do we make a "dip" command that
uses direct object manipulation instead? One possibility is a "spill"
command, that will make the avatar spill the potion on the ground. Now,
drop the items you want to "dip", and spill the potion on them. Simple.
You can make it even simplier -- many roguelikes have a "throw item"
command, and many of them have a rule that a thrown potion will spill on
whatever it hits and affect it. Why not just throw the potion on an item
on the ground then? And if the game doesn't allow you to target specific
floor squares -- put the items under a wall and throw the potion against
that wall. Isn't it a lot much fun than wading through the menus?
You have probably noticed this by now -- throwing requires targetting,
modern roguelikes often use cursor for targetting. Rogue was nicer -- it
just prompted you for a direction. Of course, this greatly limited your
choices, as you had to line up with the target -- not such a bad
meta-game, but you might not want it in your roguelike. What can be done?
Maybe just a menu (one-level, abc-style) listing all the potential
targets? I'm you can come up with even better ideas!
Why don't you try and make your game's interface a little more immersive?
--
Radomir `The Sheep' Dopieralski
Besides a mathematical inclination, an exceptionally good mastery of one's
native tongue is the most vital asset of a competent programmer. [Dijkstra]
Mario Donick
Instead of getting an inventory list, pressing "i" could enable a
special inventory mode in which you don't leave the main view. Instead,
next to your @ avatar the items of your inventory a displayed. With the
cursor keys you can switch between the different available items. On
the bottom of the screen, the name of the item is shown as text, next
to available actions.
For example:
.....
@!...
.....
cola light - [c]onsume, [d]rop, [l]ook - [ESC] Cancel
.....
@?...
.....
scroll of fire - [r]ead,[d]rop,[l]ook - [ESC] Cancel
And so on. The menu would be on the same line as other messages of the
game are shown, very unobstrusive.
Perhaps I'll try this in LambdaRogue...
Mario
Christophe Cavalaria
I'm sure that players will be happy to know that they cannot anymore dip an
object in a potion without wasting it completly by throwing it at a wall :)
As for the menu listing all potential targets, it is flawed too since the
act of targetting really means to chose a point in space, any point in
space. What will you do when the user finds a wand of stone to mud and
wants to target that little section of wall there? And what about timed
effect spells where the player will want to throw that delayed blast
fireball somewhat before that monster charging at him. Or controled
teleport spells? Or controlled location summon spells?
Radomir 'The Sheep' Dopieralski
Mario Donick wrote:
> Hmm...
>
> Instead of getting an inventory list, pressing "i" could enable a
> special inventory mode in which you don't leave the main view. Instead,
> next to your @ avatar the items of your inventory a displayed. With the
> cursor keys you can switch between the different available items. On
> the bottom of the screen, the name of the item is shown as text, next
> to available actions.
Yes. Or a more comfortable interface, similar to that used in the
Secret of Mana (Seiken Densetsu) games, where you have a ring of items
displayed, and pressing keys rotates the ring (you could have a list
like this instead:
@
!!)&[ ) [=&&%
A long sword (+1, +1)
Preferably displayed right in the middle of the screen, maybe on
a different background to differentiate it from the map, best only
showing *while* a menu key is pressed, so that we don't introduce a mode.
But this in fact introduces a cursor (sure, it keeps the shape of your
avatar...)! However, it's inferior to an abc-menu in several ways,
including an internal state (hte menu doesn't always start at the same
position) and worse display of information (you only see details of a
single item at a time). Whether these disadvantages are important -- is
a question of testing and experimenting.
Note also, that you can have separate menu commands (and so also rings)
for wielding, wearing, quaffing, etc. Switching between your sword, bow
and pickaxe becomes just a single command.
Radomir 'The Sheep' Dopieralski
Christophe Cavalaria wrote:
> Radomir 'The Sheep' Dopieralski wrote:
<snip>
>> Why don't you try and make your game's interface a little more immersive?
> I'm sure that players will be happy to know that they cannot anymore dip an
> object in a potion without wasting it completly by throwing it at a wall :)
The "spill" command can still take into acocunt the size and number of
items on the floor and "use up" the potion accordingly. But that's not the
point -- the point is that one can design the game (not only its
interface!) while keeping in mind these simple rules, it doesn't require a
lot of sacrifice.
> As for the menu listing all potential targets, it is flawed too since the
> act of targetting really means to chose a point in space, any point in
> space.
Of course it's flawed. It's just one possible solution off the top of my
head. On the other hand, targetting is not really an act of chosing a
point in space -- it's an act of chosing a direction, and in case of
roguelike games, only a few directions are really interesting at a time.
Why require from the player to enter more information than is needed?
> What will you do when the user finds a wand of stone to mud and
> wants to target that little section of wall there?
This is easily handled by the Rogue's 8-way directions.
> And what about timed
> effect spells where the player will want to throw that delayed blast
> fireball somewhat before that monster charging at him.
A what? Honestly, I don't know what are you talking about here, can
you give an example from an existing roguelike game to illustrate it?
> Or controled teleport spells? Or controlled location summon spells?
One cannot just design a good user interface and then slap it over any
existing system and expect it to work. To create a good UI, the whole
system must be designed in accordance with how the users think and
perceive the tasks to be performed.
So, you can't just fancy any arbitrarily complicated magical spell and
expect to find a good user interface for it. In particular, the whole
concept of various teleportation spells is in conflict with our innate
perception of space -- that's what makes them so special and miraculous.
So, you either have an "out of this world" interface for the "out of this
world" spells, or you make them less unnatural. Of course, that's
a gameplay decission, but here are some ideas for more natural
teleportation spells, arguably much less powerful than the "default" one:
* A ninja smoke bomb. Throw it, and it teleports you to where it fell.
* A "recall" system, where you mark some place (probably by dropping
some magical item) and can teleport back to it (probably by using a
second item, somehow connected with the first one).
* An "astral travel" spell, which freezes the game and lets you to move
around the map, walking through the walls. Actually, if you disabled
the FOV during the walk, it would become equivalent to the "full
fledged" teleportation spell. Otherwise it's like teleport spell
connected with a mapping and detect monsters spell. The "return" can
be timed or require some action.
* A phase door spell that teleports you, say, 5 squares in specified
direction. Enough for teleporting into vaults or other rooms.
* A "magic rope" spell that teleports you to the closest stairs.
As for "controlled location summon spells", I love the "ninja smoke bomb"
idea for them -- just in a form of some djinn bottle or magical figurine.
Throw it, and it shatters, summoning the contained creature.
Christophe Cavalaria
> At Sun, 07 Jan 2007 18:22:16 +0100,
> Christophe Cavalaria wrote:
>
>> Radomir 'The Sheep' Dopieralski wrote:
> <snip>
>
>>> Why don't you try and make your game's interface a little more
>>> immersive?
>> I'm sure that players will be happy to know that they cannot anymore dip
>> an object in a potion without wasting it completly by throwing it at a
>> wall :)
>
> The "spill" command can still take into acocunt the size and number of
> items on the floor and "use up" the potion accordingly. But that's not the
> point -- the point is that one can design the game (not only its
> interface!) while keeping in mind these simple rules, it doesn't require a
> lot of sacrifice.
A possible solution would be that the dip command will make the user dip the
currently wielded item into the selection potion. Now, maybe the Nethack
style "thou can wield anything!" interface might be of some use after all.
>> What will you do when the user finds a wand of stone to mud and
>> wants to target that little section of wall there?
>
> This is easily handled by the Rogue's 8-way directions.
And of course, it's exactly the same problem than Rogue when you want to
target a monster that isn't in the 8-way directions.
>> And what about timed
>> effect spells where the player will want to throw that delayed blast
>> fireball somewhat before that monster charging at him.
>
> A what? Honestly, I don't know what are you talking about here, can
> you give an example from an existing roguelike game to illustrate it?
There's a spell like that in NWN ( and D&D I suppose ). Throw the fireball
in one space, and 3 turns later it explodes. That special fireball in
itself is much more powerful than a regular fireball which makes using it
worthwhile. You just have to time it correctly because the explosion radius
isn't that big after all. It is a matter of careful placement, timing and
oponent manipulation to make the best use of it. With a severly limited
targeting system, such spell might very well be of little use since you
lack the control required to make the best use of it.
Also, there are situations where you want to target your area of effect
spell in an empty spot because the radius makes it so that point in space
is more efficient than any point centered around a monster.
> <snip>
I have little to say against your ideas. I have played and enjoyed plenty of
games with such limitations. But in the end, you contrive the gameworld
into a simplified system for the sake of the UI. Direction doesn't mean
only 8-way, and throwing an item doesn't always mean to throw it a full
force.
But before you answer, I really like your ideas on the interface. If it was
possible to provide a trully imersive interface which still handles enouth
targeting control for the user it would be perfect.
And that's why my favorite interface types are those you find in NWN or in
an FPS : mainly mouse driven with a lot of support from the keyboard to
control the actions. The cursor/crosshair is then considered an extension
of the @, it is an important part of him and represents the point/direction
where his mind is focused. Most actions are still triggered by the
keyboard, but for those that need a "target", the current point of focus is
used to find it.
fufu
Having menus or a targeting system isn't what breaks immersion, it's
more the fact that they are generally poorly designed in that the
player has to switch to a different frame of mind to utilize them.
Personally a lettered menu ala ADOM's works best for me since that
entire game is based on the alphabet and once your brain digests a-z
it's no longer an immersion breaker to read an identification scroll,
bless an item, or even dip it in a potion. Poor interactions in
general will snap a player out of their character, and the flip side of
that is keeping enough other features of the game over the top to
distract the player. Take a game like Morrowind/Oblivion - terrible
terrible UI design across the board, and yet it doesn't prevent players
from getting sucked into that world for many hours at a time.
Overall though, it is far more important to get some usuability testing
for useful feedback to work out the real kinks in your game rather than
the ones you perceive.
Radomir 'The Sheep' Dopieralski
fufu wrote:
> Regarding immersion I don't think you give gamers enough credit.
Well, of course players will adapt to mostly **anything** :)
But why should they?
> Having menus or a targeting system isn't what breaks immersion, it's
> more the fact that they are generally poorly designed in that the
> player has to switch to a different frame of mind to utilize them.
Yes, you are right. It's the underlying mechanics that don't really
fit the game world, and the interface is just a result of that. But
please not that what I'm not advocationg are not just changes in the
interface -- it's a technique of designing your whole game around the
concepts that are easy to grasp and obvious, the in-game objects and
in-game actions, the simple spatial dependencies, etc. This is supposed
to keep the internal game logic consistent with how the users think
and expect it to behave.
Of course there is nothing so wrong in the cursor per se. Actually, it's
unavoidable in some form or another. But the problem with cursor is that
it's incredibly flexible, and allows you to design interfaces much more
complicated and reality-detached than a human mind can comfortably handle.
Obviously, the technique of designing the game is not to be understood
as the one and only true way of doing a game design. We still need puzzle
games and spreadsheet-based resource management games, and all sorts of
blends between them. I just miss the simplicity of Rogue sometimes.
> Personally a lettered menu ala ADOM's works best for me since that
> entire game is based on the alphabet and once your brain digests a-z
> it's no longer an immersion breaker to read an identification scroll,
> bless an item, or even dip it in a potion. Poor interactions in
> general will snap a player out of their character, and the flip side of
> that is keeping enough other features of the game over the top to
> distract the player. Take a game like Morrowind/Oblivion - terrible
> terrible UI design across the board, and yet it doesn't prevent players
> from getting sucked into that world for many hours at a time.
>
> Overall though, it is far more important to get some usuability testing
> for useful feedback to work out the real kinks in your game rather than
> the ones you perceive.
I'm not really **so much** concerned with usability in something that is
supposed to be challenging after all :)
Radomir 'The Sheep' Dopieralski
Christophe Cavalaria wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>> At Sun, 07 Jan 2007 18:22:16 +0100,
>> Christophe Cavalaria wrote:
>> The "spill" command can still take into acocunt the size and number of
>> items on the floor and "use up" the potion accordingly. But that's not the
>> point -- the point is that one can design the game (not only its
>> interface!) while keeping in mind these simple rules, it doesn't require a
>> lot of sacrifice.
> A possible solution would be that the dip command will make the user dip the
> currently wielded item into the selection potion. Now, maybe the Nethack
> style "thou can wield anything!" interface might be of some use after all.
That's something I was trying to avoid -- it creates some sort of
"internal environment" **inside** of the player character, making into
something much more than a tool of the player. Instead of means for
exploring the world, the avatar becomes a wolrd to explore. Soon you
need helper-slots for helper-slots for slots, like in Omega :)
I rather advocate to try and move things outside, to the actual game
world. And to also **show** it on the map rather than just describe
in the menu -- so that the player sees and understands **how** it is
done, not just **what** is done.
>>> What will you do when the user finds a wand of stone to mud and
>>> wants to target that little section of wall there?
>> This is easily handled by the Rogue's 8-way directions.
> And of course, it's exactly the same problem than Rogue when you want to
> target a monster that isn't in the 8-way directions.
Why do you target a monster with a wand of stone to mud?
Note also, that the existance of an accurate targetting system is exactly
what make th wnds of stone-to-mud and of wall-building extinct -- it's
impossible to dig a tunnel going at arbitrary angle in a roguelike.
>>> And what about timed
>>> effect spells where the player will want to throw that delayed blast
>>> fireball somewhat before that monster charging at him.
>> A what? Honestly, I don't know what are you talking about here, can
>> you give an example from an existing roguelike game to illustrate it?
> There's a spell like that in NWN ( and D&D I suppose ). Throw the fireball
> in one space, and 3 turns later it explodes. That special fireball in
> itself is much more powerful than a regular fireball which makes using it
> worthwhile. You just have to time it correctly because the explosion radius
> isn't that big after all. It is a matter of careful placement, timing and
> oponent manipulation to make the best use of it. With a severly limited
> targeting system, such spell might very well be of little use since you
> lack the control required to make the best use of it.
So, you're basically talking about a delayed-detonation bomb?
Well, you could handle them by using... uhm... delayed-detonation bombs?
> Also, there are situations where you want to target your area of effect
> spell in an empty spot because the radius makes it so that point in space
> is more efficient than any point centered around a monster.
Well, this pretty much turns it into a board game, doesn't it? Sure, board
games are fun, and we certainly need them. But the "exploration" games I'm
trying to give a recipe for are certainly fun too, even when they don't
have much place for sophisticated spell placement.
>> <snip>
> I have little to say against your ideas. I have played and enjoyed plenty of
> games with such limitations. But in the end, you contrive the gameworld
> into a simplified system for the sake of the UI.
That's not my intention. As I've written anywhere in this thread, it's not
exactly very good to worry about perfect user interface for something that
is supposed to be challenging -- it's easy to end up with a "do what I mean"
button.
On the other hand, I propose to base the game design on the user
interface, because that's simply what the user sees and that's what
defines the feel of the game. I think that this way of doing things -- that
is, start with defining how do you want the game feel (not the game
world!), and **then** create everything based on it, including all the
game world -- has a chance of producing something consistent that you
really intended.
> Direction doesn't mean only 8-way, and throwing an item doesn't always
> mean to throw it a full force.
Yes, maybe that's a good hint for a good interface then? Allow more than
8 directions?
I have one idea that I want to try once my game is back in a working
state. Sort of a fuzzy 8-directions -- that is, target the closest monster
(or other possible target, if it's, for instance, wand of digging) in the
general direction indicated. So that in this situation:
.................
.............g...
.@.............m.
.................
selecting '6' as the direction would still target the goblin. Of course,
this greatly limits the precission, as you can no longer choose between
a goblin and a mage. OTOH some tabletop games even explicitly forbid you
shooting to distant target when there is a closer threat.
> But before you answer, I really like your ideas on the interface. If it was
> possible to provide a trully imersive interface which still handles enouth
> targeting control for the user it would be perfect.
I don't think it's possible. Precise targetting is something that requires
a focus switch even in the real world. However, precise targetting is
extremly rare in the real world -- you usually target objects or areas.
> And that's why my favorite interface types are those you find in NWN or in
> an FPS : mainly mouse driven with a lot of support from the keyboard to
> control the actions. The cursor/crosshair is then considered an extension
> of the @, it is an important part of him and represents the point/direction
> where his mind is focused. Most actions are still triggered by the
> keyboard, but for those that need a "target", the current point of focus is
> used to find it.
Mouse is an interesting extesions, and it surely solves most targetting
problems -- in similar way that the keyboard with little lcd displays on
the key solves the discoverability problem of letter-command-driven interfaces.
However, it's a device that's not always available, and cannot be really
included in the design as "optional". Good mouse-driven interfaces are
totally different than good keyboard-driven ones. I think that Antoine
works on one -- maybe we could hear some more about it?
Antoine
Radomir 'The Sheep' Dopieralski wrote:
> Now, do you see why the menus (the "modern", cursor-based ones) are so
> evil? They rip you from the game's world, and teleport your soul from the
> avatar you was controlling to some abstract cursor living in a dead world
> of clean-cut menus and dialogues, shaped into an antiseptic tree
> structure. As you play and the game becomes more complicated, you spend
> more and more time in this nightmare world of interface, returning to the
> beautiful and interesting world of game practically only to move your
> avatar a few squares, where you can fall in coma again and explore the
> menus.
This reminds me so much of watching my brother play Morrowind and
Oblivion.
I'm sneaking round a labyrinth... I go round the corner into a great
hall... look an evil sorcerer! he's coming towards me and so are his
minions... A monster attacks! Aargh! Whump! I'm slashing it and it's
leaping up and attacking me...
CUT! Oh look here I am in a menu. Scrolling through ten different
'weak potions of this and that'. Tum te tum... Perhaps I'll look at my
spell list. Hmm spells. Well this is nice isn't it. I wonder if I
should go back and fight the monster? Nah I'll just keep looking at my
menu of potions for a while.
I don't know how he puts up with it.
A.
konijn_
> At Sun, 07 Jan 2007 18:22:16 +0100,
> Christophe Cavalaria wrote:
>
> > Radomir 'The Sheep' Dopieralski wrote:
> <snip>
>
> > And what about timed
> > effect spells where the player will want to throw that delayed blast
> > fireball somewhat before that monster charging at him.
>
> A what? Honestly, I don't know what are you talking about here, can
> you give an example from an existing roguelike game to illustrate it?
ToME, poison cloud.
<SNIP>
Cheers,
T.
Gamer_2k4
> special inventory mode in which you don't leave the main view. Instead,
> next to your @ avatar the items of your inventory a displayed. With the
> cursor keys you can switch between the different available items. On
> the bottom of the screen, the name of the item is shown as text, next
> to available actions.
This is what I tried to accomplish with my radial menu system, where
the list of choices are displayed around the player and a directional
keypress selects one. A better idea, as far as inventory is concerned,
is what Radomir suggested: Have a ring of items around the player, like
this:
...!...
.$.../.
.......
?..@..]
.......
.?...].
...?...
! A potion of healing [U]se [D]rop Brea[K]
Unfortunately, this idea is impractical, because inventories can get
very large. Ever seen an ADOM character dump? The tedious scrolling
to access a particular item would cancel out any increased immersion.
> And so on. The menu would be on the same line as other messages of the
> game are shown, very unobstrusive.
>
> Perhaps I'll try this in LambdaRogue...
If you can make it work, I'd definitely be interested in seeing the
implementation.
Gamer_2k4
Gamer_2k4
> idea for them -- just in a form of some djinn bottle or magical figurine.
> Throw it, and it shatters, summoning the contained creature.
My friend had a fairly innovative idea for summoning. The wizard would
select a summoning point, and a gate would open for a couple of turns,
with the monster slowly entering the current plane. This is probably
how you'd expect a summon in "real" life.
Gamer_2k4
Gamer_2k4
> Having menus or a targeting system isn't what breaks immersion, it's
> more the fact that they are generally poorly designed in that the
> player has to switch to a different frame of mind to utilize them.
> Personally a lettered menu ala ADOM's works best for me since that
> entire game is based on the alphabet and once your brain digests a-z
> it's no longer an immersion breaker to read an identification scroll,
> bless an item, or even dip it in a potion. Poor interactions in
> general will snap a player out of their character, and the flip side of
> that is keeping enough other features of the game over the top to
> distract the player. Take a game like Morrowind/Oblivion - terrible
> terrible UI design across the board, and yet it doesn't prevent players
> from getting sucked into that world for many hours at a time.
You have to remember, there's a difference between gaming and
roleplaying. The loose definition of roleplaying as it applies to
roguelikes also applies to first-person shooters, racing games, sports
games, and even strategy games (you're playing the role of a commander
or something like it). True roleplaying, where the player actually
feels like he IS the character, is very hard to accomplish. The
interfaces that some people suggested help maintain mental focus on the
player character, but that's not a very large part of playing
roguelikes.
Roguelikes are about gaming and gameplay. Therefore, as fufu said, the
menus in ADOM are very effective. The entire game consists, not of
roleplaying, but of keypresses and strategic planning. Adding 2 more
keypresses to perform a specific action remains within the scope of the
player's mental focus. It streamlines the roguelike for gameplay and
therefore is a good interface.
Gamer_2k4
Mario Donick
code *lol*.
> Unfortunately, this idea is impractical, because inventories can get
> very large. [...] The tedious scrolling
> to access a particular item would cancel out any increased immersion.
That's true in general. Over the last few hours I thought about this
problem. At least for LambdaRogue it's not so hard, because there the
inventory is restricted to 20 slots, so you can't have more than 20
different types of items with you (but of every type nearly endless
exemplars).
For larger amounts of items, perhaps it was possible to make the system
category based. So, first comes a ring of types, you have to select a
type by pressing a directional key. Then you get the members of the
category:
For step 1, the categories:
.......
.../...
.(.@.%.
...?...
/ "tools" (in a wide meaning, incl. weapons/ammu/pick-axes etc.)
( "wearables" (incl. armour/clothes, but also rings and amulets)
% "comestibles" (potions/food)
? "<insert a generic term here :-) >" (scrolls/books/discs)
I tend to use only 4 categories, because it's easier to overview them.
Additionally, not everybody uses the diagonal keys. However a general
category for items not fitting to these categories is missing here.
Whenever the inventory is shown, the @ is dimmed (from white to dark
gray). First, the categories are shown in lightgray. Once a category is
selected, it get's highlighted (bright white) while the others get
dimmed (darkgray, too).
Then beneath the inventory, either the availabe items of the category
appear, or just the first of the items appears, along with two arrows <
and > symbolizing that there is more to come by pressing the arrow
keys.
I think at least LambdaRogue doesn't need the categories, as max. 20
itemtypes are not so much to scroll through. But perhaps the categories
make it easier for RLs with larger inventories to use such a system...
Wow... I think I'll try this out tonight...
Mario
>
> > And so on. The menu would be on the same line as other messages of the
> > game are shown, very unobstrusive.
>
> > Perhaps I'll try this in LambdaRogue...If you can make it work, I'd definitely be interested in seeing the
> implementation.
>
> Gamer_2k4
Mario Donick
> 'weak potions of this and that'. Tum te tum... Perhaps I'll look at my
> spell list. Hmm spells. Well this is nice isn't it. I wonder if I
> should go back and fight the monster? Nah I'll just keep looking at my
> menu of potions for a while.
Well written and very amusing. :-) However this is exactly what I do
when playing some roguelikes.
Mario
Antoine
Yes, but it doesn't seem like such a breach of immersion in a roguelike
where you aren't in such a flurry of action in the first place.
Also roguelike interfaces tend to be much quicker than the Morrowind
one IMO.
A.
Mario Donick
Although technically it works good, it has one main problem: It's seems
somehow senseless to display a ring of items using only their
ASCII-character around the @-avatar, because the user always has to
look to the line of text that tells him what exactly a selected item
is. So after a short while the user will only look to the text line
instead the itemring, because the text gives him the needed information
("which item did I select?") faster. This makes the itemring useless at
all.
The current state of my experimental inventory is that I display a
relatively small box next to the avatar:
##...............
.#...............
.#...............
.#.+-----+.......
.#.|2 | burger
##.| |.......
@ | % |......
...| |.......
...+-----+.......
.................
.................
As you can see I show the ASCII-char of the item in the middle. Right
of the the box I show the name of the item. The number in the upper
left corner of the box is the number of items of this type (so here the
player has 2 burgers). If the item was equipped, in the last line of
the box would be a word like "body", "left", "head" etc. to indicate
this (here I first head only one letter as abbreviation which looked
better imo, but was not so clear).
I don't display the name of the item in the game's message line at the
bottom of the screen because there it's outside the player's current
field of view. It's better in the middle of the screen, next to the
avatar.
Note that there aren't displayed possible actions for the items. To see
them you have to actively confirm your selection (currently by pressing
the down key). After you did this, the actions are shown below the
itemname. It depends on the current situation and the type of the item
which actions are shown and which not.
The whole inventory is called by pressing the inventory button. Then
the first item appears. You can scroll to the right by pressing [right]
and then to the left by pressing [left]. If you reached the last item
and pressed [right] again, the inventory would be closed. It's also
closed by pressing [up]. To confirm the selection of an item and to
bring up the possible actions, you have to press [down].
At the moment I'm testing the efficiency of this system with a
character who has a full inventory with different types of items, so he
can perform different actions. As my old inventory system is still
available, I can compare the old and the new way.
I definitely like that the world is still visible while browsing
through my items. It seems more direct and I think this is a big win.
On the other hand, my current implementation isn't visually appealing
and the display of the ASCII-char of the items is, as stated above,
useless. Instead I think of just displaying the item name.
We'll see... However, this inventory system has "something" that's very
gentle to me as user. I think this is mainly the visible world and the
visible @. Additionally it's easier just to scroll left and right until
the right item is shown then to search unhandy lists of the item. I
think this is faster.
So I will keep it in the next versions of LambdaRogue, perhaps only as
alternative to the normal inventory.
Later this night I will upload some screenshots, then post an URL, so
you can see it in both the console- and the SDL-version of the game.
Mario
On 7 Jan., 23:10, "Mario Donick" <mario.don...@googlemail.com> wrote:
> Radomir's suggestion is better than mine, although mine is easier to
> code *lol*.
>
> > Unfortunately, this idea is impractical, because inventories can get
> > very large. [...] The tedious scrolling
> > to access a particular item would cancel out any increased immersion.That's true in general. Over the last few hours I thought about this
Radomir 'The Sheep' Dopieralski
Mario Donick wrote:
I love to see your experiments. They certainly bring somethng fresh,
even when they don't seem particulary efficient :)
Have you considered something like this?
#.# #.#
#.# #.#
########|Wield: |####
#.......|a ) short sword (+1 +1)|....
#...@...|b ) pick axe |####
#.......|c ) small dagger x4 |
###\####|d } short bow (+0 +2) |
#.# |e / arrow x30 |
#.# #.#...#............#
#.# #.#####............#
#.# #.....+......<.....#
#.# #######............#
#.# ##############
Gamer_2k4
>
> #.# #.#
> #.# #.#
> ########|Wield: |####
> #.......|a ) short sword (+1 +1)|....
> #...@...|b ) pick axe |####
> #.......|c ) small dagger x4 |
> ###\####|d } short bow (+0 +2) |
> #.# |e / arrow x30 |
> #.# #.#...#............#
> #.# #.#####............#
> #.# #.....+......<.....#
> #.# #######............#
> #.# ##############
Ah, the Angband approach. Tried and true.
Gamer_2k4
Mario Donick
>
> #.# #.#
> #.# #.#
> ########|Wield: |####
> #.......|a ) short sword (+1 +1)|....
> #...@...|b ) pick axe |####
> #.......|c ) small dagger x4 |
> ###\####|d } short bow (+0 +2) |
> #.# |e / arrow x30 |
> #.# #.#...#............#
> #.# #.#####............#
> #.# #.....+......<.....#
> #.# #######............#
> #.# ##############
Hm, yes, but it's basically a menu. Not bad, but I want to try
something with less information. At the moment I have the following:
http://donick.net/bilder/lr/newinventory-console-1.png
http://donick.net/bilder/lr/newinventory-console-2.png
http://donick.net/bilder/lr/newinventory-console-3.png
http://donick.net/bilder/lr/newinventory-console-4.png
On picture 1, there is nothing. :)
On picture 2, I have opened the inventory. Only one item at a time is
displayed, as described in my other post. Don't be irritated by the
black background under the "bottle of water"-text; the landscape often
is under the texts (which makes it sometimes hard to read, so I think I
have to force a black background there...)
On picture 3, I had pressed [down] to activate my selection. I am
offered the possible actions which are activated using the proper
direction key. [up] always cancels. The [left] key could be generalized
as "use" and appears either as "eat", "drink", "wield", "wear", "put
on" or "remove". The [down] key usually lets somebody "look" at an
item, but if the item was a CD with magical songs on it, the
down-option would be displayed as "listen" (by listening to discs the
player learns new magical chants he later can use). The [right] key
usually shows "drop", but in the example it shows "sell", because the
player is in front of a trader. ("in front of" means the trader is not
visible for the player's eyes 'cause he's covered by the @ ).
These are all options one can do currently with objects in LambdaRogue
(no, there is no throwing at the moment), and it was rather easy to
build this context menu around them. If there come new actions someday,
there are still 4 diagonal keys to use, although I don't want to break
that horioz/vertic scheme.
In the LambdaRogue config file the player has the option to dis- or
enable this new inventory type. If he disables it, a normal fullscreen
list with all items will be shown.
I decided by the way that traders don't get the new style in their
menus (which looks basically like the old style inventory), because for
traders the long list gives me more the feeling of shopping than the
inventory. On the other hand, the songbook with the magical songs will
perhaps made the new inventory style.
I adopted the new style rather fast and now I nearly don't want to miss
it, although it's visual appeal can be optimized.
Mario
Mario Donick
Now, when the inventory is called, the dungeon map is dimmed:
http://donick.net/bilder/lr/newinventory-console-5.png
For the SDL version, this can be done by laying a semitransparent and
gray PNG over the window.
Mario
Mario Donick
ugly and can be shown ;)
1. http://donick.net/bilder/lr/newinventory-sdl-1.png
2. http://donick.net/bilder/lr/newinventory-sdl-2.png
3. http://donick.net/bilder/lr/newinventory-console-6.png
Picture 1 shows the normal view without inventory open.
Picture 2 shows the inventory, currently selected is a CD with the
heal-chant. (That there's no "drop" option is shown is due to a
temporary deactivation of the "drop"-command, 'cause the function has a
bug).
Picture 3 shows the same, but in console mode.
Of course you won't get an impression of the system and if it's
efficiently in the "max. 20 items in inventory"-context of LambdaRogue,
and I believe it's not good for roguelike who offer much more space,
but perhaps my screenshot gave you an impression of how it looks in an
actual working game.
Mario
Gerry Quinn
ma...@guildgame.com says...
> Mario Donick wrote:
> > > CUT! Oh look here I am in a menu. Scrolling through ten different
> > > 'weak potions of this and that'. Tum te tum... Perhaps I'll look at my
> > > spell list. Hmm spells. Well this is nice isn't it. I wonder if I
> > > should go back and fight the monster? Nah I'll just keep looking at my
> > > menu of potions for a while.
> >
> > Well written and very amusing. :-) However this is exactly what I do
> > when playing some roguelikes.
>
> Yes, but it doesn't seem like such a breach of immersion in a roguelike
> where you aren't in such a flurry of action in the first place.
That comment may be hitting the nail on the head as to why people like
roguelikes (and turn-based CRPGs - proper ones like Wiz8, not pseudo
ones like Baldur's Gate).
Well worth keeping in mind.
- Gerry Quinn
Pointless
> The current state of my experimental inventory is that I display a
> relatively small box next to the avatar:
>
Why not something this this...
> ##..........mustard <--- grayed out
> .#..........ketchup
> .#..........bun
> .#.+-----+..hot dog
> .#.|2 | .burger <--- lit up in white
> ##.| |..relish <--- grayed out
> @ | % |..mayonaise
> ...| |..-----
> ...+-----+.......
> .................
> .................
>
Selecting an item is like scrolling through the list, which pushes the
other items up and down depending on the direction. the box displays
the description of the item currently selected.
Arthur J. O'Dwyer
On Sun, 7 Jan 2007, Radomir 'The Sheep' Dopieralski wrote:
> Christophe Cavalaria wrote:
>> Radomir 'The Sheep' Dopieralski wrote:
>>>
>>> The "spill" command can still take into acocunt the size and number of
>>> items on the floor and "use up" the potion accordingly. But that's not the
>>> point -- the point is that one can design the game (not only its
>>> interface!) while keeping in mind these simple rules, it doesn't require a
>>> lot of sacrifice.
>>
>> A possible solution would be that the dip command will make the user dip the
>> currently wielded item into the selection potion. Now, maybe the Nethack
>> style "thou can wield anything!" interface might be of some use after all.
>
> "internal environment" **inside** of the player character, making into
> something much more than a tool of the player. Instead of means for
> exploring the world, the avatar becomes a wolrd to explore. Soon you
> need helper-slots for helper-slots for slots, like in Omega :)
I think your "#dip" example was just bad. In fact, no matter what,
if your verb takes a noun, you're going to need to specify that noun.
"Dip what? Dip the sword into what?" is complicated and might break
the player's train of thought. But "Zap what?" and "Magic-missile which
direction?" and "Eat what?" are the same kind of complication, and you
haven't given any ideas (in this subthread) about how to eliminate
that complication.
All you've suggested is replacing "Verb, direct object, indirect
object" with "Verb, object"; when what you really want to do is replace
everything with "Verb".
IMHO, you /can/ make a roguelike where most actions are "Verb".
DoomRL is the closest I can think of right now, although I don't play
many cutting-edge roguelikes.
The easiest way to make everything "Verb" is to downplay the
complicated stuff --- just don't make the player need to use it!
Move. Bump into monsters to attack them. Point and shoot.
One-object-per-space means no menus when you pick up an item.
Simple combat mechanics mean less time switching weapons (to use
a pike against a knight and a club against an orc, for example).
Specialized inventory slots like "Quiver" mean less time selecting
ammunition. Angband's auto-target means less time tabbing among
potential targets. (And so does Nethack's directional targeting.)
However, notice that everything in that list doesn't just make
the game /quicker/, or reduce the number of keystrokes. Those are
things that actually increase immersion, because they mimic real
life. In real life (defined here as "the Lord of the Rings movies" ;)
it doesn't take any time or thought at all to draw an arrow from
your quiver, or scoop up an item from the ground.
Contrariwise, I hate games with auto-opening doors. In real life,
it /does/ take time and thought to open a door. You have to consider
whether you want to open it at all, for one thing --- maybe there's
something bad on the other side! Then you have to put your hand on
the knob and turn it, and so on. (Unless you're playing a giant who
reflexively smashes doors down instead of opening them, in which case
auto-open would be the Right Thing. Auto-open would also be close to
right in a Star Trek setting.)
In short: Reflexive, unthinking actions should be reflexive and
unthinking in the game. Slow, considered actions should be slow and
considered in the game.
>>>> What will you do when the user finds a wand of stone to mud and
>>>> wants to target that little section of wall there?
>>>
>>> This is easily handled by the Rogue's 8-way directions.
>>
>> And of course, it's exactly the same problem than Rogue when you want to
>> target a monster that isn't in the 8-way directions.
>
> Why do you target a monster with a wand of stone to mud?
Don't play stupid. That's no fun for anyone.
> Note also, that the existance of an accurate targetting system is exactly
> what make th wnds of stone-to-mud and of wall-building extinct -- it's
> impossible to dig a tunnel going at arbitrary angle in a roguelike.
Or perhaps: It's possible, but it's difficult for the programmer, so
it is typically not done.
The programmer can always make a special case for the wand of
wall-building, if he wants it so much. (Or use Nethack's directions,
of course, as you say. I have nothing against Nethack's targeting
metagame; I think of it as an in-game equivalent of "dodging" or
"lining up the shot", which actually increases immersion, because it
increases the control I have other whether my character gets hit.)
>>>> And what about timed
>>>> effect spells where the player will want to throw that delayed blast
>>>> fireball somewhat before that monster charging at him.
>
>>> A what? Honestly, I don't know what are you talking about here, can
>>> you give an example from an existing roguelike game to illustrate it?
>
>> There's a spell like that in NWN ( and D&D I suppose ). Throw the fireball
>> in one space, and 3 turns later it explodes. That special fireball in
>> itself is much more powerful than a regular fireball which makes using it
>> worthwhile. You just have to time it correctly because the explosion radius
>> isn't that big after all. It is a matter of careful placement, timing and
>> oponent manipulation to make the best use of it. With a severly limited
>> targeting system, such spell might very well be of little use since you
>> lack the control required to make the best use of it.
>
> So, you're basically talking about a delayed-detonation bomb?
> Well, you could handle them by using... uhm... delayed-detonation bombs?
Yes, I would have suggested "hand grenade" as another example of
this mechanic. But "hand grenade" is not a UI implementation. Your
suggestion was to eliminate precise targeting, which would make precise
targeting of hand grenades (or fireballs, or delayed-detonation bombs)
impossible.
>> Also, there are situations where you want to target your area of effect
>> spell in an empty spot because the radius makes it so that point in space
>> is more efficient than any point centered around a monster.
>
> Well, this pretty much turns it into a board game, doesn't it?
Huh? I'm a big board-game player, and I've never seen a board game
with area-effect offensive spells. OTOH, precision targeting is a big
part of Angband (a roguelike), and I've had cause to throw fireball
against the wall in Nethack before, too.
(Nethack also has the special case of Stinking Cloud, which can be
precision-targeted.)
> On the other hand, I propose to base the game design on the user
> interface, because that's simply what the user sees and that's what
> defines the feel of the game. I think that this way of doing things -- that
> is, start with defining how do you want the game feel (not the game
> world!), and **then** create everything based on it, including all the
> game world -- has a chance of producing something consistent that you
> really intended.
But maybe the designer has a great idea for a game, but isn't much
good at UI design? IMO, it's usually much better to let the game
"universe" drive the UI, than the reverse: "Let's see, how can I use
an 80x25 display to make the player feel like he's an international spy?"
instead of "Let's see, what kind of game can I make using only
intransitive verbs and mouse gestures?"
The big BIG exceptions to my rule of thumb are the few excellent
games driven by a novel UI mechanic. Unfortunately, the only one I
can think of right now is "Joust" ("push button to flap wings").
One other arcade-game example I want to bring up, though, is the
now-ubiquitous driving sim in which you drive through "powerups" to
gain time or extra maneuverability, and the only interaction with
other cars (AI or other players) is by cutting them off or driving
into them. This is an excellent example of a simple "Verb" UI. The
verbs are "turn left" and "turn right", with "take your foot off the
gas pedal" for advanced users. Everything else comes out of that UI.
The antithesis of the driving sim is the modern Doom-style PC shooter,
in which the verbs are left-right-forward-backward-strafe-jump-fire,
plus the verb-object combos "swap weapon" and perhaps "use item" and
"manipulate object" (e.g., "open door" or "push button"). It takes
too much thought to do things that are reflexive in real life.
>> But before you answer, I really like your ideas on the interface. If it was
>> possible to provide a trully imersive interface which still handles enouth
>> targeting control for the user it would be perfect.
>
> I don't think it's possible. Precise targetting is something that requires
> a focus switch even in the real world. However, precise targetting is
> extremly rare in the real world -- you usually target objects or areas.
Precise targeting doesn't require a focus switch if you are truly
immersed --- if you /are/ the character. If you take your eyes off the
"@" to look over there, it's because /your character/ is looking over
there. If you take your eyes off the "@" to consult a full-screen
menu of items in your knapsack, it's because /your character/ is
occupied in rummaging through his knapsack. But if you take your eyes
off the "@" to consult a drop-down menu, while /your character/ is
obviously still on-screen waiting to do battle, something is wrong.
my $.02,
-Arthur
Radomir 'The Sheep' Dopieralski
Arthur J. O'Dwyer wrote:
> On Sun, 7 Jan 2007, Radomir 'The Sheep' Dopieralski wrote:
>> Christophe Cavalaria wrote:
>>> A possible solution would be that the dip command will make the user dip the
>>> currently wielded item into the selection potion. Now, maybe the Nethack
>>> style "thou can wield anything!" interface might be of some use after all.
>> That's something I was trying to avoid -- it creates some sort of
>> "internal environment" **inside** of the player character, making into
>> something much more than a tool of the player. Instead of means for
>> exploring the world, the avatar becomes a wolrd to explore. Soon you
>> need helper-slots for helper-slots for slots, like in Omega :)
> I think your "#dip" example was just bad. In fact, no matter what,
> if your verb takes a noun, you're going to need to specify that noun.
> "Dip what? Dip the sword into what?" is complicated and might break
> the player's train of thought.
Keeping the train of thought intact is not exactly my goal here. It's
rather more like making it break in the game's world rather than in
the menus or other parts of interface -- so that you think, look around,
analyze situation, etc. while controlling the avatar, not while
controlling the menu cursor.
Sure, some actions are inevitably complicated, and some can be even *made*
complicated on purpose in the game -- after all, user interfaces for games
are not always the most efficient ones, just the most fun ones. Consider a
sacrifice ritual, for example -- it could be fairly complex, requiring an
altar, an object to sacrifice, maybe some additional materials like
(un)holy symbols, maybe an item to be blessed or enchanted by the god as
the result of the sacrifice, etc. It becomes even more complicated when
the creature to be sacrificed needs to be alive.
Of course, and efficient interface could handle it using a set of menus or
even a form. You fill in apropriate fields, press "submit" and voila! But
it could also be made in a form of a real ritual, where you put objects in
designated places around the altar at designated times, preparing them
properly before (i.e. stunning the victim so that it doesn't move), and
then reading a scroll or a prayer from your holy book. Much more fun, eh?
The latter interface is even more complicated than the simple form. Yet
the complexity is outside the immediate user interface, and inside the
game world somehow. It does not only increase immersion -- it also engages
the user's creativity and problem solving -- there are multiple ways to
get the monster on the altar at the right moment, there are several ways
in which the ritual can fail, etc.
> But "Zap what?" and "Magic-missile which direction?" and "Eat what?"
> are the same kind of complication, and you haven't given any ideas
> (in this subthread) about how to eliminate that complication.
Excuse me for not solving all the problems for you beforehand :)
I don't really view them as such great problems -- especially the
single-choice actions -- you usually submit the command and select the
parameter immediately after determining the way to do so. And with
aproporiate feedback (like telling the inventory slot letter when picking
up items, for example) you really spend very short time in the menus. The
fact that they don't have a cursor and consist of a single step makes it
even better -- you're unlike to develop a sense of position in them.
I am a little bit worried about the two-step commands, like zapping
a wand or throwing. Certainly, they require attention -- the steps should
be kept in the same order all the time, and there is no place for
a "return to previous step" option -- abort is of course a must.
Of course, a "missile" slot a la Angband or ADOM (and recently even
NetHack) would remove one step -- but at a cost of increased **internal**
complexity. Adding facing is too awkward and complicated, and a text-mode
roguelike would count as internal state anyways. Throwning might be maybe
composed of a "drop" and "kick" commands...
Fortunatelly, the direction choice is a no-brainer and doesn't require
focus.
> All you've suggested is replacing "Verb, direct object, indirect
> object" with "Verb, object"; when what you really want to do is replace
> everything with "Verb".
I think you missed the point. I don't care about verbs, nouns and objects.
I just want them all in the game world, not in the menus.
> IMHO, you /can/ make a roguelike where most actions are "Verb".
> DoomRL is the closest I can think of right now, although I don't play
> many cutting-edge roguelikes.
Z-Day is even closer -- if not the "run" command.
> The easiest way to make everything "Verb" is to downplay the
> complicated stuff --- just don't make the player need to use it!
> Move. Bump into monsters to attack them. Point and shoot.
> One-object-per-space means no menus when you pick up an item.
That's how z-day does it.
> Simple combat mechanics mean less time switching weapons (to use
> a pike against a knight and a club against an orc, for example).
Or just make switchng the weapons a single keystroke, like in some
action games -- just press it multiple times. Works well when it
doesn't consume turns.
> Specialized inventory slots like "Quiver" mean less time selecting
> ammunition.
This I'm trying to avoid, as it adds to the "internal" world, not the
"external" one.
> Angband's auto-target means less time tabbing among
> potential targets. (And so does Nethack's directional targeting.)
Tabbing, hmm...
> However, notice that everything in that list doesn't just make
> the game /quicker/, or reduce the number of keystrokes.
Of course not.
> Those are
> things that actually increase immersion, because they mimic real
> life. In real life (defined here as "the Lord of the Rings movies" ;)
> it doesn't take any time or thought at all to draw an arrow from
> your quiver, or scoop up an item from the ground.
More precisely, by mimicking some of the real life mechanisms they allow
for the most processing to be delegated to the primal, heavily automated
yet very fast and effective, multitasking parts of the brain.
> Contrariwise, I hate games with auto-opening doors. In real life,
> it /does/ take time and thought to open a door. You have to consider
> whether you want to open it at all, for one thing --- maybe there's
> something bad on the other side! Then you have to put your hand on
> the knob and turn it, and so on. (Unless you're playing a giant who
> reflexively smashes doors down instead of opening them, in which case
> auto-open would be the Right Thing. Auto-open would also be close to
> right in a Star Trek setting.)
Not really. Honestly, how many times have you gone through a bulding and
then coudn't recall if there were any doors in your way or whether they
were opened or closed? How many times have you reflectively closed doors
behind you, even though you've been explicitly told to leave them open
because of summer heat? You do think before entering an unknown room --
but you would hesitate the same if there was just a dark hole there
instead of door.
> In short: Reflexive, unthinking actions should be reflexive and
> unthinking in the game. Slow, considered actions should be slow and
> considered in the game.
They are usually composed of the small, reflexive ones.
>>>>> What will you do when the user finds a wand of stone to mud and
>>>>> wants to target that little section of wall there?
>>>> This is easily handled by the Rogue's 8-way directions.
>>> And of course, it's exactly the same problem than Rogue when you want to
>>> target a monster that isn't in the 8-way directions.
>> Why do you target a monster with a wand of stone to mud?
> Don't play stupid. That's no fun for anyone.
No, really, apologies, but I mean it. There are offensive items, and there
are hm... utility items. You usually don't mix them. Even if you do, it's
easy to avoid -- by game design. Then you can have a "choose direction"
prompt for the utility stuff, and a "target monster" prompt for the
offensive items. Using a wnad of stone to mud on a golem becomes then
somehow even more satysfying.
>> Note also, that the existance of an accurate targetting system is exactly
>> what make th wnds of stone-to-mud and of wall-building extinct -- it's
>> impossible to dig a tunnel going at arbitrary angle in a roguelike.
> Or perhaps: It's possible, but it's difficult for the programmer, so
> it is typically not done.
Especially when it really brings no benefit to the actual game.
> The programmer can always make a special case for the wand of
> wall-building, if he wants it so much. (Or use Nethack's directions,
> of course, as you say. I have nothing against Nethack's targeting
> metagame; I think of it as an in-game equivalent of "dodging" or
> "lining up the shot", which actually increases immersion, because it
> increases the control I have other whether my character gets hit.)
Yes. It's possible to explore the topic further and provide, e.g. special
attacks for the fighter classes, where your previous position determines
the kind of attack -- advancing makes a charge, retreating -- defensive
stance, etc. Much better, in my opinion, than selecting them from a menu.
>>>>> And what about timed
>>>>> effect spells where the player will want to throw that delayed blast
>>>>> fireball somewhat before that monster charging at him.
>>>> A what? Honestly, I don't know what are you talking about here, can
>>>> you give an example from an existing roguelike game to illustrate it?
>>> There's a spell like that in NWN ( and D&D I suppose ). Throw the fireball
>>> in one space, and 3 turns later it explodes. That special fireball in
>>> itself is much more powerful than a regular fireball which makes using it
>>> worthwhile. You just have to time it correctly because the explosion radius
>>> isn't that big after all. It is a matter of careful placement, timing and
>>> oponent manipulation to make the best use of it. With a severly limited
>>> targeting system, such spell might very well be of little use since you
>>> lack the control required to make the best use of it.
>> So, you're basically talking about a delayed-detonation bomb?
>> Well, you could handle them by using... uhm... delayed-detonation bombs?
> Yes, I would have suggested "hand grenade" as another example of
> this mechanic. But "hand grenade" is not a UI implementation. Your
> suggestion was to eliminate precise targeting, which would make precise
> targeting of hand grenades (or fireballs, or delayed-detonation bombs)
> impossible.
It's true. Unless you use one of the ideas for the teleportation spell and
just fix the throw distance to some convenient value -- preferably just
outside the range of explosion. That's how many action games do it,
actually. It's much less powerful, of course, and generally involves much
less planning.
I think that my ideas would favor a fighter class.
>>> Also, there are situations where you want to target your area of effect
>>> spell in an empty spot because the radius makes it so that point in space
>>> is more efficient than any point centered around a monster.
>>
>> Well, this pretty much turns it into a board game, doesn't it?
>
> Huh? I'm a big board-game player, and I've never seen a board game
> with area-effect offensive spells. OTOH, precision targeting is a big
> part of Angband (a roguelike), and I've had cause to throw fireball
> against the wall in Nethack before, too.
>
> (Nethack also has the special case of Stinking Cloud, which can be
> precision-targeted.)
I don't say it's bad. It just doesn't fit the particular kind of game
I'm proposing here.
>> On the other hand, I propose to base the game design on the user
>> interface, because that's simply what the user sees and that's what
>> defines the feel of the game. I think that this way of doing things -- that
>> is, start with defining how do you want the game feel (not the game
>> world!), and **then** create everything based on it, including all the
>> game world -- has a chance of producing something consistent that you
>> really intended.
> But maybe the designer has a great idea for a game, but isn't much
> good at UI design? IMO, it's usually much better to let the game
> "universe" drive the UI, than the reverse: "Let's see, how can I use
> an 80x25 display to make the player feel like he's an international spy?"
> instead of "Let's see, what kind of game can I make using only
> intransitive verbs and mouse gestures?"
Well, maybe he's a great singer, but can't draw very nice? I'd advise him
to stick to singing then. On the other hand, if someone tends to dream of
his game in form of vivid images or even short scenes, if he does exactly
now how it is supposed to "feel", just doesn't have the colors of elven
hats planned very well, if he recognizies that repeatedly hitting
a monster should, after some time, kill it, just doesn't have the exact
formulas written down -- well, *then* he might consider the ui-driven
design.
> The big BIG exceptions to my rule of thumb are the few excellent
> games driven by a novel UI mechanic. Unfortunately, the only one I
> can think of right now is "Joust" ("push button to flap wings").
Ah, this mechanic was present in the oldest computer game ever, "lander".
> One other arcade-game example I want to bring up, though, is the
> now-ubiquitous driving sim in which you drive through "powerups" to
> gain time or extra maneuverability, and the only interaction with
> other cars (AI or other players) is by cutting them off or driving
> into them. This is an excellent example of a simple "Verb" UI. The
> verbs are "turn left" and "turn right", with "take your foot off the
> gas pedal" for advanced users. Everything else comes out of that UI.
I bet people tend to twist all ways and scream and shout and whatnot while
playing it. I bet they are tormented by the poor quality of the gameplay
and terrible immersion ;)
> The antithesis of the driving sim is the modern Doom-style PC shooter,
> in which the verbs are left-right-forward-backward-strafe-jump-fire,
> plus the verb-object combos "swap weapon" and perhaps "use item" and
> "manipulate object" (e.g., "open door" or "push button"). It takes
> too much thought to do things that are reflexive in real life.
I don't think that my ideas are such a devastating hit to the actual
complexity of the game mechanics. Sure, there *are* some simplifications,
the most notable being the lack of precise targetting (of course, you can
still add it if you insist -- for some rare occassions where it's really
needed).
>>> But before you answer, I really like your ideas on the interface. If it was
>>> possible to provide a trully imersive interface which still handles enouth
>>> targeting control for the user it would be perfect.
>> I don't think it's possible. Precise targetting is something that requires
>> a focus switch even in the real world. However, precise targetting is
>> extremly rare in the real world -- you usually target objects or areas.
> Precise targeting doesn't require a focus switch if you are truly
> immersed --- if you /are/ the character. If you take your eyes off the
> "@" to look over there, it's because /your character/ is looking over
> there. If you take your eyes off the "@" to consult a full-screen
> menu of items in your knapsack, it's because /your character/ is
> occupied in rummaging through his knapsack. But if you take your eyes
> off the "@" to consult a drop-down menu, while /your character/ is
> obviously still on-screen waiting to do battle, something is wrong.
I really can't imagine a real-life situation where you're targetting
something and not focussing on it. Even to the degree that Zen archers do.
Gamer_2k4
> >>> wants to target that little section of wall there?
> >> This is easily handled by the Rogue's 8-way directions.
> > And of course, it's exactly the same problem than Rogue when you want to
> > target a monster that isn't in the 8-way directions.
>
> Why do you target a monster with a wand of stone to mud?
I may be remembering incorrectly, since it probably happened almost ten
years ago, but I seem to recall my brother had trouble defeating a
stone golem in Moria, and a wand of stone to mud did the trick. This
may be giving Moria too much credit, but I guarantee it would work in
Nethack. That's why you target a monster with stone to mud.
Gamer_2k4
Brendan Guild
> for example), have at most one-level menus displayed on the same
> screen where the main view is (switching screens is also perseived
> as moving around). Try to make most actions use direct manipulation
> of the in-game objects. Easy to say, eh?
This has inspired me to a radical interface design idea and I wonder
if it matches what you are trying to say.
As in any normal roguelike, you have equipment slots such as armor
and weapon, and each slot has a corresponding key for putting an item
into the slot. However, in this game there is no inventory menu, so
you can only equip from the ground.
You can still have an inventory, but it must be dropped to be used.
Pressing 'i' would cause your entire unequipped inventory to spill
out onto the floor, assuming there is enough space for it there.
Naturally, there would be one item per tile to avoid menus that way,
and if the player is cramped by walls, other items, or monsters, then
'i' will simply have to refuse.
To change what you have equipped, simply move over an item on the
floor and press the appropriate key, then it will be replaced by the
item you currently have in that slot. When you are finished, you must
collect the items that you want to keep by picking them up from the
floor in the usual manner.
In addition to 'i' which would spew out all of your inventory, you
could have a 'drop' key for leaving behind the item you most recently
picked up. The inventory could act like a stack that you push and pop
from the floor. And for dipping, you could simply pop an item out
onto the floor in a place that already has a potion.
This prevents you from doing inventory manipulation while in the
middle of combat, especially if monsters could steal your inventory
while it is out on the floor, which fits with realism.
Gamer_2k4
Realistic and logical, but that's not necessarily a good thing. I
mean, seriously, did anyone like the complexity of Omega's inventory
system?
It would still be interesting to see used. Maybe something for the
upcoming 7DRL Challenge?
Gamer_2k4
Radomir 'The Sheep' Dopieralski
Brendan Guild wrote:
> As in any normal roguelike, you have equipment slots such as armor
> and weapon, and each slot has a corresponding key for putting an item
> into the slot. However, in this game there is no inventory menu, so
> you can only equip from the ground.
> You can still have an inventory, but it must be dropped to be used.
> Pressing 'i' would cause your entire unequipped inventory to spill
> out onto the floor, assuming there is enough space for it there.
> Naturally, there would be one item per tile to avoid menus that way,
> and if the player is cramped by walls, other items, or monsters, then
> 'i' will simply have to refuse.
> To change what you have equipped, simply move over an item on the
> floor and press the appropriate key, then it will be replaced by the
> item you currently have in that slot. When you are finished, you must
> collect the items that you want to keep by picking them up from the
> floor in the usual manner.
Yes, this is the direction I wanted to go, only a little farther than
I ever even thought of venturing... You see, in order to keep the
complexity of Rogue, you'd need at least... hmm... 10 slots? Let's see,
weapon, ammo, armor, two rings, amulet, wand, at least two scrolls, at
least two or three potions, food, hmm... were there shields in Rogue?
I don't think so, at least not in the plain one. So, this makes, hmm..
13 slots, 10 if you're willing to limit the player to one potion and
scroll during any encounter. This makes the internal structure of the
avatar much too complicated -- and again makes the player spend more
time in the world of slots than actually adventuring.
Not to mention that you'd need rooms large enough to fit the whole
inventory, and that any item-collecting monster would be universally
hated by all the players :)
But still a great idea, shows some potential ;)
Nolithius
news:Xns98B2B59E07...@64.59.144.76...
[snip]
> As in any normal roguelike, you have equipment slots such as armor
> and weapon, and each slot has a corresponding key for putting an item
> into the slot. However, in this game there is no inventory menu, so
> you can only equip from the ground.
This is an interesting idea-- but I'd rather have either a) a small
[battle-accessible] inventory to allow some choice mid-battle, or b) some
way to switch wielded items without having to drop everything. Most players
would expect to switch between a dagger and a crossbow without having to
spill their whole inventory into the floor ;). Note that these two are not
mutually exclusive.
> You can still have an inventory, but it must be dropped to be used.
> Pressing 'i' would cause your entire unequipped inventory to spill
> out onto the floor, assuming there is enough space for it there.
> Naturally, there would be one item per tile to avoid menus that way,
> and if the player is cramped by walls, other items, or monsters, then
> 'i' will simply have to refuse.
To avoid space bloat the most reasonable option is to limit the player to
only 8 items (that's really 16 total, 8 equipped and 8 in the inventory).
This sounds like a serious limitation under the common fantasy-packrat
paradigm, but can be interesting in a game where a) The focus is not so much
on equipment but more on character development, b) Items are dropped/found
scarecely and subsequently c) Most items the player finds is potentially
useful in some way other than selling junk.
To illustrate how a, b, and c are possible, consider basically any action
movie. In a high-stress situation, say when you have to fight a bunch of
guys to get out of a place but have no option of returning from where you
came, for example, if under pursuit by worse enemies or followed by
catrastophe such as a building collapsing or on fire-- environments like
these create a very hurried pace where the character is not focused on
juggling items in his inventory, but rather running/saving his ass by
blasting bad guys/using some skills like jumping bashing in doors to escape.
This atmosphere is hard to achieve in an RL but definitely not impossible
(fulfills a). For b and c, and assuming a limited inventory like "weapon in
right hand, unconscious girl over left shoulder" for an extreme example, the
items that are relevant to the character (in this case weapons or
unconscious women) appear rarely (fulfills b), and when they appear the
character can just ignore them if they can be quickly identified as inferior
to his currently equipped item. The only inventory juggling here is if you
find an awesome gun to surpass your puny one (and make the call to risk
picking up a potentially empty/damaged/jammed gun)-- or if you run out of
ammo, in which case you will pick up ammo or ditch your weapon for another.
Items in this environment are either junk that you can't care to carry
around anyway, or very useful (fulfills c); the idea is basically to avoid
the grey area where the packrat mentality kicks in: "Oh, this is nice, I
might find a use for this... some day."
Note: I am not claiming that a packrat-oriented design is in any way
negative so spare me the criticism :P it just obviously does not fit in the
proposed system.
>
> To change what you have equipped, simply move over an item on the
> floor and press the appropriate key, then it will be replaced by the
> item you currently have in that slot. When you are finished, you must
> collect the items that you want to keep by picking them up from the
> floor in the usual manner.
Suggestions:
1) When you move onto an item and swap it with your current item, your last
item is dropped in your last position and not your current one (you may
already have accounted for this in your design, just pointing it out). This
allows you to swap back and forth easily if you want and to retrace your
steps to return to your previous equipment configuration.
2) Please, PLEASE have an autopickup key that picks up all of your dropped
items in one shot (preferably the same 'i' so you can toggle it). Ideally it
would pick up all the 'inventory-dropped' items in a 2-square radius so that
you don't have to return to the center if you just walked over an item to
the edge-- although this is something you may want. Additionally if you want
to account for the time that it takes to pickup the inventory just make the
action take a lot of energy and possibly be automatically interrupted if a
monster comes into LOS.
<snip>
> This prevents you from doing inventory manipulation while in the
> middle of combat, especially if monsters could steal your inventory
> while it is out on the floor, which fits with realism.
Note that there are several other ways to discourage inventory manipulation
while in combat that might arguably be more effective: in a game like
Fallout, with a spendable X number of action points per turn, have the
inventory cost you AP. Inventory management in Fallout was definitely a
tactical decision. Or as I do in my game, just have opening the inventory
NOT be free: opening the inventory costs some considerable amount of energy,
so you wouldn't do it in the middle of battle just like you wouldn't walk in
place while surrounded. Another feature I have in my game is a sort of
'battle rage' that compounds as you kill your enemies (it adds damage in
melee as well as resistance to pain): walking causes it to drop slightly but
most other actions (including opening the inventory) cause it to drop
dramatically. I should mention however that I do allow for energy-cheap
weapon-switch and other quick actions that affect rage as little as
movement.
I'm not going to poke at the argument from realism here because I know what
you mean. In the same spirit, however, you must allow certain slots (perhaps
the weapon and the potion slot, for example) to be hot-swapped without the
need to drop everything-- this also 'fits with realism' ;)
Looking forward to your game! :)
--Nolithius
Gamer_2k4
> only 8 items (that's really 16 total, 8 equipped and 8 in the inventory).
This looks like a job for radial menus. :)
Gamer_2k4
Brendan Guild
> "Brendan Guild" <do...@spam.me> wrote in message
> news:Xns98B2B59E07...@64.59.144.76...
>> armor and weapon, and each slot has a corresponding key for
>> putting an item into the slot. However, in this game there is no
>> inventory menu, so you can only equip from the ground.
>
> This is an interesting idea-- but I'd rather have either a) a
> small [battle-accessible] inventory to allow some choice
> mid-battle, or b) some way to switch wielded items without having
> to drop everything. Most players would expect to switch between a
> dagger and a crossbow without having to spill their whole
> inventory into the floor ;).
Refusing to use menus is a severe limitation, but perhaps there is a
way to allow something similar without compromising. I mentioned in a
previous post that the inventory might behave like a stack, so
suppose that it is actually several stacks, one for each category of
item.
Each stack would have an associated key that would pop and item off
the stack and onto the floor beneath the PC (when not already
standing on something). Then swapping a dagger for a crossbow could
be done by: drop the dagger with 'd' (the key for dropping the top
weapon on the stack), wield the dagger from the ground with 'w', and
finally (if you can spare the time) ',' to get the crossbow off the
floor.
Similarly, we might not need a slot for scrolls if scrolls have their
own inventory. To read a scroll in battle, you can drop the top
scroll from your inventory and read it from the ground. It just
requires that you pick up the scrolls in reverse of the order that
you will want to use them.
This even has an argument from reality, since you can usually most
easily access the items that you most recently put into a pack, since
they would be at the top of the pack.
> To avoid space bloat the most reasonable option is to limit the
> player to only 8 items (that's really 16 total, 8 equipped and 8
> in the inventory).
I think it would be safe to let the player choose the inventory size
limit with a game like this. It would quickly become difficult to
manage a large inventory. Since manipulating inventory actually
requires dropping, moving around, and picking up, it takes turns and
there is a possibility of being attacked with your pack all over the
floor.
Especially if the player is required to manually pick up each item
after dropping it, I doubt players would choose to carry around junk.
If they did choose to, it would not be because the junk was sitting
forgotten in the pack.
With the ability to access different categories of items
independently, I think more than 8 items could be managed.
> 1) When you move onto an item and swap it with your current item,
> your last item is dropped in your last position and not your
> current one (you may already have accounted for this in your
> design, just pointing it out). This allows you to swap back and
> forth easily if you want and to retrace your steps to return to
> your previous equipment configuration.
I am actually thinking of disallowing a character and an item to be
in the same square. This allows the player to easily see everything
at a glance, not covered by monsters or even the PC itself. This has
the downside that the player would not be able to get a message line
of information on the item by standing on it just before taking an
action on that item.
But if we were to use such a system, all actions on items would take
a direction, so equipping something would naturally move the PC into
the place of that thing and leave the old equipment behind. Pressing
a direction without an action would naturally swap the PC with an
item.
> 2) Please, PLEASE have an autopickup key that picks up all of your
> dropped items in one shot (preferably the same 'i' so you can
> toggle it). Ideally it would pick up all the 'inventory-dropped'
> items in a 2-square radius so that you don't have to return to the
> center if you just walked over an item to the edge-- although this
> is something you may want.
'Inventory-dropped' is a bit ambiguous. This autopickup idea seems
rather complicated, so I think I would instead use a more normal
autopickup that picks up items just by moving over them. I would have
the player do it by holding 'Shift' (or some similar key) while
moving, so that it is not modal.
This is especially important if the order in which items are picked
up affects how they can be used, as I suggested above.
Mario Donick
> Pressing 'i' would cause your entire unequipped inventory to spill
> out onto the floor, assuming there is enough space for it there.
> Naturally, there would be one item per tile to avoid menus that way,
> and if the player is cramped by walls, other items, or monsters, then
> 'i' will simply have to refuse.
I had the same idea while thinking about LambdaRogue's inventory, but I
rejected it (and instead made my variant mentionend in the other path
of this discussion), because this would be very difficult to realize
when you have to use something from your inventory in tight corridors
of a dungeon or while attacked by various monsters. Imagine a situation
like:
##########
..p@p.....
###+######
###a#####.
###.##....
HP 2/26
PP 1/8
Here we have the @ attacked by two dark preachers (p) at once, and if
he'd opened the door, an abandoned android (a) would do the same. Now
also imagine that the @ has the choice between dying, between drinking
some healing potion or perhaps drinking some potion that regenerates
his psychic powers so that he can chant magical songs. If he now wants
to use such a potion, he can't because there's no space. This may be
realistic, because in battles in reality you usually don't have the
time to heal yourself, but in a roguelike this would be very
frustrating. You always had to try to stay outside of corridors and
only fight in wider rooms, but even there the space on the floor is
often too less...
> And for dipping, you could simply pop an item out
> onto the floor in a place that already has a potion.
This idea is good. It's like the way I sell items to traders; i place
the @ "on" (of course this is called "in front of") a trader and then
drop an item. Then it becomes sold automatically.
Mario
Radomir 'The Sheep' Dopieralski
Brendan Guild wrote:
> Nolithius wrote:
> Refusing to use menus is a severe limitation, but perhaps there is a
> way to allow something similar without compromising. I mentioned in a
> previous post that the inventory might behave like a stack, so
> suppose that it is actually several stacks, one for each category of
> item.
Having fun, eh?
> Each stack would have an associated key that would pop and item off
> the stack and onto the floor beneath the PC (when not already
> standing on something). Then swapping a dagger for a crossbow could
> be done by: drop the dagger with 'd' (the key for dropping the top
> weapon on the stack), wield the dagger from the ground with 'w', and
> finally (if you can spare the time) ',' to get the crossbow off the
> floor.
Why not have 3 stacks, but add a limitation that you can only put smaller
items on top of larger ones? Then add 3 commands to move items between the
stacks, and make the order of items in the first stack control what is
euqipped...
Gerry Quinn
game...@gmail.com says...
And in Crawl you target monsters standing near walls with unknown
wands, just in case they are wands of stone to mud.
- Gerry Quinn
Gamer_2k4
> > the stack and onto the floor beneath the PC (when not already
> > standing on something). Then swapping a dagger for a crossbow could
> > be done by: drop the dagger with 'd' (the key for dropping the top
> > weapon on the stack), wield the dagger from the ground with 'w', and
> > finally (if you can spare the time) ',' to get the crossbow off the
> > floor.
>
> Why not have 3 stacks, but add a limitation that you can only put smaller
> items on top of larger ones? Then add 3 commands to move items between the
> stacks, and make the order of items in the first stack control what is
> euqipped...
Haha, new algorithm: Inventories of Hanoi.
I still like the idea though. Combat shouldn't be a matter of holding
down the arrow key until letters disappear. Thought and strategy
should be involved. If you go into combat, you should have the items
readied that you want to use. Remember how Castle of the Winds did it?
If you had items in your belt, you could use them without equipping
them to your free hand first. Maybe something similar could apply
here.
Gamer_2k4
Martin Read
>Ah, this mechanic was present in the oldest computer game ever, "lander".
Lunar Lander is, at best, the tenth-oldest game ever written for a
digital computer (it's only the tenth or eleventh oldest *that Wikipedia
knows of*).
In particular, it is not the first game to represent a spaceship moving
under the influence of gravity and inertia :)
--
Martin Read - my opinions are my own. share them if you wish.
\_\/_/ http://www.chiark.greenend.org.uk/~mpread/dungeonbash/
\ / "the lights shine clear through the sodium haze the night draws near
\/ and the daylight fades" -- Sisters of Mercy, "Lights"
Arthur J. O'Dwyer
On Tue, 9 Jan 2007, Radomir 'The Sheep' Dopieralski wrote:
> At Mon, 8 Jan 2007 14:35:15 -0500 (EST),
> Arthur J. O'Dwyer wrote:
>> On Sun, 7 Jan 2007, Radomir 'The Sheep' Dopieralski wrote:
>>> That's something I was trying to avoid -- it creates some sort of
>>> "internal environment" **inside** of the player character, making into
>>> something much more than a tool of the player. Instead of means for
>>> exploring the world, the avatar becomes a wolrd to explore. Soon you
>>> need helper-slots for helper-slots for slots, like in Omega :)
>
>> I think your "#dip" example was just bad. In fact, no matter what,
>> if your verb takes a noun, you're going to need to specify that noun.
>> "Dip what? Dip the sword into what?" is complicated and might break
>> the player's train of thought.
>
> Keeping the train of thought intact is not exactly my goal here. It's
> rather more like making it break in the game's world rather than in
> the menus or other parts of interface -- so that you think, look around,
> analyze situation, etc. while controlling the avatar, not while
> controlling the menu cursor.
"Train of thought" wasn't the right phrase there. "Suspension of
disbelief", perhaps? The idea I was trying to get across --- and I think
you've been agreeing with this much all along --- is that if the player
spends too much time in inventory management and menu systems, he'll
remember he's using a computer and not sneaking through a dungeon.
[snip sacrifice ritual stuff]
> Of course, an efficient interface could handle it using a set of menus or
> even a form. You fill in apropriate fields, press "submit" and voila! But
> it could also be made in a form of a real ritual, where you put objects in
> designated places around the altar at designated times, preparing them
> properly before (i.e. stunning the victim so that it doesn't move), and
> then reading a scroll or a prayer from your holy book. Much more fun, eh?
Yes. I'd call that a "metagame". Metagames can be a lot of fun, if
they're done right. (We've already mentioned targeting in Nethack as
a metagame that IMHO increases immersion.)
[...]
> Of course, a "missile" slot a la Angband or ADOM (and recently even
> NetHack) would remove one step -- but at a cost of increased **internal**
> complexity. Adding facing is too awkward and complicated, and a text-mode
> roguelike would count as internal state anyways. Throwning might be maybe
> composed of a "drop" and "kick" commands...
I think we're agreeing that immersion is made easier if most of the
actions are "in-game-world" and not menu-based. But the point on which
I disagree with you is the "reductionist" approach you're displaying
in the above paragraph. Throwing is *NOT* just dropping something and
then kicking it! Kicking uses the feet; throwing uses the hands. And
unless you're a soccer star, throwing is bound to be more accurate.
If you force the player to type "drop+kick" when he wants to "throw",
you're breaking the fourth wall and reminding him that he's using a
computer, not throwing an object.
Additionally, I don't understand /why/ you are reducing "throw" to
"drop+kick". It seems to go against what I understand as your main
thesis, which is (roughly speaking) that menus are bad. "Throw" needs
a menu to select an item. "Drop" needs the exact same menu. Replacing
one by the other doesn't avoid any UI issues. So why would you do it?
> Fortunatelly, the direction choice is a no-brainer and doesn't require
> focus.
Agreed.
>> All you've suggested is replacing "Verb, direct object, indirect
>> object" with "Verb, object"; when what you really want to do is replace
>> everything with "Verb".
>
> I think you missed the point. I don't care about verbs, nouns and objects.
> I just want them all in the game world, not in the menus.
But to select a noun which is not visible in the game world (because
it is in your knapsack, for example), you need a menu. I know you
didn't /mention/ nouns and verbs, but I think that using those words
will help clarify your thinking. Give it a try? :)
>> The easiest way to make everything "Verb" is to downplay the
>> complicated stuff --- just don't make the player need to use it!
>> Move. Bump into monsters to attack them. Point and shoot.
>> One-object-per-space means no menus when you pick up an item.
>
> That's how z-day does it.
>
>> Simple combat mechanics mean less time switching weapons (to use
>> a pike against a knight and a club against an orc, for example).
>
> Or just make switchng the weapons a single keystroke, like in some
> action games -- just press it multiple times. Works well when it
> doesn't consume turns.
"Press a key multiple times to scroll through an enumeration of
nouns" is /exactly/ a menu. The decision to make weapon selection
accessible only through that kind of scrolling menu was IMHO possibly
/the/ worst design decision in Grand Theft Auto III, for example.
You might say, "Oh, it's not a menu, because only one item is
visible at a time." I say that's a menu with an absurdly small
"keyhole", to borrow a term from Scott Meyers' otherwise ridiculous
and whiny paper "The Keyhole Problem":
http://www.aristeia.com/TKP/
If I want to select the shotgun, I have to remember that it comes
after the pistol in my weapons list. A better menu interface would
show me /all/ my weapons, so I wouldn't need to recall that fact
every time I want the shotgun. And even better designs would be
to reduce the number of weapons (if that didn't sacrifice gameplay),
or assign a hotkey to each commonly used weapon (if the keyboard
had keys to spare).
(Actually, GTA3 might already use hotkeys. I don't know. But
just pretend it didn't, and then read my rant again in that context.)
>> Specialized inventory slots like "Quiver" mean less time selecting
>> ammunition.
>
> This I'm trying to avoid, as it adds to the "internal" world, not the
> "external" one.
I don't get it. I agree that "Quiver" is extra work for the programmer,
but if it also provides convenience and immersion for the player, you
shouldn't shrink from it.
In other words, I see how it adds to the "internal world" (i.e.,
the source code?), but I don't see why you say it fails to add to
the "external world" (i.e., the player's attachment to the game world).
>> Angband's auto-target means less time tabbing among
>> potential targets. (And so does Nethack's directional targeting.)
>
> Tabbing, hmm...
You never thought of that? ;) (Naw, I don't know what "hmm" means.
Target tabbing is used in every turret shooter I've ever played, and
many strategy games like Warcraft and Wesnoth, so it can't possibly
be unfamiliar to you.)
Still, tabbing among options is just another kind of menu, and
again it typically has a "keyhole" of one element --- because not
every enemy visible on the screen is targetable, and you don't know
which ones /are/ targetable until you tab to them. If everything on
the screen is targetable, then you've got a normal menu.
>> However, notice that everything in that list doesn't just make
>> the game /quicker/, or reduce the number of keystrokes.
>
> Of course not.
Good, I'm glad you agree. I've seen a lot of UI discussions in
here devolve into "Gee, the player uses Cast-Missile-Current Target
an awful lot, so let's bind that command sequence to the 'H' key..."
>> Those are
>> things that actually increase immersion, because they mimic real
>> life. In real life (defined here as "the Lord of the Rings movies" ;)
>> it doesn't take any time or thought at all to draw an arrow from
>> your quiver, or scoop up an item from the ground.
>
> More precisely, by mimicking some of the real life mechanisms they allow
> for the most processing to be delegated to the primal, heavily automated
> yet very fast and effective, multitasking parts of the brain.
Yep.
>> Contrariwise, I hate games with auto-opening doors. In real life,
>> it /does/ take time and thought to open a door. You have to consider
>> whether you want to open it at all, for one thing --- maybe there's
>> something bad on the other side! Then you have to put your hand on
>> the knob and turn it, and so on. (Unless you're playing a giant who
>> reflexively smashes doors down instead of opening them, in which case
>> auto-open would be the Right Thing. Auto-open would also be close to
>> right in a Star Trek setting.)
>
> Not really. Honestly, how many times have you gone through a bulding and
> then coudn't recall if there were any doors in your way or whether they
> were opened or closed? How many times have you reflectively closed doors
> behind you, even though you've been explicitly told to leave them open
> because of summer heat?
It's not about remembering afterward; it's about thinking at the time.
Consider a SWAT team entering an unfamiliar building. Will they remember
the next day how many doors they opened? (No.) Will they plan carefully
before opening any of those doors during the raid? (Yes.)
> You do think before entering an unknown room --
> but you would hesitate the same if there was just a dark hole there
> instead of door.
True. I don't know; I see a qualitative difference between "Think;
open door; go through it" and "Think; jump into pit". Namely, the
"open door" step.
It's probably not worth the bandwidth to argue about doors any more.
BTW, it occurs to me that I would also not be opposed to a roguelike
in which "door" was simply a tile type that was opaque but could be
walked through, like this:
##### ##### ##### #####
@.+.. .@+.. ..@.m ..+@m
##### ##### ##### #####
What I'm objecting to are interfaces like Angband's auto-open option,
where the sequence of events is
##### ##### ##### ##### #####
@.+.. .@+.. .@'.m ..@.m ..'@m
##### ##### ##### ##### #####
even though the player has simply pressed "right" four times in a row.
For some reason, I want to force him to press "o" (or whatever) between
the second and third panels.
>> In short: Reflexive, unthinking actions should be reflexive and
>> unthinking in the game. Slow, considered actions should be slow and
>> considered in the game.
>
> They are usually composed of the small, reflexive ones.
Not for me.
>>>>>> What will you do when the user finds a wand of stone to mud and
>>>>>> wants to target that little section of wall there?
>>>>> This is easily handled by the Rogue's 8-way directions.
>>>> And of course, it's exactly the same problem than Rogue when you want to
>>>> target a monster that isn't in the 8-way directions.
>>> Why do you target a monster with a wand of stone to mud?
>> Don't play stupid. That's no fun for anyone.
>
> No, really, apologies, but I mean it. There are offensive items, and there
> are hm... utility items. You usually don't mix them. Even if you do, it's
> easy to avoid -- by game design. Then you can have a "choose direction"
> prompt for the utility stuff, and a "target monster" prompt for the
> offensive items. Using a wnad of stone to mud on a golem becomes then
> somehow even more satysfying.
Well, none of the major roguelikes "don't mix them". The original
question obviously used "stone to mud" as a stand-in for "random spell";
it doesn't matter whether the random spell was stone-to-mud or fireball.
If it makes you feel better, rephrase the question as "What if I find
a wand of fireball and want to target that little pool over there?"
> Yes. It's possible to explore the topic further and provide, e.g. special
> attacks for the fighter classes, where your previous position determines
> the kind of attack -- advancing makes a charge, retreating -- defensive
> stance, etc. Much better, in my opinion, than selecting them from a menu.
Yes. (So long as the "special" attacks are always strictly better
than the default attack. Otherwise, the player might sometimes get mad
that he's being forced to use his lance against a newt just because
his last two moves were in the same direction.)
>> The big BIG exceptions to my rule of thumb are the few excellent
>> games driven by a novel UI mechanic. Unfortunately, the only one I
>> can think of right now is "Joust" ("push button to flap wings").
>
> Ah, this mechanic was present in the oldest computer game ever, "lander".
No, I thought Lunar Lander had a regular old "up to increase jets,
down to reduce jets" control system. Anyway, it /certainly/ didn't
have "push to flap"; that doesn't make any sense in a spaceship
context! The point of Joust's "flap" button was that if you didn't
keep flapping, you'd fall. In Lunar Lander, you could just hold down
the "jet" control, and your jets would keep firing. Am I wrong?
>> One other arcade-game example I want to bring up, though, is the
>> now-ubiquitous driving sim in which you drive through "powerups" to
>> gain time or extra maneuverability, and the only interaction with
>> other cars (AI or other players) is by cutting them off or driving
>> into them. This is an excellent example of a simple "Verb" UI. The
>> verbs are "turn left" and "turn right", with "take your foot off the
>> gas pedal" for advanced users. Everything else comes out of that UI.
>
> I bet people tend to twist all ways and scream and shout and whatnot while
> playing it. I bet they are tormented by the poor quality of the gameplay
> and terrible immersion ;)
Your first sentence was right on the mark. I don't understand how
your second sentence follows from it, though. :)
>>> I don't think it's possible. Precise targetting is something that requires
>>> a focus switch even in the real world. However, precise targetting is
>>> extremly rare in the real world -- you usually target objects or areas.
>> Precise targeting doesn't require a focus switch if you are truly
>> immersed --- if you /are/ the character. If you take your eyes off the
>> "@" to look over there, it's because /your character/ is looking over
>> there. If you take your eyes off the "@" to consult a full-screen
>> menu of items in your knapsack, it's because /your character/ is
>> occupied in rummaging through his knapsack. But if you take your eyes
>> off the "@" to consult a drop-down menu, while /your character/ is
>> obviously still on-screen waiting to do battle, something is wrong.
>
> I really can't imagine a real-life situation where you're targetting
> something and not focussing on it. Even to the degree that Zen archers do.
But you're not focusing on "something else"; you're still immersed
in the game, focusing on what your character is seeing. When you come
up into a menu, suddenly you are no longer the eyes and ears of your
character; you have made a context switch and are focusing on "something
else".
-Arthur
Christophe Cavalaria
> True. I don't know; I see a qualitative difference between "Think;
> open door; go through it" and "Think; jump into pit". Namely, the
> "open door" step.
>
> It's probably not worth the bandwidth to argue about doors any more.
> BTW, it occurs to me that I would also not be opposed to a roguelike
> in which "door" was simply a tile type that was opaque but could be
> walked through, like this:
>
> ##### ##### ##### #####
> @.+.. .@+.. ..@.m ..+@m
> ##### ##### ##### #####
>
> What I'm objecting to are interfaces like Angband's auto-open option,
> where the sequence of events is
>
> ##### ##### ##### ##### #####
> @.+.. .@+.. .@'.m ..@.m ..'@m
> ##### ##### ##### ##### #####
>
> even though the player has simply pressed "right" four times in a row.
> For some reason, I want to force him to press "o" (or whatever) between
> the second and third panels.
I agree mostly with everything you've said, but I just cannot agree with
that! Auto open door is a good thing in my opinion. When you are walking
through a corridor with a door in the middle, it is very appropriate for a
lot of reasons :
- walking into a closed door and recieving the error message "there's a
closed door here dummy, you can't pass!" is annoying
- it is much much easier to type
- the o key for open door is much more difficult to use : you have to press
o and then specify a direction to open the door. Since you have to specify
the direction at that point and that there isn't any other obvious command
the user would do when bumping into a door, the o command is useless here
Yes I know the last two points are nearly the same ;)
Andrew Doull
> Arthur J. O'Dwyer wrote:
> > True. I don't know; I see a qualitative difference between "Think;
> > open door; go through it" and "Think; jump into pit". Namely, the
> > "open door" step.
> >
> > It's probably not worth the bandwidth to argue about doors any more.
> > BTW, it occurs to me that I would also not be opposed to a roguelike
> > in which "door" was simply a tile type that was opaque but could be
> > walked through, like this:
> >
> > ##### ##### ##### #####
> > @.+.. .@+.. ..@.m ..+@m
> > ##### ##### ##### #####
> >
> > What I'm objecting to are interfaces like Angband's auto-open option,
> > where the sequence of events is
> >
> > ##### ##### ##### ##### #####
> > @.+.. .@+.. .@'.m ..@.m ..'@m
> > ##### ##### ##### ##### #####
> >
> > even though the player has simply pressed "right" four times in a row.
> > For some reason, I want to force him to press "o" (or whatever) between
> > the second and third panels.
>
> I agree mostly with everything you've said, but I just cannot agree with
> that! Auto open door is a good thing in my opinion.
There's also a number of strategic reason. Opening a door to move through it
takes time - usually which you care about when the monster starts adjacent to
you. In the example you gave at the top, the '+' is a curtain, not a door. You
also get the option of closing or leaving the door open behind you. [1]
You could make steps 2 and 3 (bump into door to open it, then move into the
doorway) an interruptible action taking two turns, but only requiring one key
press (unless you are interrupted of course), if that helps your
sensibilities.
Andrew
[1] Which asks the question why Angband doesn't have an auto-close function?
[2]
[2] It of course does, its called the Borg on a level full of breeders.
--
The Roflwtfzomgbbq Quylthulg summons L33t Paladins -more-
http://unangband.berlios.de
Christophe Cavalaria
> There's also a number of strategic reason. Opening a door to move through
> it takes time - usually which you care about when the monster starts
> adjacent to you. In the example you gave at the top, the '+' is a curtain,
> not a door. You also get the option of closing or leaving the door open
> behind you. [1]
Curtain-like doors is fine in my opinion. A little unexpected but a clever
way to code them. They do feel a little like automatic Star Trek doors
though.
> You could make steps 2 and 3 (bump into door to open it, then move into
> the doorway) an interruptible action taking two turns, but only requiring
> one key press (unless you are interrupted of course), if that helps your
> sensibilities.
I have difficulties seeing your problem here. What do you want to do with
that poor door? There are only 1 action you can do on a closed door : open
it. Well, you could bash it or something but it would be somewhat retarded
most of the time : who would bash an unlocked door?
I'm also fine with the doors as they are in Angband with auto open. What I
find distressing is forcing the user to use the flawed o command to open a
door when bumping into it with auto open works prefectly IMHO. Now, if you
could give a real reason why the o command is better.
> Andrew
>
> [1] Which asks the question why Angband doesn't have an auto-close
> [function? 2]
>
> [2] It of course does, its called the Borg on a level full of breeders.
Because, for the same reason that bumping into a closed door can only mean
ONE thing, walking into an open door will 99.99% of the time mean to
walk ;)
Brendan Guild
> smaller items on top of larger ones? Then add 3 commands to move
> items between the stacks, and make the order of items in the first
> stack control what is euqipped...
I am guessing that you are saying that my idea is ridiculous, but I
am not so sure that it can be illustrated by an even more ridiculous
example. I think that my idea might be intuitive and manageable.
Suppose that we have a tall and thin message area on the left or
right side of the screen. Messages could start at the bottom and
scroll up as new messages accumulate, but we could also fill the top
of that area with an inventory listing, with the most recent item at
the bottom, so it grows downwards. It wouldn't be a menu of any sort,
since the player cannot select from it, but it would allow the player
to see the state of the inventory.
Naturally, we wouldn't really have multiple stacks when the stacks
are based upon item type, it is just one stack that is pushed with
',' to get items from the floor. Then 'd' can pop the actual top item
off, while other keys will search down the stack for the most recent
item of a certain category.
For moving things around, quickly picking up and dropping again, ','
and 'd' would be convenient because 'd' always drops what ',' just
picked up with no menu needed.
I really do think I see what you are getting at, though. You are
saying that I am still making the internal structure of the PC too
complicated, and probably that a stack based system is even more
complicated than a slot based system. But I like what you have said
about menus breaking immersion. Surely there is some simple way to
avoid menus entirely.
An undesirable aspect of a slot based system for scrolls and potions
is that it is like a modal interface, the effect of a key tied to a
certain potion slot depends entirely on the potion in that slot.
Therefore, I propose a slotless, stackless, modeless, menuless system
as follows:
Each key represents a certain abstract action, such as healing,
cleaving, turning stone to mud, or any of the other things which a PC
might do. Since we cannot select spells from a menu, we will have to
resort to key combinations to represent all the possible actions.
There are no keys for zapping or quaffing. Each item in the inventory
represents a certain ability for the player, such a healing potion.
The PC drinks the healing potion when the player hits the heal key.
If the PC had a healing spell, that could have been used in place of
the potion. The potion and the spell represent the same ability, so
they are associated with the same key. A different key would
represent becoming invisible in the same way.
More importantly, if you have two healing potions, there is no need
to ask the player which of the two should be quaffed; just pick one
automatically. Supposing 'h' means 'heal' instead of 'left'; pressing
'h' could cause the PC to be healed by any means available, while
pressing 'qh' would ask the PC to drink any healing potion available
and 'Zh' would cast your best healing spell, if you have any.
Weapons could be handled in the same way, without wielding. You could
have different keys for attacking with a dagger vs. attacking with a
sword, assuming that there are significant rule differences between
the two. Otherwise you could just automatically attack with the most
powerful weapon in the inventory. Similarly, you can assume that the
PC is wearing all of the armor in the inventory.
You still get all the fun of collecting items, because each item
gives you new abilities and makes killing stuff easier. All we have
lost is inventory management and equipping.
Plus, this can be combined with the 'drop all' command to allow
individual inventory items to be manipulated on the floor in a quiet
moment, for getting rid of junk or polymorphing or dipping. If you
really want weapons, armor, and rings slots, then you can still equip
from the floor.
Arthur J. O'Dwyer
On Wed, 10 Jan 2007, Christophe Cavalaria wrote:
> Andrew Doull wrote:
>> There's also a number of strategic reason. Opening a door to move through
>> it takes time - usually which you care about when the monster starts
>> adjacent to you. In the example you gave at the top, the '+' is a curtain,
>> not a door. You also get the option of closing or leaving the door open
>> behind you. [1]
>
> Curtain-like doors is fine in my opinion. A little unexpected but a clever
> way to code them. They do feel a little like automatic Star Trek doors
> though.
To me, the "bump to open" doors feel more Star-Trekky. It's like I
press "right" to go right, but there's a door in the way, so the game
reads my mind and decides that I want to open the door instead.
"It is their pleasure to open for you, and their satisfaction to close
again with the knowledge of a job well done." :(
>> You could make steps 2 and 3 (bump into door to open it, then move into
>> the doorway) an interruptible action taking two turns, but only requiring
>> one key press (unless you are interrupted of course), if that helps your
>> sensibilities.
>
> I have difficulties seeing your problem here. What do you want to do with
> that poor door? There are only 1 action you can do on a closed door : open
> it. Well, you could bash it or something but it would be somewhat retarded
> most of the time : who would bash an unlocked door?
(I think you're really addressing me, not Andrew, so here's my take on
that comment.) Actually, there /are/ other things I could do to a door;
I could pick the lock, or zap it with a fireball, or examine the writing
on it, or spike it shut, to name a few. I agree that opening it is the
most /likely/ action, yeah.
But also consider that in real life, bumping into a door just hurts a
little and doesn't accomplish anything; the door doesn't magically open
itself.
...Unless it's a swinging door, or it's unlatched and swings inward.
Actually, a game with an "inward/outward" distinction on the doors would
be extremely novel, IMHO!
...And yeah, my argument is stupid, because in real life bumping into
an orc doesn't kill it, either; it just hurts a little and doesn't
accomplish anything. So maybe it's purely a religious thing. See, I
/said/ it would be a waste of bandwidth to argue about doors!
Here's an idea. Maybe the designer wants to be less unfriendly to
newbies, by making the game "prompt" any time an irreversible action
is taken. By "irreversible", I mean an action that qualitatively changes
the state of the dungeon. And by "state of the dungeon", I mean
connectivity. You don't need to prompt when the user is just moving
around the dungeon normally, because that's just quantitatively
changing the character's distance from visible monsters. But if the
user is about to change the dungeon state in a fundamental way ---
opening or closing a door, digging a tunnel, going up or down stairs
--- then he ought to be prompted.
Remember, by your most recent argument, since bumping into a wall
can ONLY mean "dig", the game ought to provide auto-dig. But by the
logic I just presented, all five of dig/open/close/up/down ought to
have special keystrokes, and indeed in Nethack and Angband they do:
Ctrl-direction, 'o', 'c', '<', and '>'.
In a "fully 3D" roguelike, in which the vertical dimension was just
another direction,[1] I would expect to be able to walk down a slope
into a new part of the dungeon in a continuous way, without any
qualitative, discontinuous change in the dungeon map. In a game like
that, I wouldn't expect "up" and "down" to need special keystrokes.
Likewise, if your doors work like curtains (excellent analogy, BTW!),
then going through them doesn't change dungeon connectivity, so it
doesn't require a special keystroke. Or is that last bit of reasoning
circular?
-Arthur
[1] - I /know/ this idea has come up here before, and I've drawn
"screenshots" for it. But I can't find them with Google.
Nolithius
<snip>
Similarly, you can also have a shift-W command which [W]ins the game :D
Seriously, though, you're creating a game which "optimizes" your selection
of spells, usable items, weapons, etc., which nerfs the decision-making.
Games are about making choices, and there is a clear difference in the game
*facilitating* how you make the choice, and making the choice for you.
Making the choice of how to heal yourself, for example, is a LARGE part of
the challenge in complex games like RLs.
I think The Sheep's concern is about how to facilitate
player-character-world interaction in a way that _maintains immersion_ and
does not negatively impact the gameplay (as in the system you have
proposed). The idea here is not necessarily to make the choices easier for
the player-- but to provide an intuitive interface that does not require the
sort of interaction that reminds you that you're choosing something from a
computer screen menu rather than looking through your potions. [1]
Earlier it was suggested that to make "Throw" 'better' you can just 'drop'
the item and 'kick' it in the desired direction. I for one find this
laughable at best. Maybe if I was playing some Kirby game or something, but
an RL?
Doing away with menus *entirely* just might not be the right choice,
specially if it creates futher convoluted situations which require arbitrary
immersion-breaking actions.
A common game-design mantra for some designers is "The best interface is no
interface." Obviously this idea is a hyperbole at best, since until we can
play games directly by thought we will need some way to interface with the
machine. The rationale is that if you spend enough time in a [specifically
modal] interface, you start playing the interface and not the game-- killing
immersion. Unfortunately what is happening here by what you suggest,
Brendan, is that you're frantically eliminating a menu-list interface and
instead providing a convoluted 'mash all these keys in the correct order to
fire a spell' interface-- breaking immersion just the same :)
There are different levels of choices you make while playing a game, some
rather trivial, some absolutely game-altering-- this is what we expect and
desire. Choosing how to heal yourself, for example, has moderate to high
consequences, depending on the game state; removing this choice takes a
chunk of the challenge out of the game, as well as 'always selecting the
best weapon from your inventory'.
The idea is the following: once you have an established game design (and I
say this because I am of the school of thought that the interface serves the
game, and not that the game serves the interface), you must decide what
exact challenges/choices the player must make through the game, and estimate
their impact.
The best practice is then to normalize: make the absolutely-game-altering
choices more forgiving, and make the rather trivial choices more important.
Ideally you'd throw out choices from either end of the spectrum which cannot
be normalized, with the goal of maintaining the choice set in a healthy area
(at the designer's discretion, of course). The corollaries of this approach
are that you do not modify choices that have moderate impact, and that you
definitely *do not* remove these choices either (as you suggested with
auto-healing and auto-weapon, both moderate-level choices in most games).
As an example of a high-impact choice that should be made more lenient, most
games have choices at character creation which [often undesiredly] grossly
affect the game; these choices need to be scaled down to either affect the
game in a more moderate way or be broken down into several choices,
preferably made during the course of the game, once the player has knowledge
of the game world and mechanics. A specific absolutely trivial choice which
comes to mind that should be either removed or made more important is the
status menu choices in Paprika, the one that jumps out at me is a checkbox
which asks you if you want to display or hide your Sex in the status box.
This is so grossly trivial that it warrants either removal or to be part of
a larger block of show/hide status entries, so that you don't have to check
on/off every single trivial thing (there are like 20), but rather more
significant blocks of maybe 5 each, for example.
Going back to the spirit of the thread, it follows that the less impacting
choices should be easier to access, and the more impacting choices require
interfaces that allow for more in-depth consideration. Walking, for example,
a low-level choice (at least while not in combat) should have a
straightforward interface, because it is a straightforward action with
little consequences in case of error. Selecting which monster to fireball,
on the other hand, is a medium-to-high impact choice (which can even cause
character death in case of error), therefore it requires an appropriate
interface that can allow the player to make the choice as he intented. This
is why I disagree with The Sheep's proposition for a 'smart-8-directional'
targeting system (somewhere in the thread) because ambigous cases are solved
at the discretion of the game, and not the player-- this surrendering of
control represents a loss in immersion.
I know it looks like I ranted a bit but the idea of normalizing game choices
and providing them with adequate interfaces is definitely worth considering,
and a boon to immersion :)
--Nolithius
Billy Bissette
news:Pine.LNX.4.61-042....@unix36.andrew.cmu.edu:
> But also consider that in real life, bumping into a door just hurts
> a little and doesn't accomplish anything; the door doesn't magically
> open itself.
In real life, bumping into a monster just hurts a little, and doesn't
cause you to repeatedly swing a warhammer at its head.
Auto-open is a useful simplification. If you press right, you want to
go right. If there is a door in the way, you'll need to open it to go
right. So pressing right tries to open the door.
If it really bothers you, you could recode a game so that bumping a
door was treated as bashing (attacking) it... Or just open it by
command.
As for someone earlier questioning the lack of auto-close, there is a
difference between auto-open and auto-close. Whenever you bump into a
door, barring weird circumstances (accidental keypress or confusion), it
is obvious that you want to take the time to open the door. It is not
obvious that you always want to take the time to close a door behind
you. Plus you'd then need the ability to "move without closing," as
even if you are a rabid door closer, there will be times when you want
to leave it open. (An extra keypress and extra thought to go through
a door without closing it is more unnatural than opening a door to pass
through it.)
Christophe
> But also consider that in real life, bumping into a door just hurts a
> little and doesn't accomplish anything; the door doesn't magically open
> itself.
But by that same argument, since bumping into a door serves nothing,
it's obvious that it wasn't what the user wanted to do.
> ...Unless it's a swinging door, or it's unlatched and swings inward.
> Actually, a game with an "inward/outward" distinction on the doors would
> be extremely novel, IMHO!
> ...And yeah, my argument is stupid, because in real life bumping into
> an orc doesn't kill it, either; it just hurts a little and doesn't
> accomplish anything. So maybe it's purely a religious thing. See, I
> /said/ it would be a waste of bandwidth to argue about doors!
Well, maybe it's an idea for a 7DRL though : bumprogue, kill your
opponents by bumping into them to death. You'll play an overweight human
for that a collect foods to increase your weight and your damage
potential. But the longer you stay in the dungeon, the more your weight
will decrease :)
> Remember, by your most recent argument, since bumping into a wall
> can ONLY mean "dig", the game ought to provide auto-dig. But by the
> logic I just presented, all five of dig/open/close/up/down ought to
> have special keystrokes, and indeed in Nethack and Angband they do:
> Ctrl-direction, 'o', 'c', '<', and '>'.
Well for the same argument, 99.99% of the time when a player bumps into
a wall, it was because he wanted to not do it. The game should then help
the user and take the most obvious action in such situation : do nothing.
Gamer_2k4
> opponents by bumping into them to death. You'll play an overweight human
> for that a collect foods to increase your weight and your damage
> potential. But the longer you stay in the dungeon, the more your weight
> will decrease :)
Good call. The 7DRL Challenge SHOULD be coming up soon (I keep
mentioning it and no one says anything), and it might be interesting to
see.
> Well for the same argument, 99.99% of the time when a player bumps into
> a wall, it was because he wanted to not do it. The game should then help
> the user and take the most obvious action in such situation : do nothing.
Well, for the same argument, 99.99% of the time when a player bumps
into a door, he didn't mean to. UNLESS there was an auto-open feature.
I'm sure the same would apply to digging.
Gamer_2k4
David Damerell
>Seriously, though, you're creating a game which "optimizes" your selection
>of spells, usable items, weapons, etc., which nerfs the decision-making.
Rubbish. Having a "use most powerful healing item" key doesn't obviate the
decision to use the most powerful item. Automatically attacking with the
most powerful weapon - either the player had the weapon stats and you're
just saving them comparing two numbers, or they didn't and you wanted them
to play guessing games, which isn't any kind of decision making.
>Making the choice of how to heal yourself, for example, is a LARGE part of
>the challenge in complex games like RLs.
And in severe danger, the choice will be "maximum effect". Pressing the
key that does that is making the choice whether or not you are required to
do the book-keeping of looking through your inventory.
--
David Damerell <dame...@chiark.greenend.org.uk> Distortion Field!
Today is Second Potmos, January.
Andrew Doull
> > Well, maybe it's an idea for a 7DRL though : bumprogue, kill your
> > opponents by bumping into them to death. You'll play an overweight human
> > for that a collect foods to increase your weight and your damage
> > potential. But the longer you stay in the dungeon, the more your weight
> > will decrease :)
>
> Good call. The 7DRL Challenge SHOULD be coming up soon (I keep
> mentioning it and no one says anything), and it might be interesting to
> see.
It sounds like the 7DRL this time round should be themed 'Pet Peeves about
Roguelikes'.
Someone can do a PPAngband variant: implementing only the worst features of
Angband.
Andrew
B0rsuk
one mentioned SOUND before. Good sound is very good for immersion. I
like it a lot in DoomRL.
Har !
Nolithius
news:hpB*wD...@news.chiark.greenend.org.uk...
This is a naive approach to game design.
I will tackle both issues separately:
Healing: You misunderstood the previous poster, he did not suggest a "use
the most powerful healing item" key, but rather "heal in the most powerful
way you can" even as a default key-- with another set of keypresses to make
the choice. This choice is of moderate to high consequence, and you do not
want to trivialize how it is chosen, as you then either remove the choice,
or worse, produce undesired situations for the player. The obvious scenario
to point out is if your most powerful healing source is a spell that costs
all your remaining mana, when in fact you were saving that mana for an
offensive spell next turn. Here you have two choices, both moderate-to-high:
healing, and offensive spellcasting. In this scenario you severely hamper
the choice availability, when in fact you'd want to increase it.
In addition, once a choice drops to trivial, it should be either removed or
made more important. This is the case with most games' healing potions, for
example. In most games, the healing potion you acquired in the early-mid
game is absolutely useless in the late game; or a low-level healing spell is
just taking up space in the interface because you'll probably never use it
either. Several answers have been posed for both of these cases, namely
normalizing healing potions and making the same spell more powerful (instead
of gaining a new one). You'll notice that once this is the case your choice
is much more meaningful and no longer obvious, and definitely does not
warrant a 'make the best choice for me' key.
Granted, if you choose to have obvious choices in your game-- then might as
well implement a key that 'makes the obvious choice'. The idea is to do away
with obvious choices (see my previous post).
Weapon selection: on the same vein, sometimes you pickup an unarguably
superior weapon to yours, and of the same type in which you are skilled, to
boot. Some games will autoequip the better weapon on pickup. Note that this
is OK: since the choice is trivial, the game removes the need for you to
make it by doing for you. However, let's say you find a mace that is much
better quality than your short sword, but you are skilled in swords, not
maces. Should the game make the choice to autoequip the mace? Of course not.
The choice is no longer trivial so it must not be removed from the player's
discretion. Neither is the choice trivial, for example, if you find a more
accurate but less damaging sword.
Similarly, different situations might call for different weapons, namely
different monsters. Most will probably agree that autoswitching to a mace
when fighting to a skeleton is unacceptable-- this choice must be made by
the player.
In closing, having a key that 'makes the best choice' or the game
automatically making the choice for you is only acceptable if the choice is
trivial and thus warrants removal. If the choice is non-trivial it must be
left to the player unless you consciously want to remove that challenge from
the game.
--Nolithius
Gamer_2k4
> one mentioned SOUND before. Good sound is very good for immersion. I
> like it a lot in DoomRL.
Good point. The monster noises are good too. Bone to be Wild tries to
do the same thing, but it gets old after about 30 seconds,
unfortunately.
Gamer_2k4
Radomir 'The Sheep' Dopieralski
Arthur J. O'Dwyer wrote:
> On Tue, 9 Jan 2007, Radomir 'The Sheep' Dopieralski wrote:
>> At Mon, 8 Jan 2007 14:35:15 -0500 (EST),
>> Keeping the train of thought intact is not exactly my goal here. It's
>> rather more like making it break in the game's world rather than in
>> the menus or other parts of interface -- so that you think, look around,
>> analyze situation, etc. while controlling the avatar, not while
>> controlling the menu cursor.
> "Train of thought" wasn't the right phrase there. "Suspension of
> disbelief", perhaps? The idea I was trying to get across --- and I think
> you've been agreeing with this much all along --- is that if the player
> spends too much time in inventory management and menu systems, he'll
> remember he's using a computer and not sneaking through a dungeon.
Yes, this I agree, only with a small correction. It's not about the actual
time spent in there -- it's about the "huh? where am I" check. It's all
good, even for extended time spans, as long as you don't get that "you are
no longer in the dungeon" hint -- either by changing the view dramatically
or by providing a cursor (explicit or just imagined by the user).
<snip>
>> Of course, a "missile" slot a la Angband or ADOM (and recently even
>> NetHack) would remove one step -- but at a cost of increased **internal**
>> complexity. Adding facing is too awkward and complicated, and a text-mode
>> roguelike would count as internal state anyways. Throwning might be maybe
>> composed of a "drop" and "kick" commands...
> I think we're agreeing that immersion is made easier if most of the
> actions are "in-game-world" and not menu-based. But the point on which
> I disagree with you is the "reductionist" approach you're displaying
> in the above paragraph. Throwing is *NOT* just dropping something and
> then kicking it! Kicking uses the feet; throwing uses the hands. And
> unless you're a soccer star, throwing is bound to be more accurate.
> If you force the player to type "drop+kick" when he wants to "throw",
> you're breaking the fourth wall and reminding him that he's using a
> computer, not throwing an object.
You are right, this is a separate thing, thank you, I didn't realise it
before.
> Additionally, I don't understand /why/ you are reducing "throw" to
> "drop+kick". It seems to go against what I understand as your main
> thesis, which is (roughly speaking) that menus are bad. "Throw" needs
> a menu to select an item. "Drop" needs the exact same menu. Replacing
> one by the other doesn't avoid any UI issues. So why would you do it?
So that there is not "which menu I'm in now" doubt.
<snip>
>>> Simple combat mechanics mean less time switching weapons (to use
>>> a pike against a knight and a club against an orc, for example).
>> Or just make switchng the weapons a single keystroke, like in some
>> action games -- just press it multiple times. Works well when it
>> doesn't consume turns.
> "Press a key multiple times to scroll through an enumeration of
> nouns" is /exactly/ a menu.
Yes. If you read my initial post carefully, you will surely notice that
I don't have, in fact, nothing against menus in general. I only want to
avoid -- among other mechanisms that produce a sense of location -- menus
utilizing cursors. The "abc menus" are ok as long as there is no nesting
and multiple choices.
And yes, an abc-style menu is *perfect* in this
case, as it gives you all the information you need, encourages and makes
use of habituation, and on top of all that doesn't have even an "imagined"
cursro, or "keyhole", as Meyers calls it in the very interesting article
you provided.
> The decision to make weapon selection
> accessible only through that kind of scrolling menu was IMHO possibly
> /the/ worst design decision in Grand Theft Auto III, for example.
> You might say, "Oh, it's not a menu, because only one item is
> visible at a time." I say that's a menu with an absurdly small
> "keyhole", to borrow a term from Scott Meyers' otherwise ridiculous
> and whiny paper "The Keyhole Problem":
> http://www.aristeia.com/TKP/
> If I want to select the shotgun, I have to remember that it comes
> after the pistol in my weapons list. A better menu interface would
> show me /all/ my weapons, so I wouldn't need to recall that fact
> every time I want the shotgun. And even better designs would be
> to reduce the number of weapons (if that didn't sacrifice gameplay),
> or assign a hotkey to each commonly used weapon (if the keyboard
> had keys to spare).
> (Actually, GTA3 might already use hotkeys. I don't know. But
> just pretend it didn't, and then read my rant again in that context.)
I don't really care if it's a menu from the technical standpoint. At this
point I only care how it "feels" like -- in particular, if it makes you
feel like you are moving somewhere. That's why any kind of preview for
the previous and next items would ruin it.
I am also ready to sacrifice some (not much) usability for the sake of
this "mechanical immersion".
>>> Specialized inventory slots like "Quiver" mean less time selecting
>>> ammunition.
>> This I'm trying to avoid, as it adds to the "internal" world, not the
>> "external" one.
> I don't get it. I agree that "Quiver" is extra work for the programmer,
> but if it also provides convenience and immersion for the player, you
> shouldn't shrink from it.
I don't think of it in terms of what is easier to code or design. This is
simply irrelevant, and of course an additional slot doesn't have to be
hard to code -- I'd rather say it's undistinguishably easy.
> In other words, I see how it adds to the "internal world" (i.e.,
> the source code?), but I don't see why you say it fails to add to
> the "external world" (i.e., the player's attachment to the game world).
Internal world == the player character, his stats, skills, experience,
hunger, equipment slots, anything not "physical" displayed on the screen,
like various cursors, indicators, health bars, minimaps and annoying paper
clips offering help.
External world == the game's world, including (but not limited to) walls,
doors, floor tiles, monsters, items lying on floor, blood splashes,
screams, shopkeepers, effects of magic spells, etc.
<snip>
>> Not really. Honestly, how many times have you gone through a bulding and
>> then coudn't recall if there were any doors in your way or whether they
>> were opened or closed? How many times have you reflectively closed doors
>> behind you, even though you've been explicitly told to leave them open
>> because of summer heat?
> It's not about remembering afterward; it's about thinking at the time.
> Consider a SWAT team entering an unfamiliar building. Will they remember
> the next day how many doors they opened? (No.) Will they plan carefully
> before opening any of those doors during the raid? (Yes.)
This is a little unfair. A SWAT team during an action operates in a little
different mode of thought -- focused and untrusting. This is not possible
to keep up for more than, say, a half an hour. Falling back to the
"normal" operation mode (because of psychical fatigue) is a common reason
for many deaths and injuries in SWAT, btw. But that aside, unless you're
making a coffee-break roguelike, your players won't be able to stay in the
"watch out" mode for long. Which is visible if you look at the statistics
of deaths in Nethack and Angband too, incidentally.
>> You do think before entering an unknown room --
>> but you would hesitate the same if there was just a dark hole there
>> instead of door.
> True. I don't know; I see a qualitative difference between "Think;
> open door; go through it" and "Think; jump into pit". Namely, the
> "open door" step.
> It's probably not worth the bandwidth to argue about doors any more.
> BTW, it occurs to me that I would also not be opposed to a roguelike
> in which "door" was simply a tile type that was opaque but could be
> walked through, like this:
> ##### ##### ##### #####
> @.+.. .@+.. ..@.m ..+@m
> ##### ##### ##### #####
Nice idea -- simplifies a lot of map-handling code without really making
doors boring...
> What I'm objecting to are interfaces like Angband's auto-open option,
> where the sequence of events is
> ##### ##### ##### ##### #####
> @.+.. .@+.. .@'.m ..@.m ..'@m
> ##### ##### ##### ##### #####
> even though the player has simply pressed "right" four times in a row.
> For some reason, I want to force him to press "o" (or whatever) between
> the second and third panels.
Looking at my own play style, I must admit I do treat "open door and walk"
keypress differently than all other "walk" keypresses. Yet still I prefer
games with "auto open" enabled -- maybe it's because "o" is in such an
inconvenient place when using keypad...
>>>>>>> What will you do when the user finds a wand of stone to mud and
>>>>>>> wants to target that little section of wall there?
>>>>>> This is easily handled by the Rogue's 8-way directions.
>>>>> And of course, it's exactly the same problem than Rogue when you want to
>>>>> target a monster that isn't in the 8-way directions.
>>>> Why do you target a monster with a wand of stone to mud?
>>> Don't play stupid. That's no fun for anyone.
>> No, really, apologies, but I mean it. There are offensive items, and there
>> are hm... utility items. You usually don't mix them. Even if you do, it's
>> easy to avoid -- by game design. Then you can have a "choose direction"
>> prompt for the utility stuff, and a "target monster" prompt for the
>> offensive items. Using a wnad of stone to mud on a golem becomes then
>> somehow even more satysfying.
> Well, none of the major roguelikes "don't mix them". The original
> question obviously used "stone to mud" as a stand-in for "random spell";
> it doesn't matter whether the random spell was stone-to-mud or fireball.
> If it makes you feel better, rephrase the question as "What if I find
> a wand of fireball and want to target that little pool over there?"
Well, you can't, or at least you can't directly, without some
preparations. If you really really need that in your game (for gameplay
purposes), maybe a separate action would be justified -- or reuse some of
already existing in-game mechanics (somehow)...
<snip>
>> I bet people tend to twist all ways and scream and shout and whatnot while
>> playing it. I bet they are tormented by the poor quality of the gameplay
>> and terrible immersion ;)
> Your first sentence was right on the mark. I don't understand how
> your second sentence follows from it, though. :)
Well, that's what tortured people usually do, no?
>>>> I don't think it's possible. Precise targetting is something that requires
>>>> a focus switch even in the real world. However, precise targetting is
>>>> extremly rare in the real world -- you usually target objects or areas.
>>> Precise targeting doesn't require a focus switch if you are truly
>>> immersed --- if you /are/ the character. If you take your eyes off the
>>> "@" to look over there, it's because /your character/ is looking over
>>> there. If you take your eyes off the "@" to consult a full-screen
>>> menu of items in your knapsack, it's because /your character/ is
>>> occupied in rummaging through his knapsack. But if you take your eyes
>>> off the "@" to consult a drop-down menu, while /your character/ is
>>> obviously still on-screen waiting to do battle, something is wrong.
>> I really can't imagine a real-life situation where you're targetting
>> something and not focussing on it. Even to the degree that Zen archers do.
> But you're not focusing on "something else"; you're still immersed
> in the game, focusing on what your character is seeing. When you come
> up into a menu, suddenly you are no longer the eyes and ears of your
> character; you have made a context switch and are focusing on "something
> else".
That's why it might be actually good to leave the cursor-based interface
for the rare cases when you need the point-precise targeting. But don't
make your designer's life easier by reusing it for everything just because
it's so flexible.
PS.
sorry for the long time to answer
--
Radomir `The Sheep' Dopieralski
Besides a mathematical inclination, an exceptionally good mastery of one's
native tongue is the most vital asset of a competent programmer. [Dijkstra]
some
lines
of
text
to
make
this
moronic
news
server
allow
posting
without
claiming
that
I
need
to
have
more
new
text
than
included
doh
Brendan Guild
> In closing, having a key that 'makes the best choice' or the game
> automatically making the choice for you is only acceptable if the
> choice is trivial and thus warrants removal. If the choice is
> non-trivial it must be left to the player unless you consciously
> want to remove that challenge from the game.
Perhaps it was not clear, but the point of my proposal was to reduce
the internal complexity of the PC in accordance with the interface
ideas of The Sheep. I want to avoid changing the cursor during play,
therefore no menus and no choosing from inventory listings, but I
also want to avoid putting structures into the PCs inventory that
could compensate for lack of menus, such as slots or stacks.
So when I make 'h' into an abstract heal key, or 'F' into an a key
for fighting with the most powerful weapon, then I do it because I
want to remove more detailed choices from the game. I am consciously
eliminating a weapon slot to simplify the PC, and I am consciously
eliminating a inventory menu to keep the cursor consistent.
In practice, I would have a weapon slot where the PC could wield from
the floor but having no weapon slot works as a dramatic illustration
of the principle.
With The Sheep's ideas in mind, I suggest a roguelike that has the
following properties:
The map and the @ are visible at all times between character creation
and death (aside from when the game is suspended and perhaps during
help screens for novice players).
The screen is divided into two areas, one active and one passive. The
active area shows only the map and the cursor '@', while the passive
area shows messages, PC information, inventory, and anything else.
The passive area is entirely for the player's information and nothing
shown there can be modified directly by pressing keys. (Of course,
there would be keys for changing which information is displayed, but
not the facts that the information represents.) And if the
information can be modified by pressing keys, then the same change
would have happened by those keys with or without that information
being displayed.
The active area is only used to represent the current state of the
game in the area close to the PC. It should not change during a turn
in response to the player pressing keys, only at the end of the turn
when something actually happens in the game. Otherwise, a false
cursor might be created. However, animation effects are allowed in
the active area, if they are not controlled by the player.
There is no place on the screen for asking the player direct
questions in the form of a menu or prompt of any sort. There will be
no confirmation prompts, including those that change the meanings of
'y' or 'n'; the player will be assumed to be aware of the choices
made so that no confirmation is needed. (Naturally, leaving the game
through saving, abandoning the character, or directing the PC to
commit suicide can be exceptions to this rule, as well as any other
time at which immersion is inevitably broken because the game is
stopping.)
There will be no 'more' prompt to indicate that the message area was
too small to display the messages for everything that happened during
the last turn. Instead, the message area will be large enough to
accommodate any number of messages that might be needed. In times
where there is a large number of messages, the message area could
overwrite other information in the passive area or the messages could
be made more concise by using abbreviations. It could also be that
only one monster can attack during a turn.
Without menus or prompts, the keyboard directly represents every
possible action that the player can choose, and it has no modes that
last past the end of a turn.
In principle, for any particular key and any particular game effect,
pressing that key at any time should have exactly that effect or else
it can have that effect at some times and produce an error at others.
Errors do not have game effects, do not end the turn and do not
advance time.
However, because the keyboard has a limited number of keys, some
actions must be represented by sequences of keys where keys can act
as a modifier to later keys, changing the effect of those keys.
Modifier keys create new modes, but those modes are not to last
beyond the current turn, and there must be an escape key devoted to
returning the keyboard to the mode that it has at the start of each
turn.
Any particular sequence of keys must either produce the one effect
that it is associated with, or it can produce an error. For example,
in Nethack, 'qe' might cause the PC to be healed on one turn, while
causing the PC to hallucinate on another turn. That is forbidden
under these rules because it is a mode for 'qe' that lasts for more
than a single turn.
The term "game effect" can be interpreted loosely or tightly. Under a
tight interpretation, when a strong PC smashes a club into the skull
of a monster it is a different game effect then when a weak PC
smashes the same club into the same skull. The difference is
quantitative, because the monster suffers more damage in one effect
than the other. This could be represented by having the player press
one of the keys '1' through '9' to indicate how hard to swing the
club, with higher numbers producing errors for weaker PCs. This gives
the player a clear indication of becoming more powerful.
On the other hand, such a system might be taking this idea a bit too
far, so we can use a looser interpretation of "game effect" where
smashing a club is always considered the same effect no matter how
hard or what sort of thing is on the other end of the smash.
Naturally, we would never interpret "game effect" so tightly that
every individual monster in the course of the game would require its
own key sequence to fight (as perhaps presented in the message area
upon sight of the monster, such as Zombie 'abc', Gridbug 'qwerty',
and Demons 'tty' and 'dvorac'). But doing so would be showing the
spirit of these rules and it would give each monster its own
individual name which might be fun. It would also prevent
accidentally attacking the wrong monster and make it simple to create
commands for precisely targeted long-range attacks, which might
otherwise be difficult under these rules.
Gamer_2k4
Sounds like Gearhead.
> The screen is divided into two areas, one active and one passive. The
> active area shows only the map and the cursor '@', while the passive
> area shows messages, PC information, inventory, and anything else.
> The passive area is entirely for the player's information and nothing
> shown there can be modified directly by pressing keys. (Of course,
> there would be keys for changing which information is displayed, but
> not the facts that the information represents.) And if the
> information can be modified by pressing keys, then the same change
> would have happened by those keys with or without that information
> being displayed.
Sounds like Gearhead.
> The active area is only used to represent the current state of the
> game in the area close to the PC. It should not change during a turn
> in response to the player pressing keys, only at the end of the turn
> when something actually happens in the game. Otherwise, a false
> cursor might be created. However, animation effects are allowed in
> the active area, if they are not controlled by the player.
Dialog screens are acceptable in the main area I would think. Other
than that, good idea.
> There is no place on the screen for asking the player direct
> questions in the form of a menu or prompt of any sort. There will be
> no confirmation prompts, including those that change the meanings of
> 'y' or 'n'; the player will be assumed to be aware of the choices
> made so that no confirmation is needed. (Naturally, leaving the game
> through saving, abandoning the character, or directing the PC to
> commit suicide can be exceptions to this rule, as well as any other
> time at which immersion is inevitably broken because the game is
> stopping.)
Sounds like Gearhead.
> There will be no 'more' prompt to indicate that the message area was
> too small to display the messages for everything that happened during
> the last turn. Instead, the message area will be large enough to
> accommodate any number of messages that might be needed.
Sounds like Gearhead.
> In times
> where there is a large number of messages, the message area could
> overwrite other information in the passive area or the messages could
> be made more concise by using abbreviations. It could also be that
> only one monster can attack during a turn.
Ok.
That part doesn't sound logical to me, but the rest of the ideas are
good. Unfortunately, Joe Hewitt beat you to many of them. Check out
Gearhead; it takes into account many of these suggestions and has a
pretty decent interface.
Gamer_2k4
Brendan Guild
> That part doesn't sound logical to me, but the rest of the ideas
> are good.
Do you really mean that it seems illogical, or are you saying that it
would make a poor interface? If it is not logical then it somehow
uses incorrect reasoning or even contradicts itself and I would very
much like to know how.
> Unfortunately, Joe Hewitt beat you to many of them. Check out
> Gearhead; it takes into account many of these suggestions and has a
> pretty decent interface.
It does not sound very unfortunate to me! It seems that Gearhead
turned out pretty well. Are you saying that Gearhead's interface was
good despite these ideas dragging it down?
I have never actually tried Gearhead, though I know it must be a
great game. I intend to try it sometime soon, especially now that I
have heard this.
Surely Gearhead must have menus. A roguelike without menus would be a
very radical departure from every roguelike that I have played, and
if Gearhead has menus that it doesn't seem to be following the spirit
of keeping a continuous cursor.
But I agree that for dialogue interaction with NPCs, it would be good
immersion to allow the @ to disappear and replace it with some sort
of NPC interaction UI. That is completely different from a spell or
inventory menu because the focus of the PC really has shifted to
talking; it's not an unnatural interruption.
Christophe
<snip>
> That's why it might be actually good to leave the cursor-based interface
> for the rare cases when you need the point-precise targeting. But don't
> make your designer's life easier by reusing it for everything just because
> it's so flexible.
Did you have a look at Angband targeting code? It looks like what you
say here :
- press a direction key to fire in that direction
- press * to select the closest monster around and press enter to fire.
Press * again to cycle between visible monsters
- press p ( or some other keys ) to enter the full cursor based
targeting mode
Radomir 'The Sheep' Dopieralski
Brendan Guild wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>> Why not have 3 stacks, but add a limitation that you can only put
>> smaller items on top of larger ones? Then add 3 commands to move
>> items between the stacks, and make the order of items in the first
>> stack control what is euqipped...
> I am guessing that you are saying that my idea is ridiculous, but I
> am not so sure that it can be illustrated by an even more ridiculous
> example. I think that my idea might be intuitive and manageable.
Only testing can tell the truth.
But there is another thing I don't like in the two-stack approach:
it's in fact a menu in disguise. The cursor is between the stacks.
> Suppose that we have a tall and thin message area on the left or
> right side of the screen. Messages could start at the bottom and
> scroll up as new messages accumulate, but we could also fill the top
> of that area with an inventory listing, with the most recent item at
> the bottom, so it grows downwards. It wouldn't be a menu of any sort,
> since the player cannot select from it, but it would allow the player
> to see the state of the inventory.
Z-day has it.
<snip>
> I really do think I see what you are getting at, though. You are
> saying that I am still making the internal structure of the PC too
> complicated, and probably that a stack based system is even more
> complicated than a slot based system. But I like what you have said
> about menus breaking immersion. Surely there is some simple way to
> avoid menus entirely.
There is no need -- you just want to avoid needless cursoring.
<snip>
> More importantly, if you have two healing potions, there is no need
> to ask the player which of the two should be quaffed; just pick one
> automatically. Supposing 'h' means 'heal' instead of 'left'; pressing
> 'h' could cause the PC to be healed by any means available, while
> pressing 'qh' would ask the PC to drink any healing potion available
> and 'Zh' would cast your best healing spell, if you have any.
Alternatively, just quaff all healing potions and use up all healing
items instantly the moment they are picked -- this works best if there
is no upper limit on your hp.
> Weapons could be handled in the same way, without wielding. You could
> have different keys for attacking with a dagger vs. attacking with a
> sword, assuming that there are significant rule differences between
> the two. Otherwise you could just automatically attack with the most
> powerful weapon in the inventory. Similarly, you can assume that the
> PC is wearing all of the armor in the inventory.
Or just collect weapon bonuses, increasing the power of your weapon
when you pick them up.
> You still get all the fun of collecting items, because each item
> gives you new abilities and makes killing stuff easier. All we have
> lost is inventory management and equipping.
I have an impression that something is lost, I'm afraid.
<snip>
Brendan Guild
> Only testing can tell the truth.
> But there is another thing I don't like in the two-stack approach:
> it's in fact a menu in disguise. The cursor is between the stacks.
I have come to realize that you are right about the problem of
internal complexity of the PC in the stack approach. I am less
certain that a cursor is involved, but forcing the player to
manipulate a stack is not something that I want in a roguelike.
I am quite certain that you have misunderstood the "two-stack
approach" as I suggested it, since it did not actually involve
specifically two stacks. It involved some unspecified number of
stacks, and in that case I cannot make sense of the cursor being
"between the stacks." How would the cursor be between the stacks in a
three-stack system? (Especially when it is impossible to transfer
items from one stack to another.)
I will not make an attempt to explain my stack suggestion more
clearly, since I have already decided that it was a mistake.
>> Surely there is some simple way to avoid menus entirely.
>
> There is no need -- you just want to avoid needless cursoring.
That is the point. You have explained how having cursors in addition
to @ breaks immersion, so the obvious next step is to reduce the
number of cursors as low as possible. If it is possible to have no
cursor but @, then all other cursors are needless.
> Alternatively, just quaff all healing potions and use up all
> healing items instantly the moment they are picked -- this works
> best if there is no upper limit on your hp.
[snip]
> Or just collect weapon bonuses, increasing the power of your
> weapon when you pick them up.
>
>> You still get all the fun of collecting items, because each item
>> gives you new abilities and makes killing stuff easier. All we
>> have lost is inventory management and equipping.
>
> I have an impression that something is lost, I'm afraid.
We certainly lose something if we adopt the alternatives that you
have indicated above. They are interesting simplifications, but far
too severe in my opinion, especially the weapon power bonuses.
With my way you lose the ability to choose between two different
healing potions from your inventory while quaffing in battle, the
choice would have to be made for the player automatically. You would
lose many similar things, but nothing of obvious value.
By spilling the inventory onto the floor, you can still work with
individual items, dipping, throwing away, zapping with wands and
whatever else you want to do.
While in the inventory, the items have an aggregate effect. When you
pick up an item with some amazing ability, the mere presence of that
item in your inventory gives you access to that ability through the
keyboard, without having to select the item in a menu. You know that
you have this ability thanks to that item, but you do not have to
break immersion by going to a menu to access it.
I can see bad things which are avoided, but I fail to see anything
good that we are losing.
Radomir 'The Sheep' Dopieralski
B0rsuk wrote:
I think you mean the same kind of immersion that Kornel mentions -- the
high-level, imagination-based immersion needed for role playing. There is
a number of techniques for enchancing that, but they mainly relate to so
called "content" of the game, the plot, the world depicted, the artwork
included, etc. and are different for different people.
What I meant in the original post was a kind of much simplier, low-level
immersion -- almost mechanical one. It's not very much related to the
story or character, or the beauty of the artwork.
Incidentally, sound seems to be helpful in both kinds of immersion.
Music and various background sounds are great for setting the mood,
storytelling and generally the "high" immersion, involving player's
imagination.
On the other hand, various sound effects and cues -- like differentiating
between hit or miss, indicating failure or success, etc. -- can
dramatically increase the "low" immersion.
Radomir 'The Sheep' Dopieralski
Christophe wrote:
> Radomir 'The Sheep' Dopieralski a ĂŠcrit :
Actually I always just used 'tt' and it worked fine. I never had any
reason to use something more, and I never had much will to investigate
the arcane targetting system. Just tried to stay off its way.
Radomir 'The Sheep' Dopieralski
Brendan Guild wrote:
> Radomir 'The Sheep' Dopieralski wrote:
> I am quite certain that you have misunderstood the "two-stack
> approach" as I suggested it,
You are right, I misunderstood it, I'm sorry.
<snip>
> While in the inventory, the items have an aggregate effect. When you
> pick up an item with some amazing ability, the mere presence of that
> item in your inventory gives you access to that ability through the
> keyboard, without having to select the item in a menu. You know that
> you have this ability thanks to that item, but you do not have to
> break immersion by going to a menu to access it.
This is actually interesting, and I am using quite a similar system:
You have two "inventories" -- one called "equipment" and one called
"treasure".
All the items from equipemnt can be thought of as worn by or strapped on
the player character, or kept in a pocket or even carried in a hand. There
is no exact description, as it's irrelevant in the game. The equipment has
a hard limit on the number of items you can carry, and also some kind of
items will conflict with others -- for example you can have only one
armor.
The "treasure" items are, on the other hand, carried in a large treasure
bag on the player character's back or even dragged behind the character.
There is no hard limit on the bag's size, only some penalties. You can
easily drop the whole bag at any time, however, getting rid of the
penalties.
You can only use the items from your equipment. In fact, most of them will
be active automatically when "worn", only things like potions or wands
require activation. Picking up and dropping things to/from your equipment
doesn't take time. Putting objects into the bag or removing them takes
a turn for every item, however.
I'm not yet sure about the impact this system has on the gameplay, but it
feels pretty nice in play -- it mirrors my categorisation of items in
inventory. I will be probably able to tell more once I have working
combat.
Jeff Lait
> > Well, maybe it's an idea for a 7DRL though : bumprogue, kill your
> > opponents by bumping into them to death. You'll play an overweight human
> > for that a collect foods to increase your weight and your damage
> > potential. But the longer you stay in the dungeon, the more your weight
> > will decrease :)
>
> Good call. The 7DRL Challenge SHOULD be coming up soon (I keep
> mentioning it and no one says anything), and it might be interesting to
> see.
The 7DRL Challenge is coming up. As per tradition, I will be making
the Call For Dates on January 24th.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Jeff Lait
> "David Damerell" <dame...@chiark.greenend.org.uk> wrote in message
> news:hpB*wD...@news.chiark.greenend.org.uk...
> > Quoting Nolithius <Noli...@earthlink.net>:
> > >Seriously, though, you're creating a game which "optimizes" your
> selection
> > >of spells, usable items, weapons, etc., which nerfs the decision-making.
> >
> > Rubbish. Having a "use most powerful healing item" key doesn't obviate the
> > decision to use the most powerful item. Automatically attacking with the
> > most powerful weapon - either the player had the weapon stats and you're
> > just saving them comparing two numbers, or they didn't and you wanted them
> > to play guessing games, which isn't any kind of decision making.
> >
> > >Making the choice of how to heal yourself, for example, is a LARGE part
> of
> > >the challenge in complex games like RLs.
> >
> > And in severe danger, the choice will be "maximum effect". Pressing the
> > key that does that is making the choice whether or not you are required to
> > do the book-keeping of looking through your inventory.
>
By that thought, I guess Letter Hunt has some naive game design in it.
For one, you always pick up items any items dropped by enemies, thus
ensuring items are never on the floor. You also always use your most
powerful attacks. If you get a regeneration ring, it is immediately
equipped and starts being consumed right away (it has a time out
effect), as does invulnerability.
> Healing: You misunderstood the previous poster, he did not suggest a "use
> the most powerful healing item" key, but rather "heal in the most powerful
> way you can" even as a default key-- with another set of keypresses to make
> the choice. This choice is of moderate to high consequence, and you do not
> want to trivialize how it is chosen, as you then either remove the choice,
> or worse, produce undesired situations for the player. The obvious scenario
> to point out is if your most powerful healing source is a spell that costs
> all your remaining mana, when in fact you were saving that mana for an
> offensive spell next turn. Here you have two choices, both moderate-to-high:
> healing, and offensive spellcasting. In this scenario you severely hamper
> the choice availability, when in fact you'd want to increase it.
*IF* you want to increase choice, you have a point. I do not take it
as a given that which healing spell to cast should be such a choice.
> Granted, if you choose to have obvious choices in your game-- then might as
> well implement a key that 'makes the obvious choice'. The idea is to do away
> with obvious choices (see my previous post).
This seems to go full circle.
If we have an obvious choice and we make a key that makes the obvious
choice, you argued this is bad because we then have no choice. But, if
we have no choice, we thus have no obvious choice, so we have removed
the obvious choice by binding it to a single key.
I think, in summary, we both agree that obvious choices aren't good.
However, I would say there are two answers to deal with an obvious
choice in a game. First, we can remove the thing entirely, as you
advocate. Instead of having Healing 1, 2, and 3 spells, we just have a
Healing spell that becomes stronger as the character does. The second,
however, is to leave the Healing 1, 2, and 3 spells intact but instead
have the Heal option always pick the most powerful spell. The net
gameplay of the two options is the same. However, I would argue that
the feeling of the game is very different. It is a lot easier to make
the Healing 1, 2, 3 solution something that seems more varied on the
surface. Minor healing may be granted at low level, Healing be the
result of a quest, and Major Healing a special ability a chosen few can
aspire to. Contrast to the "normalized" version that turns that aspect
of the game into another spreadsheet.
> Weapon selection: on the same vein, sometimes you pickup an unarguably
> superior weapon to yours, and of the same type in which you are skilled, to
> boot. Some games will autoequip the better weapon on pickup. Note that this
> is OK: since the choice is trivial, the game removes the need for you to
> make it by doing for you.
Thinking of Unreal Tournament 2004, a game I play which does this sort
of auto-equip, I'll point out that it does let you set up a "weapon
priority" in your game settings to trigger whether one weapon displaces
the other. Note that weapon choice isn't even that trivial in UT:2004.
Arthur J. O'Dwyer
On Thu, 11 Jan 2007, Radomir 'The Sheep' Dopieralski wrote:
> B0rsuk wrote:
>> Right now I don't have time to read the whole thread, but I believe no
>> one mentioned SOUND before. Good sound is very good for immersion. I
>> like it a lot in DoomRL.
>
> I think you mean the same kind of immersion that Kornel mentions -- the
> high-level, imagination-based immersion needed for role playing. There is
> a number of techniques for enchancing that, but they mainly relate to so
> called "content" of the game, the plot, the world depicted, the artwork
> included, etc. and are different for different people.
>
> What I meant in the original post was a kind of much simplier, low-level
> immersion -- almost mechanical one. It's not very much related to the
> story or character, or the beauty of the artwork.
Interesting. FWIW, my opinion is that the two are very much related;
I can't "believe in" a detailed game world unless it makes me forget I'm
wasting time in front of a computer :) (low-level immersion), and
symmetrically, the better the game atmosphere (high-level immersion)
is, the more likely I am to get sucked into it (resulting in low-level
immersion).
I do agree that the music in DoomRL makes it a better game, at least
for people who recognize the music from the original Doom game. Having
that subconscious mental link to Doom helps the player visualize an
'i' as an Imp, and not, you know, an asterisk-spitting wizard or
something. But as Sheep says, it's not intimately related to the kind
of immersion I'm thinking of, either.
> Incidentally, sound seems to be helpful in both kinds of immersion.
> Music and various background sounds are great for setting the mood,
> storytelling and generally the "high" immersion, involving player's
> imagination.
Yep. That's basically what I tried to say above. (But adding that
I think high-level immersion feeds back into low-level immersion, too.)
> On the other hand, various sound effects and cues -- like differentiating
> between hit or miss, indicating failure or success, etc. -- can
> dramatically increase the "low" immersion.
...Unless the exact same sound effect repeats over and over, in such
a way that the player gets annoyed by it and thinks, "Boy, this
computer/programmer/game is being stupid!" Then you've lost him.
-Arthur
Nolithius
"Jeff Lait" <torespon...@hotmail.com> wrote in message
news:1168528264.4...@o58g2000hsb.googlegroups.com...
My apologies, my comment was much too ambiguous. What I was trying to say
was that thinking that one particular solution applies to all games is a
naive approach to game design. Different games require a different set of
choices.
> > Healing: You misunderstood the previous poster, he did not suggest a
"use
> > the most powerful healing item" key, but rather "heal in the most
powerful
> > way you can" even as a default key-- with another set of keypresses to
make
> > the choice. This choice is of moderate to high consequence, and you do
not
> > want to trivialize how it is chosen, as you then either remove the
choice,
> > or worse, produce undesired situations for the player. The obvious
scenario
> > to point out is if your most powerful healing source is a spell that
costs
> > all your remaining mana, when in fact you were saving that mana for an
> > offensive spell next turn. Here you have two choices, both
moderate-to-high:
> > healing, and offensive spellcasting. In this scenario you severely
hamper
> > the choice availability, when in fact you'd want to increase it.
>
> *IF* you want to increase choice, you have a point. I do not take it
> as a given that which healing spell to cast should be such a choice.
To my understanding, the first one to come up with the One Key To [H]eal
Them All suggested that it would use the best healing available from
potions/scrolls/spells, etc. While this is not necessarily game-breaking if
you consciously design the game to accomodate this feature, it's a clear hit
to most full-fledged RLs where managing your items/mana is part of the
challenge.
> > Granted, if you choose to have obvious choices in your game-- then might
as
> > well implement a key that 'makes the obvious choice'. The idea is to do
away
> > with obvious choices (see my previous post).
>
> This seems to go full circle.
>
> If we have an obvious choice and we make a key that makes the obvious
> choice, you argued this is bad because we then have no choice. But, if
> we have no choice, we thus have no obvious choice, so we have removed
> the obvious choice by binding it to a single key.
Rather, what I mean is to NOT have obvious choices in your game (because
then they're arguably not even choices). If you ABSOLUTELY want to have an
obvious choice, then binding it to a key really doesn't make it any worse.
> I think, in summary, we both agree that obvious choices aren't good.
> However, I would say there are two answers to deal with an obvious
> choice in a game. First, we can remove the thing entirely, as you
> advocate. Instead of having Healing 1, 2, and 3 spells, we just have a
> Healing spell that becomes stronger as the character does. The second,
> however, is to leave the Healing 1, 2, and 3 spells intact but instead
> have the Heal option always pick the most powerful spell. The net
> gameplay of the two options is the same. However, I would argue that
> the feeling of the game is very different. It is a lot easier to make
> the Healing 1, 2, 3 solution something that seems more varied on the
> surface. Minor healing may be granted at low level, Healing be the
> result of a quest, and Major Healing a special ability a chosen few can
> aspire to. Contrast to the "normalized" version that turns that aspect
> of the game into another spreadsheet.
I entirely agree with this approach. You can either remove Healing 1 & 2, or
you can leave them in but have the default 'Cast healing' spell action
trigger 3, as long as there's still a way to access 1 & 2. In most games
with different healing spells you'll notice that 95% of the time you'll be
using the most powerful one anyway.
> > Weapon selection: on the same vein, sometimes you pickup an unarguably
> > superior weapon to yours, and of the same type in which you are skilled,
to
> > boot. Some games will autoequip the better weapon on pickup. Note that
this
> > is OK: since the choice is trivial, the game removes the need for you to
> > make it by doing for you.
>
> Thinking of Unreal Tournament 2004, a game I play which does this sort
> of auto-equip, I'll point out that it does let you set up a "weapon
> priority" in your game settings to trigger whether one weapon displaces
> the other. Note that weapon choice isn't even that trivial in UT:2004.
As I said earlier, no one design applies accross the board (specially
accross genres!). In UT this works because: a) there is a small number of
weapons b) the weapons are easily identified from far away so once you step
onto them that's enough of a pickup/autoequip command (compare to RLs where,
save for [L]ooking, items are described once you've stepped on them, and
often unidentified until after you've picked it up and cast a spell on them)
c) The weapons are placed (usually) in places where you must consciously
walk over them and can avoid them (unlike RLs).
In addition, note that while weapon choice is not trivial in UT (original,
it's the only one I've played), the game will *not* switch you to an
inferior weapon on pickup if the weapon is obviously inferior to your
current one; so while weapon choice as a whole isn't trivial, there are
certain obvious choices (which, I should point out, are the ones which cause
autopickup/autoequip, to remove having to make the obvious choice ;)
Non-obvious choices also cause this behavior since, as discussed above,
walking over a weapon is enough of a command in that particular game for
autoequip.
Really the bottom line is: do what works for your game :) Ultimately game
design is not about doing away with menus or making some complicated AI to
select your weapon for you, it's about creating a fun and immersive
experience. The main reason I jumped in to this thread was to point out how
certain design choices proposed were taking away from this ultimate goal :)
--Nolithius
Radomir 'The Sheep' Dopieralski
Arthur J. O'Dwyer wrote:
I'd have to see (hear) the examples, but I don't really think it's the
repetetiveness (spell?) of the sound that is the culprit here -- the sound
*has* to be repeated to establish its "meaning" -- Windows' sounds are a
good example here. It's likely however, that the sound is badly chosen,
too long, annoying or too specific to be used as a general cue -- then it
gets irritating, indeed.
Ray Dillinger
> I have difficulties seeing your problem here. What do you want to do with
> that poor door? There are only 1 action you can do on a closed door : open
> it. Well, you could bash it or something but it would be somewhat retarded
> most of the time : who would bash an unlocked door?
Um, spike it shut or barricade it, lock it if you
have the key, set it on fire or pour acid on the
hinges if you can't otherwise get it open, try
to peek through the keyhole, stop and listen to
see if you can hear something breathing on the
other side....
If opening is the only action your game implements,
then it's the only thing you'd want to do. But if
there's a variety of actions suitable to doors, I
think a player selection is more appropriate than
a (possibly accidental) auto-open.
Bear
Ray Dillinger
> Arthur J. O'Dwyer wrote:
>
>>>Why do you target a monster with a wand of stone to mud?
>>Don't play stupid. That's no fun for anyone.
> No, really, apologies, but I mean it. There are offensive items, and there
> are hm... utility items. You usually don't mix them.
Um. Stone Golems. Gargoyles. Stone Giants. Rockworms.
Earth Elementals. Crystal Wolves. ....
Your rock-to-mud wand is an effective weapon, if you've
the wits to use it when it's needed. And little leaps
of logic like this are important parts of most roguelike
games.
Bear
Ray Dillinger
> Quoting Nolithius <Noli...@earthlink.net>:
>
>>Seriously, though, you're creating a game which "optimizes" your selection
>>of spells, usable items, weapons, etc., which nerfs the decision-making.
>
>
> Rubbish. Having a "use most powerful healing item" key doesn't obviate the
> decision to use the most powerful item. Automatically attacking with the
> most powerful weapon - either the player had the weapon stats and you're
> just saving them comparing two numbers, or they didn't and you wanted them
> to play guessing games, which isn't any kind of decision making.
Nope. The weapon has to fit the opponents. Aside from
issues like resistances and so on, which *do* matter in
most games (jellies take double damage from blunt instruments,
skeletons take half damage from blade arms, etc) the damage
distribution has to be considered against the opponent's
effective hitpoints. A weapon that does 2d20 damage
(averaging 21) is less effective than a weapon that does
6d4 (averaging 13) when you're fighting something that
has ten hitpoints on average, because most of that damage
is wasted in overkill and the 6d4 weapon actually gets over
10 more often. But if you're fighting something that has a
hundred hitpoints on average, the weapon that does 2d20 is
the better weapon.
Now, if you want to automate all of it and come up with
"most effective weapon against current opponent" I suppose
you can. But I think weapon selection ought to be a point
of interest in the game.
>>Making the choice of how to heal yourself, for example, is a LARGE part of
>>the challenge in complex games like RLs.
> And in severe danger, the choice will be "maximum effect". Pressing the
> key that does that is making the choice whether or not you are required to
> do the book-keeping of looking through your inventory.
MmmHmmm. "Maximum effect" has different meanings too. If
If you need healing *RIGHT NOW* you might pick something
that does less healing, but does it fast, even if your
"Maximum effect" heal would do more absolute healing -
but would do it over the next ten rounds.
I think you can make automatically only such choices as are
very simple in the first place. And if these choices are so
simple as that, IMO it's a sign that you need more interesting
choices and tradeoffs.
Bear
R. Dan Henry
<andre...@hotmail.com> wrote:
>[1] Which asks the question why Angband doesn't have an auto-close function?
Because Angband PCs were raised in a barn.
--
R. Dan Henry = danh...@inreach.com
If you wish to put anything I post on your website,
please be polite enough to ask first.
R. Dan Henry
<ne...@sheep.art.pl> wrote:
>== Immersion in roguelikes ==
For immersion in roguelikes, you need one thing:
An Amulet of Water-Breathing.
Gamer_2k4
> > are good.
>
> Do you really mean that it seems illogical, or are you saying that it
> would make a poor interface? If it is not logical then it somehow
> uses incorrect reasoning or even contradicts itself and I would very
> much like to know how.
Poor wording on my part. I meant it wouldn't make sense as an
interface (not for a roguelike; for a typing tutor game it would be
fine).
> > Unfortunately, Joe Hewitt beat you to many of them. Check out
> > Gearhead; it takes into account many of these suggestions and has a
> > pretty decent interface.
>
> It does not sound very unfortunate to me! It seems that Gearhead
> turned out pretty well. Are you saying that Gearhead's interface was
> good despite these ideas dragging it down?
Unfortunate for the novelty of your ideas. They're good ideas, but
you're not the first to think of them. That's all I was saying.
> I have never actually tried Gearhead, though I know it must be a
> great game. I intend to try it sometime soon, especially now that I
> have heard this.
>
> Surely Gearhead must have menus. A roguelike without menus would be a
> very radical departure from every roguelike that I have played, and
> if Gearhead has menus that it doesn't seem to be following the spirit
> of keeping a continuous cursor.
The Gearhead screen looks like this:
+------------+----+
| | B |
| | |
| +----+
| A | |
| | |
| | C |
| | |
+------------+ |
| D | |
+------------+----+
A is the main display area. The only times when the map isn't
displayed are when you are in a dialog screen (which makes sense), when
you are looking through the inventory (which isn't too bad), when you
are checking previous messages (for size reasons), and when you are
looking at the character screen (also for size reasons).
B is the status area. It shows the armor and general health of each
body part of you and your target, as well as total hitpoints, total
stamina, attributes, modifiers (poisoned, hungry, etc.), and facing.
C is the secondary menu area. This is used for less important menus,
like skills, mecha commands, and combat options.
D is the 5 line message area.
> But I agree that for dialogue interaction with NPCs, it would be good
> immersion to allow the @ to disappear and replace it with some sort
> of NPC interaction UI. That is completely different from a spell or
> inventory menu because the focus of the PC really has shifted to
> talking; it's not an unnatural interruption.
Yes. That's one of the things that makes Gearhead unique: actual
interaction with NPCs.
Gamer_2k4
Simon Richard Clarkstone
> it /does/ take time and thought to open a door. You have to consider
> whether you want to open it at all, for one thing --- maybe there's
> something bad on the other side! Then you have to put your hand on
> the knob and turn it, and so on. (Unless you're playing a giant who
> reflexively smashes doors down instead of opening them, in which case
> auto-open would be the Right Thing. Auto-open would also be close to
> right in a Star Trek setting.)
Hmm. I have freaked myself out several time by locking (toilet) doors
without even noticing I have done it, thinking I haven't, the finding I
have. OTOH, in a dungeon, the opening of each door would come with
apprehension as to what was on the other side.
-----
More usefully, someone could take an existing game and add a feature
that logs every command and the keystrokes needed to perform it. After
some play testing with someone who is familiar with the game already,
you would get some useful (and possibly surprising) information about
which parts of your interface use up all the time.
--
Simon Richard Clarkstone: s.r.cl?rkst?n?@durham.ac.uk/s?m?n.cl?rkst?n?@
hotmail.com ### "I have a spelling chequer / it came with my PC /
it plainly marks for my revue / Mistake's I cannot sea" ...
by: John Brophy (at: http://www.cfwf.ca/farmj/fjjun96/)
Simon Richard Clarkstone
> This is actually interesting, and I am using quite a similar system:
>
> You have two "inventories" -- one called "equipment" and one called
> "treasure".
>
> All the items from equipemnt can be thought of as worn by or strapped on
> the player character, or kept in a pocket or even carried in a hand. There
> is no exact description, as it's irrelevant in the game. The equipment has
> a hard limit on the number of items you can carry, and also some kind of
> items will conflict with others -- for example you can have only one
> armor.
>
> The "treasure" items are, on the other hand, carried in a large treasure
> bag on the player character's back or even dragged behind the character.
> There is no hard limit on the bag's size, only some penalties. You can
> easily drop the whole bag at any time, however, getting rid of the
> penalties.
>
> You can only use the items from your equipment. In fact, most of them will
> be active automatically when "worn", only things like potions or wands
> require activation. Picking up and dropping things to/from your equipment
> doesn't take time. Putting objects into the bag or removing them takes
> a turn for every item, however.
>
> I'm not yet sure about the impact this system has on the gameplay, but it
> feels pretty nice in play -- it mirrors my categorisation of items in
> inventory. I will be probably able to tell more once I have working
> combat.
I think this is a good idea. I was also going to suggest separating the
stuff you have immediately accessible from the stuff that is less so.
If you could have multiple bags, then it might (just maybe) be worth
having a "proper" system of classifying stuff in it, e.g. allowing the
user to create labled categories. The gamble is that typically
characters alternate between wandering around fighting, and sorting
through and managing their stuff. One can argue from realism that when
the character is managing their stuff (e.g. after having cleared a
level) they would not be paying much attention to the dungeon layout but
instead to what they have stored where, so we replace the player's view
of the dungeon with an inventory-management screen that allows them to
move things between their bag(s) and/or their equipment.
Interface idea: the player can select a bag (or the floor or their worn
equipment) to go on the LHS of the main screen and one to go on the RHS
of the main screen, then move stuff between the two, being able to
scroll the lists independently. This would beat all the faffing about I
have to do when carrying lots of stuff in Nethack, or moving 120 items
from one bag to another, or trying on every single piece of armour I
have scavenged from the gnomish mines, or looking for something useful
from the pile of dead soldiers in Ludios, or whatever.
And of course, you would always be able to fit the main inventory all on
screen at once, so we get less interruption to on-map play, but keep the
equipment dilemmas with a nicer interface.
I just suggested the mother of all menus; I'm going to get lynched.
R. Alan Monroe
>At 7 Jan 2007 18:30:17 -0800,
> Mario Donick wrote:
>
>I love to see your experiments. They certainly bring somethng fresh,
>even when they don't seem particulary efficient :)
>
>Have you considered something like this?
>
> #.# #.#
> #.# #.#
> ########|Wield: |####
> #.......|a ) short sword (+1 +1)|....
> #...@...|b ) pick axe |####
> #.......|c ) small dagger x4 |
> ###\####|d } short bow (+0 +2) |
> #.# |e / arrow x30 |
> #.# #.#...#............#
> #.# #.#####............#
> #.# #.....+......<.....#
> #.# #######............#
> #.# ##############
>
Note the lefthand side of this picture:
http://javajack.dynalias.net/RL/RLinterface.gif
Drawn in 2002 :)
Alan
Radomir 'The Sheep' Dopieralski
R. Alan Monroe wrote:
> In article <slrneq3er...@atos.wmid.amu.edu.pl>, ne...@sheep.art.pl wrote:
>>At 7 Jan 2007 18:30:17 -0800,
>> Mario Donick wrote:
>>I love to see your experiments. They certainly bring somethng fresh,
>>even when they don't seem particulary efficient :)
>>Have you considered something like this?
<snip>
> Note the lefthand side of this picture:
> http://javajack.dynalias.net/RL/RLinterface.gif
> Drawn in 2002 :)
What about it?
Can you say what do you mean?
--
Radomir `The Sheep' Dopieralski
Never attribute to malice what can be adequately
explained by ignorance or stupidity.
R. Alan Monroe
>At Wed, 14 Feb 2007 02:17:08 GMT,
> R. Alan Monroe wrote:
>
>> In article <slrneq3er...@atos.wmid.amu.edu.pl>, ne...@sheep.art.pl
> wrote:
>>>At 7 Jan 2007 18:30:17 -0800,
>>> Mario Donick wrote:
>
>>>I love to see your experiments. They certainly bring somethng fresh,
>>>even when they don't seem particulary efficient :)
>
>>>Have you considered something like this?
><snip>
>
>> Note the lefthand side of this picture:
>> http://javajack.dynalias.net/RL/RLinterface.gif
>> Drawn in 2002 :)
>
>What about it?
>
>Can you say what do you mean?
>
The ascii art example upthread showed that using the wield command
would show you a subset of your inventory that was appropriate for
wielding... My picture showed the same concept from a few years back.
Except that rather than listing a subset of items, it highlighted, and
drew lines to, the subset of appropriate items, in the context of the
full inventory. Basically I was agreeing and showing that history
repeats itself :)
Alan
Radomir 'The Sheep' Dopieralski
R. Alan Monroe wrote:
> In article <slrnet57l...@atos.wmid.amu.edu.pl>,
> ne...@sheep.art.pl wrote:
>>At Wed, 14 Feb 2007 02:17:08 GMT,
>> R. Alan Monroe wrote:
>>> In article <slrneq3er...@atos.wmid.amu.edu.pl>,
>>> ne...@sheep.art.pl wrote:
>>> Note the lefthand side of this picture:
>>> http://javajack.dynalias.net/RL/RLinterface.gif
>>> Drawn in 2002 :)
>>What about it?
>>Can you say what do you mean?
> The ascii art example upthread showed that using the wield command
> would show you a subset of your inventory that was appropriate for
> wielding... My picture showed the same concept from a few years back.
> Except that rather than listing a subset of items, it highlighted, and
> drew lines to, the subset of appropriate items, in the context of the
> full inventory. Basically I was agreeing and showing that history
> repeats itself :)
Well, isn't it exactly what Rogue and
Nethack and Moria did too? :)