Designing for Non-Roguelikers

[Darren Grey]

Well, I'm guessing this'll spark a number of disagreements, but I'm curious as to what other people have to think or contribute to this. I've written this article today and would like to polish it a bit more before putting it on RogueBasin. But reflecting on this is as much for my own benefit as it is intended to be a guide for others.

For some this article is irrelevant – they only care about existing Roguelike players touching their games. All fine and well, but I’d like to see more people enjoying all the great games we have around, and in particular I have a goal of making the first truly accessible ASCII game. Er, wish me luck :/

One problem though – the interface. I’ve watched hardcore gamers try out Broken Bottle (which is considered to have a good interface for a Roguelike) and they’ve not been able to figure out how to move, or how to leave the first level. All the assumptions we have about the interface are completely null to them. It’s immensely painful watching someone try to play your game and being so unfamiliar with the controls that they move at a snail’s pace, and have such trouble with even movement that they fail to see the rest of the depth of play.

Well, here’s some points I’ve come to learn about making roguelikes more accessible for non-roguelikers. Most centre around interface, but there are some design considerations too. Feel free to post more in the comments.

4-way movement
Ooh, I can hear the traditionalists grinding their teeth already… But every time I introduce a new person to roguelikes they fail to grasp the ability to move in diagonals. Years of d-pad or arrow key use has made them think purely of the cardinal directions. Also it’s hard to get 8-way movement to work nicely on a laptop, whatever crazy shift+direction scheme you might invent (and don’t even *think* about forcing vi-keys on players). WASD and arrow keys are all outside gamers can cope with. So stick to 4-way, and let the monsters only move 4-way too. It feels weird at first but you’ll get used to it. Just make sure your dungeons are 4-way connected! There are some tactical things to consider around this as well, such as pillar dancing on two squares and creating choke points more easily, but these are design elements that can be overcome. Similarly you’ll find ranged combat needs nerfing or visual radius reduced to cope.

An alternative is hex, with QWE/ASD for the 6 directions. I’ll be trying this with Rogue Rage, but I’m not sure yet how well it’ll work. But from a technical point of view hex is the ultimate for all games ;)

Mouse control
Easily and quickly move to another part of the map (with appropriate interruptions for damage or spotting a threat), and right-click for contextual menus to quickly choose available interactions with enemies and items. Or right-click could fire a missile weapon. Mouse control makes a game hugely more accessible without hindering the game’s complexity. ToME4 is a complex game that can be comfortably played with either mouse or keyboard, or a combination. Tooltips also help convey detailed information quickly without forcing the player to read through manuals or help files – most players never read help files or manuals.

Gamepad support
Many players like to plug in an X-Box 360 controller. Make sure your game can be played on few enough buttons for this to work. You don’t have to directly support the input device – there are keyboard mapping programs out there for that which gamers know how to use.

Auto stairs use
A stairs should be treated like a wall square you can see through. Enemies can’t walk on it, items can’t drop on it, and once you bump into it you change level. This removes the need for < and > keys (why are they even separate keys?) without removing any tactical depth. Means stairs need space around them (can’t be in corridors) or need to be in-set in the walls (see Dungeons of Dredmor, where stairs use is made obvious to the player), and player should be placed adjacent to the stair tile when put in a new level. Makes a big difference to new players when they don’t even have to think about using the stairs, it’s just natural. Moving into stairs to use them should be as natural as bumping into doors to open them or moving into monsters to attack them.

No controls requiring shift/ctrl/alt
One reason to get rid of the stairs command… Tell a player to press < and he’ll press the , key, and then wonder why it didn’t work. In a reduced command set there’s no reason to use upper cases or keys on the shift line. Besides, on international keyboards these can be in different places, so might screw up your input in other regions. Stick to simple lower case letters or symbols easily accessible. And don’t over-rely on mnemonics – those who aren’t native English may struggle to understand q for quaff. Better to have commands grouped together in one part of the keyboard (but at a distance from the movement keys).

Use standard controls from computer RPGs
I for inventory is the big obvious one. C for character is also oft-used. Generally the less you have to use the better, but when you want to use keys think of what are the standards outside the genre as well. H for help is probably more standard than ? for instance. W for Wear will confuse many roguelikers, never mind those with little experience. And it's not enough to say "my keys are rebindable, people can do what they want". It's great to have, but very few people rebind keys, so focus on having good defaults.

Pop-up text hints
Both for interface and for gameplay, though you might want an option to turn it off. Especially at the start of the game you should have some text briefly showing the commands. It could be as easy as arrows around the character showing the move key for each direction as a quick lesson/reminder, or a small bar at the bottom of the screen saying “Arrow keys to move, F to Fire, P to Pick up items, H for Help”. But during gameplay this can be useful too, especially when introducing new features or content. If you don’t have auto-stairs use then walking over the stairs might provide a message “Stairs down to Dungeon level 3, press space to descend”. Similar for walking over items (how to pick up), or when picking up items (how to see inventory or equip). Seasoned players might not even notice these messages when they’re used to seeing them, but new players will really appreciate this help.

With ASCII it’s hard to tell what new enemies are, or how powerful they might be. So how about first time an enemy type shows a piece of text appears to say “Crikey, a raging bulbosaurus!” or something similar. Bosses might have more dramatic description to denote their importance.

Space as contextual action
Multiple key commands is useful for fidelity of action, but in 90% of situations there is only one action that can be performed. So let’s use the biggest key on the board for it. Stairs? Space to change level. Item on ground? Space to pick up. Trap? Space to disarm. Door? Space to open/close. There’s situations where this won’t work, but the exceptions shouldn’t get in the way of what would be a much smoother experience for most of the game.

Don’t rely on the game log
People don’t read it, especially if you fill it with lengthy text of “A misses B, B critically hits A” etc. Have characters flash red when hit, or have pop up text above the characters showing damage amounts. Quick, simple feedback for common actions. Keep the players eyes on the game area, and don’t make them have to pick through small text to find what’s important.

Easy Inventory system
Don’t give the player some weird custom inventory with containers and different commands for each slot. Don’t limit their space too much either. Players want freedom and ease of use. Look at how professional games do inventories. Roguelikes aren’t alone in using inventory mechanics yet so many have failed to learn any lessons from decades of game design. For easy to use inventory systems check out ADOM or ToME4, or better yet try to innovate something simpler. Items can be such a core part of many roguelikes that you should give very careful thought to how you’ll use them and how the player can access them easily.

Clarity of mechanics
Don’t hide important stuff from the player and hope that they’ll get it. Make sure your mechanics are clear and understandable. You may have coded a cool system, but if people don’t know what’s going on they won’t understand the subtleties and won’t stick around long enough to enjoy it. This is where watching someone play your game is important. Without giving them advice watch how they interact with the game elements and see how easily they grasp what is going on. Don’t think you can get by on the Nethack style of “players will learn over many years” – you are not making Nethack, nor should you be.

No cheap deaths
By cheap I mean impossible to prepare for. This is especially frustrating early game. Challenge is good and fun, but unavoidable impossible obstacles are not. Traps are the worst for this. Don’t do traps unless they’re interesting.

Tutorial zone
Not many people bother with tutorials, but if they’re having a hard time learning a game it gives them something to turn to. Powder, ToME and Dredmor all have good examples of tutorials to teach specific mechanics. Note that in all 3 you can die in the tutorial – an important lesson to learn in the tutorial as well.

Amusing/entertaining death
Death is bound to happen, and some people find it frustrating. But you can soften the blow by adding a touch of humour. Dredmor has its famous line of “Congratulations! You Have Died!” Limbo has over the top death animations to keep people engaged after many deaths. Think of other ways to make the player laugh, like putting in tortured death screams from the character, or throwing up a short randomly generated story of how the world fell apart after the player’s death. Put out a hook to get the player back in for another game, instead of leaving them feeling bitter and twisted. It doesn’t need to be humorous – you could have random game tips relevant to the death, or small lore revelations; something compelling to keep people interested in the game.

Quick restarting
Make it easy for the player to start again, such as a “Restart Same Character” option on the death screen that repeats the character creation with the same options as last time. “Restart Random” is a good option to have too. Generally your creation menu should be slick and fast anyway, otherwise people will get bored of it on the 100th playthrough.

Small levels
Can help quite a bit, though isn’t necessary. Don’t waste the players time exploring big empty spaces. Have everything densely packed in small levels. Makes it easier on display too, reducing the needs for a minimap. 4-way movement helps with this a bit – it makes the areas effectively twice as big for play moves, letting you pack monsters and items in a tighter screen space. Smaller levels feel quicker to get through, and don’t seem so tiresome to replay after death. Easier for new players to take in as well.

Permadeath optional
Okay, I don’t really like this, but it works well for Dungeons of Dredmor. In it permadeath is on by default, but you have the option of turning it off. Mentally it sets the player thinking that this is the right way for the game to be played, rather than feeling like it’s a crazy design flaw. And they can be proud that they didn’t untick that box, letting them embrace the mechanic rather than be annoyed by it. It’s important to teach that permadeath is a positive thing, not an unfair and punishing difficulty.


--
Darren Grey

[Gerry Quinn]

In article <9e12317d-07be-4e52...@googlegroups.com>,
darrenj...@gmail.com says...

> Well, here?s some points I?ve come to learn about making roguelikes more accessible for non-roguelikers. Most centre around interface, but there are some design considerations too. Feel free to post more in the comments.

I like many of your ideas, not so keen on a few.

> 4-way movement

I don't really like this much as it just feels odd to be so constrained.
Mouse control is the way to go IMO if the arrow keys are felt to be an
issue.

These days laptops are a bit wider and often have numpads, I think - the
one I bought recently has one (tho I had a USB numpad for roguelikes
anyway!)


> Mouse control

I think this is key, nothing makes a game more pick-up and play than
mouse control.


> Gamepad support

But then you lose mouse control, if the latter is more than a substiture
for arrow keys.


> Auto stairs use

I don't like this. It is a constraint on the game too, as stairs must
go both ways. Better to make them prominent, I think, and give a
message when the player is near.


> No controls requiring shift/ctrl/althave

Yes.

> Use standard controls from computer RPGs
> I for inventory is the big obvious one. C for character is also oft-used. Generally the less you have to use the better, but when you want to use keys think of what are the standards outside the genre as well. H for help is probably more standard than ? for instance. W for Wear will confuse many roguelikers, never mind those with little experience. And it's not enough to say "my keys are rebindable, people can do what they want". It's great to have, but very few
people rebind keys, so focus on having good defaults.

Agreed.

> Pop-up text hints

Yes.

> With ASCII it?s hard to tell what new enemies are, or how powerful they might be.

This is an argument for tiles.


> Space as contextual action

Yep. Keep it simple.

[...]

> Permadeath optional

I'm okay with this too. However I favour restarting at the beginning of
a level with a new map, to get the proper roguelike feeling of
exploration. If you are retracing the map you died on so you know
what's there, it's not very roguelike.

- Gerry Quinn

[Jason Pickering]

I still think 4 way keys is they way to go. Because most people do not use he numpad. They go right for the arrows.

Also I think there is a place for auto-use stairs, if there is no reason to go back. The auto use is fine

[Michal Bielinski]

Once upon a time, Darren Grey wrote thus:

> Well, I'm guessing this'll spark a number of disagreements, but I'm
> curious as to what other people have to think or contribute to this.
> I've written this article today and would like to polish it a bit
> more before putting it on RogueBasin. But reflecting on this is as
> much for my own benefit as it is intended to be a guide for others.

Very well. I will say up front I disagree with much of what you wrote.
Pretty please do something about this wretched formatting. It extends
the time I have to devote to writing reply because I have to fix it
first.

> For some this article is irrelevant - they only care about existing

> Roguelike players touching their games.

What a generalisation. Are there *any* developers out there like this?

> All fine and well, but I’d like to see more people enjoying all the
> great games we have around, and in particular I have a goal of making
> the first truly accessible ASCII game. Er, wish me luck :/

Define truly accessible. I fear this might require the game not to be
a roguelike. Interface is not everything to accessibility.

> One problem though – the interface. I’ve watched hardcore gamers try
> out Broken Bottle (which is considered to have a good interface for
> a Roguelike) and they’ve not been able to figure out how to move, or
> how to leave the first level.

I presume hardcore gamers means playing games a lot. Not necessarily
playing difficult games. Otherwise where would you find such people?
I have introduced PRIME to a bunch of university students. Some are
hardcore gamers but most are not. Walking was trivial for all of them.

Leaving first level was not so easy though. Only a portion of them
managed this. Still, PRIME does not tell you how to use stairs at all.

> All the assumptions we have about the interface are completely null
> to them. It’s immensely painful watching someone try to play your
> game and being so unfamiliar with the controls that they move at a
> snail’s pace, and have such trouble with even movement that they
> fail to see the rest of the depth of play.

Agreed with this. On the other hand my experience is different. Maybe
it is caused by my audience? I show roguelikes to students mostly.
After all Rogue also originated in a university. Most troubles people
had was with searching (when that was only exit from a room) and
leaving the level. They quickly got to experiencing the game more.

> 4-way movement
> Ooh, I can hear the traditionalists grinding their teeth already…

I am no traditionalist. I simply dislike pointless constraints.

> But every time I introduce a new person to roguelikes they fail to
> grasp the ability to move in diagonals.

Never observed this. I do mean it. Absolutely not even a single case.

> Years of d-pad or arrow key use has made them think purely of the
> cardinal directions. Also it’s hard to get 8-way movement to work
> nicely on a laptop, whatever crazy shift+direction scheme you might
> invent (and don’t even *think* about forcing vi-keys on players).
> WASD and arrow keys are all outside gamers can cope with.

Among my audience there was a vim user. Guess how we solved problem
of his laptop lacking numeric keyboard? That was a nice surprise for
him. He was amongst the worst score-wise though.

> So stick to 4-way, and let the monsters only move 4-way too. It
> feels weird at first but you’ll get used to it.

I have played POWDER for too long to confirm that. It will continue to
feel weird unless all games you play are like this. This is a minor
annoyance and can be lived with certainly. Unfortunately it never
disappears from my mind and there is this feeling of arbitrary
constraint. Perhaps ability to aim diagonally is the reason for this.

> Just make sure your dungeons are 4-way connected! There are some
> tactical things to consider around this as well, such as pillar
> dancing on two squares and creating choke points more easily, but
> these are design elements that can be overcome. Similarly you’ll
> find ranged combat needs nerfing or visual radius reduced to cope.

A valid point. Changing a major mechanic has to have impact on game.

> An alternative is hex, with QWE/ASD for the 6 directions. I’ll be
> trying this with Rogue Rage, but I’m not sure yet how well it’ll
> work. But from a technical point of view hex is the ultimate for
> all games ;)

Bah. Go 8-way movement with maximum metric. You eliminate all and
every sight/movement artifact you can think of with this.

> Mouse control
> Easily and quickly move to another part of the map (with appropriate
> interruptions for damage or spotting a threat),

A partial auto-explore? Existence of a "need" for such mechanics shows
a design flaw. You should make levels interesting and dangerous enough
to explore manually. Also, you should not make your players travel
across explored levels. Ironman is amongst easiest and most successful
ways to accomplish this.

> and right-click for
> contextual menus to quickly choose available interactions with
> enemies and items.

Nah, it would obscure the screen too much (if one would like to display
really all the possibilities a roguelike game hides) or the font would
be too small.

> Or right-click could fire a missile weapon.

Much more reasonable.

> Mouse control makes a game hugely more accessible without hindering
> the game’s complexity.

If you had omitted the "hugely" word I would be inclined to agree. As it
stands your statement appears to be false.

> ToME4 is a complex game that can be comfortably played with either
> mouse or keyboard, or a combination.

Oh, it can be played with keyboard? So how the mouse is actually even
needed? I'll quit playing straw man here. You simply give too much value
to mouse input. It is nice and all but in no way hugely improves any game.

> Tooltips also help convey detailed information quickly without forcing
> the player to read through manuals or help files – most players never
> read help files or manuals.

Their choice I'd say. I have read whole NetHack guidebook before even
running the game for the very first time. Did you know they tell you
about E-word there? Still, on rgr.nethack it is still considered somewhat
spoily proving your point. Everything one places in manual and readme
should be found in game. Documentation just exposes information in more
friendly form.

> Gamepad support
> Many players like to plug in an X-Box 360 controller. Make sure your
> game can be played on few enough buttons for this to work. You don’t
> have to directly support the input device – there are keyboard mapping
> programs out there for that which gamers know how to use.

Really good point. Fully agreed here.

> Auto stairs use
> A stairs should be treated like a wall square you can see through.
> Enemies can’t walk on it, items can’t drop on it, and once you bump
> into it you change level.

The no-walk and no-item-drop are additional properties that ordinary
walls do not have. So it is much more than a transparent wall.

> This removes the need for < and > keys (why are they even separate
> keys?)

Principle of least commands. These are not keys specially invented for
descension and ascension. These are direction keys for up and down. They
were just reused.

> without removing any tactical depth. Means stairs need space around
> them (can’t be in corridors) or need to be in-set in the walls (see
> Dungeons of Dredmor, where stairs use is made obvious to the player),
> and player should be placed adjacent to the stair tile when put in
> a new level. Makes a big difference to new players when they don’t even
> have to think about using the stairs, it’s just natural. Moving into
> stairs to use them should be as natural as bumping into doors to open
> them or moving into monsters to attack them.

Acceptable solution but requires a substantial game redesign for most
existing roguelikes.

> No controls requiring shift/ctrl/alt
> One reason to get rid of the stairs command…

Does not qualify. For an argument to be good enough to challenge the
assignment of a separate key for down and up it has to do directly with
them. Multi drop is capital D. Lets trash it too!

Your suggestion is good enough to prompt some moving keys around.

> Tell a player to press < and he’ll press the , key, and then wonder
> why it didn’t work.

The don't know how to use the keyboard properly? I don't buy it.

> In a reduced command set there’s no reason to use upper cases or
> keys on the shift line.

Reduced set of commands that are necessary to play and win is fine.
Reduced set of all commands by itself just impoverishes the input
channel of your game. For what? Hide all advanced commands but make
them available. Nobody says OpenOffice writer should remove its
shortcut keys. Or are you?

> Besides, on international keyboards these can be in different places,
> so might screw up your input in other regions. Stick to simple lower
> case letters or symbols easily accessible. And don’t over-rely on
> mnemonics – those who aren’t native English may struggle to understand
> q for quaff. Better to have commands grouped together in one part of
> the keyboard (but at a distance from the movement keys).

Remappable keys take care of most of that. PRIME does a small experiment.
It offers several key maps based on other commonly played roguelike games.
Sadly I have not collected feedback from players how helpful (or not)
it is so cannot comment on whether it is a good thing to do.

> Use standard controls from computer RPGs
> I for inventory is the big obvious one. C for character is also
> oft-used. Generally the less you have to use the better, but when you
> want to use keys think of what are the standards outside the genre as
> well. H for help is probably more standard than ? for instance.

Sure it is. But that sacrifices H! I would wager F1 is even more widely
used so bind help to this and keep H for something that deserves it.

> W for Wear will confuse many roguelikers,

Perhaps you wanted to say non-roguelikers? Very few RLs have W bound to
something else than wield or wear.

> never mind those with little experience. And it's not enough to say
> "my keys are rebindable, people can do what they want".

Mine are! Oh, okay.

> It's great to have, but very few people rebind keys, so focus on
> having good defaults.

Maybe more than one set of defaults.

> Pop-up text hints
> Both for interface and for gameplay, though you might want an option
> to turn it off. Especially at the start of the game you should have
> some text briefly showing the commands. It could be as easy as arrows
> around the character showing the move key for each direction as a
> quick lesson/reminder,

Oh, something like Abura Tan had and newest DoomRL does? Several other
roguelike also implemented this but somehow it never caught on. I think
tutorial is much better.

> or a small bar at the bottom of the screen saying “Arrow keys to move,
> F to Fire, P to Pick up items, H for Help”.

NeoHack has this.

> But during gameplay this can be useful too, especially when
> introducing new features or content. If you don’t have auto-stairs
> use then walking over the stairs might provide a message “Stairs down
> to Dungeon level 3, press space to descend”.

Yes, that is very nice. Here an example from game could be useful.
I seem to recall messages like this being printed in some game but
cannot exactly tell where it was.

> Similar for walking over items (how to pick up), or when picking up
> items (how to see inventory or equip). Seasoned players might not even
> notice these messages when they’re used to seeing them, but new players
> will really appreciate this help.

Be very wary with the part about not noticing. Hints in DoomRL almost
made me quit in frustration. In my opinion information how to turn hints
off should be *the* first hint. Make that doable from the game without
closing it and editing some config file.

> With ASCII it’s hard to tell what new enemies are, or how powerful
> they might be.

This is good. Keep it that way! Tiles are horrible in this regard
because not only they make it hard to tell creature's power rating
but may also confuse you! "This looks like those chickens I killed by
dozens already. Lets whack it! <The cockatrice hisses at you!> ...".

> So how about first time an enemy type shows a piece of text appears
> to say “Crikey, a raging bulbosaurus!” or something similar. Bosses
> might have more dramatic description to denote their importance.

DCSS introduces all monsters by name when you meet them. What you say
was being done in DeadCold and was being annoying from the second
character you played. I recommend against going much more beyond monster
name.

> Space as contextual action

Oh man, I loathe context menus. You have been warned.

> Multiple key commands is useful for fidelity of action, but in 90%
> of situations there is only one action that can be performed.

Who do you want to fool, Darren? 10% tops and even that is way too much.

> So let’s use the biggest key on the board for it. Stairs? Space to
> change level. Item on ground? Space to pick up. Trap? Space to disarm.
> Door? Space to open/close. There’s situations where this won’t work,

Ha! The problem is those situations are far too numerous to list. If they
are not you run into even worse problem. Take DoomRL's doors. Close
command usually targets the only door in your vicinity. Only when there
are more targets to choose. If that happens in a critical situation your
muscle reflexes may be faster than your brain noticing a sudden query.
You have closed like two thousand doors already, why now you need to
point at it? I lost a good character that way.

> but the exceptions shouldn’t get in the way of what would be a much
> smoother experience for most of the game.

They should. By ignoring those you get seemingly better interface but
in reality it becomes ridden with traps.

> Don’t rely on the game log

What I feared most. The game log is integral part of roguelike spirit.
Eliminating it like Cogmind does significantly changes the feel of the
game. I view roguelike games as something closer to the book than to
the movie. In the log lies power to describe events in game in a way
that invites you to imagine them. Make the log less important and you
have less of a roguelike in result.

> People don’t read it, especially if you fill it with lengthy text
> of “A misses B, B critically hits A” etc.

The clutter of messages is a valid concern but nothing that should lead
to dismissal of the log.

> Have characters flash red when hit, or have pop up text above the
> characters showing damage amounts. Quick, simple feedback for common
> actions. Keep the players eyes on the game area, and don’t make them
> have to pick through small text to find what’s important.

Again you direct complaints at badly done log. There is nothing that
would ask not to rely on the log.

> Easy Inventory system

Ouch. All games I work on are guilty of not fulfilling this.

> Don’t give the player some weird custom inventory with containers
> and different commands for each slot.

Yeah! Take out the fun! Also, take out the ability to play at blazing
speeds. Have you seen a veteran NetHack player striding through the
dungeons? He rarely invokes the inventory because he remembers places
of several of his most important tools. Since inventory does not come
up too often suspension of disbelief is maintained better.

ADOM does not assign constant letters to inventory items and it fares
well. However, TB does not exile them. Picking item by letter is a very
fast way to make a choice.

> Don’t limit their space too much either. Players want freedom and
> ease of use. Look at how professional games do inventories.

Or go read some weblog about game development. Much faster and gives
more insights. Also, does not require computer with good hardware.

> Roguelikes aren’t alone in using inventory mechanics yet so many
> have failed to learn any lessons from decades of game design.
> For easy to use inventory systems check out ADOM or ToME4, or better
> yet try to innovate something simpler. Items can be such a core
> part of many roguelikes that you should give very careful thought
> to how you’ll use them and how the player can access them easily.
>

> Clarity of mechanics
> Don’t hide important stuff from the player and hope that they’ll get
> it. Make sure your mechanics are clear and understandable. You may
> have coded a cool system, but if people don’t know what’s going on
> they won’t understand the subtleties and won’t stick around long
> enough to enjoy it.

I think NetHack remains among few offenders. Nowadays roguelikes usually
have transparent mechanics.

> This is where watching someone play your game is important. Without
> giving them advice watch how they interact with the game elements and
> see how easily they grasp what is going on. Don’t think you can get
> by on the Nethack style of “players will learn over many years” – you
> are not making Nethack, nor should you be.

I have been lucky to have someone do Let's Play videos of ZapM which is
PRIME's parent. Also, the people I have gotten to play it are even better
because I could ask "why did you do that?" and receive answer immediately.

> No cheap deaths
> By cheap I mean impossible to prepare for. This is especially
> frustrating early game. Challenge is good and fun, but unavoidable
> impossible obstacles are not.

This paragraph is completely out of place in this document. Not only
this applies equally well to roguelikers and non-roguelikers but the
former will be able to point out unfair deaths much more accurately
than the latter.

> Traps are the worst for this. Don’t do traps unless they’re
> interesting.

Saldy traps are difficult to do right. Either they are harmless and
just annoy the player or too powerful and result in "there was nothing
I could have done to prevent this" moments.

> Tutorial zone
> Not many people bother with tutorials, but if they’re having a hard
> time learning a game it gives them something to turn to. Powder,
> ToME and Dredmor all have good examples of tutorials to teach specific
> mechanics. Note that in all 3 you can die in the tutorial – an
> important lesson to learn in the tutorial as well.

So does Xenocide. It is also possible to die but this requires some
thinking on player's part and is not accompanied with lesson message.

> Amusing/entertaining death

There was a discussion about this at the temple of roguelike. I'll
allow myself to skip responding to this pargraph.

> Quick restarting
> Make it easy for the player to start again, such as a “Restart Same
> Character” option on the death screen that repeats the character
> creation with the same options as last time. “Restart Random” is
> a good option to have too. Generally your creation menu should be
> slick and fast anyway, otherwise people will get bored of it on the
> 100th playthrough.

This also means no quitting after death obviously.

> Small levels
> Can help quite a bit, though isn’t necessary. Don’t waste the
> players time exploring big empty spaces. Have everything densely
> packed in small levels. Makes it easier on display too, reducing
> the needs for a minimap.

I would say large levels densely packed with content and features are
much more interesting tactically while being very fun to explore.
The key here in my opinion is not small levels. It is densely packed
levels. Size is mostly a non-issue.

> 4-way movement helps with this a bit – it makes the areas effectively
> twice as big for play moves, letting you pack monsters and items
> in a tighter screen space.

True only in melee oriented game. In ranged combat heavy games it just
makes feel you slower. Not very fun.

> Permadeath optional
> Okay, I don’t really like this, but it works well for Dungeons of
> Dredmor. In it permadeath is on by default, but you have the option
> of turning it off. Mentally it sets the player thinking that this
> is the right way for the game to be played, rather than feeling like
> it’s a crazy design flaw. And they can be proud that they didn’t
> untick that box, letting them embrace the mechanic rather than be
> annoyed by it.

Decker did it too by having ironman box to tick. Not sure if it was
on by default. Optional permadeath has all the sad consequences of
save-scumming and can ruin the game for players. I deem it as my
obligation as a game developer to prevent that because I know how
my game was designed. It should be made possible but not in a way
that I make anything to hint it is designed like that. Developers
ought to tell how is the intended way of playing the game and then
allow players to play any way they please.

In Dungeons of Dredmor permadeath feels not like the way the game should
be played. It feels like equally valid way of playing the game which
is endorsed by the developers. This is my gripe with making permadeath
a check box.

--
Michał Bieliński

[Radomir Dopieralski]

On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:

[snip]

Would you be so nice and follow the netiquette by wrapping your posts
at less than 80 characters per line?

I will be eternally grateful, thank you.
--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Friday, June 8, 2012 9:01:22 AM UTC+1, Radomir Dopieralski wrote:

> On 2012-06-06, Darren Grey wrote:
>
> [snip]
>
> Would you be so nice and follow the netiquette by wrapping your posts
> at less than 80 characters per line?
>
> I will be eternally grateful, thank you.

I apologise - Google Groups has stupidly mangled my post. In future I will endeavour to earn your eternal gratitude :)

--
Darren Grey

[Darren Grey]

<snip>

Repost with appropriate line wrapping! Also I should probably note that
I've used far too authoratitive a tone in this for what is after all a
subjective piece meant to provide many alternative guidelines that can be
picked and chosen from at will.

[Darren Grey]

On Thursday, June 7, 2012 8:13:32 PM UTC+1, Gerry Quinn wrote:
> In article <9e12317d-07be-4e52...@googlegroups.com>,
> darrenj...@gmail.com says...
>

> I like many of your ideas, not so keen on a few.

To be expected! I'm not that keen on many of the points myself, but they are useful thought pieces. I wrote the article as a reflection for myself more than anything.

> > 4-way movement
>
> I don't really like this much as it just feels odd to be so constrained.
> Mouse control is the way to go IMO if the arrow keys are felt to be an
> issue.
>
> These days laptops are a bit wider and often have numpads, I think - the
> one I bought recently has one (tho I had a USB numpad for roguelikes
> anyway!)

Alas, all too rare! Especially with all these netbooks and the like about these days. Plus even when there is a numpad many will by default use just the arrow keys. Odd though it seems getting people to make proper use of the numpad can be as difficult as teaching them vi-keys. They can pick it up, but it takes a while for it to become anything close to natural feeling. Arrow keys on the other hand are instantly accessible.

4-way is... well, not ideal. It does have a constrained feeling. Perhaps the solution is an option like Hydra Slayer to have both 4 and 8 way controls (with mechanics like range and LOS changed to suit), having it 4-way by default.

On the other hand if we all used 4-way all the time I doubt we'd notice the difference.

> > Gamepad support
>
> But then you lose mouse control, if the latter is more than a substiture
> for arrow keys.

What's wrong with both? A game shouldn't be exclusively mouse controlled. Key commands are far faster in many circumstances.

> > Auto stairs use
>
> I don't like this. It is a constraint on the game too, as stairs must
> go both ways. Better to make them prominent, I think, and give a
> message when the player is near.

Must go both ways? How does auto-use contrain that? Look at Dungeons of Dredmor - you walk into the up stairs, you move up a level. Same with down stairs. It's easy, intuitive, and doesn't take anything away from the game. Stairs abuse is too easy in the game, but many roguelikes suffer from that.

> > With ASCII it?s hard to tell what new enemies are, or how powerful they might be.
>
> This is an argument for tiles.

Tiles can be just as bad. Plus for many getting good tiles just isn't an option.

There are ways for ASCII to be done right and still be playable - clear colour contrasts, restricted symbol use, separating power levels by case, etc.

> > Permadeath optional
>
> I'm okay with this too. However I favour restarting at the beginning of
> a level with a new map, to get the proper roguelike feeling of
> exploration. If you are retracing the map you died on so you know
> what's there, it's not very roguelike.

If you restart with the map unexplored but with all items and character progression intact then it actively encourages dying near the end of a level to scum more stuff. Some set-back on death is still good, but it has to be managed carefully to make sure it isn't encouraging bad behaviours.

--
Darren Grey

[Darren Grey]

On Friday, June 8, 2012 9:58:05 AM UTC+1, Darren Grey wrote:

> I apologise - Google Groups has stupidly mangled my post. In future I will endeavour to earn your eternal gratitude :)

Hmph, and I immediately fail. Google Groups majorly sucks :(

Anyone know of alternative web clients that make USENET usable?

--
Darren Grey

[JO]

---Okay Darren I'm up on my night off drinking terrible beer and wine,
pirating movies and just generally being a fat ass. So take this
advice in stride...---

Darren, I do think you've got a few good ideas about bringing
Roguelike design philosophy and depth to the masses. I do have some
comments (Don't I always). I think I have some insight because I do
most of my gaming with a game group. I have multiple max level WoW
characters, I am a fair Modern Warfare player (3 stars on all the spec
ops missions, co-op with my buddy, in MW2) and I play the holy shit
out of some Rock Band (I sing and guitar simultaneously...yeah, I'm
that guy). I only do roguelikes when I play by myself, and even then
half the time I'm rocking my emulator and some old school hard mode
(Been trying to beat Ninja Gaiden for like 20 years).

So I think I have some perspective to give.

First of all. ANY text game is going to turn off players. I'm sorry to
say this. Very sorry. I can't get my 'hard core' gamer friends to even
look at Brogue. Ever. Not for a second. Never going to happen. If you
prove me wrong I will tattoo a huge '@' symbol on my face. It sorta
looks like a face anyway....but you don't actually need the ASCII. I
prefer it now after playing for so long (and seeing brogue), but if
you want a non RL player to play you gotta have ANIMATED TILES. See
Cardinal Quest for how basic it can be, see TOME for how beautiful.
But if TOME is going to truly cross over it needs animation. Dwarf
Fortress players be damned, that's the major exception not the rule.

4 way movement is a must. I have no idea why there is resistance to
this. I prefer it. I play ALL roguelikes with the arrow keys. I
couldn't even play PRIME until the arrows were implemented (I actually
did it myself). Maybe that's why I suck so hard at roguelikes? I
dunno. For non-roguelike players 4 direction movement is not even a
question. 4 way is not even noticed as any kind of issue. Only
roguelike players, and old school ones, really care about it. When I
see fools whining about 4 vs 8 way I just roll my eyes. Get over it
man. [Watch some guy respond with 5+ reasons why diagonals are more
strategic. Barf].

Hexes...I realize you are hard up for hexes right now. I follow the
podcasts and your work more closely than I'd like to admit. HEXES!!!
T-ENGINE!!! ROGUEHEX RAGE!!! LOL! I'm just funning around. I think
hexes (and the T-ENGINE) are a great way to 'spaciate' a game. But
think about it. In D&D and ALL other games underground stuff is
handled with squares. That's just the way it is. If you go hex you
will turn non-roguelikers off when going underground. Name one top
down RPG game that uses hexes. One. Anyone. Here are some that use 4
way. Dragon Warrior. Final Fantasy. Zelda. Ultima. Destiny of an
Emperor (i dug it). Chronotrigger. Lufia.

The only games that really use hexes are turn based wargames. Panzer
General and Battle for Wesnoth type games. And don't even get me
started on trying to use keys for hex movement. Do you seriously think
anyone will adapt to that? VI keys have been around for decades. You
are a roguelike player. How are your VI skills? Shitty? Mine too. And
I've been playing, off and on, Hack and Nethack since 1988.

It goes without saying that if you want to go HEX you absolutely have
to have a mouse interface. For everything. Having hot keys is fine,
but if you want a turn based game with hexes it has to be all mouse
all the time. Not mouse as an after thought, but mouse primarily. Shit
you don't even need keys. Look at Battle for Wesnoth for his. That's a
good interface.

Generally, for any turn based game that wishes to break out, you need
a mouse interface. I tried a bit of a hybrid with my recent SUN
CRUSHER!!! game. It was turn based, WASD to move and mouse to point
and shoot. A turn based shooter...say what you will about the game
overall but the interface was exactly what i had planned. A WASD +
Mouse shooter interface pasted onto a turn based game. I'm pretty sure
you, Darren, saw the failed experiment. Which is cool. Now we know.
Mouse only in turnbased, it's the only way I've seen a successful
design work.

As for gamepads I made this mistake very early on. I cannot even
remember now what game it was, but very soon I realized some things.
A) very few people have computer compatible gamepads and B) even
people with gamepads will be too lazy to plug them in and C) those
that own gamepads and love them will figure out how to use them.
Binding of Isaac did this best. "Joystick Support: Use Joytokey,
google it." I laughed when I saw that. Because he has it correct. No
need to support or worry about joystickers, they figure it out on
their own. They figure it out way better than you could ever support.
Talk to Legend about this. He's a joysticker. Plays that Cthulu game
with a gamepad if I'm not mistaken. Which leads me to the next
thing...

Roguelikers are huge freakin' weirdos. If it's not Legend playing turn
based computer games with a gamepad or me dual boxing WoW with one
hand holding an SNES controller and the other a mouse is really the
height of eccentric. No. We are ALL eccentric compared to other
gamers. When people talk about us being elite snobs they are generally
right. The roguelike world is not mainstream, only when it has been
totally adulterated can it become mainstream. Isaac, Dredmore and
Diablo diverge a TON from what we have grown to love. They have to.
Straight ASCII, keyboard controlled, permadeath, super hard, super
complex and tons of reading is just never going to be popular. It's
like poetry. Who the fuck reads poetry? Only poetry nerds. But
everyone likes songs, which include elements of poetry.

Stairs: Ido said something on the podcast awhile back about bumping
being the primary move in roguelikes. You walk onto the stairs you
ascend or descend accordingly. No need to spawn next to the stairs.
Let the character spawn on the stairs. No biggie. It's the act of
moving onto, or bumping, that's important. See Zelda for the perfect
way to do this. As an aside; if you are making a top down game and
have not learned the lessons of Zelda then you are just being
willfully ignorant. Play the game. Learn why it was great. PLEASE!!!!!

No commands requiring shift or control keys? Make sure you use keys
common to the RPG genre? The fact that you even felt the need to write
that leads me to think it's not obvious to you, or others. Also you
are dead freakin' wrong. It should have read thus..."No commands
should require keys." Show me one turn based game that required a key
press. Don't tell me about hot keys. Name one successful game (as in
commercially successful) that required keys to play. Name one turn
based game, played by the masses, that couldn't be played via mouse
only. If you dig up something from 20 years ago I've never heard of to
refute my point I will consider my point well made.

Text descriptions of monsters? Look...if you really want to go ascii
you at least have to list the monsters in view on the side and let
people click on them to get info. If you want to appeal to non-
roguelike players you wouldn't be using ascii. But if you wanted to
use ascii please don't also ask people to read a bunch of scrolling
text. Especially if that text is really important. This may be my
personal bias. I skip through all text in a game. I'm a mechanics and
'show me' player.

Inventory: Point, click, drag. Nothing else will do.

Restarting: As soon as you die a pop up menu comes up. with 3 options,
"RESTART", "QUIT" and "SEE OBITUARY". Put a little blurb and head
stone graphic in, like, here lies Captain Darren Grey, Felled by
Hubris and Poison. But you can click on restart immediately and jump
right back in to the action without several annoying screens that seem
like playing but aren't. I like how Brogue used to do it. You just
start right in the dungeon, no fuss no mess. BAM, time to game. Now
there's a menu screen...lame.

Small levels are generally good because it gives players something to
beat and something new in quick succession.

Permadeath: Whether it's good for your game or not depends on how
quickly it happens, how long the game is, how quickly you can restart
(do you have to pick a new race, class, name, weapon) and especially
how varied a start can you give the player? Many games fail at this.
Is the first level lava caves? Dwarven gold caves? Limestone caverns
eroded? The kings dungeon? The Goblin King's Dungeon? If each game is
short and starts out interesting it's okay to fail over and over
because each game is so very different and fun. Modern games don't do
this though. They want their characters to live and they want hard
work to be done easily. They create many hours of content meant to
just be 'gotten through.' Everyone can get through, it's prospering
that is hard.

So in the end the key is to include the awesome bits and toss the
fringe bits, thus bringing the masses just a bit of gaming
enlightenment.

[Darren Grey]

On Thursday, June 7, 2012 11:46:27 PM UTC+1, Michal Bielinski wrote:
> Once upon a time, Darren Grey wrote thus:
> > Well, I'm guessing this'll spark a number of disagreements, but I'm
> > curious as to what other people have to think or contribute to this.
> > I've written this article today and would like to polish it a bit
> > more before putting it on RogueBasin. But reflecting on this is as
> > much for my own benefit as it is intended to be a guide for others.
>
> Very well. I will say up front I disagree with much of what you wrote.
> Pretty please do something about this wretched formatting. It extends
> the time I have to devote to writing reply because I have to fix it
> first.

Sorry sorry :( You don't disagree with all that much I must say.
Plus open debate is all well and good :)

> > For some this article is irrelevant - they only care about existing
> > Roguelike players touching their games.
>
> What a generalisation. Are there *any* developers out there like this?

Krice ;) Plus there is an attitude amongst some of "If you don't
bother to learn the controls you don't deserve to play my game". I've
seen this in specific response to this article. It's something I
disagree with, but every dev can have their own perogative.

But more than that you have to consider that if you're not going out
of your way to consider accessibility and all you do is follow the
genre's conventions then essentially you are just making games for
existing roguelike players.

> > All fine and well, but I’d like to see more people enjoying all the
> > great games we have around, and in particular I have a goal of making
> > the first truly accessible ASCII game. Er, wish me luck :/
>
> Define truly accessible. I fear this might require the game not to be
> a roguelike. Interface is not everything to accessibility.

"Pick up and play" is what I define as truly accessible. Mechanics will
take some learning, but the controls will be automatic and intuitive.

> > One problem though – the interface. I’ve watched hardcore gamers try
> > out Broken Bottle (which is considered to have a good interface for
> > a Roguelike) and they’ve not been able to figure out how to move, or
> > how to leave the first level.
>
> I presume hardcore gamers means playing games a lot. Not necessarily
> playing difficult games. Otherwise where would you find such people?
> I have introduced PRIME to a bunch of university students. Some are
> hardcore gamers but most are not. Walking was trivial for all of them.
>
> Leaving first level was not so easy though. Only a portion of them
> managed this. Still, PRIME does not tell you how to use stairs at all.

Interesting... My hardcore includes other indie devs, and people who
play the likes of Dark Souls gladly. I've not witnessed anyone without
roguelike experience for whom walking was trivial. Plenty managed
basic 4-way just fine, and some picked up 8-way after a while, but it
was never trivial.

And stairs... yeah, Jesus, no one gets stairs :(

> > All the assumptions we have about the interface are completely null
> > to them. It’s immensely painful watching someone try to play your
> > game and being so unfamiliar with the controls that they move at a
> > snail’s pace, and have such trouble with even movement that they
> > fail to see the rest of the depth of play.
>
> Agreed with this. On the other hand my experience is different. Maybe
> it is caused by my audience? I show roguelikes to students mostly.
> After all Rogue also originated in a university. Most troubles people
> had was with searching (when that was only exit from a room) and
> leaving the level. They quickly got to experiencing the game more.

What sort of students? I don't know why your experience has been
better. Oh, and was it on a normal computer or a laptop?

> > 4-way movement
> > Ooh, I can hear the traditionalists grinding their teeth already…
>
> I am no traditionalist. I simply dislike pointless constraints.

If you view it as a constraint... And importantly, how much of a
constraint? Does it really make that much difference?

A lot of people moaned about Dredmor only having 4-way movement.
It was... well, stupid. What would diagonal movement add to the game?
The game was designed around 4-way movement and worked just fine like
that. The people arguing were seeing it as a constraint rather than
accepting it as part of the game design.

I'm not a big fan of 4-way, but I think it's important not to dismiss
it out of hand. It's an alternative design that produces different
gameplay and design consideration, nothing more or less. Make the
game content compelling and the game options more interesting than
choosing between north and north-west movement.

Perhaps one option for making 8-way clear is to have a red outline
or shading on all available moves, a bit like how various tactical
games use when moving units. Would have to be something you could
turn off, of course...

> > Years of d-pad or arrow key use has made them think purely of the
> > cardinal directions. Also it’s hard to get 8-way movement to work
> > nicely on a laptop, whatever crazy shift+direction scheme you might
> > invent (and don’t even *think* about forcing vi-keys on players).
> > WASD and arrow keys are all outside gamers can cope with.
>
> Among my audience there was a vim user. Guess how we solved problem
> of his laptop lacking numeric keyboard? That was a nice surprise for
> him. He was amongst the worst score-wise though.

Well, you clearly had an unnatural group then ;)

> > An alternative is hex, with QWE/ASD for the 6 directions. I’ll be
> > trying this with Rogue Rage, but I’m not sure yet how well it’ll
> > work. But from a technical point of view hex is the ultimate for
> > all games ;)
>
> Bah. Go 8-way movement with maximum metric. You eliminate all and
> every sight/movement artifact you can think of with this.

You absolutely do not! How often have there been stupid threads on
here about making diagonal movement cost 1.4 turns? And the Square
LOS considerations to boot. 8-way doesn't make geometric sense.
But it's a game, so that's fine. But ah, hex! How gloriously
elegant all systems are in hex! I spit on your inferior 8-way :P

> > Mouse control
> > Easily and quickly move to another part of the map (with appropriate
> > interruptions for damage or spotting a threat),
>
> A partial auto-explore? Existence of a "need" for such mechanics shows
> a design flaw. You should make levels interesting and dangerous enough
> to explore manually. Also, you should not make your players travel
> across explored levels. Ironman is amongst easiest and most successful
> ways to accomplish this.

It's not meant as a partial auto-explore, but an easy way to move
several spaces with a single command, letting the computer calculate
the optimal route inbetween. And even apart from that you can have
clicking turn by turn to give an alternative input mechanism. It
helps with the laptop problem a little bit (though not much since
trackpads also suck).

> > and right-click for
> > contextual menus to quickly choose available interactions with
> > enemies and items.
>
> Nah, it would obscure the screen too much (if one would like to display
> really all the possibilities a roguelike game hides) or the font would
> be too small.

I don't get what you mean by obscure the screen? I mean context menus
like in ToME, where right-clicking on an enemies pops up a list of
available actions. Consider in a game being able to go into your
inventory, right click on an arrow pile, choose "equip and fire" and it
then equipping them and setting you straight into targetting mode to
click on an enemy.

If the list gets too long make it scrollable. Makes the default
action appear at the top (attack enemy, eat food, read scroll, etc).
Maybe left-click or double click would result in using that default
action.

There's a lot that can be done with mouse commands.

> > Mouse control makes a game hugely more accessible without hindering
> > the game’s complexity.
>
> If you had omitted the "hugely" word I would be inclined to agree. As it
> stands your statement appears to be false.

Everyone knows how to use the mouse. There's very little interface
teaching involved. There are also easy standards to be picked up from
other games with mouse usage. The fact that few roguelikes use mouse
is in a way an advantage - there are less traditions from the genre to
be followed when implementing them.

Of course mouse useage should ideally not be required. There are many
advantages to keyboard only control that it would be a shame to lose.

> > ToME4 is a complex game that can be comfortably played with either
> > mouse or keyboard, or a combination.
>
> Oh, it can be played with keyboard? So how the mouse is actually even
> needed? I'll quit playing straw man here. You simply give too much value
> to mouse input. It is nice and all but in no way hugely improves any game.

Playing with just the mouse in ToME is a dream. There are all sorts of
great customisations you can implement, like binding your most used spell
or ability to left click, so clicking on an enemy triggers that when
available (but defaults to attack or move towards otherwise). It speeds
up a lot of play. There are also mouse gestures configurable for favoured
commands. Plus you can play the whole game with one hand, not even
needing to move that hand much. Optimal play for me is a mixture of both
keyboard and mouse (numpad is nicer for movement) but the interface is
vastly improved by mouse control.

Same for Dredmor. Aiming ranged attacks is so much easier with the mouse.
So is moving items between inventory, dungeon and equipment window. And
tooltips help a lot with learning details of items, skills and enemies,
without having to go to a separate screen all the time or memorise a lot
of data.

> > Tooltips also help convey detailed information quickly without forcing
> > the player to read through manuals or help files – most players never
> > read help files or manuals.
>
> Their choice I'd say. I have read whole NetHack guidebook before even
> running the game for the very first time. Did you know they tell you
> about E-word there? Still, on rgr.nethack it is still considered somewhat
> spoily proving your point. Everything one places in manual and readme
> should be found in game. Documentation just exposes information in more
> friendly form.

I read the whole ADOM manual before ever playing the game. It was one of
the things that drew me in. I'm not sure I'd do the same for many games
these days though. Why should I read through the manual if I don't know
if I'll enjoy the game yet? Good documentation is still important of
course, but don't rely on all players making use of it. Modern gamers
especially are used to forced tutorials (ugh!) and hand-holding in new
games. They are conditioned not to read such materials, or to even expect
them to exist.

> > Auto stairs use
> > A stairs should be treated like a wall square you can see through.
> > Enemies can’t walk on it, items can’t drop on it, and once you bump
> > into it you change level.
>
> The no-walk and no-item-drop are additional properties that ordinary
> walls do not have. So it is much more than a transparent wall.

Well, depends on the game, but true. I wasn't suggesting it be an
ordinary wall of course, just to rethink the idea that it should be
like a floor tile. Why is a hole in the ground or a rising stairwell
treated like as just a common flat space with an added escape element?
It makes just as much sense (if not more) for it to impossible to
walk over. It doesn't negatively impact on the game rules, though of
course due consideration in design must be made.

Put another way, if Rogue had done it like this then every roguelike
since would have still copied it.

> > without removing any tactical depth. Means stairs need space around
> > them (can’t be in corridors) or need to be in-set in the walls (see
> > Dungeons of Dredmor, where stairs use is made obvious to the player),
> > and player should be placed adjacent to the stair tile when put in
> > a new level. Makes a big difference to new players when they don’t even
> > have to think about using the stairs, it’s just natural. Moving into
> > stairs to use them should be as natural as bumping into doors to open
> > them or moving into monsters to attack them.
>
> Acceptable solution but requires a substantial game redesign for most
> existing roguelikes.

Really? Make sure stairs can be pathed around is the main
consideration, and that's not hard. Player placement on level change
is another, but many roguelikes already have this with monster following.
It's a pretty minor redesign from my perspective.

> > Tell a player to press < and he’ll press the , key, and then wonder
> > why it didn’t work.
>
> The don't know how to use the keyboard properly? I don't buy it.

Maybe I should change to title to "How to Make Roguelikes Playable for
Idiots" ;) Honestly, I have seen this! Multiple times!

> > In a reduced command set there’s no reason to use upper cases or
> > keys on the shift line.
>
> Reduced set of commands that are necessary to play and win is fine.
> Reduced set of all commands by itself just impoverishes the input
> channel of your game. For what? Hide all advanced commands but make
> them available. Nobody says OpenOffice writer should remove its
> shortcut keys. Or are you?

Hmm, valid point - advanced commands for experienced users can be
very handy. I guess I should say all core commands instead. And help
files of commands should split the core commands and advanced commands
to make it clear to new users that you can play with just the base
set (unlike ADOM's list of commands which is almost unusable).

> > Besides, on international keyboards these can be in different places,
> > so might screw up your input in other regions. Stick to simple lower
> > case letters or symbols easily accessible. And don’t over-rely on
> > mnemonics – those who aren’t native English may struggle to understand
> > q for quaff. Better to have commands grouped together in one part of
> > the keyboard (but at a distance from the movement keys).
>
> Remappable keys take care of most of that. PRIME does a small experiment.
> It offers several key maps based on other commonly played roguelike games.
> Sadly I have not collected feedback from players how helpful (or not)
> it is so cannot comment on whether it is a good thing to do.

I think it's a good thing, just be mindful that 90% of players will
likely stick with the default. Another possibility is duplicate keys -
having both g and p for get/pick up for instance. I don't like it much
as a designer, but it can be handy when there are multiple standards
around. The classic use of this is having both vi-keys and numpad as
available move inputs.

> > Use standard controls from computer RPGs
> > I for inventory is the big obvious one. C for character is also
> > oft-used. Generally the less you have to use the better, but when you
> > want to use keys think of what are the standards outside the genre as
> > well. H for help is probably more standard than ? for instance.
>
> Sure it is. But that sacrifices H! I would wager F1 is even more widely
> used so bind help to this and keep H for something that deserves it.

Like vi keys? :) Yeah, F1 may be better. I'm not sure what the
standard is these days in mainsteam games.

> > W for Wear will confuse many roguelikers,
>
> Perhaps you wanted to say non-roguelikers? Very few RLs have W bound to
> something else than wield or wear.

No, I meant roguelikers. With a background in ADOM I am always
flummuxed by games with Nethack-esque inventory systems.

> > Pop-up text hints
> > Both for interface and for gameplay, though you might want an option
> > to turn it off. Especially at the start of the game you should have
> > some text briefly showing the commands. It could be as easy as arrows
> > around the character showing the move key for each direction as a
> > quick lesson/reminder,
>
> Oh, something like Abura Tan had and newest DoomRL does? Several other
> roguelike also implemented this but somehow it never caught on. I think
> tutorial is much better.

Tutorial is more needed for a bigger game, I think. But the optional or
one-off hints are better for smaller games. Works especially well in
7DRLs where you're not sure what defaults the designer is working from.

> > But during gameplay this can be useful too, especially when
> > introducing new features or content. If you don’t have auto-stairs
> > use then walking over the stairs might provide a message “Stairs down
> > to Dungeon level 3, press space to descend”.
>
> Yes, that is very nice. Here an example from game could be useful.
> I seem to recall messages like this being printed in some game but
> cannot exactly tell where it was.

I'm sure I've seen some 7DRLs with this... but none specifically
spring to mind. I find the beauty of a system like this is that you
don't even notice or remember it much - it's just a natural background
part of the game that doesn't take away from the immersion.

You have a good point that examples would make this whole article
much better.

> > Similar for walking over items (how to pick up), or when picking up
> > items (how to see inventory or equip). Seasoned players might not even
> > notice these messages when they’re used to seeing them, but new players
> > will really appreciate this help.
>
> Be very wary with the part about not noticing. Hints in DoomRL almost
> made me quit in frustration. In my opinion information how to turn hints
> off should be *the* first hint. Make that doable from the game without
> closing it and editing some config file.

Yes, good point. Partly it's down to how verbose and intrusive the
messages are. Pop-up boxes with an "OK" confirmation are the worst thing
possible :( But saying in the log "Your clip is empty (R to reload)" is
very unobtrusive.

> > With ASCII it’s hard to tell what new enemies are, or how powerful
> > they might be.
>
> This is good. Keep it that way! Tiles are horrible in this regard
> because not only they make it hard to tell creature's power rating
> but may also confuse you! "This looks like those chickens I killed by
> dozens already. Lets whack it! <The cockatrice hisses at you!> ...".

Haha, yes. Plus tiles are generally fugly. Some considerations for
ASCII though:

- Make weaker enemies or ones with no special abilities lower case
- Make very special enemies symbols (& for intance)
- Restrain use of the colour palette, with particularly weird colours (magenta, cyan) used for rare and intersting creatures
- Gives bosses or superpowerful enemies a background colour

> > So how about first time an enemy type shows a piece of text appears
> > to say “Crikey, a raging bulbosaurus!” or something similar. Bosses
> > might have more dramatic description to denote their importance.
>
> DCSS introduces all monsters by name when you meet them. What you say
> was being done in DeadCold and was being annoying from the second
> character you played. I recommend against going much more beyond monster
> name.

It should be stored across games so you never see the same notification
twice.

Of course tooltips make such a system irrelevant.

> > So let’s use the biggest key on the board for it. Stairs? Space to
> > change level. Item on ground? Space to pick up. Trap? Space to disarm.
> > Door? Space to open/close. There’s situations where this won’t work,
>
> Ha! The problem is those situations are far too numerous to list. If they
> are not you run into even worse problem. Take DoomRL's doors. Close
> command usually targets the only door in your vicinity. Only when there
> are more targets to choose. If that happens in a critical situation your
> muscle reflexes may be faster than your brain noticing a sudden query.
> You have closed like two thousand doors already, why now you need to
> point at it? I lost a good character that way.

Hmm, muscle memory is a valid point. I've had similar problems in ADOM
but never a death from it. And I always view it as my fault. Plus I
remember the pain of having to always choose which damn door in earlier
versions. I'll gladly take the context over the rigmarole of specifying
obvious details in every circumstance.

> > but the exceptions shouldn’t get in the way of what would be a much
> > smoother experience for most of the game.
>
> They should. By ignoring those you get seemingly better interface but
> in reality it becomes ridden with traps.

I disagree. But I guess that's where options come in :) ADOM has its
auto-select doors as an option you can disable. I'm not aware of any
that have it disabled though...

> > Don’t rely on the game log
>
> What I feared most. The game log is integral part of roguelike spirit.
> Eliminating it like Cogmind does significantly changes the feel of the
> game. I view roguelike games as something closer to the book than to
> the movie. In the log lies power to describe events in game in a way
> that invites you to imagine them. Make the log less important and you
> have less of a roguelike in result.

I didn't say dismiss, I said don't rely. Of course if you have a
*good* game log it's not as much of a problem. Part of making the log
good is getting rid of the chaff like the hit and miss notifications.
Restrict the log to important things and it becomes more noticed.
Use contextual and quick feedback for the common things that tend to
fill up the log with repetitive lines. The log should not be used to
communicate every petty detail to the player.

> > Easy Inventory system
>
> Ouch. All games I work on are guilty of not fulfilling this.

How very true! But roguelikes tend to be especially bad :)

> > Don’t give the player some weird custom inventory with containers
> > and different commands for each slot.
>
> Yeah! Take out the fun! Also, take out the ability to play at blazing
> speeds. Have you seen a veteran NetHack player striding through the
> dungeons? He rarely invokes the inventory because he remembers places
> of several of his most important tools. Since inventory does not come
> up too often suspension of disbelief is maintained better.
>
> ADOM does not assign constant letters to inventory items and it fares
> well. However, TB does not exile them. Picking item by letter is a very
> fast way to make a choice.

The article is about attracting new people, not catering for the old.
Of course when it comes to proper design you have to consider how you
want to balance between the two. ADOM has a nice balance in its
inventory system in my opinion. Nethack is just unplayable to me.
Some people may be used to it and enjoy it, but I have lots of other
good roguelikes I can play instead of forcing myself through the
pain of getting used to its system.

> > Don’t limit their space too much either. Players want freedom and
> > ease of use. Look at how professional games do inventories.
>
> Or go read some weblog about game development. Much faster and gives
> more insights. Also, does not require computer with good hardware.

Well, I said look at, not play. Youtube works :)

> > Clarity of mechanics
> > Don’t hide important stuff from the player and hope that they’ll get
> > it. Make sure your mechanics are clear and understandable. You may
> > have coded a cool system, but if people don’t know what’s going on
> > they won’t understand the subtleties and won’t stick around long
> > enough to enjoy it.
>
> I think NetHack remains among few offenders. Nowadays roguelikes usually
> have transparent mechanics.

Yes, but it bears reminding :) I've played many 7DRLs with obscure
mechanics, which seems the absolute worst place to have them since few
will replay the game often. The biggest offender is in item mechanics,
with weapons and armour not showing their power and special items not
saying at all what they do.

> > This is where watching someone play your game is important. Without
> > giving them advice watch how they interact with the game elements and
> > see how easily they grasp what is going on. Don’t think you can get
> > by on the Nethack style of “players will learn over many years” – you
> > are not making Nethack, nor should you be.
>
> I have been lucky to have someone do Let's Play videos of ZapM which is
> PRIME's parent. Also, the people I have gotten to play it are even better
> because I could ask "why did you do that?" and receive answer immediately.

Yeah, these things help a lot. Watching over someone's shoulder is best
I find. I had Broken Bottle on show at an Indie Games Expo last weekend,
which was especially revealing since it had people in who didn't exactly
choose to play the game (someone in a Let's Play is bound to keep on at
a game for a few minutes rather than quit in frustration, after all).

> > No cheap deaths
> > By cheap I mean impossible to prepare for. This is especially
> > frustrating early game. Challenge is good and fun, but unavoidable
> > impossible obstacles are not.
>
> This paragraph is completely out of place in this document. Not only
> this applies equally well to roguelikers and non-roguelikers but the
> former will be able to point out unfair deaths much more accurately
> than the latter.

True. I should have specificed "early game deaths" more. A cheap
game death can put off a new player permanently. Roguelikers are a
bit more used to this and willing to put in more persistance.

> > Traps are the worst for this. Don’t do traps unless they’re
> > interesting.
>
> Saldy traps are difficult to do right. Either they are harmless and
> just annoy the player or too powerful and result in "there was nothing
> I could have done to prevent this" moments.

Yep! Only game with compelling traps is Dredmor in my experience,
since you can use them as a resource against enemies.

> > Quick restarting
> > Make it easy for the player to start again, such as a “Restart Same
> > Character” option on the death screen that repeats the character
> > creation with the same options as last time. “Restart Random” is
> > a good option to have too. Generally your creation menu should be
> > slick and fast anyway, otherwise people will get bored of it on the
> > 100th playthrough.
>
> This also means no quitting after death obviously.

Heh, that's one way to keep a player hooked.

> > Small levels
> > Can help quite a bit, though isn’t necessary. Don’t waste the
> > players time exploring big empty spaces. Have everything densely
> > packed in small levels. Makes it easier on display too, reducing
> > the needs for a minimap.
>
> I would say large levels densely packed with content and features are
> much more interesting tactically while being very fun to explore.
> The key here in my opinion is not small levels. It is densely packed
> levels. Size is mostly a non-issue.

Both, I'd say. In respect of new players I think small levels lets
them get to new floors quicker, giving a sense of progress. It also
doesn't take anything away from the game if done right.

> > 4-way movement helps with this a bit – it makes the areas effectively
> > twice as big for play moves, letting you pack monsters and items
> > in a tighter screen space.
>
> True only in melee oriented game. In ranged combat heavy games it just
> makes feel you slower. Not very fun.

Oh? I've never felt that with Powder.

> > Permadeath optional
> > Okay, I don’t really like this, but it works well for Dungeons of
> > Dredmor. In it permadeath is on by default, but you have the option
> > of turning it off. Mentally it sets the player thinking that this
> > is the right way for the game to be played, rather than feeling like
> > it’s a crazy design flaw. And they can be proud that they didn’t
> > untick that box, letting them embrace the mechanic rather than be
> > annoyed by it.
>
> Decker did it too by having ironman box to tick. Not sure if it was
> on by default. Optional permadeath has all the sad consequences of
> save-scumming and can ruin the game for players. I deem it as my
> obligation as a game developer to prevent that because I know how
> my game was designed. It should be made possible but not in a way
> that I make anything to hint it is designed like that. Developers
> ought to tell how is the intended way of playing the game and then
> allow players to play any way they please.
>
> In Dungeons of Dredmor permadeath feels not like the way the game should
> be played. It feels like equally valid way of playing the game which
> is endorsed by the developers. This is my gripe with making permadeath
> a check box.

Yet most players play on permadeath. The mechanic is embraced. And part
of that embrace is making it clear to the player that it's their choice,
so when they die and have to restart they can't blame the game. Since
it's their choice they are more mentally ready to accept it.

Still, other games like Binding of Isaac get by with straight permadeath,
so perhaps there's more acceptance for the mechanic than I give outside
gamers credit for.

Thanks for your input, lots of good points :)

--
Darren Grey

[Darren Grey]

On Friday, June 8, 2012 10:56:20 AM UTC+1, JO wrote:

> First of all. ANY text game is going to turn off players. I'm sorry to
> say this. Very sorry. I can't get my 'hard core' gamer friends to even
> look at Brogue. Ever. Not for a second. Never going to happen. If you
> prove me wrong I will tattoo a huge '@' symbol on my face.

Ooh, now this might turn out interesting ;)

> It sorta
> looks like a face anyway....but you don't actually need the ASCII. I
> prefer it now after playing for so long (and seeing brogue), but if
> you want a non RL player to play you gotta have ANIMATED TILES. See
> Cardinal Quest for how basic it can be, see TOME for how beautiful.
> But if TOME is going to truly cross over it needs animation. Dwarf
> Fortress players be damned, that's the major exception not the rule.

Dwarf Fortress is quite a huge exception when you also consider how
it has a crazy interface and over the top learning curve. Imagine
how much better such a game would be with intuitive controls that you
could pick up quickly? Some sort of animation is nice, but tiles are
not necessary. Abstract games like Geometry Wars have proved
successful. ASCII might be able to make it too.

> Name one top
> down RPG game that uses hexes. One. Anyone. Here are some that use 4
> way. Dragon Warrior. Final Fantasy. Zelda. Ultima. Destiny of an
> Emperor (i dug it). Chronotrigger. Lufia.

Mostly console games played on a d-pad - of course they're going to
be 4 way. And if your top down restriction deliberately to exclude
Fallout?

Civilisation V recently moved to hex. Many board games use hex. It's
not a foreign concept, and works well in the roguelike sphere. Plus
it's more acceptable to traditional roguelike players than 4-way.

> It goes without saying that if you want to go HEX you absolutely have
> to have a mouse interface. For everything. Having hot keys is fine,
> but if you want a turn based game with hexes it has to be all mouse
> all the time. Not mouse as an after thought, but mouse primarily. Shit
> you don't even need keys. Look at Battle for Wesnoth for his. That's a
> good interface.

Valid point. The only thing in Rogue Rage you can't do with the mouse
is change stance - I'll amend that, and push players towards using
mouse rather than keys.

> Generally, for any turn based game that wishes to break out, you need
> a mouse interface. I tried a bit of a hybrid with my recent SUN
> CRUSHER!!! game. It was turn based, WASD to move and mouse to point
> and shoot. A turn based shooter...say what you will about the game
> overall but the interface was exactly what i had planned. A WASD +
> Mouse shooter interface pasted onto a turn based game. I'm pretty sure
> you, Darren, saw the failed experiment. Which is cool. Now we know.
> Mouse only in turnbased, it's the only way I've seen a successful
> design work.

Mouse + keyboard works really well in ToME. My favoured way of
playing. But it can be mouse only as well. One must have both to
keep traditional and new players happy.

> As for gamepads I made this mistake very early on. I cannot even
> remember now what game it was, but very soon I realized some things.
> A) very few people have computer compatible gamepads and B) even
> people with gamepads will be too lazy to plug them in and C) those
> that own gamepads and love them will figure out how to use them.
> Binding of Isaac did this best. "Joystick Support: Use Joytokey,
> google it." I laughed when I saw that.

Yes, but as a design consideration restricting your base number of
keys is always a good thing. If it can be played on a joypad then
it doesn't have too many keys for new players to learn.

> It's
> like poetry. Who the fuck reads poetry? Only poetry nerds. But
> everyone likes songs, which include elements of poetry.

Hey, lay off the poetry, man! :P

> Name one successful game (as in
> commercially successful) that required keys to play. Name one turn
> based game, played by the masses, that couldn't be played via mouse
> only. If you dig up something from 20 years ago I've never heard of to
> refute my point I will consider my point well made.

Not sure why the turn based restriction? Turn based games in general
are hard to find these days, alas. Take out that restriction and you
have little known titles like Skyrim and Diablo III that aren't afraid
to use the keyboard. Gamers can accept keyboard use just fine.

> Text descriptions of monsters? Look...if you really want to go ascii
> you at least have to list the monsters in view on the side and let
> people click on them to get info.

Waste of screen space - really bad design in my opinion. Tooltips
are far better.

> Restarting: As soon as you die a pop up menu comes up. with 3 options,
> "RESTART", "QUIT" and "SEE OBITUARY". Put a little blurb and head
> stone graphic in, like, here lies Captain Darren Grey, Felled by
> Hubris and Poison.

Hubris is underestimated :P Many are the works of pride that have
led to great new things. It should be tempered, but never repressed.

> So in the end the key is to include the awesome bits and toss the
> fringe bits, thus bringing the masses just a bit of gaming
> enlightenment.

I disagree - hardcore mechanics can be brought to the masses if the
interface supports them well. However in some cases this
combination may be impossible, and a balance will need to be found.

Overall though I like making new mechanics, so keeping these
interface considerations to mind is important for ensuring they can
be used effectively.

--
Darren Grey

[Gerry Quinn]

In article <a8ddeac1-37a9-4ba7...@googlegroups.com>,
darrenj...@gmail.com says...

> On Thursday, June 7, 2012 8:13:32 PM UTC+1, Gerry Quinn wrote:

> > These days laptops are a bit wider and often have numpads, I think - the
> > one I bought recently has one (tho I had a USB numpad for roguelikes
> > anyway!)
>
> Alas, all too rare! Especially with all these netbooks and the like about these days. Plus even when there is a numpad many will by default use just the arrow keys. Odd though it seems getting people to make proper use of the numpad can be as difficult as teaching them vi-keys. They can pick it up, but it takes a while for it to become anything close to natural feeling. Arrow keys on the other hand are instantly accessible.

The downside of the numpad is that the arrow keys on my laptop are tiny
;-)

> 4-way is... well, not ideal. It does have a constrained feeling. Perhaps the solution is an option like Hydra Slayer to have both 4 and 8 way controls (with mechanics like range and LOS changed to suit), having it 4-way by default.
>
> On the other hand if we all used 4-way all the time I doubt we'd notice the difference.

If I play a 4-way game I'm going to be thinking "what is this, Ultima
4?" There's a reason 4-way fell out of fashion.

> > > Gamepad support
> >
> > But then you lose mouse control, if the latter is more than a substiture
> > for arrow keys.
>
> What's wrong with both? A game shouldn't be exclusively mouse controlled. Key commands are far faster in many circumstances.

I'm a bit more radical with that. My game 'Lair of the Demon Ape' which
is basically 100% mouse controlled. You move several squares at a time.
Key movement is not available. If I do another roguelike it will follow
similar principles.

> > > Auto stairs use
> >
> > I don't like this. It is a constraint on the game too, as stairs must
> > go both ways. Better to make them prominent, I think, and give a
> > message when the player is near.
>
> Must go both ways? How does auto-use contrain that? Look at Dungeons of Dredmor - you walk into the up stairs, you move up a level. Same with down stairs. It's easy, intuitive, and doesn't take anything away from the game. Stairs abuse is too easy in the game, but many roguelikes suffer from that.

I mean that if going downstairs is irreversible (a trope I like) you
don't want any risk of doing it by accident. If you can just walk up
again it's fine.

> > > Permadeath optional
> >
> > I'm okay with this too. However I favour restarting at the beginning of
> > a level with a new map, to get the proper roguelike feeling of
> > exploration. If you are retracing the map you died on so you know
> > what's there, it's not very roguelike.
>
> If you restart with the map unexplored but with all items and character progression intact then it actively encourages dying near the end of a level to scum more stuff. Some set-back on death is still good, but it has to be managed carefully to make sure it isn't encouraging bad behaviours.

What I mean is that you get a new map - the stuff you remember no longer
exists. Lair of the Demon Ape does this. It saves at the end of each
level (as you go downstairs). If you die you can reload at the start of
the level you died on, or any previous level, but the level will be
randomly recreated. And you'll be loading your character as he was when
he started the level.

What's not roguelike IMO is knowing the map before entering it.
Permadeath solves that, but you can solve it in less severe ways.

- Gerry Quinn

[jice]

On Jun 6, 9:43 pm, Darren Grey <darrenjohng...@gmail.com> wrote:
> Well, I'm guessing this'll spark a number of disagreements, but I'm curious as to what other people have to think or contribute to this.  I've written this article today and would like to polish it a bit more before putting it on RogueBasin.  But reflecting on this is as much for my own benefit as it is intended to be a guide for others.
>
> For some this article is irrelevant – they only care about existing Roguelike players touching their games. All fine and well, but I’d like to see more people enjoying all the great games we have around, and in particular I have a goal of making the first truly accessible ASCII game. Er, wish me luck :/
>

Well I just pop up to show you my support. I agree with all your
points.

I understand that people can be reluctant on some points, especially
the ones that impact gameplay (like 4-way keyboard movement), but this
is really was is needed to increase roguelike audience. I hope you'll
stick to it and I'm looking forward to your accessible ASCII game :)

--
jice

[Radomir Dopieralski]

On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:

> 4-way movement Ooh, I can hear the traditionalists grinding their
> teeth already…

This has nothing to do with tradition.

> But every time I introduce a new person to roguelikes
> they fail to grasp the ability to move in diagonals. Years of d-pad or
> arrow key use has made them think purely of the cardinal directions.

I don't really think it's the years of d-pad use. The problem is rather
in how the map is presented, and in how you need to use a separate key
for going diagonal, instead of a chord of two direction keys, as in all
other computer games out there.

> Also it’s hard to get 8-way movement to work nicely on a laptop,
> whatever crazy shift+direction scheme you might invent (and don’t even
> *think* about forcing vi-keys on players). WASD and arrow keys are all
> outside gamers can cope with.

Just use chords of the standard direction keys, no problem here.

> So stick to 4-way, and let the monsters
> only move 4-way too. It feels weird at first but you’ll get used to
> it. Just make sure your dungeons are 4-way connected!

Feeling weird is not the problem here, as well as connectedness of the
levels...

> There are some
> tactical things to consider around this as well, such as pillar
> dancing on two squares and creating choke points more easily, but
> these are design elements that can be overcome.

THIS!

You seem to very gracefully slide over the topic here, while I think this
is actually the core of the issue and would like to discuss it in more
detail. Mostly, because I think that you are wrong when you write that
"these are design elements that can be overcome". I did write a number of
prototypes and finished games, and as I aim for a graphical roguelike with
animations and console-like controls, I have experimented with
carnial-only movement. After trying dozens of different approaches
I concluded that it's not possible to retain tactically interesting
movement and non-annoying controls with 4-way movement, without doing some
really ugly tricks with the monster AIs to make them artifically avoid
problematic situations.

I would be extremely interested in the design patterns that you mentioned
here, that would allow me to overcome the problems of 4-way movement.

> Similarly you’ll find
> ranged combat needs nerfing or visual radius reduced to cope.

You just have to calculate the distances using the new, taxi, metric.

--
Radomir Dopieralski, sheep.art.pl

[Radomir Dopieralski]

On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:

> Space as contextual action Multiple key commands is useful for
> fidelity of action, but in 90% of situations there is only one action
> that can be performed. So let’s use the biggest key on the board for
> it. Stairs? Space to change level. Item on ground? Space to pick up.
> Trap? Space to disarm. Door? Space to open/close. There’s situations
> where this won’t work, but the exceptions shouldn’t get in the way of
> what would be a much smoother experience for most of the game.

From my experience with user interfaces, this is a very bad advice.
The fact that you *usually* do things in one, easy, way, but occasionally
need to do them a different, harder, way, has a number of bad effects:

* the "easy" times do not prepare you in any way for the cases when you
have to use the "hard" way -- suddenly the way you always used doesn't
work and you are left in the void, having to dig through help pages and
check the manual

* often the players will not even be aware that there is the "hard" way
and will simply assume, that the action is impossible to trigger without
standing in an unambiguous position first -- that puts them in a great
disadvantage

* you can never be sure what will happen -- you have to look carefully in
what position you are to know what pressing the space will do, and even
then you can misjudge or just don't know one of the many rules that
govern the behavior of that magical key

* that requirement of constant attention is what actually slows players
down and makes extended play tiring

Of course, those problems can be worked around by removing features from
you game. An excellent example of this is Final Fantasy: Crisis Core,
which can be played through and finished by repeatedly pressing a single
button.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Friday, June 8, 2012 1:45:59 PM UTC+1, Gerry Quinn wrote:
> In article <a8ddeac1-37a9-4ba7...@googlegroups.com>,
> darrenj...@gmail.com says...
>

> > 4-way is... well, not ideal. It does have a constrained feeling. Perhaps the solution is an option like Hydra Slayer to have both 4 and 8 way controls (with mechanics like range and LOS changed to suit), having it 4-way by default.
> >
> > On the other hand if we all used 4-way all the time I doubt we'd notice the difference.
>
> If I play a 4-way game I'm going to be thinking "what is this, Ultima
> 4?" There's a reason 4-way fell out of fashion.

Dungeons of Dredmor, Binding of Isaac, Cardinal Quest. All successful
roguelikes (or similar). 4-way in the mainstream came out of fashion
because most games switched away from being grid-based. I don't
particularly see roguelikes going this way... (nor do I want them to!)

> > What's wrong with both? A game shouldn't be exclusively mouse controlled. Key commands are far faster in many circumstances.
>
> I'm a bit more radical with that. My game 'Lair of the Demon Ape' which
> is basically 100% mouse controlled. You move several squares at a time.
> Key movement is not available. If I do another roguelike it will follow
> similar principles.

Well, I look forward to seeing that, and being frustrated trying to play
it on a laptop ;)

> > Must go both ways? How does auto-use contrain that? Look at Dungeons of Dredmor - you walk into the up stairs, you move up a level. Same with down stairs. It's easy, intuitive, and doesn't take anything away from the game. Stairs abuse is too easy in the game, but many roguelikes suffer from that.
>
> I mean that if going downstairs is irreversible (a trope I like) you
> don't want any risk of doing it by accident. If you can just walk up
> again it's fine.

Ah, right. Well in that case have a prompt on bumping into the stairs.
Or have the stairs sunk into the walls like Dredmor does, so there's
much less chance of accidentally walking into them.

> > If you restart with the map unexplored but with all items and character progression intact then it actively encourages dying near the end of a level to scum more stuff. Some set-back on death is still good, but it has to be managed carefully to make sure it isn't encouraging bad behaviours.
>
> What I mean is that you get a new map - the stuff you remember no longer
> exists. Lair of the Demon Ape does this. It saves at the end of each
> level (as you go downstairs). If you die you can reload at the start of
> the level you died on, or any previous level, but the level will be
> randomly recreated. And you'll be loading your character as he was when
> he started the level.
>
> What's not roguelike IMO is knowing the map before entering it.
> Permadeath solves that, but you can solve it in less severe ways.

So integrated save-scumming, essentially. Yeah, I'm fine with that.
Many already learn roguelikes by abusing this. Should possibly be
discouraged by giving no score or something similar, to point players
towards the true path :)

--
Darren Grey

[Darren Grey]

On Friday, June 8, 2012 2:13:55 PM UTC+1, Radomir Dopieralski wrote:
> On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:
> > 4-way movement Ooh, I can hear the traditionalists grinding their
> > teeth already…
>
> This has nothing to do with tradition.

I disagree. The outrage against no diagonals in Dredmor was steeped in
illogical revulsion and vulgar elitism. It was declared by many to be
"not a roguelike" because it had only 4-way movement.

I'll say it again, if Rogue did it like this so would all of us.

There are game design considerations too. *Everything* impacts on
game design. That doesn't mean it should be dismissed out of hand.

Not that you're doing that, but some do, and these are the
traditionalists I'm talking about.

> > Also it’s hard to get 8-way movement to work nicely on a laptop,
> > whatever crazy shift+direction scheme you might invent (and don’t even
> > *think* about forcing vi-keys on players). WASD and arrow keys are all
> > outside gamers can cope with.
>
> Just use chords of the standard direction keys, no problem here.

You mean pressing two keys at once? Would require some special design
to parse that properly, but an interesting solution.

> > There are some
> > tactical things to consider around this as well, such as pillar
> > dancing on two squares and creating choke points more easily, but
> > these are design elements that can be overcome.
>
> THIS!
>
> You seem to very gracefully slide over the topic here, while I think this
> is actually the core of the issue and would like to discuss it in more
> detail. Mostly, because I think that you are wrong when you write that
> "these are design elements that can be overcome". I did write a number of
> prototypes and finished games, and as I aim for a graphical roguelike with
> animations and console-like controls, I have experimented with
> carnial-only movement.

Carnal-only movement would be more interesting ;)

> After trying dozens of different approaches
> I concluded that it's not possible to retain tactically interesting
> movement and non-annoying controls with 4-way movement, without doing some
> really ugly tricks with the monster AIs to make them artifically avoid
> problematic situations.
>
> I would be extremely interested in the design patterns that you mentioned
> here, that would allow me to overcome the problems of 4-way movement.

Well, some solutions:

1. Ignore. Not best, but you have to remember that there are flaws
and abuses in all systems. You can't overcome them all, and any new
system produces new abuses. Roguelikes in particular are plagued by
more abuses than pillar dancing.

2. No advantage. A big problem with the pillar dancing is restoration
of resources. Stop resources recovering over time (a good design feature
in my opinion) can alleviate this problem.

3. Ugly AI tricks. Who cares if it's ugly as long as it works? Stop AI
chasing the player if it can't act after x turns. This prevents other
abuses which are present in 8-way systems as well. Look at Smart Kobold
- would you call that ugly AI? It still has abuses by the way, in spite
of 8-way movement and smart AI. All games have abuses.

4. Interesting enemies. Give every monster intended to be challenging a
ranged attack or a timed heal ability or a summon skill or some area of
effect ability etc. Make them all interesting, and pillar dancing is no
longer safe. Also makes the game more interesting overall as an added
bonus. Many abuses in games are due to boring enemies that only melee
the player.

I find it interesting by the way that 4-way movement is always considered
so controversial. Roguelikes have changed in many ways over the years,
but this is something that still sticks as a sore point. I'm not sure
why that is... There are valid design considerations of course, but it's
hardly the only mechanic with this association. Food clocks and identify
systems have gotten thrown out the window in many games with nary an
eyelid blinked. Why is defence of 8-way still so strong?

And to clarify, I don't like 4-way all that much myself. I'm just saying
it's an important consideration if you want to reach beyond the core
roguelike audience.

--
Darren Grey

[Radomir Dopieralski]

On 2012-06-08, Darren Grey <darrenj...@gmail.com> wrote:
> On Friday, June 8, 2012 1:45:59 PM UTC+1, Gerry Quinn wrote:
>> In article <a8ddeac1-37a9-4ba7...@googlegroups.com>,
>> darrenj...@gmail.com says...
>>
>> > 4-way is... well, not ideal. It does have a constrained feeling.
>> > Perhaps the solution is an option like Hydra Slayer to have both
>> > 4 and 8 way controls (with mechanics like range and LOS changed to
>> > suit), having it 4-way by default.
>> >
>> > On the other hand if we all used 4-way all the time I doubt we'd
>> > notice the difference.
>>
>> If I play a 4-way game I'm going to be thinking "what is this, Ultima
>> 4?" There's a reason 4-way fell out of fashion.
>
> Dungeons of Dredmor, Binding of Isaac, Cardinal Quest. All successful
> roguelikes (or similar).

Actually Binding of Isaac is 8-way, with diagonals done by pressing two
keys at the same time.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Friday, June 8, 2012 2:28:51 PM UTC+1, Radomir Dopieralski wrote:
> On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:
> > Space as contextual action Multiple key commands is useful for
> > fidelity of action, but in 90% of situations there is only one action
> > that can be performed. So let’s use the biggest key on the board for
> > it. Stairs? Space to change level. Item on ground? Space to pick up.
> > Trap? Space to disarm. Door? Space to open/close. There’s situations
> > where this won’t work, but the exceptions shouldn’t get in the way of
> > what would be a much smoother experience for most of the game.
>
> From my experience with user interfaces, this is a very bad advice.
> The fact that you *usually* do things in one, easy, way, but occasionally
> need to do them a different, harder, way, has a number of bad effects:
>
> * the "easy" times do not prepare you in any way for the cases when you
> have to use the "hard" way -- suddenly the way you always used doesn't
> work and you are left in the void, having to dig through help pages and
> check the manual

The problem is you shove this same problem in the player's face from the
get-go, instead of hooking them into the basic gameplay before showing
them more complexity. And in a well-designed game those help pages should
be easily accessible, or there should be additional contextual help in
those "hard" situations.

> * often the players will not even be aware that there is the "hard" way
> and will simply assume, that the action is impossible to trigger without
> standing in an unambiguous position first -- that puts them in a great
> disadvantage

Potentially, but I'm not sure about the "often" part. It starts some
people off at a disadvantage whilst they learn the ropes. But it at least
keeps people playing. The important thing is to show them the fun parts
of the game as soon as possible. Let them become masters of the game
later. Normally they start off the game dying lots anyway. Hoepfully
death will be the good teacher it's meant to be and they'll pick up on
how to play better. This applies to other roguelike mechanics too.

Plus I'd say this already happens. When I started out with ADOM I didn't
know about things like extended drop, or how to change the tactical
display to show the energy use per turn, or how to lock doors with keys
or the pick lock skill. Same with other rare skill and class abilities.
Over time as I learned various parts of the game I grew to learn these
too. I'm sure others have had similar experience in other roguelikes.
I'm just suggesting dropping the bar lower so more people can get into
the game.

> * you can never be sure what will happen -- you have to look carefully in
> what position you are to know what pressing the space will do, and even
> then you can misjudge or just don't know one of the many rules that
> govern the behavior of that magical key

This is why I suggested contextual advice. "You see a key here (space to
pick up)" etc. For power users there are still the direct keys in the
background. New players can only take in so many instructions at once,
especially if they're not used to the standards of the genre. This helps
ease them in. Otherwise they might get turned off at the first door
they encounter.

> * that requirement of constant attention is what actually slows players
> down and makes extended play tiring

I'd argue that this is exactly what happens to newcomers to roguelikes.
Learning the controls is slow and tiring, and it can make the game
immensely off-putting. As I'm sure you know it can be very hard to
overcome a negative first impression.

Another solution might be to have the early game not involve the same
number of elements. No doors, no items, no food clock. Show the basic
combat and interactions, and expand to the full game as you go on. Many
commercial games do things like this. I'm not fond of the idea myself
though - it goes against the principals of replayability that roguelikes
have.

> Of course, those problems can be worked around by removing features from
> you game. An excellent example of this is Final Fantasy: Crisis Core,
> which can be played through and finished by repeatedly pressing a single
> button.

Haha, I guess that's the way to make roguelikes truly accessible ;)

--
Darren Grey

[Radomir Dopieralski]

On 2012-06-08, Darren Grey <darrenj...@gmail.com> wrote:

> On Friday, June 8, 2012 2:13:55 PM UTC+1, Radomir Dopieralski wrote:
>> On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:

>> > There are some
>> > tactical things to consider around this as well, such as pillar
>> > dancing on two squares and creating choke points more easily, but
>> > these are design elements that can be overcome.
>>
>> THIS!
>>
>> You seem to very gracefully slide over the topic here, while I think this
>> is actually the core of the issue and would like to discuss it in more
>> detail. Mostly, because I think that you are wrong when you write that
>> "these are design elements that can be overcome". I did write a number of
>> prototypes and finished games, and as I aim for a graphical roguelike with
>> animations and console-like controls, I have experimented with
>> carnial-only movement.
>
> Carnal-only movement would be more interesting ;)

I meant "cardinal", sorry.

>> After trying dozens of different approaches
>> I concluded that it's not possible to retain tactically interesting
>> movement and non-annoying controls with 4-way movement, without doing some
>> really ugly tricks with the monster AIs to make them artifically avoid
>> problematic situations.
>>
>> I would be extremely interested in the design patterns that you mentioned
>> here, that would allow me to overcome the problems of 4-way movement.
>
> Well, some solutions:
>
> 1. Ignore. Not best, but you have to remember that there are flaws
> and abuses in all systems. You can't overcome them all, and any new
> system produces new abuses. Roguelikes in particular are plagued by
> more abuses than pillar dancing.

This is obviously unhelpful.

> 2. No advantage. A big problem with the pillar dancing is restoration
> of resources. Stop resources recovering over time (a good design feature
> in my opinion) can alleviate this problem.

A bigger problem I have with two-tile dancing with 4-way movement is that
half of the time you and your opponent will be unable to hit each other,
despite trying to do so desperately on both sides. The only way out of
that impasse is to let the other party hit first, which obviously puts you
at a disadvantage. You can remove that disadvantage by making the monster
sometimes take the first hit -- but then the player will always exploit it
and have an advantage instead.

> 3. Ugly AI tricks. Who cares if it's ugly as long as it works? Stop AI
> chasing the player if it can't act after x turns. This prevents other
> abuses which are present in 8-way systems as well. Look at Smart Kobold
> - would you call that ugly AI? It still has abuses by the way, in spite
> of 8-way movement and smart AI. All games have abuses.

I care, because it actually severely limits the palette of interesting
monster behaviours that I can have in my game -- playing against the
point 4. It forces me to have dumbed-down enemies that only wait for
the player to run ower them.

> 4. Interesting enemies. Give every monster intended to be challenging a
> ranged attack or a timed heal ability or a summon skill or some area of
> effect ability etc. Make them all interesting, and pillar dancing is no
> longer safe. Also makes the game more interesting overall as an added
> bonus. Many abuses in games are due to boring enemies that only melee
> the player.

That actually dumbs the game down even more, by making all movement
irrelevant -- since you can always be hit by a ranged attack, it doesn't
matter how you move. Since all monsters have ranged attacks, it doesn't
matter which ones you attack first.

> I find it interesting by the way that 4-way movement is always considered
> so controversial. Roguelikes have changed in many ways over the years,
> but this is something that still sticks as a sore point. I'm not sure
> why that is... There are valid design considerations of course, but it's
> hardly the only mechanic with this association. Food clocks and identify
> systems have gotten thrown out the window in many games with nary an
> eyelid blinked. Why is defence of 8-way still so strong?

It's because it makes your movement matter -- it gives you a tactical
puzzle to play along with the usual strategic puzzle of planning your
equipment and managing resources. Without that tactical puzzle element,
you can reduce the game to the mechanic of the card game Munchkin and
just tell the player "you are entering the next room in the dungeon".
Perhaps you can add some animations here and there to visualise it,
but a direct control over the character's movement is no longer relevant.

> And to clarify, I don't like 4-way all that much myself. I'm just saying
> it's an important consideration if you want to reach beyond the core
> roguelike audience.

Unfortunately it's also a very difficult choice to make.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Friday, June 8, 2012 3:21:30 PM UTC+1, Radomir Dopieralski wrote:

> On 2012-06-08, Darren Grey wrote:
>
> > Dungeons of Dredmor, Binding of Isaac, Cardinal Quest. All successful
> > roguelikes (or similar).
>
> Actually Binding of Isaac is 8-way, with diagonals done by pressing two
> keys at the same time.

Ooh, crikey, I didn't realise. I suppose the point would be 4-way input
then.

--
Darren Grey

[Darren Grey]

On Jun 8, 3:42 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

> On 2012-06-08, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > Carnal-only movement would be more interesting  ;)
>
> I meant "cardinal", sorry.

I know, just thought it was amusing :)

> > Well, some solutions:
>
> > 1. Ignore.  Not best, but you have to remember that there are flaws
> > and abuses in all systems.  You can't overcome them all, and any new
> > system produces new abuses.  Roguelikes in particular are plagued by
> > more abuses than pillar dancing.
>
> This is obviously unhelpful.

Well, it's what Dungeons of Dredmor did and I don't think it's a big
problem for the game. 8-way still has pillar dancing and hack n back.
We look for solutions to these trivialisations of challenge in our
games
and we can do the same in other movement systems. Or ignore them as
many do right now.

> > 2. No advantage.  A big problem with the pillar dancing is restoration
> > of resources.  Stop resources recovering over time (a good design feature
> > in my opinion) can alleviate this problem.
>
> A bigger problem I have with two-tile dancing with 4-way movement is that
> half of the time you and your opponent will be unable to hit each other,
> despite trying to do so desperately on both sides. The only way out of
> that impasse is to let the other party hit first, which obviously puts you
> at a disadvantage. You can remove that disadvantage by making the monster
> sometimes take the first hit -- but then the player will always exploit it
> and have an advantage instead.

It gives the player an ability to exploit the AI. To game the system.
But ultimately this is what the whole game is about - bending the
rules to
your advantage. The real problem I see is immersion. It's silly to
keep
running in loops around a supposedly powerful boss so you can heal up
or get a free attack due to a time differential.

> > 3. Ugly AI tricks.  Who cares if it's ugly as long as it works?  Stop AI
> > chasing the player if it can't act after x turns.  This prevents other
> > abuses which are present in 8-way systems as well.  Look at Smart Kobold
> >  - would you call that ugly AI?  It still has abuses by the way, in spite
> > of 8-way movement and smart AI.  All games have abuses.
>
> I care, because it actually severely limits the palette of interesting
> monster behaviours that I can have in my game -- playing against the
> point 4. It forces me to have dumbed-down enemies that only wait for
> the player to run ower them.

The problem with the 4-way pillar dancing is it's based on monsters
that
have only one boring mode of operation - run to player and attack.
I'm
suggesting having extra behaviours beyond this. Some might still run
up
dumbly, but others, especially more powerful monsters, should behave
more
.... well, I don't want to say "intelligently" because I think
gaminess
is more important than smart behaviour. More interestingly, and less
exploitable.

> > 4. Interesting enemies.  Give every monster intended to be challenging a
> > ranged attack or a timed heal ability or a summon skill or some area of
> > effect ability etc.  Make them all interesting, and pillar dancing is no
> > longer safe.  Also makes the game more interesting overall as an added
> > bonus.  Many abuses in games are due to boring enemies that only melee
> > the player.
>
> That actually dumbs the game down even more, by making all movement
> irrelevant -- since you can always be hit by a ranged attack, it doesn't
> matter how you move. Since all monsters have ranged attacks, it doesn't
> matter which ones you attack first.

I didn't say all monsters have ranged attacks. Just give them extra
things to do other than chasing you. Ranged attacks is one option.

And even then it doesn't remove the movement challenge. You still
have
to think about your approach and positioning, especially if they only
fire in certain directions like Jeff Lait's kobolds. If they have
area
attacks that cover a certain pattern then that's another positioning
element to consider. If there are multiple enemies then it can be a
matter of taking out the ranged ones first so you can pillar dance the
last. Or maybe you know one type runs away rather than dancing so you
let him be last so you don't have to bother killing it. You have to
consider some enemies blocking the sights of others to stop their
ranged attacks, or killing the healers and summoners early, or keeping
open a path of escape if you need it. You might also have abilities
that have an area of effect, or that can move you about the map in
different ways, and your positioning is vital for these. There is a
wealth of traditional roguelike gameplay which is left intact.

Some of these sorts of things end up trivialised in an 8-way game, but
in a 4-way game you have to think harder about. More constraints can
lead to more interesting gameplay sometimes. The kobolds that only
fire in certain directions are a good example - they are more
interesting in game terms than ranged enemies that just have a circle
of death around them. Limiting player options can make the player
think harder about those options, and can lead to less "obvious
choices". (Can lead, not will lead - design and implementation is
of course paramount.)

> > I find it interesting by the way that 4-way movement is always considered
> > so controversial.  Roguelikes have changed in many ways over the years,
> > but this is something that still sticks as a sore point.  I'm not sure
> > why that is...  There are valid design considerations of course, but it's
> > hardly the only mechanic with this association.  Food clocks and identify
> > systems have gotten thrown out the window in many games with nary an
> > eyelid blinked.  Why is defence of 8-way still so strong?
>
> It's because it makes your movement matter -- it gives you a tactical
> puzzle to play along with the usual strategic puzzle of planning your
> equipment and managing resources. Without that tactical puzzle element,
> you can reduce the game to the mechanic of the card game Munchkin and
> just tell the player "you are entering the next room in the dungeon".
> Perhaps you can add some animations here and there to visualise it,
> but a direct control over the character's movement is no longer relevant.

It's still relevant in Dungeons of Dredmor. More so in that than in
many other roguelikes I've played, since it has a range of interesting
spells and abilities you can take advantage of that rely on
positioning,
as well as its more engaging trap system.

> > And to clarify, I don't like 4-way all that much myself.  I'm just saying
> > it's an important consideration if you want to reach beyond the core
> > roguelike audience.
>
> Unfortunately it's also a very difficult choice to make.

As it should be! But there are many such choices in game design. I
suppose my main point in the original article is that this *is* a
choice
you can make. Too often it's not even considered when the game might
get
little or no benefit from diagonal moves.

--
Darren Grey

[Gerry Quinn]

In article <0b82d1d0-df9f-40de...@googlegroups.com>,
darrenj...@gmail.com says...

> On Friday, June 8, 2012 1:45:59 PM UTC+1, Gerry Quinn wrote:
> > In article <a8ddeac1-37a9-4ba7...@googlegroups.com>,
> > darrenj...@gmail.com says...

.

> > > What's wrong with both? A game shouldn't be exclusively mouse controlled. Key commands are far faster in many circumstances.
> >
> > I'm a bit more radical with that. My game 'Lair of the Demon Ape' which
> > is basically 100% mouse controlled. You move several squares at a time.
> > Key movement is not available. If I do another roguelike it will follow
> > similar principles.
>
> Well, I look forward to seeing that, and being frustrated trying to play
> it on a laptop ;)

http://indigo.ie/~gerryq/lair/lair.htm

It will only be frustrating if you don;t have a mouse on your laptop.
The game is almost 100% mouse controlled - really the only important key
is M for Map. Keyboard control is not supported.

I think in terms of user-friendliness to non-roguelikers it is pretty
good, although it goes in some directions you wouldn't like.

- Gerry Quinn

[Gerry Quinn]

In article <426909c8-7496-499b...@googlegroups.com>,
darrenj...@gmail.com says...

> On Friday, June 8, 2012 2:13:55 PM UTC+1, Radomir Dopieralski wrote:

> > This has nothing to do with tradition.
>
> I disagree. The outrage against no diagonals in Dredmor was steeped in
> illogical revulsion and vulgar elitism. It was declared by many to be
> "not a roguelike" because it had only 4-way movement.
>
> I'll say it again, if Rogue did it like this so would all of us.

No. You said it of stairs, in the case of which it might be true. But
unlike stairs implementation details, movement directions are important.
If Rogue had used 4-way movement it would have been less successful, and
in any case subsequent games would soon have switched to a better
system.

> > Just use chords of the standard direction keys, no problem here.
>
> You mean pressing two keys at once? Would require some special design
> to parse that properly, but an interesting solution.

Pressing two keys at once isn't a good solution for roguelikes IMO. To
many presses are needed, and there will be lots of mistakes.

> I find it interesting by the way that 4-way movement is always considered
> so controversial. Roguelikes have changed in many ways over the years,
> but this is something that still sticks as a sore point. I'm not sure
> why that is... There are valid design considerations of course, but it's
> hardly the only mechanic with this association. Food clocks and identify
> systems have gotten thrown out the window in many games with nary an
> eyelid blinked. Why is defence of 8-way still so strong?

Because 8-way is unambiguously better than 4-way. Food clocks and
identification may have their charms but they bring annoyances too that
people want to get rid of.

6-way versus 8-way is an interesting choice because both have
advantages. I think the reason 6-way is uncommon in roguelikes comes
down to three main reasons:

1. There's no obvious way to map it to the numpad. You'd *think* that a
hexagon of keys such as U-I, H-J-K, N-M would work well, but for some
reason it doesn't seem to.

2. It maps poorly to rectilinear buildings and dungeons (as distinct
from the outdoors).

3. The geometric artefacts of 8-way, while worse than those of hex, are
much more tolerable than those of 4-way.

> And to clarify, I don't like 4-way all that much myself. I'm just saying
> it's an important consideration if you want to reach beyond the core
> roguelike audience.

Seems to me that people are happy with diagonal movement in games like
Diablo. And I find it hard to believe that it won't be obvious that you
can move diagonally. After all, players will see monsters doing it all
the time.

- Gerry Quinn

[Gerry Quinn]

In article <4265f56a-a56c-4c68...@googlegroups.com>,
darrenj...@gmail.com says...

>
> Another solution might be to have the early game not involve the same
> number of elements. No doors, no items, no food clock. Show the basic
> combat and interactions, and expand to the full game as you go on. Many
> commercial games do things like this. I'm not fond of the idea myself
> though - it goes against the principals of replayability that roguelikes
> have.

You could have an optional tutorial dungeon that works like this.

- Gerry Quinn

[Michal Bielinski]

Once upon a time, Darren Grey wrote thus:
> On Thursday, June 7, 2012 11:46:27 PM UTC+1, Michal Bielinski wrote:
>> Once upon a time, Darren Grey wrote thus:

>> > For some this article is irrelevant - they only care about existing
>> > Roguelike players touching their games.
>>
>> What a generalisation. Are there *any* developers out there like this?
>
> Krice ;)

Um. Ten points for you. ;)

> Plus there is an attitude amongst some of "If you don't
> bother to learn the controls you don't deserve to play my game".

Yeah. Thats weird and leads nowhere.

> But more than that you have to consider that if you're not going out
> of your way to consider accessibility and all you do is follow the
> genre's conventions then essentially you are just making games for
> existing roguelike players.

Actually I go by the paradigm of making a game that I would like to play.
This solves motivation issue quite nicely. On the other hand it looks
like PRIME is going to have two UIs in future. One for seasoned roguelike
veterans like me and another for everyone else. Maybe it is not so bad.
Implementing switchable interface will force me to design UI/engine
division better.

>> Define truly accessible.

>
> "Pick up and play" is what I define as truly accessible. Mechanics will
> take some learning, but the controls will be automatic and intuitive.

Clear and concise definition. I like it.

> And stairs... yeah, Jesus, no one gets stairs :(

PRIME is sci-fi and we still have stairs. Xenocide had elevators.
It is great yet untapped opportunity to make it something better.

>> > All the assumptions we have about the interface are completely null
>> > to them. It’s immensely painful watching someone try to play your
>> > game and being so unfamiliar with the controls that they move at a
>> > snail’s pace, and have such trouble with even movement that they
>> > fail to see the rest of the depth of play.
>>
>> Agreed with this. On the other hand my experience is different. Maybe
>> it is caused by my audience? I show roguelikes to students mostly.
>> After all Rogue also originated in a university. Most troubles people
>> had was with searching (when that was only exit from a room) and
>> leaving the level. They quickly got to experiencing the game more.
>
> What sort of students? I don't know why your experience has been
> better. Oh, and was it on a normal computer or a laptop?

Mostly a mix of informatics and mathematics students. We had a meeting
of student interest group so could use two ordinary computers to
present PRIME there. The rest played on laptops. Mind you, some had
numeric keyboards on their laptops. Still it was eight people total
at the time so not much.

>> > 4-way movement
>> > Ooh, I can hear the traditionalists grinding their teeth already…
>>
>> I am no traditionalist. I simply dislike pointless constraints.
>
> If you view it as a constraint... And importantly, how much of a
> constraint? Does it really make that much difference?

Sadly, yes. Jo has warned that weirdos like me tend to respond with
several reasons why 8-way is better tactically. Here it goes!

While being adjacent to certain enemy there is no space adjacent to
him you can step into. Z-Day has grinding machines into which you can
push zombies. It is important to be able to position yourself without
inviting the monster chewing at you to move. This would ruin the plan.

There is more steps to hiding behind a pilar because you need to circle
it. You are longer under fire from ranged weapons.

You cannot be cornered in a way that makes it possible to hit you
without getting into dead end. Also, fleeing monsters will always be
able to evade your melee at will by stepping aside. You need a dead
end or a corner and another monster to lock it into position to land
a blow.

With 4-way movement a single monster may disallow you to move past it
by clever enough AI given equal speeds. Makes avoiding monsters more
difficult. Radomir correctly notes you can make your AI stupider not
to take advantage of this. I agree with him this is bad thing.

Explosions should be diamond-shaped to maintain consistency. After
all touching diagonally some item is considered being two spaces away.
This is far uglier than FOV artifacts of 8-way movements. Even square
FOV (which I consider very ugly) does not feel as artificial IMO. Your
fireball becomes firediamond.

Playing a hydra means you can attack eight enemies instead of only four!
Okay, I made that up. No idea if any game implements that but in DCSS it
is possible to have enslaved hydra fight for you. Works monstrously well
against Vampires' horde of spammals.

Note that hexes do fine in most of situations above. The single tile
pillar does not provide much cover from line of sight but otherwise
6-way is fine. Still, the geometry problems of designing locations
prevent me from touching it.

> A lot of people moaned about Dredmor only having 4-way movement.
> It was... well, stupid. What would diagonal movement add to the game?

Possibility to cram in some more tactical depth.

> The game was designed around 4-way movement and worked just fine like
> that. The people arguing were seeing it as a constraint rather than
> accepting it as part of the game design.

The design is fine and Dungeons of Dredmor appears to be fun and very
successful game. I love solving tactical battle puzzles and thus value
eight way movement.

> I'm not a big fan of 4-way, but I think it's important not to dismiss
> it out of hand. It's an alternative design that produces different
> gameplay and design consideration, nothing more or less.

Well, the different design considerations do mean that you get less
something for more something other. Most apparent thing is you get not
as great tactical complexity but receive easier game to play from
controls viewpoint and considerably lower entry bar. It is a tradeoff.
One I stubbornly refuse to make.

> Perhaps one option for making 8-way clear is to have a red outline
> or shading on all available moves, a bit like how various tactical
> games use when moving units. Would have to be something you could
> turn off, of course...

There are touch spells like Crawl's Vampiric Drain that ask for
direction. That would be good time to show the outline you speak about.

>> > An alternative is hex, with QWE/ASD for the 6 directions.

>> > But from a technical point of view hex is the ultimate for
>> > all games ;)
>>
>> Bah. Go 8-way movement with maximum metric. You eliminate all and
>> every sight/movement artifact you can think of with this.
>
> You absolutely do not! How often have there been stupid threads on
> here about making diagonal movement cost 1.4 turns? And the Square
> LOS considerations to boot. 8-way doesn't make geometric sense.

With maximum metric diagonal movement should cost 1.0 turns to make
mathematical sense. The square FOV is the price you need to pay. Then
movement and sight is consistent.

> But it's a game, so that's fine. But ah, hex! How gloriously
> elegant all systems are in hex! I spit on your inferior 8-way :P

By my beard [1]! Thou art insulting me! :-D

[1] I actually lack one but hey, it is not required to make this
argument, is it?

>> > Mouse control
>> > Easily and quickly move to another part of the map (with appropriate
>> > interruptions for damage or spotting a threat),
>>
>> A partial auto-explore?
>

> It's not meant as a partial auto-explore, but an easy way to move
> several spaces with a single command, letting the computer calculate
> the optimal route inbetween.

Ah, okay. On NetHack newsgroup someone made a point that NetHack allows
you to use shortcuts for most common interesting points on level and
be faster than mouse users. For example hit '>' to move cursor to the
stairs.

The small problem I see with this the path calculation might drag the
player character along unfavorable places if a monster was to show up.
This could be shifted on player's shoulders and handwaved though. One
should not use the feature when it is not safe to do so.

>> > and right-click for
>> > contextual menus to quickly choose available interactions with
>> > enemies and items.
>>
>> Nah, it would obscure the screen too much (if one would like to display
>> really all the possibilities a roguelike game hides) or the font would
>> be too small.
>
> I don't get what you mean by obscure the screen?

[...]

> If the list gets too long make it scrollable.

This.

> Makes the default
> action appear at the top (attack enemy, eat food, read scroll, etc).
> Maybe left-click or double click would result in using that default
> action.

In hacklikes it makes sense to throw almost any item at monsters under
some circumstances. PRIME has Bouncy Bubbly Beverage cans which when
shaken (thrown) explode doing minor damage to single target. There are
plans of interactions between program monsters and floppy disk programs.
For example one could steal all monster's cash by hitting it with wielded
floppy disk of spam or throwing it at the creature.

Throw alone would list your whole inventory on right-click at a monster.
Unless you meant just "throw" which would open a dialog box? Verb-object
is better served by the keyboard in my opinion.

> There's a lot that can be done with mouse commands.

This should be capitalized on. Targeting and look command are excellent
places to start.

>> > Mouse control makes a game hugely more accessible without hindering
>> > the game’s complexity.
>>
>> If you had omitted the "hugely" word I would be inclined to agree. As
>> it stands your statement appears to be false.
>
> Everyone knows how to use the mouse.

Almost no one can use the mouse with precision though. This is why some
programs have snap to grid feature. Do not take your expertise (yes!)
with the input tool as granted. I've seen people confuse left and right
clicks sometimes.

Also, people swear at my mouse because it is old enough to lack a scroll
wheel but this is whole another issue. Still it allows me to observe
that hitting a specific portion of small scroll bars might be difficult.
Something to keep in mind probably.

>> > Tooltips also help convey detailed information quickly without forcing
>> > the player to read through manuals or help files – most players never
>> > read help files or manuals.
>>
>> Their choice I'd say. I have read whole NetHack guidebook before even
>> running the game for the very first time. Did you know they tell you
>> about E-word there? Still, on rgr.nethack it is still considered somewhat
>> spoily proving your point. Everything one places in manual and readme
>> should be found in game. Documentation just exposes information in more
>> friendly form.
>
> I read the whole ADOM manual before ever playing the game.

Hurrah! One of us! One of us!

> It was one of
> the things that drew me in. I'm not sure I'd do the same for many games
> these days though. Why should I read through the manual if I don't know
> if I'll enjoy the game yet? Good documentation is still important of
> course, but don't rely on all players making use of it. Modern gamers
> especially are used to forced tutorials (ugh!) and hand-holding in new
> games. They are conditioned not to read such materials, or to even expect
> them to exist.

Only thing I can do is confirm this. Can you imagine the shocked faces when
I gave percentage chance for unit attacks to miss targets under cover in
StarCraft from memory? Even much better players were surprised because it
matched their observations. It is written in help files but nowhere else.
It seemed like a big secret. The only place where concussive vs normal vs
explosive damage types were directly explained was again the help file. You
get a link to it in start menu after the game is installed but I don't
remember any other thing that told you why a ghost attacking a battlecruiser
did not do full damage. I was under impression in a competitive multiplayer
game people would read documentation to glean insights to use aginst other
players. Sooo wrong but it worked for me.

>> > Auto stairs use
>> > A stairs should be treated like a wall square you can see through.
>> > Enemies can’t walk on it, items can’t drop on it, and once you bump
>> > into it you change level.
>>
>> The no-walk and no-item-drop are additional properties that ordinary
>> walls do not have. So it is much more than a transparent wall.
>
> Well, depends on the game, but true. I wasn't suggesting it be an
> ordinary wall of course, just to rethink the idea that it should be
> like a floor tile.

Indeed. Traps obscured by items laying in same square present similar
problem.

> Put another way, if Rogue had done it like this then every roguelike
> since would have still copied it.

Wrong assumption. Roguelikes copy Rogue because it was good. If a solution
implemented inside it had been feeble it would not make to modern RLs.

>> Acceptable solution but requires a substantial game redesign for most
>> existing roguelikes.
>
> Really? Make sure stairs can be pathed around is the main
> consideration, and that's not hard. Player placement on level change
> is another, but many roguelikes already have this with monster following.
> It's a pretty minor redesign from my perspective.

I take that back. Did not look up substantial in dictionary. The word
I needed was more like nontrivial. Modifying a few dungeon generators
is a bit of work nonetheless.

>> > Tell a player to press < and he’ll press the , key, and then wonder
>> > why it didn’t work.
>>
>> The don't know how to use the keyboard properly? I don't buy it.
>
> Maybe I should change to title to "How to Make Roguelikes Playable for
> Idiots" ;) Honestly, I have seen this! Multiple times!

Okay, my friend recently did it in front of me. He realized what was going
on from my shocked expression but it is reality! Man, I seem to take my
familiarity with keyboard as granted.

> And help
> files of commands should split the core commands and advanced commands
> to make it clear to new users that you can play with just the base
> set (unlike ADOM's list of commands which is almost unusable).

This is so true. I have watched as GameHunter play ZapM. He was paging
through its list of commands looking for a specific key and missing it
because he had to read it all. This is still not changed in variant but
of course should be.

>> PRIME does a small experiment. It offers several key maps based on
>> other commonly played roguelike games.
>

> I think it's a good thing, just be mindful that 90% of players will
> likely stick with the default.

Which means the default should be good for playing on a laptop too. This
is why it includes vi-keys.

> Another possibility is duplicate keys -
> having both g and p for get/pick up for instance. I don't like it much
> as a designer, but it can be handy when there are multiple standards
> around.

ZapM does this and in comments there was a note why it is that way. One
key was for mnemonic usage ('m'utant power) while the other was to have
it available on left side of keyboard ('Z'ap a mutant power).

>> > W for Wear will confuse many roguelikers,
>>
>> Perhaps you wanted to say non-roguelikers? Very few RLs have W bound to
>> something else than wield or wear.
>
> No, I meant roguelikers. With a background in ADOM I am always
> flummuxed by games with Nethack-esque inventory systems.

Of major roguelikes only ADOM has W assigned to something other. I guess
most roguelikers wouldn't be confused by that. Just the part of player
base sticking only to ADOM and games inspired by it.

> You have a good point that examples would make this whole article
> much better.

Some you can pick up from responses already. When you drop this off at
RogueBasin let us know the article name. I'll most probably add some
additional examples.

>> > but the exceptions shouldn’t get in the way of what would be a much
>> > smoother experience for most of the game.
>>
>> They should. By ignoring those you get seemingly better interface but
>> in reality it becomes ridden with traps.
>
> I disagree. But I guess that's where options come in :) ADOM has its
> auto-select doors as an option you can disable. I'm not aware of any
> that have it disabled though...

I did it and was very happy with it. The question is which way should be
the default option. Probably Thomas was right with leaving it enabled.
Those who exploit muscle memory probably will be glad these options exist
and not give a damn why they are not set the right way for them by default.

> Part of making the log
> good is getting rid of the chaff like the hit and miss notifications.

[...]

> The log should not be used to
> communicate every petty detail to the player.

Have you seen how Sil does this? It essentially has two logs. One for
combat data where rolls are displayed in technical format and the other
ordinary log for narration. It works surprisingly well.

>> > Easy Inventory system
>>
>> Ouch. All games I work on are guilty of not fulfilling this.
>
> How very true! But roguelikes tend to be especially bad :)

Oh, look. A consolation...

>> > Clarity of mechanics
>> > Don’t hide important stuff from the player and hope that they’ll get
>> > it. Make sure your mechanics are clear and understandable.
>>

>> I think NetHack remains among few offenders. Nowadays roguelikes usually
>> have transparent mechanics.
>
> Yes, but it bears reminding :) I've played many 7DRLs with obscure
> mechanics, which seems the absolute worst place to have them since few
> will replay the game often. The biggest offender is in item mechanics,
> with weapons and armour not showing their power and special items not
> saying at all what they do.

Oh, the Sword Tester roguelike by Oohara Yuma. I loved it. Its sin was
not having nontransparent mechanics though. The real problem was not
emphasizing the command that told you all you ever wanted to know about
both a weapon and a monster.

>> I would say large levels densely packed with content and features are
>> much more interesting tactically while being very fun to explore.
>> The key here in my opinion is not small levels. It is densely packed
>> levels. Size is mostly a non-issue.
>
> Both, I'd say. In respect of new players I think small levels lets
> them get to new floors quicker, giving a sense of progress. It also
> doesn't take anything away from the game if done right.

Perhaps starting the game with small levels and progressing to larger
would work. I think Crawl's ziggurats do exactly that. Did not visit
one yet but there are plans of accomplishing this.

>> > Permadeath optional

>> In Dungeons of Dredmor permadeath feels not like the way the game should
>> be played. It feels like equally valid way of playing the game which
>> is endorsed by the developers. This is my gripe with making permadeath
>> a check box.
>
> Yet most players play on permadeath. The mechanic is embraced. And part
> of that embrace is making it clear to the player that it's their choice,
> so when they die and have to restart they can't blame the game. Since
> it's their choice they are more mentally ready to accept it.

This sounds very intriguing. Do you have some data on how big the most
part is? I think there is some research waiting to be made.

> Still, other games like Binding of Isaac get by with straight permadeath,
> so perhaps there's more acceptance for the mechanic than I give outside
> gamers credit for.

Especially because Binding of Isaac is not a roguelike at all. Yep, had
to say this. :-)

--
Michał Bieliński

[Michal Bielinski]

Once upon a time, JO wrote thus:

> First of all. ANY text game is going to turn off players. I'm sorry to
> say this. Very sorry. I can't get my 'hard core' gamer friends to even
> look at Brogue. Ever. Not for a second. Never going to happen.

This is sad but mostly matches with my experience. I got people to play
PRIME by playing it myself on a public terminals at the university
during breaks. Spectators wondered how the heck someone can have a blast
playing such a thing and eventually would try themselves when I left it
on the terminal and pretended to be looking away.

> If you prove me wrong I will tattoo a huge '@' symbol on my face.

Darren, you are getting famous! :-p You might have started a trend.

> 4 way movement is a must. I have no idea why there is resistance to
> this.

I explained it in reply to Darren.

> I prefer it. I play ALL roguelikes with the arrow keys. I
> couldn't even play PRIME until the arrows were implemented (I actually
> did it myself).

But you did not publicize the code and we had to do it ourselves again.
Still thanks again for doing this. As you see we followed in suit.

> Maybe that's why I suck so hard at roguelikes? I dunno.

It contributes but alone it is far from being a determining factor.

> In D&D and ALL other games underground stuff is handled with squares.

Note the movement is not confined to 4-way. At least my GM lets us
go diagonally on combat map divided into squares.

> That's just the way it is. If you go hex you
> will turn non-roguelikers off when going underground.

Maybe roguelikers too. But who knows until its implemented. There were
some hex based mockups of roguelikes. Some were playable.

> Name one top down RPG game that uses hexes. One. Anyone.

*sounds of gears inside a skull moving* Um...

> How are your VI skills?

Top shape!

> Mine too.

Good to know.

I apologize for this evil manipulation. :) I could not resist.

> Roguelikers are huge freakin' weirdos. If it's not Legend playing turn
> based computer games with a gamepad or me dual boxing WoW with one
> hand holding an SNES controller and the other a mouse is really the
> height of eccentric. No. We are ALL eccentric compared to other
> gamers.

No idea whether one should laugh or cry after reading that. Emacs and vim
users are not viewed as eccentric by IDE users. They are just a minority.
Not a crazed minority mind you. I think roguelike game players are also
a small group but one does not have to possess uncommon qualities to
be one.

> The roguelike world is not mainstream,

Does it really need to be?

> No commands requiring shift or control keys?

> The fact that you even felt the need to write
> that leads me to think it's not obvious to you, or others.

It is not obvious to me. Keep in mind it also includes shift-clicks
and control-clicks.

> Also you
> are dead freakin' wrong. It should have read thus..."No commands
> should require keys."

> Show me one turn based game that required a key press.

King's Bounty, the precursor to Heroes of Might and Magic. No mouse
support at all.

> If you dig up something from 20 years ago I've never heard of to
> refute my point I will consider my point well made.

So you reserve to dismiss anything I come up with "just because"? Point
well made indeed. Way to go, Jo.

> Text descriptions of monsters? Look...if you really want to go ascii
> you at least have to list the monsters in view on the side and let
> people click on them to get info.

What a thoughtless waste of screen real estate. It is only useful the
first time you meet each monster. Good for newbies I guess. If it
contained some additional info on monsters like their status and some
indicators of what weapons and armor they have that would have been
better.

> Inventory: Point, click, drag. Nothing else will do.

This is a very reserved view. Maybe there are other way better
alternatives not invented yet?

> Restarting: As soon as you die a pop up menu comes up.

[...]

> Now there's a menu screen...lame.

Indeed, lame. So do not show a menu as soon as you die because it is lame.
Dude, did you read your own post? Contradicting yourself in the very same
paragraph.

> Permadeath: Whether it's good for your game or not depends on how
> quickly it happens, how long the game is, how quickly you can restart
> (do you have to pick a new race, class, name, weapon) and especially
> how varied a start can you give the player?

Varied start is a very important point you make. Many existing roguelikes
could do better in this. DCSS includes some entry vaults to make it
funnier. A step in right direction.

Make sure not to overdo it though. If you die and start in completely
different area what you learned about the former location might seem
totally irrelevant and scare newcomers away.

--
Michał Bieliński

[Radomir Dopieralski]

On 2012-06-08, Darren Grey <darrenj...@gmail.com> wrote:

> On Friday, June 8, 2012 2:28:51 PM UTC+1, Radomir Dopieralski wrote:
>> On 2012-06-06, Darren Grey <darrenj...@gmail.com> wrote:
>> > Space as contextual action Multiple key commands is useful for
>> > fidelity of action, but in 90% of situations there is only one action
>> > that can be performed. So let’s use the biggest key on the board for
>> > it. Stairs? Space to change level. Item on ground? Space to pick up.
>> > Trap? Space to disarm. Door? Space to open/close. There’s situations
>> > where this won’t work, but the exceptions shouldn’t get in the way of
>> > what would be a much smoother experience for most of the game.
>>
>> From my experience with user interfaces, this is a very bad advice.
>> The fact that you *usually* do things in one, easy, way, but occasionally
>> need to do them a different, harder, way, has a number of bad effects:
>>
>> * the "easy" times do not prepare you in any way for the cases when you
>> have to use the "hard" way -- suddenly the way you always used doesn't
>> work and you are left in the void, having to dig through help pages and
>> check the manual
>
> The problem is you shove this same problem in the player's face from the
> get-go, instead of hooking them into the basic gameplay before showing
> them more complexity. And in a well-designed game those help pages should
> be easily accessible, or there should be additional contextual help in
> those "hard" situations.

Sure, easily accessible help pages will soften any problems with learning
the interface, but they will not solve them. On the other hand, it seems
to me that it is equally easy to tell the player "press 'o' to open the door"
as it is to say "press space to open the door".

>> * often the players will not even be aware that there is the "hard" way
>> and will simply assume, that the action is impossible to trigger without
>> standing in an unambiguous position first -- that puts them in a great
>> disadvantage
>
> Potentially, but I'm not sure about the "often" part.

I am sure. I have seen it many times. Once a user finds one way of doing
something that works, they will stick to it and do amazing feats to do it
that way instead of checking for other ways, because, you know, they have
work to do and they are not interested in fiddling with the interface.

> It starts some
> people off at a disadvantage whilst they learn the ropes.

Actually it only adds one more unnecessary rope to learn, one that
actually hides the other, easier ropes.

> But it at least
> keeps people playing. The important thing is to show them the fun parts
> of the game as soon as possible. Let them become masters of the game
> later. Normally they start off the game dying lots anyway. Hoepfully
> death will be the good teacher it's meant to be and they'll pick up on
> how to play better. This applies to other roguelike mechanics too.

I can't see how telling them to press space instead of 'o' makes them
keep playing and encourages them to discover that they can press 'o' too.

> Plus I'd say this already happens. When I started out with ADOM I didn't
> know about things like extended drop, or how to change the tactical
> display to show the energy use per turn, or how to lock doors with keys
> or the pick lock skill. Same with other rare skill and class abilities.
> Over time as I learned various parts of the game I grew to learn these
> too. I'm sure others have had similar experience in other roguelikes.
> I'm just suggesting dropping the bar lower so more people can get into
> the game.

Sure, of course, you can learn the most atrocious interface and even get
to like it once you are used to it. But I can't see how that stops to
apply when you remove the "do something" space key command. You still
need to learn the interface, but now you have one thing less to learn and
one thing less to be confused about...

>> * you can never be sure what will happen -- you have to look carefully in
>> what position you are to know what pressing the space will do, and even
>> then you can misjudge or just don't know one of the many rules that
>> govern the behavior of that magical key
>
> This is why I suggested contextual advice. "You see a key here (space to
> pick up)" etc. For power users there are still the direct keys in the
> background. New players can only take in so many instructions at once,
> especially if they're not used to the standards of the genre. This helps
> ease them in. Otherwise they might get turned off at the first door
> they encounter.

That solves the "you don't know one of the many rules" problem, but not
the "you have to pay attention" problem. Plus, as you say, new players
can only take so many instructions at a time, so why should you design
your interface in sucha a way that additional instructions are necessary?
Just remove the magical space, and suddenly everything is so much easier
to explain!

>> * that requirement of constant attention is what actually slows players
>> down and makes extended play tiring
>
> I'd argue that this is exactly what happens to newcomers to roguelikes.
> Learning the controls is slow and tiring, and it can make the game
> immensely off-putting. As I'm sure you know it can be very hard to
> overcome a negative first impression.

Obviously. But making the interface even more complicated by adding
magical "do what I want" keys doesn't help here.

> Another solution might be to have the early game not involve the same
> number of elements. No doors, no items, no food clock. Show the basic
> combat and interactions, and expand to the full game as you go on. Many
> commercial games do things like this. I'm not fond of the idea myself
> though - it goes against the principals of replayability that roguelikes
> have.

I think it is generally a very good idea to introduce new gameplay
elements slowly as the player becomes more experienced. This is possible
in several ways, but I think it should be gradual and should not involve
telling the player to stop using one set of commands and begin using
another: "don't use space anymore, power users use 'o' to open door". This
is the "advanced interface" fallacy, a well known usability antipattern.

>> Of course, those problems can be worked around by removing features from
>> you game. An excellent example of this is Final Fantasy: Crisis Core,
>> which can be played through and finished by repeatedly pressing a single
>> button.
>
> Haha, I guess that's the way to make roguelikes truly accessible ;)

You can laugh, but this is a real problem and a valid decision you might
want to make. If your game is all about the story (like Crisis Core), or
all about discovering new kinds of monsters, or all about exploring
beautifully rendered fractal levels, then you might want to concentrate
on that. You could remove all the other game elements, but then the game
would feel empty. So you can instead automate them, or nerf them so much
that they don't matter that much -- or maybe that they matter in that if
you actually do them right, you unlock more content.

That is exactly what the "professional" games you referred to do. They can
get away with it because they are mostly about "content" and much less
about the "process". People have bought them and want to be able to see
most of them, even if they don't have the time, attention or skill to
actually master them. So they are made "accessible" in that whatever you
do, you get some kind of progress (or at least you don't get set back).

Now, roguelike games usually simply don't have enough "content" in them
to afford that, and players used to the big AAA titles get frustrated
by them. Of course, the user interface is just a small part of the game
and often not really that frustrating -- but it's the easiest thing to
blame to get an excuse.

Of course that doesn't mean it's OK to make your game's interface hard
to use -- although with games you can never tell where the game ends
and the interface begins. For example, every usability expert would
admit that adding an "auto jump" option to Mario, that would make him
automatically avoid enemies and pits, would be a huge accessibility
booster -- but it would completely remove the fun from the game too.
Some kids would still play it -- just to watch the cute animated
plumber move through beautifully designed levels -- but it wouldn't
be the same anymore.

--
Radomir Dopieralski, sheep.art.pl

[Krice]

On 8 kesä, 14:28, Darren Grey <darrenjohng...@gmail.com> wrote:
> Krice  ;)  Plus there is an attitude amongst some of "If you don't
> bother to learn the controls you don't deserve to play my game".

I have noticed that you need to learn controls and read the
manual even with Nintendo's games. No matter how complex or
simple the controls are you need to learn them to play the
game. I think as a developer that you should never design
for some imaginary group X of people. Always design the game
for yourself, so you can enjoy they game. Of course it can
be good to listen to feedback and maybe give players more
options or improve UI or stuff like that, but really, if you
don't have a crystal clear image of what your game should be,
you are not a good game designer.

[Radomir Dopieralski]

On 2012-06-09, Krice <pau...@mbnet.fi> wrote:
> Of course it can
> be good to listen to feedback and maybe give players more
> options or improve UI or stuff like that, but really, if you
> don't have a crystal clear image of what your game should be,
> you are not a good game designer.

I will bite this one, because it's such a wrong advice.

Having a crystal clear image of what your game should be is the exact
opposite of being a good game designer. It is a sign that you have
designed in your head a fantasy about how a game could look in some
idealized dream world, without actually checking it in any way against the
reality. It means that your design is full of silent assumptions that may
be false and glaring holes that might be impossible to patch up.

The only way to see if your game idea actually has any sense and really
works the way that you think it will work is to implement it and test it
on an actual prototype. And then to keep on tweaking and changing the
implementation (or to discard it and start anew) until your expectations
actually come together with the reality. That also often means changing
the expectations. Having experience in the field can help you make more
accurate predictions and know the problematic areas in advance, which
speeds the process up a lot, but you will never have a crystal clear image
until the game is finished.

With more experience you are more likely to leave the problematic areas
blurry, so that you can fill them in later when your implementation
actually gets to the point where you can test it. Also, with more skill
you will be able to "fix" your design easier and make it fit reality with
less dramatic changes.

Oh, I'm sorry, there is one more case when you can actually have a crystal
clear image of what your game should be. That's when you copy an existing
game exactly. But I wouldn't call that being a good game designer.

The whole "I have trouble with designing my game so maybe I am not worthy"
thing is bogus -- game design is an insanely hard and difficult thing and
it takes years of actually designing and making finished games to learn
it. The fact that your first complete game is not very good doesn't mean
that you just don't have the talent. On the other hand, the fact that you
never even finished a game might mean that you just don't have the spirit
for it.

--
Radomir Dopieralski, sheep.art.pl

[Krice]

On 9 kesä, 22:25, Radomir Dopieralski <n...@sheep.art.pl> wrote:
> The only way to see if your game idea actually has any sense and really
> works the way that you think it will work is to implement it and test it

That's obvious, but if it always worked we would have only good
games released. We know it's not true. Sometimes it may be that
the game isn't finished but an early version, but I think more
often it's because the developer doesn't know what is good
game design. In other words he doesn't have that image in his
head.

[Gerry Quinn]

In article <9e12317d-07be-4e52...@googlegroups.com>,
darrenj...@gmail.com says...

Also, shouldn't the title be "Designing for non-roguelikelikers" :-)

- Gerry Quinn

[Darren Grey]

On Jun 9, 12:15 am, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
> Once upon a time, Darren Grey wrote thus:
>

> > But more than that you have to consider that if you're not going out
> > of your way to consider accessibility and all you do is follow the
> > genre's conventions then essentially you are just making games for
> > existing roguelike players.
>
> Actually I go by the paradigm of making a game that I would like to play.
> This solves motivation issue quite nicely. On the other hand it looks
> like PRIME is going to have two UIs in future. One for seasoned roguelike
> veterans like me and another for everyone else. Maybe it is not so bad.
> Implementing switchable interface will force me to design UI/engine
> division better.

I think the "game I'd like to play" is great for mechanics design, but
for
UI you have to think of other people. If you want your game played by
others at least.

> > If you view it as a constraint...  And importantly, how much of a
> > constraint?  Does it really make that much difference?
>
> Sadly, yes. Jo has warned that weirdos like me tend to respond with
> several reasons why 8-way is better tactically. Here it goes!
>
> While being adjacent to certain enemy there is no space adjacent to
> him you can step into. Z-Day has grinding machines into which you can
> push zombies. It is important to be able to position yourself without
> inviting the monster chewing at you to move. This would ruin the plan.

Yes, I can see that being a serious issue. One solution is to ignore
this and require the player to think more carefully when encountering
a monster how to approach it in order to lead it to the right trap.
The other is have other movement/reposition abilities that let you
get into the appropriate position more easily (whilst also providing
other interesting tactical options).

> You cannot be cornered in a way that makes it possible to hit you
> without getting into dead end. Also, fleeing monsters will always be
> able to evade your melee at will by stepping aside. You need a dead
> end or a corner and another monster to lock it into position to land
> a blow.

Look at it the other way and the complaint would be that 8-way makes
it too easy to corner monsters, or for the player to get cornered and
hit by a single monster. We are used to one standard and deem it to
be the correct one, but if we were to approach it from the other
direction we would see the 8-way system as the flawed one.

Also, this is pretty minor :P

> With 4-way movement a single monster may disallow you to move past it
> by clever enough AI given equal speeds. Makes avoiding monsters more
> difficult. Radomir correctly notes you can make your AI stupider not
> to take advantage of this. I agree with him this is bad thing.

Again can be seen as a positive thing or the "right" thing. If you
want escape options give the player skills tailored towards escape.
ToME4 has a range of interesting abilities that move you or the
enemy about the field, and as well as giving extra escape options
it also makes combat much more dynamic and fun, with lots of
movement around the battlefield.

> Explosions should be diamond-shaped to maintain consistency. After
> all touching diagonally some item is considered being two spaces away.
> This is far uglier than FOV artifacts of 8-way movements. Even square
> FOV (which I consider very ugly) does not feel as artificial IMO. Your
> fireball becomes firediamond.

Just use circles. Geometrically wrong, but this is already the case
in
8-way. In a 4-way system it means the advantage is along the
diagonals
instead of along the cardinals.

> Playing a hydra means you can attack eight enemies instead of only four!
> Okay, I made that up. No idea if any game implements that but in DCSS it
> is possible to have enslaved hydra fight for you. Works monstrously well
> against Vampires' horde of spammals.

Give the hydras extra long necks so they can attack in range 2!
Having
an enemy able to attack diagonally is a perfectly valid special
ability
to implement. The grid bugs in Powder have this for instance.

> > A lot of people moaned about Dredmor only having 4-way movement.
> > It was... well, stupid.  What would diagonal movement add to the game?
>
> Possibility to cram in some more tactical depth.

I think it has plenty of tactical and strategic depth as is. One can
always add more, but 8-way movement isn't the only way to do this.
And
in the scale of the game would make little difference overall.

> > You absolutely do not!  How often have there been stupid threads on
> > here about making diagonal movement cost 1.4 turns?  And the Square
> > LOS considerations to boot.  8-way doesn't make geometric sense.
>
> With maximum metric diagonal movement should cost 1.0 turns to make
> mathematical sense. The square FOV is the price you need to pay. Then
> movement and sight is consistent.

'Tis too high a price! Uglier than diamond in my opinion, actually,
though neither is nice.

> > It's not meant as a partial auto-explore, but an easy way to move
> > several spaces with a single command, letting the computer calculate
> > the optimal route inbetween.
>
> Ah, okay. On NetHack newsgroup someone made a point that NetHack allows
> you to use shortcuts for most common interesting points on level and
> be faster than mouse users. For example hit '>' to move cursor to the
> stairs.

That instance is faster, but if instead you want to move to a specific
item or dungeon feature or simply a certain empty room the mouse is
much quicker. It gives the freedom of choosing whatever target you
like, whilst also being easier to pick up and learn. Of course this
doesn't prevent also having keyboard commands that are faster in
specific circumstances.

> The small problem I see with this the path calculation might drag the
> player character along unfavorable places if a monster was to show up.
> This could be shifted on player's shoulders and handwaved though. One
> should not use the feature when it is not safe to do so.

If a monster shows up then the auto-movement should be interrupted,
as with any multi-turn action.

> > I don't get what you mean by obscure the screen?
> [...]
> > If the list gets too long make it scrollable.
>
> This.

Since it only shows up on right-click this isn't a problem. You can
x out of it or click elsewhere to make the list disappear if you need
to rethink your action. Ideally though you see a monster, think "I'll
fireball him", right click and choose fireball. Obscuring shouldn't
be a problem.

> Throw alone would list your whole inventory on right-click at a monster.
> Unless you meant just "throw" which would open a dialog box? Verb-object
> is better served by the keyboard in my opinion.

Dialogue box all the way. The right-click menu should be for easy
access
to the common commands. More obscure stuff would take longer to get
to.
Keyboard may be faster, but a duplicate way of getting to it by the
mouse
is still more accessible. Plus it can be a handy reminder that
throwing
*is* an option. Too often when faced with a monster you stick to the
few key commands you use frequently, forgetting the more obscure
stuff.
If your right-click menu reminds you that you can throw an item at the
monster then you're more likely to remember this in important
situations.

> > Everyone knows how to use the mouse.
>
> Almost no one can use the mouse with precision though. This is why some
> programs have snap to grid feature. Do not take your expertise (yes!)
> with the input tool as granted. I've seen people confuse left and right
> clicks sometimes.

There is also the problem with laptops, where the mouse is slower to
use
and scroll bars are less usable. Which is why I think everything
should
be duplicated to both keyboard and mouse control, and both should be
customisable to a certain degree. Like I said elsewhere, I generally
play
ToME4 using both keyboard and mouse, but sometimes switch to primarily
one or the other. You'll always find players that only want one or
the
other, so for maximum satisfaction you have to support both.

> > Put another way, if Rogue had done it like this then every roguelike
> > since would have still copied it.
>
> Wrong assumption. Roguelikes copy Rogue because it was good. If a solution
> implemented inside it had been feeble it would not make to modern RLs.

Why so many games with bad hunger clocks then? Or with poorly
implemented
id systems? Rogue did many things right that other games copied to
bad
effect.

> >> > Tell a player to press < and he’ll press the , key, and then wonder
> >> > why it didn’t work.
>
> >> The don't know how to use the keyboard properly? I don't buy it.
>
> > Maybe I should change to title to "How to Make Roguelikes Playable for
> > Idiots"  ;)  Honestly, I have seen this!  Multiple times!
>
> Okay, my friend recently did it in front of me. He realized what was going
> on from my shocked expression but it is reality! Man, I seem to take my
> familiarity with keyboard as granted.

One way of getting around this is doubling the key commands - have
both
? and / do the same thing for instance. However this can have weird
problems in different keyboard layouts.

> >> > W for Wear will confuse many roguelikers,
>
> >> Perhaps you wanted to say non-roguelikers? Very few RLs have W bound to
> >> something else than wield or wear.
>
> > No, I meant roguelikers.  With a background in ADOM I am always
> > flummuxed by games with Nethack-esque inventory systems.
>
> Of major roguelikes only ADOM has W assigned to something other. I guess
> most roguelikers wouldn't be confused by that. Just the part of player
> base sticking only to ADOM and games inspired by it.

Title of the thread is designing for non-roguelikers. My point with
this is that even veteran roguelikers can be confused by what you
think is standard.

> > Part of making the log
> > good is getting rid of the chaff like the hit and miss notifications.
> [...]
> > The log should not be used to
> > communicate every petty detail to the player.
>
> Have you seen how Sil does this? It essentially has two logs. One for
> combat data where rolls are displayed in technical format and the other
> ordinary log for narration. It works surprisingly well.

Hmm, will check this out. Does it have both logs displayed at once?

> > Yes, but it bears reminding  :)  I've played many 7DRLs with obscure
> > mechanics, which seems the absolute worst place to have them since few
> > will replay the game often.  The biggest offender is in item mechanics,
> > with weapons and armour not showing their power and special items not
> > saying at all what they do.
>
> Oh, the Sword Tester roguelike by Oohara Yuma. I loved it. Its sin was
> not having nontransparent mechanics though. The real problem was not
> emphasizing the command that told you all you ever wanted to know about
> both a weapon and a monster.

I've not played that one, but in general a lot of 7DRLs have poorly
documented features. Even my favourite of them all, PrincessRL, has
special items with no clue as to their usage. Am I meant to find out
through extensive play that the Azure Orb (only acquired with 2% of
chars) gives +1 to spell range? And there's all sorts of other
problems with not being given any info on special abilities beyond
their names, or no clue as to what monsters do. Sometimes secrets are
nice to have in a game, but proper documentation should help make it
less of a guessing game.

> >> >  Permadeath optional
> >> In Dungeons of Dredmor permadeath feels not like the way the game should
> >> be played. It feels like equally valid way of playing the game which
> >> is endorsed by the developers. This is my gripe with making permadeath
> >> a check box.
>
> > Yet most players play on permadeath.  The mechanic is embraced.  And part
> > of that embrace is making it clear to the player that it's their choice,
> > so when they die and have to restart they can't blame the game.  Since
> > it's their choice they are more mentally ready to accept it.
>
> This sounds very intriguing. Do you have some data on how big the most
> part is? I think there is some research waiting to be made.

I think on the podcast they said something like 75%. Looking at their
achievements on Steam the non-permadeath victories are slightly higher
than the permadeath victories. Certainly within the their forum
community
there is an acceptance that permadeath is the way to go, and a lot of
pride
in permadeath victories. I don't think there would be such an
attitude if
it wasn't made optional

> > Still, other games like Binding of Isaac get by with straight permadeath,
> > so perhaps there's more acceptance for the mechanic than I give outside
> > gamers credit for.
>
> Especially because Binding of Isaac is not a roguelike at all. Yep, had
> to say this. :-)

Heh, well I'll not get into that debate (mostly because I'm fairly
non-plussed about the game). There are other games with permadeath or
permafailure too, including a growing number of MMOs. There might be
more
of an appetite for the mechanic than some of us realise.

--
Darren Grey

[Darren Grey]

On Jun 8, 5:51 pm, Gerry Quinn <gerr...@gmail.com> wrote:
>
> 6-way versus 8-way is an interesting choice because both have
> advantages.  I think the reason 6-way is uncommon in roguelikes comes
> down to three main reasons:
>
> 1. There's no obvious way to map it to the numpad.  You'd *think* that a
> hexagon of keys such as U-I, H-J-K, N-M would work well, but for some
> reason it doesn't seem to.

To numpad? 789/123, with 4 and 6 alternating between each diagonal
each turn.

> 2. It maps poorly to rectilinear buildings and dungeons (as distinct
> from the outdoors).

True. And hex buildings look odd. I'm not too worried about this
myself though.

> 3. The geometric artefacts of 8-way, while worse than those of hex, are
> much more tolerable than those of 4-way.

Eh, they ain't so bad. I think we're just used to the 8-way artefacts
more. I think also as designers we notice and worry over such
artefacts a hell of a lot more than actual players do.

> > And to clarify, I don't like 4-way all that much myself.  I'm just saying
> > it's an important consideration if you want to reach beyond the core
> > roguelike audience.
>
> Seems to me that people are happy with diagonal movement in games like
> Diablo.  And I find it hard to believe that it won't be obvious that you
> can move diagonally.  After all, players will see monsters doing it all
> the time.

Have you not watched people try to play roguelikes? Even when they
figure out diagonals they're so unused to controlling diagonal
movement by keyboard that they slow down immensely when they're
required to do so. But with mouse control it's really not such an
issue.

--
Darren Grey

[Darren Grey]

On Jun 9, 3:48 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

> On 2012-06-08, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > On Friday, June 8, 2012 2:28:51 PM UTC+1, Radomir Dopieralski wrote:

> >> On 2012-06-06, Darren Grey <darrenjohng...@gmail.com> wrote:
> >> >   Space as contextual action Multiple key commands is useful for
> >> >   fidelity of action, but in 90% of situations there is only one action
> >> >   that can be performed. So let’s use the biggest key on the board for
> >> >   it. Stairs? Space to change level. Item on ground? Space to pick up.
> >> >   Trap? Space to disarm. Door? Space to open/close. There’s situations
> >> >   where this won’t work, but the exceptions shouldn’t get in the way of
> >> >   what would be a much smoother experience for most of the game.
>
> >> From my experience with user interfaces, this is a very bad advice.
> >> The fact that you *usually* do things in one, easy, way, but occasionally
> >> need to do them a different, harder, way, has a number of bad effects:
>
> >> * the "easy" times do not prepare you in any way for the cases when you
> >>   have to use the "hard" way -- suddenly the way you always used doesn't
> >>   work and you are left in the void, having to dig through help pages and
> >>   check the manual
>
> > The problem is you shove this same problem in the player's face from the
> > get-go, instead of hooking them into the basic gameplay before showing
> > them more complexity.  And in a well-designed game those help pages should
> > be easily accessible, or there should be additional contextual help in
> > those "hard" situations.
>
> Sure, easily accessible help pages will soften any problems with learning
> the interface, but they will not solve them. On the other hand, it seems
> to me that it is equally easy to tell the player "press 'o' to open the door"
> as it is to say "press space to open the door".

Yes, if you have this in the interface it's not such a problem. And
obviously something you can turn off in the options too. My issue is
more with starting a game, checking the help file, and seeing 20
different commands you need to know to play. Without contextual help
this is very off-putting. But it's especially painful when 99% of the
time you're not using those extra commands - you can start the player
off with just a subset and they'll do fine.

> >> * often the players will not even be aware that there is the "hard" way
> >>   and will simply assume, that the action is impossible to trigger without
> >>   standing in an unambiguous position first -- that puts them in a great
> >>   disadvantage
>
> > Potentially, but I'm not sure about the "often" part.
>
> I am sure. I have seen it many times. Once a user finds one way of doing
> something that works, they will stick to it and do amazing feats to do it
> that way instead of checking for other ways, because, you know, they have
> work to do and they are not interested in fiddling with the interface.

True, and this is something I've seen with the 4-way vs 8-way
problem. Player finds they can move and attack just fine with 4
directions, they don't bother to learn about the diagonal controls.
Should we remove the arrow key support to stop this happening?

> > It starts some
> > people off at a disadvantage whilst they learn the ropes.
>
> Actually it only adds one more unnecessary rope to learn, one that
> actually hides the other, easier ropes.

It's about short-term vs long-term ease. In the short term one
unified key is easier. In the long term multiple dedicated keys is
easier. So do you want to catch new players in or support longer term
players better? There is a balance to be weighed, and each developer
will make their own choice.

> >> Of course, those problems can be worked around by removing features from
> >> you game. An excellent example of this is Final Fantasy: Crisis Core,
> >> which can be played through and finished by repeatedly pressing a single
> >> button.
>
> > Haha, I guess that's the way to make roguelikes truly accessible  ;)
>
> You can laugh, but this is a real problem and a valid decision you might
> want to make. If your game is all about the story (like Crisis Core), or
> all about discovering new kinds of monsters, or all about exploring
> beautifully rendered fractal levels, then you might want to concentrate
> on that. You could remove all the other game elements, but then the game
> would feel empty. So you can instead automate them, or nerf them so much
> that they don't matter that much -- or maybe that they matter in that if
> you actually do them right, you unlock more content.

True, though I'm not sure that automated filler is really a good
thing. Certainly doesn't appeal to me as a designer. Some players
may like it but I guess they're not part of my intended audience. I
like making focussed games.

> Now, roguelike games usually simply don't have enough "content" in them
> to afford that, and players used to the big AAA titles get frustrated
> by them. Of course, the user interface is just a small part of the game
> and often not really that frustrating -- but it's the easiest thing to
> blame to get an excuse.

Well, from my experience of watching people trying to play roguelikes
and encouraging friends to play them I think UI is by far the biggest
thing. Some people are put off by the difficulty and the permadeath -
fine, they're not the audience for the genre. A few don't like the
lack of graphics - fine, screw them ;) But many are perfectly okay
with these elements but simply can't get around the long list of key
commands or the lack of easy mouse support. UI is almost universally
done poorly in roguelikes, with all the focus being on the mechanics
and interactions in the game. So we have a genre of games with great
mechanics but this steep learning curve to ever get into the games.
Many gamers just can't get over that curve.

My suggestions are mostly borne from watching others try to play my
games. It is a horrible and painful experience that I suggest all
developers put themselves through ;) Most feedback we get is from
other roguelike players online, meaning we have a very insular view of
what is good and bad.

> Of course that doesn't mean it's OK to make your game's interface hard
> to use -- although with games you can never tell where the game ends
> and the interface begins. For example, every usability expert would
> admit that adding an "auto jump" option to Mario, that would make him
> automatically avoid enemies and pits, would be a huge accessibility
> booster -- but it would completely remove the fun from the game too.
> Some kids would still play it -- just to watch the cute animated
> plumber move through beautifully designed levels -- but it wouldn't
> be the same anymore.

None of my suggestions have involved automating any gameplay or
removing basic depth from the mechanics of play (apart from 4-way,
arguably). They are about simplifying access to the mechanics of the
game or providing more guidance on how the game operates to the
player. Many of these things benefit existing players as much as new
ones.

There are some grey areas between game and interface, but I find it
hard to justify the idea that learning 60 key commands is really a
core part of the roguelike game experience. If we can find ways to
cut down the keyboard requirements without impacting on the gameplay
then we should make efforts to accommodate this.

--
Darren Grey

[Gerry Quinn]

In article <dff0c6f6-03f4-405c-aaa3-4455e19ebfc0@
3g2000vbx.googlegroups.com>, darrenj...@gmail.com says...

> On Jun 8, 5:51 pm, Gerry Quinn <gerr...@gmail.com> wrote:
> >
> > 6-way versus 8-way is an interesting choice because both have
> > advantages.  I think the reason 6-way is uncommon in roguelikes comes
> > down to three main reasons:
> >
> > 1. There's no obvious way to map it to the numpad.  You'd *think* that a
> > hexagon of keys such as U-I, H-J-K, N-M would work well, but for some
> > reason it doesn't seem to.
>
> To numpad? 789/123, with 4 and 6 alternating between each diagonal
> each turn.

I meant 'keyboard' of course. The keys I mentioned are normally laid
out in a hexagon.

> > 2. It maps poorly to rectilinear buildings and dungeons (as distinct
> > from the outdoors).
>
> True. And hex buildings look odd. I'm not too worried about this
> myself though.
>
> > 3. The geometric artefacts of 8-way, while worse than those of hex, are
> > much more tolerable than those of 4-way.
>
> Eh, they ain't so bad. I think we're just used to the 8-way artefacts
> more. I think also as designers we notice and worry over such
> artefacts a hell of a lot more than actual players do.
>
> > > And to clarify, I don't like 4-way all that much myself.  I'm just saying
> > > it's an important consideration if you want to reach beyond the core
> > > roguelike audience.
> >
> > Seems to me that people are happy with diagonal movement in games like
> > Diablo.  And I find it hard to believe that it won't be obvious that you
> > can move diagonally.  After all, players will see monsters doing it all
> > the time.
>
> Have you not watched people try to play roguelikes? Even when they
> figure out diagonals they're so unused to controlling diagonal
> movement by keyboard that they slow down immensely when they're
> required to do so. But with mouse control it's really not such an
> issue.

I admit I haven't weatched them much. But diagonal movement in games is
hardly uncommon.

In any case, I lean towards mouse control so the issue doesn't affect me
much.

- Gerry Quinn

[Radomir Dopieralski]

On 2012-06-11, Darren Grey <darrenj...@gmail.com> wrote:
> On Jun 9, 12:15 am, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
>> Once upon a time, Darren Grey wrote thus:
>>
>> > But more than that you have to consider that if you're not going out
>> > of your way to consider accessibility and all you do is follow the
>> > genre's conventions then essentially you are just making games for
>> > existing roguelike players.
>>
>> Actually I go by the paradigm of making a game that I would like to play.
>> This solves motivation issue quite nicely. On the other hand it looks
>> like PRIME is going to have two UIs in future. One for seasoned roguelike
>> veterans like me and another for everyone else. Maybe it is not so bad.
>> Implementing switchable interface will force me to design UI/engine
>> division better.
>
> I think the "game I'd like to play" is great for mechanics design, but
> for UI you have to think of other people. If you want your game played by
> others at least.

Two things to mention here.

The first problem is that most of the suggestions in your initial article
are game mechanic changes, not just user interface changes. Those changes
are there to close the gap between the user's preconceived mental model of
how all the computer games should work, and the model actually used in the
roguelike game in question. This gap cannot be closed by just adding
interface features -- although good presentation and discoverability can
make the discrepancy more obvious and allow the players to adjust their
mental models easily. Unfortunately, the process of changing your mental
models is inherently confusing, demanding intellectually and tiring --
even with excellent feedback through the interface. That means that in
order to invite the large group of players who are unwilling to learn
a new game, you are required to make your game similar to the games they
already know -- and that explains why most of your suggestions touch the
gameplay one way or other.

The second problem is with designing for imaginary people. Don't do that.
Don't try to guess what they would find comfortable -- do what is
comfortable for you (assuming you are a human), because that is the
fastest and easiest to test, and then test it on some specimen from your
intended target audience. Rinse and repeat. If you can't afford a test
subject, test on yourself and hope that the other players are similar.

(By the way, you want to make sure that you are not making your victims
used to your interface over the repeated test sessions. That's where
closed betas come in handy. Collect a list of people interested in testing
the game, and every time you change something important in the interface,
send the test link to another batch of people. This way you get to test
multiple solutions on virgin players. If you just provided a public beta,
that would not be possible.)


--
Radomir Dopieralski, sheep.art.pl

[Radomir Dopieralski]

On 2012-06-11, Darren Grey <darrenj...@gmail.com> wrote:

> On Jun 9, 3:48 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

By the way, the thing I remove from those posts are usually the things
that I agree with and don't have anything to add. Sorry if it makes me
sound all negative. I hope you don't mind.

>> Of course that doesn't mean it's OK to make your game's interface hard
>> to use -- although with games you can never tell where the game ends
>> and the interface begins. For example, every usability expert would
>> admit that adding an "auto jump" option to Mario, that would make him
>> automatically avoid enemies and pits, would be a huge accessibility
>> booster -- but it would completely remove the fun from the game too.
>> Some kids would still play it -- just to watch the cute animated
>> plumber move through beautifully designed levels -- but it wouldn't
>> be the same anymore.
>
> None of my suggestions have involved automating any gameplay or
> removing basic depth from the mechanics of play (apart from 4-way,
> arguably). They are about simplifying access to the mechanics of the
> game or providing more guidance on how the game operates to the
> player. Many of these things benefit existing players as much as new
> ones.

I actually went back and counted :)

Six out of seventeen of your suggestions (that's over 35%) are about
automating gameplay mechanics. That doesn't count things like removing
permadeath and making small levels, which could qualify as "removing
basic depth from the mechanics" if I was nitpicking.

> There are some grey areas between game and interface, but I find it
> hard to justify the idea that learning 60 key commands is really a
> core part of the roguelike game experience. If we can find ways to
> cut down the keyboard requirements without impacting on the gameplay
> then we should make efforts to accommodate this.

Learning 60 key commands is a side effect -- the actual core part is
having a choice of 60 different actions you can perform at any given
moment. It's possible to make the learning easier, for example by
making the commands composable and consistent, and also by providing
hints and good feedback -- no disagreement here. But once you start to
limit the number of keys by removing the choices, you are certainly
changing the core roguelike experience.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Jun 11, 1:34 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

> On 2012-06-11, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > On Jun 9, 3:48 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:
>
> By the way, the thing I remove from those posts are usually the things
> that I agree with and don't have anything to add. Sorry if it makes me
> sound all negative. I hope you don't mind.

Same here! I know you're not being negative for negative's sake, and
I enjoy talking over these things. The bits I remove are generally
where I agree with your points or see no reason to retread. I never
intended the list to be commandments all devs should follow, or even
myself, and appreciate that everyone has their own approach, their own
audience, their own game.

> > None of my suggestions have involved automating any gameplay or
> > removing basic depth from the mechanics of play (apart from 4-way,
> > arguably).  They are about simplifying access to the mechanics of the
> > game or providing more guidance on how the game operates to the
> > player.  Many of these things benefit existing players as much as new
> > ones.
>
> I actually went back and counted :)
>
> Six out of seventeen of your suggestions (that's over 35%) are about
> automating gameplay mechanics. That doesn't count things like removing
> permadeath and making small levels, which could qualify as "removing
> basic depth from the mechanics" if I was nitpicking.

Which 6, I must ask? And how are you defining "automating"? :P

Hmm, and I forgot about my permadeath line... But then it's one of
the things I suggested that I wouldn't do myself. Same with 4-way
movement. Smaller levels I think doesn't have to impact on the
gameplay, but then it depends on the game itself. Of course
definitions of "small" may vary.

On top of the small suggestion would be the idea of seamless level
change, like in Vicious Orcs. Replaces stairs with a more tactical
environment, whilst also being more intuitive in certain ways. But it
comes with a much bigger design overhead, and its own elements of
confusing exlporation.

> > There are some grey areas between game and interface, but I find it
> > hard to justify the idea that learning 60 key commands is really a
> > core part of the roguelike game experience.  If we can find ways to
> > cut down the keyboard requirements without impacting on the gameplay
> > then we should make efforts to accommodate this.
>
> Learning 60 key commands is a side effect -- the actual core part is
> having a choice of 60 different actions you can perform at any given
> moment.

Well, that rather depends on the game, since in many there aren't that
many actions one could choose to do at any one time. For a simple
enough game space as generic action may be appropriate.

> It's possible to make the learning easier, for example by
> making the commands composable and consistent, and also by providing
> hints and good feedback -- no disagreement here. But once you start to
> limit the number of keys by removing the choices, you are certainly
> changing the core roguelike experience.

Agreed, but not always for the worse, and depending on the game one
can improve gameplay and interface in tandem. Right-click on a target
for a list of actions is a good example of this I think - there may be
actions in there you had forgotten about or didn't properly know
about, so the gameplay depth jumps out a lot more whilst also being
more accessible.

--
Darren Grey

[Darren Grey]

On Jun 11, 1:15 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

> The second problem is with designing for imaginary people. Don't do that.
> Don't try to guess what they would find comfortable -- do what is
> comfortable for you (assuming you are a human), because that is the
> fastest and easiest to test, and then test it on some specimen from your
> intended target audience. Rinse and repeat. If you can't afford a test
> subject, test on yourself and hope that the other players are similar.

My article was specifically triggered by watching people try to play
my games. Most of the suggestions are to solve individual issues they
had with learning the interface - either by providing more info or by
removing interface obstacles. Also we're all capable of empathy and
putting ourselves in other people's shoes - if we see that there's
something we understand that others might not then we should pre-empt
problems before they arise. Especially if they are quick fixes. But
more importantly if they are integral to the game. If you want your
game to have 4-way movement so that it's more accessible then you need
to design around that from the very beginning. It's no use trying to
shoe-horn in things like that later.

And as well as learning from testing we should be learning from
previous games we've made and looking at games others have made.
Which is why more examples would help improve this article :) We all
find things out by making games and testing them on people - we should
be sharing that knowledge in the same way we share code and algorithms
and mechanics. I was hoping people would chip in more ideas to this
thread!

> (By the way, you want to make sure that you are not making your victims
> used to your interface over the repeated test sessions. That's where
> closed betas come in handy. Collect a list of people interested in testing
> the game, and every time you change something important in the interface,
> send the test link to another batch of people. This way you get to test
> multiple solutions on virgin players.  If you just provided a public beta,
> that would not be possible.)

What a lovely luxury that would be :) But then that's partly what
the Roguelike Incubator Project is about... It's easier to get such
testers if your game is accessible from the first. Ideally testers
should be for bug-fixing, balance and new gameplay ideas, and a bit of
polish on the interface - not radical changes.

--
Darren Grey

[Radomir Dopieralski]

On 2012-06-11, Darren Grey <darrenj...@gmail.com> wrote:

> On Jun 11, 1:34 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:
>> On 2012-06-11, Darren Grey <darrenjohng...@gmail.com> wrote:

>> > None of my suggestions have involved automating any gameplay or
>> > removing basic depth from the mechanics of play (apart from 4-way,
>> > arguably).  They are about simplifying access to the mechanics of the
>> > game or providing more guidance on how the game operates to the
>> > player.  Many of these things benefit existing players as much as new
>> > ones.
>>
>> I actually went back and counted :)
>>
>> Six out of seventeen of your suggestions (that's over 35%) are about
>> automating gameplay mechanics. That doesn't count things like removing
>> permadeath and making small levels, which could qualify as "removing
>> basic depth from the mechanics" if I was nitpicking.
>
> Which 6, I must ask? And how are you defining "automating"? :P

1. 4-way movement -- greatly simplify the movement (OK, this one is moot)
2. Mouse control -- basically auto-travel and pathfinding
4. Auto stairs use
8. Space as contextual action
10. Easy inventory access -- automate container management
15. Quick restarting -- automate character generation

[snip]

> On top of the small suggestion would be the idea of seamless level
> change, like in Vicious Orcs. Replaces stairs with a more tactical
> environment, whilst also being more intuitive in certain ways. But it
> comes with a much bigger design overhead, and its own elements of
> confusing exlporation.

I like levels, they give you a sense of closure and let you concentrate
on a small part of the dungeon -- at least as long as the monsters don't
travel between them too much.

But I do like placing stairs as doors, and climbing/descending them the
same way as you walk into the doors -- especially since it makes them so
much easier to show graphically.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Jun 11, 5:52 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:
> On 2012-06-11, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > Which 6, I must ask?  And how are you defining "automating"?  :P
>
> 1. 4-way movement -- greatly simplify the movement (OK, this one is moot)
> 2. Mouse control -- basically auto-travel and pathfinding

Can be used without auto-travel, simply taking you one step in the
direction you click. Tedious like that though. Personally I prefer
numpad for movement with mouse for targeting + menus. Keyboard
control of menus is horribly slow.

> 4. Auto stairs use
> 8. Space as contextual action
> 10. Easy inventory access -- automate container management

If a game has containers - many don't. But then if they're a core
part of the gameplay keep them in and find a way to make them easy to
use. My point on easy inventory access was more to get away from
Nethack style inventory interface to something more friendly, like
ADOM's. Or better yet a drag and drop with character doll and item
type tabs like ToME4 (though obviously that's more effort to make).

> 15. Quick restarting -- automate character generation

Any game should have a quickstart option. Roguelikes especially. Do
any roguelikes not have a "random character" option on start? Or some
similar preset to make generation quicker? I'm just saying have this
on death as well to keep people playing. Or some sort of hook. Don't
just exit on death.

Anyway, most of these are pretty minor automations, if at all - a far
cry from automating jump in Mario. You *can* add auto-fighting in
roguelikes, and autoexplore, but I find both of these "solutions" to
problems to be more indicative of something cancerous in the gameplay
that needs a much better fix.

And we have this rot of sorts now in that many Crawl players won't
touch other roguelikes which don't have autoexplore, since they're so
conditioned to it. It reminds me of quicktime events - in mainstream
games developers responded to the complaint of long cutscenes without
interaction by having the player press X now and then mid-scene,
without addressing the base complaint. Autoexplore is the turn-based
equivalent of quicktime events - a hack to overcome the base problem
of boring dungeons.

> > On top of the small suggestion would be the idea of seamless level
> > change, like in Vicious Orcs.  Replaces stairs with a more tactical
> > environment, whilst also being more intuitive in certain ways.  But it
> > comes with a much bigger design overhead, and its own elements of
> > confusing exlporation.
>
> I like levels, they give you a sense of closure and let you concentrate
> on a small part of the dungeon -- at least as long as the monsters don't
> travel between them too much.

Yeah, and they let you have a sense of progress. Especially with
frequent deaths it's nice to say "I made it to level 10 this game".

--
Darren Grey

[Michal Bielinski]

Once upon a time, Darren Grey wrote thus:
> On Jun 9, 12:15 am, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
>> Actually I go by the paradigm of making a game that I would like to play.
>> This solves motivation issue quite nicely.
>

> I think the "game I'd like to play" is great for mechanics design, but
> for UI you have to think of other people. If you want your game played
> by others at least.

Keeping in mind if I make UI that I dislike using the game loses its
primary developer. There are people like Kornel Kisielewicz who are
not afraid to be unskilled at their own game and play it rarely. I am
not one of them. Whenever I lose interest in playing certain roguelike
the development perspectives for it fade too. Things that I can be
programming for eternity are GenRogues - art on the code side but
no game.

>> While being adjacent to certain enemy there is no space adjacent to
>> him you can step into.
>

> Yes, I can see that being a serious issue. One solution is to ignore
> this and require the player to think more carefully when encountering
> a monster how to approach it in order to lead it to the right trap.

Handwaving is no solution. Pretending there is no problem does not make
it go away.

> The other is have other movement/reposition abilities that let you
> get into the appropriate position more easily (whilst also providing
> other interesting tactical options).

With 8-way having such abilities can be a reward. With 4-way they
become necessity. Instead of having an option to use fancy positioning
ability you force it. One potential choice less.

>> You cannot be cornered in a way that makes it possible to hit you
>> without getting into dead end. Also, fleeing monsters will always be
>> able to evade your melee at will by stepping aside. You need a dead
>> end or a corner and another monster to lock it into position to land
>> a blow.
>
> Look at it the other way and the complaint would be that 8-way makes
> it too easy to corner monsters, or for the player to get cornered and
> hit by a single monster. We are used to one standard and deem it to
> be the correct one, but if we were to approach it from the other
> direction we would see the 8-way system as the flawed one.

What standard? Fleeing monsters are really irritating for the player.
One *should* be able to corner morale-broken creatures without much
effort.

>> With 4-way movement a single monster may disallow you to move past it
>> by clever enough AI given equal speeds. Makes avoiding monsters more
>> difficult. Radomir correctly notes you can make your AI stupider not
>> to take advantage of this. I agree with him this is bad thing.
>
> Again can be seen as a positive thing or the "right" thing. If you
> want escape options give the player skills tailored towards escape.

Do you see the pattern? For the failures of 4-way you need to introduce
special abilities to make up for what was but a simple movement in 8-way.
In MPRDB you can execute attacks as you pass by. That would be impossible
if you restricted movement to cardinal directions.

>> Explosions should be diamond-shaped to maintain consistency.
>

> Just use circles. Geometrically wrong, but this is already the case
> in 8-way. In a 4-way system it means the advantage is along the
> diagonals instead of along the cardinals.

Consistency is important because it allows the player to grasp the concept
behind the game that the interface is merely communicating.

>> Playing a hydra means you can attack eight enemies instead of only four!
>> Okay, I made that up. No idea if any game implements that but in DCSS it
>> is possible to have enslaved hydra fight for you. Works monstrously well
>> against Vampires' horde of spammals.
>
> Give the hydras extra long necks so they can attack in range 2!

That would yield following attack pattern:

..*..
.***.
*****
.***.
..*..

So, how do you execute attack on the creatures in this situation:

..g..
.....
g.H.g
.....
..g..

All g's are in your range but bump to attack is impossible. I can hear
you say implement a special ability. What, another ability? Come on,
it is easier to just be consistent. Less burden on players too. Why
have them learn dozens of rules for cases which do not match general
rules? At worst you may create a mish-mash of rules that seem exactly
like the right thing on their own but make no sense at all when viewed
as a whole.

>> Possibility to cram in some more tactical depth.
>
> I think it has plenty of tactical and strategic depth as is. One can
> always add more, but 8-way movement isn't the only way to do this.

Sure, it is not. For example 7-way is very nice too. Hyperbolic Rogue
is fun game. However, I regard 4-way movement among the top ways to
limit tactical depth. The entry lowering you barter for it is simply
not worth it to me. As you say it is possible to reach similar levels
of tactical depth but this requires quirky AI, special abilities or
gameplay redesign. You could use the time instead to create content
or new fabulous mechanics.

>> Ah, okay. On NetHack newsgroup someone made a point that NetHack allows
>> you to use shortcuts for most common interesting points on level and
>> be faster than mouse users. For example hit '>' to move cursor to the
>> stairs.
>
> That instance is faster, but if instead you want to move to a specific
> item or dungeon feature or simply a certain empty room the mouse is
> much quicker.

The argument at rgr.nethack was these instances are few and far between
in comparison with picking a specific point. Anyway I agree that mouse
is better for selecting arbitrary points so there should be no reason
to drag this much further.

>> The small problem I see with this the path calculation might drag the
>> player character along unfavorable places if a monster was to show up.
>> This could be shifted on player's shoulders and handwaved though. One
>> should not use the feature when it is not safe to do so.
>
> If a monster shows up then the auto-movement should be interrupted,
> as with any multi-turn action.

My point is it is too late then. Crawl autoexplore was famous for getting
you killed in its early stage of development because it cut corners and
put your deep elf in front of an ogre who prompty oneshotted the
unfortunate adventurer. It fulfills your condition. The autoexplore
algorithm stopped when monster was sighted.

Any auto movement will be worse than human guidance. Now Crawl autoexplore
is much safer but at the time woefully inefficient. You can save quite
a lot of food if you explore manually using shifted directions.

In my opinion if you design your levels right such mechanic will not be
needed. And better not give it because then players will use it instead
of learning how to navigate efficiently and safely.

[big list of actions on right-click]

>
> Since it only shows up on right-click this isn't a problem. You can
> x out of it or click elsewhere to make the list disappear if you need
> to rethink your action. Ideally though you see a monster, think "I'll
> fireball him", right click and choose fireball. Obscuring shouldn't
> be a problem.

If the user is comfortable with selecting fireball from his huge list
by mouse who I am to prevent him? Just like selecting action from drop
down menu. You have won me over in this case.

> Keyboard may be faster, but a duplicate way of getting to it by the
> mouse is still more accessible.

That does not mean you need to make everything possible through the
mouse. Quite contrary you are better off leaving so

> Plus it can be a handy reminder that throwing
> *is* an option. Too often when faced with a monster you stick to the
> few key commands you use frequently, forgetting the more obscure
> stuff.

It is not interface's job to do this. If I were to constantly remind
the player of every thing he can do my game would continuously run out
of screen space.

>> > Put another way, if Rogue had done it like this then every roguelike
>> > since would have still copied it.
>>
>> Wrong assumption. Roguelikes copy Rogue because it was good. If a solution
>> implemented inside it had been feeble it would not make to modern RLs.
>
> Why so many games with bad hunger clocks then?

Because it was good thing in Rogue.

> Or with poorly implemented id systems? Rogue did many things right that
> other games copied to bad effect.

You are proving my point. Only the good things in Rogue get consistently
copied (right or wrong).

My turn! What modern roguelike game has the stick of draining working the
same way Rogue had it? Hint: there is one game that has a scroll that works
his way.

>> >> > W for Wear will confuse many roguelikers,

[snip my disbelief]

>
> Title of the thread is designing for non-roguelikers. My point with
> this is that even veteran roguelikers can be confused by what you
> think is standard.

First, who the heck thinks W for Wear is some kind of standard? It is
just a good mnemonic. Popular, sure. No standard though. Second, the keys
that may confuse veterans are ones rarely used. D for Drink would be
something that has greater chances for inducing confusion. As W for Wear
being confusing I could as well make the argument that mouse support
might confuse roguelike veterans.

>> > Part of making the log
>> > good is getting rid of the chaff like the hit and miss notifications.
>>

>> Have you seen how Sil does this? It essentially has two logs. One for
>> combat data where rolls are displayed in technical format and the other
>> ordinary log for narration. It works surprisingly well.
>
> Hmm, will check this out. Does it have both logs displayed at once?

Yes. Make sure your terminal is big enough to contain both. In the thread
recently necroed by Scatha at the Temple of Roguelike forums you can see
a screenshot in first post.


Thank you for information on Dredmor approach to permadeath. Some food
for thought.

--
Michał Bieliński

[Michal Bielinski]

Once upon a time, Darren Grey wrote thus:

> On Jun 9, 3:48 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:
>> Once a user finds one way of doing
>> something that works, they will stick to it and do amazing feats to do it
>> that way instead of checking for other ways, because, you know, they have
>> work to do and they are not interested in fiddling with the interface.
>
> True, and this is something I've seen with the 4-way vs 8-way
> problem. Player finds they can move and attack just fine with 4
> directions, they don't bother to learn about the diagonal controls.
> Should we remove the arrow key support to stop this happening?

Kill them. Continue to do so until they learn. Some examples to draw from:

ADOM: Standing diagonally to doors means you never get hit by falling
stone block trap which can murder starting characters outrigt. Also
booby trapped doors destroy much less items when you stand aside and
automatically partially dodge the explosion.

DoomRL: Moving diagonally constantly through rectangular rooms gives you
dodge bonus which greatly increases your chances of avoiding surprise
attack.

DCSS: The checkerboard areas sometimes generated can be navigated only
by using diagonals. You can abstain from exploring them but then have
fun with centaurs until they run out of arrows.

PRIME: Cylon centurions mercilessly gun you down from diagonals. When you
move to side so that you may line up cardinally with them they counter
that by immediately re-lining with you on diagonal line.

Some games like NetHack and PRIME feature grid bugs that do not attack
diagonally. In PRIME they teach you that abusing diagonals can be fun
thing to do. When you learn that lesson you kill them without suffering
a scratch.

Arrow support should stay. Honest. :-)

--
Michał Bieliński

[Darren Grey]

On Jun 12, 8:38 pm, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
> Once upon a time, Darren Grey wrote thus:
>
> > On Jun 9, 12:15 am, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
> >> Actually I go by the paradigm of making a game that I would like to play.
> >> This solves motivation issue quite nicely.
>
> > I think the "game I'd like to play" is great for mechanics design, but
> > for UI you have to think of other people.  If you want your game played
> > by others at least.
>
> Keeping in mind if I make UI that I dislike using the game loses its
> primary developer. There are people like Kornel Kisielewicz who are
> not afraid to be unskilled at their own game and play it rarely. I am
> not one of them. Whenever I lose interest in playing certain roguelike
> the development perspectives for it fade too. Things that I can be
> programming for eternity are GenRogues - art on the code side but
> no game.

Well, yes, ultimately you can spend all your life coding something
that no one else ever sees and enjoy yourself doing that. I have no
problem with that (well, as long as you don't go online telling others
how you're making the most amazing game ever and insulting other
people because the games they've actually released are no good
compared to yours). But as soon as you want others to play your game
you have to consider your audience. And interface improvements don't
have to mean changing the existing UI - it can be about adding
options, or parallel controls schemes like the mouse. Effort and work
and headache, yes, but if you don't put effort here you resign
yourself to being the sole player of the game.

> >> While being adjacent to certain enemy there is no space adjacent to
> >> him you can step into.
>
> > Yes, I can see that being a serious issue.  One solution is to ignore
> > this and require the player to think more carefully when encountering
> > a monster how to approach it in order to lead it to the right trap.
>
> Handwaving is no solution. Pretending there is no problem does not make
> it go away.

It's a perfectly fine solution sometimes. Often the gameplay itself
is due to restrictions. Rogue had permadeath and random levels and
ASCII representation and turn-based play because of the restrictions
of the technology of the time. If you design your game around those
restrictions then they become part of the game itself.

But as I said before, shoehorning 4-way onto an existing game is
generally not a good idea. It has to be part of the design from the
go, and all the implications of that need to be weaved into the game.

> > Look at it the other way and the complaint would be that 8-way makes
> > it too easy to corner monsters, or for the player to get cornered and
> > hit by a single monster. We are used to one standard and deem it to
> > be the correct one, but if we were to approach it from the other
> > direction we would see the 8-way system as the flawed one.
>
> What standard? Fleeing monsters are really irritating for the player.
> One *should* be able to corner morale-broken creatures without much
> effort.

True. The other option is not to have fleeing monsters if they're
only a nuisance.

> >> With 4-way movement a single monster may disallow you to move past it
> >> by clever enough AI given equal speeds. Makes avoiding monsters more
> >> difficult. Radomir correctly notes you can make your AI stupider not
> >> to take advantage of this. I agree with him this is bad thing.
>
> > Again can be seen as a positive thing or the "right" thing.  If you
> > want escape options give the player skills tailored towards escape.
>
> Do you see the pattern? For the failures of 4-way you need to introduce
> special abilities to make up for what was but a simple movement in 8-way.
> In MPRDB you can execute attacks as you pass by. That would be impossible
> if you restricted movement to cardinal directions.

I think these sorts of abilities should be in games anyway. Plus the
idea of forcing special things to counter restrictions is not bad in
my opinion. See my talk on single hit point games for justification
of this:

http://www.youtube.com/watch?v=dWBoYXpbJmg
http://www.youtube.com/watch?v=HoCVHXi5Vgc

Innovation driven by restriction can be a good thing. Copying what
everything else does is boring!

> >> The small problem I see with this the path calculation might drag the
> >> player character along unfavorable places if a monster was to show up.
> >> This could be shifted on player's shoulders and handwaved though. One
> >> should not use the feature when it is not safe to do so.
>
> > If a monster shows up then the auto-movement should be interrupted,
> > as with any multi-turn action.
>
> My point is it is too late then. Crawl autoexplore was famous for getting
> you killed in its early stage of development because it cut corners and
> put your deep elf in front of an ogre who prompty oneshotted the
> unfortunate adventurer. It fulfills your condition. The autoexplore
> algorithm stopped when monster was sighted.
>
> Any auto movement will be worse than human guidance. Now Crawl autoexplore
> is much safer but at the time woefully inefficient. You can save quite
> a lot of food if you explore manually using shifted directions.
>
> In my opinion if you design your levels right such mechanic will not be
> needed. And better not give it because then players will use it instead
> of learning how to navigate efficiently and safely.

Fully agreed - I hate auto-explore and how Crawl players have come to
rely on it as a crutch, to the point of many not being able to enjoy
the game without it. In fact I blogged about this earlier today!

http://www.gruesomegames.com/blog/?p=201

I wasn't suggesting auto-run on click as being quite like this. I
certainly don't use it like that when it's available. Clicking
outside your field of view is just stupid unless you know you're in a
safe position. It's like holding down the left key to melee a whole
bunch of weak monsters, not noticing when a dragon is hiding in the
corner.

> > Keyboard may be faster, but a duplicate way of getting to it by the
> > mouse is still more accessible.
>
> That does not mean you need to make everything possible through the
> mouse. Quite contrary you are better off leaving so

I disagree. Everyone has their own tastes on whether they prefer
mouse or keyboard, and some actions are naturally faster by one method
or the other. Preferably the whole UI should be duplicated in
keyboard and mouse. Of course there's a certain amount of development
pain associated with this! And for some things it might just be
impossible or unwieldy.

> > Plus it can be a handy reminder that throwing
> > *is* an option.  Too often when faced with a monster you stick to the
> > few key commands you use frequently, forgetting the more obscure
> > stuff.
>
> It is not interface's job to do this. If I were to constantly remind
> the player of every thing he can do my game would continuously run out
> of screen space.

Heh, I think PRIME actually does a nice job of this already.

> You are proving my point. Only the good things in Rogue get consistently
> copied (right or wrong).
>
> My turn! What modern roguelike game has the stick of draining working the
> same way Rogue had it? Hint: there is one game that has a scroll that works
> his way.

Hah, valid point. But I still believe that if some stuff had been
made convention back then it wouldn't be viewed with such suspicion
now.

> >> >> > W for Wear will confuse many roguelikers,
>
> [snip my disbelief]
>
>
>
> > Title of the thread is designing for non-roguelikers.  My point with
> > this is that even veteran roguelikers can be confused by what you
> > think is standard.
>
> First, who the heck thinks W for Wear is some kind of standard? It is
> just a good mnemonic. Popular, sure. No standard though.

It's pretty frequent. And it's a pet hatred for me. I seem to always
be ending up in this horrible position of trying out a new roguelike,
enjoying some things about it and then I find an item. I pick up the
item, go into my inventory, look at the item, decide "ooh, I want to
put this on". And then realise I have to back out of the inventory
entirely, find out what the wear or whatever key is, choose the item
again, and then choose the slot, and by this stage I am wailing and
gnashing my teeth and cursing against the sheer inhumanity the game
has put me through just to put on a damned item! And then... THEN I
find another item, and pick it up, and look at it in my inventory, and
THE PAIN STARTS AGAIN OH GOD HAVE MERCY!!!!

*ahem* I do seriously hate this mechanic. Verb object be fecking
damned. No fecking human thinks verb object. You look at the object
first and decide what you want to do with it after. Roguelikes are
all about finding loot and encountering monsters. The object always
comes first.

> Second, the keys
> that may confuse veterans are ones rarely used. D for Drink would be
> something that has greater chances for inducing confusion. As W for Wear
> being confusing I could as well make the argument that mouse support
> might confuse roguelike veterans.

Yes, very true. One must think carefully about the core audience
too. The last thing you want is a lovely polished game that normal
roguelikers won't play.

> >> > Part of making the log
> >> > good is getting rid of the chaff like the hit and miss notifications.
>
> >> Have you seen how Sil does this? It essentially has two logs. One for
> >> combat data where rolls are displayed in technical format and the other
> >> ordinary log for narration. It works surprisingly well.
>
> > Hmm, will check this out.  Does it have both logs displayed at once?
>
> Yes. Make sure your terminal is big enough to contain both. In the thread
> recently necroed by Scatha at the Temple of Roguelike forums you can see
> a screenshot in first post.

Hmm, yes, interesting. Game seems to like to throw lots of
information at the player. Not sure I like it myself, but clearly it
can work. Hmm, it's kinda sad that there are so many roguelikes I
haven't played properly :(

--
Darren Grey

[Gerry Quinn]

In article <slrnjtbpi...@shell.moinmo.in>, ne...@sheep.art.pl
says...

> Learning 60 key commands is a side effect -- the actual core part is
> having a choice of 60 different actions you can perform at any given
> moment. It's possible to make the learning easier, for example by
> making the commands composable and consistent, and also by providing
> hints and good feedback -- no disagreement here. But once you start to
> limit the number of keys by removing the choices, you are certainly
> changing the core roguelike experience.

I see no reason why there must be 60 choices. Not all roguelikes are
NetHack. You can have a perfectly good roguelike in which you have only
two choices: move, or use an item in the only way it can be used.

- Gerry Quinn

[Darren Grey]

On Jun 13, 1:08 am, Gerry Quinn <gerr...@gmail.com> wrote:
> In article <slrnjtbpid.vqr.n...@shell.moinmo.in>, n...@sheep.art.pl

I presume he means the core part of a specific roguelike, not all
roguelikes. If your game has 60 commands and they are all relevant to
the gameplay and you don't want to sacrifice them for interface then
you have to consider carefully how to integrate them well. ToME4
manages to do this with mouse control alone, or with huge arrays of
keyboard shortcuts for those that prefer.

--
Darren Grey

[Radomir Dopieralski]

On 2012-06-12, Darren Grey <darrenj...@gmail.com> wrote:

> It's pretty frequent. And it's a pet hatred for me. I seem to always
> be ending up in this horrible position of trying out a new roguelike,
> enjoying some things about it and then I find an item. I pick up the
> item, go into my inventory, look at the item, decide "ooh, I want to
> put this on". And then realise I have to back out of the inventory
> entirely, find out what the wear or whatever key is, choose the item
> again, and then choose the slot, and by this stage I am wailing and
> gnashing my teeth and cursing against the sheer inhumanity the game
> has put me through just to put on a damned item! And then... THEN I
> find another item, and pick it up, and look at it in my inventory, and
> THE PAIN STARTS AGAIN OH GOD HAVE MERCY!!!!

"Doctor, doctor, it hurts me when I do like this!"
"Then stop doing that."

You are completely unnecessarily doing extra steps and then finding that
they took you to a completely different place than you want to be.
Unless this interface is implemented as some kind of cargo cult mimicking
without actually understanding how it works, in which case it's really not
the fault of this particular kind of the interface.

The problem here is that it shouldn't be necessary for you to go into the
inventory in order to look at the item. You should be able to look at the
item as soon as you step on it. And you should be able to continue to look
at the item (together with the information on the inventory slot that it
got assigned) once you pick it up.

> *ahem* I do seriously hate this mechanic. Verb object be fecking
> damned. No fecking human thinks verb object. You look at the object
> first and decide what you want to do with it after. Roguelikes are
> all about finding loot and encountering monsters. The object always
> comes first.

About 42% of world's languages use SVO and according to Sapir-Whorf
hypothesis, about the same proportion of people thinks this way.
But I can see how being used to the "point and grunt" mode of
communication can make using any verbs at all a confusing experience
for large part of the population.

--
Radomir Dopieralski, sheep.art.pl

[Radomir Dopieralski]

I'm not saying that there should be 60 choices. This was a response to
your claim that your suggestions don't change the core gameplay. I'm
mrely pointing out a convenient metric by which you can see whether a
change applies to the gameplay or not -- if it limit the number of the
choices you have, it surely does.

--
Radomir Dopieralski, sheep.art.pl

[Radomir Dopieralski]

Of course it wasn't your claim, sorry.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

When you step on the item you see a name for it, no detail, especially
if it's unidentified. You pick it up, identify it, examine it, and *then*
decide what to do with it. Only when the object is known is the action
chosen. One should make the action possible from within that moment of
decision, when the object's purpose is revealed.

Furthermore when in a dangerous situation and deciding what to do often
my first thought is to look at my inventory and see if there's anything
to use. I might see a potion or a wand that would be perfect, decide
to use that, but then again have to back right out of the interface to
apply the verb first. It goes completely against the game flow unless
you have an insane memory for the nouns available to you.

> > *ahem* I do seriously hate this mechanic. Verb object be fecking
> > damned. No fecking human thinks verb object. You look at the object
> > first and decide what you want to do with it after. Roguelikes are
> > all about finding loot and encountering monsters. The object always
> > comes first.
>
> About 42% of world's languages use SVO and according to Sapir-Whorf
> hypothesis, about the same proportion of people thinks this way.
> But I can see how being used to the "point and grunt" mode of
> communication can make using any verbs at all a confusing experience
> for large part of the population.

I don't think roguelikes work like that. Your target is mentally chosen
first. You don't think about fighting before you see a monster.

Adventure games once had verb-based systems and it was painful. The
genre's move to target-based interaction made them much smoother to
play. I think the verb system is something that's just been inherited
from text adventures, where the imperative verb always started the
sentence.

--
Darren Grey

[Radomir Dopieralski]

That's just an error in implementation of that interface, and you can put
it together with annoying things like keys only working every second time.
You should be displayed the full information about the item right there.
Anything else is just wrong. Similarly, when you identify an item (which
you do by reading a scroll of identify or casting a spell, both of which
are *not* done from the inventory), you have the full information that was
revealed displayed, again together with the inventory slot, so you can
immediately perform an action of your choice on the item in question.

I seriously can't remember the last time when I used the [i]nventory
command in Rogue. Honestly, it's pretty useless. I think that removing
it entirely would improve the experience greatly by making the workflow
that you describe impossible.

> Furthermore when in a dangerous situation and deciding what to do often
> my first thought is to look at my inventory and see if there's anything
> to use. I might see a potion or a wand that would be perfect, decide
> to use that, but then again have to back right out of the interface to
> apply the verb first. It goes completely against the game flow unless
> you have an insane memory for the nouns available to you.

That's the result of a disconnection between the verbs used to describe
the commands and the verbs that you use to plan what to do. More on that
below.

>> > *ahem* I do seriously hate this mechanic. Verb object be fecking
>> > damned. No fecking human thinks verb object. You look at the object
>> > first and decide what you want to do with it after. Roguelikes are
>> > all about finding loot and encountering monsters. The object always
>> > comes first.
>>
>> About 42% of world's languages use SVO and according to Sapir-Whorf
>> hypothesis, about the same proportion of people thinks this way.
>> But I can see how being used to the "point and grunt" mode of
>> communication can make using any verbs at all a confusing experience
>> for large part of the population.
>
> I don't think roguelikes work like that. Your target is mentally chosen
> first. You don't think about fighting before you see a monster.
>
> Adventure games once had verb-based systems and it was painful. The
> genre's move to target-based interaction made them much smoother to
> play. I think the verb system is something that's just been inherited
> from text adventures, where the imperative verb always started the
> sentence.

Yes, it works like that, but the "point and grunt" systems have
conditioned you to conflate the object with the action, by requiring
that there is ever only one valid action that can be performed on the
object. It's a potion? Quaff it. It's a scroll? Read it. It's a weapon?
Wield it. This way you don't even realize that by choosing objects
(something that is easy to show on the screen and point to and grunt)
you are in fact choosing the action (something that is notoriously
difficult to show on screen in graphical form).

This fact is further made worse by the aforementioned disconnect between
the commands and the actual actions you wish to perform. An example will
illustrate it best. In the situation you described, where you are in a
tight spot and you wish to examine your inventory, you don't really want
to see your whole inventory. Neither you want to quaff a potion or read
a scroll. You want to heal. "Heal" is the verb that you have in your mind,
and whether it will be by quaffing a potion, reading a scroll, eating a
lembas wafer or casting a spell -- you don't care. Similarly, when you
see a particularly tough monster, you want to "boost" your offensive
ability somehow -- whether it's by going berserk, quaffing a potion of
speed or zapping a fireball wand on the monster -- is secondary. But this
discrepancy wasn't always there.

I will bring Rogue again, because it's such a great game. In rogue, you
can't heal by reading a scroll or eating food: the only healing -- or any
status effect, really -- items are potions. You are low on health,
poisoned, blind and generally in bad condition -- you press "q". At the
same time, the only offensive spells are available in the form of wands.
You see a monster that you want to shoot -- you press "z". Scrolls are the
only source of support spells, food -- the only source of food. Weapons
are the only way of increasing your damage, and armor is the only way of
protecting yourself. Finally rings are the only way of gaining long-term
skills. All the verbs correspond closely to the mental model of what you
might want to do in game.

Later this principle was forgotten. Personally I blame Moria and Angband
for completely mixing everything up and breaking the beat and well thought
out design. Actually, I think I can blame Angband for most, if not all, of
the problems that appear in user interfaces in roguelike games, including
such abominations as auto-squelch or in-game color editor.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Jun 13, 6:02 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

> On 2012-06-13, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > On Wednesday, June 13, 2012 1:57:21 PM UTC+1, Radomir Dopieralski wrote:

> >> On 2012-06-12, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > When you step on the item you see a name for it, no detail, especially
> > if it's unidentified.  You pick it up, identify it, examine it, and *then*
> > decide what to do with it.  Only when the object is known is the action
> > chosen.  One should make the action possible from within that moment of
> > decision, when the object's purpose is revealed.
>
> That's just an error in implementation of that interface, and you can put
> it together with annoying things like keys only working every second time.
> You should be displayed the full information about the item right there.
> Anything else is just wrong. Similarly, when you identify an item (which
> you do by reading a scroll of identify or casting a spell, both of which
> are *not* done from the inventory), you have the full information that was
> revealed displayed, again together with the inventory slot, so you can
> immediately perform an action of your choice on the item in question.

If you identify many items at once you will want to look at your
inventory and analyse these items, consider their stats, compare
equipment side by side, etc. You seem to be presuming that you only
deal with one item at any one time.

> I seriously can't remember the last time when I used the [i]nventory
> command in Rogue. Honestly, it's pretty useless. I think that removing
> it entirely would improve the experience greatly by making the workflow
> that you describe impossible.

Whilst in games like ADOM or ToME the inventory is pivotal. Plus more
accessible to those used to inventory interfaces in mainstream RPGs.

You may say this is a result of conditioning, but then many of the
interface suggestions I've been making about helping outside players
conditioned to other genres be able to adapt to roguelike gameplay.
Adding interaction within the inventory is something they (and I!) can
understand better, without needing to remove the traditional method of
interaction for those that prefer to think in verbs.

And yes, it may lead to some being trained to play in what you
consider an unideal way, but that's not a problem in my opinion if it
gets more people to enjoy the game in the first place.

> > I don't think roguelikes work like that.  Your target is mentally chosen
> > first.  You don't think about fighting before you see a monster.
>
> > Adventure games once had verb-based systems and it was painful.  The
> > genre's move to target-based interaction made them much smoother to
> > play.  I think the verb system is something that's just been inherited
> > from text adventures, where the imperative verb always started the
> > sentence.
>
> Yes, it works like that, but the "point and grunt" systems have
> conditioned you to conflate the object with the action, by requiring
> that there is ever only one valid action that can be performed on the
> object. It's a potion? Quaff it. It's a scroll? Read it. It's a weapon?
> Wield it. This way you don't even realize that by choosing objects
> (something that is easy to show on the screen and point to and grunt)
> you are in fact choosing the action (something that is notoriously
> difficult to show on screen in graphical form).

Not in a right-click to choose action system. In these there are
multiple options that can be performed on each object, and you choose
that action after choosing the target.

ToME is a good example of this. In it there are two ways of firing a
spell at an enemy - choose the spell and then choose the target, or
choose the target and then choose the spell. Both thought processes
are full viable depending on the situation. There are many times I
will decide I want to attack an enemy, but not decide how until I
right-click on the target and consider my various options in one handy
condensed list.

> This fact is further made worse by the aforementioned disconnect between
> the commands and the actual actions you wish to perform. An example will
> illustrate it best. In the situation you described, where you are in a
> tight spot and you wish to examine your inventory, you don't really want
> to see your whole inventory. Neither you want to quaff a potion or read
> a scroll. You want to heal.

Incorrect! I might look through my inventory and decide I want to
teleport away, or risk a powerful wand. I look at my inventory
because I want to sum up in my head the range of tactical decisions I
have available. I do not know before looking at my inventory if I
have something that allows me to teleport. It is the objects in this
situation that determine what verbs are even possible to use.

In this sort of situation of looking into my inventory to see what I
can use it becomes much easier if I can apply my verbs from within
this menu. Ideally right-click and choose action for accessibility,
though even faster may be item letter followed by verb key. Heck even
just being able to use verb keys within the inventory without having
to exit first would be nice - why is there this modal restriction
within the inventory screen that you can do nothing without returning
to the map view?

For situations like "I want to heal" then I think a manually definable
shortcut is best, letting the player decide which verb-object combo
they use on a regular and reliable enough basis to assign to a hotkey.

> I will bring Rogue again, because it's such a great game. In rogue, you
> can't heal by reading a scroll or eating food: the only healing -- or any
> status effect, really -- items are potions. You are low on health,
> poisoned, blind and generally in bad condition -- you press "q". At the
> same time, the only offensive spells are available in the form of wands.
> You see a monster that you want to shoot -- you press "z". Scrolls are the
> only source of support spells, food -- the only source of food. Weapons
> are the only way of increasing your damage, and armor is the only way of
> protecting yourself. Finally rings are the only way of gaining long-term
> skills. All the verbs correspond closely to the mental model of what you
> might want to do in game.
>
> Later this principle was forgotten. Personally I blame Moria and Angband
> for completely mixing everything up and breaking the beat and well thought
> out design. Actually, I think I can blame Angband for most, if not all, of
> the problems that appear in user interfaces in roguelike games, including
> such abominations as auto-squelch or in-game color editor.

Hmm, I partly agree, but then the vast range of item interactions is
seen as one of the charms of many games too. The restriction of
objects to only act within certain verb spaces is seen as a dumbing
down of gameplay by some, who react as vigorously to the suggestion as
others do to the idea of 4-way movement ;)

In a situation of such restricted item usage it almost becomes a
unification of verb and object command - pressing 'r' to read might as
well be the same as pressing 's' for scrolls. Other interactions may
still be possible, but they become edge cases rather than the norm.

--
Darren Grey

[Radomir Dopieralski]

On 2012-06-13, Darren Grey <darrenj...@gmail.com> wrote:

>> I seriously can't remember the last time when I used the [i]nventory
>> command in Rogue. Honestly, it's pretty useless. I think that removing
>> it entirely would improve the experience greatly by making the workflow
>> that you describe impossible.

[snip]

> You may say this is a result of conditioning, but then many of the
> interface suggestions I've been making about helping outside players
> conditioned to other genres be able to adapt to roguelike gameplay.
> Adding interaction within the inventory is something they (and I!) can
> understand better, without needing to remove the traditional method of
> interaction for those that prefer to think in verbs.

[snip]

In that light, it may indeed be good to remove the other (traditionally
roguelike) method of interaction. Clearly, mixing the two leads to
frustration.

That is not restricting. You can still have t-shirts that you can both
read and wear, and weapons you can throw at the monsters -- so you can
still have interesting decisions to make when an item has multiple uses.
The point here is merely to sort the actions in a way that has meaning
in the game, instead of randomly copying items from movies and books.

So maybe there was that one story that had a potion of fire breath in it.
So what -- in the world of your game you cannot shoot a fireball by
drinking a potion -- or anything else. You can have a wand of fire, or
you can have a potion that you can zap (here is an important difference
between a "zap" command and a "list wands" command -- the potion is not
a wand) or maybe throw at the monsters. But no shooting by drinking.

That doesn't really limit the mechanics that you have available. It merely
limits the descriptions/theming that you can use, forcing it to be
consistent with the internal logic of your game world. I consider this to
be a good thing.


--
Radomir Dopieralski, sheep.art.pl

[Michal Bielinski]

Once upon a time, Darren Grey wrote thus:
> On Jun 12, 8:38 pm, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
>> Once upon a time, Darren Grey wrote thus:

>> > I think the "game I'd like to play" is great for mechanics design, but
>> > for UI you have to think of other people.  If you want your game played
>> > by others at least.
>>
>> Keeping in mind if I make UI that I dislike using the game loses its
>> primary developer.

[...]

>
> But as soon as you want others to play your game
> you have to consider your audience. And interface improvements don't
> have to mean changing the existing UI - it can be about adding
> options, or parallel controls schemes like the mouse. Effort and work
> and headache, yes, but if you don't put effort here you resign
> yourself to being the sole player of the game.

The keyword here is "want". I do not specifically want this to happen.
There were those beautiful roguelike games BOSS and ZapM. They were not
created by me. I stumbled upon them, dusted them off a bit and workend
on both to improve them. Both games are given back to the community
as return gift. Of course interface is going to be improved along with
the engine and content. However, I will venture to making game accessible
to others only so much. The rest is up to anyone willing to make a fork.

I have also reconsidered the bit about having multiple interfaces.
LambdaRogue has two - good old plain ASCII and tiles which now look great.
Mario Donick was mostly playing tiles and it turned out ASCII mode had
an obvious crash bug that manifested only in late game. If one would stick
to single interface chances that a showstopper bug might sneak past to
release build becomes unpleasantly high.

This is not to say multiple interfaces are bad by themselves. One just
would do better to make all of them pleasant to use and well tested.
Nothing wrong in using one most of the time but designing something
strictly for me would likely result in the other option being barely
tested at best and not completely fleshed out at worst.

>> My turn! What modern roguelike game has the stick of draining working the
>> same way Rogue had it? Hint: there is one game that has a scroll that works
>> his way.
>
> Hah, valid point. But I still believe that if some stuff had been
> made convention back then it wouldn't be viewed with such suspicion
> now.

Just for your interest I was thinking about the scroll of torment.

>> First, who the heck thinks W for Wear is some kind of standard? It is
>> just a good mnemonic. Popular, sure. No standard though.
>
> It's pretty frequent. And it's a pet hatred for me.

Uh-oh. Its coming!

f - blessed +1 azbestos suit (worn)

> I seem to always
> be ending up in this horrible position of trying out a new roguelike,
> enjoying some things about it and then I find an item. I pick up the
> item, go into my inventory, look at the item, decide "ooh, I want to
> put this on". And then realise I have to back out of the inventory
> entirely, find out what the wear or whatever key is, choose the item
> again, and then choose the slot, and by this stage I am wailing and
> gnashing my teeth and cursing against the sheer inhumanity the game
> has put me through just to put on a damned item! And then... THEN I
> find another item, and pick it up, and look at it in my inventory, and
> THE PAIN STARTS AGAIN OH GOD HAVE MERCY!!!!

It was not so bad as I expected but had to think it over twice.

First, very interesting thing is you have to enter inventory to look at
item. Lets assume you had just identified it. Most roguelikes tell you
right away in the log what item was IDed with all the details. Opening
inventory is not going to give you any clues log did not give you
already. I am curious why you do it.

Lets forget it for a moment and assume you entered the inventory. PRIME
uses inventory for detailed examination and selecting something brings
lore and in-depth information. If I were to instead display a dialog
similar to what DCSS has with acquirement there would need to be another
command to view lore of items. And that is not something I am fond of.

The alternative would be to rework lore screen and forget single purpose
in favor of passing commands to main UI module. This makes lore screen
no longer just a simple and immersive presentation of game knowledge
about given item because of all the actions lingering below.

Another drawback is presentation problems of actions that are not always
available. You cannot read scrolls while standing in dark or being blind.
Similarly PRIME requires you to see or have a computer with voice
interface to boot. So floppies would have their execute action grayed
out or without a key assigned to show it is not available right now. The
problem is it does not tell you why you cannot run the floppy disk. You
still need the verb command to get to know whether you lack a computer,
it has no OS, or you are blind, or maybe it has voice interface but the
OS has no drivers for it installed.

At least PRIME never asks you for a slot. Wear, install and wield are
unambiguous. There are some musings on collapsing wear and install into
a single command in future. OTOH it will never be possible to unify
wielding with anything else.

> *ahem* I do seriously hate this mechanic. Verb object be fecking
> damned. No fecking human thinks verb object. You look at the object
> first and decide what you want to do with it after. Roguelikes are
> all about finding loot and encountering monsters. The object always
> comes first.

I see a monster and want to dispose of it. This is object-verb. But
when I have decided to kill it then my next step is to choose with
what to kill it. This is verb-object. I am^H^H^H claim to be human.

Playing DCSS. PC is combat wombat style hero. After meeting a hydra:
"It has 9 heads but my HP is full. I can handle it. What do I wield?"

Pretty simple. Now, a more difficult case.

Same game, same hero. After meeting a lone yaktaur captain:
"His buddies are slain but the monster is tough. I would better
defeat him by ranged means. Three options: spells, missile weapons
and wands."

Magic needs to be checked out through its own command. Remaining two
options can be checked by either first issuing wield and then zap or
indirectly by looking at inventory. I prefer the first method because
then armor and food will be filtered out for me. You obviously want
the second to work which triggers the backing out need for many
roguelikes.

Various *bands deal with the problem in a great way. You can have
whole inventory constantly displayed on screen. No need to issue
inventory command at all! You need to configure your screen to have
this which sadly means only small portion of players had experienced
that great feature. Sil automatically allocates free terminal screen
space which is one of its strengths.

Z-Day also did this. You had your whole inventory to the right. Whenever
you wanted to use an item you just pressed its associated key. If you
wanted to get rid of it you pressed the same key shifted. I recommend
having a look.

--
Michał Bieliński

[Michal Bielinski]

Once upon a time, Radomir Dopieralski wrote thus:

> On 2012-06-13, Darren Grey <darrenj...@gmail.com> wrote:

[...]

>> Your target is mentally chosen
>> first. You don't think about fighting before you see a monster.
>>
>> Adventure games once had verb-based systems and it was painful. The
>> genre's move to target-based interaction made them much smoother to
>> play. I think the verb system is something that's just been inherited
>> from text adventures, where the imperative verb always started the
>> sentence.
>

[...]

>
> I will bring Rogue again, because it's such a great game. In rogue, you
> can't heal by reading a scroll or eating food: the only healing -- or any
> status effect, really -- items are potions. You are low on health,
> poisoned, blind and generally in bad condition -- you press "q". At the
> same time, the only offensive spells are available in the form of wands.
> You see a monster that you want to shoot -- you press "z". Scrolls are the
> only source of support spells, food -- the only source of food. Weapons
> are the only way of increasing your damage, and armor is the only way of
> protecting yourself. Finally rings are the only way of gaining long-term
> skills. All the verbs correspond closely to the mental model of what you
> might want to do in game.

Doom the roguelike is one of newer games that stick to this to good effect.
Only weapons shoot, armor/boots can be worn and miscellaneous one-shot
items do single effects. You can press 'u' whenever you want to heal,
teleport, or modify a gun. One can hit 'U' to have a list of weapons and
ammunition packs to unload. Unfortunately there is no command to directly
swith a piece of armor. There exist quick-keys for weapons but sadly these
encompass only most common weapon classes. When you find unique stuff or
even some exotic thing you are at a loss. Lots of potential lost.

What is worst when you want to change armor you have two options to do it.
The 'e'quipment screen which is like ADOM's inventory or directly listing
inventory and choosing the item. The first requires two keypresses ('e'
for equipment and slot specification) but provides neat filtered out list.
The second immediately gets you to picking what exactly you want to wear
but lists many things and miskeypress can have you use a medpack on full
health by accident. Baaad UI design. All that could be fixed by adding
a command but no, it has to have few commands to be "user friendly". To
hell with such user friendliness! Wait, you actually go there in the game.

Final killer is the inventory screen. It is a menu with a cursor. DoomRL
goes to extreme lengths to build immersion: music, sounds, very strongly
observed theme. Then it harms it with such basic blunders. Former versions
had the option of switching the menu from hybrid to pure key-based to
enhance playing experience but it prevented you from examining an item.
You had to move cursor over it in menu to receive information and without
it of course you could not do that. Bummer.

--
Michał Bieliński

[Darren Grey]

On Thursday, June 14, 2012 6:49:32 AM UTC+1, Michal Bielinski wrote:

> What is worst when you want to change armor you have two options to do it.
> The 'e'quipment screen which is like ADOM's inventory or directly listing
> inventory and choosing the item. The first requires two keypresses ('e'
> for equipment and slot specification) but provides neat filtered out list.
> The second immediately gets you to picking what exactly you want to wear
> but lists many things and miskeypress can have you use a medpack on full
> health by accident. Baaad UI design. All that could be fixed by adding
> a command but no, it has to have few commands to be "user friendly". To
> hell with such user friendliness! Wait, you actually go there in the game.
>
> Final killer is the inventory screen. It is a menu with a cursor. DoomRL
> goes to extreme lengths to build immersion: music, sounds, very strongly
> observed theme. Then it harms it with such basic blunders. Former versions
> had the option of switching the menu from hybrid to pure key-based to
> enhance playing experience but it prevented you from examining an item.
> You had to move cursor over it in menu to receive information and without
> it of course you could not do that. Bummer.

I found DoomRL's whole inventory system to be very frustrating myself.
I think the game suffers from trying to incorporate elements like
reloading from Doom with a traditional roguelike interface, including
pick up and use items. It could maybe do with getting rid of its whole
inventory design - have unlimited ammo space, unlimited health space
(with only one health pack type, and it set to a dedicated hotkey) and
maybe 5 weapon slots that you assign and switch between. Game should be
about running and gunning, not wasting time with lists of items.

If an inventory system is fiddly sometimes the answer is to get rid of
it entirely and think about how the powers and abilities are best set
up for the game. The only real reason for a complicated inventory is
if you have a large array of items and item types, and a multitude of
interactions between them. In a simpler game there are better ways of
managing the player's resources.

--
Darren Grey

[Darren Grey]

On Thursday, June 14, 2012 6:34:38 AM UTC+1, Michal Bielinski wrote:

> The keyword here is "want". I do not specifically want this to happen.
> There were those beautiful roguelike games BOSS and ZapM. They were not
> created by me. I stumbled upon them, dusted them off a bit and workend
> on both to improve them. Both games are given back to the community
> as return gift. Of course interface is going to be improved along with
> the engine and content. However, I will venture to making game accessible
> to others only so much. The rest is up to anyone willing to make a fork.

All well and good if there are dedicated people out there. If not then
the game may go to waste. If it wasn't for your efforts already these
games would be forgotten. But modernisation of interface is not
something you can do only once and consider sorted. Standards are
always changing.

> I have also reconsidered the bit about having multiple interfaces.
> LambdaRogue has two - good old plain ASCII and tiles which now look great.
> Mario Donick was mostly playing tiles and it turned out ASCII mode had
> an obvious crash bug that manifested only in late game. If one would stick
> to single interface chances that a showstopper bug might sneak past to
> release build becomes unpleasantly high.
>
> This is not to say multiple interfaces are bad by themselves. One just
> would do better to make all of them pleasant to use and well tested.
> Nothing wrong in using one most of the time but designing something
> strictly for me would likely result in the other option being barely
> tested at best and not completely fleshed out at worst.

This is what players are for :) You shouldn't design an interface
for which you have no playtesters.

Also the chance of this sort of thing is fairly low I think. You could
use the same argument to say that one shouldn't implement new features
in the game in case there's a bug. We all add things to games without
testing them quite as thoroughly as we should, and sometimes that comes
back to bite us. But we add these things for reasons. You can't
paralyse yourself to just minor tweaks and changes.

> > I seem to always
> > be ending up in this horrible position of trying out a new roguelike,
> > enjoying some things about it and then I find an item. I pick up the
> > item, go into my inventory, look at the item, decide "ooh, I want to
> > put this on". And then realise I have to back out of the inventory
> > entirely, find out what the wear or whatever key is, choose the item
> > again, and then choose the slot, and by this stage I am wailing and
> > gnashing my teeth and cursing against the sheer inhumanity the game
> > has put me through just to put on a damned item! And then... THEN I
> > find another item, and pick it up, and look at it in my inventory, and
> > THE PAIN STARTS AGAIN OH GOD HAVE MERCY!!!!
>
> It was not so bad as I expected but had to think it over twice.
>
> First, very interesting thing is you have to enter inventory to look at
> item. Lets assume you had just identified it. Most roguelikes tell you
> right away in the log what item was IDed with all the details. Opening
> inventory is not going to give you any clues log did not give you
> already. I am curious why you do it.

In a new game you may not know what an item does, or even what type of
item it is. Is the golden stone a tool or a weapon? Often there's
more detail in the inventory screen than is given in the log,
especially if going into the inventory lets you examine said item for
more information. On top of that one might want to compare it with
other items you already possess. Or heck, it could be a case of
looking at what you start the game with. A new player might want to
look at his current items, want to try one straight away, and instantly
get turned off by the kooky system of having to go out of the inventory
to use the item he's looking at.

Also people are conditioned to operate through the inventory.
Mainstream games have you go into the inventory and right-click on
items to choose what to do with them. It's the natural thought.
Having an inventory system that lets you do nothing other than look
at what you've got seems weird in comparison.

> The alternative would be to rework lore screen and forget single purpose
> in favor of passing commands to main UI module. This makes lore screen
> no longer just a simple and immersive presentation of game knowledge
> about given item because of all the actions lingering below.

This is what I would suggest. I don't think it breaks immersion. It
fits in with how much of PRIME uses contextual advice already. And
for people like me it's what I expect and what comes naturally. Yes,
it takes more keypresses, but it also takes less thought, and it doesn't
interfere with the existing system.

Also it teaches the key commands much better than a help screen does.
The player is using the same 'r'ead keys etc but learning them through
situation specific action. They're not stuck thinking "I have a scroll,
how do I read it" - it tells them right there on the scroll! You could
have this in the log as contextual advice too, but if there are
multiple actions available this becomes messy.

> Another drawback is presentation problems of actions that are not always
> available. You cannot read scrolls while standing in dark or being blind.
> Similarly PRIME requires you to see or have a computer with voice
> interface to boot. So floppies would have their execute action grayed
> out or without a key assigned to show it is not available right now. The
> problem is it does not tell you why you cannot run the floppy disk. You
> still need the verb command to get to know whether you lack a computer,
> it has no OS, or you are blind, or maybe it has voice interface but the
> OS has no drivers for it installed.

I wouldn't bother with greying out or removing the action from the list.
Simply do what you'd normally do if trying to read from the main screen
- cut to the log and tell the player they cannot read because it's dark.
This is a small nuisance to the player in a rare circumstance that they
will quickly learn from, without any loss of information or instruction.

> > *ahem* I do seriously hate this mechanic. Verb object be fecking
> > damned. No fecking human thinks verb object. You look at the object
> > first and decide what you want to do with it after. Roguelikes are
> > all about finding loot and encountering monsters. The object always
> > comes first.
>
> I see a monster and want to dispose of it. This is object-verb. But
> when I have decided to kill it then my next step is to choose with
> what to kill it. This is verb-object. I am^H^H^H claim to be human.

Haha, so you're just defining the start of the thought process to suit
your view.

I suppose the whole object/verb debate is a bit silly. We don't work
one way or the other - we have a whole matrix of interfaces between
actions and targets in our heads that we choose from, some with complex
connotations to consider. Will this area attack influence multiple
targets? Will this drain attack restore enough life whilst also
removing the enemy? There are ways to deal with controlling this that
are entirely abstracted from considerations of verb or object first.

> Various *bands deal with the problem in a great way. You can have
> whole inventory constantly displayed on screen. No need to issue
> inventory command at all!

The problems with this are use of valuable screen real estate, and
the need for restricted inventory size (something players just find
frustrating). Something like Dredmor's inventory pane might work if
you had multiple tabs on it by item type, scrolls bars and a resize
ability (whilst retaining the ability to hide it entirely).

> Z-Day also did this. You had your whole inventory to the right. Whenever
> you wanted to use an item you just pressed its associated key. If you
> wanted to get rid of it you pressed the same key shifted. I recommend
> having a look.

Unless it has mouse-over tooltips it still has the issue of not
knowing what items do until you examine them. Over the course of
many games you may get used to this, but new players will still need
some sort of inventory or other window for expanded information.

--
Darren Grey

[Radomir Dopieralski]

On 2012-06-14, Darren Grey <darrenj...@gmail.com> wrote:
> On Thursday, June 14, 2012 6:49:32 AM UTC+1, Michal Bielinski wrote:

> I found DoomRL's whole inventory system to be very frustrating myself.
> I think the game suffers from trying to incorporate elements like
> reloading from Doom with a traditional roguelike interface, including
> pick up and use items.

The original Doom games never had reloading.

--
Radomir Dopieralski, sheep.art.pl

[Darren Grey]

On Jun 14, 1:27 pm, Radomir Dopieralski <n...@sheep.art.pl> wrote:

> On 2012-06-14, Darren Grey <darrenjohng...@gmail.com> wrote:
>
> > On Thursday, June 14, 2012 6:49:32 AM UTC+1, Michal Bielinski wrote:
> > I found DoomRL's whole inventory system to be very frustrating myself.
> > I think the game suffers from trying to incorporate elements like
> > reloading from Doom with a traditional roguelike interface, including
> > pick up and use items.
>
> The original Doom games never had reloading.

Hah, maybe that's why it feels so out of place in DoomRL... The whole
ammunition mechanic is just tedious.

--
Darren Grey

[Ido Yehieli]

On Friday, June 8, 2012 11:56:20 AM UTC+2, JO wrote:
> think about it. In D&D and ALL other games underground stuff is
> handled with squares. That's just the way it is. If you go hex you
> will turn non-roguelikers off when going underground. Name one top
> down RPG game that uses hexes. One. Anyone.

Erm, Fallout 1 & 2, quite possibly the best RPGs ever made?

[Ido Yehieli]

On Friday, June 8, 2012 11:25:49 AM UTC+2, Darren Grey wrote:
> > This is an argument for tiles.
>
> Tiles can be just as bad. Plus for many getting good tiles just isn't an option.


They don't have to be "good", just better than ascii :)

I don't think anyone would blame me for having a lot of
artistic skill, but even I can make sprites that are clearer
to the non-initiated than ascii. Here are some (very simple)
example quickly doodled in gimp:

http://i.imgur.com/D08HM.png

-Ido.

[Kusigrosz]

On 2012-06-16, Ido Yehieli <Ido.Y...@gmail.com> wrote:
> On Friday, June 8, 2012 11:25:49 AM UTC+2, Darren Grey wrote:
>> > This is an argument for tiles.
>>
>> Tiles can be just as bad. Plus for many getting good tiles just
>> isn't an option.
>
> They don't have to be "good", just better than ascii :)

Better in showing the creature's number of legs, or in showing
game-relevant information? I mean things like:
"Is that a monster, an item, or a terrain feature?"
"Is that the same type of monster I easily defeated a while ago?"
"What type of item is that?"

In your example, consider the three figures in the second column from
the left - I think they have a staff or a spear, a sword and a
dagger. At this size - only 64 tiles in this part of the screen - and
close to one another, they are easy to tell apart. But in some
roguelikes there are many hundreds, sometimes more than a thousand of
cells visible at the same time. Would these monsters be discernible
in that case, especially if not appearing at the same time?

In an ascii roguelike, they'd probably be represented as different
colours of the same letter. I find it easier to notice "this is the
first orange 'o' I meet in this game" than "this little guy seems
to be holding something different from the ones I met earlier" -
especially if the thing he is holding is some 2 mm long.

The tileset is a new alphabet the player has to learn while playing;
both (1) to tell the symbols apart, and (2) to know what they mean in
the game. If the tiles are big enough and designed well, the (2) can
be made easier, as the player can recognize and learn from the shape
shown. The designer has also freedom in organizing the tiles in
a meaningful way - items of various types, monsters, etc.

In the case of ascii, (1) is trivial (already known), while (2) can
be hard. No clue from the symbol's shape. The symbols are already
organized; the game designer can (and usually does) take advantage of
that hardwired organization.

--
To send mail, remove 'AU' from the address
You see here a scroll labeled "pJMy_rv-Ix8"

[Ido Yehieli]

On Saturday, June 16, 2012 10:46:51 PM UTC+2, Kusigrosz wrote:
> Better in showing the creature's number of legs, or in showing
> game-relevant information? I mean things like:
> "Is that a monster, an item, or a terrain feature?"
> "Is that the same type of monster I easily defeated a while ago?"
> "What type of item is that?"

This is an old and tired argument.

You will not get players used to "normal" games to play ascii games, period.

It doesn't matter what the advantages are (I'll give you that there is a tiny advantage to ascii as you state, although I see no reason why you need to present the player with 1000s of tiles per screen), people who are outside the roguelike clique will simply not play ascii games.

If you don't care about that you can do as you wish, but Darren was talking about making roguelike for non-roguelike players, and for those you need graphics (even simple ones).

[Jason Pickering]

I agree with Ido. People don't register ASCII. The first time I played a roguelike my wife thought I was programming. People don't see the uppercase D as a dragon. They see it as an uppercase D. For non roguelike players being able to recognize a game immediately is key.

[JO]

Oh shit...what an oversight! Point completely nullified.

[Michal Bielinski]

Once upon a time, Ido Yehieli wrote thus:

> On Saturday, June 16, 2012 10:46:51 PM UTC+2, Kusigrosz wrote:
>> Better in showing the creature's number of legs, or in showing
>> game-relevant information? I mean things like:
>> "Is that a monster, an item, or a terrain feature?"
>> "Is that the same type of monster I easily defeated a while ago?"
>> "What type of item is that?"
>
> This is an old and tired argument.

True, although it still has as much merit as it always had.

> You will not get players used to "normal" games to play ascii
> games, period.

I did get such players to try PRIME and even hook two of them.
Your argument is invalid, period. I'll give you that there are
not a lot of such players.

Having to choose between bad tiles and ASCII I prefer the latter.
If there is option for good tiles that is the way to go. When a RL
matures it is worth looking for an artist.

--
Michał Bieliński

[Psiweapon]

OH HAY GUISE!

On 17 jun, 17:15, Michal Bielinski <dungeon_kee...@tlen.pl> wrote:
> Once upon a time, Ido Yehieli wrote thus:

[SNIP]

> > You will not get players used to "normal" games to play ascii
> > games, period.
>
> I did get such players to try PRIME and even hook two of them.
> Your argument is invalid, period. I'll give you that there are
> not a lot of such players.

Hey, I myself had been playing computer games for long years
before I stumbled upon roguelikes. I always had a penchant for
low-ish tech games (abandonware, emulators, etc) but learning
to read an ASCII viewport is not that bad. I tend towards tiles
because I like pixel-art, but ASCII isn't a downer for me -
unless it's black-on-white or some other ugly scheme.

In fact, I think there's a widespread lack of trust on the gamers'
adaptability from roguelike niche players/developers, mostly
about ASCII and keystrokes. The first one is more founded,
let's do a bit of a test about the second:

Does the following sequence have any meaning for any of you?

L-click, s, z.
L-click, s, z.
L-click, s, h.
[most annoying sound]
L-click, s, h.
[most annoying sound]
*player grunts annoyed*
double L-click, s.

What about these?

b, w, z, enter; q, a, b, r.

s, A, B, C, k, (scroll with arrowkeys), enter, enter.

This one should be more familiar:

o, k
o, k
o, k
*player grunts annoyed*
^d, k
^d, k
*player grunts expletive*
q

Also, I remember back in the heyday of Counter Strike (did I
loathe that game!) people would talk about in-game weapons
as a "4-3" or a "2-4" or whatever, that is, by the keypresses
required to select them at the buy equipment menu.

Roguelike UI conventions are certainly a bit steep, but they can
be worse: There's Dwarf Fortress. As much as I love the game
(not nearly as much as other people though!), it's interface is
ATROCIOUS. It helps that all (or most) required keypresses
are spelled out onscreen at any given time, but still.

Don't underestimate gamers' capacity for understanding and
applying keypresses. There's certainly a demography out there
who can't make head or tails out of a keyboard but I doubt
they're a majority.

> Having to choose between bad tiles and ASCII I prefer the latter.
> If there is option for good tiles that is the way to go. When a RL
> matures it is worth looking for an artist.
>
> --
> Michał Bieliński

I, of course, wholeheartedly agree with that, wouldn't I?


P.S.: I hope formatting was OK, it's the first time I post on the
usenet tube of ze interbutts, I think.

[Kornel Kisielewicz]

On 14-Jun-12 07:49, Michal Bielinski wrote:
> The second immediately gets you to picking what exactly you want to wear
> but lists many things and miskeypress can have you use a medpack on full
> health by accident. Baaad UI design. All that could be fixed by adding
> a command but no, it has to have few commands to be "user friendly". To
> hell with such user friendliness! Wait, you actually go there in the game.

That actually makes me wonder if there should be a hardcore-UI mode. Or
extended key-set.

> Final killer is the inventory screen. It is a menu with a cursor. DoomRL
> goes to extreme lengths to build immersion: music, sounds, very strongly
> observed theme. Then it harms it with such basic blunders. Former versions
> had the option of switching the menu from hybrid to pure key-based to
> enhance playing experience but it prevented you from examining an item.
> You had to move cursor over it in menu to receive information and without
> it of course you could not do that. Bummer.

The lack of the pure-mode was due to time restrictions -- the G-version
(and it's overhaul of the UI) was a bit rushed. Don't worry, it'll
return (although probably only for ASCII mode, because G-mode will have
a completely redesigned UI).

[Kornel Kisielewicz]

The effect is quite opposite. As noted from many strategy discussions on
the ChaosForge forums, inventory management is one of the key strategic
elements of the game -- what to keep, what to carry, how to distribute
your resources. Taking it away would drastically reduce the games
complexity, and make it a lot more boring.

I tried such a simplified approach with AliensRL, and there is a
consensus now that the game should be moved towards a more traditional
item based inventory system.
--
at your service,
Kornel Kisielewicz
ChaosForge - http://chaosforge.org/

[Kornel Kisielewicz]

On 08-Jun-12 16:45, Darren Grey wrote:
> On Friday, June 8, 2012 3:21:30 PM UTC+1, Radomir Dopieralski wrote:
>> On 2012-06-08, Darren Grey wrote:
>>
>>> Dungeons of Dredmor, Binding of Isaac, Cardinal Quest. All successful
>>> roguelikes (or similar).
>>
>> Actually Binding of Isaac is 8-way, with diagonals done by pressing two
>> keys at the same time.
>
> Ooh, crikey, I didn't realise. I suppose the point would be 4-way input
> then.

Note that that works only because it's real-time. If you want
instantaneous movement, you can't rely on two keystrokes.

[Darren Grey]

I personally found that strategic element to be quite out of place in
the game. It's fairly minor strategy wise (you have your build you
play to, so there's rarely any real choices in what to keep - there's
nuisance decisions rather than difficult decisions) and it isn't
cohesive with how the rest of the game plays. But more importantly
it's fiddly and difficult to work with, starkly at contrast with the
very natural and fast-flowing main game.

Mind you I think the vast majority of games with inventory menus
suffer from this, but often in such games (roguelikes especially) the
main combat can be slow-paced as well so there isn't the same
juxtaposition of elements. But in general I think menus aren't fun,
and forcing the player to regularly go through menus during normal
gameplay isn't very fun either. There are better ways to have
strategic content, or to pace out the strategic choices. Skill/
advancement choices on level up is one way of staggering out these
more boring menu bits. Identification systems also achieve it to a
certain extent, but only if you have a fairly free inventory limit.

> I tried such a simplified approach with AliensRL, and there is a
> consensus now that the game should be moved towards a more traditional
> item based inventory system.

I quite like its streamlined system. I think the game more fails on
not having enough interesting content - barrels, ranged enemies,
varying level designs, temporary power-ups, etc - a lot of the things
that make DoomRL fun. Also the levels in general are too big I
think. I guess it has the problem of a fairly boring setting to stick
to. The Alien movies were about slow suspense, not fast action, and
that doesn't translate well into a run and gun game.

--
Darren Grey

[Kornel Kisielewicz]

On 19-Jun-12 15:35, Darren Grey wrote:
> On Jun 19, 3:59 am, Kornel Kisielewicz <ad...@chaosforge.org> wrote:
>> The effect is quite opposite. As noted from many strategy discussions on
>> the ChaosForge forums, inventory management is one of the key strategic
>> elements of the game -- what to keep, what to carry, how to distribute
>> your resources. Taking it away would drastically reduce the games
>> complexity, and make it a lot more boring.
>
> I personally found that strategic element to be quite out of place in
> the game. It's fairly minor strategy wise (you have your build you
> play to, so there's rarely any real choices in what to keep - there's
> nuisance decisions rather than difficult decisions) and it isn't
> cohesive with how the rest of the game plays. But more importantly
> it's fiddly and difficult to work with, starkly at contrast with the
> very natural and fast-flowing main game.

Well, strategy talk on the forums revolves mainly around three topics:

1) Trait selection
2) Dodging/AI behavior
3) Inventory management

I'd say it's one of the big three strategical decisions in DoomRL. It's
interface might be better (especially in graphical mode -- but I'm
working on that), but taking it away from DoomRL would kill a lot of
depth at this moment. A more serious problem for me now is whether to
introduce it to AliensRL or not.

>> I tried such a simplified approach with AliensRL, and there is a
>> consensus now that the game should be moved towards a more traditional
>> item based inventory system.
>
> I quite like its streamlined system. I think the game more fails on
> not having enough interesting content - barrels,

It does have barrels :P.

> ranged enemies,

This one is tricky, because the alien theme doesn't leave much place for
that. However, plans are to make the security and military towers
derelict, having lots of bots gone rogue.

> varying level designs,

This one is already vastly improved in the beta. Each tower has it's own
layout themes.

> temporary power-ups,

How do you think this could work in AliensRL?

[Darren Grey]

On Jun 20, 7:33 pm, Kornel Kisielewicz <ad...@chaosforge.org> wrote:
> On 19-Jun-12 15:35, Darren Grey wrote:
>
> >> I tried such a simplified approach with AliensRL, and there is a
> >> consensus now that the game should be moved towards a more traditional
> >> item based inventory system.
>
> > I quite like its streamlined system.  I think the game more fails on
> > not having enough interesting content - barrels,
>
> It does have barrels :P.

Oh, I didn't notice!

> > ranged enemies,
>
> This one is tricky, because the alien theme doesn't leave much place for
> that. However, plans are to make the security and military towers
> derelict, having lots of bots gone rogue.

Kinda defeats the point of it being Aliens then.

I think what might work well is having the aliens be more intelligent,
like the kobolds in Smart Kobold. Make them very fast-moving, and run
away if not in groups, and then swarm the player when they're
together. Would make tactical positioning more important, and would
have a scarier feel.

And maybe some guns would have a knock-back effect? Would prevent
that kinda boring feeling of just exchanging damage when an alien is
next to you. Or perhaps melee attacks would knock them back.

Also, maybe start the player with some companions that would get
picked off fairly quickly. One could have a chestburster :)

> > temporary power-ups,
>
> How do you think this could work in AliensRL?

You could have a shield that needs charge, but only now and then do
you find charge points, and the charge runs out after a while.
Getting attacked reduces the charge far faster, whilst also strongly
reducing the damage you take. Could also find bio-units that inject
you with a regenerative serum, healing over 40 turns, but they won't
do it more than once (an automated anti-overdose system).

Also, tactical terrain is needed. If there were attack bots maybe
they only attack things in certain zones, and you could try and lure
aliens into their fire.

--
Darren Grey

[Archenoth]

On Thu, 07 Jun 2012 15:12:24 -0600, Jason Pickering
<jasonhp...@gmail.com> wrote:

> I still think 4 way keys is they way to go. Because most people do not
> use he numpad. They go right for the arrows.
>
> Also I think there is a place for auto-use stairs, if there is no reason
> to go back. The auto use is fine

Well... There actually are some quite accessible roguelikes that use all
eight directions out there, they are easy to pick up by people that aren't
familiar with roguelikes normally. I have seen people play it on numerous
occasions with no other roguelike knowledge. The games I am talking about
would be the Pokemon Mystery Dungeon games...

How they work for these two aspects are:

8 directions:
There is time when you are moving between squares since it does it
smoothly with animation, so pressing two arrow keys at the same time would
make you move diagonally, it is easy enough to do when moving between
places.

Stairs:
If you walk over stairs, you are asked if you want to proceed. This avoids
annoying one-way traversals if you miss something.

If someone wants to make an accessible roguelike, I would recommend
checking these games out and scavenging the ideas you like from it.

--
The arch foe

[Gerry Quinn]

In article <op.wha6m...@angelfire-win.cg.shawcable.net>,
Arch...@live.com says...

> Well... There actually are some quite accessible roguelikes that use all
> eight directions out there, they are easy to pick up by people that aren't
> familiar with roguelikes normally. I have seen people play it on numerous
> occasions with no other roguelike knowledge. The games I am talking about
> would be the Pokemon Mystery Dungeon games...
>
> How they work for these two aspects are:
>
> 8 directions:
> There is time when you are moving between squares since it does it
> smoothly with animation, so pressing two arrow keys at the same time would
> make you move diagonally, it is easy enough to do when moving between
> places.

This will work for a slower-paced roguelike where you have to think for
every move.

It would be problematic for a roguelike with hordes of 'windshield'
monsters, where players tend to hold the mouse down (and die when one of
the 'd's turns out to be a dragon instead of a dungbeetle).

Not that the windshield model is a very good one.

- Gerry Quinn

[Darren Grey]

On Jul 12, 2:04 am, Archenoth <Archen...@live.com> wrote:
> On Thu, 07 Jun 2012 15:12:24 -0600, Jason Pickering
>

> <jasonhpicker...@gmail.com> wrote:
> > I still think 4 way keys is they way to go. Because most people do not
> > use he numpad. They go right for the arrows.
>
> > Also I think there is a place for auto-use stairs, if there is no reason
> > to go back. The auto use is fine
>
> Well... There actually are some quite accessible roguelikes that use all
> eight directions out there, they are easy to pick up by people that aren't
> familiar with roguelikes normally. I have seen people play it on numerous
> occasions with no other roguelike knowledge. The games I am talking about
> would be the Pokemon Mystery Dungeon games...
>
> How they work for these two aspects are:
>
> 8 directions:
> There is time when you are moving between squares since it does it
> smoothly with animation, so pressing two arrow keys at the same time would
> make you move diagonally, it is easy enough to do when moving between
> places.

I find animation delays to be immensely annoying in roguelikes. A
nice thing about turn-based games is you can control the pace of play,
switching between fast play and slow play depending on your
situation. Having a minimum delay between turns gets annoying.

--
Darren Grey

[Archenoth]

On Fri, 13 Jul 2012 13:28:33 -0600, Darren Grey <darrenj...@gmail.com>
wrote:

Oh, it isn't constant, you can still hold down a button and zoom around at
a very fast pace.

--
The arch foe

[David Mauro]

Hi, sorry to jump in here a little late and uninvited, but I just wanted to share something in regards to simplifying input. I'm working on a web-based roguelike with the intent of making it very easy for non-roguelikers to play and came up with this input system:
http://dmauro.github.com/Keypress/
If you check out the "Any key can serve as a modifier" example demo you'll see that it has 8 way movement with just the wasd keys in a realtime environment. It doesn't activate until keyup as a trade-off, but it seems like a pretty good compromise. You could substitute wasd for arrow keys with this as well of course. I plan on using wasd however because I want to build around the system that I, and I think a lot of other gamers are familiar with which is wasd for movement, e for contextual action, hold shift for running, hold ctrl for sneaking/crouching. I'm not a big fan of mnemonic based key kinds and would rather go for a few keys all physically near each other.

[David Lambert]

On Wednesday, June 6, 2012 3:43:37 PM UTC-4, Darren Grey wrote:
> Well, I'm guessing this'll spark a number of disagreements, but I'm curious as to what other people have to think or contribute to this. I've written this article today and would like to polish it a bit more before putting it on RogueBasin. But reflecting on this is as much for my own benefit as it is intended to be a guide for others.
>
>
>
> For some this article is irrelevant – they only care about existing Roguelike players touching their games. All fine and well, but I’d like to see more people enjoying all the great games we have around, and in particular I have a goal of making the first truly accessible ASCII game. Er, wish me luck :/
>
>
>
> One problem though – the interface. I’ve watched hardcore gamers try out Broken Bottle (which is considered to have a good interface for a Roguelike) and they’ve not been able to figure out how to move, or how to leave the first level. All the assumptions we have about the interface are completely null to them. It’s immensely painful watching someone try to play your game and being so unfamiliar with the controls that they move at a snail’s pace, and have such trouble with even movement that they fail to see the rest of the depth of play.
>
>
>
> Well, here’s some points I’ve come to learn about making roguelikes more accessible for non-roguelikers. Most centre around interface, but there are some design considerations too. Feel free to post more in the comments.
>
>
>
> 4-way movement
>
> Ooh, I can hear the traditionalists grinding their teeth already… But every time I introduce a new person to roguelikes they fail to grasp the ability to move in diagonals. Years of d-pad or arrow key use has made them think purely of the cardinal directions. Also it’s hard to get 8-way movement to work nicely on a laptop, whatever crazy shift+direction scheme you might invent (and don’t even *think* about forcing vi-keys on players). WASD and arrow keys are all outside gamers can cope with. So stick to 4-way, and let the monsters only move 4-way too. It feels weird at first but you’ll get used to it. Just make sure your dungeons are 4-way connected! There are some tactical things to consider around this as well, such as pillar dancing on two squares and creating choke points more easily, but these are design elements that can be overcome. Similarly you’ll find ranged combat needs nerfing or visual radius reduced to cope.
>
>
>
> An alternative is hex, with QWE/ASD for the 6 directions. I’ll be trying this with Rogue Rage, but I’m not sure yet how well it’ll work. But from a technical point of view hex is the ultimate for all games ;)
>
>
>
> Mouse control
>
> Easily and quickly move to another part of the map (with appropriate interruptions for damage or spotting a threat), and right-click for contextual menus to quickly choose available interactions with enemies and items. Or right-click could fire a missile weapon. Mouse control makes a game hugely more accessible without hindering the game’s complexity. ToME4 is a complex game that can be comfortably played with either mouse or keyboard, or a combination. Tooltips also help convey detailed information quickly without forcing the player to read through manuals or help files – most players never read help files or manuals.
>
>
>
> Gamepad support
>
> Many players like to plug in an X-Box 360 controller. Make sure your game can be played on few enough buttons for this to work. You don’t have to directly support the input device – there are keyboard mapping programs out there for that which gamers know how to use.
>
>
>
> Auto stairs use
>
> A stairs should be treated like a wall square you can see through. Enemies can’t walk on it, items can’t drop on it, and once you bump into it you change level. This removes the need for < and > keys (why are they even separate keys?) without removing any tactical depth. Means stairs need space around them (can’t be in corridors) or need to be in-set in the walls (see Dungeons of Dredmor, where stairs use is made obvious to the player), and player should be placed adjacent to the stair tile when put in a new level. Makes a big difference to new players when they don’t even have to think about using the stairs, it’s just natural. Moving into stairs to use them should be as natural as bumping into doors to open them or moving into monsters to attack them.
>
>
>
> No controls requiring shift/ctrl/alt
>
> One reason to get rid of the stairs command… Tell a player to press < and he’ll press the , key, and then wonder why it didn’t work. In a reduced command set there’s no reason to use upper cases or keys on the shift line. Besides, on international keyboards these can be in different places, so might screw up your input in other regions. Stick to simple lower case letters or symbols easily accessible. And don’t over-rely on mnemonics – those who aren’t native English may struggle to understand q for quaff. Better to have commands grouped together in one part of the keyboard (but at a distance from the movement keys).
>
>
>
> Use standard controls from computer RPGs
>
> I for inventory is the big obvious one. C for character is also oft-used. Generally the less you have to use the better, but when you want to use keys think of what are the standards outside the genre as well. H for help is probably more standard than ? for instance. W for Wear will confuse many roguelikers, never mind those with little experience. And it's not enough to say "my keys are rebindable, people can do what they want". It's great to have, but very few people rebind keys, so focus on having good defaults.
>
>
>
> Pop-up text hints
>
> Both for interface and for gameplay, though you might want an option to turn it off. Especially at the start of the game you should have some text briefly showing the commands. It could be as easy as arrows around the character showing the move key for each direction as a quick lesson/reminder, or a small bar at the bottom of the screen saying “Arrow keys to move, F to Fire, P to Pick up items, H for Help”. But during gameplay this can be useful too, especially when introducing new features or content. If you don’t have auto-stairs use then walking over the stairs might provide a message “Stairs down to Dungeon level 3, press space to descend”. Similar for walking over items (how to pick up), or when picking up items (how to see inventory or equip). Seasoned players might not even notice these messages when they’re used to seeing them, but new players will really appreciate this help.
>
>
>
> With ASCII it’s hard to tell what new enemies are, or how powerful they might be. So how about first time an enemy type shows a piece of text appears to say “Crikey, a raging bulbosaurus!” or something similar. Bosses might have more dramatic description to denote their importance.
>
>
>
> Space as contextual action
>
> Multiple key commands is useful for fidelity of action, but in 90% of situations there is only one action that can be performed. So let’s use the biggest key on the board for it. Stairs? Space to change level. Item on ground? Space to pick up. Trap? Space to disarm. Door? Space to open/close. There’s situations where this won’t work, but the exceptions shouldn’t get in the way of what would be a much smoother experience for most of the game.
>
>
>
> Don’t rely on the game log
>
> People don’t read it, especially if you fill it with lengthy text of “A misses B, B critically hits A” etc. Have characters flash red when hit, or have pop up text above the characters showing damage amounts. Quick, simple feedback for common actions. Keep the players eyes on the game area, and don’t make them have to pick through small text to find what’s important.
>
>
>
> Easy Inventory system
>
> Don’t give the player some weird custom inventory with containers and different commands for each slot. Don’t limit their space too much either. Players want freedom and ease of use. Look at how professional games do inventories. Roguelikes aren’t alone in using inventory mechanics yet so many have failed to learn any lessons from decades of game design. For easy to use inventory systems check out ADOM or ToME4, or better yet try to innovate something simpler. Items can be such a core part of many roguelikes that you should give very careful thought to how you’ll use them and how the player can access them easily.
>
>
>
> Clarity of mechanics
>
> Don’t hide important stuff from the player and hope that they’ll get it. Make sure your mechanics are clear and understandable. You may have coded a cool system, but if people don’t know what’s going on they won’t understand the subtleties and won’t stick around long enough to enjoy it. This is where watching someone play your game is important. Without giving them advice watch how they interact with the game elements and see how easily they grasp what is going on. Don’t think you can get by on the Nethack style of “players will learn over many years” – you are not making Nethack, nor should you be.
>
>
>
> No cheap deaths
>
> By cheap I mean impossible to prepare for. This is especially frustrating early game. Challenge is good and fun, but unavoidable impossible obstacles are not. Traps are the worst for this. Don’t do traps unless they’re interesting.
>
>
>
> Tutorial zone
>
> Not many people bother with tutorials, but if they’re having a hard time learning a game it gives them something to turn to. Powder, ToME and Dredmor all have good examples of tutorials to teach specific mechanics. Note that in all 3 you can die in the tutorial – an important lesson to learn in the tutorial as well.
>
>
>
> Amusing/entertaining death
>
> Death is bound to happen, and some people find it frustrating. But you can soften the blow by adding a touch of humour. Dredmor has its famous line of “Congratulations! You Have Died!” Limbo has over the top death animations to keep people engaged after many deaths. Think of other ways to make the player laugh, like putting in tortured death screams from the character, or throwing up a short randomly generated story of how the world fell apart after the player’s death. Put out a hook to get the player back in for another game, instead of leaving them feeling bitter and twisted. It doesn’t need to be humorous – you could have random game tips relevant to the death, or small lore revelations; something compelling to keep people interested in the game.
>
>
>
> Quick restarting
>
> Make it easy for the player to start again, such as a “Restart Same Character” option on the death screen that repeats the character creation with the same options as last time. “Restart Random” is a good option to have too. Generally your creation menu should be slick and fast anyway, otherwise people will get bored of it on the 100th playthrough.
>
>
>
> Small levels
>
> Can help quite a bit, though isn’t necessary. Don’t waste the players time exploring big empty spaces. Have everything densely packed in small levels. Makes it easier on display too, reducing the needs for a minimap. 4-way movement helps with this a bit – it makes the areas effectively twice as big for play moves, letting you pack monsters and items in a tighter screen space. Smaller levels feel quicker to get through, and don’t seem so tiresome to replay after death. Easier for new players to take in as well.
>
>
>
> Permadeath optional
>
> Okay, I don’t really like this, but it works well for Dungeons of Dredmor. In it permadeath is on by default, but you have the option of turning it off. Mentally it sets the player thinking that this is the right way for the game to be played, rather than feeling like it’s a crazy design flaw. And they can be proud that they didn’t untick that box, letting them embrace the mechanic rather than be annoyed by it. It’s important to teach that permadeath is a positive thing, not an unfair and punishing difficulty.
>
>
>
>
>
> --
>
> Darren Grey

A Compromise: Default to casual controls (mouse driven) with hardcore/traditional (keyboard) and permadeath as an option.

doomrl, dungeons of dredmor, powder, etc have all done this or something similar.

Dredmor to me is a casual roguelike as you can basically brute force your way through the game with a bit of luck.