I have always been a big fan of the guys running Vendetta Online. They are one of the only indie teams I’m aware of that have successfully built an MMO game and turned a profit. What’s more, they seem to use the right tools for the job, know what they are doing, built a solid game and interact very well with the user community. I guess those are the keys to success for an indie MMO.
I’m at the stage where really I just need to use the right tools for the job. In most respects, I believe that good games are timeless (1 2) – I’m not concerned about a decade of development time. So I can take all the time I want and I’ve spent the last few years researching the right tools for scalable game development. Like the developers of Vendetta discovered, all roads lead to Erlang. It seems to have become the de-facto standard for highly-available, scalable, reliable applications. Engineers building an MMO would be foolish to not strongly consider Erlang for their backend. And all of Erlang’s strengths are based on a single premise: components should be simple, well separated and communicate through messages.
This is great, because it’s what I’ve been planning for the engine. The best game engine design currently devised seems to be Entity Systems. While there are many competing implementations and ideas of exactly what an Entity System is, the experts seem to agree that all game objects need to be divided by function. Each component of an object manages one facet of the object and communicates with the rest of the components. The method of communication is up to the developer, but why not simple messages? This forces separation between components and greatly simplifies a number of major design headaches: networking/serialization, logging/debugging and multi-threaded performance. The client and server can be built upon a common messaging standard.
I’m hoping that this strategy will be successful, because it allows me to more effectively utilize my resources (i.e. my extremely limited free time). I can build a very simple server architecture which accepts client messages and then put server development on hold. Next, I’ll build a playable client with all game objects communicating via messages. When it finally comes time to start connecting clients to one another and building a game world, all the messages will already be there. The client NetworkManager will just need to filter out unneeded messages and forward the remainder to the server. Any messages coming from the server will look just like the local messages the client is already using.
In the end, I should have a game world which transparently scales across as much hardware as I can get my hands on and handles a large number of clients. If it turns out my code just isn’t up to snuff, or each game area has too much activity for slow network connections, I hope to be able to compromise by allowing smaller groups of clients into any given game area. Even a single client per area may be entertaining if I build the rest of the social aspects correctly. This is my fallback plan and the likely goal for initial releases.
I haven’t found anyone using Erlang for the client, and I don’t think I have a reason to try, either. That’s not its strong suit, there are not the proper library bindings and it’s not even clear there would be performance benefits. I can use a separate thread for each component system and easily scale to 8+ threads. That is plenty considering a lot of modern games get by with one or two.