19 Nov, 2009, quixadhal wrote in the 1st comment:
Votes: 0
So, I was thinking the other day, about how most DikuMUD's tend to handle rooms, objects, and mobs. Quite a bit of the lack of flexibility (and duplication of code) in the Diku system comes from the fact that these are treated as seperate things, rather than having everything be an object, some of which may be NPC's, and some of which might be rooms.

Rambling aside, one of the key differences in this system is that mobiles and objects both have the concept of a prototype or blueprint copy. That is to say, when you load up mob vnum 1200, you have the prototype for an orc. If you create an orc in the room, you now have a mobile object with vnum 1200. In the older version of DikuMUD, you couldn't modify the prototype without editing the files and rebooting (in fact, due to byte-offset indexing, you had to edit copies of the files). Most did give you a "strings" command that allowed you to modify parts of the copied objects. So, you could make "John's Sword of Death" from a plain old longsword. Player corpses were another example, where the code modified the generic corpse object.

Rooms, however, were always kept in their prototype state. One never made a copy of a room, and even later derivatives that added virtual rooms gave them unique vnums. Room 3000 was always the same. But what if you didn't do it that way?

Many graphical MMO's these days have instances, which are zones that are replicated for each player (or group, or raid) so that everyone gets a chance to play through the entire content without interference by other players, and without having to camp spawn points. One could easily add that functionality by having an "instance" bit flag and an InstanceID field on the rooms. If the bit is set, the game checks to see if the player (or anyone in his group) is already in an instance for that zone. If yes, the player is sent to the matching room that has the matching InstanceID. If no, a new instance of the room is created and the player/group is tagged as being in that InstanceID for that zone.

But wait, there's more!

Suppose you wanted to have changes to your world that were permanent, but unique to the players themselves? IE: You have a village that is burned to the ground because the players failed to save it (or because they razed it themselves)…. you don't want every player to see this, because for people who haven't done the quest line, it needs to be intact. You could tie InstanceID's to quests as well. When the players finish a quest, they get an InstanceID that sticks to them… now when they enter the village, they always find the burned out husks instead of the populated town.

Because the game driver treats these as totally seperate rooms (same vnum, but different InstanceID), you could have different mobs, objects, resets, etc… the only caveat is that anything not giving an instanceID means the "normal" prototype room (or InstanceID == 0), and that zones which are set up this way probably need to have their mobiles set to not leave the zone. One probably doesn't want the undead lich version of the town mayor stepping over the zone line into the non-instanced grassland, and then back into the non-instanced village. :)

Ideas? Comments? Wet noodles?
19 Nov, 2009, Mudder wrote in the 2nd comment:
Votes: 0
It seems fine in a non-RP enviroment. But in an RP enviroment - What if the players communicate?

Quote
John the Paladin sits to pray at the grave of his son whom he was unable to save from the terrible fires that consumed his home town.

Ryan the warrior walks up, "What's wrong buddy?"

John, "Everyone is dead, Greenville is burned to the ground. I failed them."

Ryan replies, "What the hell are you talking about? I was just there. I bought an apple. Your kid Henry says hi."

Ryan shrugs his shoulders and continues east as John stares in confusion.


Just seems unrealistic. However I am a huge fan of players being able to interact with the environment in a permenant and lasting way. Currently I'm rethinking how resets are handled entirely. A massacred village shouldn't be all happy and normal in a few IRL hours after everyone was slaughtered.
19 Nov, 2009, quixadhal wrote in the 3rd comment:
Votes: 0
Mudder said:
It seems fine in a non-RP enviroment. But in an RP enviroment - What if the players communicate?

Quote
John the Paladin sits to pray at the grave of his son whom he was unable to save from the terrible fires that consumed his home town.

Ryan the warrior walks up, "What's wrong buddy?"

John, "Everyone is dead, Greenville is burned to the ground. I failed them."

Ryan replies, "What the hell are you talking about? I was just there. I bought an apple. Your kid Henry says hi."

Ryan shrugs his shoulders and continues east as John stares in confusion.


Just seems unrealistic. However I am a huge fan of players being able to interact with the environment in a permenant and lasting way. Currently I'm rethinking how resets are handled entirely. A massacred village shouldn't be all happy and normal in a few IRL hours after everyone was slaughtered.


The way I was suggestiong, this wouldn't happen. It would be unrealistic in a different way…. John would be sitting at the grave, and Ryan would walk into the same space, and neither would see each other. One would be in room (3200,0) and the other would be in room (3200,17), for example. You *could* allow communication to ignore InstanceID's, if you wanted. That might be neat for some areas, where a person with "second sight" might see ghosts walking around that nobody else can see.

I think you'd want it to be another flag, since you would NOT want that for classic instance-style dungeons, and perhaps not for some quest-related things…. but for others, it would be handy.
19 Nov, 2009, Davion wrote in the 4th comment:
Votes: 0
I think you'd likely have to take it a step farther, and add instances for areas, as well as all things contained within an area, or else you'd just have rooms that look different, but are functionally the same. Obviously the mobs/objs would be different, but the resets, shops, progs, etc would all be the same. Really cool idea though Quix!
19 Nov, 2009, Runter wrote in the 5th comment:
Votes: 0
With all due respect, pulling out the tired argument of RP value is getting old. The suggestions made by the OP are obviously easily modified to be fit for any RP environment. I'd argue they'd be better. This isn't just a good idea–It's a proven formula for success when compared to the way most MUDs do things.
19 Nov, 2009, quixadhal wrote in the 6th comment:
Votes: 0
That might indeed be the simplest way to do it.

If you mark an area as instanced, it clones a copy of itself for each instance needed… and that way you get the "instanced dungeon" model as seen in various MMO's out there. If everyone leaves a given instance for long enough, it gets cleaned up (unloaded).

If you set an area as quest_instanced, you have to make your own copies for each quest outcome, and then make whatever changes you want to them. The system doesn't remove these, since they're meant to be permenant. In this case, they're really almost like seperate zones, except they share vnums and physical locations.
19 Nov, 2009, Mudder wrote in the 7th comment:
Votes: 0
Runter said:
With all due respect, pulling out the tired argument of RP value is getting old. The suggestions made by the OP are obviously easily modified to be fit for any RP environment. I'd argue they'd be better. This isn't just a good idea–It's a proven formula for success when compared to the way most MUDs do things.

RP is never a tired argument for me. I come from enforced RP backgrounds (IE: 1 OOC channel within the MUD, and that's a newbie channel that you cannot access past level 10.) So to me, RP is very important and things should make sense within the world you create.

My example wasn't meant to be within the instanced zone but outside the zone. RP does not stop and change with a new area. If your hometown burned to the ground - it is gone. When you enter a new village, your hometown is still gone. However with this implementation, your hometown would still exist, and be totally fine, to other players. To me it makes no sense. Why be able to impact your environment if it doesn't affect anyone or anything else?

Why bother burning down a village if no other player even sees it as destroyed? How could anyone even be a villain in this scenario? This works in MMO environment because RP is rare if it even exists at all in these places. OOC is extremely prevalent - So there is no need to worry about breaking the RP environment. People would rather be able to explore areas without other PCs interfering in their experience. I would rather not isolate characters from each other because player interaction is far more dynamic. If people wanted to play a game without anyone interfering in anything they could go play a single player game.

EDIT: Again, I am not saying the idea is bad but simply stating my feelings on it and pointing out possible drawbacks that other Devs might not even feel are drawbacks, however I guarantee there are players that will share my sentiment. So don't assume I am simply bashing Quix's ideas. I have a lot of respect for him.
19 Nov, 2009, KaVir wrote in the 8th comment:
Votes: 0
quixadhal said:
Many graphical MMO's these days have instances, which are zones that are replicated for each player (or group, or raid) so that everyone gets a chance to play through the entire content without interference by other players, and without having to camp spawn points.

quixadhal said:
Ideas? Comments? Wet noodles?

Not sure if you've read this article by Richard Bartle already (I did also reference it in another recent thread), but if not you may find this part interesting:

Example 2 (new): Instancing

Instancing looks very appealing on the face of it: groups of friends can play together without interference in relative tranquillity. What's not to love?

The thing is, this is not what virtual worlds are about. How can you have any impact on a world if you're only using it as a portal to a first-person shooter? How do you interact with people if they're battened down in an inaccessible pocket universe? Where's the sense of achievement, of making a difference, of being someone?

Most players don't see it that way, though.

Newbies see it as familiar - "fantasy Counterstrike, cool!" (point #2). They don't know what it means for their long-term enjoyment (point #4). Of course, they eventually will learn what it means - boredom and disenchantment - but even so, they probably won't connect the effect with the cause. They'll just go looking for another virtual world that features instancing (point #3). Older-era players will perhaps initially avoid anything with instancing because their first love didn't have it (point #3), but they'll probably try it eventually because (point #4) hey, maybe it's that missing piece that will give them the sense of closure they crave?

Thus, instancing will get locked into the paradigm. New virtual worlds that don't have it will get fewer players than those that do have it, even though they have the better design.

Instancing is short-term good, long-term bad: accepted.


I do use instancing in my mud, and I think it has its advantages, but I can also see Bartle's point - if you're not careful you can end up losing the 'M' from your MUD.
20 Nov, 2009, Runter wrote in the 9th comment:
Votes: 0
I think Bartle often has made statements riddled with false truisms. Even though he's often right on some level he takes it to a purist ideological stage. In that passage you quoted:

Quote
The thing is, this is not what virtual worlds are about. How can you have any impact on a world if you're only using it as a portal to a first-person shooter? How do you interact with people if they're battened down in an inaccessible pocket universe? Where's the sense of achievement, of making a difference, of being someone?

Most players don't see it that way, though.


Nor do most developers. This is a very purist point of view with seemingly no room for compromise.

Quote
Thus, instancing will get locked into the paradigm. New virtual worlds that don't have it will get fewer players than those that do have it, even though they have the better design.


Yes, people are too dumb to know what they actually enjoy. This "lack of long term enjoyment" is why the big boy MMOs are losing old players exponentially as they toil and struggle with their boredom and disenchantment. I think empirically we know that I'm being sarcastic here.

Also, I dispute the idea that game A had a better design than game B by this virtue. Or rather, I dispute that people actually made their decision to play B over A because of this. It was likely, as with most MMOs today, that B was riddled with other problems as players (including myself) have seen and cited for reasons for shying away from many MMOs.
20 Nov, 2009, quixadhal wrote in the 10th comment:
Votes: 0
Mudder said:
Why be able to impact your environment if it doesn't affect anyone or anything else?

Typically, because your players consume content much faster than your builders can produce it.

In small scale RPG's, such as pen-and-paper games, the DM controls how content is deployed, and can create new content on the fly to address players making unexpected choices. This works great, and makes for a fun and immersive experience. Unfortunately, in a MUD, the computer code is taking on the role of the DM, using content provided by builders and coders. It can't make stuff up on the fly. It also, and this is where instancing comes into play, can't ensure that everyone who wants to play the game progresses through the content at the same pace.

In a D&D campaign, the DM can even handle party splits and arrange for people to end up at the right place, at the right time, and all around the right experience level to handle an encounter. In an MMO, players might work as teams for short term goals, but their long-term experience is individual. If a group wipes out a goblin village, is it fair to never allow any other player afterwards to enjoy that content? More to the point, can you churn out content fast enough to make such things one-time throw-aways, where only a single group can ever claim to have done it?

That's where the quest instancing idea I'm presenting comes into play. If you've conquered the troll village, then for you, it has burned to the ground and you can't keep recamping it. But a new player can still enjoy finding and solving the puzzles, and can still get a group together to burn down the village.

I do see that it breaks immersion, and makes for some strange RP potential. However, I think the benefits from having permanent events that can still be enjoyed by all the players outweighs the RP constraints unless you are a pure RP game. In that case, you can arrange things so that people should only RP about common experiences. If I've done the quest, and you haven't, us talking about it is essentially OOC chatter. It's no different than several people reading the same book, and one being ahead of the other.

KaVir said:
I do use instancing in my mud, and I think it has its advantages, but I can also see Bartle's point - if you're not careful you can end up losing the 'M' from your MUD.


I agree. I've played both the original Everquest (no instancing), and World of Warcraft (heavy instancing). They both have their good points, however in most MMO's, quests don't really change the world. In those cases, I prefer instancing because it can be a very frustrating evening to have a group get together, spend 2 hours battling their way to an encounter only to find someone else already there finishing it. If the changes are more substantial, I'd prefer anyone who hasn't done the event to be able to join in and then see the permanent results, but not by locking the content away from everyone else.

In many ways, I think it depends on how your game is structured. If it's cooperative, you want as many people in the same place as possible, as this encourages working together to do big things. If it's more competitive, having them all competing over the same (limited) resources makes for good competition, but also makes for frustration and farming.
20 Nov, 2009, Scandum wrote in the 11th comment:
Votes: 0
quixadhal said:
Ideas? Comments? Wet noodles?

Instancing is easy and Bartle's argument against it is pretty solid. It would make more sense to focus on non static world design. Using a two faction PK system you could create a chess like strategic end-game where groups would battle over configuring the world into a state desirable for their faction. An economic end game could be interesting as well, where the destruction of a bridge could drive up the price of certain goods. For a system like this to work you'd probably have to build it from the ground up.

And even then players would eventually become disillusioned since their impact on the world is only temporary, or insignificant, but I think it'd be an overall improvement.
20 Nov, 2009, Skol wrote in the 12th comment:
Votes: 0
Hm, you know I've also seen a mix of instancing that seemed to work decently.
It didn't allow impacting say buildings, but you could drop items and they later show up to everyone else, but say the first few minutes it's just something you see. (Runescape, play it with my son sometimes).

Say you kill a mob (they don't allow kill/stealing unless it's in a specified zone), you kill the mob and you see the corpse and items, but no one else does until their 'vis' timer runs and then everyone else sees them. Same if you drop things.

In that small case it's instancing those items, but again a small case. It also allows for everyone else to see each other and interact though.
20 Nov, 2009, Dean wrote in the 13th comment:
Votes: 0
quixadhal said:
Mudder said:
Why be able to impact your environment if it doesn't affect anyone or anything else?

I agree. I've played both the original Everquest (no instancing), and World of Warcraft (heavy instancing). They both have their good points, however in most MMO's, quests don't really change the world. In those cases, I prefer instancing because it can be a very frustrating evening to have a group get together, spend 2 hours battling their way to an encounter only to find someone else already there finishing it. If the changes are more substantial, I'd prefer anyone who hasn't done the event to be able to join in and then see the permanent results, but not by locking the content away from everyone else.


So you spend 2 hours battling to said encounter only to find another guy/group killing this Boss. Seems there'd be two logical options A) Wait for boss to respawn or B) Murder the group/guys for having the nerve to get to your kill before you. :wink:
20 Nov, 2009, Tyche wrote in the 14th comment:
Votes: 0
I wonder if you could incorporate instancing, including instancing characters, to run alternate timelines in some sort of time travel game. :-)
20 Nov, 2009, Erok wrote in the 15th comment:
Votes: 0
I have a few different zone types (haven, quest, and arena), heavily based on how Guild Wars works. And I don't care what Bartle thinks of instancing (I think the guy gets more credit/deference than deserved - actually reminds me of the countless people who claim responsibility for the internet).

Haven zones are singleton safe zones (i.e., no combat allowed). These are typically home towns, that link together quest zones, where players shop, socialize, and organize into groups.

Quest zones are PvE and instanced on a per group basis. One group cannot interfere with another, and mobiles are not able to leave a quest zone. The zone loads when a group enters it, and unloads when they leave it. A nice side-effect is that there is no such thing as spawning (and thus camping).

Arena zones are PvP (and optionally PvE) and I haven't yet decided if they will be instanced or not. If instanced, it would be for a pair of teams. If singleton, it's your team versus all others.
20 Nov, 2009, quixadhal wrote in the 16th comment:
Votes: 0
Erok said:
I have a few different zone types (haven, quest, and arena), heavily based on how Guild Wars works. And I don't care what Bartle thinks of instancing (I think the guy gets more credit/deference than deserved - actually reminds me of the countless people who claim responsibility for the internet).

Haven zones are singleton safe zones (i.e., no combat allowed). These are typically home towns, that link together quest zones, where players shop, socialize, and organize into groups.

Quest zones are PvE and instanced on a per group basis. One group cannot interfere with another, and mobiles are not able to leave a quest zone. The zone loads when a group enters it, and unloads when they leave it. A nice side-effect is that there is no such thing as spawning (and thus camping).

Arena zones are PvP (and optionally PvE) and I haven't yet decided if they will be instanced or not. If instanced, it would be for a pair of teams. If singleton, it's your team versus all others.


I would probalby make arena zones instanced, since that's structured combat. If you have open world PvP zones, those would be best non-instanced, since you want everyone to find everyone else. :)

Along the same lines, Everquest II did a clever thing when they launched. All of their zones are instanced, but they instance by population. When a zone population exceeds a certain number, a new copy is spawned. They provided objects in the zones (and later, menu options) to allow you to go to a particular copy so you could join your friends. Most MUDs are (alas) not going to have problems with lag and overpopulation, but that was a nice way to handle it transparently.
20 Nov, 2009, David Haley wrote in the 17th comment:
Votes: 0
Mudder said:
My example wasn't meant to be within the instanced zone but outside the zone. RP does not stop and change with a new area. If your hometown burned to the ground - it is gone. When you enter a new village, your hometown is still gone. However with this implementation, your hometown would still exist, and be totally fine, to other players. To me it makes no sense. Why be able to impact your environment if it doesn't affect anyone or anything else?

How does a world work in which players can raze entire zones to nothing? Are you building more zones by hand to replace the destroyed ones? Are players just as able to create towns as they are to destroy them?
21 Nov, 2009, Scandum wrote in the 18th comment:
Votes: 0
David Haley said:
How does a world work in which players can raze entire zones to nothing? Are you building more zones by hand to replace the destroyed ones? Are players just as able to create towns as they are to destroy them?

The most obvious solution would be to have NPCs rebuild towns, but it'd make sense to let players create more generic destructible content as well. So the world would be elastic, for lack of a better term.
21 Nov, 2009, Mudder wrote in the 19th comment:
Votes: 0
Like Scandum said, NPCs would slowly repopulate and rebuild areas that are "messed up." Also destroying an entire village would surely not be an easy feat - It would require a small army depending on the size of the village. The village if destroyed would remain there, just be burned down and crappy for awhile. Perhaps it would even unlock certain things like a secret passageway that was normally almost impossible to find.

I'm still simply brainstorming this so I'm not even sure how it would work. I'm pushing it back further until I am more familiar with C++ (I have a few books to buy/read)
21 Nov, 2009, kiasyn wrote in the 20th comment:
Votes: 0
Mudder said:
Like Scandum said, NPCs would slowly repopulate and rebuild areas that are "messed up." Also destroying an entire village would surely not be an easy feat - It would require a small army depending on the size of the village. The village if destroyed would remain there, just be burned down and crappy for awhile. Perhaps it would even unlock certain things like a secret passageway that was normally almost impossible to find.

I'm still simply brainstorming this so I'm not even sure how it would work. I'm pushing it back further until I am more familiar with C++ (I have a few books to buy/read)


I cast 'destroy argument' followed by 'destroy village'!
Random Picks
0.0/114