ID:154548
 
I'm experimenting with a nifty concept in my latest project (which basically consists of a series of nifty experiments.) I don't want to deal with the constraints of assigning each room in the MUD a set of spatial coordinates, for figuring out distances and things, so for shouts, I decided to simply make it broadcast to everyone in the same "region" (regions being fairly small for this purpose... a single house, a graveyard, and so on.) But when I was building the first region (a rural Catholic church), I came up with the idea of making it so that if you play a song on the churchbells, it would broadcast to everyone in the church, the churchyard, and surrounding regions. Then I came up with the auxiliary idea of making it so that if you go up to the belfry and shout something, it would be similarly broadcast.

A little while later, I was adding the confessional, and it occured to me that although the priest and penitent have separate alcoves, things said in one should be able to be heard in the other... since this was somewhat similar to the previous idea, I thought it would be nifty to make a general system to handle both. Therefore, acoustic properties. Each region and room can have specific instructions for what happens to things that are said, whispered, and shouted. Indoors, in buildings with thick walls, shouts might just travel to the adjoining rooms and perhaps rooms adjoining them, whereas outdoors they may bbe carried to everyone around. In a noisy room, it may be impossible to hear anything EXCEPT shouting. In a narrow stone corridor or high vaulted ceiling, anything said aloud may echo all around. If you want to get a message to everyone, shout it from the rooftops... literally!
Therefore, acoustic properties. Each region and room can have specific instructions for what happens to things that are said, whispered, and shouted. Indoors, in buildings with thick walls, shouts might just travel to the adjoining rooms and perhaps rooms adjoining them, whereas outdoors they may bbe carried to everyone around. In a noisy room, it may be impossible to hear anything EXCEPT shouting. In a narrow stone corridor or high vaulted ceiling, anything said aloud may echo all around. If you want to get a message to everyone, shout it from the rooftops... literally!

I've actually been playing with "acoustics" in CATs... Mainly, in my case, I made a little 'sound obj'. This little sound obj would move straight towards any mob within a certain range. Every time it passed through a turf, it would lose a bit of volume. Passing through walls and stuff would drop volume significantly. If it ran out of volume before it reached the mob, the mob wouldn't hear anything.

Tests were okay, but when there were a vast amount of mobs in range, it lagged considerably (NPCs needed to hear sounds too, so they could come running if someone fired a gun -- I'd have filtered them out otherwise).

Also, sounds didn't reflect, and they didn't carry better at different elevations, etc.

Something to think about, though!
In response to Spuzzum (#1)
I think defining an object would be more work than I need... sound travels faster than anything else should in my MUD world, so no need to figure delays... and since the game is room/region based, I think handling it that way is good for my purposes. However, that would be a great idea for LexyMUD... I feel severely vexed that oview is limited to 2xview, as I intended to have the font size for shouts begin at 5 and diminish by 1 for each multiple of view the recipient is away from the target, with the shouter's identity lost after a certain point. If I generate sound objects and send them out, though, that has possibilities for extending the range to the desired amount.

On 6/8/01 10:53 pm Spuzzum wrote:
Therefore, acoustic properties. Each region and room can have specific instructions for what happens to things that are said, whispered, and shouted. Indoors, in buildings with thick walls, shouts might just travel to the adjoining rooms and perhaps rooms adjoining them, whereas outdoors they may bbe carried to everyone around. In a noisy room, it may be impossible to hear anything EXCEPT shouting. In a narrow stone corridor or high vaulted ceiling, anything said aloud may echo all around. If you want to get a message to everyone, shout it from the rooftops... literally!

I've actually been playing with "acoustics" in CATs... Mainly, in my case, I made a little 'sound obj'. This little sound obj would move straight towards any mob within a certain range. Every time it passed through a turf, it would lose a bit of volume. Passing through walls and stuff would drop volume significantly. If it ran out of volume before it reached the mob, the mob wouldn't hear anything.

Tests were okay, but when there were a vast amount of mobs in range, it lagged considerably (NPCs needed to hear sounds too, so they could come running if someone fired a gun -- I'd have filtered them out otherwise).

Also, sounds didn't reflect, and they didn't carry better at different elevations, etc.

Something to think about, though!
In response to LexyBitch (#2)
On 6/8/01 11:08 pm LexyBitch wrote:
I think defining an object would be more work than I need... sound travels faster than anything else should in my MUD world, so no need to figure delays... and since the game is room/region based, I think handling it that way is good for my purposes. However, that would be a great idea for LexyMUD... I feel severely vexed that oview is limited to 2xview, as I intended to have the font size for shouts begin at 5 and diminish by 1 for each multiple of view the recipient is away from the target, with the shouter's identity lost after a certain point. If I generate sound objects and send them out, though, that has possibilities for extending the range to the desired amount.

Well... you could filter through the mobs in world.contents, performing a get_dist() on each to see if they are in range.

Alternately, you could use block(locate(usr.x - 5*world.view, usr.y - 5*world.view, usr.z), locate(usr.x + 5*world.view, usr.y + 5*world.view, usr.z)) and loop through the contents of each turf in the block() for mobs. (Make sure to check that the boundries of the block are within the world!)

Each method will take a while. I imagine the relative speed between the two methods would depend on the world.view and how many mobs you have in the world.
In response to Shadowdarke (#3)

Well... you could filter through the mobs in world.contents, performing a get_dist() on each to see if they are in range.

Alternately, you could use block(locate(usr.x - 5*world.view, usr.y - 5*world.view, usr.z), locate(usr.x + 5*world.view, usr.y + 5*world.view, usr.z)) and loop through the contents of each turf in the block() for mobs. (Make sure to check that the boundries of the block are within the world!)

I think the object idea would be quicker... a maximum of 24 objects (5 x 5 grid, with the player being the center object) needed, and instead of actually "sending them out", they could just be created at the appropriate distances. I'll put a minimum time between a given player's shouts, just to prevent abusive spam.
In response to Spuzzum (#1)
I've actually been playing with "acoustics" in CATs... Mainly, in my case, I made a little 'sound obj'. This little sound obj would move straight towards any mob within a certain range. Every time it passed through a turf, it would lose a bit of volume. Passing through walls and stuff would drop volume significantly. If it ran out of volume before it reached the mob, the mob wouldn't hear anything.

Good idea, Spuzz!

I wonder if you could eliminate some of the lag by simply setting the default density (or opacity for that matter) differently for different turf types and using that in the calculation. Also you might save a bit of time by reusing the same sound obj over and over again instead of creating a new one for each check.

Of course, knowing you, you probably tried both of these already... in which case I'll stick to my original 'Good idea, Spuzz!'

In response to Gughunter (#5)
On 6/9/01 4:35 am Gughunter wrote:
I wonder if you could eliminate some of the lag by simply setting the default density (or opacity for that matter) differently for different turf types and using that in the calculation.

Good idea. By treating it as a data object, you do all the calculations on the server and no doubt save a lot of lag.
In response to Deadron (#6)
Good idea. By treating it as a data object, you do all the calculations on the server and no doubt save a lot of lag.

Yeah; actually, I considered that, but never actually got around to testing it out.

I haven't worked on CATs in ages, and thankfully it's still stored away due to the Great Zipping. Haven managed to sneak its way back onto my HDD, but that's the only one. =)

I should rig some sort of test-case. If I get it fudged well-enough, I might release it as some sort of demo...


Oh, and Lexy: the objs didn't have a delay. They'd move from the source to the target in the span of a single tick (i.e. just loop that continually calls Move() until it reaches the destination). Which was why it was laggy.