28 Feb, 2010, KaVir wrote in the 1st comment:
Votes: 0
I'm not disagreeing with the following comment, but it reminded me of something so I'm quoting it for context:
David Haley said:
On a higher level I think one of the issues that has been plaguing Dikuland for some time now is simply that areas are supposed to be such self-contained entities, with one person doing everything and only at the end attaching it into the rest of the world. There is very little notion of a catalog of useful things, be it for scripting or even for common objects or actors.

Reading that also brought to mind an old blog post:

http://kooneiform.wordpress.com/2007/01/...

In particular the comment: "What Karinth has that GW II lacks are the traditional, story-based areas with a lot of color."

Many times over the years I've heard arguments in favour of having a single seemlessly connected world instead of self-contained "plug and play" areas - not just for mob and object consistency as mentioned in the first quote, but also for the overall world consistency, so that the game world feels more like a living breathing world, a single entity rather than a cluster of unrelated locations stapled together.

But in practice, is this really desirable? Encapsulation makes it easier to design a varied game world, and it makes it easier to break up the world development into managable chunks that can be assigned to different members of staff, with each area clearly assigned its own story, subtheme, flavour, puzzles, challenges and objectives.

Perhaps more importantly still, I think the gameplay can actually be improved by splitting the world up into clearly identifiable sections for the players. I remember a discussion I once had with someone who had drawn up a well thought-out list of guidelines for mud design, and the first of his five points was "multiple, easily achieved short term goals". An encapsulated world can do exactly that, turning each area into a clearly defined short-term goal.

You can still do this with a seemless world, but it's not as easy from a design and development perspective, nor are the areas so clearly defined for the players. Which raises the question: is a seemless world actually a desirable feature, or is it just one of those things that sounds cool on paper?
28 Feb, 2010, Kline wrote in the 2nd comment:
Votes: 0
I think you can still have a seamless world while maintaining the boundaries of encapsulation; it just takes vision and proper oversight to achieve. Take WoW for example; the entire world (sans instances) is entirely seamless, yet still has distinct areas and even sub-areas. The only defining movement between an area is that your screen/map will display the new area name for a brief moment. Everything works well with the gradual blending of one zone into another as you near the borders of any given region, yet each region is still distinct in its look, feel, types of creatures, etc.
28 Feb, 2010, Scandum wrote in the 3rd comment:
Votes: 0
I think continents work best in practice as building often occurs in bursts, so if you plan it right you can have your builders finish a continent, and as a side effect get them to do that extra bit of work just to get the continent looking right. So you'd have areas encapsulated in continents, encapsulated in the world.
28 Feb, 2010, Idealiad wrote in the 4th comment:
Votes: 0
In practice 'seamless' mud worlds are basically encapsulated, as areas are added piecemeal by accreting them onto previous ones.

However I wanted to point out (as I did in the comments of that linked post) that Karinth used a wilderness system, where the areas were plugged into the wilderness grid – essentially GW2's system as it stands (though I don't think GW2 has areas, unless you count dungeons and task bubbles).

The problem with the first method is because most muds don't have the time or resources to develop a fully fleshed out world first, sometimes attention isn't paid to transitioning areas so they feel more natural (i.e. the classic desert area next to the forest area problem). This counts for culture as well as geography. The advantage of the wilderness map with plugged in areas is obvious here, but then you face the second problem of justifying certain area sizes within a fixed wilderness grid.

I don't know if there's a simple solution to that other than planning things out beforehand, or using continents/islands/planes as noted above.
28 Feb, 2010, Tonitrus wrote in the 5th comment:
Votes: 0
I don't think seamless worlds are in any way bad. On diku style rooms, you type movement commands, you read descriptions. In a well-written area, the descriptions are detailed and interesting, and there's a great feeling of exploration as you wander through them and explore. Now, compare that to the stock area Town of Solace. "A road is here, going east and west." Despite the fact that diku rooms are each their own little microcosm, Solace is in no way interesting. Why? It's sparse, and there aren't enough different, interesting things to read. I think this is the trouble with GW2 areas, not the fact that the locations are seamlessly connected. Also, moving large distances doesn't show you updates in descriptions, so you may not even notice if you pass through an interesting section. The movement messages help, though. I think with more descriptions in the areas and maybe having autolook on desc changes, the more traditional area effect could be achieved on GW2. Given the size of the world, though, that could take awhile to implement.

So, in more general terms: Seamless worlds should be able to work fine if they have enough different descriptions to read. It would also be useful to have things like extra descriptions and such, and maybe hide away some things for explorers to find.
28 Feb, 2010, David Haley wrote in the 6th comment:
Votes: 0
I think you can compare it to a bunch of programmers working on their own code, while sharing a common base tree. Generally, if you find yourself doing something that you feel is common or at least probably going to be reused, it's considered polite to find a place in the shared code to put it. Otherwise, you put it into your tree. Occasionally, people (hopefully) review the situation to make sure that groups aren't adding too much should-be-common stuff to their code, and refactor into the shared tree as appropriate.

The analogy to building is clear hopefully. If builders find themselves creating fairly standard furniture objects, for example, they should consider adding them to a shared catalog of sorts instead. (Of course, you need to support this notion of a shared catalog: for Dikurivatives, everything is rather intimately tied into specific areas and the whole permission model works around that.) The head builder (or somebody) would need to keep an eye on the objects being created in individual areas to see if there should be effort to move things up to the common catalog.

I have no real issue with taking the world, cutting it up into chunks, and assigning these chunks to individual people; in fact this seems like a very reasonable thing to do. It's just that as you cut stuff up, you need to be careful, as others have said, to maintain consistency somehow. (I would think that this is typically the head builder's role.)

That said, I think that the issue of having clearly defined gameplay objectives is somewhat orthogonal to whether or not areas are built completely individually with zero cross-referencing. You can still define "zones" (erk, overloaded vocabulary) within a seamless world that should have certain properties.
28 Feb, 2010, Runter wrote in the 7th comment:
Votes: 0
I think there's a huge difference between trying to make your world completely non-modular and having that catalog of resources to build with. There's a great deal of things that don't necessarily have to be limited to actual items in your game that can be used. These may be scripts, techniques, patterns, etc etc.
0.0/7