Mecha zeta project title next generation real time internet game self proposed
This presentation is the property of its rightful owner.
Sponsored Links
1 / 86

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


  • 48 Views
  • Uploaded on
  • Presentation posted in: General

Mecha Zeta Project Title: Next-Generation Real Time Internet Game (Self-proposed). Supervisor(s): Dr. C.L.Wang, Dr. W.Wang and Dr. A.T.C.Tam 2 nd Examiner: Dr. K.S. Lui Project Members: (CE) Cheung Hiu Yeung, Patrick Sin Pak Fung, Lester Wong Tin Chi, Ivan Ho King Hang, Tabris

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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, Lester

Wong Tin Chi, Ivan

Ho King Hang, Tabris

Yuen Man Long, Sam


Project description

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

Mecha Zeta

P2P network architecture

Cheung Hiu Yeung, Patrick


Network architecture

Server

server

Coordinator

(also a client)

Client

Coordinator

(also a client)

Client

Client

Client

Coordinator

(also a client)

Client

Client

Client

Client

Client

Client

Diagram showing the whole network architecture

Network Architecture


Communication subsystem

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


Communication subsystem1

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 subsystem2

Trials

TCP Connection RTT (ms)

UDP Datagram RTT (ms)

1

261

40

2

311

100

3

300

120

4

891

60

5

300

timeout

Communication Subsystem

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


Client server communication

Client Server communication

  • Login and get data when starting game

  • Send peer groups’ game state

  • TCP is acceptable as connection is needed


Client server communication1

Server

server

Coordinator

(also a client)

Coordinator

(also a client)

Coordinator

(also a client)

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


Peers communication

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


Peers communication1

Coordinator

(also a client)

Client

Client

Client

Peers Communication

  • Broadcast controls to all other peers

  • No connection is needed for dynamic grouping

  • UDP is employed


Peers communication2

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

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


Peers communication3

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


Peers communication4

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


Peers communication5

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 zeta1

Mecha Zeta

Partitioning

Sound Engine

Sin Pak Fung, Lester


Network architecture1

Client-Server communication

Server

Peer to Peer communication

Client

Client

Client

Client

Client

Network Architecture

  • Peer to peer Architecture


Partitioning system

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 system1

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 system2

Client-Server communication

Server

Client

Client

Client

Client

Client

Client

Peer to Peer communication

A cell

Partitioning system


Dynamic vs static

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 static1

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

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

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 principle1

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

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


Discussion

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

Sound Engine

  • Using JDK 1.2 (making use of java.applet.AudioClip)

  • Using Java Sound API

  • Using Java Media Framework (JMF)


Sound engine1

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


Mecha zeta2

Mecha Zeta

Synchronization mechanism

Wong Tin Chi, Ivan


Introduction

Introduction

  • The role of synchronization mechanism

  • Current design trend

  • Synchronization mechanism in Mecha Zeta

  • Conclusion


The role of synchronization mechanism

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

Focuses

  • Performance of Synchronization algorithms on the 2 aspects

    • ResponsivenessvsConsistency

    • Minimal disturbance to simulation

      • Computation and storage overhead of error recovery


Current design trend

Current design trend

  • Consistency protocol

    • State-based

    • Command-based

  • Synchronization algorithm

    • Conservative

      • Lockstep

      • Chandy-Misra

    • Optimistic

      • TimeWarp

      • Breathing

      • Bucket


Challenges in mecha zeta

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

Commands + Events (E0)

Synchronization

Engine

Game States (G1)

Game States (G0)

Commands + Events (E0)

Game States (G1)

Game Engine

GameState Engine

Commands + Events (E0)

Rollback

Synchronization mechanism in Mecha Zeta

  • Overall Architecture

  • Semantic remark:

    • Command = Command or Event

  • Game Clock - NTP

  • Command Classification


Protocol algorithm

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)

Advances

Lower storage overhead(TimeWarp)

Faster response(Bucket)

Simulation Time

Local Host

200 ms

400 ms

600 ms

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.


Bucket synchronization1

200 ms

200 ms

400 ms

400 ms

600 ms

600 ms

Bucket Synchronization

  • Example

420

Simulation Time

Local Host

200 ms

400 ms

600 ms

Host 2

Host 3

Current Time

Bucket


Bucket synchronization2

200 ms

200 ms

400 ms

400 ms

600 ms

600 ms

Bucket Synchronization

  • Example

470

470

Simulation Time

Local Host

200 ms

400 ms

600 ms

Host 2

Host 3

Current Time

Bucket


Bucket synchronization3

200 ms

200 ms

400 ms

400 ms

600 ms

600 ms

Bucket Synchronization

  • Example

580

430

Simulation Time

Local Host

200 ms

400 ms

600 ms

Host 2

Host 3

Current Time

Bucket


Bucket synchronization4

200 ms

200 ms

400 ms

400 ms

600 ms

600 ms

Bucket Synchronization

  • Example

600

430

470

Simulation Time

Local Host

200 ms

400 ms

600 ms

Host 2

Host 3

Current Time

Bucket


Bucket synchronization5

200 ms

200 ms

400 ms

400 ms

600 ms

600 ms

Bucket Synchronization

  • Example

680

Rollback

260

Simulation Time

Local Host

200 ms

400 ms

600 ms

Host 2

Host 3

Current Time

Bucket


Multi states synchronization

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


Multi states synchronization1

S0

Executed

Pending

Multi-States Synchronization

  • Example

500

Current Time

450

430

Simulation Time

Local Host

200 ms

400 ms

600 ms

S0

Executed

Pending

S0

Executed

Pending


Multi states synchronization2

S0

Executed

Pending

Multi-States Synchronization

  • Example

630

Current Time

430

450

Simulation Time

Local Host

200 ms

400 ms

600 ms

Rollback

S0

Executed

Pending

S0

Executed

Pending


Bucket vs mss

Bucket vs MSS


Evaluation

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)


Conclusion

Conclusion

  • Synchronization delay determines

    • Responsiveness vs consistency

    • Storage & Computational overhead

  • Study on synchronization delay dynamically to network conditions


Mecha zeta3

Mecha Zeta

Graphic engine

Collision detection

Ho King Hang, Tabris


Graphic engine and collision detection

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

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 detection

    • Java is suitable


Graphic engine design

MZMecha

MZSceneObj

MZBullet

extends

2DGraphics

2DText

TerrainObject

extends

2DObject

Terrain detail

Graphics Renderer

Graphic Engine Design

  • High Extensibility – easy to add other kind of objects

  • Simple interface – for other modules to manipulate objects


Performance analysis

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

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 highly-duplicated scenarios


Collision detection system

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

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

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

Collision Detection Design

  • Challenge:

    • Too many objects in the world

    • Checking impossible collision -> waste time

    • Need to work properly in real time


Candidate pruning

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

Ray-Model Candidate Pruning

  • Bullet direction is used to select candidates

Selected Candidates

Pruned Candidates

Bullet

Pruned Candidates

Player robot


Accurate collision detection

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


  • Detection accuracy for attack

    Robot

    Robot

    Bullet

    Bullet

    Previous frame

    Current frame

    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


    Screenshots of attack collision

    Screenshots of attack collision


    Evaluation1

    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


    Mecha zeta4

    Mecha Zeta

    3D Modeling & Animation

    Game Logic

    Shadow Volume

    Yuen Man Long, Sam


    Overview

    Overview


    3d modeling

    3D Modeling

    • Challenges

      • Reusable components

      • Flexible animation scheme

      • Smooth motion

      • Visual quality

      • Playability


    3d modeling1

    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”


    3d modeling2

    3D Modeling


    3d modeling3

    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

    • Challenges

      • Reusable components

      • Flexible animation scheme

      • Smooth motion

      • Visual quality

      • Playability

    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


    Animation1

    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

    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


    Shadow algorithms

    Shadow Algorithms

    • Challenges

      • Reusable components

      • Flexible animation scheme

      • Smooth motion

      • Visual quality

      • Playability

    • Fake shadow

    • Vertex projection

    • Static shadow

    • Shadow volume casting


    Shadow volume

    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 volume1

    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


    Shadow volume2

    Shadow Volume

    One pass

    Two passes


    Shadow volume3

    Shadow Volume

    • Problems

      • Only support infinity light source

      • Low performance

      • Popping

    • Solution to first problem

      • Plane equation & light position


    Shadow volume4

    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 volume5

    Shadow Volume


    Shadow volume6

    Shadow Volume

    • Performance analysis

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


    Shadow volume7

    Shadow Volume

    • Conclusions

      • Drawing the faces in the shadow casting steps (two passes of casting)

      • Frequent checking of the stencil buffer bits


    Overall evaluation

    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

    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 zeta5

    Mecha Zeta

    • Q & A


  • Login