Virtual Reality over the Internet

1. Virtual Reality over the Internet Virtual Reality Fighter Alex Suo Denny Ma Frank Leung James Lee Raymond Ng

2. Introduction

3. Objectives of the Project • Build a scalable, real-time, flexible 3-D online game with good graphic quality • 3 Key Areas: • Computer Graphics • Internet Communication • Object Definition

4. Fundamental Requirements • Real-time interaction between clients. • Support large amount of users (hundreds users). • Network traffic is minimized. • Models can be dynamically added to the game (optional in program implementation).

5. Master Server Game Server 1 Game Server 2 ……………. Game Server 3 Internet Client 1 Client 2 Client 3 Client n Overall System ArchitectureMulti-Server Architecture

6. Data Store Game Engine Main Game Loop Partition Handler Collision Detection Internet Controller Parser Internet Engine Architecture - Server

7. Graphic Engine Data Store Game Engine Graphic Controller Input Transformer Main Game Loop Input Receiver Internet Controller Internet Engine Parser Architecture - Client

8. Game Engine

9. Why multi-server?? • Distribute the Network Traffic • Distribute the network loading among game servers • But…..this will introduce inter-server network traffic • Inter-server traffic is not frequent • Change partition VS Update position

10. Why multi-server?? • Fewer Requirements on the Servers • Computation is distributed among game servers • Each server will have a smaller loading • Fewer hardware requirements on the server • Even a desktop PC can be a server

11. Why multi-server?? • Distributed Game State • Each server keep a portion of the global game state • One server’s game state corrupt will not affect others • Only recover the corrupt portion

12. Why multi-server?? • More Scalable • Allow new game server join dynamically • Without stop the whole game • Can change the scale easily • Adjust the number of servers in the server group • Theoretically, can support infinite servers • Can support infinite clients

13. Why multi-server?? • Avoid Single Point of Failure • Single server • Server failure  termination of the whole game • Multi server • One server failure  only clients of the failed server will be affected • Master server failure  new servers cannot join the server group and the new clients cannot join the game

14. Why multi-server?? • Efficient Static Partition • Each partition is handled by one server • More detail will be given later in the discussion of partition techniques

15. Features of the Game Engine • Real-Time Interaction • Dynamic • Modularized Architecture • Scalable • Extensible • Flexible Application Layer Protocol

16. Problems and Solutions • How to allow dynamic joining of the game • Generate position that is not occupied • Synchronize the game state before start

17. Problems and Solutions • How to increase the scalability and extensibility • multi-server architecture • system can change to different scale dynamically • flexible application layer protocol • modularized design

18. Problems and Solutions • Application Layer Protocol Design problem • define the message exchange between the client and servers • increase the flexibility  allowed to change easily • underlining network layer has the message encoding and decoding • handler for the new message type can add easily

19. Future Planning • Cluster Architecture • The multi-server architecture can be extended to the cluster architecture • inter-communication delay between the game servers can be minimized • game state can be centralized

20. Future Planning • Flexible and extensible platform • flexibility and extensibility of the game platform can be further enhanced so that the game can evolve over time

21. Advanced Topic: Synchronization

22. The importance of synchronization • interaction between the players is in a real-time • players are not in sync, some strange behavior may arise • synchronization is needed to make sure the game messages are process in order

23. Synchronization mechanism • mainly performed on the server side • keep several snap shots of the game state at different time • keep a list of messages received from the client • time-stamping, time-framing and game state roll-back techniques

24. Features • Message Classification • Two main categories • Critical • Non-Critical • Critical Message will affect the consistence of the game state if the order is reversed • Non-Critical Message will not affect the consistence of the game state if the order is incorrect.

25. Features • Time Stamping • Each network message will have a time stamp • Use to determine the order of the messages • Time Framing • Time will be divided into frames of 100ms • At the end of each frame, a snap shot of the game will be made

26. Features • Game State Roll-back • out of order critical message • Roll-back the game state by cover the game state with the snap shot • Re-execute all the game messages received in order after the roll-back • Maximum Delay Allowed • Maximum delay is 200ms • Message with delay more than 200ms will be noticeable by the players

27. Problems and Solutions • Problem about the time stamping • Need to synchronize the server time and client time • Client record the current time t0. • Client send a time request message to server • Server send back the current time of the server to the client • Client receive the server time and record the current time t1 • Assume the processing time is negligible compare with the network delay, client calculate the time difference due to network delay d = (t1 – t0)/2 • Client calculate the approximate time different between the client and server td = (server time – delay – client time)

28. Problems and Solutions • How to avoid un-necessary synchronization • Too frequent synchronization  consume a lot of processing power • Only the out of order or missed critical message will trigger the synchronization • Un-necessary synchronization can be avoided

29. Problems and Solutions • How to minimize the amount of data backup • trade off between the memory space and the precision of the synchronization • Smaller time frame  more backups • Larger time frame  fewer backups

30. Problems and Solutions • How to classify different message type

31. Problems and Solutions • How to classify different message type

32. Future Planning • Advance Game State Backup • Backups of the game state will consume a lot of memory space • Compress the backups to save memory • Design of special data structure • Consume less memory • More backups can be kept • More precise synchronization

33. Network Engine

34. Game Engine Network Engine Message Serializer Network Resources Architecture

35. Features • TCP Communication • UDP Communication • Redundant messages • Multi-thread support • Fixed-format message • Message encoding and decoding

36. Advanced Topics • Partition techniques • Synchronization

37. Partition Techniques

38. Why partitioning? • Too many clients at one server • Network traffic increase • Irrelevant network traffic • Reduce network traffic

39. Features • Static partitioning • Depends on number of clients • One partition per server • Persistent throughout the game • Balance load among servers

40. Features • Dynamic partitioning • Idea • Divide static partitions into 8 smaller partitions • Applied whenever too many clients within 1 partition • Basic Octree • Non-leaf nodes with eight children • Implemented using array and pointer • Used in computer graphics for collision detection, frustrum culling or hidden surface removal • Here used for reducing network traffic

41. Features • Interest filtering • Neglect uninterested objects • Fighter position forecasting

42. Problems and Solutions • Problem • Clients crossing boundary • Change partition message sent to another server with delay • Clients in new partition don’t know the existence of the new client • Wrong collision detection Solution • Client position forecasting • Clients may exist in both partition near boundary

43. Problems and Solutions • Problem • Search operation is frequent, but slow Solution • Original data structure: array and pointers • Proposed structure: hash map • Use unique partition id as key • Each partition as value

44. Problems and Solutions • Problem • Memory required for keeping each partition • Some are useless Solution • Keep only those partition with clients • Each non-leaf node need not have 8 children • Saves space

45. Evaluation

46. Future Planning • Other partitioning approaches: • Area-of-Interest (AOI-based) • What is AOI? • Group clients with overlapped AOI • Distance-based • Compute distance between clients • Distance metrics, e.g. Euclidean distance • K-means algorithm (clustering in database)

47. Future Planning • Dynamic load balancing • Currently, all new partitions in same server • Future, allocate new partitions to each server • Clients hosted by servers according to server capacity

48. Terrain Modeling

49. Terrain Modeling • Flexible • Users can design and plug in their own model • Render model in the user specified way • 3 stages of terrain modeling

50. Stage 1 • Simple VRML representation • Flexible for users to plug in models • no specific data structure