最近兩年似乎大家一致的想把網路遊戲向所謂動作感、打擊感的這個方面推進。我想是因為，已經有太多人厭倦了打木樁吧。
我們在三年前就一直在考慮這個問題，但似乎走向了歧路。乙個勁的考慮如何解決網路同步問題，怎樣在一定網路延遲下保持公平，怎樣避免作弊……
結果，嘗試了多次後的結論就是，我們依然沒有找到正確的方法解決以上問題，暫時把這一塊擱置起來。最近，公司又有許多同事熱切希望給遊戲加入更多的操作感。我們又重拾這個課題。這次，換了個角度看這個問題：假設我們完全不考慮網路這個因素，就算做單機遊戲，我們其實也沒有太多動作遊戲的設計實現經驗。那麼首先要解決的是如何把遊戲的操作手感做出來，之後才應該考慮怎樣在網路環境下實現它們。
為此，我糾結了很久。花了很長時間思考，以及編寫了大量的**印證，總算感覺自己的思路稍微清晰了一點。做一下記錄，不一定正確，只是寫出來或許可以給其他同僚提供一些思路。在內部討論的過程中，這些也被廣泛的質疑，許多人都不太認同。所以，一家之言，辜枉看之。
首先，所謂好的操作感打擊感，和顯示引擎的關係並不那麼密切。如果指望引入物理碰撞系統、布娃娃系統、更好的動作融合模組，就可以一勞永逸的解決問題。讓人物格鬥以真實物理公式去運作，就能夠給玩家爽快的體驗，我認為不是正確的解決之道。
從最強調操作感的格鬥類遊戲來看，玩家的對抗運算，從來都不是建立在所謂物理碰撞等這些系統之上的。從格鬥遊戲的開山之作街頭霸王，大學裡，我們寢室間最為流行的真侍魂，到我最喜愛的 vf ，都有簡單且嚴格的遊戲規則。設計人員在那些基本規則上建立起平衡的遊戲。前段時間我在 google reader 上[讀到一篇文章《從快打旋風談格鬥�戲》，深以為然。
第二，做為需要操作感的遊戲，一定是主要由
遊戲內在邏輯去驅動動畫，而不是由動畫驅動邏輯
。所以不應該過於依賴畫面最終的表現來做任何判定和處理。在以往的回合制遊戲中，由於不強調操作，而偏向畫面的動作表現，往往在動畫資料中插入大量資訊（比如關鍵幀反饋）。這是因為，當我們只關心每個動作的結果時，這樣做能減少動作控制和外界的耦合。但，一旦我們希望提供更多的細節控制，即遊戲設計的基本元素細於單個完整的格鬥動作，再這樣做就本末倒置了。
設計人員必定需要把握拆分後的動作片段的細節，才可以掌握最終遊戲的平衡。而不是任由美術人員做出華麗的招數，然後根據招數的表現來左右最終的打擊判定。
當遊戲從 2d 過度到 3d 後，表現力變的更強、靈活度更高，我們的製作人員反而有點束手無策了。不知道該怎麼控制 3d 人物動畫，還轉而去追求所謂物理碰撞等等原本屬於渲染的枝節技術，我十分懷疑是否走對了路？當遊戲中的動作畫面是一幀幀畫出來的時候，我們反而可以做出強烈的打擊感，這是件沒道理的事。看過鐵拳、vf 等等 3d 格鬥遊戲，我們知道，一定是我們沒找對方法，而不是 3d
的錯。關於動畫動作控制。我曾經在 blog 上**過一次。實踐過程中，由於設計依舊不夠簡潔，我們在互動性強的遊戲中，去掉了引導動作的設計（因為本來就要做仔細的控制）。複雜的動作片段組合，用有限狀態機來實現最好。狀態機使得分片的**可以分開來寫，減少了耦合。並且，狀態機是用純資料表達的。如果條件成熟，還可以設計一種
dsl 來描述。不過在研究階段，我們並沒有完全肯定最終怎樣表達最好，暫時我是用 lua 的表來描述的。這塊資料可以根據遊戲的具體動作設計來獨立修改，能夠交給非專業程式設計人員協同維護。這也使得單一程式原始檔不至於過大。（流程資料化後，讓資料和演算法分離）
狀態機的好處還在於，提高了動作控制模組的健壯性。讓一些非法的狀態切換很早就可以檢測出來。減少把**寫成一鍋粥的可能性。
比較難處理的是動作中的互動元素。即攻擊者和受擊者的動作配合問題。這部分邏輯，由攻擊者物件管理或受擊者物件管理都不自然。比較容易想到的是提到第三個獨立模組去處理。另外，3d 或所謂 2.5d (我不喜歡這個不嚴謹的詞) 遊戲中，不同於格鬥遊戲的是，存在多打一的情況。不確定性更多。這些難點，我經過一些思考後，得到的方案是這樣：
先抽象出「衝突(clash)」這個最小戰鬥單元。乙個「衝突」被定義成一對一的乙個招式。乙個衝突中一定存在乙個且只有乙個攻擊者和乙個防禦者。衝突過程中，雙方總是趨向於面對面，即處於乙個一維空間（如果有跳躍的設定，則是 2d 空間）。在這個衝突空間中，雙方能做的主要動作是前進和後退。這個前進和後退都可以是主動完成或被動完成的。衝突本身會因為招式，迫使雙方保持在合適的距離。因為只有距離合理，才能更真切的表達出打擊感。因為保持距離的需求，大多數情況下會逼迫防守者後退。衝突模組同時會不斷的督促參與者調整自己的面向，保持正確的衝突空間。
每場區域性戰鬥，在時間軸上都由多場衝突構成。在動作表現上，每個物件只能同時存在於乙個衝突中（邏輯上，它還是可以受到多方面而來的傷害）。只有退出乙個衝突，才能進入下乙個衝突。每個衝突中，只要有一方宣布退出，那麼衝突就結束。
最終，我們實現了乙個衝突管理器，稱為戰場。以衝突的固定心跳頻率（略低於遊戲邏輯）來更新。每次更新時，會根據每個物件實體發出的訊息請求以及優先順序，來最終配對，構成一場場衝突，逐個處理。
細節不再展開。下面再談另乙個問題。
動作遊戲中，我們不再簡單的處理人物的位置。允許他們重合站在乙個點上。因為位置對動作性非常重要。但是我個人比較排斥所謂堵門的設定。我希望更自然的處理遊戲世界中碰撞的問題。
當然，我不會採用任何的所謂物理系統，（物理碰撞系統可以加入遊戲，但不是在這裡加入）。作為遊戲設計者和實現者，我認為無此必要，甚至會畫蛇添足。它讓我不太容易把握遊戲的平衡。我簡單的把規則定為：允許物件的座標重合，但是如有可能，它們都趨向於保持距離。結合上面提過的設定，再加另一條原則：
遊戲世界的每個物件都盡力完成自己應該做的事情，讓這個世界趨向合理。比如：我被人擊中會硬直一段時間，或是需要後退。這並不是攻擊方強加給我的，而是通過衝突模組建議給我，以及動作控制的狀態機建議給我的。然後我盡量按照建議來行動。作為遊戲物件，一切事情都是主動完成，不分主動被動。
物件乙個遊戲物件，它的行動**可以來至自身的狀態機運轉、來至於戰場模組，來至於環境障礙，來至於環境的位置管理器。最終在一起決策，做出合理的行為。
至於 pc 和 npc 的區別，僅在於外部對狀態機的輸入是 ai 還是控制器。
在實現這些東西的時候，我發現雖然我把事情分成了許多小模組逐個實現。但是我一開始並不能把握所有的需求（應該是因為我沒有此類遊戲的製作經驗）。所以無法一開始就設計好全部介面。也不容易分工給不同的同事一起來做實現。
所以我選擇了一種方案，
每個模組間都採用訊息通訊的機制。並且非同步的處理訊息。每個模組都認為外部有可能發生一些不合理的事情，而被允許過濾掉一些訊息。同時也會認為自己提交的請求會被拒絕受理。這樣，單獨編寫模組會相對容易。這個思路來至於 erlang
對我的影響。
非同步處理的必要性還在於，有許多事件雖然先後到達，但邏輯上需要相互決策。當我們解開小模組間的耦合，就失去了調整模組運作的先後次序的機會。這樣，我們只好再把邏輯處理劃分成時間片，讓每個時間片的事件可以放在一起做乙個協調。同時物件需要根據不斷的狀態變化，對自己的行為做乙個反饋。（所以，我在
實現衝突中被擊打者後退的動作時，並沒有由衝突模組準確傳送應該後退多少，而是簡單的傳送乙個「後退」訊息，由持續不斷的反饋機制來做到最終需要的效果
）除了訊息傳遞這個基本機制，我還給整個系統增加了另乙個基本元素。被稱為探測器(detector) ，這個東西用來取代直接向物件索取資料。比如，我可以建立出乙個物件位置的探測器，從中拿到物件在世界中的座標。這個間接層我還沒有找到足夠的理由說明它和直接獲得物件屬性的區別和好處。但是直覺暫時告訴我，是有必要的。因為在現實中，我們了解到外部的一切都來至於我們的感官感受到的東西。也就是說，我們看到的東西僅僅是外部世界在視網膜上的圖象投影，並不是外部世界的本質。detector
就是模擬的這一點。
在模組劃分上，對於這些不確定的需求，我傾向於按功能劃分模組，而不是物件的實體
。傾向於用非侵入式的方式擴充套件功能，而不是在乙個類上不段的增加**。比如，訊息通訊物件就不是放在需要收發訊息的物件內部的，而是獨立出來，由物件自己去從通訊模組中找到屬於自己的介面。因為我不希望有乙個類不斷的增加成員資料，龐大到不可收拾的地步。而且，在執行次序上，我更希望按功能去統一處理：形象點說，我希望處理完所有物件的視覺訊號後，再處理所有物件的行動。把物件的視覺模組放在一起管理，可以更方便的做到這點。
學遊戲設計要什麼學歷 學歷低學遊戲動作設計好就業嗎
學歷低學遊戲動作設計好就業嗎 遊戲行業對於學歷的要求沒有那麼高，技術才是最主要的，你可以選擇中關村的匯眾啊，學習學歷 技能班級，學歷和技術都有了 讀書真的沒用嗎？為什麼有些人學歷低還是會成功 以個別學歷低還是會成功的人做例子，本身缺乏代表性，更沒有廣泛性，所以不能因此就推理讀書無用論。這種斷言方法，...
ACT 動作遊戲
動作遊戲是一種廣義上的遊戲型別。以 動作 作為遊戲主要表現形式的遊戲即可算作動作遊戲，動作遊戲也包含 射擊遊戲 和 格鬥遊戲 2005年後，單純的動作遊戲已較為罕見，因為 動作 都由各種不同的形式來表現。具有關卡設計的橫版過關遊戲可以稱其為動作遊戲，目前動作遊戲均指傳統的過關式動作遊戲，或不強調 射...
遊戲中慢動作 加速動作的實現
很多遊戲將慢動作 快速動作作為一種特效，來給遊戲增加可玩性及刺激感。非常常見的格鬥遊戲中，一般大招的施放前兆是靠慢動作來表示的。街霸遊戲，運用的灰常灰常ox unity中實現慢動作非常簡單 核心 time.timescale 是關鍵。不過unity建議，在放慢了時間time.scale的同時，最好同...