views:

156

answers:

4

I want to implement a bbg which supported large number of members and provided realtime actions.

My current game hasbeen running but its seems burn out shortly.

The method I'm using is polling. I guess the waste of idle user make server burn out (server is in C# and client is Javascript)

How can I do to solve this?

A: 

If you want something to react in realtime, polling isn't going to do the job. Your going to need to use some sort of persistent connection via long running http connections or something. (Comet)

Steve918
I did research about Comet. But it seems that it cannot handle multiple request quite well. I wonder how to implement comet?
thethanghn
A: 

Persistent connections/polling in HTTP can be tricky and as you point out, not very efficient anyway. I'd suggest migrating to a plugin based game that supports server-pushed messages. Maybe Unity since it is basically designed for games but Flash if you want something more ubiquitous.

If you really want to stick with HTML a hybrid solution may work, passing messages via the plugin and rewriting the DOM on responses.

SpliFF
which plugin I can use ?
thethanghn
flash, silverlight, java and unity should all do what you need.
SpliFF
+3  A: 

Perhaps http://goldfishserver.com might be of some use to you (ie a Comet server). It provides a simple API to allow push notifications to your web pages. In short, when your data updates, send it (some payload data) to the Goldfish servers and your client browsers will be notified, with the same data.

Turn-based games are ideally suited for Goldfish, although a more 'large world' system can probably be used, depending upon your design.

Disclaimer: I am a developer working on goldfish.

cmroanirgo
+1  A: 

You will always have some lag. I'm not sure if you are polling for single updates, but you can look at doings some of the following to lower the lag and intense server resource:

  • Poll once for all updates. Don't poll for "number of lives" in one call and "position" in another, do it all in one hit.

  • Poll less as there are less updates. I poll frequently when there are a lot of updates. I poll less frequently when there are none or fewer new updates.

  • Finally, I would send multiple updates with a time for when they happened. So let's say player x moves to 5,5 then attacks someone and moves to 5,8. That would be three different events that come back in one poll. The front end would be responsible for displaying these changes over time in a way that makes sense to a user.

I don't think this is a final solution. This is more of a suggestion on how to handle the polling aspect better.

Markus