May Contain Nuts

“Why hasn’t Cyan released the Plasma source code by now?”

Because, as RAWA explained, it’s a long, painful process. As RAWA somewhat implied, there are very few people at Cyan who even know anything about the engine code anymore. Most – if not all – of the Headspin team they bought the engine from have since left the company or been laid off. The number of “Don’t use this, we don’t know what it does” comments in the ResEng documentation I was given when I started there speaks volumes about how much work needs to go into the engine to get it ready for release.

Further, open-sourcing the engine as it stands now faces a number of additional issues. First, I’m under the impression that Cyan wants to separate the engine code from any game content that might be tied up in it, in order to retain legal rights to their D’ni universe intellectual property and released content. Given how often purpose-built engines have game content references hard-coded into them for the sake of convenience, this may be more likely than it seems. Second, I’m fairly certain that Cyan intends to continue using Plasma after they open-source it, so it must be done in a way that doesn’t prevent Cyan from using the engine commercially in the future. Third, there’s a number of proprietary components in the Plasma engine that are the property of third parties (PhysX is a good example), which Cyan can’t release the code for. However, stripping the references to that code out of the engine would make it essentially useless.

A good parallel to draw, I think, is to Relic’s decision about 5 years ago to open-source the engine they used to create the original Homeworld title in 1999. As with Plasma, everyone at the time was mind-boggled at the fact that a AAA game engine for a best-selling title was just going to be given away by its creators. However, to this day there still isn’t an openly available version of the engine that can be used for anything besides running an extremely buggy and feature-deprived build of Homeworld, because so much of the engine got crippled when Relic ripped out stuff like the Bink decoder used for the animatic cutscenes (which weren’t released along with the engine, so until the hard-coded references to them were removed from the engine, the game would just crash because of the missing assets), and there’s a pile of assembly code that just doesn’t work very well on modern hardware, including a lot of homebrewed custom OpenGL assembly code (dubbed “RelicGL”) that was written to get bare-metal access to the anemic or even non-existent graphics hardware available in 1999. Check out the Homesource forums for a taste of what fresh Hells Relic’s engine hath wrought.

So, if Relic’s approach can shed any light on this subject (and I think it can), throwing the code out now now now isn’t going to accomplish Cyan’s goals any faster than releasing the code at a later date, and is in all likelihood actually going to slow things down even further. I know there’s a lot of code monkey geniuses in the Myst community, but Plasma is a 15-year-old monster of an application, and more eyeballs on the problem doesn’t always mean faster results.

Which leads me to…

“Why won’t Cyan let trusted community members help get the code ready for release?”

As RAWA’s noted, and as many others have mentioned, there are a whole swarm of thorny legal issues involved with granting non-employees access to a proprietary code base full of more licensed proprietary third-party software, on top of the very probable situation that Cyan doesn’t have a system in place for allowing outside access to their Plasma code repository, it’s probably in a rather outdated source control system (perhaps even Visual Source Safe *shudder*), and compiling it may also require licenses for software that volunteers would need to be given (just as an example, anyone who’s tried to recompile a C++ VS6 or VS.NET project in VS08 should know it’s not likely to go smooth). Getting all of this set up, settling the hazy legal issues surrounding unpaid labor in the US, and drafting and issuing contracts and access permissions that are locked-down to only the relevant material is probably more trouble than it’s worth, honestly. Again, remember, this is a spare-time effort that Cyan can’t afford to expend valuable resources on when they’re needed elsewhere for other projects.

I also wouldn’t be surprised if Cyan is holding onto the code to try and hammer out some additional security issues, which they don’t want out in the open for discovery when they’re also running the only (legal *ahem*) active shard of the game on the planet. Given the (admittedly long-ago) history of outsider abuse of the Myst community (such as hacking the Riven Lyst), I would understand it if Cyan wasn’t willing to expose the Uru community to another outage resulting from someone exploiting the code’s most evident weaknesses. Considering the Vault always struck me as being held together with duct tape and bailing twine, I’d be willing to bet that there’s a lot that can go wrong very easily, and again, right or not, Cyan may just want to avoid that situation if at all possible by keeping the code internal for now (and please spare me the “security through obscurity” arguments, because they never seem to convince anyone in either direction).

And now, for my own petty comment: I also wouldn’t be surprised if the Uru hacking community’s tendency to do whatever they want with or without Cyan’s permission is putting Cyan off from being willing to accept their assistance. I applaud Paradox for actually working with Mark on the Pidgin KI plugin, and that sort of approach – independent development of tools and extensions with Cyan’s permission since it’s their property – if repeated elsewhere, could go a long way towards improving the apparent lack of interest on Cyan’s part towards the hacker community, and community involvement in general (assuming the aforementioned hurdles aren’t going to get in the way).

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 .

I came to the conclusion last night that Uru doesn’t work as an MMO (shocking, I know). First of all, it’s not profitable (at least, not quickly enough to justify its continued commercial development). Secondly, its style of play isn’t very well suited to an MMO… I don’t think this is Uru’s failing, I just think adventure games in general make for pretty crummy MMOs. Not every genre works equally well when you tack “MMO” in front of it.

So I started thinking about how to make a game like Uru actually work. What I came up with is sort of a hybrid between a traditional single-player adventure game and the MMO world of Uru, with a splash of TV thrown in for extra flavor (I swear, it’ll make sense once I explain it!). Beware, those of you well-versed in Uru’s ancient history may find portions of the following explanation tiresome. Because this is a really long post, I’ve put the rest below the fold for the sake of those reading MystBlogs… (I’d also like to apologize if it doesn’t make much sense. This kept me up until almost 4:30 AM, so I’m a bit tired…)

Read more…?

Quick update on Labyrinth!…

I’ve had a number of other things taking priority over Labyrinth! development over the past few weeks, which successfully nixed the chances of getting the game released in April. Given that this summer is going to be rather busy between going to AFF next weekend and having Mysterium 2009 planning kick into over-drive very, very soon, I don’t know if I’ll be able to wrap the game up by the end of May, or even by the end of the summer, but I’ll keep soldiering on and giving it my best shot.

Development continues apace. Last night I worked on getting the control scheme and event handling used in the original beta (which we’ll now call an alpha, because it was really, really janky) up to snuff for a multi-level game with proper abstraction so that I don’t have to re-write code for every level.

Ran into a minor setback when physics suddenly decided it just wasn’t going to cooperate anymore, and the marble stopped responding to gravity. Nothing I did would fix the problem, so I decided to ditch the old project (which has been around since Unity 1.6.2, and upgraded through Unity 2.5… this may be the cause of some issues now that I think about it) and start a new one, without any of the legacy junk cluttering up the asset list and possibly interfering with behavior.

Unfortunately, the move to a new project has seen the return of a few glitchy behaviors in the marble collision… it’s now really, really easy to get the ball to fall through the floor, just as it was during the early days of the original alpha. Now I have to try and remember back 18 months to figure out what I did to fix that problem…

Aside from the glitchy marble collision, though, things are going quite well. The main menu has been tweaked so that it looks good at multiple resolutions (those running widescreen displays and high-res screens will see a fair amount of blank space around the main UI, but this is a lot easier for a first project than trying to dynamically rebuild the placement of every UI element based on specific resolutions, or trying to use proportional dimensions by dividing the screen width into various fractions and trying to line everything up that way). Level loading now works properly, the levels themselves have a proper pause feature built-in (it freezes the marble, decouples the mouse from the board controller, and displays a menu UI), and the start/end triggers are functioning properly.

Today, my goal is to get the scoring system built, which includes building in a timer to track how long you’ve been playing the level, and a counter to determine how many balls you’ve used. The 3-ball limit from the original alpha (as well as the infinite ball bug where restarting the game after losing would give you unlimited balls for a second try) is now gone, as we’re moving to a different scoring system with the new builds of the game. There are also a couple of additional in-level menu items that need to be added to the pause screen, further testing to ensure that the hole collision and powerup spawning/collision work properly, and a way to submit player scores to an online leader board (with in-game leader board display, ideally).

Tomorrow, I’m going to be building the Maroontown Games logo animation and integrating it into the game’s launch process (complete with skip triggers, so if you don’t want to watch the animation, you don’t have to!), and doing some more testing with higher-level boards to make sure everything works correctly. Hopefully by Sunday I can start working with the real final boards, texture and all, and be able to get the whole game linked up by the end of the day Sunday. Final assets for stuff like powerups and background scenery will be completed over the next week.

Next week, I also plan on working on audio with Oscy. We’ve got plenty of music that needs to be composed, and sound effects that need to be designed. Sound is the one place where we’re really falling down at the moment, unfortunately, because we don’t have a location or the hardware to record good foley, and our compositional tools are somewhat limited (we have GarageBand, but no instruments or midi keyboards to plug into it). Hopefully we can pull something off that’s better than what we had in the early pre-alpha builds in 2007… it was so bad it was just unusable.

Just a short development update. First, to emphasis this game’s Labyrinth-ness (as it relates to the original wooden board game, anyway), the name has changed slightly. It’s now “Labyrinth!”. How enthusiastic!

As I noted last night on Twitter, the game now has a fully-functional main menu UI. There’s a few extra bells and whistles to add in, and the graphics will probably end up changing a bit before the end result is done, but the core functionality is complete. The main menu, player selection, and level selection menus all work, and the level selector also loads the selected level and has support for locking more advanced levels until players reach certain thresholds (like completing earlier levels or hitting a minimum cumulative score).

Ash has been busy building the game boards for me, and tonight I’m going to work on designing and building the assets for some of the game’s various “power-ups” (score multipliers, teleporters, and anti-gravity triggers). I’ll also try to get the first level completely built, including its own in-level menus and indicators (like score and time). Once the first one’s done, the rest should fall into place fairly quickly, so I suspect that by Monday, I’ll have a fully-functional game that just needs some polish to make it complete.

Labyrinth! Finally! Exciting! XD

Recently, the game development IDE I use to pretend to build games was updated, and it was pretty substantial. The IDE now runs on both Mac and Windows, and while it’s always been able to build for both platforms, I could only ever use the Indie version (which is 1/10th the cost of the Professional version) to build for the Mac. This in and of itself wasn’t exactly a bad thing, but it did rather substantially limit the market I could target. The new version removes that restriction, favoring less severe (but still occasionally frustrating) restrictions like realtime shadows, post-processing effects, render-to-texture capabilities, and most live asset streaming. The practical upshot of this is that I can now reach a potential audience that’s 90% larger than it would have been before.

Now all I have to do is freaking build a game… and on that note, I fired up my long-ignored Labyrinth project a couple of days ago. Blessedly, the control scheme still works flawlessly, and the marble behavior is possibly even a bit better than it was in the older versions of the IDE (PhysX implementation improvements FTW).

My biggest stumbling block with this game has been coming up with unique board designs that are challenging without being Nintendo-hard, and that take advantage of the possibilities of a digital version of Labyrinth. Since I’ve hit something of a roadblock in the board design department, I’ve decided to just build what I have and go from there. Maybe modeling some of these boards will give me the creative boost I need to design some more. As it stands, I’ve got somewhere between 10 and 15 designs already, which I think makes for a decent low-end, low-price game. If I can work out how, I’d like to leave this thing somewhat open-ended and provide downloadable content packages for a fee, so that I can always return to this game if I need a break from another project.

So, tonight, I build Labyrinth boards. Tomorrow, I work on the game’s UI. Since the control scheme for the game is already in place (I even have server-side high score reporting, so all of the really hard stuff is pretty much done), I can hopefully get this thing released by the end of the month. Fingers crossed!

By the way, if anybody has any experience with or knowledge about selling games on services like Steam, MacGamesArcade, or Greenhouse, let me know, eh? I’d like to hit as big of a target audience as possible, and the fewer billing-related things I have to worry about, the better.

I touched on this a bit in my last post, but I wanted to take some time and go over a few (but certainly not all) of the possibilities for what we might end up being allowed to do with OpenURU, depending on how the Plasma and the Uru content are licensed.

First off, I think it’s at least somewhat likely that Cyan will release the Plasma code under a Creative Commons license, in which case the most likely candidates are Attribution, Attribution Share Alike, Attribution Non-Commercial, and Attribution Non-Commercial Share Alike (I’m not going to go into GPL, BSD, MIT, etc. because I have very little knowledge of their inner workings, and I don’t have a supremely large amount of time to devote to what is essentially a thought exercise).  The Share Alike licenses are, to my mind, the most likely of the most likely candidates, and the Non-Commercial versions seem like a reasonable certainty, but I’ve been wrong before. Any of these licenses would enable developers to take the Plasma engine, the Plasma server code, or both, and use them to build their own brand new, not-D’ni-related MMO. The only question is whether those new MMOs will be able to make a profit, as determined by whether the license is Non-Commercial or not.

None of this covers the actual content of the game, though; just the code that makes the game run. That, if it’s licensed at all, would almost certainly be licensed separately.

What I would prefer to see Cyan do is license the entire existing game’s contents under the Attribution Non-Commercial Share Alike license, or something fundamentally similar. This would enable the community to fix long-standing problems with the game’s content – from fixing minor graphical issues, to overhauling the KI, to completely revising how the game begins for new players – without running afoul of Cyan’s intellectual property rights by ensuring that the content remains under the same license. Since this license would apply only to the material that Cyan created and any derivative works that were made from it (they’d be licensing the models, not the universe), I believe (but am not 100% absolutely certain) that user-created Ages would not be subject to the Share Alike clause – treating the content as divorced from the engine powering it is a cheap but effective way of attempting to ensure that. In any case, if the Attribution Non-Commercial Share Alike license ends up not quite fitting the bill, I’m sure something could be found that would require changes made under the license to Cyan’s own content to be redistributed under the same license without requiring new Ages added by the community to be similarly licensed.

It should be noted that under this sort of license, Cyan would be creating a platform for fan fiction, but not the creation of an Extended Universe of D’ni canon. Without a specifically-defined process by which content created by the community can be approved for inclusion into the Extended Universe canon, the story of D’ni will be static until Cyan (or a licensee) is able to add to it in the future.

Since I’m all about increasing the breadth and depth of the D’ni universe, I would love to see Cyan maintain its stance on user-created canon expansions that RAWA outlined for MORE: a community-run panel would review submitted content, and approve it if it passed a set of well-defined criteria. I don’t know if the FCAL panel should necessarily retain its originally-intended composition though. What would be more flexible is a dual panel, with the GoW and GoMa in charge of overseeing the inclusion of content into OpenURU based on its stability, where such content could be added to any shard upon approval. The GoA would run a separate “canon review” panel, which would be entirely optional, but whose approval would enable the applicant’s content to be placed on an (the?) Exnteded Universe Shard, which would likely be managed by the Guilds.

(I should note that Guild approval is obviously not going to be a requirement for content inclusion depending on the shard, but I would hope that if something passes a GoW/GoMa test plan, it could be added anywhere with reasonable assurances as to its stability. Clearly, though, content is going to need to be tested before it’s added to a live shard… exactly how that happens will likely be up to the individual shard managers.)

This is, of course, all what I would prefer to have happen, because it’s incredibly flexible in what it allows, without requiring Cyan to give up creative control of their intellectual property – all derivative works would have to be properly attributed, with their content specifically (i.e. the stuff from MOUL) licensed under a Share Alike-format agreement. It sets up the possibility for both canon wonks and casual storytellers alike to have a place and a way to contribute without stepping on each other’s toes. It also makes it possible for other groups or companies to benefit not just from Cyan’s years of work on their engine, but also from the mountainous improvements that are bound to be rolled into the code by the open source community. The MMO space has never really had a AAA-quality engine be this accessible to so many people; it will be interested to see what happens in the future with Cyan taking the first step towards leveling the playing field for newcomers.

Of course, what could also happen is that Cyan retains exclusive ownership of the content from MOUL, which seems like a bit of a dick move, since it would severely hinder the ability of the community to fix some of the more eggregious problems with the game – not just technically, but gameplay-wise as well. It would require us to figure out a completely different way of integrating new user-created content too, rather than doing the “easy” thing of piling it into the Nexus, or the more visually interested thing of expanding the Library.

In such a situation, Cyan will still need to have a license in place for user-created content, because even if Cyan isn’t interested in letting players expand the D’ni universe anymore, user-created content within the D’ni universe still requires a license from Cyan because at the end of the day, you’re building off of their intellectual property and distributing it to other people (and it’s the “distributing it to other people” bit that causes problems, legally). Given the immense interest people have in adding content to Uru, I don’t think Cyan in its current state is going to be able to handle individual requests in a timely manner; a CC Attribution Non-Commercial license for the D’ni universe IP with a few additional restrictions (basically what’s on their Legal page) would probably be more than sufficient.

I, of course, have more thoughts on what I would like to see happen, gameplay-wise, in OpenURU, but for now, I kind of need to get back to work.  More later .

So, evidently Cyan is open-sourcing Myst Online. After re-reading the comments in the Spokesman Review a third time in preparation for writing this entry, I’ve picked up on a couple of things that I’m not sure others have really noticed… I’ll get to that in a minute, but first, my initial reactions.

I suspect that it’s currently one of my worst-kept secrets, but since the plan to release MORE essentially dissolved earlier this year, I’ve been working hard-core on ideas for how to build a new MMO set in D’ni (the chances of actually pulling it off without obscenely large piles of money were always very slim, but I considered it a good thought experiment at least). To say that this new announcement has drastically altered any and all of my thoughts about this little side-project of mine is something of an understatement. I may be one of the few people in the community to actually be a tad conflicted about this revelation, but then I had some pretty slick ideas for how to improve on what I saw as the game’s fundamental flaws. I’d like to discuss some of these ideas in the future in the interests of making OSMOUL a better game, so keep an eye out for that.

My very next thought was, “oh crap, what’s this going to do to the Archive?!” I initially missed the part in the Spokesman Review blog post where it says that Cyan still plans to operate the central Vault, and flipped out about the potential for a completely fragmented multi-shard insanity where no shard’s implementation of OSMOUL was the complete one, and the complete view of OSMOUL’s shards was a contradictory mess. Having now realized that Cyan intends to keep MOUL itself on one instance with multiple servers attached to it from around the world, much in the same way that MORE would have, I’m less freaked out by the prospect of OSMOUL than I was an hour ago. I have no doubt that other shards will inevitably appear, whether out of necessity or desire, but I think it’s safe to say that any official canon expansion or Extended Universe canon development will take place on the shard backed by Cyan’s Vault, while other shards will range anywhere from high-end fanfic to “just goofing around”, and honestly I have no problem with that. As it stands, Uru can most certainly not be all things to all players, and while I hope that the official shard develops quickly enough that newcomers of all persuasions can find something that interests them, I also understand that for any number of reasons, some fans might want a different type of experience with Uru as a game from that offered on the official shard.

With all of that said, I’m very much interested in finding out what Cyan wants to do about fan-created content on their shard. If the plan is to basically just run it like an open-source MORE, then I think the Guilds (myself included) ought to get back to the task of creating the FCAL Panel and hammering out a process for how content will move from a testing environment to the official shard. I hope to get the Archive back into a more active state as well, since the future of D’ni doesn’t look quite as bleak now as it did a couple of hours ago. On that note, I’m eagerly awaiting the release of Invision Power Board 3, which powers DPWR’s backend, as it should enable the site to do pretty much everything I’ve been trying to hand-code in some form or fashion over the past several site revisions. More on DPWR later, though.

Having thought this whole thing over for some time now, I’m actually rather excited now at the prospect of what OSMOUL could do for Uru. With fans able to get their hands on the code, hopefully some long-overdue projects will finally get taken care of, like an overhaul of the KI, or fully debugging the stupid doors, or the client collapsing under the weight of handling physics objects in a highly populated area (or making the client more capable of loading and rendering massive Ages intelligently). Depending on how lax Cyan intends to be with what they let us create and add into the game, maybe I could even get to some of the places I’ve been oggling over since I first read the Book of Ti’ana over 10 years ago. A complete implementation of the Descent would be beyond awesome, and getting to more of K’veer or into the Guild Hall would be super cool. At the very least, getting some of the lingering graphical glitches in MOUL tidied up would be nice to see.

To paraphrase Strong Bad, “oh, you thought there was no more Uru deconstruction butguesswhatthere’sUrudeconstruction!”

This article on Joystiq summarizing the Austin GDC panel on the psychology of MMO gamers got me thinking a bit on griefing in MOUL, and ways to try to counteract it.  By and large, MOUL was pretty devoid of griefers, probably in equal parts because of how little the game itself did to make griefing a viable activity and the general makeup of the MOUL community at large (stunningly, the number of people I had to deal with for griefing in my 3 months as a ResEng could probably be counted on one hand).  I think it’s somewhat surprising, given the somewhat poor attitude most “hard-core” gamers seem to have towards Myst, that MOUL wasn’t more of a target for people just looking to have a laugh at our expense… perhaps the 3-gig download put many of them off.

To the best of my knowledge, the only griefing tactic that was in any way inconveniencing for an individual player was Relto-spamming, wherein a person would repeatedly and rapidly attempt to share their Relto Book with another player, preventing them from being able to move away or even call for help as a result of the way Uru’s GUI was designed (Books act as modal dialogs that block access to any other UI functionality, including the KI and the game’s menu system).  There are of course other ways that players can grief each other… one such common method was sabotaging the Delin and Tsogahl door runs, but even that was typically no more than a 5-minute problem, as contacting a ResEng would usually have the person bounced to Biegalski’s Tetsonot shortly thereafter.  Other tactics were typically limited to lack of respect for personal space (intentionally walking through/standing in other avatars) and verbal diarrhea in the chat channels, again something that was usually remedied by calling a ResEng (abuse of the chat channel was also easily remedied by ignoring the offender using the in-game chat command).

Ultimately, the worst that a player could do as a drive-by griefing was the Relto-spamming (of course stalking and other such serial offenses weren’t unheard of, but were at least extremely rare during the run of the game that I was present for), and I think there’s an easy way to make sure that such actions aren’t possible in the future (I say “easy” because it’s something that would be trivial to implement if one were building the game from scratch… doing it in the current platform would probably be akin to pulling out your wisdom teeth with a pair of tweezers).

Whenever a player attempts to share a Book with another player (typically their Relto Book, but this is basically a pre-emptive removal of other Book-based griefing attempts), they will be presented with a game dialog asking the player if they want to accept the other person’s invitation to use their shared Book (in the format of “<User> wants to share their <Age Name> Book with you.”).  The sharee may then choose “Accept” or “Deny”, with a check-box to always perform the selected action for that sharer.  So, every time a new person wants to share a Book with you, you’ll see that prompt, and if it’s a one-time deal, you can be prompted again the next time you see them.  If they’re a good friend or someone you otherwise trust not to be a jackass, you can forgo the prompt and the game will skip straight to sharing the Book with you.  If you’ve been drive-by’d, you can deny the share offer, and if you’re being intentionally griefed, you can deny all further efforts by that person to share their Book with you.  At that time, the sharer would no longer be able to click on you as a sharee when in “Share Book” mode.

When this dialog appears, it will be semi-modal, in that it will block your ability to move, but not your ability to use the current chat channel or get to the game’s menu system (at the very least, access to the ResEng call screen will not be blocked).  This way, you can continue to use the chat channel to talk with those around you, and still call for help if you need to.

To deal with the possibility that this preference may need to be changed for certain people at some point in the future (either because your good friend has decided to start wearing his ass hat, or because you accidentally ignored someone permanently), there needs to be a panel in the game’s menu that allows players to manage the people on their list of sharers.  This dialog would contain a filterable list of all the people who have offered to share a Book with you, with options to set each person to “Always Accept”, “Always Deny”, and “Prompt”, which covers the other two options.

I realize that griefing is still going to find its way into any incarnation of any MMO, and that Uru is not an exception, but I think that Uru is in a unique position – both because of its community and its inherent design – to be a game where griefing on the whole requires significantly more effort than most griefers are willing to expend to get their jollies.  While Cyan’s tendency towards naievte and idealism regarding people’s interactions online means they probably never even considered Relto-spamming to be a potential issue (and I think justifiably so… it was only ever reported to be a problem to any degree in MOUL, a full 5 years after the game’s original release, so it clearly wasn’t something that had come up as something to deal with before then), I think it’s one of the few instances of griefing that can actually be eliminated because of its ability to put control of the situation in the hands of the target and not the perpetrator, without burdening the game with excessive overhead, or creating a confusing or time-consuming process for the player to maneuver through to block the perpetrator’s actions.

I apologize, by the way, for the lack of visuals to illustrate the way I envision this anti-Book-spamming feature looking… I’m writing from work and don’t really have the time to dedicate to putting together my usual visual aids.

Also, I really hope someone from Joystiq manages to find their way into the Austin GDC panel on Uru, if only so I don’t have to wait for Eleri’s convention report to see how it went.