游戏网络物理模型

 

挺好的文章：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.