Post on 03-Feb-2016
description
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, LesterWong Tin Chi, Ivan
Ho King Hang, TabrisYuen Man Long, Sam
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
Mecha Zeta
P2P network architecture
Cheung Hiu Yeung, Patrick
Network ArchitectureServer
Client
Client
Client
Client
Coordinator(also a client)
Coordinator(also a client)
Client
Client
Client
Coordinator(also a client)
ClientClientClient
Diagram showing the whole network architecture
server
Communication Subsystem
Communication needed in the game Get the data stored in the server when st
arting the game Each client needs to recognize the
state of the game. Broadcast controls and position to peers
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
Communication Subsystem
Test result on measuring RTT in TCP and UDP implementation in JAVA:Trials TCP Connection
RTT (ms)UDP Datagram RTT (ms)
1 261 40
2 311 100
3 300 120
4 891 60
5 300 timeout
Client Server communication
Login and get data when starting gameSend peer groups’ game stateTCP is acceptable as connection is needed
Client Server communication
Server is aware of each coordinatorIf find one coordinator is left, take another client as new coordinatorSend ‘ping’ message to determine
Server
Coordinator(also a client)
Coordinator(also a client)
Coordinator(also a client)
server
Peers CommunicationFlow of one command:
Received the packet and then make update to the graphics
Format the command in the game system
Command from keyboard
Send out the formatted command by network methods
Peers Communication
Broadcast controls to all other peersNo connection is needed for dynamic groupingUDP is employed
Coordinator(also a client)
Client
Client
Client
Peers Communication
Recognize status of a peerUse ‘ping’ and customize the UDP
No. of Times sending a ping message Time for failure of a ping (min)
1 3
2 14
3 29
4 No failure in testing time
Testing time: 30 minutes, Timeout for Ping: 3sec, Time period for retry: 4sec
Peers CommunicationReliable transfer is still needed between peers, e.g. being attack or firingReliable protocol designStop-and-wait protocol is employed Timeout and re-transmission Sliding window protocol
Message size is small, seldom need parallel sending to one recipient
Peers Communication
Challenge: outburst of controls in clientCongestion control to prevent congested channelSimple 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
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
Mecha Zeta
PartitioningSound Engine
Sin Pak Fung, Lester
Network Architecture
Peer to peer Architecture
Server
Client ClientClientClientClient
Client-Server communication
Peer to Peer communication
Partitioning system
Challenge:Number of client increases => 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 <110 times> 1000 players, 1000 x (1000 – 1) = 999,000 messages <11100
times>
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.
Partitioning system
Server
ClientClientClient
Client-Server communication
Peer to Peer communication
ClientClientClient
A cell
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
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.
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.
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)
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
Result
For 100 players, without partitioning systemIn 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
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
Sound Engine
Using JDK 1.2 (making use of java.applet.AudioClip) Using Java Sound API Using Java Media Framework (JMF)
Sound Engine
Little trick - pre-loading the audio clip Response time is shortened
Play, loop or stop at suitable timeA sound engine is implemented
Mecha ZetaSynchronization mechanism
Wong Tin Chi, Ivan
Introduction
• The role of synchronization mechanism
• Current design trend• Synchronization mechanism in Mech
a Zeta• Conclusion
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
Focuses
Performance of Synchronization algorithms on the 2 aspects Responsiveness vs Consistency Minimal disturbance to simulation
Computation and storage overhead of error recovery
Current design trend
Consistency protocol State-based Command-based
Synchronization algorithm
Conservative Lockstep Chandy-Misra
Optimistic TimeWarp Breathing Bucket
Challenges in Mecha Zeta
Frequent P2P communications Requires fast response
Responsiveness and consistency Disturbance to the simulation
Large game state Computational and storage overhead
Synchronization mechanism in Mecha Zeta
Overall Architecture
Rollback
Game States (G1)
Game States (G1)
Commands + Events (E0)
Commands + Events (E0)
Game States (G0)
Commands + Events (E0)Synchronization
Engine
Game Engine GameState Engine
Game Clock - NTPCommand Classification
Semantic remark: Command = Command or Event
Protocol & Algorithm
Consistency Protocol Command-based
Synchronization algorithm Optimistic
Bucket Synchronization (Hybrid) Multi-States Synchronization
Bucket Synchronization
Inherits Buffering (Bucket) Command & game state
achieved for future rollback (TimeWarp)
Threshold (Breathing)
AdvancesLower storage overhead (TimeWarp)
Faster response (Bucket)
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.
Local Host Simulation Time
400 ms 600 ms200 ms
Bucket Synchronization
Example
Local Host
Bucket
Simulation Time
400 ms 600 ms200 ms
Current Time
400 ms 600 ms200 ms
400 ms 600 ms200 ms
Host 2
Host 3
420
Bucket Synchronization
Example
470Local Host
Bucket
Simulation Time
400 ms 600 ms200 ms
Current Time
400 ms 600 ms200 ms
400 ms 600 ms200 ms
Host 2
Host 3
470
Bucket Synchronization
Example
Local Host
Bucket
Simulation Time
400 ms 600 ms200 ms
Current Time
400 ms 600 ms200 ms
400 ms 600 ms200 ms
Host 2
Host 3
430
580
Bucket Synchronization
Example
Local Host
Bucket
Simulation Time
400 ms 600 ms200 ms
Current Time
400 ms 600 ms200 ms
400 ms 600 ms200 ms
Host 2
Host 3
600430
470
Bucket Synchronization
Example260
Local Host
Bucket
Simulation Time
400 ms 600 ms200 ms
Current Time
400 ms 600 ms200 ms
400 ms 600 ms200 ms
Host 2
Host 3
680RollbackRollback
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)
AdvancesLower storage overhead (TimeWarp)
Faster response (Bucket)
Lower computational overhead
Multi-States Synchronization
Example
Local Host Simulation Time
400 ms 600 ms200 ms
Current Time 500
PendingS0 Executed
PendingS0 Executed
PendingS0 Executed
430
450
Multi-States Synchronization
Example
Local Host Simulation Time
400 ms 600 ms200 ms
Current Time 630
PendingS0 Executed
PendingS0 Executed
PendingS0 Executed
450
430
RollbackRollback
Bucket vs MSSBucket MSS
Responsive and Consistency
Visually instant response Adjustable consistency
Same as Bucket
Disturbance to simulation
Locating point of recovery
Background calculation
Computational and storage overhead
No threading Same storage overhead
Reduced computation on locating recovery pointSame storage overhead
Conclusion :
Computational overhead as a cost of disturbance Bucket Synchronization – P2P synchronization MSS – Client-Server synchronization
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)
P.I.
Bucket 14
MSS 15
P.I.
Bucket
18
MSS 14
P.I.
Bucket
34.14
MSS 20.78
Conclusion
Synchronization delay determines Responsiveness vs consistency Storage & Computational overhead
Study on synchronization delay dynamically to network conditions
Mecha Zeta
Graphic engineCollision detection
Ho King Hang, Tabris
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
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 (< 1%) using JNI for collision d
etection Java is suitable
Graphic Engine Design
High Extensibility – easy to add other kind of objectsSimple interface – for other modules to manipulate objects
Graphics Renderer
TerrainObject
2DObject
2DGraphics 2DText
MZMecha MZBullet
extends
extends
MZSceneObj
Terrain detail
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
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, >200% performance gain in hi
ghly-duplicated scenarios
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
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
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
Collision Detection Design
Challenge:
Too many objects in the world
Checking impossible collision -> waste time
Need to work properly in real time
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
Ray-Model Candidate Pruning
Bullet direction is used to select candidates
Bullet
Pruned CandidatesPlayer robot
Selected Candidates
Pruned Candidates
Accurate Collision Detection
External library: ColDetBase on collision models
E.g. Head, Body, Sword,…
Collision models built in initializationJNI is used Detect two models for collision accurately
E.g. Sword model to other robots’ models
Candidate pruning eliminates large portion of detectionsGive very satisfactory performance and excellent quality
Detection Accuracy for attack
Challenge: Undetected collision may happens!
Solution: Approaching last frame and leaving this frame, consider as hit100% accuracy achieved from extensive testing
Previous frame Current frame
Robot Robot
BulletBullet
Screenshots of attack collision
EvaluationGraphic 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
Mecha Zeta
3D Modeling & Animation
Game Logic
Shadow Volume
Yuen Man Long, Sam
Overview
3D Modeling
Challenges Reusable components Flexible animation scheme Smooth motion Visual quality Playability
3D Modeling
Model format: MD3 Vertex position, normal, texture mapping
and animation information Connect components by “Tag”
Challenges Reusable components Flexible animation scheme Smooth motion Visual quality Playability
3D Modeling
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
Animation
Interpolation & frame-skip Frame rate for animation fixed When display rate > frame rate
Interpolate the two adjacent frame When display rate < frame rate
Frame-skip occurs
Challenges Reusable components Flexible animation scheme Smooth motion Visual quality Playability
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
Game Logic
Update physicsDetermine how each robot responses upon external event (e.g. being hit)Constraints on gameControl mechanism
Challenges Reusable components Flexible animation scheme Smooth motion Visual quality Playability
Shadow Algorithms
Fake shadowVertex projectionStatic shadowShadow volume casting
Challenges Reusable components Flexible animation scheme Smooth motion Visual quality Playability
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
Shadow Volume
Draw the objectsDetermine 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
Shadow Volume
One pass Two passes
Shadow Volume
Problems Only support infinity light source Low performance Popping
Solution to first problem Plane equation & light position
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
Shadow Volume
Shadow VolumePerformance analysis Platform: Pentium III 800MHz, 256MB
RAM, GeForce2MX400, WinXP, 800X600Conditions fpsShadow Off 40
Shadow On 14
Shadow Cast Only(no rendering on color buffer)
16
Shadow On(one pass casting)
19
Shadow Volume
Conclusions Drawing the faces in the shadow
casting steps (two passes of casting) Frequent checking of the stencil
buffer bits
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
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
Mecha Zeta
Q & A