May Contain Nuts

Yeah, I’m at it again. Be afraid. Be very afraid . Also please note that for as much as I go on about this, I really would like to see Cyan do Something Completely Different, rather than staying chained to the boat anchor that is Uru Live.

There are several things that have recently motivated me to further reflect on how to build a better Uru, though two really stand out for me. The first is the fact that I’ve been poking around in Second Life for a while now, and have gotten a feel for how the game’s user-editability works in a broad sense. The second is that the platform I’ve been targeting all of my thinking toward, Unity, is now free for the basic version of the development IDE, which eliminates the barrier-to-entry concerns I had for player-created content on that platform.

To focus briefly on Unity’s strengths, it’s a rock-solid 3rd party engine with its own extensive QA testing department, meaning that support and maintenance of the engine itself are no longer concerns, which makes the cost overhead of development considerably smaller (programmers are not cheap). It has full support for DirectX and OpenGL pixel shaders including bloom, blur, and a whole host of others. It will run natively on Windows, as well as Intel and PowerPC-based Macs, which means no more Crossover or Cider strangeness in the Mac port, and increased accessibility to the product for players with older Mac systems (I’m willing to take any users I can get at this point). It supports live asset streaming from server to client, which means that assets can be retained on the remote server and only downloaded when the client needs them. Considering the bandwidth requirements of most MMOs anyway, these downloads should be fairly speedy, and should even be able to be handled asynchronously, so the remaining content can load while you’re exploring the initial spawn point. It natively opens 3DS MAX files (on Windows), layered Photoshop PSDs, and will import FBX files exported from MAX and Blender, in addition to a whole host of additional mesh, image, video, and audio file support. This pretty much covers all of the most popular tools currently being used to build player-created content for the Plasma engine, with the added benefit of having a documented development API and IDE with full support for every possible feature out-of-the-box.

All of these factors combine to position Unity as a truly capable technology that can easily supplant Plasma in practically every way. I give major props and kudos to Cyan for developing their own graphics engine and server technology in-house to do things in realtime that were unimaginable when they started Uru’s development over 10 years ago, but truth be told, it’s decidedly buggy and lag-ridden in ways that I don’t think open-sourcing the project will ever adequately solve (or at least, ever solve in a reasonable timeframe). Plasma has had a good run, but I think it’s time to move on to something better.

On top of all this, I’ve been reflecting for a while on how to bring some of Second Life’s openness into Uru without destroying the core of what Uru is, or just turning it into a Myst-themed Second Life clone. When players can go pretty much anywhere they please, and do basically whatever they want, as well as build almost anything they can imagine, with a minimal outlay of real-world cash on their part, Uru’s restrictive and largely fixed, scenic environments seem much more sterile and uninviting by comparison. This puts a further degree of importance on the developer-driven storyline, as player-developed concepts are limited to what can be done with only KI notes and unmodified in-game photos as props, and it’s somewhat surprisingly difficult to get people to use their imagination to invent unseen, behind-the-curtain locales for player operations when the rest of the game is so fully visualized. Thus, when the developer’s storyline isn’t going anywhere, or isn’t moving at a pace that can keep up with players’ demands for new material, the game suffers greatly.

After spending a really long time reflecting on what I think makes Uru a great concept, as well as working hard to incorporate some of the most demanded aspects of gameplay throughout Uru’s troubled existence, I think I’ve arrived at a model that can be used to build a better, more potentially successful Uru Live by creating a more player-friendly world built on stronger underlying technologies. Here’s what I’ve got.

User-placeable objects. The game wouldn’t have an object editor like Second Life’s, which is really super complex, but players would have the ability to place arbitrary objects around the game. Certain limitations would be imposed to retain a certain degree of “realism”, so objects like papers could only be placed on designated surfaces like the ground or on cork boards, rather than allowing them to float in mid-air. Players could use this system to drop short notes, full-on notebooks, images, and even arbitrary objects from a global object library into the game. Notes, notebooks, and images would follow a Second Life-style modify/copy/transfer permissions structure, so players would be able to configure whether others can edit, send, send copies, pick up, or pick up copies of the object in question. Arbitrary objects from the library or from a player’s personal collection would have only copy/transfer permissions since there would be no way to edit them in-game.

To further protect certain areas of the game, regions may be configured by the developer to disallow the dropping of objects onto them (the ability for a surface to receive dropped objects would be an explicit opt-in flag in the back-end). Player-owned areas of the game, such as rooms in the D’ni City, may have their structures configured by the owner to determine where things can be dropped by non-owners.

Asynchronous, lazy loading of content. Perhaps one of Plasma’s largest bottlenecks next to physics objects is the way in which it loads content. Everything seems to be loaded synchronously, so in large areas with lots of players, it takes a considerable amount of time before the game gets to a state even barely approaching useable. By decoupling content loading from the main rendering thread and making it asynchronous, players can begin to explore an area before all of the content has finished loading. This is especially prudent for objects like avatars and player-dropped content, but could theoretically be extended to cover the environment itself as well.

More user control of the game’s visual quality. This is a simple thing, but it would make a world of difference to many players. Give them the ability to reduce the visual complexity of the game by reducing the number of avatars their system renders at a time (X nearest, polled intermittently), and by reducing the draw distance for objects such as avatars and player-dropped content. Besides the general improvements to frame rate that would come from migrating to the Unity engine and cleaning up older, more inefficiently-assembled areas of the game, giving players control over the draw distance would likely have a marked impact on performance on lower-end machines, where even a one hundred polygon low-LOD avatar object would add strain to the rendering system. This is a point where we would have to concede “absolute realism” for overall quality and playability, but I think it’s an important and valid trade-off.

The ability to upload content into the game. This one’s going to stir a few pots, I suspect, but frankly speaking, there is no way to make Uru what players want it to be without making this possible. Having Cyan be the gatekeeper on every item that goes into the game is impractical, and there’s already precedent for user-created material being directly added into the game in the form of KI notes, which can be freely shared, edited, and posted publicly. Provided there is a method for reporting and removing offensive content, I think an honor code-driven system would work fine in Uru for the vast majority of cases. Players should be able to upload their own images into the game for use as images to share, and for use on clothing as extra texture options, without needing to go through Cyan for approval first.

I’m unsure of how (or even whether) a Second Life-like system where uploading content costs a marginal amount of real-world cash would work given Cyan’s traditional eschewing of micro-transactions for extra material, but when it comes to the storage space needed for uploaded text and images, there should probably be some way to defray those costs. The rest of the gaming industry, and Second Life in particular, has illustrated that micro-transactions are a viable method for minor gate-keeping and expanding a player’s available content for a minimal up-front cost, and I think if properly structured, such a system would work for Uru, but it would have to be very carefully managed, and should be considered separately from the notion of a player-driven economy within the game where players can sell items to one another, rather than just paying to upload their own content for themselves.

Uploading actual models and textures into the game would be a somewhat different ball of wax, I think, because of the way in which Unity compiles its game assets and given the fact that we wouldn’t be providing an in-game editor for creating one’s own objects. Objects would need to be built in a modeling environment, imported into Unity, and then submitted to the developer (in this case, Cyan) for addition to the global library/libraries in batches, or to an individual player’s account for their personal use. These additions could be done independent of major content drops because of support for on-demand content streaming built into Unity.

Create an API on top of which players can build. Player-created content is obviously going to be a big draw for Uru, if only because it’s been teased at for so long and is already happening under the table in Plasma. Creating a recognized development framework for players to build their own content and integrate it into the game is an absolute must from day 1. The framework should support adding objects, whole regions (Ages etc.), and extensions to the user interface (like new KI functionality) into the game. Depending on the type of material being developed, the developer may need to act as a gate-keeper of sorts, if only to serve as the conduit through which player content is included into the game’s published assets.

Because not every player will have the ability to build their own content for any number of reasons, it’s reasonable to assume that other players may band together to create development shops which would build objects for other players. Existing Guilds such as the Writers and Maintainers may be very well-suited to this task, and there may be some way to create a development shard that is more frequently updated (or possibly can be built on-demand) so that player-developers can test their content before giving it the green light for inclusion into the release builds. Addition of content would not be explicitly subject to Guild involvement, however; if a player wanted to build something and submit it on their own, they would be free to do so.

Certain areas of the game that were originally created by the developer could even have their own additional APIs for creating player-made rule structures, enabling things like more enforceable gameplay rules for player-invented games in Jalak. Provided the technology supported it, players should be able to upload these area-specific override scripts directly to the game for immediate integration, with the obvious ability to report broken, offensive, or griefing scripts.

Give players somewhere to showcase their work. Hand in hand with allowing players to create things like their own Ages is developing a way to let others access them. There should be developer-created spaces in the game for featuring player-created content such as Ages or artwork, and players should also be able to place their own content in player-controlled areas as well. For instance, if a player owned a room or building in the City, they could place a Linking Book to an Age they had created in that room or building, which would then be access-controlled based on who was allowed to enter that space in the City.

This framework for privatized content placement could even be expanded to a more fragmented shard system, where players could lease or operate their own server, and for a stated cost per month could operate player-created content on that machine with their own rules and code of conduct. Such privatized content would require certain disclosures to be put in place for players who may stumble onto it (my first and admittedly clunky thought is to present the player with a dialog box when they click such a linking panel, containing the destination’s rules as they differ from the main area of play, requiring the player to explicitly authorize the link before continuing to the new server).

In addition, there should be central upload repositories where players can upload content from their KI such as notes, images, and marker missions, for other players to download at their leisure. Again, content uploaded to these stations should have modify/copy/transfer controls built into it so players can control the distribution of their own content.

Don’t forget the story. If Uru did all of this, and nothing more, it would essentially be the Myst-themed Second Life clone I want to avoid turning it into. However, the strength of Cyan’s games has always been the one-two punch of high-quality content and storytelling. Without these, Uru is nothing special, but without the rest of this list, storytelling and content become such a tremendously exclusive focus of the player base that maintaining a sufficient development throughput quickly becomes unsustainable. Do all this, and provide a compelling central story with imaginative and gripping environments, and I think Uru’s chances of success improve greatly.

Of course, it sounds a lot easier than it actually is, or it’d be done by now .

This entry was posted on Tuesday, November 17th, 2009 at 4:04 pm and is filed under Game Development, Games, Myst, Uru Deconstruction. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.