I'm trying to decide between keyboard and mouse movement controls for a web-based multiplayer. It would be quite resource-intensive to use the WASD-keys and AJAX the server with controls every second.

Can I implement WASD-key movement and still have the server do all the movement calculations (to deter cheating)?

| improve this question | | | | |
  • \$\begingroup\$ Why would mouse-based controls be any more resource-efficient? Many MOBAs (famously DotA) have mouse-based movement controls: Good players typically spam clicks in huge volumes, sometimes over 100 clicks per minute. Guild Wars allows both types of control interchangeably. Is this even objectively a problem? \$\endgroup\$ – Anko May 28 '14 at 16:58
  • \$\begingroup\$ @Anko The difference is MOBAs like LoL and DotA aren't web browser based. There's a difference between sending an ajax call (if i were to do this ajax but since someone pointed out web sockets, i won't) every half a second that the WASD keys are pressed vs one every 5 seconds or so when the mouse is clicked at a location \$\endgroup\$ – LazyProgrammer May 29 '14 at 0:43
  • \$\begingroup\$ I'm confused now. What relevance does browser-basedness have to the way different control schemes are used? Where do your quoted values come from? \$\endgroup\$ – Anko May 31 '14 at 21:42

WASD is viable because for the best player experience the client (the browser) should be simulating actions based on inputs at the same time the server is verifying inputs as valid and sends you appropriate data back.

To put it in perspective, if you are playing a game and we figure on average it takes 100ms (arbitrarily picked this number - no real significance) for you to get a response from the server after pushing a button, as you already know it is going to feel awful to you as a player to wait 100ms before seeing your action occur on the screen ESPECIALLY when it comes to controlling your character.

So as I said, to resolve this you are going to simulate the action on the client as a best guess while the server validates the inputs. So if the player presses W the client knows that usually that means the character should move forward at a rate of 30 units per second and does so. If the player gets snared by a mob after 1 second but the client doesn't hear about it until 1.1 seconds that's ok because the server would have sent data about this snaring at the same time and as a result you can correct the client and put the player as snared in the correct position as opposed to the estimated position by the client. If your client is simulating properly, unless there is major lag the corrections should be minimal and possibly unnoticeable altogether.

Yes this approach means that the player could potentially do some silly client side trickery to make his game client do hackish things, but these hackish things won't actually occur on the server and your server isn't going to send back data that the player wouldn't otherwise normally be able to see because you you've confirmed everything server side. No hacks should get by if you've programmed the systems correctly.

It is my understanding that this is how a lot of games do it and it should work for your game as well. A really good read on this approach has been published by Valve for the Source Engine. You'll find a lot more technical information in that article and much more specific scenarios and other such information that you should find useful.

So to finally answer your question, yes you can implement fluid WASD controls while processing all your data server side (with client side simulation) to prevent hacking. You are not limited to only mouse movement.

| improve this answer | | | | |
  • \$\begingroup\$ Pretty sure i know the answer to this but just in case, for MMOs, it's generally better to use TCP instead of UDP right? So websockets can probably do the job. Not sure if websockets are able to use UDP, i'm just assuming the websockets is strictly tcp \$\endgroup\$ – LazyProgrammer May 28 '14 at 6:00
  • \$\begingroup\$ There are arguments on all sides on what sort of networking protocol to use. I'd recommend searching the site and reading this blog post \$\endgroup\$ – SpartanDonut May 28 '14 at 6:11
  • \$\begingroup\$ @LazyProgrammer MMOs generally use a mix of UPD and TCP. However, as this is a browser game using JS and HTML, you'll be using TCP exclusively. \$\endgroup\$ – DampeS8N May 28 '14 at 15:22
  1. When you are OK with excluding Internet Explorer 9 and below, you might consider to use WebSockets instead of AJAX. It is much more suitable for real-time games.
  2. You do not need to notify the server every tick which key the user is holding down. It's enough to tell the server when the user starts pressing it and when the user is releasing it. The release-command should be accompanied by an exact position to avoid inconsistencies of the traveled distance due to fluctuating latency.
| improve this answer | | | | |
  • \$\begingroup\$ Doesn't the server need to know where the player is going so that it can render the background accordingly? Or would this be under the assumption we're using web sockets? \$\endgroup\$ – LazyProgrammer May 28 '14 at 0:48
  • \$\begingroup\$ @LazyProgrammer generally speaking, yes, but that does not imply that the server needs to know every player movement, especially for real-time updates. For example, panning in Google Maps does not require sending every mouse movement to the service; instead the client has data for areas surrounding the current screen so that small pans appear seamlessly to the client, and when the client pans far enough, a request is sent to load a batch of data around the new location. \$\endgroup\$ – congusbongus May 28 '14 at 1:48
  • \$\begingroup\$ @LazyProgrammer The server doesn't need to "render" anything. The graphical representation is the responsibility of the frontends. \$\endgroup\$ – Philipp May 28 '14 at 3:22

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.