Server-Oriented Multiplayer Games

Presented by:

Eric Fesenmaier

ecf1@cec.wustl.edu

Outline

A Short History of Multiplayer Games Architectures for Multiplayer Games Advantages/Disadvantages of Client-

Server Client-Server Design Client-Server Design Issues

Multiplayer Game HistoryThey Had Computers Then?

1958 – William Higinbotham designs two-player pong like game on analog computer and oscilloscope.

Multiplayer Game HistorySounds like something I played …

1979 – First Multiplayer User Dimension (MUD) is created – a text based RPG. It can handle up to 250 players.

Multiplayer Game HistoryWow!

Coming soon – The makers of Everquest debut Planetside, a Multiplayer First Person Shooter (FPS) capable of handling 3500+ users per server.

Multiplayer Game ArchitecturesHow should I connect?

Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

Network

Client A Client B

Multiplayer Game Architectures Do I want this model?

Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

Client A Client C

Client B

Multiplayer Game Architectures Do I want this model?

Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

Client A

Server

Client C

Client B

Multiplayer Game Architectures Do I want this model?

Client B

Server 1

Client A

Client C

Client E

Client D

Client F

Server 2

LAN

Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

AdvantagesWhy choose Client-Server?

Easier to connect Simplicity

Consistency by defaultClient and Server separate out functionality

Easier to develop Security/Administration

DisadvantagesReasons to try something else

Server requirements – high bandwidth, high performance

Reliability – single point failure

DesignGeneric Multiplayer Game

Connect Socket

Game StatePlayer Threads

Clients

DesignGeneric Multiplayer Game

Connect Socket

Game StatePlayer Threads

Clients

events

DesignGeneric Multiplayer Game

Connect Socket

Game StatePlayer Threads

Clients

events

changes

DesignGeneric Multiplayer Game

Connect Socket

Game StatePlayer Threads

Clients

events

changes

update

update update update

DesignThe Actors: Server vs. Client

Serversets up connectionsupdates state based off current state and

events. sn = f(sn-1, event)sends out updates (when appropriate)

Clientsends events (when input changes)renders updates

DesignTurn-Based vs. Real Time

Turn-Based – Clients only send a message when it is their turn (i.e. card games, board games).

Real Time – Clients continuously send messages. Latency and bandwidth becomes a problem.

Design IssuesBandwidth & Latency

Consider the bandwidth of a 28.8Kb/s modem (28.8Kb = 3.6KB):

3.6 KB/s = 120 bytes/frame30 frame/s

Limits the number/size of messages Average latency nation-wide is 50 – 200 ms An estimation method can resolve these

problems

Design IssuesDead Reckoning with Point-to-Point

Motivation: Clients can only receive 5 – 10 updates/s due to bandwidth, while fluid motion requires 30 updates/s. Also, the updates will be old due to latency.

Solution: Server only send updates when necessary. All clients use an agreed upon estimation method to render the scene until an update is received. This achieves a consistent view.

Design IssuesDead Reckoning with Linear Convergence

Point-to-Point method in example results in jerkiness Clients don’t receive update until later Solution: After receiving new point, create a smooth

path

Design IssuesDead Reckoning with Cubic Splines

Linear convergence looks unnatural. You’d like a smooth path that takes initial and final velocities into account.

“Cubic Splines” are an easy way to fit a curve to some set of points

Whenever you receive an update: Take current point, and the next

estimated point Take the updated point, and

estimate two points in the near future

Use “Cubic Splines” to fit a smooth curves to the points

Equations in referencet0

t1

t2

t2

t3

Design IssuesDead Reckoning with Cubic Splines

Linear convergence looks unnatural. You’d like a smooth path that takes initial and final velocities into account.

“Cubic Splines” are an easy way to fit a curve to some set of points

Whenever you receive an update: Take current point, and the next

estimated point Take the updated point, and

estimate two points in the near future

Use “Cubic Splines” to fit a smooth curves to the points

Equations in referencet0

t1

t2

t2

t3

t7

t8

Design IssuesDead Reckoning with Cubic Splines

Linear convergence looks unnatural. You’d like a smooth path that takes initial and final velocities into account.

“Cubic Splines” are an easy way to fit a curve to some set of points

Whenever you receive an update: Take current point, and the next

estimated point Take the updated point, and

estimate two points in the near future

Use “Cubic Splines” to fit a smooth curves to the points

Equations in referencet0

t1

t2

t2

t3

t7

t8t4

Design IssuesDead Reckoning with Cubic Splines

Linear convergence looks unnatural. You’d like a smooth path that takes initial and final velocities into account.

“Cubic Splines” are an easy way to fit a curve to some set of points

Whenever you receive an update: Take current point, and the next

estimated point Take the updated point, and

estimate two points in the near future

Use “Cubic Splines” to fit a smooth curves to the points

Equations in referencet0

t1

t2

t2

t3

t7

t8t4

t5

Design IssuesDead Reckoning with Cubic Splines

Linear convergence looks unnatural. You’d like a smooth path that takes initial and final velocities into account.

“Cubic Splines” are an easy way to fit a curve to some set of points

Whenever you receive an update: Take current point, and the next

estimated point Take the updated point, and

estimate two points in the near future

Use “Cubic Splines” to fit a smooth curves to the points

Equations in referencet0

t1

t2

t2

t3

t7

t8t4

t5

t6

Design IssuesDead Reckoning Example

Two cars in the X-Y plane with constant speed

Game State: X, Y Position X, Y Velocity Orientation

Client A

Server

Client B

1 mslatency

0 mslatency

Why use Client-Server?

Scalable Easier to implement Less synchronization issues

Conclusion

Architectures for Multiplayer Games Advantages/Disadvantages of Client-

Server Client-Server Design Client-Server Design Issues

Questions???

References www.gamedev.net/reference/articles/article722.asp - the essentials of multiplayer

games staff.cs.utu.fi/~jounsmed/papers/AspectsOfMCGs.pdf – theory of multiplayer games staff.cs.utu.fi/~jounsmed/papers/TR454.pdf – theory of multiplayer games www.gamasutra.com/features/19970919/aronson_01.htm – articles and forums on

designing multiplayer games warriors.eecs.umich.edu/games/papers/quakefinal.pdf – honors thesis on multiplayer

game architecture www.gamedev.net/reference/articles/article914.asp– cubic splines in multiplayer

games (with equations) online.redwoods.cc.ca.us/instruct/darnold/laproj/Fall98/SkyMeg/splinepres/

sld025.htm -- cubic splines made easy www.internetgames.com – articles on new games www.gamespy.com – articles on the history of multiplayer games cec.wustl.edu/~cs333/calendar/Multi-threadServerTutorial.ppt -- multithreaded server

diagram