Mecha Zeta Project Title: Next-Generation Real Time Internet Game (Self-proposed)

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)


Client

Client

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


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


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




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


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


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


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


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


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


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


Example


400 ms 600 ms200 ms

Current Time 500

PendingS0 Executed

PendingS0 Executed

PendingS0 Executed

430

450


Example


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”


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


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


Shadow Algorithms

Fake shadowVertex projectionStatic shadowShadow volume casting


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

Mecha Zeta Project Title: Next-Generation Real Time Internet Game (Self-proposed)

Documents

Transcript of Mecha Zeta Project Title: Next-Generation Real Time Internet Game (Self-proposed)