How to make a webbased mmorpg

Hello,

After thorough R&D, I came to the decision to develop TGE as follows:

Client:

• canvas/audio/video tags for rendering stuff in the browser
• websockets for network traffic
• javascript as main development language; absolutely no DOM manipulation, except for canvas/audio/video placement
• future development will switch gears to utilize Google Chrome Native Client (NaCl) sandbox for client development once it supports WebSockets, and re-implement client in C/C++Server
  
  • developed in C#
  • utilizes ORM for database object syncing, and liberally-licensed support modules (websocket, http server)
  • designed to run wherever .NET and Mono are available (within reason)
    In short, you need to be able to:
    
    • serve up portions of maps on-demand
    • maintain mini "chatrooms" (i.e. sections of map) which broadcast to all players subscribed to that "chatroom" (i.e. map section) when a player does something
    • render animation on-the-fly
      In the client, HTML5 canvas is suited for this; DOM is not (it's slower). Java is suited for this, but the path to entry (I feel) is significantly more time-consuming than straight JS. Debugging tools are great (Chrome Dev Tools).
      
      In the server, any language which can speak websockets (XHR is an unacceptable fallback, it's not bidirectional. Long-polling/CometD implementations are too cumbersome) is a good choice. Avoid PHP, it's not designed for stateful engine development. If someone can comment on its debugging tools (and a link to a useful tutorial on how to set up Zend? debugger) it'd be much appreciated.
      
      I'd be happy to discuss at length; get in touch if you're interested.

• canvas/audio/video tags for rendering stuff in the browser
  

Canvas may be slow for real-time rendering. Also, I don't think IE8 even supports it; at least very well.
Then again, WebGL is even less supported (but fast where it is).

• websockets for network traffic
  [/quote]
  
  websockets are not particularly well supported right now. If you use websockets, try a wrapping API like socket.io that can fall back to XMLHttpRequest if needed. Or just build everything around double-buffered XMLHttpRequest.
  
  

  • future development will switch gears to utilize Google Chrome Native Client (NaCl) sandbox for client development once it supports WebSockets, and re-implement client in C/C++
    [/quote]
    
    Why?
    
    

    • utilizes ORM for database object syncing, and liberally-licensed support modules (websocket, http server)
      [/quote]
      
      I would strongly recommend against using an ORM. Either use a REST-style document interface, or use real relational semantics. See also: ORM is an anti-pattern and why I don't use ORM which I think state many of the problems I've run into myself.
      
      

      • designed to run wherever .NET and Mono are available (within reason)
        [/quote]
        
        Beware that the garbage collector in Mono may not be as slick as that of Microsoft. Also, last I tried Mono for servers, each asynchronous I/O call (BeginReceive(), etc), spawned a new thread, which ended up being quite inefficient. Still, I'd rather take C# than Java :-)
        

        
        

        • serve up portions of maps on-demand
        • maintain mini "chatrooms" (i.e. sections of map) which broadcast to all players subscribed to that "chatroom" (i.e. map section) when a player does something
        • render animation on-the-fly[/quote]
          
          Sorry, who does what there? It sounds like the first two are server-side, and the third is client-side. However, you've totally missed "game rules" -- a MMO succeeds or fails based largely on its game rules and how it entertains and supports players without being exploitable. This means game rules must be enforced on the server, but the UI for issuing commands must be context aware: don't show a "cast spell X" or "pick up object Y" command if it's not available. Writing all game rules in both JavaScript and C# may be a problem.

• Canvas renders quite nicely
• WebSockets is supported in FF7, Cr14, and IE10 (my engine runs fine in each)
• Cr NaCl decision is targeting a specific platform
• You can strongly recommend against ORM, but can you also strongly recommend a back-end development team that will work for free? My ORM library does what it needs to do, and offloads the burden it was designed to offload. The minimal performance cost is certainly offset by the development convenience.
• Regarding "game rules"; I'm not sure what you're trying to identify, but I'm familiar with client/server methodologies, so ... thanks?
  Granted, some of the technologies used in my gaming platform are bleeding edge, but in a year from now, they will be significantly more commonplace. I'm not releasing the game "tomorrow", or "next week"; my development timeline is designed to align with the coinciding of current technology trends with where I anticipate them to be in a year or two from now.
  
  If you'd like to further discuss how wrong my technology stack is, I'd be happy to do so offline.

If you'd like to further discuss how wrong my technology stack is, I'd be happy to do so offline.

I'm not saying your platform is wrong for your needs. I'm providing other data points, because your description was in response to an original question by another poster, and I think that someone embarking on this kind of work (such as the original poster) needs to understand the different trade-offs.

And, to be fair, all the things I didn't say anything about, I'm totally in agreement with :-) Using HTML5 is great -- Flash is on the way out (and has been for some time). I just wish more browsers that people actually use would support it better. Only 17% of Internet Explorer installs support Canvas and Video! (check out http://www.riastats.com/# ) I also recently wrote a Canvas application that doesn't work at all in IE8 -- the most popular version of IE right now with 25% of all browser share (even though Microsoft literally pay people money to upgrade to 9). This will hopefully get better with time.

Offline discussions don't really help the community understand how different technologies work out for different kinds of projects, though, so I'd invite you to keep posting about your choices, your reasons, and your success/failure as time goes on!