游戏网络物理模型

 

挺好的文章：http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

Age of Empires: http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php

 

 

---

2010年的主要是讲2011年的第四种网络模型：Authority Scheme

• PDF http://bit.ly/9CFzWb
• most of material in this page. http://gafferongames.com/2010/03/11/gdc-2010-networked-physics-slides-demo/

 

2011：GDC Networked Physics 2011  

• http://www.slideshare.net/BarrelRoll/gdc-networked-physics-2011#btnNext

总结：

网络模型：

• Pure client/server
  • Client does not run any game logic
  • Client send input to the server
  • Server sends render stat back to client
    • Client需要记录server送过来的位置等信息，并且根据客户端时间做interpolation，来达到平滑的目的
  • 优势：
    • Simple
    • Secure
    • Late join is easy
  • 缺点
    • Round trip delay between player input and physics response
• Client side prediction
  • Special treatment of local player object
  • Client simulates local player object ahead without waiting for server round trip
  • Server sends correctioni to client if it disagrees with client state
  • Exapmles:
    • Halo
    • Quake
    • Unreal
    • CounterStrike
    • TF2
    • Left4Dead
    • Portal 2?
  • 优势：
    • No round trip delay
    • Almost as secure as pure client/server
    • Late join is still relatively easy to implement
  • 缺点
    • Expensive to rewind and replay physics
    • Collision between player objects are poorly defined
• Deterministic lockstep
  • Each machine runs same game code
  • Wait for input from all players before advancing to next frame
  • Rely on determinism to stay in sync
  • Examples:
    • Every RTS ever made
    • Halo COOP story mode
    • Little Big Planet(soft body physics + fluids)
    • PixelJunk Shooter2(fluuid sim)
    • Most fighting games(SF4, GGPO)
  • Physics engine must be deterministic
  • 优势
    • Only need to send player inputs
    • Handles interactions between players well
    • Everything "just works"
  • 缺点
    • Low player counts only (2-4)
    • Floating point determinism
    • Lat join can be difficult or impossible
    • Forking simulation is very expensive
• Authority scheme
  • Split up the simulation and run parts of the world on different machines
  • Design the split to suport networking goals, eg. latency hiding, conveniene
  • Authority Rules:
    • Player Authority: Player always have authority over the object they are controlling
    • Tie-Break Authority: in areas of overlap, for grey cubes with default authority -- lowest player id wins.
    • Interaction Authority: Players take authority over objects they interact with -- effectively becoming the server for that bject, until it returns to rest and becomes grey again. This last technique hide latency for the higher player ids in areas of overlap.
  • Examples:
    • Mercenaries 2
    • Insomniac games "sync host"
    • Many Many other console games
  • Apply to physics
    • Take authority over objects you interact with. Become the server for thest objects
    • Resolve conflicts when multiple players want authority over the same object
  • 优点
    • Does not require 100% determinism
    • Does not wait for most lagged player
    • No need to rewind & replay or fork simulation to hide latency
  • 缺点
    • Trusting the client (cheating) -- Use the tech in coop game only.
    • Difficult to handle interactions between multiple players
    • Late join is difficult

How to choose?

• 如果延迟不是问题：pure client/server， 简单
• 如果有很多状态要发送，那么就用Deterministic lockstep，因为这种方法只要发送input即可，可以用Fork simulation来had lag
• 如果游戏引擎本身不是deterministic的，或者有很多玩家，那么用client side prediction或者authority scheme
  • client side prediction is basically an anti-cheat measure for FPS
  • if you cannot afford it, do a COOP game with authority scheme instead, but in this case we need to validate authority physics on dedicated server.

转载于:https://www.cnblogs.com/dbbs/archive/2012/12/10/2804702.html