Friday, May 25, 2012

Essential Components of the New Framework

What are the components that are absolutely essential to get right in the Ultimate MMO Framework (still need a catchy name)? If had those components today, you'd be using them in your current game, even if you had to integrate them to a bunch of other stuff you have to get a full solution. If we could build those essential pieces, and they were free, I think they would slowly take over the industry, shouldering less effective solutions out of the way. If each piece can be made independent of the others, there is a better chance the system will be adopted even if someone thinks it isn't all a perfect fit.

It is tempting to start with message passing. After all, it isn't an online game without that. But there are a lot of great message passing systems. There might even be some decent event handling systems. And there are definitely some good socket servers that combine the two. While I see problems with these that could be improved, and I see missing features, I think message passing is a second priority. You could make do with an existing system, and swap it out later. Although, I don't know how you can get away from the assumption that you have a publish/subscribe api that the higher levels can use.

More essential is the Entity System. It is where game play programmers interact with your system, and when done well, much of the rest of the system gets abstracted away. The decisions made here are what enable a server to scale, a client to stay in synch, content to get reused in interesting ways, and game play to be developed efficiently. BTW, what I mean by an Entity is a game object. Something that represents a thing or concept in the game world. The term comes from discrete event simulation. Jumping ahead a bit, the Entity System needs to be Component oriented such that an Entity is aggregated from a collection of Components. The Entity State system is the basis of replication to support distributed computation and load balancing, and of persistence. Done well, the Entity System can be used for more than just visible game objects, but could support administrative and configuration objects as well.

Related, but probably separatable is the Behavior system. How do get Entities to do something, and how do they interact with one another? I don't mean AI, I mean behavior in the OO encapsulated-state-and-behavior sense. It will be interesting to distinguish between and tie together AI "plans", complex sequences of actions, and individual behavior "methods". And, of course, the question of languages, scripting and debugging land right here. (A second priority that relates to Behaviors is time management. How do you synchronize client and server execution, can you pause, can you persist an in-flight behavior?)

Content Tools are the next big ticket item. If the Framework is stable enough, a new game could be made almost exclusively using these tools. Close to 100% of your budget would be spent pushing content through them in some imaginary perfect world. These tools allow for rapid iteration and debugging across multiple machines, and multiple platforms. It is not clear how much of the tools can be made independent of Entity state and behavior choices.

What other systems are absolutely essential? They drive everything else? They don't already exist, and you feel like you always have to rebuild them?

What do you think? Wouldn't it be cool to have a standalone Entity System that you could use in your next game? What if it came with a collection of Components that solved a lot of major problems like movement, collision, visibility, containment?

5 comments:

  1. Persistence. Web-based systems have access to broadly-useful technologies like message queues and memcached to help them scale. I haven't seen any MMO platforms do things that are comparably useful.

    ReplyDelete
  2. BTW, second your nomination of using composition for your Entity system. (Says the guy who is mired in Inheritance Hell *yet again*)

    ReplyDelete
  3. Yes entities are probably fundamental. But I wouldn't isolate the Entity approach without also defining some principles about the persistence, distribution/scaling and IO/client event/update model. Perhaps multiple strategies can be supported but they really need to be spelled out. (I'm only saying this because I've made the mistake of trying to shortcut this...)

    Regarding behavior I'd make a distinction between lower-level physical actions - mechanical behavior if you will - and higher-level behavior, including the choices of what actions to perform. AI and player input falls in this latter category, whereas the former falls under "physics simulation" (or maybe rules engine).

    ReplyDelete
  4. This isn't a system in itself exactly, but rather a consideration that should be made for the design of the other systems you mentioned:
    A web-compatible interface to live game systems. Obviously this is primarily a concern for traditional fat client MMOs. Having a RESTful interface is probably a good idea, but I think an argument could be made that MMOs aren't likely to be "internet-scale" in the same way as Facebook for a while yet.
    The sense that I get from the majority of current and prior generation MMOs with native clients is that the ecosystem of web-based first- and third-party games/services/tools was more of an after-thought and that the data driving these services is pulled from non-live databases generated by scraping the live DB.
    This setup is nice from a security standpoint as you limit the avenues for data to enter the DB, and minimize chances of the live DB becoming overloaded for reasons other than game cluster load.
    However web-based direct interaction with the live DB, with write operations as well as read operations, can be a huge help with quickly developing and iterating internal tools as well as supporting third-party services and tools.
    In a world that is increasingly going free-to-play for all new releases integration with social platforms such as Facebook is becoming more essential to gaining a sufficient playerbase. Having a better web-based API can massively improve the quality of these integrations: Imagine if your Lord character in-game could hire dozens of craftsmen or farmers who are actually casual players of your Facebook integration game, and the results of their play translated directly into usable material goods for players of the traditional 3D client.

    CCP is already working along these lines with their CREST API (http://wiki.eveonline.com/en/wiki/CREST_Documentation) and I'm excited to see how it will change EVE.

    ReplyDelete
  5. I'm going to be the testability nerd and add message workflow traceability and metrics. Which message queues are not getting serviced adequately causing backups (there are only so many cores)? Which client requests are failing because they're starved for attention and timing out? (Server should be able to track this without requiring client logs.) Which client requests are being sent more often than they should be? Which messages are stalling because of erroneous services? Which services are failing because of erroneous messages? A message went in but never came out, where did it go? With gobs of such workflow timing information how do I make sense it all? Largely a problem of visualizing the messaging complex. A system that allowed stepwise execution of message flow would be icing on the cake.

    ReplyDelete