A text Myst Online project

[belford]

Thanks for sharing this with us, Belford!

You're welcome!

I can now connect with Firefox, however Safari still says The connection to the server could not be opened. (undefined,undefined) (but http://www.websocket.org/echo.html works).

That's annoying. I still don't know what would cause Safari to fail like that. But it's more information than I had before, so hopefully it will help someday.

Several places have multiple links (in close proximity) that pop up the same detail description. Is that intentional?

Sometimes I do this when there are a couple of related objects which get implemented in the same closeup description. I don't want to imply that either of them is out-of-scope, because the player might look at either part of the text and think "I want to look at that." But I don't want to invent two separate detail texts either, when one will suffice.

The "visited" color shift and the "back" button are both technically tricky. The underlying scripting model is powerful, which means any click could in theory do anything, which means that the engine can't really calculate whether a given link does something you've already done before.

(And stacking boxes would make the interface hopelessly confusing, I think.)

[belford]

Hm. Some web-research indicates that Safari 5.x has an old version of websocket that my server does not support. (But http://www.websocket.org/echo.html does support it, I suppose?) Looks like Safari 6.0 is needed.

(Which means OSX 10.6 users are out of luck, as far as Safari goes.)

[Mystler]

I have noticed something too: When playing Talgrea and starting the first dialogue, the detail box does not close automatically. This allowed my curiosity to click it again and get stuck in the age.
So, if there is not already one, I suppose there should be a way to allow writers to close these detail boxes manually.

[Christian Walther]

I would like the links to change color when I’ve visited them, so that in such a situation, all the links would appear “visited” after I used the first of them, so that I know that I don’t need to bother clicking on the others because they won’t reveal anything new.

This might make sense, but there are many cases where it wouldn't work well, such as when those detail descriptions change. Imagine a link that pops up a description of a panel of colored lights; if you flip a switch in another room, causing one of the lights to turn on, should the link for the panel description turn to the "unvisited" color?

Hmm, that’s a good question. I guess in some situations, when the puzzle consists of noticing that something may have changed on the control panel and you should perhaps look at it again, that could give away too much. It would probably be hard to implement too, as I guess the description isn’t generated until the link is clicked. So, no, I think it should just be based on “have I been there before”, not “does it still look the same as when I was there”.

When one detail box leads to another, I would like to have a “back” button that takes me to the previous box I was at, because in some cases it can be unobvious or complicated to figure out how to reach that box again in order to continue exploring where you left off. Or maybe the boxes should appear stacked, so that closing the topmost one will reveal the previous one. (Some of the boxes have a back link in their text, but it would be nice to have an “external” back link that is always there (unless maybe there is a gameplay reason why you shouldn't be able to go back), visually distinct so you can spot it without having to search through the text, and automatically takes you back to where you came from rather than up to a fixed ancestor box.)
(Now that I think about it, this would be good for locations as well. In fact, I have occasionally had this problem of it not being immediately obvious how to get back where you came from even in the graphical node-based (not real-time-3D) Myst games: You pop into a new location, maybe it turned you a bit, and when you turn around you see nothing or multiple things that look approximately like where you were before. This is an unrealistic, out-of-character problem, an artifact of the discrete world, because when you can move continuously, you also have a contiguous way back in your mind, so I think an equally artificial back button would be an appropriate solution for it.)

In both of these cases, the main problem is that sometimes you're not supposed to be able to go back. If the door slams shut behind you, locking you in, you shouldn't be able to go "back" to the room you came from. Likewise, text in popups may describe transient states that are no longer applicable once you've clicked away.

Yes, that is what I meant by “gameplay reason”. But I think for detail boxes, these should be rare, since looking at something should have no side effects. (As a player, I expect it to have no side effects, anything else would be surprising/confusing. Well, I guess in a game, surprise can have its place, but in other kinds of software, it’s typically a bad idea.) In the case of the transient state, the old box would just either show different text than before when you return to it, or it might have an internal annotation that causes it not to be entered into the back stack in the first place when it is left.

For places, alright, maybe a different way would be better. How about this: Any link in a new place (or its detail boxes) that goes back to the place you came from is shown in a special color.

Several places have multiple links (in close proximity) that pop up the same detail description. Is that intentional?

Sometimes I do this when there are a couple of related objects which get implemented in the same closeup description. I don't want to imply that either of them is out-of-scope, because the player might look at either part of the text and think "I want to look at that." But I don't want to invent two separate detail texts either, when one will suffice.

OK, understood. I think it would be helpful in this case if the two links could somehow be recognized as being in fact one and the same link, not separate ones – e.g. if, when clicked, they would all light up simultaneously (I’m guessing that is doable in JavaScript).

The "visited" color shift and the "back" button are both technically tricky. The underlying scripting model is powerful, which means any click could in theory do anything, which means that the engine can't really calculate whether a given link does something you've already done before.

As far as I’m concerned, it needn’t be as general as “does something you've already done before” – I’d be happy with “goes somewhere you’ve already been before” and “looks at something you’ve already looked at before”. If the engine can’t figure out by itself whether a link is a “look” link (and at what), a “go” link (and where), or neither, then maybe the author needs to annotate it with that information to take advantage of these features.

(And stacking boxes would make the interface hopelessly confusing, I think.)

I don’t know, maybe less confusing that having to figure out how the heck I get that previous box back… Or maybe there just needs to be a policy that there should be no boxes that can only be reached from another box, but all boxes should be reachable from the main text – then you could just ignore the “look” links in boxes (assuming you can recognize them as such) and be sure you’ve explored everything when you’re through with all the “look” links in the main text.

Here’s how I imagine the stacked boxes to work: Clicking on a “look” link in a box pushes the new box on the stack (and pops the old one if it is marked as transient, see above). Clicking on a “look” link in the main text replaces the whole stack by the new box. How to avoid infinitely deep stacks when there are cyclic links between boxes? Maybe if a link goes to a box that is already in the stack, it either shouldn’t push a new instance of it, but pop everything that’s on top of it, or should move the existing box to the top of the stack.

OSX 10.6 users are out of luck, as far as Safari goes

Thanks for looking into it – I can live with that.

[Acorn]

I would like to see a visual distinction between “look” links (that pop up the description box at the bottom) and “go” links (that take you to some other place). I would often click on a link and be taken by surprise when it took me somewhere else, thinking “hey, I didn’t want to walk away yet, I first want to look at everything in this place”.

This is planned, but not yet implemented.

Christian, I do agree, this was one of my first suggestions, back in June:

Sometimes I found that a link would unexpectedly move me on when I hadn't read everything at that location. Maybe that was my mistake, of course! I'm not familiar with this genre of gaming - apart from the old-style text games from the old days so I may have missed something. But I wondered whether it might be possible to signal [more clearly?] which are the "move on to next location" links and which are the "explore what is around you" links?

and the reply I got was:

Also, you're absolutely right that links should distinguish "look" from "move". (There are also "act" links, but only a couple of examples so far. Eating a jellybean in the tent is an example.)

I have added that to my todo list.

[Christian Walther]

Thanks Acorn, I must have missed that. I thought I had re-read this thread before posting, and actually wondered why nobody had brought this up… must have been too late at night. Or too hot outside. Or both.

[Pavitra]

So, if there is not already one, I suppose there should be a way to allow writers to close these detail boxes manually.

unfocus() does this.

I think it would be helpful in this case if the two links could somehow be recognized as being in fact one and the same link, not separate ones – e.g. if, when clicked, they would all light up simultaneously (I’m guessing that is doable in JavaScript).

I like that. Because it only applies at the instant that you click, it automatically behaves correctly if things vary behind the scenes.

It occurs to me that, once there are different colors for move/look/action links, it might also be nice to be able to falsify those colors. For example, the shelves link in Tsani-Tsina is implemented as an action, but meant to be perceived as a description.

[belford]

Or maybe there just needs to be a policy that there should be no boxes that can only be reached from another box, but all boxes should be reachable from the main text

I think this is a good idea; I have stuck with it *except* when a detail is supposed to be unobvious. (Things which are supposed to require some amount of searching to uncover.)

My general response to the "visited color" suggestion is that it is low-benefit for the amount of work involved. In general you will see *all* links in that color, all the time, except for your first visit to an Age. Or we could have some policy where the color resets after some amount of time, or on the next visit... this is even more work. :/ So I will add this to the feature list, but I don't put a high value on it.

It occurs to me that, once there are different colors for move/look/action links, it might also be nice to be able to falsify those colors.

I think these colors will have to be set manually by the author. (Doing it automatically would require extra database fetches when generating locale descriptions.) So you will have every opportunity to get them wrong. :)

(I realize automatic is better, but cheaper is also better. Sigh.)

[Pavitra]

There seems to be no way to trigger arbitrary Code upon an EditStr being saved. There also seems to be no useful way to have a player EditStr, so editable texts can only be per-instance, not per-player. (Either or both of these may have been addressed upthread; I don't feel like going back to check.)

There is now a large scroll of paper in Terelin where anyone can post messages. A signature will be added automatically after your message. Only the five most recent messages are retained.

[KathAveara]

I got around that problem by not having the EdtStr directly display its contents: you must first click another link which moves the comments of the EdtStr to another property which is displayed, and also fires any other arbitrary code.