08 Feb, 2013, arendjr wrote in the 1st comment:
Votes: 0
This post is mostly a cross-post from the PlainText blog that I want to share with you.

After some heavy development of the past weeks, I have updated the demo world and created a little mini-quest to introduce the new functionality. But first let's see what's new:

  • Rooms have dynamic descriptions now, which include spatial relations. This started after a discussion here on MudBytes.

  • Looking at items or portals can reveal other items or portals that are in close proximity.

  • Looking into arbitrary directions, and turning to directions is now properly supported and shows generated descriptions of whatever's nearby in the direction you're looking.

  • Some heavy updates to the map editor. Not visible on the demo server unless you got an admin account, but look at the screenshots to get an idea.

  • Lots of bugfixes.

Okay, now onto the mini-quest. Remember it's not really a quest with a storyline or anything else, it's just a little teaser to invoke some participation, give an idea of the new features, and gather feedback…

Alright, the demo world contains part of a little city called Middle Port. There's a city wall which you can get on top of after a little bit of effort. From the city wall you can see the roofs of various buildings, and you will be able to see a man on those roofs. Normally, this man is a little too far to see much details about, but nonetheless there is a way to get close-up view of him. If you manage to do this, you will be able to answer the following question: What's the sigil of the man on the roof? Anwers can be posted here in this thread or in the comments on the blog :)

If you've done the mini-quest, or maybe get stuck, I'd be interested to hearing your feedback! What did you like best about the experience? What did you like least about the experience? Specifically, how do you experience being able to see and hear events from other rooms?

Cheers!

The demo server can be reached at http://mud.yunocloud.com:8080/.
09 Feb, 2013, Idealiad wrote in the 2nd comment:
Votes: 0
I gave it a try, but I can't figure out how to get closer to the man. Getting on the wall wasn't too bad. I have some ideas about how to get a closer view Spoiler
telescope?
but searching around the city I didn't get anywhere. I thought Spoiler
maybe in the shipyard I could find something, but no luck.


I noticed one odd thing, doors seem to close themselves after you without you doing anything. Unless you get a message saying the door does that they should stay open IMO.

It would be helpful in shops to see a note in the room description that you 'can do X' to get a list of something to buy. It took me a second to figure it out (basic user interface should be immediately obvious I think).

I'm not sure how I feel about the sensory events. When there's no one else online it's fine, but it might get spammy if you also have other players running around. I think it'd be important to be able to set OOC levels of sensory spam control.
09 Feb, 2013, arendjr wrote in the 3rd comment:
Votes: 0
Thanks for the feedback! I can tell you your hunch is correct, and you may find it through some more enquiry ;)

Idealiad said:
I noticed one odd thing, doors seem to close themselves after you without you doing anything. Unless you get a message saying the door does that they should stay open IMO.

Hmm, it seemed intuitive to me to have them close automatically. Otherwise everyone would leave them open and the purpose of a door gets lost… But it's an interesting point :)

Idealiad said:
It would be helpful in shops to see a note in the room description that you 'can do X' to get a list of something to buy. It took me a second to figure it out (basic user interface should be immediately obvious I think).

Agreed. In fact, my girlfriend complained about the same thing too. I'll figure out a way to make this more intuitive and obvious.

Idealiad said:
I'm not sure how I feel about the sensory events. When there's no one else online it's fine, but it might get spammy if you also have other players running around. I think it'd be important to be able to set OOC levels of sensory spam control.

Yeah, the level of spam is a sensitive topic. I don't like an OOC solution though; I'd consider it a failure in design when you leave it to the players to configure their experience. Also the work for builders would become more complicated if they cannot rely on a consistent experience for players.

Partly I think it is important to design the game world in such a way that whatever players see is actually relevant. But I've also had the idea of introducing thresholds that can filter out certain events when a lot is going on. I appreciate the feedback and of course I'll try to keep improving the experience.

Cheers!
09 Feb, 2013, Rarva.Riendf wrote in the 4th comment:
Votes: 0
Quote
Hmm, it seemed intuitive to me to have them close automatically


Unless they are 'automatic door' that would also open automatically btw, it is pretty unituitive. You should only change a door status if no one is around looking (a tree falling in the forest yadayada). Or if you could send an event that would shut them down by the wind making noise, or anything. But you should inform the player the door close without any action.

Quote
Partly I think it is important to design the game world in such a way that whatever players see is actually relevant. But I've also had the idea of introducing thresholds that can filter out certain events when a lot is going on. I appreciate the feedback and of course I'll try to keep improving the experience.

A concern I raised in another thread, with an event system with sounds. You want to hear footstep at night in a silent surrounding, but not when there are plenty people around. Maybe using a 'weight' system, to flag them as background noise if the event raise too many occurence in the same room. (and when this number of occurence suddenly decrease ALSO raise an event to say it…going from lots of noise to silence is something you want to notice)
09 Feb, 2013, Idealiad wrote in the 5th comment:
Votes: 0
I meant to add one more thing about doors; if a door is unlocked (or if you possess the key) it's nice to have implicit opening without you doing the command first. I guess I can see some advantages to keeping it the way it is, for example if you're being chased, but I'm not sure that outweighs the ease-of-use argument.
10 Feb, 2013, Idealiad wrote in the 6th comment:
Votes: 0
arendjr said:
I can tell you your hunch is correct, and you may find it through some more enquiry ;)


Fair enough, but all I can say is I've been all over using that idea and haven't been successful. So while it may be possible, it doesn't seem reasonable :).
10 Feb, 2013, arendjr wrote in the 7th comment:
Votes: 0
Took a look at the logs and I notice I would have to improve the responses of the city guards a bit :)

Spoiler
The reason you couldn't find it is because the magic word is binocular rather than telescope ;)

He will spoil that himself through some conversation after you greet him, but apparently nobody does that :)
10 Feb, 2013, Idealiad wrote in the 8th comment:
Votes: 0
Ha! Good one. I think the reason I didn't hit on that was Spoiler
binocular doesn't seem to fit the setting. Then again, there is that lighthouse I guess.
10 Feb, 2013, quixadhal wrote in the 9th comment:
Votes: 0
Just to second the bit about doors…. they should be consistent. If you have to open them manually, you should have to close them manually. If they auto-open (assuming you have keys, or whatever other prereqs to be able to open them), they should auto-close. In either case, it never hurts to print a message informing the player that the door opened or closed.

As for the event spam… I think what you really want is notification based on rate of change. If you're in a noisy crowd, you don't want to be told about everything going on around you, only the really loud events that stand out… or if it suddenly gets quiet. If you have a value associated with the noise level at the listener's POV, what you could do is print the initial events and then scale them back so you only show spikes. Basically, simulate people getting used to the environment around them.
11 Feb, 2013, Idealiad wrote in the 10th comment:
Votes: 0
The problem with doing it dynamically like that is text has no ambient cues. If you walk into a loud, crowded party, your senses are on overdrive at first, but then they adjust to the environment. However the ambient sensory cues don't drop off. In text, unlike visually or aurally, you have no way of registering those ambient cues in a dynamic system like you describe. I think a better option might be some kind of dynamic grouping that still indicates the level of sensory events, just with less text.
11 Feb, 2013, arendjr wrote in the 11th comment:
Votes: 0
Well, I have already spent considerable effort into grouping characters, for when you look into a specific direction. This results in messages like:

Quote
In the distance, you see some people.


This grouping works even when those characters are not in the same room as each other, and depending on visual clarity they will be regarding as simply "people", or grouped between "men" and "women", or actually become identified. The message from above may look like this when I use my binocular:

Quote
In the distance, you see a shopper, a housewife and a shopper walking away from you.


I guess a sensible way to keep spam under control would be to queue messages from other rooms for up to a second for example, and if multiple come in they can be grouped using the same (or slightly tweaked) algorithm.
11 Feb, 2013, Idealiad wrote in the 12th comment:
Votes: 0
Yes, that sounds like it could work.

OK, I finally completed the task. Spoiler
The sigil of course is a black water drop
.

I'd say it was useful as something to get me to explore the city. However, speaking as a long-time text adventure player, Spoiler
'magic word' or 'guess the word' quests, while a staple of text adventures, are not really considered fair puzzles. Then again, you didn't say you were trying to be fair! :)
11 Feb, 2013, Idealiad wrote in the 13th comment:
Votes: 0
Sorry for the double post, but this relates back to the senses discussion.

In the mud you'll see output like,

Quote
You hear someone walking to the northeast.
You hear someone walking to the northeast.
You hear someone walking up to you from the right.

City Wall
You are on top of the city wall. From here you have a clear view over the forest to the south, as well as over some of the buildings in the city. On the roof, you see someone.
Obvious exits: northeast, west.You see a city guard.
A city guard walks west.
You see a city guard walking away from you.


So I take it the 'someone' was the city guard. However there's never a message that a city guard has arrived in the room.

I guess this makes sense from a facing perspective – you see him walking away when he passes you I suppose. But from a user playability perspective this doesn't seem so good. The last message that you see is that 'someone walks up to you', then nothing. Is the player supposed to face in the correct direction to see who has arrived? This will lead to the infamous 'lighthouse effect' of 2D games with a restricted field-of-view, where the player constantly spins around to see who's there. It's OK in a FPS, but I think this would be awkward in a text-based game.
11 Feb, 2013, arendjr wrote in the 14th comment:
Votes: 0
Cool! Thanks a ton for playing and providing feedback! I definitely learned a lot :)

Spoiler
I have to say I never really intended to be unfair and make it a guessing game, though indeed it turned out to be like that much more than I thought. That alone is very valuable feedback. Btw, before I posted the challenge I let my girlfriend do a playthrough without giving her hints to see if it was doable, and she actually did intuitively greet the guards which quickly let her to solve it :)


Regarding the "walking up to you": Yes, it is intentional that you don't know who it is. To be honest I don't know if the usability of that will indeed work out in practice, but the thought behind it is that you should not know if it is a friend or foe, giving some extra tension and suspense. The decision actually comes from a different scenario than the demo world, so it might seem extra out of place here. Thanks, I'll keep it in mind :)
11 Feb, 2013, quixadhal wrote in the 15th comment:
Votes: 0
I think it's a good example of usability. While having the guard's identity remain hidden until they enter your field of view makes sense in a graphical game, text games make assumptions because the player CAN'T gain information at the same rate they could visually. So, one such assumption is that if the guard is in a position where they COULD be seen by the player, assume that the player isn't standing there like a robot, but is actually looking around and staying aware of their surroundings. If they heard someone walking up from the right, they'd logically turn their head and look… don't force them to actually do it.

You might want to implement a "recognizeable" value to associate between various NPC's and players. For example, a city guard is likely going to be easily recognizeable on sight, as they normally have specific uniforms. A merchant might not stand out as much to most people. To make it more interesting/useful, you could assign different values to different classes/professions/etc. By that, I mean that to a fighter, a merchant is a merchant unless they're at their place of business, but to a thief, a jeweler and a fruit vendor might be easily distinguishable. Likewise, the fighter would have no problem telling an archer from an infantryman, but to a mage, they're all just soldiers.
11 Feb, 2013, arendjr wrote in the 16th comment:
Votes: 0
quixadhal said:
I think it's a good example of usability. While having the guard's identity remain hidden until they enter your field of view makes sense in a graphical game, text games make assumptions because the player CAN'T gain information at the same rate they could visually. So, one such assumption is that if the guard is in a position where they COULD be seen by the player, assume that the player isn't standing there like a robot, but is actually looking around and staying aware of their surroundings. If they heard someone walking up from the right, they'd logically turn their head and look… don't force them to actually do it.

Well, it's a tradeoff of course. Usability is only one aspect, where atmosphere and suspense are others. I want to purposefully limit line of sight to the direction the player is watching to emphasize the feeling that someone or something else can creep up on you from another angle. Be aware it's also an experiment. Maybe it won't work out as I intend to, maybe it could become too cumbersome, but it is the direction I want to go and try out.

Btw, there's also another catch to seeing everything from all directions at the same time: You won't know anymore where something is happening unless you add even more text. Right now if I'm facing east, and I see something happening in the distance or ahead of me, I know it's happening east of me. Seeing in all directions simultaneously would possibly lead to even more spam, and even longer text messages to communicate what's happening and where.


+1 on recognizeable attributes :)
12 Feb, 2013, Runter wrote in the 17th comment:
Votes: 0
Quote
Just to second the bit about doors…. they should be consistent. If you have to open them manually, you should have to close them manually.


Why? I don't see it as consistent because if you walk into a door it's a user initiated action that can semantically be considered "I want to walk into that room." But I don't see the same semantic as "I want to walk into that room and close the door." Almost every game I've played that auto opens door never auto closes them. It would be surprising to most users. Also, not desirable to most users. You could have a configuration to "auto close" doors, but I suspect there's no advantage to doing this and the general usecase for players will be to want their line of sight and map unobstructed (for most games.)

Actually, what I mean is that I don't see a clear way to implement it just because you want to auto open.
15 Feb, 2013, Nathan wrote in the 18th comment:
Votes: 0
It might be easier to say something when the door will stay open without further effort than the reverse. I do agree that open doors should stay open. How hard would it be to implement the user adding open/close after the exit name to indicate what state you'd like to leave the door in?

Runter said:
Quote
Just to second the bit about doors…. they should be consistent. If you have to open them manually, you should have to close them manually.


Why? I don't see it as consistent because if you walk into a door it's a user initiated action that can semantically be considered "I want to walk into that room." But I don't see the same semantic as "I want to walk into that room and close the door." Almost every game I've played that auto opens door never auto closes them. It would be surprising to most users. Also, not desirable to most users. You could have a configuration to "auto close" doors, but I suspect there's no advantage to doing this and the general usecase for players will be to want their line of sight and map unobstructed (for most games.)

Actually, what I mean is that I don't see a clear way to implement it just because you want to auto open.


What's being argued, I think, is that most people type the exit expecting that opening the door and using the exit belong within the same action. No one in the real world makes considering whether the door is open/closed and actually opening two distinct actions. It's treated as one action, such as going out or going in. If you can figure it out, maybe you should consider making outside doors auto close and implement a way to prop them open (e.g. a doorstop) and make inside doors simply stay however the user makes them and implement a way to barricade them/hold them shut. That would seem to be consistent with the player's expectations.
15 Feb, 2013, quixadhal wrote in the 19th comment:
Votes: 0
It's also generally true, that in the real world, when we open a door that was closed, we tend to then close it again afterwards. IE: there was a reason for it to be closed in the first place.

That's why I said it should be consistent. If you auto-open doors as you walk into them, you should auto-close them behind you too. If you want to leave it in an open state, manually type "open door" after you've walked through it. OTOH, if you have to open a door first, then you should also have to close it by hand.

But any time an automated action happens, the user should be told about it. Think back to the infocom games.

> go north.
You head north [opening the door first].

You're in a new room. blah blah blah.
[The door closes behind you]
>
0.0/19