09 Jul, 2014, jakesmokes wrote in the 1st comment:
Votes: 0
So, the general strategy seems to be: rooms have inventories. So the room points to the object. In my current state, locations have inventories, but objects also have their location stored in their object. So… doubly linked in essence. So that's two references that need to be maintained. So I am thinking about removing the link from objects to their location. Less work, right? But I am concerned about objects which might have an impact on their environments: Light source, bonfire, ceiling fan, whatever. If an object is going to manipulate its location then it will either need to have its reference or find that info some other way. Like, hash any impactful objects to their locations.

What do you all do in this case?

Thanks (yet again),

David
09 Jul, 2014, Idealiad wrote in the 2nd comment:
Votes: 0
I prefer only objects knowing what objects they contain. My reasoning is that to find where an object is, you'll have to call some routine. Whether it's object.location or object.location() doesn't matter much. If performance becomes an issue (which I doubt) you can tune, perhaps keep a cache, whatever. But this way you eliminate maintaining the state in two separate places, which is a win in my book.
09 Jul, 2014, quixadhal wrote in the 3rd comment:
Votes: 0
Rather than making links all over the place, have you considered an event broadcasting system?

The idea being, objects can broadcast events, and they can listen to events they're interested in. So, a room might listen for the event of a light source entering, which it might use to modify its description. Likewise, an NPC might be listening for lighting events, so it can rescan the room for targets which it might not have been able to see at a lower light level.

Having recently been doing some python coding, I've found the old Diku model of having pointers flying everywhere just makes lots of confusion and headaches trying to save world state. It's much simpler to just keep a list (mapping/hash/dictionary/associative-array actually) key'd on unique ID's and let all things track their environment's ID, and the ID's of their inventory.

In the case of a room, it won't have an environment. In the case of an item that isn't a container, it won't have an inventory. But in all other cases, you can easily just grab those ID lists and then directly look them up in your array/mapping/etc. No pointers to maintain or have corrupted. Easy serialization of your data if you want to preserve state. Performance impact is laughable on today's hardware, given the size a MUD will be.
09 Jul, 2014, jakesmokes wrote in the 4th comment:
Votes: 0
I actually have considered that. And I am still weighing the approaches. I've also considered a dependency graph.

So in your scenario, then, you'd suggest having containers contain objects. Objects wouldn't know where they were but when a container moved it would broadcast relevant data about the movement of the items? That is to say, it would be the usual rooms / players have inventories and when there is a need for a notification that happens when the thing containing the object moves or the object changes state?

David
09 Jul, 2014, jakesmokes wrote in the 5th comment:
Votes: 0
Idealiad said:
I prefer only objects knowing what objects they contain. My reasoning is that to find where an object is, you'll have to call some routine. Whether it's object.location or object.location() doesn't matter much. If performance becomes an issue (which I doubt) you can tune, perhaps keep a cache, whatever. But this way you eliminate maintaining the state in two separate places, which is a win in my book.


I agree which is why I am posing the question. Having multiple pointers in the way I described just feels like extra work and opportunity for things getting out of sync. But in the absence of that then you would need to have indexes into where objects (like a light source) and do the right thing when its state (location, etc) changes or implement a dependency or broadcast system as quixadhal (that's hard to type :-)) suggests.

David
09 Jul, 2014, quixadhal wrote in the 6th comment:
Votes: 0
The way I've pictured it, every entity would know the things it contains (inventory) and the thing it is contained by (environment). ALL forms of movement involve the entity changing environments, so whenever that happens, you could broadcast the event. It's also entirely possible to have two events spawned by a movement… a pre-move event which would notify everything in the entity's current environment that the object is about to leave, and a post-move event which would notify everything in the entity's NEW environment that the object has arrived.

You could choose, as an implementation detail, if you want the object to simply notify the old and new environments and let THEM propagate the notification to their own environment and/or inventory, or do have the objects do their own event propagation. I'd probably suggest the former, because it gives you a bit more flexibility and control. Maybe you're in a stone dungeon room and it knows to only propagate an event within the room itself… but a wide open town square might want to also propagate to adjacent rooms.

Also, you have no idea how many times my hard-to-type name saved me in PvP. :)
09 Jul, 2014, jakesmokes wrote in the 7th comment:
Votes: 0
Quote
Also, you have no idea how many times my hard-to-type name saved me in PvP. :)


I bet :-)

The debate in my mind, which addressed some in your post, is whether to push or subscribe to the notifications. I think about light sources moving. If you have, say, a thousand locations subscribing to light source changes and then broadcast those when they move then a thousand decisions will be made whether to handle that. But I am thinking ,which I think you are suggesting also, is to have the objects themselves have behaviors which detect changes in location and then push that notification to nearby locations or entities subscribing to that notification. That seems like the most efficient way. So if I build a fire in the forest then that location and the neighboring ones would get notifications of a light source affecting light values until the fire is extinguished. Would you agree?

Currently, I have inventories (players, NPCs, containers and locations have these) and each object has a set of behaviors which are represented as objects. My thinking is to the owners of the inventories (A player carrying a torch moves) notify their inventories and then they propagate the notification if applicable, ignoring the state change otherwise. There has to be some intelligence to that notification, though, it would seem for cases like a player is walking along the outside of a castle carrying a torch at night. That should illuminate the locations nearby on the side of the wall he is on and not the other.

That seems like the most efficient solution to have the instigators of change broadcast that change in appropriate ways. That may have been what you were suggesting originally. Thoughts?

On the name thing, I recall one mud I played way, way back where a character named himself 1ll1ll1 or something for the same reason. It was hard to keep typing his name unless you aliased it.

I appreciate all the insight.

David
12 Sep, 2014, Nathan wrote in the 8th comment:
Votes: 0
If you make it so that the object has no idea what room it's in (objects know what they have inside but not what they are inside) then how do you tell where stuff is? It might work in a mud, but any games that has something like a 'where' command now has to iterate through all the rooms looking for players rather than iterating through players to see where they are. You could remove the room having a list of objects but then you have to search through all possible objects to see what is in the current room. This common tendency you refer to simplifies a handful of things at the cost of some extra references and a little more care in updating them. If the object holds an ID instead of a pointer/reference then you introduce an additional lookup into the process which might not be so bad but it probably adds up a little if instead of doing object.getLocation() to get the room the object is in you have to do something like getObject( object.getlocation() )

I don't think that the notions presented are generally/universally good ideas. Each might work better in one system or another.



I think that with light sources you have to decide whether it's done on a space/room level or a player level. Does the torch the player is carrying only help that player see or does the torch actually illuminate the environment such that it helps any other players see as well. The player compartmentalized approach is probably easier to code but doesn't match reality completely. It does handle the situation of a room where the illumination in question would generally be too far away (mentally/logically) to actually help the other player anyway without having to introduce a space system and differing levels of illumination.
12 Sep, 2014, plamzi wrote in the 9th comment:
Votes: 0
jakesmokes said:
So, the general strategy seems to be: rooms have inventories. So the room points to the object. In my current state, locations have inventories, but objects also have their location stored in their object. So… doubly linked in essence. So that's two references that need to be maintained. So I am thinking about removing the link from objects to their location. Less work, right? But I am concerned about objects which might have an impact on their environments: Light source, bonfire, ceiling fan, whatever. If an object is going to manipulate its location then it will either need to have its reference or find that info some other way. Like, hash any impactful objects to their locations.


An object's location strikes me as the second most important property after its name. So if I were you, I would be concerned about any object not having a way to reference its location very quickly. It doesn't have to be a pointer/property. It could be a function / method as long as it doesn't involve iterating through some likely huge list (e. g. a lookup hash would be pretty fast).

Lots of things are doubly-linked for a good reason. In this case, it seems pretty clear that your objects are often going to need to know where they are, for any routine that starts from the objects themselves, or starts from a character and passes through an object first. That's a pretty common scenario.

Your thinking here seems influenced by an earlier discussion about how useful it is to keep an index of all items' locations. I recall that I, and several others, thought it would create more bureaucracy than benefit, because how often do you need to retrieve just the locations of all items in the game? The case of an item knowing its own location / container, however, seems very different.
13 Sep, 2014, Scandum wrote in the 10th comment:
Votes: 0
jakesmokes said:
But I am concerned about objects which might have an impact on their environments: Light source, bonfire, ceiling fan, whatever. If an object is going to manipulate its location then it will either need to have its reference or find that info some other way. Like, hash any impactful objects to their locations.

Diku has a light integer that gets increased when a light source enters the room, which gets decreased when a light source leaves. Lola takes this one step further and recognises the strength for a light source and allows light to spill over in other rooms.

This approach requires some faith in your ability to maintain a state machine.
15 Sep, 2014, Oliver wrote in the 11th comment:
Votes: 0
Scandum said:
jakesmokes said:
But I am concerned about objects which might have an impact on their environments: Light source, bonfire, ceiling fan, whatever. If an object is going to manipulate its location then it will either need to have its reference or find that info some other way. Like, hash any impactful objects to their locations.

Diku has a light integer that gets increased when a light source enters the room, which gets decreased when a light source leaves. Lola takes this one step further and recognises the strength for a light source and allows light to spill over in other rooms.

This approach requires some faith in your ability to maintain a state machine.


Maintain a state machine? Not to call into question your methodology, but you can achieve the same result simply by having the routine that displays information to the player always check lightConditions(). When you display the room, or check if a player can see, you can just call some lightConditions() function that tallies up how much light is in that room (possibly including surrounding rooms if that's your thing). No state machine required…

(This is how my game handles light, and this works to accommodate both the existence and strength of light sources working in concert.)
17 Sep, 2014, Nathan wrote in the 12th comment:
Votes: 0
Perhaps I misunderstand, but I think the point about a state machine is the notion of appropriately handling transition/changes in the light level. Arguably a game is a state machine of sorts. See -> http://whatis.techtarget.com/definition/.... Lighting is probably a sort of pseudo state machine persay because if you bring a light source in you change the amount of light in the room and if you take the light source out it decreases. The room has a certain amount of lighting regardless of whether you check how much there is. Sure you could tally that up every time, but it's more efficient, in some ways at least, to do it when the light level changes so you only have to check the current light level as a value. If you have such a routine, there is some overhead for each call to it. I can't claim to know when or if it would actually present any sort of noticeable issue, but it would probably take more cpu time technically.
18 Sep, 2014, quixadhal wrote in the 13th comment:
Votes: 0
A state machine has nothing to do with arbitrary values of object properties. A state machine is defined by having a set of states which drive the logic of the program. The program behaves differently, based on the current state.

The TELNET protocol is most often implemented as a state machine, where the states tend to include a "receiving data" state, a "partial token" state, a "subnegotiaton" state, and others.

When you start up, you're in the "receiving data" state (usually) and stay there on any input except the TELNET IAC character, at which point you enter the "partial token" state until you either get the rest of a valid token and return to receiving data, or you get the subnegotiation start symbol and then go into a different state to accept all the subnegotiation data until the end symbol sequence.

The light level of a room would only be a state machine if the game acted differently based on that level. And by differently, I mean the game logic, not just showing a slightly different description.

I would think it might qualify if, for example, you had grues. In the classic game Zork, if you didn't have a light source, attempting to move (or do MOST commands, for that matter) would result in you being eaten by a grue. The same actions would not, if you had a light source. So, in a minimal way, you had a state machine of HAS_LIGHT and NO_LIGHT. :)
0.0/13