Make Your Own Virtual World

One of the bottlenecks in virtual world research is the fact that we academics don't have any virtual worlds of our own. The reason for this is simply cost: it's just too expensive to create one to anything approaching professional quality (unless you go with a textual world, in which case it's cheap but you don't get players).

There are free development tools around, but they always seem to be missing some crucial component. NeL gives you a skeleton, for free, but wants half a million Euros for a something you could actually use. Kaneva's game engine is more complete, but you can't use it for free-to-play worlds of any scale (ie. more than 30 players - and they want to host it on their own network). RealmForge is very good except for its network features, although it is rapidly improving in that area. RealmCrafter is only $55, so it's practically free, but its graphics engine is dated and it's still something of a work-in-progress. BYOND is 100% free, and is excellent - if you don't mind having a 2D world rather than a 3D one.

I was a little suspicious, then, when at the AGC I heard of Multiverse, launching today. It's a complete, end-to-end platform solution that is free for non-commercial use. "We only make money when you make money, and if you never charge a cent, you never have to pay us anything". Nevertheless, having looked into it, it does indeed seem to be the genuine article. It was set up by a bunch of ex-Netscape developers, and they took their give-it-away philosophy with them. The business model appears to be to build up an installed base of Multiverse browsers through free games, thereby making the platform attractive to commercial developers (who will have to pay to use it).

Never mind the world of commerce, though - this is great for academics! We get a free, commercial-quality engine, plus SDK, documentation, sample game, art assets - everything except our own content. Because there's a common client, it looks as if even home users could set up small virtual worlds on their own, in the same way they currently set up web pages. If that happens, virtual worlds will really take off.

There has to be a catch, right?

Comments

[Jessica Mulligan]

1.

The only gotcha I see upfront is that not one of these people ever built an MMO before deciding to build a toolset for them.

So, they may have something, but I suggest plenty of due diligence; until you've done it and run the game live, you really have no idea of the problems and issues. Expect holes, :D.

[Julian]

2.

The only catch I see is a further increase in the self-referentiality of game research... but that may be a good thing. I for one can't wait to build a world according to my own theoretical bias. I think I'll call it Narrat.

[magicback (Frank)]

3.

I think that this goes along with the idea that MMO clients will be the next web browser.

The don't necessary have to build a perfect platform, they just have to open it up and rely on the community to build it up.

They'll make money hats via companies paying licensing fee to put their MMO OS on mobile phones, consoles, etc.

At this that's the direction I would go.

Three cheers and let the exploration and experimentation begins!!!

Frank

[Mike "Salvator" Sherman]

4.

I think the downside is the lack of "names" associated with it. Where are the big Mud-Dev names working on this suite? Are we suppose to assume they got it right?

[Punisher2K]

5.

Given the recent history of some of those "names" I'm perfectly ok with it not having them. All to often a MMO developer gets into a mindset and can't let that mindset go. Some fresh blood is a good thing.

[Richard Bartle]

6.

Jessica>The only gotcha I see upfront is that not one of these people ever built an MMO before deciding to build a toolset for them.

Yes, although that goes for most of the other developers of free engines too, of course. I don't know if Multiverse drafted in any consultants to advise them, but I do know they read your & Bridgette's book so that ought to do just as well, heh heh.

Magicback>I think that this goes along with the idea that MMO clients will be the next web browser.

Yes, they have a single client that works for all virtual worlds produced using their software. It could be argued that a bespoke client will always be classier/faster/prettier than a one-size-fits-all client, but that's immaterial if everyone has the generic client installed already.

Richard

[David Hamilton]

7.

There's another option worth mentioning on the low end of the scale - check out:

http://www.prairiegames.com/games.html

Their minions of mirth engine is open, cheap, and easily extensible using tools that will be familiar to quake engine modders, the back end is accesible via python, and the server code comes with the purchase (~$25). This is the easiest of all the options mentioned to get up and running with and begin modifying.

[Jessica Mulligan]

8.

Richard:
<< Jessica>The only gotcha I see upfront is that not one of these people ever built an MMO before deciding to build a toolset for them.

Yes, although that goes for most of the other developers of free engines too, of course. I don't know if Multiverse drafted in any consultants to advise them, but I do know they read your & Bridgette's book so that ought to do just as well, heh heh.>>

If only it was that easy, :D.

[Mike Sellers]

9.

I think this is a great development for MMOs and MMO developers -- commercial, academic, and indies/wannabes. Jessica is correct that careful due diligence is required but, having met with these guys, I'm optimistic. IMO Multiverse, Emergent">http://www.emergentgametech.com/">Emergent Game Technologies, and Kaneva are the current leaders in this area for serious developers (commercial or not), each offering a different blend of the necessary tools, components, and expertise (each of these three, at least, have good people and seem to know what they're doing). I suspect this may lead to a new market segmentation, but it's too early to tell. The other providers mentioned here each have some sort of show-stopping flaw: poor content integration, narrow gameplay definition in the underlying tools, non-MMO networking capability, huge gaps in their toolset, high price tag, etc.

I think the real significance of this trend is going to become clear as the quasi-commodification of MMOG components emerges and we see an increased focus on content and gameplay. Several years ago, most game makers saw no realistic option but to create their own 3D engine to remain competitive -- a risky, difficult, and expensive process that sucked resources away from gameplay and other areas. Now, few developers choose to take this task on internally as there are multiple solid 3D renderers/game engines available.

In the same way, I think we're beginning to see that beyond 3D, MMOG infrastructural systems from billing and networking to chat and content management can be separated from the heart of MMOG development, just as 3D has been separated from the rest of game development.

As Multiverse, Emergent, Kaneva, NeL, or some these other groups begin to provide technology packages that let MMOG developers focus on, well, MMOG development, this will be a huge boost to our industry. I look forward to seeing a wild and woolly bunch of odd and terrific games (commerical and academic) appear over the next few years, our own little Cambrian explosion.

[ron meiners]

10.

Agreed, I think the potential for an explosion in innovative game design is really exciting. Low barrier to entry means much more experimentation by all those young capable people that are otherwise scrambling to figure out how to fit into the system. This should be a much better use of their time.
Actually I sort of see this as the first steps in a new wave of game design (so to speak) - or a return to focusing on game and story elements from the wanderings in technology and finance that have driven the art for the last years.
And yes, I'm already thinking about what might be fun to try.

[Chas]

11.

As mentioned, we have to all be a little wary as we see this develop, but I'm most interested in the exchange-type service where developers can swap components:

Have ideas for a set of guild management utilities that takes that part of the game to new levels, but not a whole system? Find someone willing to use it. Have a political-modeling system you wanted to try? Put it up there. Your own twist on ingame economies? Ditto.

It seems many of us have our own specialties and interests in virtual worlds- this could give us the ability to focus our efforts in the arenas we specialize in.

[Peter Edelmann]

12.

Is there any information on licensing besides this vague little blurb?

[Matt Mihaly]

13.

I think a LOT of caution is warranted. This whole thread could have taken place in 1990 as this happened in MMOs before, around 1990 when the text codebases like DIKU started coming out. Did it let lots of people make text MMOs? Sure. There are about 1500 MMOs running on a primarily text interface. 98% of them have about 5 players and are nearly identical to each other.

To run worlds of the size that the average hobbyist will attract, you don't need anything more than Neverwinter Nights really. I can't say I see how academics, for instance, will particularly benefit from Multiverse. If you just want a cheap way to create a virtual world to study, text has been available for a decade and a half. Yes you won't get many users, but then, you're not going to get many users with a nearly budget-less graphical MMO, and you'll have far less content and far less depth due to the cost of producing the models/textures/animations. Far less ability to actually produce something interesting to study.

Mike Sherman wrote:

I think the downside is the lack of "names" associated with it. Where are the big Mud-Dev names working on this suite? Are we suppose to assume they got it right?

I unsubscribed to mud-dev awhile ago, but if I recall, Blizzard didn't participate at all and managed to produce a product that kicked the living sh*t out of every game made by the "Mud-dev" crowd put together.

I guess my biggest reasons for not being excited about this boil down to two points:
1. On the scale we're talking about (ie, presumably, small indies or hobbyists), the technology side of things is not particularly complicated or difficult. They can't afford to create the content to back up a high-end game, so there's no need for all the flash.
2. The difficult parts - polish, content creation, and unique selling points - cannot be effectively middle-wared, so the majority of the challenge is still there.

Have ideas for a set of guild management utilities that takes that part of the game to new levels, but not a whole system? Find someone willing to use it. Have a political-modeling system you wanted to try? Put it up there. Your own twist on ingame economies? Ditto.

Well, if enduring a flood of low-quality graphical MUDs with nearly identical feature-sets is appealing.....

Good game design is not on a "black box" system. You can't just swap an economic system out for one that was developed for another game with different baseline expectations. Particularly in a virtual world, integration of the various systems is key, in my opinion at least.

--matt

[Mike Sellers]

14.

Matt said: This whole thread could have taken place in 1990 as this happened in MMOs before, around 1990 when the text codebases like DIKU started coming out. Did it let lots of people make text MMOs? Sure. There are about 1500 MMOs running on a primarily text interface. 98% of them have about 5 players and are nearly identical to each other.

It's significant to me that in the past fifteen years we haven't already seen a replication of the proliferative success of LP/DIKU and other text variants for graphical games. I think this is probably been because the various technological elements of a graphical MMOG have been so difficult, so much a "black art" that developers (mistakenly IMO) saw these as part of their commercial advantage. Multiverse (et al) is taking the tack of lowering the barrier to entry to as close to zero as possible, which is the exact opposite of the way it has been for graphical MMOGs.

Will this result in an explosion of derivative, cloned games that are never finished and have only a few people in them? I expect so. But I suspect that at the same time we'll see two other valuable things happen: first, this will enable a new generation of developers to cut their teeth on a real MMOG system rather than creating mods for shooters -- consider the successes that have come out of the modding community, despite the many lousy/unpopulated/never played mods out there. Second it will enable new/indie developers to try out ideas that would otherwise never see the light of day in a "regular" MMOG project.

We've all decried the narrow, derivative, in-bred nature of MMO design. The risks involved in creating an MMO require that designs stay with the tried-and-true; innovation is dangerous and risky. Well, if you remove that risk, what happens? Sure you'll get a ton of derivative half-baked games... but my guess is you might also get a few killer games that would otherwise never have come to fruition. The key for success for Multiverse, Kaneva, Emergent, etc., is to have enough high-profile successes to offset the sea of dorm-room projects that never go anywhere (this points out a critical difference between 1990 and now too: the market is orders of magnitude larger, thus making a commercial play like this tenable).

On the scale we're talking about (ie, presumably, small indies or hobbyists), the technology side of things is not particularly complicated or difficult.

I disagree. Unless you're willing to go for text-based worlds (which, frankly, most of us and any players we'd attract aren't), then the technical hurdles to make a viable MMOG are huge. There are freeware/open-source solutions, but they're buggy and poorly documented -- you can end up spending all your time chasing down someone else's obscure bugs and hidden assumptions. There have been a few low-cost solutions like Torque, but these are clearly not meant for MMOs, and require a lot of detailed knowledge and rework to make them applicable.

[Indies] can't afford to create the content to back up a high-end game, so there's no need for all the flash.

I think that's the point of the Developer Marketplace that Multiverse is trying to put together. This sounds like a for-profit version of hugely successful Sims Exchange, and could be a key ingredient to success with (and for) this platform.

The difficult parts - polish, content creation, and unique selling points - cannot be effectively middle-wared, so the majority of the challenge is still there.

If this middleware + marketplace model works, then this could enable developers to spend the bulk of their time on these difficult parts rather than having to fiddle with tedious technological concerns that don't add value to their game. It might also allow smaller developers to create viable commercial games that don't have to be multi-million dollar monstrosities to be successful -- meaning they can focus their efforts on gameplay and polish without having to employ an army of artists and programmers.

Like I said before, I'm optimistic about this development. There's a lot left to be seen -- no pudding yet so no proof. But I suspect we may look back on this in a year or so and see it as a major sea change in how we look at MMO development and ultimately the MMO market.

[David Reim]

15.

Mike said: IMO Multiverse, Emergent Game Technologies, and Kaneva are the current leaders in this area for serious developers (commercial or not)

I'd have to add BigWorld. Obvious disadvantage is it's commercial-only pricing

[Matt Mihaly]

16.

Mike Sellers wrote:

I disagree. Unless you're willing to go for text-based worlds (which, frankly, most of us and any players we'd attract aren't), then the technical hurdles to make a viable MMOG are huge. There are freeware/open-source solutions, but they're buggy and poorly documented -- you can end up spending all your time chasing down someone else's obscure bugs and hidden assumptions. There have been a few low-cost solutions like Torque, but these are clearly not meant for MMOs, and require a lot of detailed knowledge and rework to make them applicable.

A Tale in the Desert. Underlight. Runescape. Habbo Hotel. None of these are text and they were all put together by an extremely small team initially without the benefit of something like Kaneva or Multiverse. Granted, the first two aren't particularly commercially successful, but the latter two certainly are, in a very big way. Tale, Underlight, and Habbo also fall way outside the Diku-derived gameplay that dominates most of the big commercial players.

Anyway, I see your point about giving the modding community the ability to play in the MMO sandbox rather than just the FPS sandbox, but I'm not sure I buy the idea that this really allows people to try things they couldn't before, insofar as text allows experimentation design-wise far cheaper than graphics will, aside from experimentation that requires 10s of thousands of players. But, you're not going to get 10s of thousands of players without a serious budget for graphics anyway though, in which case you're likely to be less willing to actually try something innovative.

I guess we'll see what happens. I'd tend to think that a company our size is the ideal target for something like Multiverse or Kaneva's commercial aspirations, but I just don't find them compelling as solutions. That may just be me, and I may, of course, be dead wrong.

--matt

[Michael Chui]

17.

To be fair, Matt, I was working on my design for a MUD-style game, fully intending to be textual, when I hit a snag that I realized could only be overcome by switching to graphical. At which point I threw up my hands and ditched the project, because there was no way in hell I'd be able to find the time to make a graphical game when a textual one would have been a massive drain anyways.

There's a knowledge barrier in the technological side of things, and if you can't surmount it for whatever reason, you're denied entry.

[Matt Mihaly]

18.

There is a knowledge barrier, of course, but my point was that the biggest barrier, by far, is the content. I'm not suggesting Multiverse or Kaneva don't make things easier (though I would suggest that they do not make sense to use for a real commercial project). I'm just suggesting that this sudden jubilation sounds to me like hype and that I don't expect to see a flourishing of serious hobbyist graphical MUDs suddenly, much less financially successful indie graphical MUDs based on their platforms.

--matt

[Mike Sellers]

19.

But, you're not going to get 10s of thousands of players without a serious budget for graphics anyway though, in which case you're likely to be less willing to actually try something innovative.

Except that as you noted, Runescape and Habbo Hotel both did (and both started with 2D representations too). I'd view all four of the games you mentioned as notable exceptions under the current method of making MMOs -- and uncommonly patient ones at that -- but as potential exemplars under a low-threshold middleware approach. That is, I expect to see a lot more than just a few sparse examples like this when the technical obstacles to making a graphical MMO have been largely removed.

BTW, I suspect a company like yours might well benefit from tools like Multiverse's or Kaneva's, but you'd have to decide whether the transition to 3D and the replacement of tech you already have in place would be worth it to you and the potential bump in players you might get. For others who haven't yet invested in the infrastructure you have, it's an easier decision.

[magicback (Frank)]

20.

Most technological advances has 1) reduce barrier of entry and 2) experience gradual adoption.

This doesn't solve the issue of content creation, which is a key component of a successful MMO, but at least it will allow people to try their hand at this.

Now most will not go beyond the hobby stage, but a few will take the lesson learned to their new jobs or next venture and succeed there.

I see it more as a good tool to train aspiring MMO developers. Perhaps, these tools will now allow content creators to participate. For example, an artist can create an surreal environment that is nothing but an art exhibit. Of course SL got that market already, but a college class can use this as a canvas for their school project :)

On in this sense, it is all good.

Frank

[Matt Mihaly]

21.

Mike Sellers wrote:

Except that as you noted, Runescape and Habbo Hotel both did (and both started with 2D representations too). I'd view all four of the games you mentioned as notable exceptions under the current method of making MMOs -- and uncommonly patient ones at that -- but as potential exemplars under a low-threshold middleware approach. That is, I expect to see a lot more than just a few sparse examples like this when the technical obstacles to making a graphical MMO have been largely removed.

Chuckle, got me there alrighty. They did indeed grow without large graphics budgets. I don't see that "uncommonly patient" is relevant though. They put together great products. It took time. I hope nobody is expecting to whip out an MMO that's not a piece of junk overnight!

BTW, I suspect a company like yours might well benefit from tools like Multiverse's or Kaneva's, but you'd have to decide whether the transition to 3D and the replacement of tech you already have in place would be worth it to you and the potential bump in players you might get. For others who haven't yet invested in the infrastructure you have, it's an easier decision.

Well, our tech would be suitable for small scale graphical MUDs (with modifications of course), but it's not for multi-world/shard games. Small scale graphical MUDs on the order of our text MUDs are not going to do nearly as well either. Players are simply willing to pay more for text MUDs than graphical MUDs, at that scale at least.

So, in our case at least, the technical architecture we already have is pretty irrelevant. It's the experience in creating it that (hopefully!) carries over, not what we've done before. The reasons it's really unlikely we'd decide to use something like Multiverse or Kaneva commercially are rooted largely in not wanting to wed ourselves to companies with no track record and in not wanting to tie ourselves to a technology whose use requires paying such massive backend royalties.

I suppose that if their architecture is demonstrated to both make sense and to actually work, it's largely going to be back to the typical consideration: risk vs. reward. I have a high tolerance for risk, and so we'll be developing royalty-free technology from a combination of off-the-shelf and internally rolled solutions. I accept other people may not be interested in the risk or able to develop/pay-for-development-of their own tech, obviously.

Something did occur to me that makes Multiverse(and kin) different from the free codebases from which 99% of text MUDs are derived (and boy can you tell): The free codebases come with restrictions on commercial use in some cases, although it's widely and loudly alleged that numerous text MUDs are violating those restrictions. It's possible that we'd see a lot more commercially successful text MUDs without that restriction and perhaps that difference will end up making something like Multiverse actually create a more viable indie MMO scene vs. a purely hobbyist MMO scene.

--matt

[Already Done]

22.

Uhhh,

http://www.crystalspace3d.org/tikiwiki/tiki-directory_browse.php?parent=1

anyone?

The value of these worlds are either brand or community.

WoW had both. SecondLife has a community. Multiverse has neither.

[Peter Edelmann]

23.

Matt > The reasons it's really unlikely we'd decide to use something like Multiverse or Kaneva commercially are rooted largely in not wanting to wed ourselves to companies [...] tie ourselves to a technology [...]

I agree that the lock-in to proprietary technologies should be front and centre, whether we are talking about commercial projects like Matt's or non-commercial/educational ones. MOOs became a popular choice in educational circles because of the very liberal (open source-like) licence, and the ability to maintain, change and redistribute the code as needed - regardless of one's relationship to Xerox (or whether Xerox still existed). I hope to be pleasantly surprised when I see the licence for Multiverse, but for now I would be very wary of planning a serious educational/non-commercial project based simply on a "free access" marketing strategy.

[Avi Bar-Zeev]

24.

For what it's worth, I've talked to a number of companies who want to be in this space, going back ten years (not too many lately, as I've been doing other things). Most of them had little or no clue as to the greater set of challenges (LindenLabs being the notable exception). And I'm not even talking world-design issues, to which I'd defer to the notables on this site.

The business model here seems like it could work. In fact, if I had $6M in my pocket, I'd be tempted to do something similar. The big gotcha is a market for resuable art assets can't (IMO) work with static assets. They need to be inherently customizable (which is what I've actually been thinking about lately...)

But as others have said, it's the execution that counts. The screenshots don't give me much confidence (mostly hand-drawn art, from what I saw). And my experience with people who tout their vast experience with "enterprise solutions" is they assume having a website that can handle 1M users without cracking is similar to handing even 10K low-latency battles in a real-time 3D app. One company was adamant Java was the way to go, since it is "so scalable." IP over Pigeon is fairly scalable too (if you don't mind the big per-pigeon time-multiplier), but the I wouldn't use them for an MMO.

The other red flag is four co-founders. I've seen that work wonders for cohesion...

But I do wish them luck. I'd love to see this space take off, and I'd love to build worlds without having to write the damn code each time.

[magicback (Frank)]

25.

Avi,

In regards to reusable and customizable art assets, what do you think about the procedural process being used in Spores? Still needs craftsmanship, but 80:20 should work.

Maybe it would be good to stick that $6m venture capital in developing tech for this area. There probably more money to be made in this area.

Frank

[Richard Bartle]

26.

Matt Mihaly>I can't say I see how academics, for instance, will particularly benefit from Multiverse.

I'm part of a consortium bidding for an EU grant for a couple of million Euros to create a virtual world implementation of European fairy tales (that's academia for you). I don't rate our chances of success all that highly, but if we do get the money then I'll be knocking on Multiverse's door the next day.

Richard

[Avi Bar-Zeev]

27.

Frank> In regards to reusable and customizable art assets, what do you think about the procedural process being used in Spores? Still needs craftsmanship, but 80:20 should work.

I think, as usual, Wil Wright is way ahead of the game. Procedural planets are/will be big soon. Procedural everything is interesting.

But the bigger/more important problem, IMO, is how to combine fully procedural object generation with intuitive customization for achieving artistic (of the human variety) results.

For example, I can write some code to generate arbitrary skyscrappers. Now, try to have a designer (or end-user) adjust the model in an easy way: "make it taller" is easy, but how about "more art deco, less gothic." How do we encode those qualities in knobs and dials?

If you use random or genetic tweaking of the parametric knobs (as I imagine Spores does), you largely bypass this problem, which is very clever, but doesn't work as well in other contexts, like intentional user-directed world-building...

Anyway, That's what I'm thinking about now. And, yes, if anyone has $6M...

[cube3]

28.

www.thex3dxperience.com

the online realtime 3d open standards portal to worlds.....TODAY.

enjoy.

[Corey Bridges]

29.

Hi, everyone. First, I want to say how gratified the Multiverse team is that TerraNova broke the news about us, and that you were the first community to really start analyzing our ideas. Thanks for the vigorous discussion.

BTW, just to give you an update: within one day, well over 1000 people, many representing larger dev teams, registered with us to be early developers on our beta platform. We can only support a small fraction of that number in our early platform beta, but we'll eventually make room for everyone in the months ahead.

I hope you'll forgive me posting a note that's blatantly about our company, but I figure it's on-topic for this discussion. I want to reach back to the start of this thread and comment on Jessica's point:

The only gotcha I see upfront is that not one of these people ever built an MMO before deciding to build a toolset for them.
So, they may have something, but I suggest plenty of due diligence; until you've done it and run the game live, you really have no idea of the problems and issues. Expect holes, :D.

She's 100% right.

We've heard that from all the developers who have tromped through our offices over the last couple of years to examine what we're building. I think it was probably Andy Tepper who was the most compelling: "You absolutely have to build a game on your platform. No doubt about it. That's the only way you can really know the pain your customers feel. You'll know if you solve that pain."

So that's why we're building our own MMOG. "Kothuria: The World's Edge" is not only a proof-of-concept to you, the developers, that our technology platform works; we also hope that it's our bona fides that we do, forgive the expression, "feel your pain." (And you want pain? Let me tell you about my pipeline headache. Oy...) And finally, because our solution enables the creation of a network of MMOGs and other virtual worlds, we'll use Kothuria as a way to start attracting consumers. (Which, we hope, makes our solution more attractive to developers. Which then attracts more developers, and so on. Internally, we call that virtuous cycle "the flywheel.")

Don't get me wrong--our core business is not to develop games. We're platform guys, through and through. From Borland to SGI to Netscape to Multiverse, our calling has been to build platforms that let OTHER people make wild new things--things no one had ever even thought of before.

Another point on the topic of outsiders building technology for an ultra-specialized industry:

It's worth noting that 10 years ago, when all of us were at Netscape, we were building technology to be used by the world's top banks, publishers, and, uh, pornographers, and we got the same comments, at first. "No one from outside of the [banking/publishing/whatever] industry could possibly build something that we could use." That worked out pretty well, and we still aren't bankers, publishers, or, uh, pornographers. Well, okay, some of us did dabble.

In banking! Come on, get your heads out of the gutter...

And naturally, this sort of platform-creation isn't done in a vacuum. The industry veterans we've met with over the last couple years have provided us advice and feedback; data to allow us to confirm our strategy and make course corrections when appropriate. (And we still have many mistakes ahead of us, I'm sure. But we are trying to be lean and flexible enough to correct those quickly, too.)

But the proof of the pudding, as Mike Sellers said, is in the eating. Early developers will get a chance to see our tech, but they'll be sworn to secrecy. When we release our platform into open beta in 2006, then the peer review process should begin in earnest.

Thanks again.

[Ilari Kajaste]

30.

I don't have much knowledge on the subject, but it might very well be that the Narya library by Three Rings Design (who brought us Puzzle Pirates) is worth a mention here.

It can be found at http://threerings.net/code/narya/ and the short description reads: "The Narya library provides various facilities for making networked multiplayer games." As far as I understand, it can be freely used by anyone.

[Krakrok]

31.

>Avi Bar-Zeev wrote:
>I think, as usual, Wil Wright is way ahead of >the game. Procedural planets are/will be big >soon. Procedural everything is interesting.

I think the most important procedural timesaver in Spore is the characters and animation. The procedural planets are important to Spore but procedural characters and animation would be important to practically everyone as they take a greater amount of time to create.

>Avi Bar-Zeev wrote:
>But the bigger/more important problem, IMO, is >how to combine fully procedural object >generation with intuitive customization for >achieving artistic (of the human variety) >results. [..snip..] How do we encode those >qualities in knobs and dials?

Bryce does a pretty good job of this. Skies, terrain, water, and textures. A novice can load it up and create some decent looking material with a few clicks.

However, other than the fact that Multiverse has licenced SpeedTree I don't see anything else on their website regarding procedural anything. They list some stock character graphics and such but if I'm reading it right they are focusing more creating the "browser", the "network", and the assets marketplace than providing procedural graphic creation tools.

[Mike Rozak]

32.

Procedural content is not the panacea some people seem to think it is. I have a lot of procedural textures and objects, and there are problems. For example:

1) Procedural textures/objects tend to look artificial, no matter what you do to spruce up the algorithm. If you do spruce up the algorithm, it's extremely slow, and it still looks fake (although slightly less so).

2) Procedural objects are inefficient for rendering. They typically have 2x-4x as many polygons as an equivalent human-generated model because humans know what polygons can be cut out without degrading the look of the model. I suspect the same inefficiency exists with textures as well as animations. This is a HUGE problem for MMORPGs which are trying to optimize their framerate and memory consumption.

3) Procedural textures, objects, and animations have a certain "sameness" about them. You can tell (at a subconscious level at least) that all wood grains produced by my procedural wood-grain algorithm are from the same algorithm, and that all my procedural trees are from the same algorithm.

[Andrew]

33.

The process of actually making an MMOG is a massive prospect. The next step will be using this for open source MMOGs.

[Richard Bartle]

34.

Corey BRidges>I want to say how gratified the Multiverse team is that TerraNova broke the news about us

We only broke the news first because I happen to live in the UK and my day starts several hours earlier than yours. Otherwise Daniel Terdiman would have been first with his CNET article.

Glad to hear you've had over a thousand responses. Let's hope you can build up some momentum from that.

Richard

[Mike]

35.

This will lower barriers to noncommercial MMOG development, and raise standards for commercial MMOG development. Look at what Mugen did for 2D fighting games and RPG Maker did for RPGs.

[Jordon]

36.

hello everyone this is a really cool website

[chris price]

37.

RE Comments re procedural code re MMOGs

My passion and recent own-time development is precisely the
point of making procedural code (perl-based for interactive debugging,
lists of lists, avoidance of OOP's type complexities)

is that large virtual worlds cannot be achieved with humans clicking
on 2d screens trying desperately to make 3D 'real' objects, and placing decals
on them.

parametric, recursive, persistent databased code is needed to build complexity, build non-human interpretable nested networks of linkages, LOD, etc.

Reactions to prev post:

+ procedural code will be as real as the design models of the objects
being looked at. A knob that has 'gothic' on one end will require
design of geometry manipulation (/ratios/sections/systems selections),
e.g. search on queen mary houses should come up with parametric
code projects.
+ efficiency of polygon production totally irrelevant given the staggering
growth of GPU's plus LOD nested networks will make the billion polygon
reality at all levels of zoom.
+sameness will go then decals can be placed using a procedural database
that will deliver a texure as fitting and varied as required.

I note that a lot of the scripting that exists in most animation/modelling packages (when affordable) are for customisation of the actions doable
with the package. The parametric coding movement that started with 80's CAD
packages seems to have retrenched to these interface scripts- a great pity
because the design needed to make the systems that underlie gothic knobs
is great indeed.

On the current tack of the Multiverse discussion- their presentation is
woefully short of detail. A white paper is needed to showcase their technologies
not just a list of plugin technologies supposedly covering vast topics as physics
and 3D (which combined alone explode into too numerous issues).

[chris price]

38.

RE Comments re procedural code re MMOGs

My passion and recent own-time development is precisely the
point of making procedural code (perl-based for interactive debugging,
lists of lists, avoidance of OOP's type complexities)

is that large virtual worlds cannot be achieved with humans clicking
on 2d screens trying desperately to make 3D 'real' objects, and placing decals
on them.

parametric, recursive, persistent databased code is needed to build complexity, build non-human interpretable nested networks of linkages, LOD, etc.

Reactions to prev post:

+ procedural code will be as real as the design models of the objects
being looked at. A knob that has 'gothic' on one end will require
design of geometry manipulation (/ratios/sections/systems selections),
e.g. search on queen mary houses should come up with parametric
code projects.
+ efficiency of polygon production totally irrelevant given the staggering
growth of GPU's plus LOD nested networks will make the billion polygon
reality at all levels of zoom.
+sameness will go then decals can be placed using a procedural database
that will deliver a texure as fitting and varied as required.

I note that a lot of the scripting that exists in most animation/modelling packages (when affordable) are for customisation of the actions doable
with the package. The parametric coding movement that started with 80's CAD
packages seems to have retrenched to these interface scripts- a great pity
because the design needed to make the systems that underlie gothic knobs
is great indeed.

On the current tack of the Multiverse discussion- their presentation is
woefully short of detail. A white paper is needed to showcase their technologies
not just a list of plugin technologies supposedly covering vast topics as physics
and 3D (which combined alone explode into too numerous issues).

[genericdefect]

39.

How did independent film succeed? Certainly not by owning their own distribution franchise. They relied on the niche distributor networks that already existed. The same lesson applies for the backend of any multiuser project.

Small communities for no-budget projects can spring up quite easily if much or all of the infrastructure is ported to the client. That's not a new idea, but I suspect it is the only one that will ever work correctly.

As for creative control over such a project.. the only effective option seems to be to give each participant client dynamic control over their participation with other individual clients. This eliminates all possible authorial input from anything except your orthodox masses.

[Alex]

40.

Now, True Indie Approach, anyone?:

Large commercial games aside, : how can we develop usable 3d MU games/systems for “normal” WWW user or for education without burning millions?

I've been doing MU 3D applications for the past 10yrs for industry and education – all with 100% open tools and all with pretty simple architecture – web applications with 3D virtual worlds & avatars (OpenGL or VRML/X3D).

1.NEED TO RELY ON OPEN STANDARDS:
There is a lot of good work going on in Web3D consortium developing open 3D web standards – for games, simulations and more. There we basically look at «VRML on steroids» (in XML syntax) that would give high-quality 3D graphics to the open world. There are new browsers, tools etc. rolled out...

BTW – read somewhere that City of Heroes is actually VRML in disguise – so much for the scary-game-engine-issue we all spin around...

2. DEVELOPMENT HAS TO BE EASY & DISTRIBUTED = DEMOCRATIC:
Those who can draw or model in clay will find it relatively easy to model... I should post a tutorial for sceptics – and there ARE free tools around...

With all respect to the pro modellers: it takes me just about 2 hours to get high school kids going in modelling own 3D models/spaces that can be plugged into multiuser online games...

BTW- I am NOT impressed by meshes from WOW, - how many of us are? - And I am not sure we need even that much detail either – especially for non-fairytale uses – like education, storytelling...

Those who can write – let us just write the story and build games bottom-up ;) How about (grand?)-parents developing storytelling applications for their and other kids and visualising them in an open web scripting environment (XML+ x3d?) – and who said we need zillion of simultaneous users?

AND we can well have an internal market in there too – why not...

I am thinking more “3d – game – blogs” – maybe EVEN in normal, not fairytale setting (let us let elves and monsters rest for a while)

Scripting
It has to be dead simple and open – XML configuration files dynamically converted into 3d worlds, - I'd prefer dead-simple, but open solution, - and it is all doable, - knowledge & hype barrier (“KHB”?) has to be melted...

3. PUBLISHING
It should be truly FREE – not shards run from some commercial server, but truly distributed – published by the end-users – “3D web pages” -.and if you need to sync animations etc. you do not need zillion users in one space... For many uses, groups of 10-20 is actually enough ;)

When I rolled out a prototype of mine, I will be glad to share with anyone interested

Cheers
Alex