5

I'm interested in producing some sort of multiplayer RPG as a purely browser based game, with little or no plugin requirements. Having done quite a bit of research I've arrived at the following plan. I'm aware that some of the tech I'm referencing here is not adopted across all browsers ( specifically IE ) but I'm willing to accept that for the moment.

Also - I'm aware that an MMO is a lofty goal to strive for in any case, but having done lots of smaller projects in the past in a similar direction, I feel like I want to give this a really good go finally.

So heres a rough outline, I'd love to hear of glaring problems anyone can see in this arrangement:

CLIENT: WebGL / Javascript ( probably three.js ). Use browser local storage to hold game assets, accepting that deleting the browser cache will remove these.

MESSAGING: encode messages between client / server using google protocol buffers, for convenience and size reduction. Message delivery would be via WebSocket.

GAME SERVER: running on top of gevent in python ( looks to be a good solution for dealing with many concurrents ). Would be built using the sharded pattern, based on the design here:

DB SERVER: MySQL for the database, PHP acting inbetween the game server and the DB.

DETAILS: I intend to have the game server update an individual client roughly 15-20 times per second, and use client-side prediction to fill in the gaps. Clients may send key input / messages to the server in the region of 30 fps. I'd prefer to go for an experience that is as close to realtime as possible, rather than turn-based. My main concern is the TCP based protocol of WebSocket, will this make the whole thing impossible?

Does this solution seem realistic to SO?

many thanks,

bharling
  • 2,800
  • 1
  • 18
  • 25

1 Answers1

1

You generally get 5MB of space with the localStorage API. If you really have a 3D game with sound/music, that's going to get eaten up really quickly by your assets (how big is a good-quality mp3 these days?). You'll need to be super aggressive with compressing your assets and most likely have to come up with a mechanism to stream stuff in and out of local storage while the game runs.

I would ask why you need PHP between the game server and the database. Can't the game server speak directly with the database and save you some work?

Good luck with your project.

danbo
  • 246
  • 1
  • 3
  • 6
  • Ah! Well thats one thing I didnt know straight away, 5mb is quite a limiting factor, so yes some sort of streaming would be in order then. As for the PHP thing, I thought it would make sense to take some of the DB transaction load away from the game server, so that it can concentrate on serving the client as fast as possible, and just periodically fire off chunks of data to be written to DB, without undertaking to format and write that data itself – bharling Oct 26 '11 at 09:06
  • Yup, try looking at the CouchDB, supports REST calls right away. – Anders Oct 26 '11 at 12:48