1. Server-Oriented Multiplayer Games Presented by: Eric Fesenmaier ecf1@cec.wustl.edu

2. Outline A Short History of Multiplayer Games Architectures for Multiplayer Games Advantages/Disadvantages of Client- Server Client-Server Design Client-Server Design Issues

3. Multiplayer Game History They Had Computers Then? 1958 – William Higinbotham designs two-player pong like game on analog computer and oscilloscope.

4. Multiplayer Game History Sounds like something I played … 1979 – First Multiplayer User Dimension (MUD) is created – a text based RPG. It can handle up to 250 players.

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

6. Multiplayer Game Architectures How should I connect? Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

7. Multiplayer Game Architectures Do I want this model? Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

8. Multiplayer Game Architectures Do I want this model? Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

9. Multiplayer Game Architectures Do I want this model? Client-Client (Peer-to-Peer) Client-Server Server Network (Server Pool)

10. Advantages Why choose Client-Server? Easier to connect Simplicity  Consistency by default  Client and Server separate out functionality Easier to develop Security/Administration

11. Disadvantages Reasons to try something else Server requirements – high bandwidth, high performance Reliability – single point failure

12. Design Generic Multiplayer Game Connect Socket Game State Player Threads Clients

13. Design Generic Multiplayer Game Connect Socket Game State Player Threads Clients events

14. Design Generic Multiplayer Game Connect Socket Game State Player Threads Clients events changes

15. Design Generic Multiplayer Game Connect Socket Game State Player Threads Clients events changes update

16. Design The Actors: Server vs. Client Server  sets up connections  updates state based off current state and events. s n = f(s n-1, event)  sends out updates (when appropriate) Client  sends events (when input changes)  renders updates

17. Design Turn-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.

18. Design Issues Bandwidth & 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

19. Design Issues Dead 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.

20. Design Issues Dead 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

21. Design Issues Dead 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

22. Design Issues Dead 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

23. Design Issues Dead 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

24. Design Issues Dead 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

25. Design Issues Dead 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

26. Design Issues Dead Reckoning Example Two cars in the X-Y plane with constant speed Game State:  X, Y Position  X, Y Velocity  Orientation

27. Why use Client-Server? Scalable Easier to implement Less synchronization issues

28. Conclusion Architectures for Multiplayer Games Advantages/Disadvantages of Client- Server Client-Server Design Client-Server Design Issues

29. Questions???

30. References www.gamedev.net/reference/articles/article722.asp - the essentials of multiplayer games www.gamedev.net/reference/articles/article722.asp staff.cs.utu.fi/~jounsmed/papers/AspectsOfMCGs.pdf – theory of multiplayer games staff.cs.utu.fi/~jounsmed/papers/AspectsOfMCGs.pdf staff.cs.utu.fi/~jounsmed/papers/TR454.pdf – theory of multiplayer games staff.cs.utu.fi/~jounsmed/papers/TR454.pdf www.gamasutra.com/features/19970919/aronson_01.htm – articles and forums on designing multiplayer games www.gamasutra.com/features/19970919/aronson_01.htm warriors.eecs.umich.edu/games/papers/quakefinal.pdf – honors thesis on multiplayer game architecture warriors.eecs.umich.edu/games/papers/quakefinal.pdf www.gamedev.net/reference/articles/article914.asp– cubic splines in multiplayer games (with equations) www.gamedev.net/reference/articles/article914.asp online.redwoods.cc.ca.us/instruct/darnold/laproj/Fall98/SkyMeg/splinepres/sld025.ht m -- cubic splines made easy online.redwoods.cc.ca.us/instruct/darnold/laproj/Fall98/SkyMeg/splinepres/sld025.ht m www.internetgames.com – articles on new games www.internetgames.com www.gamespy.com – articles on the history of multiplayer games www.gamespy.com cec.wustl.edu/~cs333/calendar/Multi-threadServerTutorial.ppt -- multithreaded server diagram cec.wustl.edu/~cs333/calendar/Multi-threadServerTutorial.ppt