因為Seed Engine誕生之初，就定位為主要面向Android、iOS等移動設(shè)備（直到2012年6月才有了Flash平臺的內(nèi)部版本，才開始正式需求鼠標事件），所以Seed的輸入模塊除了對鍵盤做了簡單支持（主要是出于調(diào)試目的）外，在很長的一段時間內(nèi)，鼠標事件都是被wrap成為觸摸事件。所有后續(xù)關(guān)于輸入的工作都是針對觸摸來做的。所以這篇文章主要重點講觸摸這個方面，尤其是手勢識別的做法。
在Seed發(fā)展至今的期間，面臨了大量復(fù)雜的需求，不斷改進完善，目前還有很多不盡善盡美的地方。這篇文章會回顧一下這個過程，重點介紹一下當前的處理機制，再展望一下將來期望進行的改進工作。
Seed目前總計支持四種輸入：鍵盤、鼠標、觸摸、重力感應(yīng)。
所有的輸入會被響應(yīng)的處理模塊封裝成一個struct，這個struct的頭四個字節(jié)表明了觸摸的類型。在單線程模式下，這個struct會被直接傳遞給應(yīng)用。在多線程模式下，這個struct會在堆上分配，將指針傳遞給邏輯線程。這樣的好處是在邏輯線程忙的時候，消息處理函數(shù)可以更及時返回，避免諸如窗口拖動卡頓之類的問題。
這一部分極其簡單，因為簡單，所以不容易出問題。之所以把底層架構(gòu)放在歷史之前談，正是因為自從2011年10月份Seed誕生以來，引擎的這部分代碼幾乎從未變過。
對于Lua層來說，這部分的接口一直表現(xiàn)為一個全局事件，input.key、input.touch等等，參數(shù)struct會被iLuaWrapper(Seed中一個神秘組件)包裝成Lua可以直接訪問的數(shù)據(jù)，由Lua腳本去做任何上層的處理。
裸奔時代
Seed誕生以后的一段時間內(nèi)，當時的工作重心在完善2D渲染基礎(chǔ)、2D場景管理，2D物理等等較為繁雜的模塊上。因為沒有具體項目的負擔，當時的輸入模塊只以滿足調(diào)試需求、實現(xiàn)簡單交互為目的。因此，Seed在2011年10月以前，一直處在輸入裸奔的狀態(tài)。譬如只用鍵盤做操控，那就直接注冊input.key去監(jiān)聽需要的事件。為了實現(xiàn)諸如簡單的按鈕之類的功能，當時產(chǎn)生了一堆垃圾代碼，在事件里直接判定坐標等等。當然，這樣寫代碼是不可能做出沒有BUG的游戲來的，于是我們在一個游戲項目的原型階段結(jié)束后不久的時間，迅速推出了第一套框架。
山寨時代
因為需求緊迫，做任何游戲至少都少不了做一堆能tap的button出來，所以我們抓緊推出了第一版的input_ex插件。
input_ex以盡可能簡單的方式實現(xiàn)了對指定對象的觸摸事件處理。場景中的node可以被注冊到input_ex中，以接受tap、hold、drag事件。在touchdown的時候，input_ex會遍歷所有注冊的結(jié)點以找到被命中的node，之后的消息都會派發(fā)給這個node。
好吧，至少現(xiàn)在可以創(chuàng)建一堆不同的button了。input_ex的嚴重不足主要體現(xiàn)在功能上：
1、input_ex中的手寫狀態(tài)機，幾乎決定了除了tap、hold、drag以外，每加一個新的操作種類都是一個巨大的困難。
2、input_ex不能很好的處理多點觸摸。在多點的設(shè)備上各種出問題，以至于后來在某些項目里，強行屏蔽了除了1號手指（對應(yīng)安卓里的0號手指）以外的所有操作。
3、消息最開始就確定了對象，隨后的過程不能改變消息的對象。譬如一個scrollview上面有一堆button，那么當button截獲了消息的時候，scrollview就無法處理相應(yīng)的拖拽事件了。
除此以外，在使用上，每個節(jié)點存在一個獨立的用于處理輸入的對象，其生命周期需要手動管理，錯誤的使用會導(dǎo)致各種問題。初學(xué)者幾乎很難寫出正確的代碼。因為實現(xiàn)復(fù)雜，input_ex本身也在很長的時間內(nèi)都存在引用關(guān)系的BUG，導(dǎo)致不需要的資源不能被正確的釋放。總體來說，使用input_ex插件做游戲簡直是一段不堪回憶的黑歷史。
山寨時代之后
在使用input_ex完成了三四個界面操作簡單的小游戲后，我們開始構(gòu)思新的輸入系統(tǒng)。我們理想中的輸入系統(tǒng)應(yīng)該符合如下幾個條件：
1、很好的支持多點觸摸。這包含兩方面：第一，必須能夠很好的識別利用多個手指的操作，譬如scale, pinch, rotate等。第二，我們認為對于大屏幕的觸屏設(shè)備，能讓多個玩家在不同的地方互不干擾的進行多個操作也是很有必要的需求，這會給游戲設(shè)計師帶來很多新奇的玩法創(chuàng)意。
2、一定要很方便的加入各種不同的操作識別。我們希望能夠?qū)崿F(xiàn)很多有創(chuàng)意的小游戲，依靠觸摸的操作來做很多有意思的事情。我們也希望我們的界面能夠交互起來更酷，可以操作控制的地方更多。那么操作一定不能只局限于區(qū)區(qū)數(shù)種，一定要在特定的游戲里就能通過代碼添加大量不同的全新操作才行。
3、操作對象的識別更智能。在scrollview 上面的button做scroll操作時，操作對象要能正確的變成scrollview。
4、根據(jù)操作對象所接受的事件有所不同，以及其父結(jié)點所接受的事件有所不同，對同一事件的處理可能會有差別。譬如一個button接受tap，當觸摸并移動的時候，只要沒移開范圍，邏輯應(yīng)等待手指松開時再判定為tap成功（正如你在windows下按住一個按鈕然后小范圍拖動鼠標，click并不會因此而失敗）。但假如這個button有一個父結(jié)點甚至是祖先結(jié)點接受drag，那么早在剛開始移動的時候，就應(yīng)該判定為tap取消，事件轉(zhuǎn)為drag事件而派發(fā)給相應(yīng)的祖先結(jié)點。
5、不會為了滿足上面的需求，把上層邏輯代碼搞的太麻煩。最理想的情況下，上層邏輯代碼只要選擇好自己所接受的操作種類，然后安心等待事件監(jiān)聽器被調(diào)用就好了。
而我們不想要：
1、像安卓那樣復(fù)雜的事件分派機制，所有的觸摸都被綁在一起依次分派下去，在結(jié)點上依據(jù)類型的不同寫代碼去做對應(yīng)的操作。我們認為應(yīng)該要有一個很好的手勢識別底層，僅僅把結(jié)點關(guān)心的信息拋給它。
2、像HTML DOM那樣的事件冒泡機制。因為觸摸處理的復(fù)雜性，在touch down的時候往往根本不能確定真正用戶想要進行何種操作。而如果等操作進行完了才給予反饋，那操作過程就很難得到非常及時的反饋。在上述scrollview和button的例子里，button必須首先獲得事件以立即展現(xiàn)被按下的效果，等到用戶的操作能夠明確為一個scroll操作之后，再由scrollview來處理后續(xù)的事件。再加上之前所述的期望4，已經(jīng)不是簡單的對同一事件的冒泡足以滿足的。
真的有一套框架能完美的解決我們的需求嗎？下一章起，我會逐步講解我們?yōu)榇怂龅呐Α?/div>
