Roguelike Interface
Gamer_2k4
should show all relevant information, and no unnecessary information;
this information should be easily accessible. Examples of good
interfaces include the two line message display in ADOM, the combat
icons (*, -, /, etc.) in Gearhead, and the monster HP display in the
sidebar in some Angband variants.
When the player is just moving around, what should be displayed? Is it
really important for the player to know each of his attributes at all
times? Probably not. It's probably only necessary to determine status
conditions, like "hungry" and "bleeding", speed, maybe a list of
visible items or creatures. Angband variants do the last two features
very well. Also, if sounds are heard, an '!' icon should display,
adjacent to the player and in the direction of the noise. Perhaps
color could indicate distance or type of sound. for example, in ADOM,
"you hear the wind howling" would display a dark grey '!' in the
direction of the forge.
During combat, there are several things the player wants to know.
These include monster HP, player HP, player MP, player resistances,
attack results, status effects, and so on. It's also a good idea to
alert the player if his equipment breaks, or if he scores a critical
hit, or some similar event that changes his combat ability. Ideally,
the information will not need to be displayed as a message, so that the
player doesn't have to check the top of the screen after each attack.
An attack would display a '*' on the target, with the color indicating
damage. Light grey might be a normal hit, dark grey could be a harder
hit, dark red could be a critical hit, and so on. Spells and arrows
should always be displayed "graphically", assuming the player would be
able to see them.
Well...what else is there? Roguelikes are about movement and combat.
I think that's it for display, except for one thing. Earlier I
advocated that only certain pieces of information should be shown at
certain times. However, there should definitely be commands to view
all the information. Obviously the player will want to know his
Strength or Dexterity at some time, even if he never directly needs
that information. So it's a good choice to have a character screen
that gives all that information.
Interface also refers to input, so here are a few ideas for that.
There should be a generic command to interact with the environment, and
another generic command to equip items. Unless you're making the next
Nethack, there's no need for a different commands for wear and wield.
There should also be a generic command to use an item, like drinking a
potion or reading a scroll. Better yet, why not have all such commands
dealt with from the inventory screen? 'I' might bring up the inventory
screen, which would have a list of items and a bottom row something
like this:
[M] More information [U] Use/wear [D] Drop Filter:
[]{}()/\+=!?~"
You would just select the item you want with the arrow keys, and use
the commands when the desired item is selected. Of course, this would
get tedious searching for items, so it would be good to have a filter
option like in ADOM.
There should definitely be a macro system of some sort to handle
tedious commands, or at least a way to map certain spells or attacks to
the function keys. Also, why should there be a difference in combat
techniques, abilities, and magic? Maybe you've learned the Cross-slash
technique and the Fire Bolt spell, and you can intrinsically use Stone
Skin. Why should you need different keys to access them? Maybe use
'a' for ability, then just select one.
Basically, input should use as few commands as necessary, and the
player should have to read as few messages as necessary. This keeps
the display open, and the interface uncluttered in general. I think
roguelikes would benefit from an effective interface; maybe we'll see
some new roguelike that uses these ideas or even new ones.
Gamer_2k4
Icey
because the interface works differently to other roguelikes:
http://iceyboard.no-ip.org/images/paprika/interface.gif
The interface is MDI (multiple document interface). This means there is
a set of child windows which are contained inside one parent window.
All child windows can be moved, resized, maximized, minimized and
restored. Some windows like the map don't need to be shown at all. The
only two that are needed are the log window and the dungeon window,
when a game is in progress.
The player can make any layout they like, which is saved and restored
for when they play the next time.
The interface modes are graphical and text. The mode can be switched at
any time, even during a game. The tiles and text size can be made
bigger and smaller. For example, here's the same scene above, after
I've switched the mode:
http://iceyboard.no-ip.org/images/paprika/interface-text.gif
The colours and symbols used can be changed by editing a simple data
file.
There are other windows available, like high scores, bestiary, journal
and so on. The player can open these at any time and have them usable
while a game is in progress.
The contents of the status window can be changed by clicking on it.
Information can be added and removed very easily:
http://iceyboard.no-ip.org/images/paprika/interface-status.gif
Creatures show health bars so the player can easily determine how
damaged they are. Hostile creatures (like the black ant) have green
health bars and friendly creatures (like the pet baby dinosaur) have
blue health bars. The health of the player is shown in the status
window. It turns to red if it gets below 25%.
The player can examine things by left-clicking on them. Ranged weapons
are used by right-clicking on the target. Actions are performed on
inventory items by right-clicking them and using the menu. The first
screenshot shows an example of that.
The interface is operated by mouse and keyboard, both must be used.
Keyboard actions can be performed by pressing letters (g to get an
item, t to travel using stairs or a path, c to close a door, etc) or by
using the actions menu. The actions menu is there to help new players
who might not be familiar with the letters.
The log window displays different types of messages in different
colours. For example, messages related to combat are in red and
messages related to items are in blue. I think this helps to
differentiate between messages and is easy to see than messages that
fade to grey.
I think that's about everything I can say about the interface. I know
that a lot of people wont like it, because it's MDI and requires the
mouse, but I feel there are many advantages to those things and there's
no point in every roguelike being the same. Paprika is still in early
stages, so things will be improved and things will be changed
dramatically over time.
I hope my rambling is useful to you :)
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
This is a very broad domain of knowledge, and I can see you are bravely
stepping in unarmed. This is bold, yet doomed. Please try to arm yourself
with some knowledge of the human perception, it can save your life.
> Many roguelikes have, IMO, a clunky interface.
Agreed, especially the recent, "modern" ones.
> Ideally, the screen
> should show all relevant information, and no unnecessary information;
Untrue. No matter how much information you do display, the human being
in front of the screen will only see a small part of it. Sure, it can
switch the focus and change the parts it sees, but focus switching is
one of the most inefficient and costly operations a human being does --
it can take even up to several seconds! No kidding, you don't "feel"
this time as you are busy context-switching, but have a friend
measure it for you.
> this information should be easily accessible.
Care to explain what this sentence means? :)
> Examples of good
> interfaces include the two line message display in ADOM, the combat
> icons (*, -, /, etc.) in Gearhead, and the monster HP display in the
> sidebar in some Angband variants.
You can't talk about user interface solutions in separation from all of
the actual interface.
> When the player is just moving around, what should be displayed? Is it
> really important for the player to know each of his attributes at all
> times? Probably not. It's probably only necessary to determine status
> conditions, like "hungry" and "bleeding", speed, maybe a list of
> visible items or creatures.
The human in front of the screen doesn't see the stats and other
unnecessary things displayed on the screen when he's (yes, he, not
his avatar, as psychologically it's the player that's walking around)
moving about the dungeon. Even if it sees them, it doesn't comprehend
them. So they add no effort to interpreting the screen.
On the other hand, when they are displayed consitently all the time,
preferably in a form that can be easily grasped (i.e. bars and colors
rather than just numbers), the human being in front of screen can
develop a reflex to "recognize" states just as it recognizes faces
of its friends -- without really seeing all the details.
> Angband variants do the last two features
> very well.
Depends on the actual variant, I guess.
> Also, if sounds are heard, an '!' icon should display,
> adjacent to the player and in the direction of the noise. Perhaps
> color could indicate distance or type of sound. for example, in ADOM,
> "you hear the wind howling" would display a dark grey '!' in the
> direction of the forge.
Woudn't that obscure the most important part of the dungeon -- the
immediate visinity of the avatar?
> During combat, there are several things the player wants to know.
> These include monster HP, player HP, player MP, player resistances,
> attack results, status effects, and so on.
That again depends on the kind of the combat. I certainly don't
care about monster's hit points when I'm "running over" a pack
of rats.
> It's also a good idea to
> alert the player if his equipment breaks, or if he scores a critical
> hit, or some similar event that changes his combat ability.
It's pretty pointless to do so -- the human being in front of screen
will not remember that, unless it was deliberately focusing on that
information (and it doesn;t like to switch its focus).
> Ideally,
> the information will not need to be displayed as a message, so that the
> player doesn't have to check the top of the screen after each attack.
> An attack would display a '*' on the target, with the color indicating
> damage. Light grey might be a normal hit, dark grey could be a harder
> hit, dark red could be a critical hit, and so on.
What about monochrome displays?
> Spells and arrows
> should always be displayed "graphically", assuming the player would be
> able to see them.
Why?
> Well...what else is there? Roguelikes are about movement and combat.
I think they are a little bit richier than that. For example, resource
management seems to play an important part.
> I think that's it for display, except for one thing. Earlier I
> advocated that only certain pieces of information should be shown at
> certain times. However, there should definitely be commands to view
> all the information. Obviously the player will want to know his
> Strength or Dexterity at some time, even if he never directly needs
> that information. So it's a good choice to have a character screen
> that gives all that information.
Beware of information overload. Sure, displaying all relevant stats
together, in a way that makes them easy to compare is very good. But
Displaying *all* available information together only makes all the parts
compete for the human being's attention.
> Interface also refers to input, so here are a few ideas for that.
> There should be a generic command to interact with the environment, and
> another generic command to equip items.
Why?
> Unless you're making the next
> Nethack, there's no need for a different commands for wear and wield.
Why?
> There should also be a generic command to use an item, like drinking a
> potion or reading a scroll. Better yet, why not have all such commands
> dealt with from the inventory screen? 'I' might bring up the inventory
> screen, which would have a list of items and a bottom row something
> like this:
>
> [M] More information [U] Use/wear [D] Drop Filter:
> []{}()/\+=!?~"
> You would just select the item you want with the arrow keys,
This is awkward and makes habituation, that all human beings develop,
and enemy rather than a friend.
> and use
> the commands when the desired item is selected. Of course, this would
> get tedious searching for items, so it would be good to have a filter
> option like in ADOM.
... you could further improve the interface and reduce the number of
keypresses needed (not to mention removing a mode), by providing
shortcuts for commands with the filters already enabled, like 'wear'
or 'wield' or... wait, you just dismissed it :D
> There should definitely be a macro system of some sort to handle
> tedious commands, or at least a way to map certain spells or attacks to
> the function keys.
Yes, that will easily prevent improving the bad parts of interface and
gameplay by just patcheing them with macros. Why take the responsibility
for the user interface when you can shift it on the human being in front
of the screen?
> Also, why should there be a difference in combat
> techniques, abilities, and magic? Maybe you've learned the Cross-slash
> technique and the Fire Bolt spell, and you can intrinsically use Stone
> Skin. Why should you need different keys to access them? Maybe use
> 'a' for ability, then just select one.
I say why do westop here? Let's have the game operated with one "do what
I mean" key.
> Basically, input should use as few commands as necessary, and the
> player should have to read as few messages as necessary. This keeps
> the display open, and the interface uncluttered in general. I think
> roguelikes would benefit from an effective interface; maybe we'll see
> some new roguelike that uses these ideas or even new ones.
You see, game interface is even harder to research than other
application's user interface -- that's because the interface is part
of the game.
One can argue that, for example, Arkanoid has terible user interface --
the motion of the palette can be easily automated, relieving the player.
But where's the game then?
--
Radomir `The Sheep' Dopieralski
"When in doubt, use brute force." [Ken Thompson]
Radomir 'The Sheep' Dopieralski
Icey wrote:
> The interface is MDI (multiple document interface). This means there is
> a set of child windows which are contained inside one parent window.
> All child windows can be moved, resized, maximized, minimized and
> restored. Some windows like the map don't need to be shown at all. The
> only two that are needed are the log window and the dungeon window,
> when a game is in progress.
Don't you think that using 'panels', like the modern IDEs do, would be
better? Or at least let the windows to be 'docked'?
> The player can make any layout they like, which is saved and restored
> for when they play the next time.
Isn't that just dodging the responsibility for making a good layout
yourself? How do you know that it's possible to make a usable layout
at all with the building block you provide?
Icey
> At 10 Nov 2006 17:54:27 -0800,
> Icey wrote:
>
> > The interface is MDI (multiple document interface). This means there is
> > a set of child windows which are contained inside one parent window.
> > All child windows can be moved, resized, maximized, minimized and
> > restored. Some windows like the map don't need to be shown at all. The
> > only two that are needed are the log window and the dungeon window,
> > when a game is in progress.
>
> Don't you think that using 'panels', like the modern IDEs do, would be
> better? Or at least let the windows to be 'docked'?
Aye, that would be nice. However, I'm using Visual Basic 6 and I want
to keep dependencies to a minimum (none at the moment), so I don't
really want to be adding in additional components.
I will look into that though, thank you for the suggestion.
> > The player can make any layout they like, which is saved and restored
> > for when they play the next time.
>
> Isn't that just dodging the responsibility for making a good layout
> yourself?
What I consider a good layout may be different to what other people
consider a good layout. For example, I may want a large dungeon view,
not show the minimap, have a long inventory and lots of status
information. Other people may prefer the opposite. My layout system is
designed to handle any situation.
>How do you know that it's possible to make a usable layout
> at all with the building block you provide?
The current system is very flexible, so it's definitely possible to
create a usable layout.
Gamer_2k4
> > should show all relevant information, and no unnecessary information;
>
> Untrue. No matter how much information you do display, the human being
> in front of the screen will only see a small part of it. Sure, it can
> switch the focus and change the parts it sees, but focus switching is
> one of the most inefficient and costly operations a human being does --
> it can take even up to several seconds! No kidding, you don't "feel"
> this time as you are busy context-switching, but have a friend
> measure it for you.
I understand that. You'll notice that I later advocate that
information be displayed adjacent to the player (combat, sounds). That
way the player can focus on the @ and its immediate surroundings,
something they do anyway.
> > this information should be easily accessible.
>
> Care to explain what this sentence means? :)
If the monster's HP are important, display it on the side (Angband)
instead of making the player do a 'look' command. Things like that.
> > Examples of good
> > interfaces include the two line message display in ADOM, the combat
> > icons (*, -, /, etc.) in Gearhead, and the monster HP display in the
> > sidebar in some Angband variants.
>
> You can't talk about user interface solutions in separation from all of
> the actual interface.
What's the difference?
> > When the player is just moving around, what should be displayed? Is it
> > really important for the player to know each of his attributes at all
> > times? Probably not. It's probably only necessary to determine status
> > conditions, like "hungry" and "bleeding", speed, maybe a list of
> > visible items or creatures.
>
> The human in front of the screen doesn't see the stats and other
> unnecessary things displayed on the screen when he's (yes, he, not
> his avatar, as psychologically it's the player that's walking around)
> moving about the dungeon. Even if it sees them, it doesn't comprehend
> them. So they add no effort to interpreting the screen.
Well, maybe he doesn't see the words, but he will see the color (that's
something I forgot to mention: Alerts must be colored). In ADOM, for
example, if you catch a bit of yellow out of the corner of your eye,
you'll realize you're Hungry! and need to eat quickly. It's the minor
visual cues that help. Remember I said information must be easily
accessible? This is another example of what I mean. Color is easier
to observe than text, and therefore is more accessible.
> On the other hand, when they are displayed consistently all the time,
> preferably in a form that can be easily grasped (i.e. bars and colors
> rather than just numbers), the human being in front of screen can
> develop a reflex to "recognize" states just as it recognizes faces
> of its friends -- without really seeing all the details.
I don't think I've played a single roguelike where I remembered my
attributes. In ADOM, Angband, or Nethack, I don't even know what they
are most of the time. This is because it makes very little difference.
When I'm playing, I go off of the messages: "You hit the monster and
moderately wound him." It doesn't matter how high my strength is; what
matters is that I am damaging the monster. It doesn't matter how high
my constitution is; what matters is my hitpoints.
> > Also, if sounds are heard, an '!' icon should display,
> > adjacent to the player and in the direction of the noise. Perhaps
> > color could indicate distance or type of sound. for example, in ADOM,
> > "you hear the wind howling" would display a dark grey '!' in the
> > direction of the forge.
>
> Wouldn't that obscure the most important part of the dungeon -- the
> immediate vicinity of the avatar?
Typo - "an '!' icon should briefly display"
The alert would appear, then disappear.
> > During combat, there are several things the player wants to know.
> > These include monster HP, player HP, player MP, player resistances,
> > attack results, status effects, and so on.
>
> That again depends on the kind of the combat. I certainly don't
> care about monster's hit points when I'm "running over" a pack
> of rats.
Naturally. Then again, if the monster dies right away, his HP
shouldn't display in the first place.
> > It's also a good idea to
> > alert the player if his equipment breaks, or if he scores a critical
> > hit, or some similar event that changes his combat ability.
>
> It's pretty pointless to do so -- the human being in front of screen
> will not remember that, unless it was deliberately focusing on that
> information (and it doesn;t like to switch its focus).
It would be displayed the same way as combat: an icon appear briefly.
The player can still focus on his character without needing to watch
the message bar as well.
> > Ideally,
> > the information will not need to be displayed as a message, so that the
> > player doesn't have to check the top of the screen after each attack.
> > An attack would display a '*' on the target, with the color indicating
> > damage. Light grey might be a normal hit, dark grey could be a harder
> > hit, dark red could be a critical hit, and so on.
>
> What about monochrome displays?
Cool people don't use monochrome displays. ;)
> > Spells and arrows
> > should always be displayed "graphically", assuming the player would be
> > able to see them.
>
> Why?
So that the player can maintain his focus on his character. It's
better to see the relevant spell than to have to read the messages.
> > Interface also refers to input, so here are a few ideas for that.
> > There should be a generic command to interact with the environment, and
> > another generic command to equip items.
> > Unless you're making the next
> > Nethack, there's no need for a different commands for wear and wield.
>
> Why?
Because it overcomplicates things. Unless the commands do different
things (which they don't; both equip an item), they're redundant and
therefore unnecessary.
> > There should also be a generic command to use an item, like drinking a
> > potion or reading a scroll. Better yet, why not have all such commands
> > dealt with from the inventory screen? 'I' might bring up the inventory
> > screen, which would have a list of items and a bottom row something
> > like this:
> >
> > [M] More information [U] Use/wear [D] Drop Filter:
> > []{}()/\+=!?~"
>
> > You would just select the item you want with the arrow keys,
>
> This is awkward and makes habituation, that all human beings develop,
> and enemy rather than a friend.
It won't be awkward. The habituation will be fine, since the player
will grow accustomed to using the same process to accomplish different
actions.
> > and use
> > the commands when the desired item is selected. Of course, this would
> > get tedious searching for items, so it would be good to have a filter
> > option like in ADOM.
>
> ... you could further improve the interface and reduce the number of
> keypresses needed (not to mention removing a mode), by providing
> shortcuts for commands with the filters already enabled, like 'wear'
> or 'wield' or... wait, you just dismissed it :D
Wear -> select item
Inventory -> select item
...Seems the same to me.
> > There should definitely be a macro system of some sort to handle
> > tedious commands, or at least a way to map certain spells or attacks to
> > the function keys.
>
> Yes, that will easily prevent improving the bad parts of interface and
> gameplay by just patcheing them with macros. Why take the responsibility
> for the user interface when you can shift it on the human being in front
> of the screen?
It's not so much that you don't care about the interface. Think of it
this way: A player can either press 'm', then select a healing spell,
or he can macro the key combination. There's no logical way to
simplify a process like that, short of having a key 'H' which heals the
players using the best possible method. While we're at it, why not
have 'A' mean "attack using the most effective method"? Since we can
simplify it that much, let's have Ctrl-A automate the character so the
person doesn't have to press all those keys.
The interface itself isn't bad, but there's a limit to how useful it
can be. Macros let the player increase the usefulness of the interface
more than the programmer can.
> > Also, why should there be a difference in combat
> > techniques, abilities, and magic? Maybe you've learned the Cross-slash
> > technique and the Fire Bolt spell, and you can intrinsically use Stone
> > Skin. Why should you need different keys to access them? Maybe use
> > 'a' for ability, then just select one.
>
> I say why do we stop here? Let's have the game operated with one "do what
> I mean" key.
No need to be sarcastic. Remember, if two processes accomplish the
same thing, it is logical to use the simpler one. In Angband, the 'U'
key brings up a list of what are basically race-intrinsic spells. Why
not have them on the same menu as normal spells? It's just like the
wear/wield situation. Since they both do the same thing, why not
combine them?
Gamer_2k4
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
>> > Ideally, the screen
>> > should show all relevant information, and no unnecessary information;
>> Untrue. No matter how much information you do display, the human being
>> in front of the screen will only see a small part of it. Sure, it can
>> switch the focus and change the parts it sees, but focus switching is
>> one of the most inefficient and costly operations a human being does --
>> it can take even up to several seconds! No kidding, you don't "feel"
>> this time as you are busy context-switching, but have a friend
>> measure it for you.
> I understand that. You'll notice that I later advocate that
> information be displayed adjacent to the player (combat, sounds). That
> way the player can focus on the @ and its immediate surroundings,
> something they do anyway.
I'm sorry, I didn't make myself clear. I used the word "focus" without
explaining that I mean "mental focus", i.e. the thing you concentrate on,
not "visual focus", i.e. the area scanned by your eyes.
They are two different things. Consider this example:
Imagine some kind of game requiring concentration, for example the
good old Arkanoid. Now, imagine you 'enchance' the game by displaying
some scrolled text with 'backstory' as the game is played. But you
don't want to "distract" the player, so you display the text several
lines at a time, half-trasparent, overlayed over ball (on which player
naturally concentrates).
What do you think, how many people would even notice the text? Most
would just say that something is obscuring the view. That's because
while it's true that their eyes focus on the same are of screen where
the text is displayed, their minds focus on tracking the ball rather
than reading the text.
On the other hand, consider an Angband player fighting some nasty monster.
His eyes (player's, not monster's) constantly wander, from the message
are to the stats, to the monster's hitpoints bar, and back to the message
area. Yet his mind is focused on fighting the monster. Even if a message
appears about hunger, or destroying of an item in the backback -- it will
be probably ignored, even when the player *was* looking at it and even
*has* read it -- because it's not immediately related to what the player
focuses on.
Sure, there is a number of techniques to "draw player's attention". They
basically force you to switch the focus. They are usually very tiring in
the long term and universally extremely annoying (think Clippy).
>> You can't talk about user interface solutions in separation from all of
>> the actual interface.
> What's the difference?
What works for some interfaces will not work for others.
tab-completion is extremely useful in cli, yet unbearable in text
authoring.
<snip>
>> > During combat, there are several things the player wants to know.
>> > These include monster HP, player HP, player MP, player resistances,
>> > attack results, status effects, and so on.
>> That again depends on the kind of the combat. I certainly don't
>> care about monster's hit points when I'm "running over" a pack
>> of rats.
> Naturally. Then again, if the monster dies right away, his HP
> shouldn't display in the first place.
So how to you know when to display what?
>> > It's also a good idea to
>> > alert the player if his equipment breaks, or if he scores a critical
>> > hit, or some similar event that changes his combat ability.
>> It's pretty pointless to do so -- the human being in front of screen
>> will not remember that, unless it was deliberately focusing on that
>> information (and it doesn;t like to switch its focus).
> It would be displayed the same way as combat: an icon appear briefly.
> The player can still focus on his character without needing to watch
> the message bar as well.
And he will. That's why it's pointless.
Why do something that will be ignored anyways?
<snip>
>> > Spells and arrows
>> > should always be displayed "graphically", assuming the player would be
>> > able to see them.
>> Why?
> So that the player can maintain his focus on his character. It's
> better to see the relevant spell than to have to read the messages.
How an animated arrow makes him maintain the (mental) focus better than
a message?
>> > Interface also refers to input, so here are a few ideas for that.
>> > There should be a generic command to interact with the environment, and
>> > another generic command to equip items.
>> > Unless you're making the next
>> > Nethack, there's no need for a different commands for wear and wield.
>> Why?
> Because it overcomplicates things. Unless the commands do different
> things (which they don't; both equip an item), they're redundant and
> therefore unnecessary.
They do the same thing from the point of view of the programmer -- toggle
and 'equipped' flag, set some 'current weapon' pointer, etc. Yet the
things they do are very different from the gameplay point of view -- 'wield'
effectively changes the kind of attack you use by default. 'Wear' changes
the way you are protected -- your resistances, immunities, evasion, armour
class, etc. 'Put on' changes the (protective) magic you use, etc.
Remember, that decreasing the number of options, while maintaining the
level of complication, forces you to increase the number of choices to be
made per operation -- that is, doing the same thing requires more work,
not to mention it introduces additional modes.
With the additional habituation-preventing techniques you advocate, this
makes very poor interface.
>> > There should also be a generic command to use an item, like drinking a
>> > potion or reading a scroll. Better yet, why not have all such commands
>> > dealt with from the inventory screen? 'I' might bring up the inventory
>> > screen, which would have a list of items and a bottom row something
>> > like this:
>> >
>> > [M] More information [U] Use/wear [D] Drop Filter:
>> > []{}()/\+=!?~"
>> > You would just select the item you want with the arrow keys,
>> This is awkward and makes habituation, that all human beings develop,
>> and enemy rather than a friend.
> It won't be awkward. The habituation will be fine, since the player
> will grow accustomed to using the same process to accomplish different
> actions.
lol
Ok, so I will get used to the fact that doing the same exact thing will
heal me, or poison me, or make me less hungry or kill me instantly. Great.
What use is that?
A 'gotcha' game?
<snip>
>> > There should definitely be a macro system of some sort to handle
>> > tedious commands, or at least a way to map certain spells or attacks to
>> > the function keys.
>> Yes, that will easily prevent improving the bad parts of interface and
>> gameplay by just patcheing them with macros. Why take the responsibility
>> for the user interface when you can shift it on the human being in front
>> of the screen?
> It's not so much that you don't care about the interface. Think of it
> this way: A player can either press 'm', then select a healing spell,
> or he can macro the key combination. There's no logical way to
> simplify a process like that, short of having a key 'H' which heals the
> players using the best possible method. While we're at it, why not
> have 'A' mean "attack using the most effective method"? Since we can
> simplify it that much, let's have Ctrl-A automate the character so the
> person doesn't have to press all those keys.
What's the difference between including that 'heal' or 'automate' commands
in the game, and making the player write them?
> The interface itself isn't bad, but there's a limit to how useful it
> can be. Macros let the player increase the usefulness of the interface
> more than the programmer can.
I don't fully understand it. What is so 'magical' in macros that cannot be
implemented in the game directly as a command? You have a working game,
you can include all the commands that users need. If some additional
commands prove useful, you just add them in the next release. After you
make sure that they don't break the gameplay, that is.
>> > Also, why should there be a difference in combat
>> > techniques, abilities, and magic? Maybe you've learned the Cross-slash
>> > technique and the Fire Bolt spell, and you can intrinsically use Stone
>> > Skin. Why should you need different keys to access them? Maybe use
>> > 'a' for ability, then just select one.
>> I say why do we stop here? Let's have the game operated with one "do what
>> I mean" key.
> No need to be sarcastic. Remember, if two processes accomplish the
> same thing, it is logical to use the simpler one. In Angband, the 'U'
> key brings up a list of what are basically race-intrinsic spells. Why
> not have them on the same menu as normal spells? It's just like the
> wear/wield situation. Since they both do the same thing, why not
> combine them?
You need to design the user interface looking from the perspective
of "what the player character does now", not from the "how is this
coded" one.
Radomir 'The Sheep' Dopieralski
Icey wrote:
> Radomir 'The Sheep' Dopieralski wrote:
>> At 10 Nov 2006 17:54:27 -0800,
>> Icey wrote:
>>> The player can make any layout they like, which is saved and restored
>>> for when they play the next time.
>> Isn't that just dodging the responsibility for making a good layout
>> yourself?
> What I consider a good layout may be different to what other people
> consider a good layout. For example, I may want a large dungeon view,
> not show the minimap, have a long inventory and lots of status
> information. Other people may prefer the opposite. My layout system is
> designed to handle any situation.
It's like saying that a quill is better than a printing press because
it can creade practically any graphical symbol, while the printing press
is limited to the typeset it has.
So now you expect the users to all do their own reasearch on usability of
your game, learn a large chunk of cognitive psychology, do the timings and
tests and thus determine what layout is best for your game?
'Good layout' is not sopmething you can 'feel. You need to measure it.
Gamer_2k4
> > consider a good layout. For example, I may want a large dungeon view,
> > not show the minimap, have a long inventory and lots of status
> > information. Other people may prefer the opposite. My layout system is
> > designed to handle any situation.
>
> It's like saying that a quill is better than a printing press because
> it can creade practically any graphical symbol, while the printing press
> is limited to the typeset it has.
>
> So now you expect the users to all do their own reasearch on usability of
> your game, learn a large chunk of cognitive psychology, do the timings and
> tests and thus determine what layout is best for your game?
>
Ok, cool it with the psychology stuff. People know what they like.
Think of it this way. You can have a supreme pizza that has everything
and caters to the cognitive psychologists, or you can let the person
choose his toppings. Someone who only likes pepperoni and sausage
won't like the supreme pizza. The same is true with this interface.
People who only want the dungeon and message buffer, for example,
shouldn't have to be bogged down with other information that the
designer might consider important. Maybe one person likes having a
list of visible monsters, and another doesn't. Why not let them choose
what they want displayed?
Gamer_2k4
pol
> The current system is very flexible, so it's definitely possible to
> create a usable layout.
>
Maybe if you put in 3-4 different recommended layouts, it would be better.
Then they are still fully customizable, but i dont have to build everything
myself. Players are lazy
When I tried Paprika i was a little overwhelmed with all of the menus and
trying to figure out what information I needed to be displaying, some type
of preset layout, or layout templates would have been great and got me
started playing a lot quicker
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
>> So now you expect the users to all do their own reasearch on usability of
>> your game, learn a large chunk of cognitive psychology, do the timings and
>> tests and thus determine what layout is best for your game?
>> 'Good layout' is not something you can 'feel. You need to measure it.
> Ok, cool it with the psychology stuff. People know what they like.
> Think of it this way. You can have a supreme pizza that has everything
> and caters to the cognitive psychologists, or you can let the person
> choose his toppings. Someone who only likes pepperoni and sausage
> won't like the supreme pizza. The same is true with this interface.
> People who only want the dungeon and message buffer, for example,
> shouldn't have to be bogged down with other information that the
> designer might consider important. Maybe one person likes having a
> list of visible monsters, and another doesn't. Why not let them choose
> what they want displayed?
ehm... because they are important for the gameplay?
The designer decides what's important and what's not, he knows the game
best and is thus in the best position to design the interface.
And no, people won't notice which interface is more efficient, unless
they get used to it and then compare.
On the other hand, as an user, I don't care about how flexible the
layout is. I want to play the game, and if I need to set a trillion
options first to have it usable -- well, the Rogue works out of the
box...
Krice
> layout is.
We can all see that. Now, if you don't have anything meaningful
to say for this subject then why don't you just shut up.
Antoine
Radomir, don't be put off by Krice's worthless post.
A.
Dark God
*cannnnnt resssssists ttthe trolll*
Krice, Now, if you don't have anything meaningful to say for this subject
then why don't you just shut up.
Sorry guys, I just couldn't resist!
Christophe Cavalaria
You can bet that a game in which you have to script the UI yourself before
using it has lower quality that one in which you don't need to do it.
I said script because, at first you just place that subwindow in that
corner, the minimap there. Then later you want the inventory window to open
only in some situations, and later you want to create a few macro to help
you efficiently access some specific items and then ...
Users want to enjoy the game, not build it for you ;) That's why the default
UI should be enouth for everybody, or nearly everybody.
Krice
> That's why the default UI should be enouth for everybody
Agreed. UI design is important, and traditional roguelike
"UI"s can be improved so many ways...
Sheep is against improvements, because that would make
roguelikes more user friendly and maybe more "mainstream"...
You know, some people are afraid of that:)
It's like linux, it's known to have horrible ui designs derived
from ancient unix realm and linux hackers want it that way,
because they want to be hackers and power users.
I can't understand that kind of people. They are like doing
things that should not be "things" at all.
Gamer_2k4
> His eyes (player's, not monster's) constantly wander, from the message
> are to the stats, to the monster's hitpoints bar, and back to the message
> area. Yet his mind is focused on fighting the monster. Even if a message
> appears about hunger, or destroying of an item in the backback -- it will
> be probably ignored, even when the player *was* looking at it and even
> *has* read it -- because it's not immediately related to what the player
> focuses on.
I'm not just hypothesizing here. I'm speaking from experience. I like
Gearhead's combat interface because I don't HAVE to watch the messages.
Yes, I still look at the stats and hitpoints, but at least I can focus
more. If you've played ADOM, you'll know it's bad to ignore the "your
weapon breaks!" messages. A visual alert would be very useful in this
case. Also, think about it this way. Some Angband variants change the
player color or icon based on hitpoints. If, just by looking at your
player and the adjacent tiles, you know how many hitpoints you have and
that you're doing damage, does it really matter how many hitpoints the
enemy has?
> >> > During combat, there are several things the player wants to know.
> >> > These include monster HP, player HP, player MP, player resistances,
> >> > attack results, status effects, and so on.
>
> >> That again depends on the kind of the combat. I certainly don't
> >> care about monster's hit points when I'm "running over" a pack
> >> of rats.
>
> > Naturally. Then again, if the monster dies right away, his HP
> > shouldn't display in the first place.
>
> So how to you know when to display what?
It would take very little effort to code
if (player.isInCombat())
display.showMonstHP(player.fighting());
If you kill the monster right away, the next time your display
refreshes, you won't be in combat, so no HP display will appear.
> >> > Spells and arrows
> >> > should always be displayed "graphically", assuming the player would be
> >> > able to see them.
> >> Why?
> > So that the player can maintain his focus on his character. It's
> > better to see the relevant spell than to have to read the messages.
>
> How an animated arrow makes him maintain the (mental) focus better than
> a message?
It may increase the mental focus simply by increasing the visual focus.
If it doesn't increase the mental focus, there's still no downside.
> >> > Interface also refers to input, so here are a few ideas for that.
> >> > There should be a generic command to interact with the environment, and
> >> > another generic command to equip items.
> >> > Unless you're making the next
> >> > Nethack, there's no need for a different commands for wear and wield.
>
> >> Why?
>
> > Because it overcomplicates things. Unless the commands do different
> > things (which they don't; both equip an item), they're redundant and
> > therefore unnecessary.
>
> They do the same thing from the point of view of the programmer -- toggle
> an 'equipped' flag, set some 'current weapon' pointer, etc. Yet the
> things they do are very different from the gameplay point of view -- 'wield'
> effectively changes the kind of attack you use by default. 'Wear' changes
> the way you are protected -- your resistances, immunities, evasion, armour
> class, etc. 'Put on' changes the (protective) magic you use, etc.
I think it's reasonable to abstract this to "wear something that
changes your survival chance". If the player has a sword (defender), a
ring of protection, and and suit of armor, they are all doing the same
thing: increasing his AC. If the player has a ring of fire resistance
and a sword of frost, they each increase his chances of slaying a fire
type monster. Since the function is the same in both cases, why
shouldn't the command be as well?
> Remember, that decreasing the number of options, while maintaining the
> level of complication, forces you to increase the number of choices to be
> made per operation -- that is, doing the same thing requires more work,
> not to mention it introduces additional modes.
Except that by decreasing the number of options, you are also
decreasing the level of complication. The number of choices stay the
same, but the interface is simpler to use.
> >> > There should definitely be a macro system of some sort to handle
> >> > tedious commands, or at least a way to map certain spells or attacks to
> >> > the function keys.
>
> >> Yes, that will easily prevent improving the bad parts of interface and
> >> gameplay by just patcheing them with macros. Why take the responsibility
> >> for the user interface when you can shift it on the human being in front
> >> of the screen?
>
> > It's not so much that you don't care about the interface. Think of it
> > this way: A player can either press 'm', then select a healing spell,
> > or he can macro the key combination. There's no logical way to
> > simplify a process like that, short of having a key 'H' which heals the
> > players using the best possible method. While we're at it, why not
> > have 'A' mean "attack using the most effective method"? Since we can
> > simplify it that much, let's have Ctrl-A automate the character so the
> > person doesn't have to press all those keys.
>
> What's the difference between including that 'heal' or 'automate' commands
> in the game, and making the player write them?
A roguelike is largely about decision-making. The macros allow the
player to decide what actions are important to him. An archer may
assign (target, fire) to F1, but to a warrior, that would be an
unnecessary and even arbitrary assignment, especially if it was hard
coded. Also, one player may stock up on healing potions, while another
may use mana potions and just cast "heal self" instead. If the player
uses certain actions a lot, it would be logical for him to set these to
macros; OTOH, it would be illogical for the programmer to set the
macros based on what the player *might* do.
> > The interface itself isn't bad, but there's a limit to how useful it
> > can be. Macros let the player increase the usefulness of the interface
> > more than the programmer can.
>
> I don't fully understand it. What is so 'magical' in macros that cannot be
> implemented in the game directly as a command? You have a working game,
> you can include all the commands that users need. If some additional
> commands prove useful, you just add them in the next release. After you
> make sure that they don't break the gameplay, that is.
If your character has a maximum of 15 hitpoints, it would be good to
set F1 to "quaff potion of heal minor wounds". If, however, your
character has 200 hitpoints, potions of minor healing would be almost
useless, and it would be better to set F1 to "quaff potion of heal
critical wounds". Ok, so make a key that heals the most possible
without going over, right? Not necessarily. Like I said before, there
are a lot of different ways to heal, based on player preference. It
would be foolish for the programmer to create pre-defined macros, and
in essence tell the player what his preferences "should" be.
Gamer_2k4
Slash
How dare ye perform such a meaningless attack over the guy with the
highest post count on the history of r.g.r.d. ??!??
It is like an AI-less level 2 troll attacking a level 50 paladin of the
@ !!! :P :P
--
Slash
Jeff Lait
> I think it's reasonable to abstract this to "wear something that
> changes your survival chance". If the player has a sword (defender), a
> ring of protection, and and suit of armor, they are all doing the same
> thing: increasing his AC. If the player has a ring of fire resistance
> and a sword of frost, they each increase his chances of slaying a fire
> type monster. Since the function is the same in both cases, why
> shouldn't the command be as well?
Because when the user wants to use their sword (defender), they want to
be able to find it quickly in their backpack full of "useless green
gems".
> > Remember, that decreasing the number of options, while maintaining the
> > level of complication, forces you to increase the number of choices to be
> > made per operation -- that is, doing the same thing requires more work,
> > not to mention it introduces additional modes.
>
> Except that by decreasing the number of options, you are also
> decreasing the level of complication. The number of choices stay the
> same, but the interface is simpler to use.
The number of choices does not stay the same. This is the essential
advantage of the Verb based approach that you have been missing.
If I hit 'w' for wield, I see only a list of weapons in my inventory.
If I hit 'W' for Wear, I see only a list of armour in my inventory. If
I hit 'P' to put on, I see only a list of rings in my inventory.
The verb-basd system lets the player prompt the game with additional
information. The more information in each keypress reduces the
information required for later keypresses. This is, ironically,
exactly why you are advocating for macros - you are desiring the
ability to encode more information into a single keypress.
To go back to your 'U'se example. This boils down to a Noun-Verb
selection method. First one selects the item to act on, and then how
you want to act on the item. (or the latter is implied if the item has
but one use). Despite the fact that POWDER uses this very approach, I
would not argue it is inherently superior. When you press the 'u' key
you give the computer very little information: "I want to use an item".
This leaves the player to still have to specify which item to use.
Your earlier suggestion for this was to add filters to the Use (or
inventory) menu. Consider the implications. Now, if I want to wield
something, I hit 'u'. I get a list of all my inventory, from which I
need to pick out that neat sword I just picked out. Since the list is
too long, I filter by pressing '(' to get just weapons. We have thus
done 'u(' to start a wield. Likewise, to put on a ring I need to do
'u=' to list the available rings, to wear armour a 'u[' to wear armour.
After a while, I get bored of having to always do two keypresses, so I
use your macro technology to bind a key to collapse this into a single
keypress. Say, bind 'w' to 'u(', 'W" to 'u[', and 'P' to 'u='.
Now, we note that the advanced user has gone full circle. If this is a
common configuration, it only makes sense to roll it into the official
game so everyone doesn't have to setup the same macros. You have now
returned back to a verb-based system.
> > What's the difference between including that 'heal' or 'automate' commands
> > in the game, and making the player write them?
>
> A roguelike is largely about decision-making. The macros allow the
> player to decide what actions are important to him. An archer may
> assign (target, fire) to F1, but to a warrior, that would be an
> unnecessary and even arbitrary assignment, especially if it was hard
> coded. Also, one player may stock up on healing potions, while another
> may use mana potions and just cast "heal self" instead. If the player
> uses certain actions a lot, it would be logical for him to set these to
> macros; OTOH, it would be illogical for the programmer to set the
> macros based on what the player *might* do.
If (target, fire) is so repetitive, perhaps that workflow needs to be
sped up anyways? Perhaps the target should be preselected so you can
multi-fire easily without having to build
your own macro?
I have nothing against macros, or keybindings. I fear, however, that
all too often they are taken as a license for the developer to abdicate
responsibility for making an efficient game. A well designed game
should not have anyone making macros. If the archer feels compelled to
macro (target, fire), your firing interface is broken. If casting Heal
is so painful to do by the "official" route that players will be
compelled to research your macro system and bind their own 'H' key,
then you should rethink your official route.
> > > The interface itself isn't bad, but there's a limit to how useful it
> > > can be. Macros let the player increase the usefulness of the interface
> > > more than the programmer can.
> >
> > I don't fully understand it. What is so 'magical' in macros that cannot be
> > implemented in the game directly as a command? You have a working game,
> > you can include all the commands that users need. If some additional
> > commands prove useful, you just add them in the next release. After you
> > make sure that they don't break the gameplay, that is.
>
> If your character has a maximum of 15 hitpoints, it would be good to
> set F1 to "quaff potion of heal minor wounds". If, however, your
> character has 200 hitpoints, potions of minor healing would be almost
> useless, and it would be better to set F1 to "quaff potion of heal
> critical wounds". Ok, so make a key that heals the most possible
> without going over, right? Not necessarily. Like I said before, there
> are a lot of different ways to heal, based on player preference. It
> would be foolish for the programmer to create pre-defined macros, and
> in essence tell the player what his preferences "should" be.
These sort of customizability problems can be solved in ways other than
macros, however. Diablo, I think, does an excellent job in this
regard. You can bind whatever options you want to the right/left mouse
buttons, but it isn't like it requires one to write a macro. Likewise,
the potion-belt solves your heal-potion problem in a much better way
than a macro. It seems foolish that when I become more powerful I have
to rewrite the F1 macro to drink a more powerful potion. The potion
belt system in Diablo lets me use the same 1-4 keys regardless of my
character level and with no concern about having to "reprogram" my
belt.
For comparison, consider Nethack's (or is it Crawl's?) alternate weapon
option where you can quickly exchange between two weapons with a single
'x'change command. Sure, they could have embedded a macro language
which would let one inscribe @1 and @3d4 on the weapons so that they'd
be exchanged.
Go ahead and have macros. But have macros so that you can easily write
the 'x'change command and the 'w'ield command yourself, as the
developer, to provide prepackaged to players. Do not expect or require
the players to write the macros.
Going back to the MDI interface. The same thing is instructive here.
MDI is very useful for the developer to try different setups. Further,
if the developer wants to change the setup, it makes it much easier to
do without needing to touch code. However, players should be presented
with the right setup from stage one. They should not have to alter
that setup. It is your job as a developer to make that initial setup
good enough that they are not even tempted into wondering if they can
change it.
POWDER runs into these issues to. You can rebind the four buttons on
the GBA to any command you want. Nonetheless, I endeavour to ensure
that the default button arrangement is the "right" one.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Jeff Lait
>
> Ok, cool it with the psychology stuff. People know what they like.
> Think of it this way. You can have a supreme pizza that has everything
> and caters to the cognitive psychologists, or you can let the person
> choose his toppings. Someone who only likes pepperoni and sausage
> won't like the supreme pizza.
When I'm choosing the toppings for the pizza, I don't also choose what
sort of car should deliver it to me. Choice is not a good thing. As a
player of your roguelike, I want to play the game. Not the interface.
I often complain about roguelikes that demand I enter a detailed
backstory for every character before I first step foot in the dungeon.
I'm faced with a dozen choices (race, class, gender, name, alignment,
favorite colour) which mean nothing to me before I start the actual
action I came for. The ultimate example is ShockFrost's roguelike
which consists *solely* of character creation. Not even an @ shows up
on the screen at the end of a dozen questions about whether you want to
learn tin-snipping or flower arranging.
> The same is true with this interface.
> People who only want the dungeon and message buffer, for example,
> shouldn't have to be bogged down with other information that the
> designer might consider important. Maybe one person likes having a
> list of visible monsters, and another doesn't. Why not let them choose
> what they want displayed?
How am I supposed to have the slightest clue what I want displayed when
I first start your game?
Sheep isn't decrying a customizable interface. He's decrying the idea
that a customizable interface means the developer doesn't need to worry
about the interface. Sensible defaults should be the start and end of
your interface design. Configuration options are great things for the
devleoper to test different approaches to learn what the settings
should be. But, at the end of the day, the version you get right out
of the box should be the *right* version.
Again, I bring up Diablo, if only because Blizzard are infinitely wise
at these things. Notice that you can't resize the 'C'haracter screen?
Or the 'I'nventory? But notice how this is actually very useful. You
don't have to think about how much play area to sacrifice to keep your
inventory up. You either have half inventory or none. One less
game-unrelated decision to plague your subconcious, letting you focus
on the hack and slash. One less potential problem of reducing it to
one pixel width and wondering why it doesn't come back when you 'i'
toggle. One less thing to save to a .config file. One less annoyance
when you play on a new computer or someone else's machine which isn't
set up to your particular percentages.
Krice
> How dare ye perform such a meaningless attack over the guy with the
> highest post count on the history of r.g.r.d. ??!??
Is this some kind of competition for highest post counts or what?
I don't like Sheep's attitude. He is saying exactly nothing for
this particular subject. He is like 2D game developer in the
3D game newsgroup, trying to convince that no one needs
3D games in the first place:)
Radomir 'The Sheep' Dopieralski
Krice wrote:
> Slash kirjoitti:
>> How dare ye perform such a meaningless attack over the guy with the
>> highest post count on the history of r.g.r.d. ??!??
> Is this some kind of competition for highest post counts or what?
Consider who's on the 5th place ;)
> I don't like Sheep's attitude.
That's what killfile is for.
> He is saying exactly nothing for
> this particular subject.
I'm making considerable effort trying to explain my point. It's not easy
for me, but I think that those who actually read my post have some vague
idea of what I'm talking about. You're free to read them too, you know.
As for whether I'm right or wrong -- well, I never claimed to have
monopoly on ultimate truth. If my statements feel like patronizng or
forcing my point of view, then it's unintentional, due to either my
poor english or bad social skills. Most probably both.
> He is like 2D game developer in the
> 3D game newsgroup, trying to convince that no one needs
> 3D games in the first place:)
Sorry, I somehow fail to grasp your methaphor.
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
>> On the other hand, consider an Angband player fighting some nasty monster.
>> His eyes (player's, not monster's) constantly wander, from the message
>> are to the stats, to the monster's hitpoints bar, and back to the message
>> area. Yet his mind is focused on fighting the monster. Even if a message
>> appears about hunger, or destroying of an item in the backback -- it will
>> be probably ignored, even when the player *was* looking at it and even
>> *has* read it -- because it's not immediately related to what the player
>> focuses on.
>
> I'm not just hypothesizing here. I'm speaking from experience. I like
> Gearhead's combat interface because I don't HAVE to watch the messages.
> Yes, I still look at the stats and hitpoints, but at least I can focus
> more. If you've played ADOM, you'll know it's bad to ignore the "your
> weapon breaks!" messages. A visual alert would be very useful in this
> case. Also, think about it this way. Some Angband variants change the
> player color or icon based on hitpoints. If, just by looking at your
> player and the adjacent tiles, you know how many hitpoints you have and
> that you're doing damage, does it really matter how many hitpoints the
> enemy has?
Agreed: Alert, notification, warning.
Alerts are there to *force* a change of your focus, to draw your attention
to something of critical importance. The techniques you described --
distinctive, colored messages, warning icons obscurign the view, etc. are
all very good for alerts.
One important thing -- to be effective and meaningful, alerts
should be very rare and only appear when the situation indeed requires
immediate attention -- otherwise players will just develop a habit of
dismissing them without even noticing, like you do with the file deletion
confirmation dialogues.
>> So how to you know when to display what?
>
> It would take very little effort to code
> if (player.isInCombat())
> display.showMonstHP(player.fighting());
>
> If you kill the monster right away, the next time your display
> refreshes, you won't be in combat, so no HP display will appear.
I'm especially interested in the implementation details of the isInCombat
method ;)
>> >> > Spells and arrows
>> >> > should always be displayed "graphically", assuming the player would be
>> >> > able to see them.
>> >> Why?
>> > So that the player can maintain his focus on his character. It's
>> > better to see the relevant spell than to have to read the messages.
>> How an animated arrow makes him maintain the (mental) focus better than
>> a message?
> It may increase the mental focus simply by increasing the visual focus.
> If it doesn't increase the mental focus, there's still no downside.
I can see two downsides:
* development and maintenance effort
* non-skippable animations making the game unresponsive
I must admit, though, that I think that presenting shooting visually on
the map has its advantages. Not the ones you mentioned, but still
important:
* they immediately show which monsters is involved
<snip -- answered much better by Jeff>
Ray Dillinger
> Krice wrote:
>>He is saying exactly nothing for
>>this particular subject.
> I'm making considerable effort trying to explain my point. It's not easy
> for me, but I think that those who actually read my post have some vague
> idea of what I'm talking about. You're free to read them too, you know.
I think most people understand your point. The problem
is they don't agree with it.
I believe in a reasonably flexible layout: I think a game
probably ought to allow options that make the layout work
in the same way that the player's used to from another game,
and there are, you know, several other games.
You can have it start on the one you think is best.
Bear
Slash
Krice wrote:
> Slash kirjoitti:
> > How dare ye perform such a meaningless attack over the guy with the
> > highest post count on the history of r.g.r.d. ??!??
>
> Is this some kind of competition for highest post counts or what?
Off course not, else we would respect Twisted Neo :P (just kidding :D)
> I don't like Sheep's attitude. He is saying exactly nothing for
> this particular subject. He is like 2D game developer in the
> 3D game newsgroup, trying to convince that no one needs
> 3D games in the first place:)
I dont know if it is just me, but I see his point is perfectly valid.
If he talks with authority about this topic it is because he has
authority, and he is not trying to step over anybody opinion but
contributing to the discussion. I think you mustnt be so defensive ;)
--
Slash
Brendan Guild
>>> better than a message?
>>
>> It may increase the mental focus simply by increasing the visual
>> focus. If it doesn't increase the mental focus, there's still no
>> downside.
>
> I can see two downsides:
> * development and maintenance effort
> * non-skippable animations making the game unresponsive
While it might slightly increase development and maintenance effort,
I believe that doing animations properly requires that the animations
be simultaneous with accepting player commands. In other words, I
want animations that are non-skippable and yet cause no delay in game
response.
A player with really fast fingers might be able to cast a spell three
times in a second, or even more. If the spell animation takes a
second to run, then why not have the three animations overlap on the
screen? With such a system, there would be no reason to limit the
length of an animation, and you get all the benefits of showing the
player what is happening with none of the side-effects.
A non-skippable animation that locks me out of the game while I watch
is completely unacceptable, no matter how short the animation. An
interesting animation that would be cut short if I were to enter a
command would also be slightly annoying, since it would make me not
want to enter a command.
Kornel Kisielewicz
> At 10 Nov 2006 16:22:24 -0800,
> Gamer_2k4 wrote:
>
> This is a very broad domain of knowledge, and I can see you are bravely
> stepping in unarmed. This is bold, yet doomed. Please try to arm yourself
> with some knowledge of the human perception, it can save your life.
>
>> Many roguelikes have, IMO, a clunky interface.
>
> Agreed, especially the recent, "modern" ones.
Something tells me that clunkiness of interface is in the eye of the
beholder. Most people praise DoomRL for it's interface, but reading your
repies makes me understand that you wouldn't like it :/.
>> Also, if sounds are heard, an '!' icon should display,
>> adjacent to the player and in the direction of the noise. Perhaps
>> color could indicate distance or type of sound. for example, in ADOM,
>> "you hear the wind howling" would display a dark grey '!' in the
>> direction of the forge.
>
> Woudn't that obscure the most important part of the dungeon -- the
> immediate visinity of the avatar?
Not if it would only flash for a split second ;].
>> An attack would display a '*' on the target, with the color indicating
>> damage. Light grey might be a normal hit, dark grey could be a harder
>> hit, dark red could be a critical hit, and so on.
>
> What about monochrome displays?
Yeah, stop supporting monochrome, and we'll loose users who use
monochrome displays. Like 70% of the overall? :P
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
My Princess has returned to me...
Kornel Kisielewicz
>> It would take very little effort to code
>> if (player.isInCombat())
>> display.showMonstHP(player.fighting());
>>
>> If you kill the monster right away, the next time your display
>> refreshes, you won't be in combat, so no HP display will appear.
>
> I'm especially interested in the implementation details of the isInCombat
> method ;)
for sx := Player.x-1 to Player.x+1 do
for sy := Player.y-1 to Player.y+1 do
if Level.NPC[x,y].isHostile then
Exit(true)
Exit(false)
:-P
(Berserk! uses something similar to check wether the crossbow can be
fired... although it's easier, because anything except the player is
hostile :P)
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Come on, Kornel. 11 years and no binary? And it's not
vapourware?" -- Mike Blackney
Kornel Kisielewicz
> A non-skippable animation that locks me out of the game while I watch
> is completely unacceptable, no matter how short the animation. An
> interesting animation that would be cut short if I were to enter a
> command would also be slightly annoying, since it would make me not
> want to enter a command.
It works in both DoomRL and Berserk! and I never got any complaints
about it...?
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"From what I've read, a lot of people believe that GenRogue
exists and will be released some day" -- Arxenia Xentrophore
Kornel Kisielewicz
> Radomir 'The Sheep' Dopieralski wrote:
>
>> Krice wrote:
>
>>> He is saying exactly nothing for
>>> this particular subject.
>
>> I'm making considerable effort trying to explain my point. It's not easy
>> for me, but I think that those who actually read my post have some vague
>> idea of what I'm talking about. You're free to read them too, you know.
>
> I think most people understand your point. The problem
> is they don't agree with it.
Ah, I can second that. In my opinion the problem of Sheep vs. Gamer 2k4
lies on another plane that both of them are unaware of. Sheep's
arguments are absolutely true, when we consider a roguelike player
trying out a new roguelike. Gamer's arguments are mostly true (I can't
agree with all of them -- lack of a useful and well-tought default
interface is a bad thing) when we consider a "normal person"[1] trying
out a roguelike.
Just my 2 cents.
[1] yeah, we roguelikers are a bunch of masohistic creatures... and
roguelike developers are those sadists that torture them.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"If hackers will ever use virtual reality, it would show a bunch
of text terminals floating around them..." -- The Sheep
Brendan Guild
> Brendan Guild napisał(a):
>> A non-skippable animation that locks me out of the game while I
>> watch is completely unacceptable, no matter how short the
>> animation. An interesting animation that would be cut short if I
>> were to enter a command would also be slightly annoying, since it
>> would make me not want to enter a command.
>
> It works in both DoomRL and Berserk! and I never got any
> complaints about it...?
Yes, I certainly was not meaning to complain about DoomRL. That is a
great game, though it has been a while since I have played it.
As I give it a try right now, it the animations are almost too fast for
me to notice whether they are skippable or not. I think that they are
and that is certainly better than non-skippable. However, I wonder
about BFG animation. It will take me more playing to get a BFG and
remember how that is handled, but that is exactly the sort of situation
where it would be great to keep playing while the animation is being
rendered.
DarkGod
> Brendan Guild napisa�(a):
I didnt see him "napisa" around :)
> > A non-skippable animation that locks me out of the game while I watch
> > is completely unacceptable, no matter how short the animation. An
> > interesting animation that would be cut short if I were to enter a
> > command would also be slightly annoying, since it would make me not
> > want to enter a command.
> It works in both DoomRL and Berserk! and I never got any complaints
> about it...?
The non-skippable animation ins DoomRL and Berserk! are extremely
annoying and break the fun for me. Please do something!
--
DarkGod comes from | Do not meddle in the affairs of wizards
the hells for YOU ! :) | because they are subtle and quick to anger.
-----------------------+----------------------------------------------
ToME power! http://t-o-m-e.net
Kornel Kisielewicz
> Kornel Kisielewicz wrote:
>> Brendan Guild napisał(a):
>>> A non-skippable animation that locks me out of the game while I
>>> watch is completely unacceptable, no matter how short the
>>> animation. An interesting animation that would be cut short if I
>>> were to enter a command would also be slightly annoying, since it
>>> would make me not want to enter a command.
>> It works in both DoomRL and Berserk! and I never got any
>> complaints about it...?
>
> Yes, I certainly was not meaning to complain about DoomRL. That is a
> great game, though it has been a while since I have played it.
>
> As I give it a try right now,
Better wait a month -- 0.9.9 is almost ready :)
> it the animations are almost too fast for
> me to notice whether they are skippable or not. I think that they are
> and that is certainly better than non-skippable.
That was my point -- they're not, but people don't notice that at all.
Even the longest "bloodslide" animation is between levels, and people
take a "breather" then anyway.
> However, I wonder
> about BFG animation. It will take me more playing to get a BFG and
> remember how that is handled, but that is exactly the sort of situation
> where it would be great to keep playing while the animation is being
> rendered.
Well it's not. It's certainly the longest gameplay animation, but usualy
people just stare at it with a satisfaction :). As BFG shots don't
happen often (ammo for it is hard to find) any BFG shot is a reason to
have fun watching it :P.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"A random group of people is useless for anything except
statistics" -- Anubis
Kornel Kisielewicz
> I didnt see him "napisa" around :)
>
>>> A non-skippable animation that locks me out of the game while I watch
>>> is completely unacceptable, no matter how short the animation. An
>>> interesting animation that would be cut short if I were to enter a
>>> command would also be slightly annoying, since it would make me not
>>> want to enter a command.
>> It works in both DoomRL and Berserk! and I never got any complaints
>> about it...?
>
> The non-skippable animation ins DoomRL and Berserk! are extremely
> annoying and break the fun for me. Please do something!
As you are the first person to complain -- in DoomRL you can turn them
off in the INI file :P.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Well, the philosophy of the World of Shadows is based on most of the
degenerate, immoral and foremost amoral philosophical beliefs of our
world exagarated to the maximum." --Anubis
DarkGod
> DarkGod napisa�(a):
I do NOT frelling napisa around!
> > The non-skippable animation ins DoomRL and Berserk! are extremely
> > annoying and break the fun for me. Please do something!
> As you are the first person to complain -- in DoomRL you can turn them
> off in the INI file :P.
;>
--
Radomir 'The Sheep' Dopieralski
Kornel Kisielewicz wrote:
> Radomir 'The Sheep' Dopieralski napisaĹ (a):
>> I'm especially interested in the implementation details of the isInCombat
>> method ;)
> for sx := Player.x-1 to Player.x+1 do
> for sy := Player.y-1 to Player.y+1 do
> if Level.NPC[x,y].isHostile then
> Exit(true)
> Exit(false)
Ok, now you'refighting with a Large White Snake in Angband.
The snake is half as fast as you, so you use the good ol'
tactics of hit and step away, hit and step away...
Now, you're in combat all the time, yet the hp display
appears and disappears annoyingly...
Radomir 'The Sheep' Dopieralski
Kornel Kisielewicz wrote:
> Radomir 'The Sheep' Dopieralski napisaĹ (a):
> Something tells me that clunkiness of interface is in the eye of the
> beholder. Most people praise DoomRL for it's interface, but reading your
> repies makes me understand that you wouldn't like it :/.
Indeed, but I have seen worse. For example, the z-day's interface is
pretty bad :)
>> What about monochrome displays?
> Yeah, stop supporting monochrome, and we'll loose users who use
> monochrome displays. Like 70% of the overall? :P
Depends on yu user base. I certainly don't always have time to fix
the terminfo settings on various weird terminals I happen to sometimes
use. And many servers I have accounts on don't have proper entries
for screen, so it's monochrome too.
Not to mention playing over telnet.
It's not really a question of losing users. It's rather more a question
of having a game that works when other games don't. And at low
implementation cost, usually.
Arthur J. O'Dwyer
On Wed, 15 Nov 2006, Radomir 'The Sheep' Dopieralski wrote:
> Kornel Kisielewicz wrote:
>> Radomir 'The Sheep' Dopieralski napisaĹ (a):
>>> I'm especially interested in the implementation details of the isInCombat
>>> method ;)
>
>> for sx := Player.x-1 to Player.x+1 do
>> for sy := Player.y-1 to Player.y+1 do
>> if Level.NPC[x,y].isHostile then
>> Exit(true)
>> Exit(false)
>
> Ok, now you'refighting with a Large White Snake in Angband.
> The snake is half as fast as you, so you use the good ol'
> tactics of hit and step away, hit and step away...
>
> Now, you're in combat all the time, yet the hp display
> appears and disappears annoyingly...
I would never have given Kornel's answer, there. The "correct" answer,
and (AFAIK) the one Angband implements, is
if (the player just hit somebody)
current_opponent = that_guy;
if (current_opponent != NULL && current_opponent.not_dead &&
current_opponent.is_visible)
display_hp(current_opponent);
else current_opponent = NULL;
This correctly handles your "white snake" case, and it also doesn't
go nuts every time the player gets surrounded by monsters. Checking
if the current opponent is visible means that the HP display will
eventually go away on its own, if the player runs away from a fight.
You could add a timer to the current opponent, too, so that backing
around a corner didn't reset current_opponent immediately.
HTH,
-Arthur
Brendan Guild
> Better wait a month -- 0.9.9 is almost ready :)
Wonderful! I will certainly try it.
> Brendan Guild napisał(a):
>> the animations are almost too fast for me to notice whether they
>> are skippable or not. I think that they are and that is certainly
>> better than non-skippable.
>
> That was my point -- they're not, but people don't notice that at
> all. Even the longest "bloodslide" animation is between levels,
> and people take a "breather" then anyway.
The bloodslide is great. In fact, all the animations are great. I
would not consider switching to a skippable mode now because I would
hate to lose the animations. On the other hand, I do not see why I
should be forced to choose between two such unpleasant options.
In all animations except for the bloodslide, I would like to keep
moving, especially during the longer animations. It did not take me
long to notice that the barrel explosion animations are both blocking
and nonskippable. They would be a great place to make the animations
overlapping with the game-play.
It might sound like I am asking for a bit of real-time in the game,
but I am not. If there are barrels exploding when the player decides
to make a move without waiting for the animation to finish, then just
immediately apply the final effect of the barrels before the player
actually takes the move, but keep the animation going until it
finishes naturally.
>> However, I wonder about BFG animation. It will take me more
>> playing to get a BFG and remember how that is handled, but that is
>> exactly the sort of situation where it would be great to keep
>> playing while the animation is being rendered.
>
> Well it's not. It's certainly the longest gameplay animation, but
> usualy people just stare at it with a satisfaction :).
You're not giving them much choice! How about in 0.9.9? I think
overlapping animation would be a really great DoomRL RFE. I have not
looked at the source, but I don't think it should be hard to
implement. All you need to do is break the animations up into cells,
and they probably already are.
Then your main loop could be like this
while the game is not over
get the current time
while not enough time has passed for the next frame
get player input (nonblocking)
if the player entered a command
do any animation-delayed effects
do the immediate effects of the command
record any effects that you want to do after the animation
add any new animation to the animation list
else sleep for a moment (without losing input, if possible)
check how much time has passed
if the animation list isn't empty
reset the display to the bare state (without animation stuff)
for each animation (with newest animations coming last, perhaps)
draw the current animation frame
advance the animation
How hard could that be? The only two tricks are keeping careful track
of the time and breaking up the animations into frame. I'm sure they
are both trivial compared to the rest of the game.
Arthur J. O'Dwyer
On Wed, 15 Nov 2006, Brendan Guild wrote:
>
> Kornel Kisielewicz wrote:
>> Better wait a month -- 0.9.9 is almost ready :)
>
> Wonderful! I will certainly try it.
Gee, I didn't even know DoomRL was still in development; I'm still
playing the 7DRL version! :) Cool!
>> Brendan Guild napisał(a):
>>> the animations are almost too fast for me to notice whether they
>>> are skippable or not. I think that they are and that is certainly
>>> better than non-skippable.
>>
>> That was my point -- they're not, but people don't notice that at
>> all. Even the longest "bloodslide" animation is between levels,
>> and people take a "breather" then anyway.
>
> The bloodslide is great. In fact, all the animations are great. I
> would not consider switching to a skippable mode now because I would
> hate to lose the animations. On the other hand, I do not see why I
> should be forced to choose between two such unpleasant options.
...But if you like the animations, then they're not so unpleasant
after all, right?
> In all animations except for the bloodslide, I would like to keep
> moving, especially during the longer animations. It did not take me
> long to notice that the barrel explosion animations are both blocking
> and nonskippable. They would be a great place to make the animations
> overlapping with the game-play.
Seems like a big waste of developer time. Roguelikes are not real-time;
I spend longer paused between moves[1] /voluntarily/ than the barrel
animations take to run through. (I do wonder why the barrels "explode"
twice, or is that just a quirk of the old version I'm playing?)
Besides, pretty much all hardware+OS combinations support a keyboard
input buffer, so you can keep typing during the animation and your
commands will be processed after the game starts accepting input again.
The end result is the same.
> It might sound like I am asking for a bit of real-time in the game,
> but I am not. If there are barrels exploding when the player decides
> to make a move without waiting for the animation to finish, then just
> immediately apply the final effect of the barrels before the player
> actually takes the move, but keep the animation going until it
> finishes naturally.
People generally don't notice pauses of less than 0.1 second; and
I'm not sure the barrel animation takes even that long. How slow is
your computer?
(BTW, Kornel, I must know: Is the atom bomb (sorry, I forget the exact
name) good for anything or not? I set one off once, and promptly died.)
-Arthur
[1] - At least, the kinds of moves that would involve exploding things.
For pretty much anything with an in-game effect or message, I try to read
the message before plowing ahead.
Martin Read
> (BTW, Kornel, I must know: Is the atom bomb (sorry, I forget the exact
>name) good for anything or not? I set one off once, and promptly died.)
Yes, but only if you set it off in an appropriate place and are
invulnerable at the moment of detonation.
--
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"
Slash
Arthur J. O'Dwyer wrote:
> On Wed, 15 Nov 2006, Brendan Guild wrote:
> >
> > Kornel Kisielewicz wrote:
> >> Better wait a month -- 0.9.9 is almost ready :)
> >
> > Wonderful! I will certainly try it.
>
> Gee, I didn't even know DoomRL was still in development; I'm still
> playing the 7DRL version! :) Cool!
AFAIR no such 7DRL version exists! :P
SNIP
> -Arthur
>
> [1] - At least, the kinds of moves that would involve exploding things.
> For pretty much anything with an in-game effect or message, I try to read
> the message before plowing ahead.
--
Slash
Gamer_2k4
Slash wrote:
> Arthur J. O'Dwyer wrote:
> > On Wed, 15 Nov 2006, Brendan Guild wrote:
> > >
> > > Kornel Kisielewicz wrote:
> > >> Better wait a month -- 0.9.9 is almost ready :)
> > >
> > > Wonderful! I will certainly try it.
> >
> > Gee, I didn't even know DoomRL was still in development; I'm still
> > playing the 7DRL version! :) Cool!
>
> AFAIR no such 7DRL version exists! :P
It doesn't. I was talking to Kornel the other day and I happened to
call DoomRL a 7DRL, and he told me it never was one. Maybe since it's
so simple (not in a bad way), everyone just assumes was made quickly.
Gamer_2k4
Ilya Bely
Hi there!
DoomRL was under (secret) development for years (mostly inactive).
You must be confusing it with DiabloRL, that was also developed
by Kornel during one of the previous 7DRL events.
--
May your code work forever and never have a bug.
At your service, Ilya Bely
i e l y @ l . c o
l y a b g m a i m
Elethiomel
> "Arthur J. O'Dwyer" <ajon...@andrew.cmu.edu> wrote:
>
>> (BTW, Kornel, I must know: Is the atom bomb (sorry, I forget the exact
>>name) good for anything or not? I set one off once, and promptly died.)
>
>
> Yes, but only if you set it off in an appropriate place and are
> invulnerable at the moment of detonation.
Well, technically you don't need to be invurnerable.
--
A good signature is a concise and original summary of personality. This
is not a good signature.
Kornel Kisielewicz
> It might sound like I am asking for a bit of real-time in the game,
> but I am not. If there are barrels exploding when the player decides
> to make a move without waiting for the animation to finish, then just
> immediately apply the final effect of the barrels before the player
> actually takes the move, but keep the animation going until it
> finishes naturally.
I would happily implement that but unfortunately it's not possible :(.
Or, it IS possible, but would require a LOT of work (reimplementation of
the whole animation system), which would be better spent on for example
improving the AI.
>> Well it's not. It's certainly the longest gameplay animation, but
>> usualy people just stare at it with a satisfaction :).
>
> You're not giving them much choice! How about in 0.9.9? I think
> overlapping animation would be a really great DoomRL RFE. I have not
> looked at the source, but I don't think it should be hard to
> implement. All you need to do is break the animations up into cells,
> and they probably already are.
LOL, the DoomRL source at some places is messier than Win95 source :P.
The problem is DoomRL's base engine was procedural, but DoomRL was built
using Borland's Objects. And recently I modified it to use Classes
instead xD. What is the result -- a ugly mix of procedural/object/class
code...
And the main reason what makes splitting the animations difficult is the
fact that damage is calculated on the fly, as the explosion propagates.
Of course I could implement "reaction dodge", that would allow you to
escape an explosion if you have fast reflexes... but that would be ...
awkward, and would put the game seriously off-balance.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Invalid thought detected. Close all mental processes and
restart body."
Kornel Kisielewicz
> Hi there!
>
> Gamer_2k4 wrote in message <1163638464.6...@m7g2000cwm.googlegroups.com>:
>
>> Slash wrote:
>>> Arthur J. O'Dwyer wrote:
>>>> Gee, I didn't even know DoomRL was still in development; I'm still
>>>> playing the 7DRL version! :) Cool!
>>> AFAIR no such 7DRL version exists! :P
>> It doesn't. I was talking to Kornel the other day and I happened to
>> call DoomRL a 7DRL, and he told me it never was one. Maybe since it's
>> so simple (not in a bad way), everyone just assumes was made quickly.
>
> DoomRL was under (secret) development for years (mostly inactive).
Yeah, but I once revealed that the underlying engine was done in 7 days,
so that might be the reason of confusion :).
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
Kornel Kisielewicz
>
>> Yeah, stop supporting monochrome, and we'll loose users who use
>> monochrome displays. Like 70% of the overall? :P
>
> Depends on yu user base. I certainly don't always have time to fix
> the terminfo settings on various weird terminals I happen to sometimes
> use. And many servers I have accounts on don't have proper entries
> for screen, so it's monochrome too.
>
> Not to mention playing over telnet.
>
> It's not really a question of losing users. It's rather more a question
> of having a game that works when other games don't. And at low
> implementation cost, usually.
Okay, so you say that it would be good to implement a text mode in
Diablo, not to loose some users?
My point is that some games have minimum requirements just so they
provide a basic level of gameplay. In case of my games it's almost
always a color display.
BTW, I don't get that telnet argument -- I played DoomRL and Berserk!
via SSH without problems :). I wouldn't play them if they would be
monochrome anyway -- both games use color for mood, and for me it would
be like playing Quake in wireframe mode --
It's like with an idealy vertical atom bomb launcher -- sure you can
make one, but why the hell? ;p
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
Radomir 'The Sheep' Dopieralski
Kornel Kisielewicz wrote:
> Radomir 'The Sheep' Dopieralski napisaĹ (a):
>> At Wed, 15 Nov 2006 08:09:28 +0100,
>>>> What about monochrome displays?
> Okay, so you say that it would be good to implement a text mode in
> Diablo, not to loose some users?
I repeat, it's not about losing (you mean losing, right?) users. It's
about making them able to play your game even in dire circumstances :)
> My point is that some games have minimum requirements just so they
> provide a basic level of gameplay. In case of my games it's almost
> always a color display.
And my point is to not intorduce artifical minimum requirements when
your game doesn't really need them -- provided some small effort. Of
course, in cases when the effort is not small, it's not worth it.
Brendan Guild
> Brendan Guild napisał(a):
>
> I would happily implement that but unfortunately it's not possible
> :(. Or, it IS possible, but would require a LOT of work
> (reimplementation of the whole animation system), which would be
> better spent on for example improving the AI.
That is certainly a shame. This is why it is so important to be
careful and thoughtful when designing a game on the inside as well as
on the outside. Even though the internal structure of a game is
hidden from the player, it can easily create serious frustrations
when trying to make improvements.
> And the main reason what makes splitting the animations difficult
> is the fact that damage is calculated on the fly, as the explosion
> propagates.
That doesn't sound like much of a reason! Even if the animation were
split into frames, each frame would still be created from the
previous and the damage could be calculated as usual when the
appropriate frame is being created.
Only two changes should be required. The first is that each animation
loop would have to be transformed into a method call onto an object,
where the object would hold all the variables that are maintained
between iterations. This is so that animations can be run
independently and in parallel.
The other change is that the calculation of damage and all other
effects that are not purely for looks should be separated from the
animation. In other words, the animation of a barrel exploding and
the actual explosion would be calculated separately, though
undoubtely sharing much in common. This is so that if the player does
not want to wait for the animation, the actual explosion can be
accelerated to the speed of the player without sacrificing the pretty
animation.
In other words, if the marine shoots a barrel at 0-range, then there
is a possibility of taking a step before the explosion animation
finishes. If that happens, the player will see the @ getting thrown
back before the blast that throws it. But since the animations are
all rather quick, the visual flaw should be minor, and certainly much
less than cutting short the animation or freezing the keyboard.
> Of course I could implement "reaction dodge", that would allow you
> to escape an explosion if you have fast reflexes... but that would
> be ... awkward, and would put the game seriously off-balance.
I agree, that does not sound like a good idea at all. It would be
especially bad if 'reaction dodge' were a real-time thing. Even if it
were merely a stat of the character then it would be adding unhelpful
complexity to a game that is great for its simplicity.
Kornel Kisielewicz
> Kornel Kisielewicz wrote:
>> Brendan Guild napisał(a):
>>> [animations overlapping with gameplay]
>> I would happily implement that but unfortunately it's not possible
>> :(. Or, it IS possible, but would require a LOT of work
>> (reimplementation of the whole animation system), which would be
>> better spent on for example improving the AI.
>
> That is certainly a shame. This is why it is so important to be
> careful and thoughtful when designing a game on the inside as well as
> on the outside. Even though the internal structure of a game is
> hidden from the player, it can easily create serious frustrations
> when trying to make improvements.
Buahaha, DoomRL was NEVER meant to go public in the first place :D. It
was made as a personal side-project, to be discarded :>
>> And the main reason what makes splitting the animations difficult
>> is the fact that damage is calculated on the fly, as the explosion
>> propagates.
>
> That doesn't sound like much of a reason! Even if the animation were
> split into frames, each frame would still be created from the
> previous and the damage could be calculated as usual when the
> appropriate frame is being created.
Y'know, the system is realy simple and straightforward now :P. It
wouldn't be if I changed it suddenly to frames.
> The other change is that the calculation of damage and all other
> effects that are not purely for looks should be separated from the
> animation. In other words, the animation of a barrel exploding and
> the actual explosion would be calculated separately, though
> undoubtely sharing much in common. This is so that if the player does
> not want to wait for the animation, the actual explosion can be
> accelerated to the speed of the player without sacrificing the pretty
> animation.
Unfortunately it's not that simple. And as I said, there are many other
areas waiting for improvement -- ones that will truly affect gameplay.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
Kornel Kisielewicz
> your game doesn't really need them -- provided some small effort. Of
> course, in cases when the effort is not small, it's not worth it.
That's the place we differ -- I think that color is a MUST in my games :)
Slash
Kornel Kisielewicz wrote:
> Radomir 'The Sheep' Dopieralski napisa³(a):
> > And my point is to not intorduce artifical minimum requirements when
> > your game doesn't really need them -- provided some small effort. Of
> > course, in cases when the effort is not small, it's not worth it.
>
> That's the place we differ -- I think that color is a MUST in my games :)
That's because it is one of the few aids you have to induce atmosphere
in a character based display ;)
> --
> At your service,
> Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
> "From what I've read, a lot of people believe that GenRogue
> exists and will be released some day" -- Arxenia Xentrophore
--
Slash
Radomir 'The Sheep' Dopieralski
Slash wrote:
> Kornel Kisielewicz wrote:
>> Radomir 'The Sheep' Dopieralski napisaĹ (a):
>> > And my point is to not intorduce artifical minimum requirements when
>> > your game doesn't really need them -- provided some small effort. Of
>> > course, in cases when the effort is not small, it's not worth it.
>> That's the place we differ -- I think that color is a MUST in my games :)
> That's because it is one of the few aids you have to induce atmosphere
> in a character based display ;)
Any particular idea?
-
Radomir `The Sheep' Dopieralski
Note: The above should be explicitly not read as being a prohibition on (but is
not limited to) criticism, vituperation, espousal of conspiracy theories,
disagreement, speculation on personal habits and/or motivations, expressions of
contempt, unfavorable extrapolations of past behavior in order to guess future
behavior, mild cursing or any other traditional method of expressing
disapproval with a person's policy positions or personality, provided of course
that such behavior does not violate another of the Posting Rules.
Gamer_2k4
> Slash wrote:
>
> > Kornel Kisielewicz wrote:
> >> > And my point is to not intorduce artifical minimum requirements when
> >> > your game doesn't really need them -- provided some small effort. Of
> >> > course, in cases when the effort is not small, it's not worth it.
>
> >> That's the place we differ -- I think that color is a MUST in my games :)
>
> > That's because it is one of the few aids you have to induce atmosphere
> > in a character based display ;)
>
> Any particular idea?
Ah yes, another goal of an effective interface: to create an
appropriate atmosphere. If the game has a real-time display, it may be
possible to animate weather, such as falling rain and snow. That helps
with the atmosphere, but it's really hard to convey feelings with 256
characters of 16 colors. Messages MIGHT work, but they'd be pain to
constantly read, and don't actually do much. As I mentioned in another
post, "Roguelike Emotion", for a good atmosphere, actions need to have
long-reaching effects, so the player actually feels what the character
is feeling. At any rate, little events do need to have an impact on
the character.
Gamer_2k4
Brendan Guild
> Y'know, the system is realy simple and straightforward now :P. It
> wouldn't be if I changed it suddenly to frames.
That sounds odd to me. If it is simple now then it should also be
simple to modify. I know that this is a nontrivial modification, but
I think that if it is done with care the results could actually be
cleaner and simpler than the current animation system.
Of course, the actual overlapping and timing of animations and the
non-blocking IO will be extra complexity, but the animations
themselves might actually be simplified and clarified by being broken
up into frames. Even if you were not to use overlapping animations, a
frame-based animation system would make it easier to modify the
timing of the animations.
> Unfortunately it's not that simple. And as I said, there are many
> other areas waiting for improvement -- ones that will truly affect
> gameplay.
Naturally that is true. While overlapping animations would be a nice
feature, it is certainly not very creative or artistic. If you are
making progress in more important areas of the game then please keep
doing so.
On the other hand, I think overlapping animations would be a great
coat of polish on an already beautiful game. In fact, if you would be
willing to let me take a look at the relevant parts of the source
then I would be more than happy to take a crack at modifying the
animation system and the main game loop to use overlapping
animations.
At the very least I am interested to see why it cannot be done, and
my Pascal skills could use some dusting.
Radomir 'The Sheep' Dopieralski
Gamer_2k4 wrote:
Personally I think that the impact of the user interface and 'eye candy'
on the mood is a little overrated. copx's game didn't seem more 'sinister'
to me just beacuse I had to up my monitor brighness to even see something.
it's better to create the mood with monsters, items, maps, npcs, available
actions and other elements of the game mechanics.
Brendan Guild
> Ah yes, another goal of an effective interface: to create an
> appropriate atmosphere.
> Messages MIGHT work, but they'd be pain to constantly read, and
> don't actually do much.
If the messages are a pain to read then something has gone seriously
wrong. Even with tiles, the player is still only gets to see a
symbolic representation of what is supposed to be happening to the
PC. People who study mathematical fields know that symbols are only
fun if you keep inventing new challenges, so the replay value drops
like a lead balloon if symbols are all we give the player.
Ideally, the messages should be the focus of the game. The player
should spend more time looking at the messages than at the map and
each new message should be of critical importance. While the map
gives you vital tactical information and a sense of space, the
messages actually let you see and feel what is supposed to be
happening.
While I have no vast experience with how to create good messages, I
do have some thoughts on how I will try to do it in my game.
Obviously, there needs to be something interesting in every message.
Otherwise, there would be no point in reading the message or even
presenting it to the player. Given that, repetitive combat messages
which just tell you who hits whom should be dropped entirely. If the
player is happily arrow-smashing to splatter gridbugs on the
windshield, then there is no reason to offer unnecessary distractions
such as messages.
Until we teach the player otherwise, the player will have to assume
that every message could be important. But once the player has seen
enough generic combat messages to get the idea that just looking at
the HP gauge will provide a better way of getting the important info,
then you have lost the player forever.
Throwing some critical messages into the soup with all those tedious
messages is no way to fix the problem. It just forces the player to
read (or skim) every message as if it could be important, and most of
the time it will be nothing but a minor frustration.
If you have nothing interesting to say, then say nothing at all.
Either let the player focus on the HP gauge or else put the HP gauge
into the message area so that the player will actually have a good
reason to want to look there.
This does not mean that you cannot have combat messages. In fact,
combat is probably the most interesting activity that any person can
participate in. You just need to tap into that.
First, if nothing interesting happens in a round of combat then say
nothing. Much like UNIX shell commands, the player will assume that
the PC hit the monster and the monster hit back unless told
otherwise.
On the other hand, if someone gets injured then that definitely
qualifies as interesting. It is the fear of being injured that keeps
people excited during a fight. By 'injured', I do not mean a small
drop in HP or anything so trivial. Just as we advance characters by
levels to keep the player interested, we can use a similar sort of
advancement right in the middle of combat: serious injuries that have
important and lasting effects on play.
We need the message to contain graphic descriptions of violence and
blood. If possible, the player should be almost able to feel the
pain. The message should not be merely a spiced up way of saying -5
to HP, or else the player will become conditioned to ignore it after
hours and hours of play. Every injury that is presented in a message
should sound serious to the player and it should have a serious
effect on game-play.
The player should be able to to query the PC for a graphic
description of physical fitness, and through that the player will be
forced to accept that those injuries that the PC got during the last
fight were real and serious and they are not going away.
Once you have that, then offer the player commands for bandaging cuts
and setting broken bones. Implement the effects of infection and
blood-loss and make sure that they have a real effect on the game. If
the PC's face gets burned off, then do not forget to drop the
charisma stat at the very least.
After you have all that, then you can start implementing
representations of the horror that the PC is feeling about the latest
grievous injuries and put that into the messages. People cannot stop
watching another person suffering, so that is just another way to
keep message reading from becoming a pain.
On the other hand, I do not mean to suggest that every game should be
focused on such grizzly things. I only want to say that if you do not
care to give the combat messages depth then feel free to omit them
entirely.
If an experienced player is not going to care, then it is just a
distraction. In fact, if the PC is almost as likely to survive
whether or not the player knows what some message is trying to say,
then you should seriously consider skipping the message. If that
means that you have only one message per ten thousand turns, then so
be it. As long as that one message is important to the player, it is
far better to have it standing alone than floating in a sea of near-
useless messages.
Krice
> it's better to create the mood with monsters, items, maps, npcs, available
> actions and other elements of the game mechanics.
How about this plus mood you can get from graphics and possibly
using sound fx too. You know, those two don't rule out each other.
Simon Richard Clarkstone
> Gamer_2k4 wrote:
>>Messages MIGHT work, but they'd be pain to constantly read, and
>>don't actually do much.
at player's request) to have an extra status line somewhere (also
dismissable at player's request), to say how much damage the player did
and how much was done to him in the last move made (numerically?), and
maybe the words "severe", "critical", "fatal", "poisoning", "confusing",
etc to denote particularly devastating attack and special effects, as
well as "miss" to denote that something missed. With colouration, the
player would know to keep an eye of this area. Also a 3x3 grid like this:
.!-
-@-
?.!
In a status area could denote which monsters hit "!", missed "-", which
did a special attack (?), and where the adjacent empty squares are ".".
> On the other hand, if someone gets injured then that definitely
> qualifies as interesting. It is the fear of being injured that keeps
> people excited during a fight. By 'injured', I do not mean a small
> drop in HP or anything so trivial.
This fits in with my idea above.
> If an experienced player is not going to care, then it is just a
> distraction. In fact, if the PC is almost as likely to survive
> whether or not the player knows what some message is trying to say,
> then you should seriously consider skipping the message. If that
> means that you have only one message per ten thousand turns, then so
> be it. As long as that one message is important to the player, it is
> far better to have it standing alone than floating in a sea of near-
> useless messages.
Also, I found Z-Day's very very short messages to be handy. One word is
very quick to read, and many of them can be put on one line.
Must dash, I have a lecture.
--
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/)
Slash
On Nov 19, 12:29 pm, Radomir 'The Sheep' Dopieralski
<n...@sheep.art.pl> wrote:
> At 19 Nov 2006 09:21:40 -0800,
>
> Slash wrote:
> > Kornel Kisielewicz wrote:
> >> Radomir 'The Sheep' Dopieralski napisał(a):
> >> > And my point is to not intorduce artifical minimum requirements when
> >> > your game doesn't really need them -- provided some small effort. Of
> >> > course, in cases when the effort is not small, it's not worth it.
> >> That's the place we differ -- I think that color is a MUST in my games :)
> > That's because it is one of the few aids you have to induce atmosphere
> > in a character based display ;)
>Any particular idea?
Yep, human eye needs eyecandy. As I said, it is just an aid that cannot
replace a properly set theme with monsters, items, and most important:
available actions.
But an aid is an aid ;) the same I think of sound effects and music
>
> -
> Radomir `The Sheep' Dopieralski
>
> Note: The above should be explicitly not read as being a prohibition on (but is
> not limited to) criticism, vituperation, espousal of conspiracy theories,
> disagreement, speculation on personal habits and/or motivations, expressions of
> contempt, unfavorable extrapolations of past behavior in order to guess future
> behavior, mild cursing or any other traditional method of expressing
> disapproval with a person's policy positions or personality, provided of course
> that such behavior does not violate another of the Posting Rules.
yeah yeah, that disclamer was absolutely needed! :D
--
Slash
www.santiagoz.com
Kornel Kisielewicz
> Kornel Kisielewicz wrote:
>> Y'know, the system is realy simple and straightforward now :P. It
>> wouldn't be if I changed it suddenly to frames.
>
> That sounds odd to me. If it is simple now then it should also be
> simple to modify. I know that this is a nontrivial modification, but
> I think that if it is done with care the results could actually be
> cleaner and simpler than the current animation system.
No, believe me :).
>> Unfortunately it's not that simple. And as I said, there are many
>> other areas waiting for improvement -- ones that will truly affect
>> gameplay.
>
> Naturally that is true. While overlapping animations would be a nice
> feature, it is certainly not very creative or artistic. If you are
> making progress in more important areas of the game then please keep
> doing so.
This is a kind of feature that could be added once the sources are public.
> On the other hand, I think overlapping animations would be a great
> coat of polish on an already beautiful game. In fact, if you would be
> willing to let me take a look at the relevant parts of the source
> then I would be more than happy to take a crack at modifying the
> animation system and the main game loop to use overlapping
> animations.
>
> At the very least I am interested to see why it cannot be done, and
> my Pascal skills could use some dusting.
Hah, you don't even imagine how ugly the code it ^_^. But you'll be able
to take a look in the future :).
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Coding is *much* easier if you know what you want to do..." -
Gamer_2k4
R. Dan Henry
>Hi Gamer_2k4. I've made a screenshot of my roguelike for you, mainly
>because the interface works differently to other roguelikes:
>
>http://iceyboard.no-ip.org/images/paprika/interface.gif
>
>The interface is MDI (multiple document interface). This means there is
>a set of child windows which are contained inside one parent window.
>All child windows can be moved, resized, maximized, minimized and
>restored. Some windows like the map don't need to be shown at all. The
>only two that are needed are the log window and the dungeon window,
>when a game is in progress.
The little intro story text says "Determine to rid the world of the
demon..." -- it should start "Determined".
Could you at least make it "critically hits" instead of "critical hits"?
I'd rather see something that doesn't require a gamer's neologism, such
as "hits the foo very hard!" or use of weapon-based verbs like
"bisects", "smashes", and "skewers".
>The player can make any layout they like, which is saved and restored
>for when they play the next time.
I dislike the arrangements shown because there's a lot of wasted space,
so I'd definitely want to switch things.
>The interface modes are graphical and text. The mode can be switched at
>any time, even during a game. The tiles and text size can be made
>bigger and smaller. For example, here's the same scene above, after
>I've switched the mode:
>
>http://iceyboard.no-ip.org/images/paprika/interface-text.gif
Ah. So I'm guessing that thing with the green line under it is an 'a'nt
and not a hookah. (Yeah, I'm an ASCII guy and this just reminded me why.
The "P"ig or whatever [looks like a klingon targ] is cool-looking,
though.)
>The contents of the status window can be changed by clicking on it.
>Information can be added and removed very easily:
>
>http://iceyboard.no-ip.org/images/paprika/interface-status.gif
That's very nifty. However, I'm not sure the benefits of flexibility are
really worth putting in the effort here instead of working on the game
itself.
>The interface is operated by mouse and keyboard, both must be used.
And you just lost me there. I don't want to mess with the mouse when I'm
playing. Such a flexible interface... except where it really matters to
me.
Good luck, anyway.
P.S.: Your game does have a cool name.
--
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
Dopieralski <ne...@sheep.art.pl> wrote:
>And no, people won't notice which interface is more efficient, unless
>they get used to it and then compare.
But efficiency is not what most people are looking for when they want to
customize. What they want is familiarity. Which is a sort of efficiency
in that it minimizes learning a new set up, but it ignores the sort of
"best layout for the job" efficiency you are looking for. But to make
the game newbie-friendly, letting them mimic a layout from a favorite
game (even if it is objectively not such a good one) may be a very good
move.
It also provides an actual roguelike environment to try out those
theories about interface layout. I doubt any of those psychologists
looks specifically at the needs of RL players, so this could be a tool
for taking general theory and testing specific applications in a RL
game. Probably this is more useful for designers/design theorists than
for players who won't be bothered to try out different layouts.
Kornel Kisielewicz
> P.S.: Your game does have a cool name.
*giggles* Never mind the game name -- his nick is a lot cooler :P
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"In summary, it's new, important, and obsolete." -- Mao/GearHead
Timofei Shatrov
<admin@nospam_chaosforge.org> tried to confuse everyone with this message:
>R. Dan Henry napisał(a):
>> P.S.: Your game does have a cool name.
>
>*giggles* Never mind the game name -- his nick is a lot cooler :P
Ice cold, baby! :)
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Icey
> The little intro story text says "Determine to rid the world of the
> demon..." -- it should start "Determined".
Fixed. Thank you for pointing that out.
There's about 12 different starting intro's like that and the game
picks a random one for each game. Once the game is further along
developement, that will be removed and the story will be told in the
game. For example, the commoners will be running around the town
screaming about terrible monsters, how their house was destroyed by
wild magic and the town mayor will turn up and explain the situation.
That sort of thing.
> Could you at least make it "critically hits" instead of "critical hits"?
> I'd rather see something that doesn't require a gamer's neologism, such
> as "hits the foo very hard!" or use of weapon-based verbs like
> "bisects", "smashes", and "skewers".
Done. I've changed it to "critically hits".
There are two types of hits: Normal and Critical. Critical hits, as
expected, do more damage. For example, a weapon that normally does d4
acid damage would do d4*2 damage. Poison only effects the attacked
creature a specified percentage of the time, but with critical hits it
always takes effect, unless they are immune or save against it.
The player and any creature can do critical hits against opponents.
> >The player can make any layout they like, which is saved and restored
> >for when they play the next time.
>
> I dislike the arrangements shown because there's a lot of wasted space,
> so I'd definitely want to switch things.
Yes!! This is my thinking as well. We all like different things, so by
providing a flexible interface, everyone is happy.
> >http://iceyboard.no-ip.org/images/paprika/interface-text.gif
>
> Ah. So I'm guessing that thing with the green line under it is an 'a'nt
> and not a hookah.
Aye, that's a wimpy black ant. You need to watch out for the nasty
fire-infested red ants. The green line shows the health of the
creature.
The green line shows the health of the creature. I'll probably change
it so hostile creatures have a red bar (currently green) and friendly
creatures have a green bar (currently blue).
I've never heard of a hookah before *runs over to wikipedia* Oooh, it
does look a bit like that!
> (Yeah, I'm an ASCII guy and this just reminded me why.
> The "P"ig
"P"et :)
There's different pets, but I wanted them to have the same letter,
otherwise it would be a bit confusing to tell them apart from monsters
in ascii mode.
> or whatever [looks like a klingon targ] is cool-looking,
> though.)
It's a baby dinosaur, which has a small chance of causing blindness by
stabbing creatures in the eye with that spike!
> >The contents of the status window can be changed by clicking on it.
> >Information can be added and removed very easily:
> >
> >http://iceyboard.no-ip.org/images/paprika/interface-status.gif
>
> That's very nifty. However, I'm not sure the benefits of flexibility are
> really worth putting in the effort here instead of working on the game
> itself.
At this stage of developement it probably wasn't a wise thing to write
in, because there are more important things to write in. However, all
the status display code is written in now, so no matter. I'm saving the
larger nice-to-have features for much later.
> >The interface is operated by mouse and keyboard, both must be used.
>
> And you just lost me there. I don't want to mess with the mouse when I'm
> playing. Such a flexible interface... except where it really matters to
> me.
It's a shame you feel that way. Why don't you like using the mouse?
Virtually every game and application uses it.
I want the game to be accessible for people who haven't played a
roguelike before, so I'm not using loads of letters to perform actions.
Instead of pressing a letter for an action, displaying the inventory
and then pressing another letter to match the item, the player would
click the item in the inventory and a menu is displayed with the
actions (drop, examine, sell, drink, eat, cast, etc). I think this is a
much easier system to learn and use.
> Good luck, anyway.
Thank you, and for your suggestions and comments as well.
> P.S.: Your game does have a cool name.
I think so as well :) I had a mini-discussion about it before:
http://groups.google.com/group/rec.games.roguelike.development/browse_frm/thread/d6616abdcf5af3be/e87c48d8d6b9259f?#e87c48d8d6b9259f
Dark God
Probably easier to learn yes. Easier to use ? No way.
Pressing 2 or 3 predefined keys is always much faster than moving the
mouse to the right spot, click the second button then moving again to
the right spot and then clicking again.
Using keyboard you just need to know the letters and the keyboard.
Only your mind and your hand are at work. When you use mouse you need
to know the location of the item to click, the location where you'll need
to move the mouse to in the menu, it requires the hand, the mind and the
eye to work.
Have both.
Christophe Cavalaria
> Probably easier to learn yes. Easier to use ? No way.
> Pressing 2 or 3 predefined keys is always much faster than moving the
> mouse to the right spot, click the second button then moving again to
> the right spot and then clicking again.
> Using keyboard you just need to know the letters and the keyboard.
> Only your mind and your hand are at work. When you use mouse you need
> to know the location of the item to click, the location where you'll need
> to move the mouse to in the menu, it requires the hand, the mind and the
> eye to work.
> Have both.
handling the mouse and coordinating those three things at the same time
should be too much of a problem.
Oh and, try more advanced UI like the one in NWN for example. Want to cast a
fireball? No problem, right click on target, move up-right for spells,
up-left for wizard spells ( think, multiclass here ), right for level 3
spells and right again for fireball. Works great I assure you ;)
Dark God
> Well, since I see no point in playing with my eyes closed, I don't think
> handling the mouse and coordinating those three things at the same time
> should be too much of a problem.
You eyes are in the map usually no the inventory..
> Oh and, try more advanced UI like the one in NWN for example. Want to cast a
> fireball? No problem, right click on target, move up-right for spells,
Moving is the problem, it is much harder to move X pixels in a direction
than to press a key. You have to move fast enough(otherwise it's just too
bothersome), in the correct direction, for the correct distance.
A key you just press it, they are big enough to not be mistaken and you
can press it hard or soft or whatever, it just works.
Obviously I'm speaking for people experienced with the mouse and people
experienced with the keyboard.
When learning the mouse is indeed easier. It just is not quite as fast
> up-left for wizard spells ( think, multiclass here ), right for level 3
> spells and right again for fireball. Works great I assure you ;)
I played NWN a lot, the interface is easy to use, but it sucks for
fast play. I never could play combats real time because what you describe
is really too slow.
The shortcut bar helped a lot since it could be triggered by the keyboard
(although it still required to mouse select a target each time).
Arthur J. O'Dwyer
On Wed, 22 Nov 2006, Christophe Cavalaria wrote:
> Dark God wrote:
[on mouse-driven item selection]
You play a lot of DDR, I take it? :)
I agree --- pressing 'w' to wield a weapon is too confusing for newbies.
The mouse is much simpler; just move it up-down-up-down-left-right-left-
right-A-B to select "wield", then at a 45-degree angle for 0.3 seconds
to indicate "broadsword"...
Seriously, if you want to expend effort on mouse events, go for it,
but make sure to keep the keyboard shortcuts. There's no penalty for
using the keyboard, and it'll make it a lot easier for experienced players
(if your game sticks around long enough to acquire any... or, including
yourself when trying to debug a problem quickly!).
The real issue isn't so much the required manual dexterity to use a
mouse accurately; it's the overloading. In, say, NetHack, 'w' only ever
means one thing. But moving the mouse diagonally and then left-clicking
could mean any of a dozen things, which your brain has to disambiguate
on the fly. Therefore, it's much easier to use the unambiguous and speedy
'w' and save your brain cells for the game itself.
For the same reasons, every graphical OS, browser, word processor,
etc., provides keyboard shortcuts such as Ctrl-V in addition to ---
or sometimes instead of --- "right-click, locate Paste, mouse to Paste,
left-click".
HTH,
-Arthur
Kornel Kisielewicz
>> Oh and, try more advanced UI like the one in NWN for example. Want to
>> cast a
>> fireball? No problem, right click on target, move up-right for spells,
>> up-left for wizard spells ( think, multiclass here ), right for level 3
>> spells and right again for fireball. Works great I assure you ;)
>
> You play a lot of DDR, I take it? :)
I do! I hope it is reflected in my games :P. BTW, I once had an idea, to
make a roguelike that could be solely controlled by a dancing mate. Look
-- playing with no hands :-P.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"It's much easier to make an army of dumb good people than to
make one single smart good guy..." -- DarkGod
Christophe Cavalaria
> Moving is the problem, it is much harder to move X pixels in a direction
> than to press a key. You have to move fast enough(otherwise it's just too
> bothersome), in the correct direction, for the correct distance.
> A key you just press it, they are big enough to not be mistaken and you
> can press it hard or soft or whatever, it just works.
You know, when I gave the NWN example it wasn't at random. In NWN, the
distance you move the mouse does not matter! Only the direction count
( well, you still have to move far enouth and not too far but it is very
tolerant ). They have a very similar interface in the Temple of Elemental
Evil although slightly more complex. I find it easier to press the wrong
key than to select the wrong menu item ;)
> Obviously I'm speaking for people experienced with the mouse and people
> experienced with the keyboard.
> When learning the mouse is indeed easier. It just is not quite as fast
Maybe, maybe not. But this is the realms of the CLI vs GUI flame war, and I
dare say that nobody has a definitive answer on that one.
> The shortcut bar helped a lot since it could be triggered by the keyboard
> (although it still required to mouse select a target each time).
You know what? I like that the game lets me chose myself the target of my
fireball :) It sure makes for a friendly experience.
Elethiomel
You could also use the keypad to navigate the radial menu. Pressing "0"
on the keypad would open the radial menu on the player character. This
was how I cast the usual buffing spells on myself in NWN - the mouse was
far too slow, as you say.
--
A good signature is a concise and original summary of personality. This
is not a good signature.
Christophe Cavalaria
>
> On Wed, 22 Nov 2006, Christophe Cavalaria wrote:
>> Dark God wrote:
> [on mouse-driven item selection]
>>> Probably easier to learn yes. Easier to use ? No way.
>>> Pressing 2 or 3 predefined keys is always much faster than moving the
>>> mouse to the right spot, click the second button then moving again to
>>> the right spot and then clicking again.
>>> Using keyboard you just need to know the letters and the keyboard.
>>> Only your mind and your hand are at work. When you use mouse you need
>>> to know the location of the item to click, the location where you'll
>>> need to move the mouse to in the menu, it requires the hand, the mind
>>> and the eye to work.
>>> Have both.
>>
>> Well, since I see no point in playing with my eyes closed, I don't think
>> handling the mouse and coordinating those three things at the same time
>> should be too much of a problem.
>>
>> Oh and, try more advanced UI like the one in NWN for example. Want to
>> cast a fireball? No problem, right click on target, move up-right for
>> spells, up-left for wizard spells ( think, multiclass here ), right for
>> level 3 spells and right again for fireball. Works great I assure you ;)
>
> You play a lot of DDR, I take it? :)
Well, the game has visual menu to show what is each direction. But once you
get used to it since the layout doesn't change often, you do not take the
time to read what is written ( or drawn in that cast ) anymore.
> I agree --- pressing 'w' to wield a weapon is too confusing for
> newbies.
> The mouse is much simpler; just move it up-down-up-down-left-right-left-
> right-A-B to select "wield", then at a 45-degree angle for 0.3 seconds
> to indicate "broadsword"...
As a matter of fact, either you open the inventory screen and drag the sword
in the hand of the avatar, or you drag the sword to the shortcut bar and
you press the corresponding key ;)
> Seriously, if you want to expend effort on mouse events, go for it,
> but make sure to keep the keyboard shortcuts. There's no penalty for
Keyboard shortcuts are VERY important for a mouse interface. After all, you
only need one hand to handle the mouse. The other is free to press any
shortcut it wants.
Mouse only interfaces should be avoided unless you are targeting PDA type
systems where keyboards aren't available. Because of that, they are indeed
an interesting topic of study.
> using the keyboard, and it'll make it a lot easier for experienced players
> (if your game sticks around long enough to acquire any... or, including
> yourself when trying to debug a problem quickly!).
>
> The real issue isn't so much the required manual dexterity to use a
> mouse accurately; it's the overloading. In, say, NetHack, 'w' only ever
> means one thing.
Then what does pressing twice 'w'? Hint, the first is the wield command, and
the second selects an item in the w slot. There is some overloading after
all ;)
> But moving the mouse diagonally and then left-clicking
> could mean any of a dozen things, which your brain has to disambiguate
> on the fly. Therefore, it's much easier to use the unambiguous and speedy
> 'w' and save your brain cells for the game itself.
I can only ask you to try for yourself a web browser with mouse gestures.
You'll find that it is easy enouth to learn, remember and use efficiently.
There's a Firefox/Mozilla plugin and Opera has them builtin for a long
time. KDE has them builtin so you can add gestures in any application if
you want ( right-left-down => open a terminal rulez ;) )
Jeff Lait
Interesting choice of example. In NWN, I had memorized the num-pad
keys required to cast various priest buffs. I rarely used the radial
menu with the mouse, instead opting for pressing the right number key
each time.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Gamer_2k4
> on the keypad would open the radial menu on the player character. This
> was how I cast the usual buffing spells on myself in NWN - the mouse was
> far too slow, as you say.
That's an excellent idea. You could have the standard verbose spell
screen, and then you could have a selector, activated by pressing num0.
It might look something like this:
############### ############### ###############
# # # # # #
# # # # # #
# Attack # # Defense # # Healing #
# # # # # #
# # # # # #
############### ############### ###############
############### ###############
# # # #
# # # #
# Divination # @ # Morph #
# # # #
# # # #
############### ###############
############### ###############
# # # #
# # # #
# Movement # # Control #
# # # #
# # # #
############### ###############
Since the camera is centered on the player (at least in my game), you
can always bring up this display without worrying about going off the
screen or something similar. To select the desired spell type, you
just press the correct directional key. This would bring you to the
appropriate spell list.
############### ############### ###############
# Fireball # # Drain Life # # Smite #
# Cost: 5 # # Cost: 8 # # Cost: 1 #
# Level: 2 # # Level: 3 # # Level: 5 #
# Range: 5 # # Range: 1 # # Range: 5 #
# Damage: 2D6 # # Damage: 5D4 # # Damage: 1D3 #
############### ############### ###############
############### ###############
# Decay # #Pwr Word Kill#
# Cost: 8 # # Cost: 20 #
# Level: 3 # @ # Level: 1 #
# Range: 3 # # Range: 5 #
# Damage: 6D5 # # Damage: 9D9 #
############### ###############
############### ############### ###############
# Blizzard # # Lucent Beam # # Acid Blast #
# Cost: 10 # # Cost: 5 # # Cost: 6 #
# Level: 1 # # Level: 2 # # Level: 4 #
# Range: 8 # # Range: 8 # # Range: 3 #
# Damage: 3D5 # # Damage: 4D3 # # Damage: 4D4 #
############### ############### ###############
In the above diagram, the player selected Attack and is now presented
with a list of options. This way you can have access to 64 spells of 8
types, activated with 3 key presses and no scrolling.
Gamer_2k4
Kornel Kisielewicz
> That's an excellent idea. You could have the standard verbose spell
> screen, and then you could have a selector, activated by pressing num0.
> It might look something like this:
>
> ############### ############### ###############
> # # # # # #
> # # # # # #
> # Attack # # Defense # # Healing #
> # # # # # #
> # # # # # #
> ############### ############### ###############
>
> ############### ###############
> # # # #
> # # # #
> # Divination # @ # Morph #
> # # # #
> # # # #
> ############### ###############
>
> ############### ###############
> # # # #
> # # # #
> # Movement # # Control #
> # # # #
> # # # #
> ############### ###############
Great idea! I could easily control that with my DDR dancing mate :D
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Oh come on. We both know the truth about this game --
vapourware." -- Anathiel about GenRogue
Gamer_2k4
Which brings up an interesting question: would it be possilbe to
simplify the controls of a roguelike to the point that one could
operate them with just the arrow keys (or dancepad)?
If so, would it be a good idea?
Next on "Roguelike of the Month": DDRL!
Gamer_2k4
Kornel Kisielewicz
The first problem I see is the lack of middle button on most dancing
mates. Not to mention that most metal ones have only 4 directions :).
But I confess I had this idea, and even a preliminary design ^_^.
Dance Dance Roguelike :D
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"It is by Perl alone I set my webpages in motion. Perl generates
PHP, PHP generates HTML. HTML becomes a warning. It is by Perl
alone I set my webpages in motion... " -- Anubis
Antoine
Gamer_2k4 wrote:
> > Great idea! I could easily control that with my DDR dancing mate :D
>
> Which brings up an interesting question: would it be possilbe to
> simplify the controls of a roguelike to the point that one could
> operate them with just the arrow keys (or dancepad)?
On a related note, my in-dev game can be played with a one-button
mouse. Without using menus.
(Could also use a stylus, the principle is the same.)
Right button is also used for mouse-look, but you can easily manage
without that.
A.
Slash
On Nov 23, 8:28 pm, "Gamer_2k4" <gamer...@gmail.com> wrote:
> > You could also use the keypad to navigate the radial menu. Pressing "0"
> > on the keypad would open the radial menu on the player character. This
> > was how I cast the usual buffing spells on myself in NWN - the mouse was
> > far too slow, as you say.That's an excellent idea. You could have the standard verbose spell
Very nice idea Jarred! I like it a lot... kindof reminds me of Seiken
Densetsu.
Will be very useful on my cellphone version ;)
>
> Gamer_2k4
--
Slash
Slash
On Nov 22, 4:01 pm, Kornel Kisielewicz <admin@nospam_chaosforge.org>
wrote:
> Arthur J. O'Dwyer napisał(a):>> Oh and, try more advanced UI like the one in NWN for example. Want to
> >> cast a
> >> fireball? No problem, right click on target, move up-right for spells,
> >> up-left for wizard spells ( think, multiclass here ), right for level 3
> >> spells and right again for fireball. Works great I assure you ;)
>> You play a lot of DDR, I take it? :)
>
> I do! I hope it is reflected in my games :P. BTW, I once had an idea, to
> make a roguelike that could be solely controlled by a dancing mate. Look
> -- playing with no hands :-P.
Do you really? I used to play DDR some time ago (not that I was a
master tapper)
And if you can make a dancing mate controlled roguelike that could
easily be translated to a mobile device ;)
> --
> At your service,
> Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
> "It's much easier to make an army of dumb good people than to
> make one single smart good guy..." -- DarkGod
--
Slash
Elethiomel
When stepping on a dance mat, it's trivial to press two buttons (very
nearly) simultaneously. This could be used for menu selection, etc.
POWDER shows that it is possible to make a roguelike with a very limited
selection of buttons.
Christophe
Shouldn't be a problem, in fact I'm sure it can be done with only one
button : http://en.wikipedia.org/wiki/Morse_code
;)
Kornel Kisielewicz
You don't get my point :) -- I was thinking of doing a FUN game xD
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"Some thing's just cannot be programmed in a roguelike. For
everything else, there's GenRogue" -- Anubis
Kornel Kisielewicz
>
> On Nov 22, 4:01 pm, Kornel Kisielewicz <admin@nospam_chaosforge.org>
> wrote:
>> Arthur J. O'Dwyer napisał(a):>> Oh and, try more advanced UI like the one in NWN for example. Want to
>>>> cast a
>>>> fireball? No problem, right click on target, move up-right for spells,
>>>> up-left for wizard spells ( think, multiclass here ), right for level 3
>>>> spells and right again for fireball. Works great I assure you ;)
>>> You play a lot of DDR, I take it? :)
>> I do! I hope it is reflected in my games :P. BTW, I once had an idea, to
>> make a roguelike that could be solely controlled by a dancing mate. Look
>> -- playing with no hands :-P.
>
> Do you really? I used to play DDR some time ago (not that I was a
> master tapper)
My close friend is the second DDR-player in Poland, and first one on
Double mode :].
> And if you can make a dancing mate controlled roguelike that could
> easily be translated to a mobile device ;)
Nah, that's not the idea. The idea is to make a dynamic dungeon crawl in
which you would sweat in the more tedious battles. But from the other
side, it should not involve just tapping as fast as possible.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
Christophe
> (snip) In the above diagram, the player selected Attack and is now
> presented with a list of options. This way you can have access to 64
> spells of 8 types, activated with 3 key presses and no scrolling.
Hey, wouldn't that be also a great way to control a roguelike with a
console gamepad?
Slash
On Nov 24, 10:44 am, Kornel Kisielewicz <admin@nospam_chaosforge.org>
wrote:
> Slash napisał(a):
>
>
>
> > On Nov 22, 4:01 pm, Kornel Kisielewicz <admin@nospam_chaosforge.org>
> > wrote:
> >> Arthur J. O'Dwyer napisał(a):>> Oh and, try more advanced UI like the one in NWN for example. Want to
> >>>> cast a
> >>>> fireball? No problem, right click on target, move up-right for spells,
> >>>> up-left for wizard spells ( think, multiclass here ), right for level 3
> >>>> spells and right again for fireball. Works great I assure you ;)
> >>> You play a lot of DDR, I take it? :)
> >> I do! I hope it is reflected in my games :P. BTW, I once had an idea, to
> >> make a roguelike that could be solely controlled by a dancing mate. Look
> >> -- playing with no hands :-P.
>
> > Do you really? I used to play DDR some time ago (not that I was a
> > master tapper)My close friend is the second DDR-player in Poland, and first one on
> Double mode :].
>
> > And if you can make a dancing mate controlled roguelike that could
> > easily be translated to a mobile device ;)
> Nah, that's not the idea. The idea is to make a dynamic dungeon crawl in
> which you would sweat in the more tedious battles. But from the other
> side, it should not involve just tapping as fast as possible.
So, moving would be turtle-like in the four directions, tapping both
sides would enter attack mode, where special attacks are made based on
certain arrow patterns?
>
> --
> At your service,
> Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
> "Some thing's just cannot be programmed in a roguelike. For
> everything else, there's GenRogue" -- Anubis
--
Slash
Jeff Lait
Console game pads don't let you specify 8 directions easily. You can
only rely on the user being able to pick one-of-four.
That said, my early plans for POWDER had me using quad-menus everywhere
to select things to reduce menu length. In practice, I find the linear
menus suffice for rare operations and common operation shouldn't be on
a menu to begin with.
Christophe Cavalaria
I think this could work with 8 directions with a small delay before
validation ( this would leave enouth time for the game to pickup the
diagonal ) or even by requiring the user to validate the input with a
button. That last one will be slightly less efficient but not too much.
Also, I said that it could be used for a console game, and thinking about
it, I guess it was already done. At least the limited 4 directions version
you talk about. I've seen such system in the Shining Force games, and in
the other games by the same team : the awesome Golden Sun on GBA for
example :)
Gamer_2k4
> Densetsu.
>
> Will be very useful on my cellphone version ;)
Actually, the Secret of Mana (which Seiken Densetsu is either based on
or is a sequel to) was where I got the idea.
And it's "Jared", with one 'r'. It's still closer than most people are
(jahrod, gerrad, jerad, jerrod, etc.) ;)
Gamer_2k4
Kornel Kisielewicz
Oh don't bitch about it! At least you have a pronouncable surname :P.
Martin Read
>Gamer_2k4 napisał(a):
>> And it's "Jared", with one 'r'. It's still closer than most people are
>> (jahrod, gerrad, jerad, jerrod, etc.) ;)
>
>Oh don't bitch about it! At least you have a pronouncable surname :P.
What's unpronounceable about "Kisielewicz"? :)
--
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"
Antoine
Martin Read wrote:
> Kornel Kisielewicz <admin@nospam_chaosforge.org> wrote:
> >Gamer_2k4 napisał(a):
> >> And it's "Jared", with one 'r'. It's still closer than most people are
> >> (jahrod, gerrad, jerad, jerrod, etc.) ;)
> >
> >Oh don't bitch about it! At least you have a pronouncable surname :P.
>
> What's unpronounceable about "Kisielewicz"? :)
It seems easy to me. First you say 'Kis' then you say 'ielewicz'
A.
Gamer_2k4
Good point...when I bother to say your name, I generally say it like
"keeselweasel", mainly due to lack of effort on my part, even though
it's probably pronounced "keeselevis".
Gamer_2k4
Krice
> "keeselweasel", mainly due to lack of effort on my part, even though
> it's probably pronounced "keeselevis".
I think it's keeslevich (kiislevich).
Who knows.. polish.. god damn language..
Kornel Kisielewicz
Actualy the closest english transliteration would be Kee-she-le-vitch.
;] -- but the "she" sylab would have to be like in shepard but softer :P.
--
At your service,
Kornel Kisielewicz (adminATchaosforge.org) [http://chaosforge.org]
"In summary, it's new, important, and obsolete." -- Mao/GearHead
Milesss
http://midp-calc.sourceforge.net/Calc.html#Menu
This Java calculator for cellphones uses menu navigated only by
joystick. I find it very handy and i think something like that could be
implemented to control roguelike, especially mobile one.
--
Milesss zvy...@vagrevn.cy
Ray Dillinger
> Oh and, try more advanced UI like the one in NWN for example. Want to cast a
> fireball? No problem, right click on target, move up-right for spells,
> up-left for wizard spells ( think, multiclass here ), right for level 3
> spells and right again for fireball. Works great I assure you ;)
I don't think I'll ever play a roguelike that requires me to take my
hands off the keyboard. Mousing breaks up my zen.
Bear