Game Development Reference
In-Depth Information
For more information on lock-step, check out
http://www.
altdevblogaday.com/2011/07/09/synchronous-rts-engines-
and-a-tale-of-desyncs/
and
http://www.altdevblogaday.
com/2011/07/24/synchronous-rts-engines-2-sync-harder/
.
For more information about client-server prediction, check out
http://
gafferongames.com/networking-for-game-programmers/
what-every-programmer-needs-to-know-about-game-
networking/
.
To learn about interpolating between authoritative and client states, see
http://www.gamedev.net/page/resources/_/technical/
multiplayer-and-network-programming/defeating-lag-
with-cubic-splines-r914
.
There is a great Google Tech Talk by
Rob Hawkes
on HTML5
multiplayer game development with many tips about overcoming
common pitfalls. You can watch it at
https://www.youtube.com/
watch?v=zj1qTrpuXJ8
.
Technologies
The Web Sockets API (
https://developer.mozilla.org/en-US/docs/
WebSockets
) is the most practical way to maintain a fast connection with a game
server in JavaScript, and the easiest way to use web sockets is to use node.js
(
http://nodejs.org/
) on the server with the socket.io library (
http://socket.
io/
). Node.js allows JavaScript to be a first-class server-side language, so you can
write your game code once and worry less about differences between the server-side
and client-side simulations. It's also mentally easier to write both the server-side and
client-side code in a single language.
Web sockets are the best we can do at the moment because
JavaScript doesn't have as much control over how it accesses the
Internet as desktop and console games do, for security reasons. Web
sockets are actually reasonably good, but they are based on
TCP
,
which is a common way to access the Internet that ensures reliability
but occasionally causes delays. Many desktop and console games
that use client-server prediction use
UDP
to access the Internet
instead, which serves the same purpose as TCP but compromises
data-integrity guarantees in favor of minimal delays.
