May Contain Nuts

In the interest of letting everyone read this, as well as ensuring that I can find this blurb later when I inevitably go looking for it, I’m not putting this in the comments to my last post.

One of the nice thing about Uru’s chat system is that it automatically limits chat to a certain range once the Age population reaches a certain limit.
- Alahmnat
Can’t say I agree with this, I personally find this one of the chat features biggest hinderences, if it was a voice chat then that would be understandable as sound degrades over long distances depending on the volume, but the KI is text chat it can communicate between universes splendedly but starts having issues when 20 people are in one hood? Not sure how that makes sense.
- Tweek

Well, as I mentioned, Uru’s chat system is sort of a hybrid strange thing half intended to be used as an IM-like text chat system, and also half intended to be used as a more voice-replacement-esque text communication method. I think it’s this hybridization that makes it less than perfect, and it should either e used entirely one way or entirely the other, but not both simultaneously.

The biggest problem with KI chat is that there’s no delineation between text “chat” and IM chat in the chat window… it’s all the same thing. The apparent contradiction of having everyone in the Age on your buddy list but only having a handful of them able to hear you (and you’re never sure how many that is…) is the biggest problem, because the buddy list is acting like an IM client’s would, while the chat is simulating localized conversation by limiting the broadcast range, and then only when the system reaches a certain number of players.

This is the biggest thing I want to fix by having the local, public conversation “channel”, as well as private channels for long-distance conversations with small groups or individuals, and enabling players to toggle between them, rather than have them all mashed together.

Moving on to “phone” and other voice communication methods…

I can only assume that Cyan originally intended the KI to be capable of long-distance voice chat between two people regardless of where they were in the game (inter-Age voice chat… which does happen to be listed in the Gahreesen KI document), but for whatever reason, it never seems to have been implemented (that along with audio recording…). I would very much like to implement such a system, and having had the night to think it over, I’ve got a few ideas on how to do it.

By default, double-clicking on a user in your buddy list (whether they’re on your buddies list or your “local people” list) will initiate a private messaging session with them, just like launching a chat window in AIM/ICQ/MSN/etc. You can also right-click on any person in the list and be presented with a few extra options. Players in your buddies list can be removed from the list, and players in the “local people” list can be added to your buddies. If you right-click on a buddy, you have the option to call them. The person receiving the call has the option to ignore it, in the event that someone’s been randomly adding people to their list, and also to block all incoming calls (either for privacy or because they don’t have a mic). If someone is already in a phone conversation, they will have a little phone icon beside their name, and will be unable to accept new incoming calls.

Additionally, right-clicking on someone on your buddies list will give you the option to invite them to a group text or group voice chat. For a group text chat, you can choose to create a new “room” and call it whatever you like, or you can use one of your existing chat rooms. You can carry out multiple group text chats at the same time. For voice chats, right-click on one of the people you want to have in the group, and select the option for group voice chat. This will issue a phone call to that person, after which you can continue to add new people. Since the voice chat system only allows for one chat group at a time, there is no need to name the chat, and once you hang up, you’re free to initiate a new call.

There is also a “missed calls” menu in the interface which lists all of the calls you were unable to receive because you were on the phone, or away getting food, or whatever.

You also have the ability to put a voice chat on “hold” in the event that you need to talk to someone right next to you in the game. When you’re having a phone conversation, your voice is broadcast only to the person or people you’re on the phone with, ensuring the conversation’s privacy. You can put the conversation on hold and re-enable public voice chat by clicking a button on the device, then switch back to the phone chat by pressing the button again.

The one thing I’m not sure about is how to handle public voice chat reception by those on the phone. My first inclination was to just mute it outright, but I don’t know if that’s the best idea. However, unlike the real world, where it’s easy (or at least, easier) to distinguish between people on the phone and people standing next to you, online it can be difficult to tell where a sound is actually coming from. Perhaps I should look into realtime holophonics…

Chat is, quite frankly, a nightmare.

MMOs are an odd mix of traditional online communication methods (IMs and chat channels) with an attempt to enable players to communicate with others (usually via text) in a way that mimics that of the real world. The only problem is that, by and large, these two forms of communication are based on entirely different architectures, so to speak. In the real world, you only communicate with those in your immediate vicinity, unless you happen to have a cell phone on-hand, in which case you can also communicate one-on-one (or maybe a 3-way call) with someone else in a completely separate area.

In MMOs, communication tends to be global, or at least, far broader in scope than the “immediate vicinity” range of traditional real-world communication. I think the biggest reason for that is the reliance on text-based communication, which has no tangible fall-off range like vocal communication does. The only problem is that this communication method, while it works well in the abstract realm of the Internets, becomes too fluid and expansive when applied to a simulated world with physical boundaries. It’d be like being able to converse with the entire downtown population of a major city on your cell phone. Doesn’t really work.

So really, what’s needed are two separate chat systems… one to simulate conversation in the real world, and the other to replicate existing IM behaviors as found in clients like AIM and such. The challenge is implementing them in a way that is seamless, understandable, and user-friendly. I think the chat system as devised for Uru is part-way there, but I want to take it a step farther…

One of the nice thing about Uru’s chat system is that it automatically limits chat to a certain range once the Age population reaches a certain limit. The problem is that there is no visible indicator of this chat range, be it a boundary line in the game itself or an indicator beside the names of those in your buddy list who can “hear” you. Because my goal is to create an environment in Phoenix that has no load time between areas of the game, an “Age Players” equivalent would basically be the shard’s online population. Obviously, this doesn’t work. What I’d like to do instead is a more extreme version of Uru’s chat range system, where not only does your message only get broadcast to those in range, you only see those who are in range of your message listed in the “local” section of your buddy list. This list would only display players who are within, say, 50 to 100 meters of your position, and only they would be able to receive your public chat messages. This would likely result in the creation of “pockets” of chat, where a small group of players would gather to discuss something, and across the street, say, another group could gather to discuss something else, without interfering with each other’s chats, because that’s how it works in the real world.

In addition to this dynamic public chat system, there would also be a more traditional IM chat format, which would enable communication with players on totally opposite sides of the game world. Most IMs would be one-to-one chats, and could be easily tabbed beside or beneath the “public” chat, for easy access. These private chats would display in the same space as the public chat, replacing its contents much like a tabbed IM window would on a computer’s chat client. In addition, group chats could be initiated and named by the chat group’s creator, and also placed in the chat’s tab list, perhaps with a distinctive icon to delineate it from P2P chats.

The real challenge, though, comes in voice chat, because there just isn’t a way to properly and realistically simulate its effects in an online world. A large group of people conversing in a room like Bevin’s community room would create considerable echo and ambient sound, even if the specific voices were indistinguishable. However, once your voice reaches the edge of the broadcast envelope, it vanishes, and goes nowhere. Hopefully, Live will fix the sudden cut-off and replace it with a more gradual fall-off curve, but the total loss of voice over distance is still a considerable problem for creating believable ambience in group situations.

Additionally, voice chat should be possible over a phone-like service to other players in other regions of the game, even if only on a one-to-one basis (although small-group chat would be very nice for group-based quest situations requiring real-time rapid collaboration). I’ve not even begun to consider the necessary UI requirements for such a system, but it’d be nice…

Anyhoo, just some ramblings inspired by a few posts on the Uru Live forums and a chancing across a more recent re-design of my KI impersonator today.

There’s a rather touchy topic running on the Uru Live forums regarding the quality (or lack thereof) of the story in Uru. The conversation has, for the last 12 pages, ranged mostly over the lack of story resolution or consequence in the single-player game, and has more recently begun moving into a conversation about Prologue and the merits of its story, as well as its method of story telling.

It is my opinion that MMOs, by design, cannot support the same game play experience that a single-player game provides. SP games almost universally feature you as the star character, off to perform some feat of rescue or somesuch, at the end of which you get a big reward, a happy credit scroll, and a feeling of real personal accomplishment, which you can take and share with the millions of other personally accomplished people who have done the exact same thing. MMOs operate on a different wavelength… typically, players are not the heros, or if they are, they’re only one of a great many. The uniqueness of one’s experiences in an MMO are defined not by being the hero in the same game as everyone else, but by being a contributor in a larger world. In the case of Uru, where the content is designed to be driven by a strong central storyline, it’s virtually impossible to provide the same sort of experience as the Myst series did… where you alone are the only person who can help Atrus and his family by setting right some unspecified number of wrongs. The reason for this, clearly, is because you aren’t you alone… you’re you amongst a whole scad of other folks. At that point the novelty of being the personal hero sort of wears off for me, because if I’m in this world with all these other people, and they’re all accomplishing the same incredible feats as me (saving Atrus, retrieving a lost Book, banishing Sirrus’ spider-brain to an inky black nothingness, whatever), my actions have less meaning than they would if the same situation were provided as the plot for a SP game. In SP games, if I don’t do it, nobody else will… but in an MMO, if there’s a monstrous beast descending on a village from a nearby mountain, if I don’t go save them, someone else will undoubtedly be along in a minute to help them out. Instancing that sort of experience in an MMO so that everyone can defeat the dragon and be the hero of the town seems to sort of demean the importance of it.

The same is true in Uru, although the circumstances are somewhat different. To borrow an example of an event from Prologue, Phil Henderson’s return was something that was experienced by one person… this happened to be Zardoz. He spoke with Phil and as a result Phil returned to D’ni and started into a bit of a spat with the DRC. If everyone had been able to meet and speak with Phil in Eder Kemo, it simply wouldn’t have made any sort of consistent sense. After Phil’s return, he wasn’t going to be re-appearing in Eder Kemo every night for a repeat performance in case you missed it. It would have destroyed the story’s continuity, which is rather important in a persistent online world, where events have a lasting impact. Additionally, to continue the example with Phil, only a few people were in the City that day when he fell in the Guild Hall. Enabling everyone to experience that at their leisure whenever they chose would again destroy the continuity of the story. Some things must, by necessity of the story, happen only once. If you miss it, you miss it. Now, there are varying levels of this phenomenon, and I think only the most extreme was ever explored in Prologue because of technical limitations on what Cyan could work with while attempting to continue their bug fixing. When you have a small(ish) stage, you have to make do with the props (barricades, scripted events, whatever) you have on hand, because the audience is already filing in, and you don’t have time to build more set pieces.

More subtle examples of lasting impacts on the game world through one-time events would, I imagine, include things such as Ahnonay in its originally-intended format. Imagine being the first group of explorers to see Kadish’s Age for what it actually was, and what sort of storytelling possibilities could arise from that revelation. The DRC’s reactions alone would have been interesting to see, and the discovery of the fourth sphere would have been another gem, I’m sure. But these discoveries can only happen once, when it comes to storytelling continuity. Since Ahnonay would most likely have been a privately-instanced Age like all the rest, other explorers could make that discovery for themselves, but the story, by that time, would have moved on to a new track that took that discovery into account.

The challenge behind story development in MMOs is to create a story that will involve as many people as possible, but without drawing everyone into the same repeatable situation for them to resolve on their own, seemingly independent of the passage of time in the game world. For these reasons, I think a lot of Uru’s story would have been and probably will again be more passive than the Myst series (most notably the more recent releases), dealing more with unveiling ancient D’ni histories and their relationships with newly-opened areas than finding Yeesha’s lost pair of Bahro toenail clippers. Not to say that quests like that (okay, hopefully not too much like that…) will never be a part of Uru… the existence of the Journey is evidence against that right away. While its delivery and purpose was, I think, altered and in some ways convoluted in the effort to turn it into a whole game’s worth of SP content, it’s been part of Uru since the Ubiru testing days, with the culmination located in a private Age, presumably where some repeatable event was to have taken place… something that everyone could get through, experience, and relate with without risking some sort of freakish timeline distortion by letting newcomers 2 years on trigger something (like Phil coming out of the Journey Door) that simply wouldn’t make sense now that the story of that character has moved on.

I have no problem with instancing areas like the Ages, where puzzle solving and story development can take place on a more personal, direct, and often more repeatable level, as has been the case with the Journey story arc for the past 2+ years. However, I don’t think it’s appropriate or even terribly realistic to expect the entire game to conform to that mold of story telling. If it did, there would be no point putting it online, since everything could be accomplished individually and at any time you wanted. By taking a game world and placing it in an online persistent environment, you are by default handing over a certain level of control over repeatability of gameplay. Persistence means that things you do stay done, and this is most vitally important in the public areas like the Cavern itself… private Ages can get away with the concept of being reset and replayed because they aren’t a shared space, but even so, discoveries made in private Ages that are communicated into shared spaces (such as Zardoz’s encounter with Phil) can become one-off events that push the games plot ever onward.

To wind this around to Phoenix, since I’ve tagged this entry in that category, I’ve been spending a bit of what very little free and idle time I have trying to come up with concepts for how to develop areas that can be shared communally, but reflect into instanced, private regions, missions, events, etc. without excluding the possibility of a one-off event. Sometimes you need a one-off to push things along, and the less new actual content you have, the more often you need these one-offs to keep things going in the existing material. I would actually anticipate that the sheer volume and rapidity of one-off events in Prologue was disproportionate to the number of one-offs that would take place in a fully operational Live environment, simply because it was the easiest and cheapest way to progress the story at the time.

Anyway, back to Phoenix… my plan at the moment is to provide, at launch, a really vast area of the capital city for players to live in, play in, and explore. Oddly enough, the game is planned as a sci-fi/space sort of game, but initially, there probably won’t be much space-related stuff to do. Most of it will be centered around the city and its single current connection to space at the time of launch, the not-quite-finished space station. Over the first few months to a year, the game world will gradually expand to include the station and surrounding regions of space, all the way out to and including pretty much the whole 3-planet star system. The only way this sort of progression is possible is to provide one-off events, like the grand opening of the space elevator attached to the space station, coupled with communally-driven story elements… just as a for instance, as more players join and begin filling the city and skies of the game, new colonies will need to be founded, which provides unique opportunities to those interested which only come around every so often. While this background story is taking place, a lot of the more personal things will mostly center around simply living in this new world… hopefully nothing as doldrum as level grinding in mines and such, but taking contract jobs, running goods, even stuff on the level of private investigating or corporate espionage or just outright theft (Firefly… *ahem*). Nothing that would very often affect the game’s primary plotline, but lots of stuff that can be done and doled out to a LOT of players repeatedly without losing too much of the novelty. Every now and then, throwing a curve ball into the game in the form of a one-off event (like running into an alien craft and the potential consequences of that player’s actions in that encounter) would help to push the main plot forward, but overall, most of the relevant gameplay time in Phoenix would be driven by either communal projects (gathering materials for a construction project, for instance) or private activities (executing a hit on an NPC maybe). If you happen to get caught up in a one-off, huzzah for you, but one-offs won’t be the only way of participating.

Similarly, as I mentioned, the frequency of one-offs in Prologue was largely due to the need for a storytelling method that was content-light and heavy on involvement to draw players in during the ramp-up period while simultaneously trying to prevent the rampant distribution of new content while bugs were being addressed in the stuff we already had. Once the content moves into Live to support the gameplay, I would expect the regularity of one-off advancements to drop, but not cease. However, I would also not expect such a shift overnight… working on an MMO with a team of less than 30 is insane any day of the week, and right now it’s Cyan’s standard operating procedure.

So I was noodling around with the PAD design last night, and it occurred to me that with the increased probability that you’ll encounter an action-oriented situation in Phoenix, having a device that blocks the view of the entire screen when it’s running is a rather bad idea. So, bowing to design requirements and hoping I don’t get attacked legally for stealing the KI concept for my own purposes, I turned the PAD into a holographic device called the PHD (Personal Holographic Device), which the in-game company that “makes” them nicknamed “The Doc”. It’s provided me with new opportunities for better functionality than a static, fixed-size screen-in-a-screen design would have allowed, but it also presents new challenges in terms of how to display stuff or activate tools/functions without confusing the user or requiring a lot of work.

The new device, which is about the size of a CD were you to have one in your hands, is a circular object with a large screen on it, displaying much the same information it did in the PAD design. The device sits at the lower-left corner of the screen, partially obscured on the left and bottom to reduce wasted space. A small nub extends from the top-right portion with a photograph button on it, and two other buttons on the top and right activate the chat and contact list holographic screens, which are the only holographic elements that cannot be moved.

My goal was to enable the game to provide better HUD capabilities without resorting to lots of random screens and windows that were on your screen with no explanation as to how you’re seeing them. Some stuff, like inventory management and the like, will still play this role, but most of it should be done through an in-game device if it’s stuff you’re interacting with in-game, IMO. Removing the need to totally stop your movement through the game whenever you want to fully utilize the tech interface is the primary motivation behind revising the PAD design, and in doing so, it enables me to design new elements of the now-PHD to enable better interaction with things on missions, like a code-cracking app you have to download and then use to get into a secure facility. Not requiring an app to take up the full size of the PAD screen also enables apps to be more space-conservative, and lets you have more than one app open at a time, which is a good thing.

Over the next few days I’ll be hammering out the details of the design and probably putting up a few design mock-ups from Photoshop, so stay tuned. This’ll be fun.

A couple posts ago I made a few comments on how players should be able to interact with the environment and objects within it. I’d like to take a moment to expound on that a bit, as I think my comments were somewhat misinterpreted.

First, I want to make it very clear that I think the puzzles in Uru that were driven exclusively by the physics engine (such as the Teledahn slave prison, and more obnoxiously the Gira fish baskets) were very poorly designed from the start. While Teledahn’s puzzle was at least solvable by alternate means if you had enough people in the Age with you, Gira was all or nothing, and the interface made it incredibly difficult to maneuver the fish baskets into place.

Now, with that said, players will still need some way on interacting with the environments, and total removal of the physics engine would be inadvisable, if only because I know how much of a nightmare Cyan had with realMYST (which was made before Plasma had a proper physics simulator). I just think that there are other ways of interacting with objects besides kicking them around. To re-use my example of arranging the furniture in your apartment, I at no time had any intention of requiring the player to kick their furniture around the room. In fact, the furniture will probably be locked down and immobile when it’s not being re-arranged, because really, how often do you bump into your recliner and send it scooting across the room?

What I want to do is expand the utilization of hotspots in the game to include more than one possible action. Most hotspots will still only have one action (benches have a sit action, switches have a toggle action, doors have an open/close action, etc.), and it should be pretty clear simply from what you’re clicking on what the game will do once you click it (you don’t expect to open a bench by clicking on it, you expect to sit, and you will). Some objects, however, will have more than one possible action. When this is the case, the cursor will change to a hotspot icon that is slightly different from the standard hotspot icon. Right-clicking on this object will roll out a string of icons + text indicating what you can do to that object.

In the case of moving your chair, you would walk up to it and right-click it. You would be presented with a small menu with “sit”, “move”, “rotate”, “settings”, “pick up”, and “store” options. Sit, being the default action, will also be performed when left-clicking on the chair, and your avatar will sit down in it. Move and rotate will display control overlays for the item you want to move. Since I don’t have a handy image of a chair that I can use, I’ll use a Quab from Ahnonay to illustrate my point. Moving the Quab will display a set of arrows around the object with a control grip in the center. You can use the control grip to move the object in all any direction (2-dimensionally), or you can use the arrows to move the object along that axis only. Rotating the Quab will display a ring around the object, which you can grab with your cursor and drag to rotate the object. Please note that these are crappy Photoshop attempts at simulating 3D widgets with some clever drop-shadows and bevels, so the final widgets will look and overlay a LOT better… this is just a quick bash to illustrate what I’m talking about.

These widgets will also only be visible to you, and only while you are involved in moving/rotating the object. It’s one of the sacrifices of realism for the sake of playability that I’m willing to make, because I recognize that there needs to be a more controlled way of moving things around than simply slamming your avatar into them and hoping they go where you want (not that that can’t be fun at times… just not when you’re trying to accomplish something). I think enabling the player to control their possessions this way in the engine itself ultimately makes the interactions more realistic, and it also enables us to allow players to move/rotate things outside of just specific areas where they would have access to a floor plan.

Also on the subject of hotspots… this is not a puzzle-oriented game, so the objective is not to find all the hotspots and click on them. A hotspot is simply something that indicates that you can interact with a certain object, and usually it will be clear from the object’s design that you can interact with it anyway, so the hotspot isn’t the sole way of knowing you can do something. It’s just there to confirm that you can. I just prefer that hotspots not be indicated visually by large floating icons whenever you get anywhere near something/someone like they are in There. It’s distracting, and I simply do not like that form of interface. Many of the hotspots in the game won’t even be necessary to getting “through” the game (if you can actually get “through” an MMO)… they’ll just be placed on park benches and whatnot to allow you to sit down on them or do whatever other action may be associated with the object in question. Like I said, though, if something is important and players need to know they can interact with it, there will be indications to that effect beyond the cursor changing when you mouse over it.

Also, one final note before I wrap this out for the moment. There will be instances in the game where players will need to interact with computer systems and other technology that cannot be accessed with the PAD. The most notable example that comes to mind besides piloting a spaceship (which is far to complex to use as a simple example here) is interacting with an elevator in a building. In order to cut down on the number of places in the city that we have to build, elevators will behave more like turbolifts than traditional cable-car-in-shaft elevators. They will be capable of transporting the player straight to the door of whatever location they’ve selected. However, for security, the elevators will only allow the player to select locations to which he/she is authorized to go. The authorization is done “wirelessly” through the PAD… just walk into the elevator and touch the elevator’s control screen and the authorization is already done for you. The elevator control screen will then display a customized list of locations in the building based on where you can go. The screen itself will have a similar style and interface to that of the PAD, and you need but to click on a location with your cursor and the car whisks you off to it (yes, I know, this sounds a lot like the Nexus… it’s not intentional, I swear… it was actually an idea I developed from one of Pat’s suggestions, and he’s never played Uru, so nyah). Other devices such as game tables and some more specific data terminals will also not be PAD compatible (and this will be indicated as such), and need to be interacted with from within their own control scheme. However, the objective of the technology interface is to make it as unified as possible, and direct as much activity as I can through the PAD interface in an effort to provide a consistent UI which people know will always be accessible to them. Even when the PAD itself cannot be used for the interface, it is usually in charge of “authenticating” the player when they interact with another device. Obviously this is an illusion, since the player’s data vault is what ultimately says where they can go and what they can do, not the PAD on their hip, but it’s nice to have an IC explanation for these things .

One of the trickiest elements of developing an MMO that isn’t set in the middle ages or some magical incarnation thereof is the way that players in the game interact on a technical level. Obviously, since this is “future time” (to borrow the phrase from the creators of Alpha Shade), the way in which tech is handled is vastly different from how (or even if) it’s handled in games like Everquest and World of Warcraft. Much like the modern world, technology is everywhere, and the number of devices we need to use in the real world to achieve a complete digital lifestyle “package” is rather immense, depending on the depth of your digital life.

I don’t want this concept to carry over into Phoenix. However unlikely it is that all of the tech developers the world over will have resolved their differences and allowed one platform to monopolize 100% of the consumer market share, doing it makes things a lot easier on both the development team and the players themselves. There are times in a digital realm where options and niche-market designs become counter-intuitive and simply serve to bog down the interface. To again borrow concepts from Uru, the objective is to create a KI-like device which will interface with anything and enable a seamless and consistent interface to be put on virtually every technology-driven task. In a way, it’s sort of the realization of the combined visions of Apple and Microsoft in a virtual realm.

I know a lot of people disliked the KI in Uru. I think there was a fair amount of ball-dropping at Cyan when it came to the documentation of the device to begin with, but in addition to that, it was a bit convoluted and not the most intuitive thing in the world to get used to messing with. Understand that when I say I want to create something like the KI, I don’t want to re-create the KI itself (though unfortunately my initial design renderings in Photoshop look rather KI-ish in appearance… oy, originality is a bitch). I want to create something that much more closely mimics the design and human interface guidelines of modern OS software (with probably more than a little bit of leaning on Apple in particular, if only because their human interface guidelines are actually accessible online ). What this means is descriptive icons, text, and a simple yet useful interface that feels a lot like a Palm or PocketPC user environment. I’ve come up with something which I call a PAD (for present lack of a better word). It has two display modes, much like the KI, but for now I’ll be focusing on the full-screen mode.

The device – a mock-up for which is shown on the left (click it for a larger view) – has 3 screens: the menu/chat screen, the buddy list screen, and the “main” screen where “applications” load. Right now I’m just using OS X icons as placeholders until I make my own (which is time-consuming), but the icons arrayed around the ring in the top-right are all “application” icons. There will be apps for various things, like chat/buddies, PAD settings, photo organization, text notes, mail, audio content, video content, a “web” browser (sort of like EVE’s in-game web browser, which will actually open sites on the web related to EVE), etc. The second segment of the ring is the devices dock. The single icon currently in the dock is the PAD itself, and it’s always listed. When you are close to PAD-enabled devices (computer terminals, public photo billboards, etc.), the device will appear in the devices list. Clicking on the device will cause a new set of application icons to spin into the app ring. Basically, the apps listed in the ring are what the currently-selected device will allow you to do. Sometimes there will be only one or two items in the ring, if there are any at all, and sometimes there will be a number of them, depending on your level of access to the device and what the device is actually for. The name of the app that is currently open will be displayed in the top half of the circular screen (in this case, “Chat” is open), while the bottom half will display the current date/time (only, 900 years in the future ). The other element of the top screen is the text chat system. Unlike Uru, you will be able to communicate in a number of various channels (not at once, mind you), and switch between them at will. There will, of course, be the typical “global” chat channel, but there will also be various smaller channels that you can retreat to when you want a break.

The buddy list will function somewhat like Uru’s does, in that there are groups of buddies that you can collapse, and clicking on a group or individual will send your messages to the selected person(s). Unlike Uru, however, you can create your own groups to put buddies in, and any organizations you join will be listed in the group list, along with all of its members. I’m still refining the way that private or group conversations are depicted, so it’s a little rough around the edges still. There are also actually 2 buddy lists on this screen. The one selected in the mock-up is your buddy list, but there’s also the Channel list, which lists everyone currently in the channel you’ve selected (think of it as taking the Age Players list from Uru’s buddy list and putting it in a separate tab, since not everyone on that list will be a buddy). The “Call Buddy” button will ring the buddy’s PAD, enabling you to voice-chat with your friend even when they’re on the other side of the city. In Channel mode, this button becomes “Add To Buddies”, which will add the selected person to your buddy list. I might also change “Buddies” to “Friends”, but anyway…

Finally, there’s the main screen. Unlike a fully-fledged computer, you can’t have more than one app open at a time (yeah, I know, everyone loves to multitask, but not in the future ). This screen will be filled by whatever application you’ve selected from the app ring. While the interface for each app will be different in terms of what is displayed, the design of each app’s interface will be consistent with all of the others, so it shouldn’t be too hard to get the hang of. Plus, we’re not dealing with D’ni communications conventions, but rather tried-and-true human interface guidelines and symbols, so understanding what’s going on shouldn’t be nearly as difficult.

Since I’ve decided to display the chat screen (I thought when I started that it would be the easiest… I was wrong), I’ll go into a little bit more depth about it. The Channels column provides you with a list of all active channels on the communications network (which is referred to in-game as the Backbone). You can select any channel and add it to your favorites, and can always be removed at any time. You can also search through the list of channels to find one with the title you’re looking for (anyone who knows what Spotlight or Google Desktop Search are should get how this search will work). The UI in the mock-up is slightly inconsistent, as the selected channel is in the Favorites list, and as such, the button at the bottom should say “Remove From Favorites”, but oh well. You can also choose to drop out of the public chat system entirely, which will limit your communication to private or small-group communication with those on your buddy list. I imagine this could also be parental controlled so that younger players can be kept off the public chats, but anyway, moving on. The Buddies frame provides a list of all of your buddies and groups. The mock-up isn’t quite complete in this area, as it doesn’t show that user-created groups can be deleted (this is done by selecting a group and clicking the button at the bottom, which will become a “Remove Group” button, rather than Add). Clicking on a group name will display all buddies in that group. To view all of your buddies, click the “Show All Buddies” text.. The options in the box below Groups are for your buddy list. The first will display the names of buddies who are offline when checked, and hide them when unchecked. The second will hide any groups without online buddies in them from being shown in the buddy list screen (this doesn’t affect the list of groups in the Groups column of the Chat app). The buttons next to each buddy in the list will display that buddy’s profile card (the “i”) or remove the buddy from the list (the “X”). To add buddies to user-created groups, just drag and drop. No annoying little arrows needed . Buddies cannot be added to or removed from system-created groups, as the system groups display members of organizations you’re a part of. I should also point out that scroll bars will be added to the Groups and Buddies columns when they get long enough to need one.

Organization control and whatnot will be handled by another app on the ring, so that information is not displayed here. I’ll probably be doing more screen mock-ups as the days and weeks and months roll by, so stay tuned.

I’ve been quietly observing my wife as she plays There, taking in what the engine can do, how the interface works, what’s available in-game to do, make, interact with, etc. I’ve been comparing There with Uru and other MMO interfaces, trying to find a balance between giving players tools to interact with the environment and maintaining a level of realism that There’s floating-blue-ring-with-orange-arrow interaction menus belie.

One of the positive things about Uru’s interface is that all interaction with other devices took place in the KI. Obviously, it may have been able to be a bit simpler in terms of the design, but I think that the concept was a solid one. By taking all of the data interaction in the game and moving it to a single object, players no longer have to contend with lots of screens and menus cluttering their screen, leaving the game’s graphics to do more of the “talking”, as it were. I feel the immersion level increases by removing all of the secondary screens from the display and simply showing the player the game world itself.

Obviously, any sort of single-device interface needs to be well-designed and well-planned to enable future expansion of the concept, as well as to enable ease of use for the player. It also needs to have two functional modes: full-screen and small-screen, similar to Uru’s BigKI and MiniKI displays. In Phoenix, I want to develop something more akin to Verizon’s V phone. The small-screen mode would enable the player to see the V’s screen and interact with it on a basic level, bringing up things like contact lists and maps, as well as enabling basic tools like text chat, phone calls, etc without requiring the player to step out of the game world (like the MiniKI, you can still walk around while you’re interacting with it). The full-screen mode is more in-depth and provides the player with the full gamut of menu options, enabling them to do everything the small-screen mode can do and much more.

This effectively covers any digitally-oriented interaction with the environment, such as voice chat, text communication, emails, photos, video, sound, etc. However, that doesn’t solve our interface requirements for physical interaction with the environment itself. As I noted, There indicates the ability to interact with something by hanging a blue circle with an orange arrow inside it over the object in question. Hovering over this icon brings up a menu of things you can do with that object. While this is handy in There, it’s largely because many of the objects you can interact with have more than one function (like hoverboards, which can be ridden, gotten off of, put away, gotten out, retrieved to your position, etc.). I don’t honestly anticipate this level of complexity in Phoenix, though some form of interface standards will need to be developed regardless.

Again looking at Uru, its simplicity of interface was very appropriate, because there wasn’t much in the environments that required the player to do more than throw a switch or sit down on a bench. Obviously one big example to the contrary would be all of the kicking puzzles, which would have benefitted from a more robust physical interaction interface. The trick is creating an interface that enables that level of interaction without breaking the reality of the world, because I don’t know of any time I’ve been walking through a room and little bobbles appeared over the chairs indicating I could sit down in them. Another suggestion I’ve seen is to cause interactive objects to glow when you approach them, but again, this seems rather unrealistic. Ultimately, though, some sort of visible UI needs to be instituted to allow for more robust interactions with the environment using totally unnatural tools such as a keyboard and mouse.

Still, I liked the simplicity of Uru’s cursor-based control scheme, where anything you could interact with was indicated as a hotspot, and clicking it would perform the relevant action. To the greatest extent possible I want to retain this simplicity, but in some instances, it’s not advisable. More on that in a moment.

Something else I want to enable is the ability for players to make their private spaces truly their own by enabling them to decorate and arrange their apartments and offices to their liking. This includes prints to hang on the walls, the fabric and style of the furniture, the style of flooring, the colors of the walls themselves, etc. Obviously, players will be able to choose what they want from a large but ultimately finite library of existing meshes and fabric styles, but by using color overlays on the fabric textures, you can create hundreds of different chairs from 1 texture and mesh. But more than simply being able to pick their furniture and finishings, players should be able to arrange the room how they want it. This is an instance where requiring a more robust physical interaction interface becomes important, as moving furniture around by bumping into it is highly undesirable. One possibility is to create two different kinds of hotspots: basic and advanced. Basic hotspots simply cause the avatar to perform a scripted task attached to that hotspot, like sitting on a bench or picking up an object and placing it in your inventory. Advanced hotspots would, when the right-mouse-button is pressed, bring up a small roll-out menu of options, like move, rotate, pick up, sit down, etc. Left-clicking would perform the “default” action for that object, which may be indicated by a small icon below or to the side of the basic cursor.

For example, in the instance of arranging furniture in your apartment, you have two chairs, a table, and a poster. Left-clicking on the chair causes you to simply sit down in it, and may be indicated by an icon to that effect (basic hotspots may include these icons as well for the sake of being more verbose about what happens when you click something). Generally speaking, though, left-clicking a hotspot will do the most likely action, so sitting in a chair or throwing a switch is sort of understood when clicking on a chair or a switch. Right-clicking on the chair would bring up a roll-out enabling you to move the chair around the room, rotate it to face a different direction, sit down in it, change its settings (which would bring up the PAD), or “pack” it into your inventory, allowing you to take it somewhere else (more on the specifics of this later). Right-clicking on the poster would enable you to move it around the walls, change the image/frame (again, opening your PAD), or pack it away.

I’ve got more to discuss, but this is long enough as it is, so I’ll bring up the rest of it later .

Anybody who doesn’t understand what that title has to do with what I’m about to blabber about wasn’t privy to the super-flammable Uru Live closure threads on the UbiSoft forums back in February of last year. Go here for an explanation.

Anyway, this does not, in fact, relate to Uru (at least not directly), but rather it’s another rambling musing post on my own game development, written when I should be asleep because the dipstick of an HR manager scheduled me to open tomorrow morning at 10AM (to those wondering why I’m complaining, I’m a night person almost by nature, and have worked about 6 opening shifts in the past year, but I’m digressing already).

I finally had a chance to sit down and chat with Pat – my manager who also doubles as a partner in insanity – about Phoenix (the partial title of my game, not the city in Arizona). For those who may have forgotten, Phoenix started life as a Homeworld mod idea, and ballooned from that into its own fully-fledged RTS game, and has since evolved into an MMO of epic proportions.

We talked about a lot of things tonight, and I got a number of good ideas just from taking to him. I always do, which is why I wanted to discuss things with him in the first place, plus he and I share similar opinions on the entertainment factor of the current offering of MMOs, so we share a similar wavelength when it comes to what we want to do.

The first thing we discussed was storytelling in a player-oriented world. I had, up until a couple of weeks ago, been willing to let players be characters from any currently-known race, but ran into problems when push came to shove and my story demanded events go one way, when player activity could very well drive them somewhere else. So, I briefly entertained the notion of simply restricting play to the human race, making all alien races NPC-only. Pat disagreed with that idea, and suggested a more fluid approach to storytelling be taken, wherein certain events should be written to occur in several different scenarios, so that while the events and circumstances leading up to a vital event may be different, odds are it will play out in a similar (though not identical) way to what had originally been designed. It requires a lot more work on the part of myself and whoever else ends up helping with the story development, because with this concept we’ll need a lot of consequence flowcharts to track the story’s evolution, and it requires me letting go of my incredibly vague story concept just a bit (which is fine, really…), but I think it will ultimately make for a game and a story that flow together better and take better advantage of player influence.

We also talked about city development and planning, and how to launch a game with a supposedly bustling capital city in place. Metropolises are hard to simulate in a computer because of the sheer volume of space they occupy, and modeling each room in every building is not on my to-do list. Ultimately, Pat confirmed that one of my earlier ideas was, with a little tweaking, a good one. Namely, let the city contain a number of skyscrapers and other rather large structures, but only allow general access to the lobbies of those buildings. Access to other areas would require an invitation or special clearance, thus saving me the headache of having to develop an entire city inside and out. Players could own storefronts near the spaceport, and warehouses above them would provide storage space for raw materials the shop may need, or finished items. Apartment complexes would offer general housing opportunities to players looking for a place to call home and stash their stuff, while more affluent players would eventually be able to afford whole houses or even mansions built in more “respectable” communities. The potential for player-owned property would even create the opportunity for unique player to player cooperation and communication. An example Pat used was one in which a restaurant owner in a certain neighborhood may offer discounts on meals to out-of-work members of the local community. Ultimately, I think I’ve decided to set the launch time period a little earlier than I originally planned to, enabling players to take greater part in the development of this new capital city and really make it their own (at least, to the extent that the game can feasibly allow). And for players who join later, there will always be more colonies to live in and help grow, if that’s the sort of player experience they’re interested in.

Interplanetary transportation also came up, as well as discussion of the design of the solar system itself. The design discussion lead to a rather interesting idea for a system that provides unique exploration and storytelling possibilities, and I really rather prefer it to the more boring 3-planet system I’d originally been developing. As for transportation, we decided on a number of things. First, Pat agreed with my notion of making the ship an inhabitable space, rather than just a shiny hollow shell you mysteriously inhabit. Again, more work for me because I have to design the exteriors *and* interiors, but hey, it’s fun. Besides, I want people to be able to really get attached to their ships and be able to tweak them to their own personal preferences, and it’s easier to do when you can stencil the dining room with a floral pattern . Anyway, NPC vs. PC transportation of other players came up, and we opted to allow both, especially for long-haul cross-system runs. We even decided to let players log out and still be able to continue their trip, unless of course you were the pilot, in which case, logging out could lead to you falling victim to a pirate attack while you were offline, with the potential for nasty consequences for your character, as well as anyone else you were carrying at the time. Cross-system travel won’t exactly be a quick trip, either… from one side to the other is about eight hours (planet-to-planet would, obviously, be a LOT shorter than that, depending on planetary positions at the time), so NPC transport is likely to have a bit of a stranglehold on the long-haul transport business. Capital city mass-transit also came up, and I opted to install a subway system, partly because I have a strange affinity for a well-designed subway system, and also because it allows for some CG trickery that above-ground systems wouldn’t be able to handle. Subway stops could be more easily added as the city expanded without having to worry about re-building railways, re-scripting entire bus routes or re-designing NPC taxi systems (PC-run taxis would be another interesting business possibility, coincidentally).

Finally, some random thoughts. PvP should be possible, though both parties would need to opt in before such activities would be permissible by the game (unless you specified during player creation that you were okay with unprovoked PvP against your character, such as a contract hit). By extension, Pat is of the opinion that players should be able to physically interact with each other (such as shoving and bumping), but I worry about the potential for severely decreased mobility in congested areas. Crafting should never be an option, but storefront owning, material sales, and possibly some industrial resourcing sorts of jobs should be allowed. The game should have a well-rounded, functioning economy, with failsafes in place to prevent recessions in the event that the game’s story drives the economy into the ground (how, I’m not sure, but I’ll go for it… nobody likes a recession). Players should be able to team up and form crews, who could go on jobs as a team and live in a ship together.

Ultimately, I was a bit pleasantly surprised that Pat was as enthused about the potential that MMOs provide for telling your own stories inside of a larger arc as I am, and we had a great time discussing ins and outs of design and gameplay, how the engine should accommodate certain scenarios, and what players could and should be able to do to help grow not just the story but the world itself.

More later. Right now, I’m off to bed. Have to be up entirely too soon.

My biggest stumbling block with turning my game design into an MMO (originally it was going to be an RTS, but it’s kind of moved away from that) is coming up with enough player-oriented stuff to do… having not played traditional MMOs much at all, I’m not sure what all is possible. I know mining is usually a big draw (if such a monotonous task can really be called a “draw”; “unfortunately necessary chore” seems more appropriate), but beyond that, I don’t really know what could be included in a space-based MMO as player “jobs.” EVE – the only space-based MMO I’ve even bothered with – really doesn’t give me any clues, because you’re stuck in your ship 24/7… one of the things I consider dull, and only slightly ridiculous (not being able to land on a planet is another biggie). I’ve never even seriously investigated Star Wars Galaxies, which seems like it would be my only other source of insight. I’d pick the brain of my cohort in crime, but he’s out of town right now trying to whip another theatre’s projection booth into shape (yes, my “criminal” companion is my manager), and these conversations are hell on wireless minutes.

I get the feeling this is one of those warning signs you’re supposed to see, as a developer, and say “hey, I really don’t know what the hell I’m doing… maybe I should re-think this.” However, nobody ever said I was all that bright when it came to knowing when to quit while I was ahead (or even just barely breaking even), so I’m likely to continue plowing through this idea with the grim determination that can only come from either sheer genius or overwhelming stupidity. Hopefully, more of the genius will stick than the stupidity.

To continue, then, I think the difficulty in moving the game world from a single planet into interplanetary (and eventually, interstellar) space is that you increase the mount of potential game space more than exponentially (would “factorially” be a good word to use here?), without actually being able to dump content into much of that space. It’s great to have derelicts and space stations and asteroid belts and the like dotting the map, but there’s still, by necessity, going to be large tracts of vast nothingness between them. This is, I’ve found, an issue that land-based games don’t tend to have. Single-player games tend to break a planet off into small, distinct levels with lots to do, but which cannot be accessed in other missions, while MMOs break the world into zones, all of which can be explored at any time – you just have to wait for them to load – and all of which have something of at least minor interest in them. Again, in this regard, I feel like I need to sit down and have a good long chat with someone who plays WoW incessantly, just to get a feel for how transportation, communication, and city planning works in these kinds of games.

The biggest trick, for me, is that I don’t want everyone in the game to have to own a spaceship. It just strikes me as highly improbable that an entire population would be made up exclusively of spaceship pilots and their crews. Obviously, one could simply shift the planet-side duties to NPC-only characters, but that seems to be pre-emptively limiting my options as far as what players can do. Admittedly, it would be simpler if everyone just started out with a spaceship and to hell with the planet-side jobs, but I don’t think that would offer as much variety in things to do (it would also make landing on planets and such rather pointless, which brings us back to EVE). Since this is the space age, though, what sorts of things can your average PC do without a ship? Mining is an option only because spaceships are still made of the stuff… a lot of the craftsman jobs in medieval-fantasy MMOs are probably not going to exist because you don’t need shields and weaponry basic enough for your average metalworker to create. Farming is a possibility, but what sort of short-term results can you get out of that kind of job? I guess you could shift the burden to retail, so people buy finished or nearly-finished products from an NPC distributor and then assemble/sell them, but that’s not much fun (of course, to me, neither is incessantly making swords with your mouse… whatever).

Possibilities increase if you own a ship (or at least, they differ greatly), but if you don’t start out with a ship, how long will it take you to get one? Would you be able to buy one on credit? If so, could you default on your loan and have your ship impounded? If so, could you evade impoundment by keeping to the edge settlements and staying on the run? If not, why? Could you elect to start your character out with a ship at the expense of other things, like more money, clothing, etc? If so, how good would the ship actually be?

If you have a ship, what can you do with it? Run passengers? Run cargo? Do salvage ops? Go on rescue missions? Mine asteroids? Could you do these things with illicit cargo / fugitives? Could you engage in piracy against NPC and PC ships? If so, what counts as acceptable piracy and what counts as griefing? Would there be pirate-friendly zones outside of which piracy is frowned upon (and if so, would these be established in advance, or by players as trade routes developed), or would it basically be “fly at your own risk”?

There’s also options to join the military… armies and space-based naval forces (possibly even actual marine navies if the player count gets high enough) that would carry out operations against enemies, or in defense of allies. Though, initially, I don’t think there’s going to be a big sign-up rush for the Fleet, because initially, I don’t actually intend for there to be any other races… just us humans. That will change in time, though. It’s part of the story .

Of course, you can take missions and get paid for doing them, but it’s freelance work, and I don’t know if I could drive enough content to make freelancing viable at the start of the game (perhaps I may even have to take advantage of instanced missions for less dramatic stuff, like recovery of cargo from a drop point and various other shady dealings). As things take off and more space opens up (as well as new races), the number of jobs to take on would go up dramatically, but initially, one may be hard-pressed to make a living on the “raggedy edge”. Of course, this is the difficulty with creating a strongly story-driven MMO… you can’t release ALL of your content at once, because some (most?) of it has to come in with story elements down the road. The result is a fairly small initial game world that could potentially be burned through in a couple of weeks by people with no lives, as opposed to games like World of Warcraft (or EVE… ye gods), where it could take you two weeks just to get to the other side of the map.

A lot of “what to do” is also compounded by “where can you go”… unlike EVE, I intend for you to be able to look around inside your ship at any time (in space or on the “ground” [space stations count as ground]), as well as get out of your ship when you’re on a planet or docked at a space-based facility and look around. This creates problems when you intend to let people roam around a human spaceport metropolis, because you kind of have to make the city explorable; locking folks inside the spaceport complex is just dumb. And unlike Uru, where they had a perfectly good in-character reason why you couldn’t go everywhere the moment the game opened, I really don’t have such an excuse for why certain areas would be off-limits, while others are open. The added difficulty here is actually creating a living city, not just a static bunch of locked buildings with shiny storefronts. Again, I think I need to have a chat with someone who plays WoW and see what the Blizzard guys have done for city development.

Anyone who wonders why it took Cyan six years to get Uru release-ready should spend a couple of weeks really trying hard to come up with an equivalent concept… it’s a lot harder than it looks . More to come, as always, when I get some more time to ramble .

I wonder, in the back of my head as I ruminate on this pet MMO project of mine that will likely never see the light of day anyway… is it a good idea to approach a game, even partially, from the perspective of trying to “fix” what was wrong with a game you’ve played in the past and found flaws with?

At first, it sounds like a brilliant idea, but upon closer inspection I think it’s something you have to do very carefully, and even sparingly, perhaps to the point of giving up on fixing some of the flaws. Two games I’ve played come immediately to mind when I think of previous efforts along these lines: Myst III: Exile and Homeworld: Cataclysm (I’d link these to official sites, but neither of them exist anymore). Both games, it so happens, were made by third-party developers, who took on the universe of another company’s creation while the parent company itself was busy with another project. Specifically, Presto Studios did Exile while Cyan worked on Uru, and Barking Dog Studios did Cataclysm while Relic Entertainment worked on Impossible Creatures.

Anyway, in both cases, the games got somewhat mixed reviews from fans of the original developer’s work, and it so happens that Exile and Cataclysm often shared the same complaints… it was easier than the original, or it lacked the cohesiveness, or took the artistic style and narrative structure somewhere different. Both games also introduced a new generation of fans to the community, who often times found themselves at odds with the more tenured members, and in some cases, were actually uninterested in the games done by the original developers. This in and of itself is something I want to go into a little deeper in another post, as I think it’s a cause of some of the divisiveness in the Myst community, but I digress.

Both companies approached their projects with the intention of “fixing” what was “wrong” with the games… removing oft-complained-about elements and replacing them with simpler or just plain different game mechanics. Presto made a conscious effort to not just make the puzzles easier than they were in Riven, but also to make them far more obvious in Exile. They certainly succeeded, though I’ll leave it up to the reader to decide whether they went too far. I think Presto was trying to make a true “Myst II”, since Riven was (and is) considered to be an altogether different beast. Maybe without Riven, Exile would seem more impressive, but it seemed more reactionary in its design than visionary (not that vision has much time to manifest itself in an 18-month pre-rendered development cycle). Cataclysm, by the same measure, reacted to many of the things people complained about in the original Homeworld: fighters had fuel concerns, the Mothership was a giant, defenseless, floating space banana, and the enemy fleet was so much a carbon copy of yours that you could actually play the single-player campaign as either race with little difference. As a result, while the game shared the same artistic style, and added a few welcome improvements to the engine, there were a number of nonsensical changes made as well, and changes that simply didn’t seem to fit into the construct of the universe that the guys at Relic had created.

Interestingly enough, Cataclysm is also what kicked off my initial thought to make an RTS where you could actually *fail* mission objectives and still be able to continue, with the game compensating as you went along, changing the structure and objectives of later missions.

Anyway, I look at what I’m trying to do – namely, come up with an MMO that I would enjoy playing – and I see myself taking his same reactionary approach to engine design, featureset development, and player controls, and I wonder if I’m falling into the same trap of trying to make a game I’ve already played “better”. Obviously the largest problem with trying to make anything “better” is that it’s a subjective term… “better” for me may be infinitely worse for a lot of other people. And yet, at the same time, I want very much to take the universe I’ve conjured up (which, after seeing Firefly, ended up being not nearly as original as I thought in some regards, but whatever), and turn it into a living, breathing place in a way that hasn’t really been done before online. Where does one draw the line between originality and improving on existing concepts? Is there really much originality left, especially when it comes to space-based games?

I’ve got more to ramble about specifically relating to my own MMO concept, but for the sake of coherency I’ll split it into a separate entry. I just wanted to throw this ponderable out there.