09 Nov, 2010, David Haley wrote in the 61st comment:
Votes: 0
I think it's generally better to explain why you're copying something wholesale rather than just repeating it and expecting people to divine your meaning.
09 Nov, 2010, lockewarrior wrote in the 62nd comment:
Votes: 0
Runter's post seemed to say, to me anyway, that there's no point speculating over the effectiveness of implementing instances in a given scenario when you could simply try it and measure the result. I quoted my earlier post to indicate that, while we may I have differing views on instancing, I certainly wouldn't contest that statement.

You might be right, though! Leaving people to 'divine' my meaning from 'wholesale' copying, we end up with Ssolvarain's snide, "So instancing was your idea now?"

I guess I'm to blame. :{
09 Nov, 2010, Ssolvarain wrote in the 63rd comment:
Votes: 0
It was a light-hearted poke. I don't get that emotional about the internet anymore.

You're like a walking MUD meme. You just gotta accept that :biggrin:
11 Nov, 2010, lockewarrior wrote in the 64th comment:
Votes: 0
I'm taking that as an underhanded compliment and offering my wholehearted approval of this thread now. :]

I hate how ambiguous text can be & I think people have a hard time getting my sense of humour anyway.

Certainly was light-hearted about that as well.

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.

I don't think Lua is ideal for this setup, but it's fun experimenting anyway.
11 Nov, 2010, Ludwig wrote in the 65th comment:
Votes: 0
David Haley said:
Ludwig said:
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.

So now players can talk to each other about their adventures and quests in their own Orc Stronghold that they stumbled upon without having to introduce these strange alternate realities.

Yes – 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. The "strange alternate realities" have not been addressed, because there will still be a break between the non-instanced areas and the instanced areas they connect to.

Really, if you're going to use instancing, you should just accept that it will never truly make sense in the game world unless you start invoking multi-dimensional portals or something like that.


I never said that these hypothetical, instanced Orc strongholds would occupy the same physical space. If you wish to imagine it that way, that these instanced locations all take up the same space, then that's a limitation that comes from the way you think. I would not place these instances in the same physical space. 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. Instead of having a single "Orc Stronghold to the east of the main town," you will have many Orc Strongholds in the Orc country to the east of the main town. Then it makes perfect sense.
11 Nov, 2010, David Haley wrote in the 66th comment:
Votes: 0
Your modification doesn't really change anything about the physical location problem. There's no need to tell me that my thinking is limited. :smile: On the contrary, your response indicates to me that you might not have thought this all the way through, because your modification doesn't really address the problem I pointed out, it just changes the exact details of the problem.

In your modified solution, where people are led to different places, we have this problem:
One player goes east a bit, then north a bit, and finds an orc fortress.
Another player goes east a bit, then north a bit, and finds nothing. But if this player goes east a bit then south a bit, there's an orc fortress, that (somehow) absolutely nobody else noticed (and, for that matter, will never be able to notice, even at the same time).
Umm, what?

"Hey Bob, I found this great fortress – let's go raid it. It's over there."
"But, uh, George, it's actually there, not where you said it is."
Oops, spatial inconsistency.

"Hey Bob, I just wiped out this fortress over in Orc Land. Yay!"
"Umm no, it's still there, I see it…"
I guess they breed (and build) like rabbits??

There is no way that you will make true instancing make any kind of sense. 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 unless you invoke mysterious dimensional portals and parallel worlds.

It's much better to just accept instancing as a solution to a problem (or not) and not try to make it magically sensible. I would be eager to be wrong about this, but so far you haven't solved the problem, you've just waved a magic wand around and said it goes away because the orc fortresses mysteriously multiply. What have you actually solved here? You've created confusion about where things are located ("hey, go check out that nice raid <here>") while not enforcing any kind of spatial or temporal consistency.
11 Nov, 2010, Ludwig wrote in the 67th comment:
Votes: 0
"Your modification doesn't really change anything about the physical location problem."

I didn't modify my argument, I only explained further. It is the same argument and I never wavered from it. You, unfortunately, also didn't modify your argument, which includes the belief that all these instances are one and the same (they are not). I will show how you believe that all instances are one and the same.

"Hey Bob, I found this great fortress – let's go raid it. It's over there."
"But, uh, George, it's actually there, not where you said it is."
Oops, spatial inconsistency.


When you created the Bob and George scenario, you assume that Bob and George think that the two fortresses are the same. They are not. One is called (as an example) Orc Fortress of King Gurgash and the other is called Orc Fortress of King Krulla. According to my suggestion where each instance is unique in name and location, Bob and George should not be confusing the two fortresses. Another example where you think each instance is one and the same:

"Hey Bob, I just wiped out this fortress over in Orc Land. Yay!"
"Umm no, it's still there, I see it…"


Why does George think that his fortress is the same as Bob's when each fortress has a unique name? They are not the same fortresses. They are similar but unique. The fortresses are different, even in name. One fortress will never be confused for another. There is no inconsistency.
11 Nov, 2010, David Haley wrote in the 68th comment:
Votes: 0
I'm sorry, but you really need to think this through more.

First off, I should have said 'clarified', not 'modified'. Second, you do not understand my argument if you believe that it is about thinking these places are all the exact same places.

It doesn't matter if you give these fortresses different names. It doesn't matter if one has goblins and the other has orcs. It doesn't matter if one's a fortress and the other a cave.

The simple fact of the matter is that a place will exist for one player in a very specific location, and will not exist for anybody else in that location. This is, quite simply, inconsistent. The physical world changes depending on who is looking at it.

You are correct that people won't believe that they're going to the same exact fortress, but that does not in any way address the fundamental concern here, which is the problem of instancing breaking world consistency. They're not going to the same fortress, so why is it exactly that they can't go to (or even see!) the place the other is going to?

You say things like this:
"Why does George think that his fortress is the same as Bob's when each fortress has a unique name? They are not the same fortresses."
But this is making the mistake of saying "his fortress" – if a world is consistent, the fortress exists, or it doesn't. Any other answer – such as: it exists for some people but not others – creates an inconsistent world.

Maybe your world obeys some kind of macro-level quantum mechanics rules where entire cities appear and disappear depending on who is observing them… that's just another way of saying that you have some magic dimensional portal of some sort, I suppose.
11 Nov, 2010, plamzi wrote in the 69th comment:
Votes: 0
I'm by no means an expert on instancing in 3D MMO's but isn't there a single entry point (a portal, e. g., or a "transport my party" button) at the crux of it all? The entry to the instance is regulated in a way that makes it 'appear' absolute to every player who is within range or is otherwise eligible to enter. Maybe the portal is only open until 30 people pass through, or the button gets enabled when all 30 members of a party are within sight of a "portal"… In a MUD context, you could make sure that everyone in the same room, or the same group, sees the same instance entry, up until the point when the instance is sealed off. This takes care of the George and Bob issue.

Ludwig's suggestion, as I understand it, is that instances of the same area can have name variations to add flavor. To me, this seems like a double-edged feature. If you're cloning the exact same area, you're potentially confusing players who revisit an instance under a different name or players who ask each other about how to explore an area. I understand that the idea is to clear the confusion between two players in two different instances of the same room/zone–but this seems to merely delay and displace the confusion, not disperse it. To carry the idea of unique zone names through, you'd have to randomize the dungeon, and add the same kind of variation flavor to all special items and mobs inside it. These are not trivial things to automate for a MUD.

If I were to introduce instances, I'd start with just taking care of the basic logistics to instancing the same zone–that's a big enough bite, I think.

I'm curious if anyone can point to an instance implementation on a MUD and what that looks like. I know that in my MUD it would be a can of worms. Some questions that come to mind: Where do I respawn dead players so they can re-enter but also potentially accept help from others? How do I make the instance re-accessible to participants who want to duck out to a 'main area' temporarily? When and how do I destroy the instance safely?
12 Nov, 2010, Ludwig wrote in the 70th comment:
Votes: 0
David Haley said:
The simple fact of the matter is that a place will exist for one player in a very specific location, and will not exist for anybody else in that location. This is, quite simply, inconsistent. The physical world changes depending on who is looking at it.
Ok, I see your point that instancing has the potential to lead to an inconsistent physical world, and I see that the example I gave does lead to an inconsistent physical world. But, I still do not believe that instancing is fundamentally inconsistent. In other words, I do not believe using instancing will always lead to inconsistencies. I think it depends on how you use instancing in a MUD, and I believe there is a way to use instancing without the inconsistencies you brought up.

This time I will modify my example from before (uniquely named Orc Strongholds) to show that instancing can be used without leading to an inconsistent physical world:

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. (This is where implementation and story come in) The Orcs of each stronghold will only interact with the "creator" of the instance, and will ignore and probably kick out anyone else. This way, every Orc Stronghold will exist for everyone in the location it was first found. Each Orc Stronghold will probably have to have a set of unique coordinates within the larger Orc Country, but that is yet another implementation issue and not a fundamental problem with instancing.
12 Nov, 2010, David Haley wrote in the 71st comment:
Votes: 0
In your modified example, you solve the problem of physical inconsistency. But other inconsistencies are added in its stead: 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?

You still do have a physical problem, though, although not one of inconsistency. Let's assume that your orc country is 100 square miles, and that a fortress takes up half a square mile (random numbers). After 200 players have created instances, you don't have any room left to add more instances.

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.

Let's take a step back, perhaps. Why is it so important to you to work around the traditional instancing approach? It seems reasonable enough, and avoids a lot of extra contortions that we're having to go through here.
12 Nov, 2010, Runter wrote in the 72nd comment:
Votes: 0
Also if you're worried about everything making real world sense never let KaVir scrutinize your combat system. Or probably practically any system. Odds are someone will point something out. I've found how fun a game is has no relationship to how much of a reality simulator it is.
12 Nov, 2010, quixadhal wrote in the 73rd comment:
Votes: 0
You guise…

First of all, instancing is SUPPOSED to give alternate views of the world to different (groups of) players. That's kind of the whole point. The problem instancing was developed to overcome is the spawn camping and content abuse that games without instancing typically have. The dragon spawns, and 50ms later, 5 groups of 40 people all attack it, 1 group tags it, and the rest have to sit down and wait for it to respawn again.

Instancing provides a split world-view, where each group sees their own dragon, and attacks it. They're all physically in the same place, but they don't see one another, nor the effects they might have upon the chunk of world that is instanced. That's the point. It isn't supposed to be physically consistent. That would defeat the purpose.

In other uses, it's been applied as a storyline mechanic. Player X wanders into a desolate graveyard and distrubs a grave, suddenly the graveyard is filled with zombies because of his actions. He mows them all down with a lawnmower that just happened to be nearby, and loots the artifact from the grave. If he returns later, the grave is now empty and there are zombie bits scattered around in the grass. If player Y wanders into the same area, they see the desolate graveyard, undisturbed because they haven't advanced the storyline yet.

Now, without instancing, player X gets to enjoy the fun zombie attack, and gets the loot. Player Y is either SOL and will never get to see it, or they have to sit around waiting for the zone to reset. If it does reset, player X might not be able to start the event or loot the grave, but he can still hang around and suck free EXP from the zombies which were supposed to be for player Y.

In every example of instancing *I* have ever seen, the goal of making things instanced is specifically to do things that would be NOT FUN if it were physically consistent. Even player housing. Star Wars Galaxies had non-instanced player housing, and while it was cool when the servers were full, it was not so cool when you had to stomp across half the game world through ghost towns trying to get to the one shop that was still operational, or to your friend's house that was way out in the sticks because that was the closest spot he could build a house.
13 Nov, 2010, Ludwig wrote in the 74th comment:
Votes: 0
David Haley said:
In your modified example, you solve the problem of physical inconsistency. But other inconsistencies are added in its stead: 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?

You still do have a physical problem, though, although not one of inconsistency. Let's assume that your orc country is 100 square miles, and that a fortress takes up half a square mile (random numbers). After 200 players have created instances, you don't have any room left to add more instances.

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.

Let's take a step back, perhaps. Why is it so important to you to work around the traditional instancing approach? It seems reasonable enough, and avoids a lot of extra contortions that we're having to go through here.


These are all problems with story and implementation, and not fundamental problems of instancing.

"for example, interaction inconsistency. Why are these orcs only responding to one specific player? Why can't Bob kill them too?"

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."

"You still do have a physical problem, though, although not one of inconsistency.
…After 200 players have created instances, you don't have any room left to add more instances."


I'm going to ignore this physical space problem because it exists in all types of MUD areas, not just instancing. For example, if you make a small rowboat with an area of 20 sq feet and give it 200 rooms, then of course you'll run into a physical space problem. That problem comes from implementation (building in this case), and not from instancing.

"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."

Well that's a problem with my examples, not with instancing. You say the problem is that the world behaves differently based on who is acting upon or observing that world. I don't see a problem with NPCs acting differently toward different people. I see that as a benefit. If you are worried that (for example) a quest object cannot be picked up by anyone other than the instance creator, then that's just an implementation decision. It is fully possible to let any player interact freely with any instance. But as a good builder you wouldn't allow it. It's not a fundamental problem of instancing. Now for the observing part. If you wanted, you could also let each instance keep its appearance to ALL players. It's totally possible. The only reason why the world behaves differently in my examples is that I chose to have them act that way. That decision came from me and was not forced by instancing.

"Let's take a step back, perhaps. Why is it so important to you to work around the traditional instancing approach?"
I don't care about instancing. I just feel that, logically, your claim was wrong and I am prepared to show why.
13 Nov, 2010, chrisd wrote in the 75th comment:
Votes: 0
The whole point of instanced content is to provide inconsistent game experiences to individual players.

Ludwig said:
These are all problems with story and implementation, and not fundamental problems of instancing.

Ludwig said:
That interaction limitation is just an implementation decision and not a fundamental problem with instances.

Ludwig said:
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."

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

First you suggest that the perceived inconsistencies inherent in instancing are actually a result of individual implementation decisions, and aren't a problem with instancing itself. This is a cop out on your part.

Then you redefine the way instancing should work (allow players to mess with each other's instances - how is this different from regular content?) and thereby make it a completely useless mechanic, gameplay-wise. Five copies of the same Orc Stronghold accessible by all players are "instances" in the same way that every mob in the game is an "instance" - in a technical sense. It makes no difference to gameplay.

Then you suggest that the consistency problem is with your examples, not your argument. If you cannot supply valid evidence to support your claim then why should we believe you? Ultimately neither you, anyone I've ever talked to, nor any game I've ever played has managed to make instanced content consistent while retaining its value (i.e. full experience of the content for every player) - and most don't even bother trying because - as quix points out above, and as I opened this post - the entire point of instancing is that it provides an inconsistent game experience for individual players.
13 Nov, 2010, Ludwig wrote in the 76th comment:
Votes: 0
^^
"The whole point of instanced content is to provide inconsistent game experiences to individual players. "

Can you supply evidence for this claim? If not, then it's just an opinion (interestingly worded btw to refute my claim).

"First you suggest that the perceived inconsistencies inherent in instancing are actually a result of individual implementation decisions, and aren't a problem with instancing itself. This is a cop out on your part."

Well I stand by what I stated. Can you tell me why you think it's a cop out? While you're at it, define "cop out" because I only know the term through context.

"Then you redefine the way instancing should work (allow players to mess with each other's instances - how is this different from regular content?)"

I'm just using instancing differently. I'm not redefining instancing by using it differently. The definition of instancing stays the same. Let's cut out some confusion. Let's define instancing as making unique copies of something from a prototype. In this case we are talking about making instances of an area (including mobs, items, rooms, progs, quests, etc) from a prototype area. Once the area instances are made, it's the MUD code that allows or prohibits a player's interaction with each instance. The way instancing "should work" is a personal choice and it's not set in stone.

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.

btw, if you're going to reply to a post, please read through all the previous posts that are quoted within it so you don't read things out of context. So if there's a cut out quote somewhere, take the time to read the entire quoted post too.
13 Nov, 2010, chrisd wrote in the 77th comment:
Votes: 0
Ludwig said:
Let's define instancing as making unique copies of something from a prototype.

In that case, let's define a consistent game world as one that does not contain instanced content. While it is certainly easy to argue by defining the terms in your favour, I think my previous sentence should make the flaw in this approach quite obvious. What you are talking about is instancing in a technical sense. As far as I can see, this thread has been focused on instancing as a game mechanic - at least, that is what people have been saying produces inconsistent experiences. As a game mechanic, instancing is designed to produce unique copies of content for players to enjoy without other players intruding on the experience. Your examples of consistent instanced content have been moving further and further away from this. According to your definition, all content in my game is going to be instanced. To the player, however, the vast majority of content is going to be a single world which they share with other players. That is not "instancing" as a mechanic (nomenclature sucks).

Ludwig said:
btw, if you're going to reply to a post, please read through all the previous posts that are quoted within it so you don't read things out of context. So if there's a cut out quote somewhere, take the time to read the entire quoted post too.

I'm almost certain I've read this whole thread, but I don't concentrate too hard while browsing MudBytes, so I may well have missed soemthing.
13 Nov, 2010, KaVir wrote in the 78th comment:
Votes: 0
chrisd said:
the entire point of instancing is that it provides an inconsistent game experience for individual players

Interesting choice of words - earlier the discussion was about an inconsistent world, but now you're also saying its also an inconsistent game experience? I specifically added instancing to my mud to provide a consistent game experience for individual players. By giving everyone their own instanced location, I ensure that players can't help or hinder each other in situations where I want them to overcome personal tests of skill.

chrisd said:
As a game mechanic, instancing is designed to produce unique copies of content for players to enjoy without other players intruding on the experience.

That's a common implementation, but it's not necessarily the case. Take the towns in Guild Wars, for example - the game creates an instance for every 100 players, and players can even switch between the instances if they wish.

Likewise, there's no reason why you couldn't base the instance on the entrance coordinates - a fantasy setting where the land is riddled with underground dungeons, or a modern day theme set in a sprawling city where you can 'enter' any nearby building, or a sci-fi setting where the universe is packed full of explorable worlds. From a technical perspective this is much the same concept - you're creating one instance per unique ID. The only difference is that the ID comes from world/city/universe/stargate/etc coordinates rather than the character ID, and thus multiple characters could actually enter the same instance (but good luck finding me while I'm off collecting alien loot).

Of course this also raises the question of what, exactly, is a "copy" - if the world was riddled with thousands of identical dungeons then that would quickly get boring. But there's no reason why you couldn't randomly generate the dungeons each time (I already do so for non-instanced dungeons), or even procedurally generate the layout based on the ID, ensuring that each dungeon is both unique and persistent. The drawback is that you're then relying on fully or partially generated content, which is a pretty hefty design decision, and not one that appeals to everyone.

The instancing article on wikipedia discusses some of the background and uses, and references articles by a couple of MMO lead designers who discuss the drawbacks, and how instancing can be used to make sense within the context of a fictional universe.
13 Nov, 2010, chrisd wrote in the 79th comment:
Votes: 0
KaVir said:
chrisd said:
the entire point of instancing is that it provides an inconsistent game experience for individual players

Interesting choice of words - earlier the discussion was about an inconsistent world, but now you're also saying its also an inconsistent game experience? I specifically added instancing to my mud to provide a consistent game experience for individual players. By giving everyone their own instanced location, I ensure that players can't help or hinder each other in situations where I want them to overcome personal tests of skill.

I've been using the term in place of "world" because I think it's a more accurate description. It is the interaction of players with the content and each other that makes inconsistencies obvious. If two players separately battle through the dungeon of Grog the Orc King, killing Grog at the end, then they have had a consistent experience when it comes to that particular content. Ultimately, though, their actions are inconsistent with the actions of the other player, all other players in the game who've defeated Grog, and the game itself (because Grog is presumably still terrorising his neighbourhood). One aspect of the game experience is consistent (that's the point of instancing, after all), but it introduces a range of inconsistencies into the game experience as a whole.
13 Nov, 2010, KaVir wrote in the 80th comment:
Votes: 0
chrisd said:
I've been using the term in place of "world" because I think it's a more accurate description. It is the interaction of players with the content and each other that makes inconsistencies obvious. If two players separately battle through the dungeon of Grog the Orc King, killing Grog at the end, then they have had a consistent experience when it comes to that particular content. Ultimately, though, their actions are inconsistent with the actions of the other player, all other players in the game who've defeated Grog, and the game itself (because Grog is presumably still terrorising his neighbourhood).

And what if two players separately battle through the <location> of <name> the <race> <title>, an instance that's been procedurally generated based on the coordinates of the entry point and the timestamp of the last time it was completed?

chrisd said:
One aspect of the game experience is consistent (that's the point of instancing, after all), but it introduces a range of inconsistencies into the game experience as a whole.

What inconsistencies would my procedurally generated example introduce?
60.0/114