I'm in the very early phases of developing a browser based MMOG, kinda like this game but not as cartoonish and with more features. I'm an experienced web developer, yet not once have I ever used websockets.

Are websockets required for something like this?

  • \$\begingroup\$ Do you know what language and framework you are going to use? \$\endgroup\$ – AturSams Jan 9 '15 at 19:47
  • \$\begingroup\$ I would like to use Javascript with a PHP & MySQL backend. I'm also heavily considering using WebGL for image rendering \$\endgroup\$ – Robert Jan 9 '15 at 20:26
  • 1
    \$\begingroup\$ I am adding an answer to point out some important differences Phil didn't mention in his answer. \$\endgroup\$ – AturSams Jan 10 '15 at 11:31
  • \$\begingroup\$ You could use a library that abstracts over different transports, like sock.js? \$\endgroup\$ – Anko Jan 13 '15 at 20:17

ajax / html request

Slowpoke. Good for loading pages without navigating to another url. No good for action games but should be fine for turn based games I imagine. That is unless it's a very fast paced turn based game (think roguelike fast).

The good thing is that the server only needs to handle one request at a time. So the server code is serial and not concurrent. This means it's a lot less complicated. Each request is often processed in an infinitely short amount of time. I think the default limit is something like 15 seconds. The point being the server grabs a request, starts working on it and only it, and is done after a short while.


Fast and responsive, great for action games. The server needs to handle all clients simultaneously (concurrently) and ceaselessly. This means possibly more processing power and more memory. This means that you are running a process that doesn't stop supposedly ever (PHP isn't oft for such processes). You need a reasonably powered machine with serious bandwidth capability. This is considered more resource intensive.

The code is also far more complex and often requires threads or chunking up the work into small portions and supporting multiple user request in parallel. Both threads and chunking up the workload into small pieces make the code somewhat more complicated and harder to debug.

Please be aware that this means the devs need prior experience with either threads or what is basically an implementation of threads as a serial program. Also considering that most server CPU's nowadays have a bunch of cores, using threads is possibly preferred.

Side-note: Generally, an indie socket based game + server could cost could somewhere in the tens of thousands of dollars to develop. This is because of the graphics and client-side programming any game would require plus the added costs of developing a stable server.

  • \$\begingroup\$ If I were to do a single player game kinda like this one, would PHP & MySQL ad AJAX be ideal for it? \$\endgroup\$ – Robert Jan 10 '15 at 15:18
  • 2
    \$\begingroup\$ @Robert This could work, you might consider Google App Engine for scalibility. Single player is not demanding. The heavy lifting with multiplayer is making sure everyone is experiencing the same world at the same time. This is pretty hard. Think about some of the MMO you know and realize a lot of them let most of the action occur within an instanced zone so they only need to keep a few player synchronized and that enables them to cut back on resources and improve responsiveness. \$\endgroup\$ – AturSams Jan 10 '15 at 19:45
  • \$\begingroup\$ Ok. That's probably what I'll do then, just do a single player game. That'll give me the chance to actually learn how to do one and continue to learn more about how to do a MMOG later on. Thanks alot for the advice and help. \$\endgroup\$ – Robert Jan 10 '15 at 20:24
  • 1
    \$\begingroup\$ @Robert - Sure thing, making indie games is a lot like building a camp fire, you want enough logs to keep the flame alive but you don't want too many logs to stifle the fire. Think about the fun factor, make the fun things that are important for your enjoyment as a player. Leave the boring stuff for tomorrow. \$\endgroup\$ – AturSams Jan 10 '15 at 20:28

Websockets are a very elegant and fast way to implement asynchronous communication between client and server. But they are far from the only. When low latency isn't that important for you, you can substitute it with XmlHttpRequest (aka "AJAX").

But for a real-time action-oriented game, WebSockets are usually the superior solution.

  • \$\begingroup\$ Awesome, thanks. You wouldn't happen to have a resource link to where I can learn the API for them would you? \$\endgroup\$ – Robert Jan 8 '15 at 15:01
  • \$\begingroup\$ @Robert: For the client-side: developer.mozilla.org/en-US/docs/WebSockets. I never used websockets with PHP, so I can not help you with that. \$\endgroup\$ – Philipp Jan 8 '15 at 15:04
  • \$\begingroup\$ I'm not entirely sure PHP uses websockets honestly. I've never seen PHP mention them. Of course, I just now discovered sockets so I could just be behind. Thanks for that link \$\endgroup\$ – Robert Jan 8 '15 at 15:07
  • \$\begingroup\$ You might be interested in this talk I gave last year at HTML5DevConf: "More Than Just WebSockets for Real-Time Multiplayer Games and Collaboration". Video and slides available at blog.lightstreamer.com/2013/12/… \$\endgroup\$ – Alessandro Alinone Jan 9 '15 at 9:49
  • \$\begingroup\$ @Robert PHP is not used with sockets, it's for http requests. How were you planning to develop the game server? \$\endgroup\$ – AturSams Jan 9 '15 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.