Search code examples
javascriptphpdatabaseserverreal-time

Inner workings of browser based real-time MMO games

So, suppose there was a game which consisted of a website, and a client that you can launch from said website. I've looked a bit and a relatable example would be Habbo Hotel.

What I'm asking is, what are all the different parts that would make such a game work: for the website part, I'd imagine a server, a database, and some HTML, CSS and PhP coding would be required, but how would the client side operate?

More specifically, how would the client-to-server (and vice versa) real-time communications happen? Suppose the client be coded in C, how would the integration of C into a (I suppose PhP-framed) browser window be executed? Note that the client is never downloaded on the user's PC, so where would it reside?

I'm sorry if these are a lot of questions, if the answers were to be too tedious to compose, feel free to just leave some documentation or tutorials (which I've looked for but haven't really been able to find), I'll happily read them on my own. Thanks in advance.

Solution

  • On one side your question is too broad but on the other side I can give you some pointers of how to do this in a modern way:

    • don't have a client, just a page in a browser
    • use HTML5 canvas, you may also want to look into SPA (single page application)
    • connect via websocket, there are HTML5 javascript implementations and PHP or node.js for the server-side
    • best is, use node.js on the server, PHP would be way too cumbersome
    • via websocket, send and receive JSON objects
    • host node.js on its native platform (Linux)
    • you may want to look into phaser as an HTML5 client-side canvas rendering framework, but it lacks many functionality and is mainly oriented towards twitch-based action games, which don't work well with this architecture because of lag

    this will lead you to one conclusion: javascript is at the center of this system. you'll encounter several roadblocks, such as:

    • security on websockets with SSL for login
    • avoid SSL for real-time data (above 1 Hz)
    • UI on the client inside the canvas is not easy to implement, you'll have to re-invent the wheel or find a UI library for that
    • expect lag, the network code will take some 20%-30% overhead in respect to native C/C# code using TCP/IP or UDP (Lidgren?) and protobuf (Lidgren+protobuf) is what high-frequency AAA titles use (MMORPG or FPS alike)

    From the questions you asked I sense a great lack of understanding and knowledge about the field. I guess you'll have to study some 6-12+ months beforehand. This is what I recommend, because if you start right away you'll make a lot of errors and waste your time. If above are any names you don't know about, search them and study them well. And don't start to code, there is a very steep learning curve ahead of you!

    EDIT: more about server-side

    If you want to implement an action-based interactive game (like an FPS or 2D shooter) I have to tell you this.

    You may want to look into Unity 3D, using directly TCP/IP connections and binary messages (no HTTP, no websocket, instead protobuf).

    C# (client-side) and node.js (server-side) are a good combination. For horizontal scaling you may want to look into cloud computing, docker, provisioning and a lot of server security.

    But this is hostile terrain, it leads you into DevOps territory, which is way off game development. More like an architect's job. Imagine that 3-tier system (client + server + database) has a bottleneck on the server.

    You want to spawn more nodes to handle more clients. This is what EVERY lobby-based game does (LoL, Overwatch, WoT, WoW instances, and so on) and what you do for partitioned maps (e.G. the "maps" in LOTRO, RIFT, many more MMORPGS). Also, to mirror (which means multiple instances of the same map to accomodate an overpopulated crowd).

    To have this kind of horizontal scaling your servers must go online/offline on their own without you clicking around on command and control (e.G. puppet and similar software).

    While this is the ultimate approach, it also has the most steep learning curve, especially because of security (advert DDOS, flooding, slow-loris, fake clients, and the list goes on). A new node must be "provisioned" on the fly (e.G. cloud-config) before it attaches to the cluster and goes online, so there's a whole new world of pain and learning.

    The center-piece of such an elastic cloud-based server system is SSO (single sign-on).