14 Nov, 2010, quixadhal wrote in the 81st comment:
Votes: 0
I think the key thing to consider here is what is contained within the instance. If Grog appears outside the instance as the evil Orc King who is terrorizing the village, and then players enter an instance to stop him (by whatever means), then yes. You get an inconsistent view between players who have stopped his reign of terror, and those who haven't done so yet. Either he resets, and even though you stopped him, he's back to his old ways; or your personal view of the world now has him defeated but Joe still sees the terror.

To be consistent, Grog AND the village in question shouldn't appear AT ALL outside the instance. So, rather than spawning an instance for a single quest event, you spawn an instance for the entire village and ALL the quests it might contain. Each player or group will be able to do their own quests, and their personal progress gets saved so whenever they visit the village they see things at the point of the story they are at.

Now, you might still have an inconsistent view if the village has a fixed name and/or location in the world, but there's no reason that has to be the case. You might move the village's location around for each player, so everyone gets to save a village from an evil orc king, but maybe not the same one, and maybe not in the same place.

Games like WoW accept the inconsistency of players being at different points of the same storyline. There is only one Lair of Onyxia, and some people have killed her, and others haven't. There's no perma-death in WoW (either for NPC's or players), so this is fine. If your game has permanent changes, then you might want to go the extra step to ensure everyone gets slightly different content.
14 Nov, 2010, David Haley wrote in the 82nd comment:
Votes: 0
Ludwig said:
That interaction limitation is just an implementation decision and not a fundamental problem with instances. If a MUD owner wants to let any player mess with any instance, then that MUD owner can do so. It's not instancing that creating this "inconsistency."

As Chris said, it's rather unclear to me what exactly you mean by instancing if everybody can affect everybody else's instances when the whole point was to give people their own experiences so that they could do some quest without other people having done it before them.

Ludwig said:
I'm going to ignore this physical space problem because it exists in all types of MUD areas, not just instancing.

You better not ignore it! It's a fundamental consequence of your solution to physical inconsistency introduced by your examples. You introduced it because you want to give players each their own separate physical location; so you have to deal with the consequences!

It most certainly does not exist in all types of MUD areas, because when I create a world I don't have to account for potentially unlimited numbers of places added in the middle of the world as new players crop up. It is a problem very specific to your proposed solution, so you can't just run away from it. :smile:

Ludwig said:
Well that's a problem with my examples, not with instancing.

As Chris said, you can't really say that your argument is perfect if not for your examples. If you're going to show how this is workable without inconsistencies or spatial problems, you need to actually show how we can get this working. It is not enough to simply that that there might exist some solution; we need to actually see it.

Let's put it this way: I'm saying that instancing introduces fundamental problems (but that we don't necessarily care about those). You're saying that that is not true, and you are giving examples that turn out to be flawed (which you admit to e.g. above). Well, from an argumentation perspective, if you are going to provide positive proof of a system that works without problems, inconsistencies etc., you need to, well, provide that example. You say that you disagree with me "logically" and are "prepared to show why", so please do so. If you say it's enough to say you're right because you say you are, then I might as well say that I'm right because I say I am. :smile:

Ludwig said:
Instancing does not fundamentally create an inconsistent game world. Instancing is fundamentally simple and the issues you brought up are due to the way you use instancing.

What exactly does instancing mean to you? Let's take your definition of making unique copies. As a side note, I agree with Chris that it's not quite fair to redefine everything in your favor, but it turns out that even this definition favorable to you doesn't solve your problem. Your definition has all of the inconsistencies or physical problems that we've talked about several times now, such as:
1- unique copies collide in terms of physical consistency
and/or
2- eventually you run out of space to put these unique copies

So if you want to use your definition, how exactly do you address these problems? All I ask for is that you provide some example that doesn't have the problems we have identified (and, well, any future problems we might identify with further examples).
14 Nov, 2010, Ludwig wrote in the 83rd comment:
Votes: 0
Let's define some terms and concepts before we drown in discussion.

"Instance" (many instances, one instance, to instance, act of instancing) needs a definition.
We need to know the difference between "different" and "inconsistent."
We need to come up with a term for "instancing as a mechanic" or "the common implementation of instancing" because the word instancing alone is confusing.

To KaVir: I don't think procedurally generated areas are the same as instanced areas. I guess an area can be both instanced and procedurally generated, but something tells me it's not the same. I could be wrong though.
14 Nov, 2010, KaVir wrote in the 84th comment:
Votes: 0
Ludwig said:
Let's define some terms and concepts before we drown in discussion.

I did already provide a link to wikipedia's definition of "…a special area, typically a dungeon, that generates a new copy of the location for each group, or for certain amount of players, that enters the area".

Ludwig said:
To KaVir: I don't think procedurally generated areas are the same as instanced areas. I guess an area can be both instanced and procedurally generated, but something tells me it's not the same. I could be wrong though.

I didn't say they're the same, I said you could also randomly or procedurally generate the area, in addition to instancing it. Otherwise you could still have your dungeon that's accessable from any point in the world, but each instance would look exactly the same as all the others, and IMO that would be pretty pointless.
14 Nov, 2010, Ludwig wrote in the 85th comment:
Votes: 0
David Haley said:
As a side note, I agree with Chris that it's not quite fair to redefine everything in your favor.


By all means, please give me your definition of an "instance" if you disagree with my definition.
14 Nov, 2010, Ssolvarain wrote in the 86th comment:
Votes: 0
KaVir said:
"…a special area, typically a dungeon, that generates a new copy of the location for each group, or for certain amount of players, that enters the area"


That's exactly right.

And instancing static dungeons has always been common for MMOs. It's just not as obvious as WoW's form of instancing. At a certain population peak, a new dungeon instance is set as default and fills, allowing the older one to eventually close.
15 Nov, 2010, lockewarrior wrote in the 87th comment:
Votes: 0
Why code when you could be arguing on Mudbytes instead??

Wwwwwooooooo!!

So, I'm pretty sure this -entire- thread has assumed we're talking about 'instancing' in the sense of instanced dungeons like one would find in World of Warcraft. (By 'pretty sure', I mean absolutely, unquestionably without a gosh-darn shadow of a doubt certain.) Five pages into this, and all the sudden you start mixing the discussion with some: "Instancing is a copy of any prototype.." crap that's entirely not relevant to the discussion.

That's lame.
15 Nov, 2010, KaVir wrote in the 88th comment:
Votes: 0
lockewarrior said:
Why code when you could be arguing on Mudbytes instead??

When I want to code, I code. When I want a break, I do something else - and online discussions can be much more useful for my mud than reading a book or watching TV. Many of my most successful features were inspired by posts on usenet, forums and mailing lists, and at least two of them were the direct result of recent threads on MudBytes.

lockewarrior said:
Wwwwwooooooo!!

So, I'm pretty sure this -entire- thread has assumed we're talking about 'instancing' in the sense of instanced dungeons like one would find in World of Warcraft. (By 'pretty sure', I mean absolutely, unquestionably without a gosh-darn shadow of a doubt certain.) Five pages into this, and all the sudden you start mixing the discussion with some: "Instancing is a copy of any prototype.." crap that's entirely not relevant to the discussion.

That's lame.


Actually it was you who first used "instancing" in that way. As to whether or not your usage back then was "crap that's entirely not relevant to the discussion", at the time you prefixed it with the words "on topic":

lockewarrior said:
On topic: I'm working on a MUD driver/mudlib type codebase written purely in Lua, and am playing around with a setup of almost pure instancing. The driver defines generic prototypes for things like mobs, organizations, items, rooms, etc. (even players). The mudlib then simply defines game logic by initialising instances of these prototypes and setting their attributes.
17 Nov, 2010, David Haley wrote in the 89th comment:
Votes: 0
Ludwig said:
Let's define some terms and concepts before we drown in discussion.

Just a minute, now. I'm pretty sure that the thread was proceeding just fine according to a well-understood, common definition until you showed up to engage in sophistry (which is how you described your own activity – you were only interested in showing that some position was incorrect and didn't care about the discussion at hand).

So before we worry about "drown[ing] in discussion", I think the only person having trouble with definitions and understanding differences between "different" and "inconsistent" is you, because – IMHO – you need to introduce these artificial questions in order to try to shore up a position that just hasn't been working out in your favor. Everybody else seems to be pretty clear on what is being discussed.

Even when people agree with your definitions for the sake of argument, they find further problems that you don't address…

Just to play along with this little game, the definition of "different" is (hopefully obviously) "not the same" and the definition of inconsistent is when something does not obey rules that one would normally follow.

For example, according to the rules of geography etc., taking the same steps from the same starting location should result in arriving at the same place. Breaking this rule is a form of inconsistency.

Anyhow to be very frank I'm not sure what all you're exactly interested in here, because you said yourself that you don't actually care about the subject at hand, and when your assertions are challenged you have little to follow up with. :sad: What exactly are we trying to achieve with this discussion? I have no objection to discussion in general, but this one is feeling a little fruitless.
17 Nov, 2010, Ssolvarain wrote in the 90th comment:
Votes: 0
David Haley said:
For example, according to the rules of geography etc., taking the same steps from the same starting location should result in arriving at the same place. Breaking this rule is a form of inconsistency.




Also inconsistent, but I can make it in a mud anyway.
17 Nov, 2010, David Haley wrote in the 91st comment:
Votes: 0
The point is not that we cannot make inconsistent things – of course we can – the point was that we initially stated that we wanted to avoid inconsistency, and that instancing fundamentally breaks consistency by bending the rules of space and sometimes even time.
18 Nov, 2010, ATT_Turan wrote in the 92nd comment:
Votes: 0
And when we mess with the space-time continuum, everyone except Commander Data starts predicting what the poker cards are going to be :smirk:
22 Nov, 2010, Ludwig wrote in the 93rd comment:
Votes: 0
I did care about the discussion at one point, in my original post. But then you, David Haley, felt the need to quote my post to argue and then proceed to make some incorrect claims. Maybe other people on this site don't mind being constantly corrected by David Haley, and just bear it, but I am willing to defend myself as a matter of principle.

And I do think it's necessary to define terms and concepts before ANY discussion, otherwise we will forever be arguing in murky waters. I'm the one trying to get at the truth (even if it disproves against my claims) through logic, to dive down to the heart of the matter.

Different or Inconsistent?

I agree with your definition of different as "not the same."
Your definition of inconsistent is also good. To add some definitions from online dictionaries, inconsistent can also be defined as "having self-contradictory elements. Or, acting at variance with one's own principles or former conduct."

Let's imagine a pattern of letters ( A B A B A B ) to illustrate the words "different" and "inconsistent." If the next letter in the pattern were A ( A B A B A B A), then this would be different from the previous letter, but it would be consistent (with the pattern). If the next letter were B ( A B A B A B B ), then this would not be different at all from the previous letter, but it would be inconsistent. Of course, if you add in the letter C anywhere, it would be both different and inconsistent.

Instancing vs To Make Instances

Fine, let's go with your definition of instancing (dungeon instancing definition from Wikipedia). From now on, "instancing" by itself will refer to the common implementation which is "a special area, typically a dungeon, that generates a new copy of the location for each group, or for certain amount of players, that enters the area."

We'll also need a term for the act of making instances from a prototype. We can't call this "instancing" anymore. We need a new term. btw, in all my posts I've been using instancing to refer to this concept.
22 Nov, 2010, Idealiad wrote in the 94th comment:
Votes: 0
It's called cloning.
22 Nov, 2010, lockewarrior wrote in the 95th comment:
Votes: 0
The word 'clean' means something different if you're talking about a gun, a hospital room, or a drug-addict. A clean gun is not registered. A clean hospital room is not dirty. A clean drug-addict is not high. Nobody needs anyone to look up the word 'clean' in the dictionary or requires it to be defined at the beginning of the conversation. The meaning of the word 'clean' is defined by context.

Likewise, if I'm discussing programming or coding in an object-oriented paradigm, then the context of that discussion pretty clearly dictates what a prototype is and what an instance is. In fact, one might instantiate (create an object) of a specific class.

If I'm discussing the new raids available in World of Warcraft's latest patch with my 14 year old cousin, and he says, "I din't make group b4 they hit the instance." the context of our discussion clearly indicates the meaning of 'instance' here.

Is this really what this thread is about? If you're discussing a mud where you use a prototype/instance paradigm, and also have 'instances' (i.e. like found in WoW), then just be clear about which one you mean.
23 Nov, 2010, David Haley wrote in the 96th comment:
Votes: 0
Allow me to roll my eyes at somebody taking some kind of silly high horse position about an argument when engaging in that very argument on matter of principle is what they have explicitly given as his current goal, for no other purpose than proving a sophist point. If you want to have the discussion, have it. If you don't, go away. But don't adopt this ridiculous half-way position of being morally superior while at the same time engaging in the conversation. So you're unhappy that you made a post and somebody disagreed with it? Well, look at your first post in the thread – you came out telling people that they "must be crazy" to believe something! And now you're getting upset about somebody engaging you on that point? Ludwig, drop the personal attacks and stick to the discussion.

In the meantime, I asked you several questions that you've ignored and instead you're bringing us down this rabbit hole of definition discussion. Trust me, I agree that having clear definitions is useful, but in this case you're taking it much further than we need to. Besides, you seem to be the person most unclear on what people are talking about.

You gave several examples that turned out to be flawed. You said that while your examples may be flawed, the position is in fact correct. We've all been waiting for you to show us better examples.
23 Nov, 2010, Ludwig wrote in the 97th comment:
Votes: 0
No matter how much you attack me, I won't roll over, David Haley.

Let me steer us back to the discussion at hand.

In my first post I defined my usage of "instancing" and claimed it would make more sense to use it a certain way:
Quote
If you're going to instance areas, just make each instance unique. After all, that's what instancing is for, right? To make unique copies of something. Instead of instancing The Orc Stronghold of Orchaven, it would make more sense to lead each player to a unique Orc stronghold with a unique name, like An Orc Stronghold named Gristbak and An Orc Stronhold named Lorketch.


Then you took my example and imagined it a certain way in your head. You imagined each instance being in the same place and conflicting with each other. Those conflicting instances happened because of the way you implemented my example in your head. You built up an scenario in your head and then poked holes in it as if it were mine. Note that I never said where each instance would be.
Quote
it makes a lot of sense in the game world for the orc stronghold to the east of the main town to keep changing names, even if people go there at the same time! You said that instancing doesn't make sense because people can't talk about it sensibly. But your solution doesn't let people talk about these areas sensibly either, because different places supposedly occupy the same physical space


Notice that you put words in my mouth there. I never said anything close to "instancing [in general] doesn't make sense because people can't talk about it sensibly." I said instancing A NAMED AREA doesn't make sense. There are many other ways to use instancing (like in my first example each instance had a unique name), and those make "MORE SENSE."

So I took my original example and implemented in a way that would make sense.
Quote
I would lead each player to an Orc "country" or "zone" and have them each find their own Orc Stronghold within that larger Orc zone.


Then you said it still doesn't make sense because other players can't see a certain player's instance.
Quote
Your world will have things that exist to some players and simply do not exist to others, and no matter how you spin it, that doesn't make physical sense

Note that I never said that's how my example's world would work. I didn't specify the rules of interaction at all, an oversight on my part. You decided to imagine my example in the common way that instancing is used. But it doesn't have to be used that way. I then offered a different, more consistent way to use my example.

Quote
Each instance of the Orc Stronghold will still be uniquely named. Every player can enter the instance of another player and view the content, but a player's interaction with the content will be limited if they did not "create" the instance.


Then you said it still doesn't make sense in the game world because of the limited interaction.
Quote
for example, interaction inconsistency. Why are these orcs only responding to one specific player? Why can't Bob kill them too? He can see them, and he can kill the orcs over there, so why not here?


I said this was an arbitrary design decision and wasn't a problem with instancing.
Additionally, you said that your belief that instancing has a fundamental problem lied in my examples!
Quote
The reason why I believe instancing has this as a fundamental problem is that in all examples given so far, the world behaves differently depending on who is acting upon or observing that world.

If your belief lies in my examples, then I repeat that it is a problem with my examples, which seem to be the basis for your general claims about instancing.

I'll take a day to come up with an implementation of "instancing" (as I used it in my first post) that makes sense in-game.
23 Nov, 2010, quixadhal wrote in the 98th comment:
Votes: 0
So, I have just one question for you guys. It's important! Which of you are the Hatfields, and which are the McCoys?
23 Nov, 2010, David Haley wrote in the 99th comment:
Votes: 0
Ludwig said:
If your belief lies in my examples, then I repeat that it is a problem with my examples

OK. It's a problem with your examples. We knew that already. Why are we even talking, then? Come back with better examples if you can get any – that's all that matters. :sad:

It's as if you expect me to read your mind, when all I have to work with are the words you post here. You then get remarkably huffy and puffy when your mind is not read correctly, despite all these problematic examples you keep giving (by your own admission no less).

Please just get to the point already, and stop your silly moral posturing. Two can play that game, except that that would merely be twice as ridiculous. If you have better examples, give them. If you don't, then let's just move on already. In its current form, this thread is a waste of everybody's time.
24 Nov, 2010, Ludwig wrote in the 100th comment:
Votes: 0
The following is an example that uses instancing in a way that makes sense in-game without creating inconsistencies.

To the east of the main town of a game is an "Orc Country" or "Orc Zone." Every player will be lead to a uniquely named instance of an Orc Fortress (Orc Stronghold of Briskug, Orc Stronghold of Hegger, etc), each with its own X,Y coordinates within the Orc Country. Because of land limitations within the Orc Country, there is a limit to the number of potential Orc Strongholds. Let's say the limit is 10 million Orc Strongholds. The 10,000,001th player that tries to find an Orc Stronghold within the Orc Country will not find one. I imagine this limitation of 10 million created instances is a lot higher than the limit brought about by memory or storage issues.

Anyway, once a player finds a named Orc Stronghold it can be visited by any other player. Any player can interact fully with any existing Orc Stronghold. However, it is almost impossible to gain access to another person's instance. The farthest an outsider can usually get is just outside the front gates. This makes sense in-game and doesn't create inconsistencies because the Orcs of that stronghold only recognize the first player ("the owner") as friendly or worthy enough to enter their stronghold. Everyone else is denied entry, not by the code, but by the in-game discretion of the mobiles. On the slim chance that an outsider gains access to another person's found stronghold they can do whatever they want. They can pick up quest items, they can slaughter mobiles, etc. I think it's makes sense in-game for NPCs to treat people differently.

This example hopefully solves the spatial problems of instancing and makes each instance truly exist for all players.
80.0/114