Mecha Zeta Project Title:NextGeneration Real Time Internet Game Selfproposed

1
Mecha ZetaProject Title Next-Generation Real
Time Internet Game (Self-proposed)

• Supervisor(s) Dr. C.L.Wang, Dr. W.Wang and Dr.
  A.T.C.Tam
• 2nd Examiner Dr. K.S. Lui 
• Project Members (CE)
• Cheung Hiu Yeung, Patrick
• Sin Pak Fung, Lester
• Wong Tin Chi, Ivan
• Ho King Hang, Tabris
• Yuen Man Long, Sam

2
Project description

• Motivation
• Majority of present large capacity interactive
  Internet games
• Client-Server bottleneck of frequent
  communications
• Pre-computed shadowing
• Approximate collision-detection
• Project goal
• To test the feasibility of developing
  interactive, real and large capacity real-time
  multiplayer games under unreliable Internet
  communication in P2P architecture
• P2P network architecture over the Internet
• Partitioning and P2P synchronization
• Real-time shadowing
• Accurate collision-detection

3
Mecha Zeta

• P2P network architecture
• Cheung Hiu Yeung, Patrick

4
Network Architecture
5
Communication Subsystem

• Communication needed in the game
• Get the data stored in the server when starting
  the game
• Each client needs to recognize the state of the
  game.
• Broadcast controls and position to peers

6
Communication Subsystem

• TCP and UDP available in JAVA
• TCP, reliable connection-oriented transfer, no
  lost, in-order
• UDP, unreliable connectionless transfer
• Decide which one to choose on game purpose

7
Communication Subsystem

• Test result on measuring RTT in TCP and UDP
  implementation in JAVA

8
Client Server communication

• Login and get data when starting game
• Send peer groups game state
• TCP is acceptable as connection is needed

9
Client Server communication

• Server is aware of each coordinator
• If find one coordinator is left, take another
  client as new coordinator
• Send ping message to determine

10
Peers Communication

• Flow of one command

Command from keyboard
Format the command in the game system
Send out the formatted command by network methods
Received the packet and then make update to the
graphics
11
Peers Communication

• Broadcast controls to all other peers
• No connection is needed for dynamic grouping
• UDP is employed

12
Peers Communication

• Recognize status of a peer
• Use ping and customize the UDP

Testing time 30 minutes, Timeout for Ping 3sec,
Time period for retry 4sec
13
Peers Communication

• Reliable transfer is still needed between peers,
  e.g. being attack or firing
• Reliable protocol design
• Stop-and-wait protocol is employed
• Timeout and re-transmission
• Sliding window protocol
• Message size is small, seldom need parallel
  sending to one recipient

14
Peers Communication

• Challenge outburst of controls in client
• Congestion control to prevent congested channel
• Simple rate-based one can be employed
• Define a rate limit at the send channel
• If over limit, reduce the number of packets being
  sent in next frame

15
Peers Communication

• Some other congestion control schemes
• AIMD congestion control
• Used in TCP
• Reduce the rate by half each time a congestion
  comes
• Equation-based congestion control
• Involve complicated calculation
• Increase the work load in complicated game engine

16
Mecha Zeta

• Partitioning
• Sound Engine
• Sin Pak Fung, Lester

17
Network Architecture

• Peer to peer Architecture

18
Partitioning system

• Challenge
• Number of client increases gt increase amount of
  network traffic exponentially, e.g,
• 10 players, 10 x (10 1) 90 messages
• 100 players, 100 x (100 1) 9,900 messages
  lt110 timesgt
• 1000 players, 1000 x (1000 1) 999,000
  messages lt11100 timesgt

19
Partitioning system

• Idea - Send message only to those who need it
• Theory - The game world is partitioned into
  different regions. Each region is named as a
  partitioned area, or a cell.

20
Partitioning system
21
Dynamic VS Static

• A dynamic system
• Initiates the game with one cell
• As the number of player in a cell increases,
  split the cell
• Can control the maximum number of player in a
  cell
• A static system
• Partitioned the world at the compile time
• Will not deal with runtime calculation
• Can minimize calculation at runtime

22
Dynamic VS Static

• Static partitioning is selected, because
• We used P2P architecture, every client should
  know who they need to communicate
• For dynamic system, updating all players upon
  change of cells is required. (that is, updating n
  clients by the server)
• For static system, the partitioned world could be
  pre-calculated and loaded to every client at
  compile time
• Static partitioning is preferred in P2P
  architecture, while dynamic partitioning is
  preferred in client-server architecture
• Sacrifice the control of max. number of player in
  every cell.

23
Design and construction
The Blue Area the area without any overlapping.
Robots here only send message to its cell.
The Red Area the area that is overlapped by
other cells. Robots here need to send message to
its cell, and other associated cells.
The Green Area the area that this cell overlaps
its adjacent cells. Robots over there need to
send their message not only to their cell, but
also to this cell.
24
Working principle

• Robot joining
• Add this robot to a cell
• Send cell information to this robot
• Update other robots in that cell
• Robot movement
• According to their positions at that time, send
  messages to others at particular cell(s)

25
Working principle

• Cell transition
• monitored by the server
• If detected, update the cell ID of this robot
• Update the robots in the new cell
• Remove this robot from the original cell
• Robot exiting
• Remove this robot from the original cell

26
Result

• For 100 players, without partitioning system
• In every update of position,
• 100 (100 1) 9900 messages
• Assume 10 cells are added with 10 players at a
  cell,
• 100 (10 1) 900 messages
• Network traffic could be reduced

27
Discussion

• Determination of cell transition
• Involve heavy computation
• May use coordinator to help monitor
• However,
• Server is still involved in update of other cells
• Unfair
• Dynamic VS Static
• Static partitioning sacrifices the control of
  max. number of player in every cell
• If this control should be stressed in a
  particular game, a dynamic system should be used

28
Sound Engine

• Using JDK 1.2 (making use of java.applet.AudioClip
  )
• Using Java Sound API
• Using Java Media Framework (JMF)

29
Sound Engine

• Little trick - pre-loading the audio clip
• Response time is shortened
• Play, loop or stop at suitable time
• A sound engine is implemented

30
Mecha Zeta

• Synchronization mechanism
• Wong Tin Chi, Ivan

31
Introduction

• The role of synchronization mechanism
• Current design trend
• Synchronization mechanism in Mecha Zeta
• Conclusion

32
The role of Synchronization Mechanism

• Minimize the adverse effect of network delay on
  the simulation.
• Prediction and Correction
• 2 sub-systems
• Consistency protocol
• Synchronization algorithm

33
Focuses

• Performance of Synchronization algorithms on the
  2 aspects
• Responsiveness vs Consistency
• Minimal disturbance to simulation
• Computation and storage overhead of error recovery

34
Current design trend

• Consistency protocol
• State-based
• Command-based
• Synchronization algorithm
• Conservative
• Lockstep
• Chandy-Misra
• Optimistic
• TimeWarp
• Breathing
• Bucket

35
Challenges in Mecha Zeta

• Frequent P2P communications
• Requires fast response
• Responsiveness and consistency
• Disturbance to the simulation
• Large game state
• Computational and storage overhead

36
Synchronization mechanism in Mecha Zeta

• Overall Architecture

• Semantic remark
• Command Command or Event

• Game Clock - NTP
• Command Classification

37
Protocol Algorithm

• Consistency Protocol
• Command-based
• Synchronization algorithm
• Optimistic
• Bucket Synchronization (Hybrid)
• Multi-States Synchronization

38
Bucket Synchronization

• Idea It employs the bucket mechanism to
  buffer the incoming events and commands but
  execute them optimistically. It also reduces the
  no. of game states.

• Inherits
• Buffering (Bucket)
• Command game state achieved for future rollback
  (TimeWarp)
• Threshold (Breathing)

• Advances
• Lower storage overhead (TimeWarp)
• Faster response (Bucket)

39
Bucket Synchronization

• Example

420
Simulation Time
Local Host
400 ms
600 ms
200 ms
Host 2
Host 3
Current Time
Bucket
40
Bucket Synchronization

• Example

470
470
Simulation Time
Local Host
400 ms
600 ms
200 ms
Host 2
Host 3
Current Time
Bucket
41
Bucket Synchronization

• Example

580
430
Simulation Time
Local Host
400 ms
600 ms
200 ms
Host 2
Host 3
Current Time
Bucket
42
Bucket Synchronization

• Example

600
430
470
Simulation Time
Local Host
400 ms
600 ms
200 ms
Host 2
Host 3
Current Time
Bucket
43
Bucket Synchronization

• Example

680
Rollback
260
Simulation Time
Local Host
400 ms
600 ms
200 ms
Host 2
Host 3
Current Time
Bucket
44
Multi-States Synchronization

• Idea Instead of locating the error point in
  case there is a mistake , get data for rollback
  from a parallel execution of the game.

• Inherits
• Buffering (Bucket)
• Command game state achieve for future rollback
  (TimeWarp)
• Threshold (Breathing)

• Advances
• Lower storage overhead (TimeWarp)
• Faster response (Bucket)
• Lower computational overhead

45
Multi-States Synchronization

• Example

500
Current Time
430
450
Simulation Time
Local Host
400 ms
600 ms
200 ms
Pending
S0
Executed
Pending
S0
Executed
46
Multi-States Synchronization

• Example

630
Current Time
450
430
Simulation Time
Local Host
400 ms
600 ms
200 ms
Rollback
Pending
S0
Executed
Pending
S0
Executed
47
Bucket vs MSS
48
Evaluation

• Number of Rollback vs Frequency of command
• Capacity of synchronization algorithms
• PI no. of Rollback at same frequency (70ms)
• Number of Rollback vs Synchronization delay
• Optimizing the consistency and responsiveness
• PI no. of rollback at same delay (100ms)
• Rollback Cost
• Computational overhead
• PI Mean of Rollback cost (ms)

49
Conclusion

• Synchronization delay determines
• Responsiveness vs consistency
• Storage Computational overhead
• Study on synchronization delay dynamically to
  network conditions

50
Mecha Zeta

• Graphic engine
• Collision detection
• Ho King Hang, Tabris

51
Graphic Engine and Collision Detection

• Goals
• Graphic Engine
• Highly Extensible
• Robust Performance
• Have simple interface to be used by other modules
• Collision Detection
• Accurate collision detection in game
• Co-operative detection to achieve high scalability

52
Using Java in Graphics Engine

• What we want - productivity and performance
• Java vs C
• Java offers better productivity and OO structure
• C offers better performance
• From self-constructed benchmarks,
• Java lags 10 performance in OpenGL programming
• Insignificant slow down (lt 1) using JNI for
  collision detection
• Java is suitable

53
Graphic Engine Design

• High Extensibility easy to add other kind of
  objects
• Simple interface for other modules to
  manipulate objects

54
Performance Analysis

• Performance Challenges
• Performance is crucial to give realistic and
  smooth visual experience to players
• Analysis
• Render only objects that are viewable
• Limit amount of objects rendered

55
Performance Optimizations

• Frustum Culling
• Renders only viewable objects
• Increase performance by 67 from benchmark
• Limit amount of object display
• The size of frustum is dynamically adjusted
• Display List for rendering duplicated objects
• Precompile the model rendering to memory
• From benchmark, gt200 performance gain in
  highly-duplicated scenarios

56
Collision Detection System

• Challenges and Analysis
• Overall System
• Many objects in the scene
• Naïve method Pair-wise detection
• Impossible in high scalability scenario
• Accuracy of collision detection
• Exact detection gives players the best realism
• Able to perform well in high scalability scenario

57
Co-operative Collision Detection

• Improvement Co-operative detection
• Each player responsible to own detection
• Eliminates duplicated detections
• Collision events transfer like normal controls
• Efficiency improvement O(n2) to O(n)
• Benchmark result
• 5.5 times faster (in term of FPS) then pair-wise
  method (without rendering robot)
• Dependencies
• Rely on synchronization and reliable protocol
  transfer

58
Collision Detection Mechanism

• 2 types of detection
• Environmental
• Prevent objects from penetrating others
• Bounding Cylinder detection is used
• Attack
• Determine an attack is successful
• High accuracy is important
• Decisive for game results
• Accurate detection is used

59
Collision Detection Design

• Challenge
• Too many objects in the world
• Checking impossible collision -gt waste time
• Need to work properly in real time

60
Candidate Pruning

• Solution Candidate Pruning
• 2-level process
• 1st Level
• Fetch nearby objects from Partitioning System
• 2nd Level
• Environmental and close attack
• Prune those far away
• Distant attack (shooting)
• Ray-Model detection to select candidate
• Huge performance improvement by 4 times in high
  scalability scenarios

61
Ray-Model Candidate Pruning

• Bullet direction is used to select candidates

Selected Candidates
Pruned Candidates
Bullet
Pruned Candidates
Player robot
62
Accurate Collision Detection

• External library ColDet
• Base on collision models
• E.g. Head, Body, Sword,
• Collision models built in initialization
• JNI is used
• Detect two models for collision accurately
• E.g. Sword model to other robots models
• Candidate pruning eliminates large portion of
  detections
• Give very satisfactory performance and excellent
  quality

63
Detection Accuracy for attack

• Challenge Undetected collision may happens!
• Solution Approaching last frame and leaving this
  frame, consider as hit
• 100 accuracy achieved from extensive testing

64
Screenshots of attack collision
65
Evaluation

• Graphic Engine
• Optimization is important
• Simple interface for use by other modules can
  lead to effective development
• Collision Detection
• Co-operative detection
• distributing work load among clients
• Candidate Pruning
• eliminates large portion of unnecessary
  detections
• Real time collision detection possible
• 100 accurate collision detection is achieved

66
Mecha Zeta

• 3D Modeling Animation
• Game Logic
• Shadow Volume
• Yuen Man Long, Sam

67
Overview
68
3D Modeling

• Challenges
• Reusable components
• Flexible animation scheme
• Smooth motion
• Visual quality
• Playability

69
3D Modeling

• Challenges
• Reusable components
• Flexible animation scheme
• Smooth motion
• Visual quality
• Playability

• Model format
• MD3
• Vertex position, normal, texture mapping and
  animation information
• Connect components by Tag

70
3D Modeling
71
3D Modeling

• Feasibility of using 3DS
• No tag structure
• There is unknown in the 3DS file format
  definition
• Inadequacies of MD3
• Number of vertices is fixed
• Frame rate fixed at model building time
• Bounding box is not included

72
Animation

• Challenges
• Reusable components
• Flexible animation scheme
• Smooth motion
• Visual quality
• Playability

• Interpolation frame-skip
• Frame rate for animation fixed
• When display rate gt frame rate
• Interpolate the two adjacent frame
• When display rate lt frame rate
• Frame-skip occurs

73
Animation

• Motion transition
• E.g. a running robot stops
• Current frame of current animation
• First frame of standing animation
• Lower the frame rate for this particular
  interpolation

74
Game Logic

• Challenges
• Reusable components
• Flexible animation scheme
• Smooth motion
• Visual quality
• Playability

• Update physics
• Determine how each robot responses upon external
  event (e.g. being hit)
• Constraints on game
• Control mechanism

75
Shadow Algorithms

• Challenges
• Reusable components
• Flexible animation scheme
• Smooth motion
• Visual quality
• Playability

• Fake shadow
• Vertex projection
• Static shadow
• Shadow volume casting

76
Shadow Volume

• Advantages
• Produce real-time exact shadow
• Can be applied to any landscape (not only flat
  ground)
• Proper self-shadowing
• Support dynamic light source
• Disadvantages
• Significantly reduce the frame rate

77
Shadow Volume

• Draw the objects
• Determine light-facing faces
• From dot product of the face normal and light
  direction
• Cast the shadow volume with the edges of those
  faces onto the stencil buffer in two passes

78
Shadow Volume
One pass
Two passes
79
Shadow Volume

• Problems
• Only support infinity light source
• Low performance
• Popping
• Solution to first problem
• Plane equation light position

80
Shadow Volume

• Performance improvement
• Determine the Silhouette edges
• Require knowing the adjacent faces
• Draw shadow volume only with these edges
• Solution to popping
• Insetting the shadow volume
• Drawing the objects in two passes

81
Shadow Volume
82
Shadow Volume

• Performance analysis
• Platform Pentium III 800MHz, 256MB RAM,
  GeForce2MX400, WinXP, 800X600

83
Shadow Volume

• Conclusions
• Drawing the faces in the shadow casting steps
  (two passes of casting)
• Frequent checking of the stencil buffer bits

84
Overall Evaluation

• P2P network architecture over the Internet
• Complex implementation is adding computational
  and network load.
• Transfer delay is shortened, favorable for highly
  interactive game

85
Overall Evaluation (cont.)

• Accurate collision-detection
• 100 accuracy in attack collision to provide high
  realism
• Co-operative system, candidate pruning makes it
  feasible in real time game
• Graphics Effects
• Real time shadow is only suitable for high
  performance computers
• Complex optimizations have to be done

86
Mecha Zeta

• Q A