300 likes | 479 Views
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.
E N D
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)
Multiplayer Game ArchitecturesDo I want this model? • Client-Client (Peer-to-Peer) • Client-Server • Server Network (Server Pool)
Multiplayer Game ArchitecturesDo I want this model? • Client-Client (Peer-to-Peer) • Client-Server • Server Network (Server Pool)
Multiplayer Game ArchitecturesDo I want this model? • Client-Client (Peer-to-Peer) • Client-Server • Server Network (Server Pool)
AdvantagesWhy choose Client-Server? • Easier to connect • Simplicity • Consistency by default • Client 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 Player Threads Game State Connect Socket Clients
DesignGeneric Multiplayer Game Player Threads Game State Connect Socket events Clients
DesignGeneric Multiplayer Game Player Threads Game State changes Connect Socket events Clients
DesignGeneric Multiplayer Game Player Threads Game State update changes Connect Socket update events update update Clients
DesignThe Actors: Server vs. Client • Server • sets up connections • updates state based off current state and events. sn = f(sn-1, event) • sends out updates (when appropriate) • Client • sends 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/frame 30 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 reference
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 reference
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 reference
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 reference
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 reference
Design IssuesDead Reckoning Example • Two cars in the X-Y plane with constant speed • Game State: • X, Y Position • X, Y Velocity • Orientation
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
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