Raph is no longer taunting us (Metaplace)

[Kaa]

Balkanization is a good word.

Sometimes. Unfortunately it happens to be an antonym to "critical mass" and correlates well with "obscurity".

But anyway, it will be very interesting to observe virtual worlds (and specifically MMOGs) living with open, easily modifiable clients. Security issues, botting, etc. etc.

Kaa

[Lum]

MMO clients are technically open anyway. You can't assume that someone isn't logging into any given MMO with a client they made up themselves. It's actually not that big a hurdle from "make sure every input is sanity tested server-side" to "oh, and don't care if someone logs in with whatever funky client they want".

[Krakrok]

Theoretically, yes, it's looks attractive to have a rendering-neutral protocol and be client-agnostic. In practice this doesn't work so well. I suspect the effective outcome will be the pairing of specific virtual worlds with specific clients, and if you don't use the recommended client all bets are off. This could lead to rather ugly balkanization unless a dominant client emerges early.

Actually, it might work out pretty well. You probably don't want to run around and kill shit on your cell phone when other people are doing the same from a 3D client on their keyboard and PC. However, you can have a PCish client which does all that and then theoretically you could have a lite cellphone client that just lets you IM with your friends ingame, sell/buy items, and maybe travel from place to place. How that would work with the framework they have setup I have no idea.

[Alkiera]

But it's kind of silly to expect something to render the same on a phone as on a 3d video card.

It's also kind of silly to design a virtual world that will be as usable from a mobile phone as it would be from a full-blown gaming rig.

Theoretically, yes, it's looks attractive to have a rendering-neutral protocol and be client-agnostic. In practice this doesn't work so well. I suspect the effective outcome will be the pairing of specific virtual worlds with specific clients, and if you don't use the recommended client all bets are off. This could lead to rather ugly balkanization unless a dominant client emerges early.

Kaa

Emphasis mine.

I agree completely.  I see the point of having a neutral network API to allow for multiple client types, the same way they allow for multiple game types.  Some games will require the flash client, some a heavier 2d client, some a 3d client.  Some a cellphone client.  But I would guess that it'll be up to the game developer to detect/allow for those clients and provide different interfaces for them.

To my mind, you build some sort of playable flash interface as something you can stick on the main page to demo some aspect of your game.  Not the whole thing, not even in the main world, but featuring some part of the engine.  Then you req. a download to get fully into it, for any 'serious' game, i.e. anything more complicated than your average Flash popcap type thing.  If you want, you build a way to login to the same account from, say, a cellphone client, for either chat/mail purposes or to monitor Auction House/vendor sales, manage crafting factories, etc.  Perhaps put a similar thing in flash or even just CGI for those with web access but no client, and no cell.

--
Alkiera

[Raph]

To my mind, you build some sort of playable flash interface as something you can stick on the main page to demo some aspect of your game.  Not the whole thing, not even in the main world, but featuring some part of the engine.  Then you req. a download to get fully into it, for any 'serious' game, i.e. anything more complicated than your average Flash popcap type thing.  If you want, you build a way to login to the same account from, say, a cellphone client, for either chat/mail purposes or to monitor Auction House/vendor sales, manage crafting factories, etc.  Perhaps put a similar thing in flash or even just CGI for those with web access but no client, and no cell.

--
Alkiera

Don't underestimate what you can do with Flash. :P It's certainly capable of delivering Diablo/UO/Baldur's Gate level experiences.

[Soln]

MMO clients are technically open anyway. You can't assume that someone isn't logging into any given MMO with a client they made up themselves. It's actually not that big a hurdle from "make sure every input is sanity tested server-side" to "oh, and don't care if someone logs in with whatever funky client they want".

you're being sarcastic, correct?

[Lum]

Actually, no. There have been instances where third party clients were developed specifically to hack the game (Second Life especially has suffered from this recently: see http://shoopedlife.nexisonline.net/wiki/Main_Page).

[Raph]

Think of it this way. You can encrypt, obfuscate, and in general secure the client as much as you wish. Then you hand it over with the decoding mechanism to players (after all, the client must decrypt, de-obfuscate, and unsecure it to display it). That's why the adage "never trust the client, it is in the hands of the enemy" comes up.

So yeah, knowing that there's open clients really just makes us offload more stuff to the server. It's not that big a leap. In fact, such a little leap that it hasn't really even come up much here at work.

[Margalis]

Someone name a single advantage of multiple clients.

No, hacking is not an advantage.

The fact that people theoretically CAN make clients is not the same as telling them it's a good idea, which is what you are doing.

[Slyfeind]

Someone name a single advantage of multiple clients.

No, hacking is not an advantage.

The fact that people theoretically CAN make clients is not the same as telling them it's a good idea, which is what you are doing.

You mean like, World of Warcraft having both a PC and a Mac client? Or...like something else?

[Margalis]

I mean two different clients that run on the same profile (for example PC) that have different rendering engines and/or logic.

For example a flash client, a text client and an OpenGL client.

[Lum]

People make what could be called third party clients for World of Warcraft constantly. Consider these screenshots (linked for your screenwidth protection):

http://i81.photobucket.com/albums/j233/cihwh/pallyscreenshot.jpg
http://img526.imageshack.us/img526/4871/uilf0.jpg
http://img110.imageshack.us/my.php?image=wowscrnshot053107224940fb9.jpg
http://img.photobucket.com/albums/v453/AEHood74/H1.jpg

The rendering engine is the same, but the interface can be radically changed. Most people consider WoW's mod-friendly interface a good thing.

[Lum]

I mean two different clients that run on the same profile (for example PC) that have different rendering engines and/or logic.

For example a flash client, a text client and an OpenGL client.

A Flash client could be embedded in a web page, a text client could work on a fairly advanced cell phone, and an OpenGL client would be the most visually distinctive/attractive.

[schild]

I'm still waiting for someone to make a WoW gui that just has the game in one corner and the rest is a spreadsheet. I mean, that's what we're working towards at this point anyway.

[Soln]

I think someone answered this once before, but DTLS isn't used?  Wouldn't that help?

[Trippy]

Like how the spell-checker and tag-adder on f13.net uses some Java thing that doesn't work on my corporate laptop.

It doesn't.

[Margalis]

People make what could be called third party clients for World of Warcraft constantly.

Yes, you could call them that if you have no idea what the words "third party clients" actually mean. Luckily I do. All those mods require the WOW client, they aren't "third party clients" and we both know it.

A Flash client could be embedded in a web page, a text client could work on a fairly advanced cell phone, and an OpenGL client would be the most visually distinctive/attractive.

Show me a game you can play in an OpenGL client and a text client that you would actually *want* to play in both. Not two different games that use some of the same backend data, I mean the same actual game.

Quick, what does a WOW text client look like? LOL. Not even Tetris and Worm make sense in a text client.

I understand the theory, but history has defninitely proven that the theory is useless. The only time you want different clients is with wildly different profiles, and usually in the end you end up re-writing the application anyway because when profiles get that different it just doesn't make sense to feed them the exact same application.

Maybe you could make a cell-phone "WOW client" that let you check your mail and auction house but it sure as hell wouldn't be getting the same data as the PC client.

[Lum]

Do you rage this hard against people who complain that your pixel-perfect web designs break their non-standard browser widths?

Data is data. How you display it is up to the client. Unless you believe that *your vision* is the only correct way to display that data. Thus, the WoW mod displays I posted; they display the data (the information from the WoW game servers) in a form different from the vanilla game user interface. Which is the part of the game client most relevant to the user - if the rendering engine is swapped, but invisibly to the user, they won't care. If you went into a user's WoW client and flipped the OpenGL/Direct3D switch, very few would notice.

Another, more relevant example: a high school student in England was miffed that she couldn't talk to her friends in Second Life through her school's firewall, so she made her own light client. Same servers, same data - it just pitches most of the parts it considers irrelevant.

[tmp]

Show me a game you can play in an OpenGL client and a text client that you would actually *want* to play in both. Not two different games that use some of the same backend data, I mean the same actual game.

If I remember right, there's EVE-Online cellphone client in active development (if not finished already) to supplement the 3d client. It's made for people who want to check on their character skill training, received mail, production queues etc. Then there's Anarchy Online where people run special clients that provide functionality of 'channel bot' you get on regular IRC. Finally there's the common dual-boxing in MMOs, where theoretically that other box could be replaced with automated client that doesn't need 3d frontend at all.

The UI customization Lum speaks of is the main convenience factor, though. Not all games come with as flexible internal UI scripting as WoW, for these other games you would indeed need different game client working over the common communication interface rather than convenient script add-on.

[tmp]

Okay, so you can lock down your world great, but will Coke, IBM, Parmount, Universal want  spend their advertising dollars in a system that also hosts goatse world or other worlds that host their copyrighted content.

They didn't pull out of the www because there's goatse and their copyrighted content on some web pages, did they?

[Kaa]

MMO clients are technically open anyway. You can't assume that someone isn't logging into any given MMO with a client they made up themselves. It's actually not that big a hurdle from "make sure every input is sanity tested server-side" to "oh, and don't care if someone logs in with whatever funky client they want".

Well, it's a messy kettle of fish.

Theoretically, yes, you could and should go with a dumb client which is essentially a remote rendering device that also sends you the input events from the user. Such a client could be completely open and wouldn't have any security problems. However for a variety of practical reasons, server load and bandwidth utilization being the main ones, it's very common to offload some processing/decisionmaking onto the client itself. This is where problems begin.

For an example (with which Lum should be very familiar), consider DAoC, a RvR game with stealth. For implementation reasons, the client was sent the information about *all* characters around you, including the stealthed ones, and it just wouldn't display the ones in stealth. Well, if one hacked the client or just sniffed the network traffic, one could completely negate the stealth in the game. DAoC developers and hackers skirmished around this for a long time. Every new patch would break the hackers' solutions and a few days later they'd come up with new ones.

The proper solution was, of course, not to give client the information about the location of the stealthed characters and I think Mythic was eventually forced to do this. This small example, however, shows that MMORGs are generally not set up to deal with open clients. Yes, of course, there is checking the input for sanity and such, but even then speedhacking is surprisingly common. The biggest MMORG at the moment -- WoW -- checks the client machine (!) for things it doesn't like.

I suspect the openness of the client is going to be a problem for some and a boon for others. I would expect some worlds to come with custom, closed clients. I would expect some worlds to be made for bots and bot competitions (Core Wars style, maybe). Angband, a roguelike game, for example, comes with a regular client for humans to play and a bot client for humans to tweak to see how far would it get. And, of course, diku games are very well suited to botting which might prove, ahem, interesting...

Kaa

[Margalis]

If I remember right, there's EVE-Online cellphone client in active development (if not finished already) to supplement the 3d client. It's made for people who want to check on their character skill training, received mail, production queues etc.

I would be very surprised if the EVE cellphone client was just the PC client that didn't render graphics. VERY surprised.

Keep in mind that creating a client for a specific game is very different than creating a new, generic client. Sure, if the EVE network protocols and server are nicely put together you might be able to make an app that lets you check mail and skills without re-coding the back end at all, just log on and make specific calls that get only that data efficiently. But how could you do that if your client is a generic client that runs a bunch of different games?

That is why I used the web browser example, and why the examples Lum came up with don't make sense. Web browser is the right analogy because web browsers run a variety of different apps.

If you are creating a new client for a specific game you can put that specific game knowledge to use. If you are making a new generic client you don't have any specific knowledge to leverage.

It's like adding your own "inventory management UI" to a web browser or Flash. What the hell does that even mean when you are viewing MSNBC.com or watching a Flash movie?

To improve Flash you could make it faster and render at higher quality, add some random features like saving movies to disk easily - other than that you are out of luck. You can't change it to be a chat client or add different spellcasting timers or inventory management or make it able to "check character skill levels" because those are all application-specifc.

Are you going to have a bunch of specific clients that only work with specific apps? Sounds like a nightmare. I don't have 4 different versions of Flash and 5 different versions of Firefox so I can run different apps in them.

Again, the correct analogy is a web browser, Flash player, Java runtime engine or something of that nature. Those are generic platforms, not game-specific clients. What Lum is describing is a generic client that renders markup, not a client tied to a specific well-understood game.

[Krakrok]

Quick, what does a WOW text client look like? LOL. Not even Tetris and Worm make sense in a text client.

What are you talking about? Ascii Quake kicks ass!

[Kaa]

Data is data. How you display it is up to the client. Unless you believe that *your vision* is the only correct way to display that data.

Wallhacking.

Kaa

[Lum]

For an example (with which Lum should be very familiar), consider DAoC, a RvR game with stealth. For implementation reasons, the client was sent the information about *all* characters around you, including the stealthed ones, and it just wouldn't display the ones in stealth. Well, if one hacked the client or just sniffed the network traffic, one could completely negate the stealth in the game. DAoC developers and hackers skirmished around this for a long time. Every new patch would break the hackers' solutions and a few days later they'd come up with new ones.

Except the server never sent packets for the stealthed characters, even on day 1. Why would it? It was a waste of network bandwidth and the server ditched any data on stealthed characters before sending it as part of the update packet for a given character. I know it was a popular misconception, but the client literally never received packets for stealthed characters unless the server registered that that character had decloaked them.

Still, there was a lot of benefits to having a top-down "radar" view, which is why radar clients (essentially a dumbed-down 2D client) were so popular. The best implementation I ever saw trying to break the stealthed-character thing was a client that strobed a character's last position when it thought they went into stealth.

You're correct in that a lot of MMO clients "cheat" and offload some things to the client for performance reasons. Coincidentally, those things tend to map on a one-for-one basis with exploits used in the live environment...

Wallhacking

....only works if the client is getting information about entities obscured by walls. (Which is a necessity in shooters due to client-side prediction)

I would be very surprised if the EVE cellphone client was just the PC client that didn't render graphics. VERY surprised.

Uh... why? A far better implementation would be an RPC server that acted as a gateway to Eve's database, using a web app as a front end on the cellphone side. Eve's probably the most database-driven MMO on the market; its data-driven nature drives most of the gameplay decisions (such as how movement and combat are controlled in a near-stateless manner). I've heard Eve's developers brag about literally 'playing the game' through an Excel spreadsheet. That's about as alternate a client as you can get.

What Lum is describing is a generic client that renders markup

Unless I'm wildly mistaken, I thought that was exactly what Raph is describing, and what I thought we were discussing - developing an "MMO markup language" that was client-agnostic. The entire *point* of Raph's enterprise is a server platform that supports generic web-friendly clients.

[Kaa]

Except the server never sent packets for the stealthed characters.

You're right. I confused a radar hack which showed everyone around you with a no-stealth tool.

Which is also precisely what Raph is describing, and what I thought we were discussing. The entire *point* of Raph's enterprise is a server platform that supports generic web-friendly clients.

Well, the issue is what kind of games will be viable with completely open clients. Habbo-style social environments won't have any problems. 3D shooters are likely to have problems. Given the stress on the third-party, largely amateur game developerment, I would guess that a lot of wannabe game designers/implementors won't be ready for the "client is in the hands of the enemy" attitude...

Kaa

[Lum]

Heh, yeah, agreed there. To be fair I don't think Raph ever described Metaplace as able to handle shooters. They seem to be aimed squarely at the Habbo market. Which in case you missed the memo is FREAKISHLY HUGE.

[Margalis]

I would be very surprised if the EVE cellphone client was just the PC client that didn't render graphics. VERY surprised.

Uh... why? A far better implementation would be an RPC server that acted as a gateway to Eve's database, using a web app as a front end on the cellphone side.

Are you agreeing or disagreeing with me? Isn't that what I said?

Unless I'm wildly mistaken, I thought that was exactly what Raph is describing, and what I thought we were discussing - developing an "MMO markup language" that was client-agnostic. The entire *point* of Raph's enterprise is a server platform that supports generic web-friendly clients.

Every example you've given of a "third party client" was a client (or not) for a specific game, not a generic client.

You are talking about writing specific clients for specifc games. I am discussing writing generic clients for generic markup. (Which I don't think is even MMO specific)

Again, the right analogy is not WOW UI mods or Second Life clients - those are specific clients for specific games. The right analogy is a generic client, such as Flash or a Java runtime. The web browser is an obvious one because it renders markup for a variety of applications.

There are different web browsers but for the most part their differences are more annoyances than anything else. And the major differences are the things like toolbars, tabbed browsing, etc, not the actual rendering part. Different web browsers that render in significantly different fashions are a pain in the ass. (Except for very low-level differences like perf and image quality)

[tmp]

That is why I used the web browser example, and why the examples Lum came up with don't make sense. Web browser is the right analogy because web browsers run a variety of different apps.

Since you mentioned browsers, there's text based web browsers out there. Their existence doesn't make the web page makers try and ensure their creation remains 100% usable through them though, they're just there as option for advanced user who knows what they're getting themselves into.

I'll have to disagree with you here on the 'don't make sense' part. But then I suspect we're looking at this issue from entirely opposite perspectives -- you are speaking of "writing game to work in numerous game clients" while I'd expect it to be the other way around -- custom clients if any are created as add-ons to specific games, to either make the experience easier or to offer subset of functions that do make sense in particular scenarios. Like the mentioned EVE skill checker, the AO chat bots, or the heal monkey for dual boxer.

Also, I'd expect such generic web browser-like client you speak of to be bottom tier of two-tier sort of deal. That is, the "real" generic client can be expected to be pretty much just framework for scripts, which form the other tier and which implement less or more game-specific UI. It's the common interface-implementation model you find in programming, and it's almost exactly what Lum gave as example -- WoW client under the hood *is* to large extent such base for scripts that determine how it behaves in the end. Tackled from this angle the whole drama becomes non-issue, as game developer only has to provide set of scripts that generate appropriate 'default' UI for their particular creation. As lot of UI elements is universal and shared between many games, so can be such UI scripts, making it easier for small game developer to provide set suitable for their game. And if some group of users decide they'd have different UI with more/less/no goatse, they simply replace some of these scripts, while the main client remains unchanged.

This would make more sense with a graph but I really can't be bothered.

[Lum]

Are you agreeing or disagreeing with me? Isn't that what I said?

On rereading, you're correct; I mistook what you said. We agree! Hearts and flowers for all!

Unless I'm wildly mistaken, I thought that was exactly what Raph is describing, and what I thought we were discussing - developing an "MMO markup language" that was client-agnostic. The entire *point* of Raph's enterprise is a server platform that supports generic web-friendly clients.

Every example you've given of a "third party client" was a client (or not) for a specific game, not a generic client.

You are talking about writing specific clients for specifc games. I am discussing writing generic clients for generic markup. (Which I don't think is even MMO specific)

Again, the right analogy is not WOW UI mods or Second Life clients - those are specific clients for specific games. The right analogy is a generic client, such as Flash or a Java runtime. The web browser is an obvious one because it renders markup for a variety of applications.

I think that's something of a red herring. No one comes up with alternate clients for specific markups unless they want to *fix* something (such as freeware PDF viewers to get around Adobe's increasingly bloated client). What Raph's Metaplace is trying to come up with (as I understand it - all I know is the same snippets everyone else does) is a client-agnostic markup so that someone can come in and write a client better than they can. Most people really won't care, because they just want a branded chatroom for their webpage, so will use whatever Flash-based thing Areae provides. The grognards that want to do "UO DONE RIGHT BUT WITH PRECASTING AND CHIMPANZEES" will most likely have more demanding requirements, and if one of their number is sufficiently motivated, they could come up with a dedicated client for just their game, rather than the one-size-fits-all ones provided. Correct me if I'm wrong, but what you're taking umbrage with is that Areae isn't coming up with that specific client, or forcing everyone to use the same client similiar to NWN.

[tmp]

"UO DONE RIGHT BUT WITH PRECASTING AND cockstabbing midgets"

Fixed..?

[Margalis]

I think that's something of a red herring. No one comes up with alternate clients for specific markups unless they want to *fix* something (such as freeware PDF viewers to get around Adobe's increasingly bloated client). What Raph's Metaplace is trying to come up with (as I understand it - all I know is the same snippets everyone else does) is a client-agnostic markup so that someone can come in and write a client better than they can.

 Most people really won't care, because they just want a branded chatroom for their webpage, so will use whatever Flash-based thing Areae provides. The grognards that want to do "UO DONE RIGHT BUT WITH PRECASTING AND CHIMPANZEES" will most likely have more demanding requirements, and if one of their number is sufficiently motivated, they could come up with a dedicated client for just their game, rather than the one-size-fits-all ones provided. Correct me if I'm wrong, but what you're taking umbrage with is that Areae isn't coming up with that specific client, or forcing everyone to use the same client similiar to NWN.

There is an important distinction between markup and data. An alternate client that can display "you have three leather bags" is very different from an alternate client that can display "put leather_bag.jpg at x = 200." You can do a lot with the first, not too much with the second, because the second has no greater meaning and is just a UI instruction.

That's why I keep bringing up HTML and Flash. If someone makes an HTML page that has a bunch of DIVs in it you have no clue what those DIVs represent or how you can display them in some better fashion. They are just DIVs and all you can do is put them where you are told.

If you are writing a specific client for a specific game then either the game is sending over data instead of markup (in which case it isn't using the Metaplace markup at all as I understand it) or you are doing a hell of a lot of work to take apart the UI markup, make sense of it and then re-render it.

HTML is the analogy they use on their site! They repeatedly stress that MetaMarkup is similar to UI markup. I submit to you that writing a specific web client for an HTML game would really suck and be mostly useless.

I think that is our sticking point. You said "data is data" but UI markup isn't data, it's UI markup. Writing different renderers for pure data may make some sense, writing different renderers for UI markup makes very little sense.

[tmp]

There is an important distinction between markup and data. An alternate client that can display "you have three leather bags" is very different from an alternate client that can display "put leather_bag.jpg at x = 200." You can do a lot with the first, not too much with the second, because the second has no greater meaning and is just a UI instruction.

Markup is used primarily to put data in context. The appearance details are just that, details and optional as such. The difference between the <p> and <table> vs style = "ghey_purple" if you will.

In the example you give the client is expected to understand all properties of the inventory bag passed in form of markup, and optionally skip the included details about associated icon etc.

[Margalis]

Markup is used primarily to put data in context. The appearance details are just that, details and optional as such. The difference between the <p> and <table> vs style = "ghey_purple" if you will.

In the example you give the client is expected to understand all properties of the inventory bag passed in form of markup, and optionally skip the included details about associated icon etc.

That isn't how HTML works (more or less, I don't feel like getting into it), and there is no reason to believe that is how Metaplace works.

MetaMarkup is UI markup. That is what their text says and their example shows. Maybe they have some data markup as well but I highly doubt it, in part because the range of possible data for web games is many many orders of magnitude greater than the range of UI markup instructions.

You can create UI out of a very limited number of instructions, but game data comes in infinite variety.

[Raph]

Wow. I suppose I am pleased that this has led to such a large discussion. :)

We are saving lots of details on MetaMarkup for a future blog post, but suffice to say that it exists at two levels: one for "play clients" and another for "tool clients." Tool client ones implement a much larger version of the spec because they need to display serverside backend data to tool clients (and yes, of course there is a permission system on the server as to whether you get this stuff or not). Play clients implement basically a few categories of tags: world tags, place tags, ui tags, object tags, fx tags, and system tags.

You can probably deduce what these each represent, but suffice to say that they are basically ALL "display only" for data coming down. We have shown two examples publicly so far, one which draw an image on the HUD, and another which sent down the name of the world you were logging into.

There will be a minimum compliance set of tags that a client needs to display in order to be functional. Functional does not equal playable, for a given game. The biggest area of compliance, of course, will be on rendering fidelity.

Finally, IMHO, you could do WoW raiding in a text client. I submit to you that many of the high end raiding mods effectively try to do this anyway. ;)

BTW, our lead programmer said the following regarding our markup, for the geeks among you:

A bit more on XML vs MetaMarkup. Network protocols for games and other low-level binary protocols are essentially application specific compression schemes. All of the type and layout data for the packet stream lives in the definition of the protocol and is "well known" by both the client and the server. This allows them to communicate very efficiently, but not not very flexibly or robustly. XML based protocols like SOAP and XMLRPC are the opposite end of the spectrum of network protocols - all of the type and layout data is embedded in every message. This makes them very inefficient, but very flexible and robust. MetaMarkup is literally what the name says - it is a meta-protocol. The builtin types and layout of MetaMarkup behave like a game protocol - although text based, then once the stylesheet has been setup using this efficient baseline, application/game specific communication occurs between the client and server who now have a shared "well known" format for the game they are participating in.

FWIW, the client I want someone to write is one that supports hex grid view. We don't have that yet, and I imagine a lot of folks want it. ;)