Messages

46

Traditional Roguelikes (Turn Based) / Re: A Fan Type Analysis of Roguelikes

« on: January 02, 2012, 05:12:44 AM »

And please tell me again how the nethack towel is more intuitive than my paperdoll suggestion.

It does only have put on and wear. After trying those out I can be sure I have exhausted equipping possibilities.

Forgive me, I've never played nethack, but how do you know that you only have those two options? Is it intuitive that you can only do those, are they listed as possible actions or is it found by trial and error (serious question).
[/quote]

The paperdoll is not a menu, it is half of an interaction context.

A menu is not an interaction context then? It could have menu items with hands and head. How is that different from an image?

Interaction: head interact with helmet. hands interact with weapon. The result of these interactions are easy to guess, hence more intuitive.

Well designed commands with context are always far more intuitive that contextless commands, and such a mouse UI, while less efficient than keys, can be designed to map to thousands of different game actions.

While I fully agree with second part of this sentence the first assertion eludes me. In what way is it more intuitive?

By mimicking the way real world objects work, it's more intuitive. Real world objects don't exist in a vacuum, they interact. Hence interaction context. Compare 'use meat on fire', to 'select meat, press c'. At face value it's obvious that I can guess that the first will result in either cooking (or burning ). The second is only understandable in this discussion because I contrast it with the contextual example. If I just come to any non-RL player on the street and present one of those two 'commands' and ask them to guess what happens, the first would garner far more correct guesses.

For examples of good context sensitive UI's I suggest taking a serious look at Ultima 7 through Ultima Online.

I did so a few years ago. Played on a private server. I loved how you could double click an empty pitcher and target a cow to get milk. However, players were upset there was no possibility to empty it without drinking the contents. Developers acknowledged it and proposed double clicking on a non-empty pitcher would also ask for a target. Picking ground would pour contents out. Yay, intuitive and simple! But then there were cries drinking does not work intuitively and bug reports one can't target other people to feed them. Players were led thinking if a target is asked for one also can pick other players and NPC.

The gripe I have with Ultima is you never know the boundaries of its UI. A strict set of commands is just easier for me to grasp.
[/quote]

I completely agree with you, but as I stated in my response above, just because you can find some failure in the UI presentation, it doesn't prevent the UI from being an unqualified and enormous success in intuitively presenting complex gameplay. It does take extraordinary effort to design interactions well, but the result is very much worth it.

Anyways, I've hijacked this thread long enough, I'm pretty sure we understand each other, and I respect your opinion, you've made several valid points that have got me thinking. I hope you've learned a little bit from the conversation too.

Sincerely,
Mouse based interface fan

47

Traditional Roguelikes (Turn Based) / Re: A Fan Type Analysis of Roguelikes

« on: January 01, 2012, 02:45:50 AM »

Now, I have two questions; first, can this really express everything you need done?  Second, if it can, is it still actually simpler than a command interface where you tell the guy what to do?

Bear, perhaps I did misunderstand, I thought you were talking about an expressive interface, not a universal interface where you can apply standard commands to anything. In that case keys are better, but I've never played a game where you can 'eat' anything, or 'read' anything.

In regards to attempting to apply objects in incompatible contexts. Doesn't the same thing happen in life? You try to wrap your feet in a towel and it just doesn't work? What's wrong with that compared to a key command? As long as there is clear feedback as to what the effect of an action is, I don't see anything wrong with it. It's just akin to pressing a key that has no effect when something is highlighted. And please tell me again how the nethack towel is more intuitive than my paperdoll suggestion.

The paperdoll is not a menu, it is half of an interaction context. Because we're playing games where items have some loose isomorphism with their real world equivalents we're able to make educated guesses about the effects of certain actions. Using a helmet on a head? Using a potion of acid on a head? It's up to the designer to make good decisions and comprehensive interactions. Well designed commands with context are always far more intuitive that contextless commands, and such a mouse UI, while less efficient than keys, can be designed to map to thousands of different game actions.

Perhaps you've developed such a history with roguelikes that a roguelike context automatically triggers recall of any key command you want. This is not the norm for casual players (like myself).

For examples of good context sensitive UI's I suggest taking a serious look at Ultima 7 through Ultima Online. They progressively get better and better, and by the time Ultima Online comes along, the depth of actions is enormous, larger than many roguelikes I've played. This includes extensive harvesting, crafting, enchanting, commerce (including bartering), training. If you like, I'm sure you can pick it apart and explain how one missing feature makes this a poor UI for a 'real roguelike', but the UI is an overwhelming success and can be adapted to suit many actions.

48

Traditional Roguelikes (Turn Based) / Re: A Fan Type Analysis of Roguelikes

« on: December 31, 2011, 01:25:28 AM »

Bear, have you ever played Ultima Online? It leveraged realworld knowledge to make an awesome point n' click interface. If you double click a knife (or sword, or any bladed weapon) a targeting cursor appears. What do you think would happen if you targeted a rabbit corpse? You cut up the corpse into skin and meat. Now granted there isn't an option to gouge out the eyes and repeatedly stab the corpse while yelling 'I'm a good little boy mother!', but it's pretty darn intuitive anyways.

Most skills were used in the same way.Use a hammer on an anvil and you get an option to forge weapons and armor . Use a needle/thread combo on leather and you could make leather armor. Use a piece of meat on a fire and you cooked it.

I think you are missing the point. Chopping up a corpse, forging, sewing armor and cooking are just single actions involving two items at once. The point and click interface is actively limiting choices there. What if you wanted to make useful burning the piece of meat instead of cooking it? Either you present the menu or introduce mouse gestures over the fire to change meaning. This way you increase complexity of interface way beyond what accomplishing the same with keyboard would take.

Try to design good mouse based interface for using Nethack towel or Zap'M roll of duct tape *and* make it more friendly and faster than keyboard commands at the same time. You'll see what Bear means.

I'm not missing the point at all, the point is an intuitive and expressive vocabulary of game actions. Keyboards will always be more expressive, simply due to the sheer combinatorial volume of keypresses. I can make a command in roguelike that requires you to write war and peace if I like. But this is not intuitive.

So if I want to burn meat, first I'll cook it and then I'll cook it again. Done. Slower, yes, easy, yes. If burning meat is really important to the plot, then a good designer can streamline the process. Perhaps troll meat is extra sensitive to fire and burns right away, skipping the cooking stage.

If I want to blindfold myself with a towel, use it on my characters paperdoll head. If I want to wipe my hands, use it on the paperdolls hands. Fast, yes, easy, yes.

Just like in real life objects in games can be context sensitive, and if the designer is cautious, then the relationships between objects are pretty intuitive. This requires hard work on the part of the designer, but it can certainly be expressive enough to achieve a huge variety of actions, and in a way that can be divined without a FAQ or manual.

49

Traditional Roguelikes (Turn Based) / Re: A Fan Type Analysis of Roguelikes

« on: December 30, 2011, 09:16:32 AM »

Point & Click interface. Imagine you have somebody doing things for you but you cannot tell him or her what to do.  Instead, you can only point at things.  Now, I have two questions; first, can this really express everything you need done?  Second, if it can, is it still actually simpler than a command interface where you tell the guy what to do?  I'm not really opposed to the mouse-interface idea, although it's not my cuppa.  I just doubt that the point&click language is expressive enough.  Oh, you can MAKE a point&click language that's expressive enough, if you use enough fiddly menus to provide symbols it would be easier to just type, but wouldn't it bear the same relationship to "intuitive" use of the mouse that ASL or ESL bears to "intuitive" talking gestures? -- ie, if it's that complex, it becomes a language with a syntax and grammar (or a pile of menus) that needs to be learned.  It's the complexity, rather than the keyboard/mouse mode, that presents a learning curve, and I haven't yet really seen languages of equal expressiveness that aren't equally complex.

Bear, have you ever played Ultima Online? It leveraged realworld knowledge to make an awesome point n' click interface. If you double click a knife (or sword, or any bladed weapon) a targeting cursor appears. What do you think would happen if you targeted a rabbit corpse? You cut up the corpse into skin and meat. Now granted there isn't an option to gouge out the eyes and repeatedly stab the corpse while yelling 'I'm a good little boy mother!', but it's pretty darn intuitive anyways.

Most skills were used in the same way.Use a hammer on an anvil and you get an option to forge weapons and armor . Use a needle/thread combo on leather and you could make leather armor. Use a piece of meat on a fire and you cooked it.

Most people think that mouse UI == endless submenu UI. Not so.

50

Traditional Roguelikes (Turn Based) / Re: A Fan Type Analysis of Roguelikes

« on: December 27, 2011, 05:26:07 AM »

As I rambled on above, it's not mouse vs. keyboard or anything like that. It's cognitive load + physical action - error rate. Moving your hand from the mouse to the keyboard might have a higher cost than executing a menu. Or maybe not. The point it that very few people measure these things, and just rely on 'whatever feels right'.

51

Traditional Roguelikes (Turn Based) / Re: A Fan Type Analysis of Roguelikes

« on: December 26, 2011, 11:47:35 AM »

@Krice

UI's can be rated along different dimensions, here is one what to organize it:

1: Ability to learn (perhaps through experimentation, or in-game scenarios)
2: Ability to do what you want
3: Efficiency of use, how much mental/physical effort goes into doing something (cognetics)

Classic RL interfaces fail mostly at 1, and this in turn can sometimes lead to a degradation of number 3, because it takes a lot of effort to figure out how to do what you want. Number 2 is usually executed to perfection.

Since number 1 is the first thing any player will face, it's often the highest barrier to adoption for new RL players. Number 3 is the bane of 'modern', million-menu systems, and number 2 suffers from any UI that requires physical dexterity to operate (mis-clicks and so on).

When looked at systematically, it's precisely because developers have their 'own ideas' about UI's that things are in such a state. Few people take the time to minimize cognitive load (reducing clicks/button presses, showing tooltips at appropriate times, etc), but rather chase some kind of cool factor. Good UI designers take an inventory of inputs and actions, and try to map those inputs to actions in a way that common tasks take little mental and physical effort, and related groups of inputs have some loose isomorphism with the resulting tasks (ie, if left click is move, right click could map to look, rather than bringing up character status).

Look at nintendo games, there are only enough actions available to map to the controllers buttons. Even if you could make the game world 'better' by adding another feature, the difficulty in using it would only end up backfiring. In my own game (WIP), I have a radically different approach to UI because I follow nintendo's lead. I've made loads of features that I easily could've stuffed into submenus, but I held back and tried to find other ways of representing those actions. In a few cases I decided NOT to add a feature because I didn't have a clear way of presenting an interface to it.

Sorry for the rant. UI is a measurable property. See how long it takes you to do an action, what is the rate of failure due to input error, and how long does it take to 'prime' the action. Then you can make a great interface.

In the interest of fair disclosure, some people HATE my games interface and others have praised it highly...

52

Programming / Re: Objective C Portability

« on: December 20, 2011, 02:56:22 PM »

Yeah, and although I don't have much experience with LibTCOD, a lot of competent people recommend it, so it sounds like a good bet.

53

Programming / Re: Objective C Portability

« on: December 19, 2011, 06:00:28 AM »

I don't know of any portable Objective-C libraries at all (OpenStep has not worked well for me...)

The good news is that Objective-C is a strict superset of C, so you can use any C library without recompiling.
Your best bet is to pick a good framework like SDL or something, write a roguelike engine that will draw whatever you want wherever you want it and then proceed from there.

Objective-C is a very nice language IMHO, quite readable, but most people only know it as Cocoa/NextStep.

54

Programming / Re: Spell casting types of costs

« on: December 18, 2011, 01:16:55 PM »

I'll tell you what I use in my game Mysterious Castle.

I'm going for more of a D&D type magic system, where you can learn spells of different levels, and then prepare a certain number of spells with material components when not in battle. In my case the components are mushrooms of different colours. So you can prepare X (lets say 5) level one spells when not fighting, and then during play you can cast them. This puts a limit on what the caster can du during combat, and adds a scarcity value to the material components (mushrooms), which requires you to balance out what spells you prepare/cast. It's a little like the expendable spells system mentioned above, but without being embodied in an object.

PS. For some really great magic systems you need to look at Ultima 8, it's an isometric RPG from 1993/4 which had 5 different magic systems (ok, 4 that the PC could use), each one different from the other. I thought that game felt really magical when you had to arrange red and black candles and various reagents on a pentagram in order to prepare fire spells. If you did it wrong, a demon might appear and smash you! Good times...

55

Other Announcements / Re: Thank you to this forum

« on: December 17, 2011, 03:55:30 AM »

A big hearty thank you to everyone here! Mature, positive, constructive. A really great community. And a big thanks to getter77 for moderating and maintaining this great place.

56

Programming / Re: Talents/Feats/"Special skills"

« on: December 17, 2011, 03:52:44 AM »

I personally don't like handing things out for no real reason, ie because you level up. Everytime you gain something it's an opportunity to increase the story and immersion of a roguelike, you can tie it to a quest, like an ancient book, or a legendary trainer or something. Just pressing a key after you gain a number of points is kind of boring (to me).

So of your choices, both 2 and 3 are so much more interesting than 1. Try tying feats to a location (a famous training hall), an item (a book or enchanted X), person (trainer), or action (if you can get past tons of enemies to location Y without killing anything, you have developed a new level in sneak, for example).

My 2c.

57

Programming / Re: Need more monster names

« on: December 16, 2011, 01:45:25 AM »

Yeah, mostly correct.

However I don't think you need massive changes to warrant a name upgrade. Monster AI is going to stick with a handful of templates, but it makes a big difference if you face a shambling slow zombie that slugs and claws at you, or a shambling slow wight that slugs and claws at you and drains your strength stat.

58

Programming / Re: Need more monster names

« on: December 14, 2011, 03:06:16 PM »

Uhh...

Acolyte (dark acolyte), coincidentally, that's my title on these forums 
Bugbear,
Drow Elf,
Gryphon
Hippogryph (can't remember the spelling).
Wight,
Wisp, or Will o' Wisp

That's just off the top of my head. Those are all pretty standard D&D fantasy monsters, except for Acolyte, which is a title.

59

Programming / Re: Need more monster names

« on: December 14, 2011, 12:34:42 PM »

Ah, please put them in alphabetical order and I'll come up with some!

60

Programming / Re: Let's talk a bit about world map generation!

« on: December 14, 2011, 10:19:52 AM »

This is great, I love procedural/random map generation, but it's so darn difficult! Is there a place for best practices having to do with such things? I know of the procedural content generation WIKI, but that's about algorithms and not code. Perhaps it's time to start a page on roguebasin...

EDIT:
This represents my solution to making level generation algorithms that can be used flexibly. I'm interested in peoples opinions, and I'd really love to start some kind of library project, although that might be a little ambitious.
http://roguebasin.roguelikedevelopment.org/index.php/Designing_Flexible,_Reusable_Algorithms