Q：我想問一下大家在製作遊戲時BUFF、裝備更換是如何處理的：
1.效果觸發時運算一次，結束時在逆運算一次。
2.每次數值變動時都重新計算一次，在連線遊戲的時候可能又要考慮到更多東西，希望高手能夠解惑一下。
A1
重點是用演出、黑白換色停格效果或 CUT-IN 來換取 server 同步時間。
現在遊戲採取類單機遊戲機制時，其實完全是 client - trust ，server 不計算 buff 施放期間，只接收戰鬥結束後是否勝利與一些必要記載資訊即可。
你可以參考刀塔傳奇，他一場戰鬥二到三分鐘之內可以來來去去重複幾十遍，直到最好的結果，傳出英雄血量、存活與否等訊息而已。
其他星數獎勵什麼的都是讀表判斷直接演示。另外一個極端，參考皇室戰爭，這個遊戲完全是 server - trust 。
他的做法是你拉角色丟到場上去的時候，他跳下並且讀秒這個動畫就是在爭取 server 同步時間，他傳出的訊息包含"施放技能"的時間點，導致server 回到玩家放下角色的時間點重新計算結果。
到下次有人丟新角色或技能到場上為止，再重新演算。裝備的即時更換、升級、附魔等等都可以參考這個做法，所以說來說去，其實就是用演出來 cover server 同步時間，不管是 client - trust 或是 server - trust 原則上應該都是。
每次數值變動時都重新計算一次但你要限制數值變動的頻率跟速度，以確保 server 跟得上。程式設計師在設計即時連線遊戲的時候總以為這個過程應該是即時的，但你應該確保你的同步動作有動態演示在 cover 你的同步過程。
適當的做法是在每一個訊息同步階段的同時加上一到一點五秒的動畫，然後你就可以得到合理的計算空間。皇室戰爭把這個動畫應用得淋漓盡致，甚至上場讀秒冷卻可以長達 4 秒，這都大幅降低了重覆運算的壓力。
他的做法是你拉角色丟到場上去的時候，他跳下並且讀秒這個動畫就是在爭取 server 同步時間，他傳出的訊息包含"施放技能"的時間點，導致server 回到玩家放下角色的時間點重新計算結果。
到下次有人丟新角色或技能到場上為止，再重新演算。裝備的即時更換、升級、附魔等等都可以參考這個做法，所以說來說去，其實就是用演出來 cover server 同步時間，不管是 client - trust 或是 server - trust 原則上應該都是。
每次數值變動時都重新計算一次但你要限制數值變動的頻率跟速度，以確保 server 跟得上。程式設計師在設計即時連線遊戲的時候總以為這個過程應該是即時的，但你應該確保你的同步動作有動態演示在 cover 你的同步過程。
適當的做法是在每一個訊息同步階段的同時加上一到一點五秒的動畫，然後你就可以得到合理的計算空間。皇室戰爭把這個動畫應用得淋漓盡致，甚至上場讀秒冷卻可以長達 4 秒，這都大幅降低了重覆運算的壓力。
Q：大概了解用動畫演示來填補畫面在訊息同步中造成的空白，限制數值變動的頻率跟速度這點倒是讓我好奇，如果在多人即時連線遊戲(比如Lol和CS)這種施放技能攻擊、數值變動頻繁的遊戲遇到這種問題的話呢？
A1
CS 跟 LOL 使用的是區域連線功能，他的作法是以主程式當作媒介去搓和一個區域連線的房間。區域連線的同步速度較快，可以作到幾乎即時，然後跟皇室戰爭採取同樣作法，每個技能後面接動畫，爭取同步時間。
LOL 如果你網路同步速度比別人慢，你會看到沒事突然血掉一段。因為 SERVER 已經紀錄到對方施放招式，而你的位置在他的範圍內，你在SERVER 上已經扣血了，如果你的網路速度不夠快，你扣血的時間點不幸在他播完動畫以後，你什麼都不會看見。
LOL 如果你網路同步速度比別人慢，你會看到沒事突然血掉一段。因為 SERVER 已經紀錄到對方施放招式，而你的位置在他的範圍內，你在SERVER 上已經扣血了，如果你的網路速度不夠快，你扣血的時間點不幸在他播完動畫以後，你什麼都不會看見。
A2
1. Buff會有兩種方式，第一種是他人給予的，這種你接收到Buff已經代表伺服器記錄你有這個Buff了，所以之後放的技能就是直接已經是變更後的了。
2. 另外一種就是自己放的，這種可以有兩種做法，一種就是Buff等到server回傳ok之後才生效，另外一種就是client先暫時紀錄有Buff狀態，在server回傳ok之前送的技能會加上buff的附加資訊。
client端其實有些部分也可以做處理，比如說cs好了，他們會有tcp跟udp兩種通訊，人物移動跟子彈方面會用udp做廣播，來減少延遲，之後用tcp做確認。
server會接收所有玩家丟過來的udp，直接不做處理的廣播到範圍內的client上。然後玩家做的任何動作，除了udp之外，也會用tcp送一些需要驗證的資訊，比如說子彈發射，人物移動，中彈，手榴彈跟患子彈等等動作。
這樣的話，Lag的時候，你人明明往前走，可是server覺得你跑超過的時候，就會用tcp回傳給你說你要回溯。而client就是針對udp送過來的資訊，子彈就判斷是否中彈，障礙物等等的，都在client做出動畫或者碰撞，之後tcp再做驗證。
2. 另外一種就是自己放的，這種可以有兩種做法，一種就是Buff等到server回傳ok之後才生效，另外一種就是client先暫時紀錄有Buff狀態，在server回傳ok之前送的技能會加上buff的附加資訊。
client端其實有些部分也可以做處理，比如說cs好了，他們會有tcp跟udp兩種通訊，人物移動跟子彈方面會用udp做廣播，來減少延遲，之後用tcp做確認。
server會接收所有玩家丟過來的udp，直接不做處理的廣播到範圍內的client上。然後玩家做的任何動作，除了udp之外，也會用tcp送一些需要驗證的資訊，比如說子彈發射，人物移動，中彈，手榴彈跟患子彈等等動作。
這樣的話，Lag的時候，你人明明往前走，可是server覺得你跑超過的時候，就會用tcp回傳給你說你要回溯。而client就是針對udp送過來的資訊，子彈就判斷是否中彈，障礙物等等的，都在client做出動畫或者碰撞，之後tcp再做驗證。