21 Aug, 2014, wifidi wrote in the 1st comment:
Votes: 0
Blurred (intentionally missing) text is a cool spell or game effect. Consider these combinations and how meaningful they could be:
"Blur <who_or_what>:

mobiles, rooms and things
mobiles
rooms
things
players
NPC's
a kind of player
a group of players
a player
a kind of area
an area
a kind of room
a room
a kind of thing
a thing
a mobile's things


to <whom>:"

players
a kind of player
an area's players
a room's players
players below a certain level
a player group
players possessing/holding/wielding a kind of thing
a player
a player possessing/holding/wielding a kind of thing
a player possessing/holding/wielding a thing


What is the best way to code the combinations/effects players want without coding all possible combinations?
21 Aug, 2014, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
You probably already (if not you should) have a method that do return a unique ID for any possible argument (player, object, or room).
Store the ID to blur on the targeted player.
Then in any method that write a desc to this character (there are only a few:player , room and object, gag the ID when it is asked to be shown.

Simple.
22 Aug, 2014, wifidi wrote in the 3rd comment:
Votes: 0
So a "send to char" function/method would blur whatever is listed as something to blur with the receiving player. Adding "blur ID's" as an integer array with each player would work especially well to blur players to each other because the array would normally contain less than a dozen ID's at a time (number of players on). However entering every room or object ID into such an array might get cumbersome.

Traditional players would want to be able to blur:
eq/inventory when players look at them
the contents of a bag
a room's/area's/world's description(s)

I bet a text MUD could use this as the kind of theme Tyche suggests is a needed strategy for text MUDs, e.g.: a major Wizard lives somewhere trying to evilly blur the world ("just to blur the world"). A benign Cleric, Wizard and Druid also inhabit the world, the Cleric insisting on blurring beings because they become like idols; the Wizard bent on blurring things because things wreak so much havoc in the world; the Druid blurring nature (room descriptions) to prove that "all is one". A name for this MUD could be MurkMUD. A name for the development MUD could be MurkyMUD. Murk++ is an appropriate codebase because its the right vintage for a story like that. Of course admin's can apply the idea to some other codebase.

An advanced application of blurring would be:
a shrine (its players, mobiles, rooms & objects) is blurred to players whenever a player is wielding a weapon

I can't program at the speed of thought, so wish me luck and I certainly will hesitate to "open the doors" to players without knowing I've got the goods. I think the smartest move would be using a codebase that officially includes the features. People who program for a living often know the sophisticated, efficient ways of achieving the desired result instead of having to use a stream-of-thought approach known to unnecessarily tax the CPU. For example, is it right to check every message ever sent to a player for something that may not exist in the game often enough? After all, the obvious objection to "murked" or "blurred" content is that once its gone, then the game is simply back to being what a normal game is.
22 Aug, 2014, Rarva.Riendf wrote in the 4th comment:
Votes: 0
>However entering every room or object ID into such an array might get cumbersome.

hmm No ? in C you would use a linked list to not be limited in size and not allocate too much memory for no need, but in any other langage worth its salt, you have arrays that are dynamically sized depending on their content, so who cares.
23 Aug, 2014, Scandum wrote in the 5th comment:
Votes: 0
wifidi said:
What is the best way to code the combinations/effects players want without coding all possible combinations?

If you want to do it right you'd create a dynamic description engine.
23 Aug, 2014, Rarva.Riendf wrote in the 6th comment:
Votes: 0
Scandum said:
wifidi said:
What is the best way to code the combinations/effects players want without coding all possible combinations?

If you want to do it right you'd create a dynamic description engine.


Without even going this far, even the basic rom is pretty dynamic.
Rom description are only displayed if you have a light, Object if they are not invis etc.
Blurring thing is no different than checking for a light on the player, or if he has detect invis.
24 Aug, 2014, wifidi wrote in the 7th comment:
Votes: 0
I think you're right about focusing on the player because they're usually a smaller list to deal with and are the ultimate recipients of messages. A player variable storing exactly what is blurred to that player could be added and programmed to update during movement into/out of a blurred room/area, affect expiration, spell affect, etc.

In Murk++, it also requires modifying or creating: functions that show text to players or statements that contain those function calls. An example approach is finding "send_to_char", "show_char_to_char" and similar function calls throughout the files, identifying what they show players when unaltered, then using a conditional statement such as:

(<pseudocode>is this kind of message blurred to the recipient) ? blur_to_char(msg) : send_to_char(msg);

Then writing a blur_to_char function that replaces random text with a space or otherwise obscures the normal text.

In some programs the trend is having "all the code needed" in one place, e.g. a "codebox" in the final message function, though until I'm smart enough to code it, I'd more likely create a bottleneck at that point in the program.
07 Sep, 2014, Nathan wrote in the 8th comment:
Votes: 0
Rarva.Riendf said:
Scandum said:
wifidi said:
What is the best way to code the combinations/effects players want without coding all possible combinations?

If you want to do it right you'd create a dynamic description engine.


Without even going this far, even the basic rom is pretty dynamic.
Rom description are only displayed if you have a light, Object if they are not invis etc.
Blurring thing is no different than checking for a light on the player, or if he has detect invis.


That's not really a dynamic description, persay. It's more of a static description with dynamic elements or a handful of checks for when to show/not show it. The basic
description doesn't change in any way and it's certainly not player dependent.

Leaving stuff out seems like it could be useful if you wanted some kind of weather/pseudo-weather system where. Especially when your descriptions normally include stuff that's visible in the distance. That information can then go away when your vision is obscured by rain or snow or some such. Of course that probably works best as a supplement to a design where that data normally gives the player knowledge of how far away from the destination they are. I.e. it's far enough that they don't automatically remember, but the room description would normally cue them in to relative distance. You might even hide the "road sign" in a thick fog so they know they can go n/s/e/w/etc but they can't see any information about where that direction leads.
0.0/8