Inspired by BrowserQuest, I want to try my hand at making my own kind of game like this but I don't really know anything about game development other than the basics, like how the game loop works. Although, I feel more than confident with server-side/client-side JS so it's mostly just about learning concepts for me.

Some questions I've had so far when thinking about how I'll go about implementing it:

  1. I understand there'll be unsynced client-side code and synced server-side code. If a player presses an arrow key on their keyboard, should it send that information to the server, then the server says it's ok, then the client does it? Or should the client just do it anyway then the server validate it after-the-fact and correct the client if they perform an invalid action?
  2. The data going between server and client will initially be very simple. Currently I just have x and y positions for players. But how often is it ok for clients to send this data back to the server and the server to broadcast the data to all clients? I could do these things every 1ms which would make everything as smooth as possible, but wouldn't this kill the client/server or at least use a truck-load of bandwidth? I only have a very small VPS and wouldn't want to overload it by sending 1000 JSON objects to a bunch of clients every second when I don't have to. What's the sweet-spot here?
  3. I want to include some PvP style combat in my game but am not sure if the websocket protocol is suitable for this. With UDP, data is sent back and forth super fast partly in thanks to its unreliable nature, right? With websockets, will the communication between clients/server be fast enough to process something like a player attacking another player?

Any other advice about this sort of thing would be great, even if it's just links to existing documentation/examples. Cheers.

  • \$\begingroup\$ You are having three different questions. In the future you might want to avoid this and ask three separate questions instead. \$\endgroup\$
    – Philipp
    Commented Mar 13, 2017 at 14:41
  • 1
    \$\begingroup\$ Start here \$\endgroup\$
    – Bálint
    Commented Mar 13, 2017 at 14:52

1 Answer 1


1: Should the client wait for confirmation before moving the player?

Websockets use the TCP protocol, which can have very irregular latencies from time to time (which is usually why UDP is recommended for real-time games, but that's not available to browser-based Javascript). When the reaction to each input is not just delayed but delayed irregularly, your game will seem very unresponsive and laggy to the player. So if you can predict with reasonable sincerity that the server will confirm an action, you should execute it without waiting for that confirmation.

2: How often to send data to the clients?

Only send data when something has actually changed. Sending "Bob is still standing on 45:67" every millisecond is quite pointless. Only send a message when Bob started moving and another when Bob stops moving or changes direction.

Most online game servers run with a fixed number of ticks per second (usually something between 10 and 100). The ideal tick-rate depends on the game and is something you need to find out through test-play, but usually the more action-oriented a game the more does it benefit from a higher tick-rate.

3: Is Websocket fast enough for PvP combat?

I'm sorry, but that's impossible to answer. It depends too much on the combat system of your game and on how good the internet connections between your players and your server are. But considering that you seem to be on a tight budget and thus likely can't afford top-notch peering in local datacenters all around the globe, you might want to go for a combat system which emphasizes strategy and tactics over reaction speed and dexterity.

Any other advice about this sort of thing?

You want to build an MMORPG all by yourself? If you are just doing it for the learning experience, then go for it! There is a very wide variety of useful skills to pick up in the process. But don't expect it to be successful.

I also developed an MMORPG all by myself. And it actually worked quite well. After a few years of after-work and weekend development, the technology was practically feature-complete. I even had a bunch of working maps and a fully functional tutorial. But then I realized that if I want to manage an MMORPG the way it deserves, I don't just need to quit my day-job but also hire a whole bunch of people to create content and manage the community. I wasn't ready and willing for that kind of commitment. So I mothballed the project.

I don't regret the project at all. Most of what I know about Java, JavaScript, WebSockets (wrote my own implementation. It was as educating as it was painful) MongoDB and Linux server administration did I pick up in the course of that project. But just don't think that this project will make your rich or even financially independent, unless you are able and willing to invest a lot of money into it.

  • \$\begingroup\$ Really helpful, thanks. The kind of PvP I had in mind was sort of like classic Zelda game style combat. E.g. player swings with a sword and enemy is damaged and knocked back. I wanted to know if websockets would allow for this kind of multiplayer combat to feel good or if it would end up feeling like badly written netcode combat like Minecraft, where players just spam attack and hope the server registers a hit. \$\endgroup\$
    – Jazcash
    Commented Mar 13, 2017 at 15:09
  • 1
    \$\begingroup\$ @Jazcash Unless you can afford a local realm hosted on an own server in every larger city in the world, it will likely be more like Minecraft. \$\endgroup\$
    – Philipp
    Commented Mar 13, 2017 at 15:14
  • \$\begingroup\$ I'm just dropping by to point out that you should check out WebRTC for high performance communication between clients. See here for some more information: stackoverflow.com/questions/18799364/… \$\endgroup\$
    – Alex
    Commented Mar 13, 2017 at 21:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .