I believe definitions is what is going on with this post by "Kressilac" (Derek Licciardi?):
http://blogs.elysianonline.com/blogs/derek/archive/2009/05/29/6400.aspx I'd guess we do hold the same values.
Derek argues that portions of an MMO server are suited to using and best implemented using web technology. I absolutely agree. I call these parts of the system "Game Services". Most would be accessed directly from the client. Examples:
- profanity filtering,
- shard status, open, full, down, locked, capped
- in game search/player online,
- clan/guild management,
- item trade,
- auction,
- voting/elections,
- chat,
- match making/lobby,
- leaderboards,
- persistent messages/email,
- reputation management/community services,
- in-game advertising
- Search,
- authentication,
- CSR account locking
- patching, streaming patching
- microtransactions
- petitions
- custom content
- character annotation, friend lists,
- knowledge base
- voice chat
- Maybe: inventory, quests, crafting (touches in-game entities)
Most of these systems are "decorative" and are for the community aspects of the game.
The complication arises where the data managed by these services is affected by or used by the simulator (I.e. in-game logic). E.g. the number of members of your clan changes Mana recharge rate. I'd suggest that most of those kind of communications are not critical to be transactional or latency critical or can have the game design bent to accommodate that restriction.
There are a couple of those game services (especially those interacting with items) that are entangled. The easiest way to deal with those is to transfer ownership of the Entities in question to one system or the other such that there is no synchronization needed other than at the transfer. I'm betting that is how WoW does auctions and mailing of items.
My "run screaming; it sucks" article is my thinking about the core gameplay/simulator manipulated Entities. What Derek calls Real Time Data. To me that is the "hard problem". All the rest of the stuff can be handled by web-tech, and that is a solved problem (waves hand dismissively), and not so interesting.
Well. There are a few interesting issues, like coordinating authentication. But the coolest payoff (as Derek states) is that these things automatically become available offline via browsers, mobile devices, etc.
BTW, I'm working on another contentious article that more fully details the issues that drive my opinion about DB-centric game state management.
I have written a somewhat lengthy commentary/response to this over on my blog:
ReplyDeletehttp://idempot.net/blog/archives/67-Online-Game-Techniques-and-web-technology/
"Some background before I get on with my point: I read, but only very rarely agree with, Darrin West's blog Online Game Techniques."
Yes, Derek Licciardi == Kressilac. That's a long story but I've been using the alias since 1990 or there abouts so they are in many ways synonymous.
ReplyDeleteThanks for your response to my reply to your post. I too agree that the web services model tends to break down when your simulation server needs access to certain bits of data but I'm not sure we agree on the point where it breaks down. Your example of the clan size impacting mana regeneration is a good one. That should be easily solvable by telling the Add/Drop Member web service methods to add an event to a processing queue on the simulation server. If the Add/Drop Member needs to happen regardless of the mana recharge rate update then decouple the two. The web service API adds the member. The simulation server updates its data upon receipt of the event. You'll need to build in a periodic check to make sure the event wasn't "missed" or use some sort of monitor to ensure event processing by the simulation server but there is no reason why the Add/Drop could be done with a web service and the data owned by the DB behind the web service.
The only client to the game server (as in the entire collection of hardware and software servers that run the total scope of the game) that is not stateless is the 3D client. Every other client is a stateless client. Twitter, Facebook, Metaplace, text messegaing, iPhone apps, guild web sites, official web sites... The challenge as I see it is to put as much of your game server's data in a format that is readily consumable(read, write, delete) by these other head ends and then engineer ways for the 3D client to consume that data. Make the 3D client the only exception to the client implementation paradigm and marginalize the exceptions within it at that. Organize your server architecture such that the home grown technology used in implementing the simulation server is the smallest it can be allowing you to take advantage of things like MSMQ, DB transactions, OpenID, Windows Communication Foundation... (I come from a Windows centric world as you can tell)
That's how I see it at least and from your post here, I think you at least partially agree with me. For discussion: How far do you think you can push game logic into the web services layer while maintaining the "stability" of the game server? The edge cases are where it all gets interesting as you point out so let's talk about them.