Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUSHclient ➜ Plugins ➜ Calling Plugin procedures from triggers
Calling Plugin procedures from triggers

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2 

Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #15 on Wed 11 Jul 2007 06:50 PM (UTC)

Amended on Wed 11 Jul 2007 06:55 PM (UTC) by Shadowfyr

Message
Ok, first, I was thinking in terms of processor overhead, since you are **not** just mixing only premade sounds, but also possibly several dynamic speeches that have to overlap each other. That takes extra processing time for *each* "voice" that is going to be talking. A server might be able to use a separate sub-server to handle that, or actually have far more processing power at its disposal, maybe. Probably not with most normal muds though. MMOs get by with mixing it on the client end because a) they don't usually support spoken speech, unless its parsing the output in the chat window, so there is no simultaneous events, and b) they used canned speech, which obviously isn't going to be the case of 10 players are all in a room talking at once, like in a market. Mostly, they probably handle it by *not* having those things happen at the same time, so you could probably do that, but it takes away from some of the realism, and won't help you if you integrate something like real-time voice chat too. Mind you, that is probably going too far for a mud. lol

Second, nothing stops you, if the voices are distinct enough, or one is louder, from doing and people do naturally, and pick their own names out of speech in a crowd, or focus on a single speaker in the room. You could have 4-5 people speaking in the room, at different locations and distances and still follow what is happening. You could also have a quite distinct voice that is *only* used to do the equivalent of narration, for the descriptive parts. It can't be any harder than real life to follow, and last I checked, even blind people manage to do fairly well in crowds, despite all the noise. Why would it be different when the crowd "is" noiseless babble, with 2-3 real merchants and a few players talking to those? I think you exaggerate the problem a bit. Its all about the quality of the speech and how adaptive you can make it. Sadly, most probably use what isn't much better than 10 years ago, since that sort is simple to implement, so its uncertain how different you *can* make the voices. That is the only serious hangup I can see with it though.

Oh, and to add a bit, this idea would "require" males to use male voices, females to use female, etc. Making them distinct... Its a bit more complicated, but maybe you could take the NPC/Player name and use that to generate the "voice" that specific individual has. The problem is, again, finding a speech system that is a "bit" better than the old ones I have heard, so you can get a better variety and fewer, "Ugh, that combination of settings is horrible!", situations. lol
Top
Posted by Sean Randall   United Kingdom  (14 posts)  Bio
Date Reply #16 on Wed 11 Jul 2007 08:24 PM (UTC)
Message
A hallmark of MUDs has been their ability to run on many systems, regardless of spec. I think in adding streamed speech per room detracts from that considerably.

I see the concept, but to be truly useful a whole new kind of client-server protocol would need to be negotiated and a client probably created from the ground up, with accessibility taken into consideration from the outset.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #17 on Wed 11 Jul 2007 08:51 PM (UTC)
Message
Quote:
MMOs get by with mixing it on the client end because a) they don't usually support spoken speech

Do you have any idea what it would entail to mix any form of sound whatsoever on the server end for a game with several clients? It's not that MMOs "get by with mixing it on the client" -- it's that they cannot afford to mix it server side.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #18 on Thu 12 Jul 2007 04:13 AM (UTC)
Message
Quote:
Ok, first, I was thinking in terms of processor overhead, since you are **not** just mixing only premade sounds, but also possibly several dynamic speeches that have to overlap each other. That takes extra processing time for *each* "voice" that is going to be talking.

I will agree that it takes extra processing time for each voice used, which is why it would be so much more efficient client-side in terms of speed. If everyone logged into the game were forced to be in the same room or maybe just a handful of rooms, then having a sound server streaming sounds might not be a terrible idea. However, if you have a decently large game, the amount of sound generated will increase quite a bit per person (also taking into account that not everyone will have the same communication channels open), and that there will be several rooms that people could possibly be in.

For example, on Aardwolf right now, there are 347 players logged in. There are 28031 explorable rooms (a few thousand are flagged non-explorable). There are also 29 channels (not including say and personal tells and such), which are all individually able to be toggled on and off. Due to the variety, it would make much more sense to just send the text and let the client sort it out.

To expand that further to show why MMORPGs don't deal with sound like that, imagine something similar on the scale of 10,000 people on at any given time, having to deal with combat sounds, environmental sounds, and mixing people's speech. Not a terribly easy task server-side, unless you have a supercomputer dedicated to the task.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #19 on Thu 12 Jul 2007 05:10 AM (UTC)
Message
Quote:
If everyone logged into the game were forced to be in the same room or maybe just a handful of rooms, then having a sound server streaming sounds might not be a terrible idea.

I'm having trouble understanding why it would ever be a good idea even for that kind of situation. You'd not have the processing problem (at least not as much) but you would still have all the bandwidth issues. This isn't just a speed issue; it's a load issue in general.

You're already talking about a special client that can play sound sent from the MUD. So just let the client mix sounds that are all client side. I honestly can't see any reason whatsoever for the server to bear all or even any load of mixing and broadcasting the sounds...
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #20 on Thu 12 Jul 2007 05:27 AM (UTC)
Message
I was only referring to the processing issue in that post. I made no mention of bandwidth whatsoever, or I'd start talking about a game I play which has a chatroom and a shoutcast station, and how there is sometimes one is up to a minute behind the other. Not terribly effective in terms of communication, but you can get fun games of Marco Polo going. Granted, these two things are on different servers, so there won't be quite as big of an issue with lag time, but bandwidth is an issue for servers, which is why a lot of muds use mccp, which sacrifices minor processing time for huge savings on bandwidth. It's much more effective for the money in the long term.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #21 on Thu 12 Jul 2007 06:40 PM (UTC)
Message
To be fair, I am not talking about mixing everything, just speech, in a stream. Environmental sounds, music, babble, etc. are are possible to handle without the overhead on the client end. The biggest worry is, what happens on the client end when you have 10 people speaking in the same room as the player, and you need to map all those voices, in real time, into the sounds... Each of those has to take process time to convert from text to speech *before* you can hear them. But yeah, there is the point about how big of a mess it would be with a lot of rooms, each with a player in them, each hearing 4-5 voices. The issue is if the client end could handle 4-5 in a room well either, given some of the hardware a person might be using to run the client.

I mean, its a lot easier with real voice over IP, where people just talk, but you still have the problem of NPC speech there, which isn't as solvable. For a text mud, its unlikely anyone is using voip, so the problem is just amplified. Short of a hardware based solution, like a special translation card that you could feed text and parameters, which would then dump that through something like the CD audio connector, you are going to be looking at the OS trying to sort it out. A real mess, if you have dozens of voices involved.
Top
Posted by Nick Gammon   Australia  (23,133 posts)  Bio   Forum Administrator
Date Reply #22 on Thu 12 Jul 2007 09:09 PM (UTC)

Amended on Thu 12 Jul 2007 09:11 PM (UTC) by Nick Gammon

Message
MMORPGs try hard to get the client to do as much as they can. After all, a single game server is likely to have 1000 clients hanging off it. Any job the server takes on has to be multiplied by 1000. Streaming audio (or video) must be one of the most data-intensive jobs you could choose to do.

In fact, MMORPGs download as much as they can (or install off the CDROM), like scenery, mob images, sound effects. After that they try to make the client do things that it safely can without compromising security (allowing cheating), such as letting characters move locally, and sending updates to the server about where the character is now.

They try to predict which way a mob will run when it attacks you, so it looks smooth. Sometimes they get it wrong and the mob gets suddenly readjusted to somewhere else.

In fact, I was thinking if I ever redid a MUD server, I would use a custom protocol so that if you walk in and out of a room a dozen times, it doesn't have to resend a 5-line room description each time (after all, the room itself hasn't changed).

That would make stuff like "look" and "inventory" very fast, because it would simply be displaying its local copy of the information. Then you could even have the client display the room description, inventory, equipped items, known skills, etc. in special dialog boxes, since they would be unambiguously identified for what they were, rather than relying upon complex triggers to try to decode incoming text.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #23 on Fri 13 Jul 2007 04:37 AM (UTC)
Message
Quote:
In fact, I was thinking if I ever redid a MUD server, I would use a custom protocol so that if you walk in and out of a room a dozen times, it doesn't have to resend a 5-line room description each time (after all, the room itself hasn't changed).

Actually, Aardwolf does something similar to this already. It gives you options for what to see when you enter a room, with the 'look' command always displaying the full room description.
You are currently set to brief mode 1.

Valid brief modes are:
   0 - See all room descriptions.
   1 - See new room descriptions only.
   2 - Never see room descriptions.

The amount of bandwidth this saves is amazing. The only drawback is when wandering into a new mazed section. You can always tell when you've entered a new room when you have brief set to 1, so it's a bit harder to trick the people with this setting.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #24 on Fri 13 Jul 2007 06:07 AM (UTC)
Message
Brief is a more or less standard feature, isn't it?

Yes, the part about not being able to fool players is the only big problem I can see. (Same thing about showing vnums or not.) If that was really a problem, you could set up a flag that effectively ignored the middle brief setting, and always considered that you'd never been in the room before.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #25 on Fri 13 Jul 2007 06:50 AM (UTC)
Message
No idea if it's a standard feature or not. It's the only mud I've been able to stick with for any decent length of time in the past 10 years. As for the explore issue, I'd rather see the flag do the opposite, make it always look like the room has been visited before, then process as normal. At least for every room except for the first one. That way people might not notice something is up if they drop an item, then walk into the room again from another room.

But until this is implemented, I have to result to my other ways of torturing people trying to figure out the area quests... Muhahaha! erm... I mean, I have ways to add unique and creative challenges to enhance the playing enjoyment of others.
It is much easier to fight for one's ideals than to live up to them.
Top
Posted by Shadowfyr   USA  (1,790 posts)  Bio
Date Reply #26 on Fri 13 Jul 2007 07:17 PM (UTC)
Message
Well. I think it is probably pretty standard. When pathing I use brief all the time, since the buffering for command *and* text don't work well on the mud I play at, so if you move more than, I think, 10 rooms, while in verbose it chops most of the rooms that follow, including the one you arrive in. As a result, I do stuff like, "brief, 20 s, 4 n, 3 ne, 5 s, brief, 1 s", this eliminates the buffer glitch for all the rooms in between, but still lets the last room you arrive in be visible. Mind you, a mud+client that stored descriptions locally, like Nick is talking about, could display them all, if you have been there before, without doing brief, but most are going to choke in the middle of a long walk if you don't add a command delay into the mix.

In any case, we have as options:

1. Show short description (room name).
2. Show short long description.
3. Show both.

It has no way to do something like showing only "new" rooms. And frankly, for that to be reasonable, I would expect a sort of negotiation like, client: "I want to move to x.", server: "ACK Unchanged #", or server: "ACK Changed # + data". For clients with no support for that, you would still need a "always show room contents."

As for triggers, etc. One could simply set the server to send something like: "NACK + data", meaning, "I am not going to tell you if this room changed or not, or even what its internal ID is, but here is the room.", for those areas that you *don't* want someone to map as easily.
Top
Posted by Shaun Biggs   USA  (644 posts)  Bio
Date Reply #27 on Fri 13 Jul 2007 09:52 PM (UTC)
Message
Aardwolf solves this problem twice. First off, the brief command will check to see if you've been in a room before and display room descriptions according to the option you have set. Secondly, and more frequently used, there is a run command. You type in "run 2s10wn2wn4wn8wn14w12w8n" and the mud will move you there, just showing room names and how many moves you have left at each step. This also cuts back on data sent out from the mud. It's also displayed in a way that screen readers can be set to just plain ignore the output until you hit the last room.
It is much easier to fight for one's ideals than to live up to them.
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

83,637 views.

This is page 2, subject is 2 pages long:  [Previous page]  1  2 

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home