Architecture for social multiplayer browser game (backend choice + frontend choice [flash/silverlight])

Question

Hi there

I'm thinking about developing online multiplayer social game. The shared state of the world would require something fast on the backend, so the potential solutions seem to be:

1. fast game engine on server (eg. c++ ) and some frontend language (php/python/ruby) + flash

2. whole stack in python (using twisted or stackless python) + flash

3. .NET (asp.net or asp.net mvc) + flash

4. .NET + silverlight

first one may be an overkill from productivity point of view (3 heterogenous layers)

Nr. 4 may be programmer's heaven (common environment on all layers), but:

• No such thing has been ever built with Silverlight, maybe there are some showstoppers hiding around the corner
• It may be hard to find silverlight designers
• Despite Flash movie/clip model being criticized when compared to SL full OO architecture isn't it an advantage when it comes to designing extra parts of the virtual world by external designers? They can just prepare .swf with eg. 4 perspectives of an item on 4 frames - wouldn't it be harder with SL?
• Silvelight apparently lacks in some gaming features (like collision detection)

what do you think?

[EDIT] The game itself would be part of the bigger portal - hence it would be nice to integrate the engine with some web framework.

Answer 1

Option 2 -- using stackless Python -- is what Eve Online uses.

http://support.eve-online.com/Pages/KB/Article.aspx?id=128

---

Edit

Until you have actual software, of course, it's impossible to create an architecture that performs reasonably well. So, any judgment here is just idle speculation.

Consider the following, however.

1. Static content (.js files, .css, .png's, etc.) tend to dominate your network bandwidth. You'll have to use a reverse proxy server (e.g., squid) to handle this.

2. Squid has to get the content from somewhere. You want a lightweight file server providing static content to squid. Nginx or lighttpd or something. Apache will work for this, but -- to an extent -- it might be overkill.

3. Your dynamic content -- it appears -- will be in two forms.

   • JSON to support the game.

   • HTML to support the portal.

   For this, you'd be happiest with a mod_wsgi engine. Apache certainly does this; ngingnx and lighttpd might also work.

   • Your JSON stuff should be one set of URI's. REST is a good design pattern. Through mod_wsgi, these connect to the game-oriented server using -- if necessary -- stackless Python. Your front-end (Apache, for instance) has a location, directory or virtualhost to filter these URI's and route them to a mod_wsgi daemon that serves the game. Look at Wekzeug to build this.

   • Your HTML stuff is another set of URI's. Through mod_wsgi, these connect to a Django server running conventional Python. Your front-end (Apache, for instance) has a location, directory or virtualhost to filter these URI's and route them to a mod_wsgi daemon.

Answer 2

Twisted has been used for this purpose with success. Being based on asynchronius calls it's very efficient for applications requiring persistent connections. Also it has a nice RTMP implementation for use with flash. Check chesspark, it's built with Twisted:

http://www.chesspark.com/

Plus the game engine doesn't really have to be in c/c++. Depends on the complexity and type of the game. But there's also the pygame library which is pretty good.

Personally I'd discourage you from using silverlight. The flash plugin is much better adopted and will continue to be in the forseeable future, especially on non ms operating systems. Don't take this to heart but I wouldn't install silverlight just to see your game.

Answer 3

I spent a year working on a massively multiplayer online game using Silverlight for the frontend and Python for the backend (I actually used IronPython in Silverlight so as to simplify development)

Silverlight is very well suited for this, I wouldn't do a serious online game in anything else. It already has 35% of the market, by the time you're done developing it should be high enough not to matter much anymore. For serious games, most people really won't mind installing a 4MB browser plugin. If you just want a little asteroids clone, use flash.

If I had to do it over, I think I would keep Python for the server, because it's the server technology I'm most skilled with, but I think I'd use C# on the frontend and use JSON for passing data.

The best advice I can give you is:

1. Make use of existing libraries and code as much as possible
2. Don't think about performance prematurely

The toughest part is going to be finishing the game, use technology you know well, and optimize for your time, not the code. Hopefully you can do what I could not - finish the damn game :)

Edit

Regarding why I'd use C# if I had to do it over:

IronPython had it's advantages and disadvantages. It was great that I could share code files (constants, models, etc) across server and client. Making a change and refreshing the browser to see it was awesome. Debugging was not as friendly as C#.

But in some ways it's a second class citizen to C#, data binding didn't work, and you can't use IronPython classes in xaml. Loading time was a problem, so I actually spent a great deal of effort to set up importing in parallel on background threads to speed it up. Because of the second citizen status where xaml is concerned, I used a template language to generate the xaml as if it were html, which actually worked out better than data binding, but no python template languages worked in IronPython, so I wrote my own (another time sink.)

To enable sharing models I had to write my own ORM. That was easy enough. But to transfer them I passed on JSON and made an optimized binary format instead that worked between IronPython and Python. That was another time sink.

In hindsight I shouldn't have gotten distracted by all those rabbit trails.