19 Aug, 2013, Scandum wrote in the 21st comment:
Votes: 0
KaVir said:
Scandum said:
If I destroy a room that contains another room, both rooms would get destroyed if the system recognizes that room as a child.

Unless you choose to move it out before destroying the parent, which can often make sense.

That's a common problem. In the Diku system there is no such concept as a parent, so that's a clear conceptual difference as there is no method to adopt hypothetical children.
03 Sep, 2013, Nathan wrote in the 22nd comment:
Votes: 0
KaVir said:
quixadhal said:
You guys are trying to make distinctions in things that are all just directed graphs.

You can call them "rooms", "planes", or "states"… they're still just nodes on a graph which has edges controlling which nodes you can freely travel between.

Really? You consider the "Connected state" in Diku to be a room-based system? CON_READ_MOTD -> CON_PLAYING = room-based movement?

Scandum said:
If I destroy a room that contains another room, both rooms would get destroyed if the system recognizes that room as a child.

Unless you choose to move it out before destroying the parent, which can often make sense. I had a few bugs with players 'vanishing' after being eaten by a creature that then died, or being inside a building while it burnt down.


Really, players that are "eaten" ought to be considered dead, or given the chance to escape the dead body of the thing if they aren't. A game where rooms/buildings can burn down really ought to warn the player of their imminent demise somehow..

Ex.
The fires burn fiercely around you, any moment now the walls could collapse onto you… which would be fatal.

Of course, the players do have to be modestly literate unless you want the game to tell you. "MOVE! YOU ARE ABOUT TO DIE!"
03 Sep, 2013, plamzi wrote in the 23rd comment:
Votes: 0
Scandum said:
KaVir said:
Scandum said:
If I destroy a room that contains another room, both rooms would get destroyed if the system recognizes that room as a child.

Unless you choose to move it out before destroying the parent, which can often make sense.

That's a common problem. In the Diku system there is no such concept as a parent, so that's a clear conceptual difference as there is no method to adopt hypothetical children.


To me, this kind of debate is a product of a pretty simple phenomenon I call "over-classing", a geek variation of the more general "over-thinking".

Just because we have object-oriented programming doesn't mean that every entity in your game has to have an object/class parent. Sometimes, an array of objects works just fine.

Even within the nested objects paradigm, making peers actual parents of each other seems to create problems where there weren't any to begin with. If you need that kind of relationship, what's wrong with just using pointers? That way, you can actually have multiple relationships, not just "one is inside the other".

And, again the Diku folks already had that. They made some poor design decisions, sure, and some of their approaches now feel dated, but overall I always feel the job they did was pretty damned good.

On the topic, I'd like to suggest that 99% of games with coordinate-based worlds are in fact hybrids. Consider walking inside a house in "Oblivion" or any stepping through "magical portals" that take you to an area with no clear spacial relationship to the area you came from. The only reason I'm saying 99% is to account for the possibility of a game I don't know about where everything has a strict spacial relationship to everything else.
03 Sep, 2013, Nathan wrote in the 24th comment:
Votes: 0
The problem described seems to be an issue of a desire to represent a meta-location, ex. "under the bed". The example presents a solution which is having another room and the logic suggests that it be destroyed along with the house if the house is destroyed. If your house burns down, the space under the bed is also exposed to the fire…. If you don't have means of describing that relationship then logical inconsistencies/fallacies crop up, like being "under the bed" resulting in there being no negative consequences to you despite being in the center of the fire.

@plamzi
I'm not sure that's relevant to this… One way to have something inside something else is for the "parent" to contain a reference/pointer to the "child" object. I suppose you could put one "inside" the other if your rooms have some container capability that can hold other rooms. Not sure what would necessary be invalid about that approach, since it would avoid have additional class fields/variables to represent those relationships.

Magical portals have a pretty clear relationship in my mind, they link two specific spaces together, those spaces just aren't required to be geographically adjacent, though. Really in a video game, the "inside" size of buildings should roughly correspond to the "outside" size unless it's absolutely impossible. Nevermind that if you make that true, then it's likely much easier to implement spells/mechanisms to actually put a hole in walls. Probably a game with any kind of physics at all needs that kind of thing.
03 Sep, 2013, quixadhal wrote in the 25th comment:
Votes: 0
KaVir said:
Really? You consider the "Connected state" in Diku to be a room-based system? CON_READ_MOTD -> CON_PLAYING = room-based movement?


You could certainly implement it that way, if you wanted to.

CON_READ_MOTD is just a state saying the player has been shown the MOTD file and the next input is to "unpause" them and start playing.

If you wanted to be silly, you could get rid of those states and make the player actually move through rooms which have specific command sets which pertain to their actions. It would be silly, but there's nothing magical about the directed graph of connection states that really makes it different from the directed graph of a set of rooms.

Smartass.
03 Sep, 2013, plamzi wrote in the 26th comment:
Votes: 0
Nathan said:
The problem described seems to be an issue of a desire to represent a meta-location, ex. "under the bed". The example presents a solution which is having another room and the logic suggests that it be destroyed along with the house if the house is destroyed. If your house burns down, the space under the bed is also exposed to the fire…. If you don't have means of describing that relationship then logical inconsistencies/fallacies crop up, like being "under the bed" resulting in there being no negative consequences to you despite being in the center of the fire.


You could have two categories of pointers, one that gets destroyed if the object is destroyed, and one that doesn't. So, your "under the bed" is destroyed, but "behind the stone wall" isn't.

Clearly, the "solution" to this problem is to not try to reduce everything to a parent-child relationship.

Nathan said:
I'm not sure that's relevant to this… One way to have something inside something else is for the "parent" to contain a reference/pointer to the "child" object. I suppose you could put one "inside" the other if your rooms have some container capability that can hold other rooms. Not sure what would necessary be invalid about that approach, since it would avoid have additional class fields/variables to represent those relationships.


Since you're clearly talking about pointers and not inheritance, I'm not sure what it is about my suggestion that's different from yours, or what makes mine irrelevant :) I'm also not sure what you mean by "avoid have additional class fields/variables to represent those relationships".

Nathan said:
Magical portals have a pretty clear relationship in my mind, they link two specific spaces together, those spaces just aren't required to be geographically adjacent, though.


In my mind, rooms in the game I've played for many years have a pretty clear relationship. That doesn't make them coordinate-based.

Nathan said:
Really in a video game, the "inside" size of buildings should roughly correspond to the "outside" size unless it's absolutely impossible.


The only thing that a video game *should* be is fun. Anything else *should be* a means to that end. If you are having fun spending an hour walking around the city walls to get to the entrance (because all these places inside the city take up realistic space even though they are not accessible to you at the moment), then have at it.

To me, that's a very bad form of realism. I prefer the total cheating that's going on in even in games like Oblivion that try to create *a sense* of realistic space dimensions without actually providing them.
03 Sep, 2013, Nathan wrote in the 27th comment:
Votes: 0
Eh. I suppose that would work. Nevertheless for say rooms in a building, a parent->child relationship makes the most sense to me. I didn't say that was the solution, but I do feel some solutions are more rational in some contexts.

I don't know if it's ultimately different, I just felt the need to spell it out, in part because what you were saying sounded confusing. If you think they're essentially similar, great. At least that would mean I am not as confused as I felt.

I think it's safe to say we disagree on the degree of realism that is desirable. I personally rather appreciate the scale of Skyrim in terms of making the world feel huge and real even if it occasionally bothers me trying to get somewhere I haven't been before. It definitely works a lot better in a video game than on a mud or something. To put it simply, I consider some things fun and that includes a certain aspect of realism.

A little tiny house outside being huge inside bothers me. I generally don't mind the lack of, say, a realistic number of npc houses that I would never go in anyway if it makes navigation easier. On the other hand, if there is a castle or fortress and it's less than 50-100 feet long outside, that would probably bother me. Big things should feel big, and better still be big. I don't mind walking, provided that it seems reasonable. Frankly, this means that I love roads, because roads take you from point A to point B and tend to lead right up to the entrance I want. To be fair, having a bunch of things for "realism's" sake that I can't get into would ruin my fun. If they can't/won't put the effort in to make it explorable, then I suppose I can tolerate some corner cutting in the realism department.
03 Sep, 2013, Tyche wrote in the 28th comment:
Votes: 0
plamzi said:
Scandum said:
KaVir said:
Scandum said:
If I destroy a room that contains another room, both rooms would get destroyed if the system recognizes that room as a child.

Unless you choose to move it out before destroying the parent, which can often make sense.

That's a common problem. In the Diku system there is no such concept as a parent, so that's a clear conceptual difference as there is no method to adopt hypothetical children.


To me, this kind of debate is a product of a pretty simple phenomenon I call "over-classing", a geek variation of the more general "over-thinking".

Just because we have object-oriented programming doesn't mean that every entity in your game has to have an object/class parent. Sometimes, an array of objects works just fine.

Even within the nested objects paradigm, making peers actual parents of each other seems to create problems where there weren't any to begin with. If you need that kind of relationship, what's wrong with just using pointers? That way, you can actually have multiple relationships, not just "one is inside the other".


Under the covers all class/object based programming language constructs are also directed graphs of pointers[1].
The mud world sits on the back of a pointer. That pointer sits on the back of another pointer.
It's pointers all the way down.

[1] that is a location in memory that stores another location in memory.
24 Oct, 2013, Idealiad wrote in the 29th comment:
Votes: 0
Arise ye thread.

So in a forum game at another site there was an interesting little part where the DM wrote:

Quote
TWISDEX, ZAXWEN, and AHATHA arrive at the site of a cold and disused camp in the foothills. Following an obvious trail winding through the CLIFFS OF CORINE, your party arrives at a narrow crevasse in the tall steppes. Pegged to the cliff walls are freshly-scalped humanoid heads, and a low wall of ugly stone blocks sits a few feet from the cavern mouth.

ZAXWEN spies movement out of the corner of his keen elven eye, and whirls to face two dark-skinned DUERGAR dwarves, peeling themselves away from the walls of the cliff-side pass behind them as some sort of supernatural camouflage fades from their bodies. The DUERGAR wear hardened flowstone armor, and wield stone handaxes. At the same time, a second pair of DUERGAR hustle out of the cavern entrance, brandishing crossbows. These take cover behind the low stone wall.

This area consists of two ZONES: the NARROW PASS and the CLIFFSIDE CAVERN SHELF.
This CLIFFSIDE CAVERN SHELF contains two FEATURES: the CAVERN MOUTH and the STONE WALL.

TWISDEX is caught by SURPRISE! He cannot yet act.
AHATHA is caught by SURPRISE! She cannot yet act.

Your PARTY awaits instruction!


It's not revolutionary or anything but at least I have never seen a mud that divided its space like Area -> Zone -> Feature. In this example that looks like,

Area: Cliffs of Corine
Zone: Narrow Pass
Zone: Cliffside Cavern Shelf
feature: cavern mouth
feature: stone wall


With free movement amongst those zones and features. Would be interesting to make a little prototype mud with that.
24 Oct, 2013, quixadhal wrote in the 30th comment:
Votes: 0
Seems a nice alternative to the cardinal directions most games use.

I assume the party is current in the Cliffside Cavern Shelf, and thus can see the features present? It sounds like you could move to the "Narrow Pass" zone via the stone wall feature (exit), and to an as-yet-undiscovered zone via the cavern mouth feature (exit)?

One also assumes the dark dwarves are currently occupying those features and will have to be dispatched before they can be used. :)
25 Oct, 2013, Idealiad wrote in the 31st comment:
Votes: 0
Sort of, I don't think the features are exits per se, but more like tactical features in the combat situation. So the 'room' is like the whole Cliffs, with two zones. I'm guessing to engage across zones you need a ranged weapon.
25 Oct, 2013, quixadhal wrote in the 32nd comment:
Votes: 0
Or, you need to move to the "feature" in question, to engage in melee combat, hence making them "exits". :)

If it really required you to use ranged weapons ONLY, I'd say the game is horribly broken, as nothing in the description made it sound like those features were inaccessible. A sniper on a rooftop might well be protected from non-ranged people, but dwarves running out of a cave entrance, or next to a wall should be accessible by anyone who's mobile, given the time to cover the distance.
26 Oct, 2013, Idealiad wrote in the 33rd comment:
Votes: 0
OK, I'll say the obvious – they're not exits because you're not 'exiting' anywhere. It would be like calling a table 'feature' in the middle of a room an exit when you jump on it in the middle of melee.
26 Oct, 2013, quixadhal wrote in the 34th comment:
Votes: 0
+1 Troll Powers!

I think most of us are smart enough to know that an "exit", in terms of any of these kind of games, is simply a node on a graph, to which you can travel.

If those "features" aren't sub-areaa to which you can travel, or which can be used as "exits" themselves by trying to go there, what's the point of making them ALL CAPS TO GET YOUR ATTENTION?

Clearly, you are meant to interact with them in some way. What are you supposed to do… throw candy wrappers at them? Exclaim "Oh, what a lovely STONE WALL, you have there!"
20.0/34