各位看官老爺們，這裡是RuaiRuai工作室，一個做單機遊戲的興趣作坊。
在這一篇中，我們將會自頂向下地討論本2D遊戲中主角不可或缺的一個功能——移動控制。
首先我們簡單分析一下2D遊戲中主角與移動相關的需求。最主要的，主角應該接受玩家WD或者左右箭頭的輸入，以進行水平方向上的移動；應該接受玩家跳躍鍵的輸入，以進行跳躍的動作；我們暫時把這一類移動需求稱為玩家控制位移。除了玩家控制位移，主角還可能收到某種機關、怪物的被動位移，比如擊退效果、牽引效果等等，這一部分，我們把它稱為被動位移。同時，作為一個主打戰鬥的2D遊戲，技能是必不可少的部分，部分技能可能也有位移效果，比如衝刺技能，跳躍技能，有後座力的技能等等，對於這一部分移動需求，我們把它稱為技能位移。除了移動需求，與之類似的還可能有傳送需求，不管是主動的還是被動的。上面所說的大概就是與位置移動有關的需求。當然，考慮一個遊戲專案的需求是遠遠不夠的，因為我們永遠無法“確定”一個遊戲究竟是什麼樣子的，我們現在所要做的，就是從上面所提到的主體需求提煉出一個有效且“可擴充套件”的框架，以便以後出現需求變更我們現有的框架能夠比較容易的容納之。
有了思路，我們就應該分析一下以上幾種移動需求的異同點，並考慮一個實現方法。
對於玩家控制位移，主角根據玩家每一幀的輸入進行響應移動；對於擊退、擊飛等被動位移，我們希望主角在一定時間內移動指定距離，並在這個時間內玩家無法進行操控；對於類似風場的牽引效果，我們希望能夠在主角的現有位移上每幀疊加一個向心位移量；對於技能位移，我們也希望主角進入和擊退等狀態相同的狀態。
從這種角度考量，主角的移動大致可以分成以幀為單位進行的，以及以給定時間位移量為單位進行的兩種。同時，存在不同的位移狀態之間存在互斥關係，比如在技能位移狀態下，就無法進行玩家操控，也無法收到來自外界的被動位移效果等等；也存在位移狀態是疊加生效的，比如牽引效果等。針對這種需求，我們使用四個陣列列表來實現目標需求：
其中，兩個互斥列表用來獲得當前幀的“主要位移量”。主要位移量疊加兩個疊加列表所有記錄項的位移和，產生當前幀的總位移。
關於主要位移量的優先選擇問題，我們應該存在一個優先順序排序，使得當多個主要位移量需求同時存在時，我們可以選出一個優先順序最高的位移。我們可以用一個指標列表表示：
除此之外，時間-距離位移量還需要一個計時器來保證這個位移狀態在我們想要讓他失效的時候不再生效，所以最後，我們的主要資料結構示意圖變成了這樣：
除了主要的資料結構，我們還應該定義一系列方法來操控這些資料結構，但是話都說到這個份上了，我們也不再往下分析了，各位看官各取所需，定義自己的管理方法就好~
在這個資料結構棧中，我們把位移需求抽象成兩種主要的實現方式：每幀進行和按時間進行，對於這兩種方式我們構建了若干個列表予以儲存，當我們需要檢視當前幀主角的移動情況時，我們通過找一個主要位移量併疊加若干個疊加位移量來實現。當我們的需求擴充套件，擁有更多種類的位移需求時，我們只需要擴充套件這些列表中的項，以及擴充套件優先順序列表即可。
到此為止，我們有了一個相對完善設計和實現思路來達到我們的功能性和靈活性的需求。但是，考慮這樣一個情況，當玩家在主角釋放技能的狀態下釋放了另一個技能，我們的程式應該如何響應?應該允許其打斷當前釋放的技能嗎？還是讓這個輸入無效？或者說，在一組互斥狀態下，我們應該如何規定當前狀態允許進入哪一種狀態，不允許進入哪一種狀態。在下一篇中，我們會說明與主角狀態控制有關的元件設計，以及狀態控制和位移控制是如何搭配對主角的移動及各種狀態進行管理的。
那麼今天的分享就是這些，歡迎訪問：
整個專案原型github地址：
www.gitHub.com/yunshiyue/elementgame
看官有何見解，有何指點，歡迎留言，也歡迎私聊~