因為Seed Engine誕生之初，就定位為主要面向Android、iOS等移動設(shè)備（直到2012年6月才有了Flash平臺的內(nèi)部版本，才開始正式需求鼠標(biāo)事件），所以Seed的輸入模塊除了對鍵盤做了簡單支持（主要是出于調(diào)試目的）外，在很長的一段時間內(nèi)，鼠標(biāo)事件都是被wrap成為觸摸事件。所有后續(xù)關(guān)于輸入的工作都是針對觸摸來做的。所以這篇文章主要重點講觸摸這個方面，尤其是手勢識別的做法。
在Seed發(fā)展至今的期間，面臨了大量復(fù)雜的需求，不斷改進(jìn)完善，目前還有很多不盡善盡美的地方。這篇文章會回顧一下這個過程，重點介紹一下當(dāng)前的處理機制，再展望一下將來期望進(jìn)行的改進(jìn)工作。
Seed目前總計支持四種輸入：鍵盤、鼠標(biāo)、觸摸、重力感應(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)，當(dāng)時的工作重心在完善2D渲染基礎(chǔ)、2D場景管理，2D物理等等較為繁雜的模塊上。因為沒有具體項目的負(fù)擔(dān)，當(dāng)時的輸入模塊只以滿足調(diào)試需求、實現(xiàn)簡單交互為目的。因此，Seed在2011年10月以前，一直處在輸入裸奔的狀態(tài)。譬如只用鍵盤做操控，那就直接注冊input.key去監(jiān)聽需要的事件。為了實現(xiàn)諸如簡單的按鈕之類的功能，當(dāng)時產(chǎn)生了一堆垃圾代碼，在事件里直接判定坐標(biāo)等等。當(dāng)然，這樣寫代碼是不可能做出沒有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的嚴(yán)重不足主要體現(xiàn)在功能上：
1、input_ex中的手寫狀態(tài)機，幾乎決定了除了tap、hold、drag以外，每加一個新的操作種類都是一個巨大的困難。
2、input_ex不能很好的處理多點觸摸。在多點的設(shè)備上各種出問題，以至于后來在某些項目里，強行屏蔽了除了1號手指（對應(yīng)安卓里的0號手指）以外的所有操作。
3、消息最開始就確定了對象，隨后的過程不能改變消息的對象。譬如一個scrollview上面有一堆button，那么當(dāng)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等。第二，我們認(rèn)為對于大屏幕的觸屏設(shè)備，能讓多個玩家在不同的地方互不干擾的進(jìn)行多個操作也是很有必要的需求，這會給游戲設(shè)計師帶來很多新奇的玩法創(chuàng)意。
2、一定要很方便的加入各種不同的操作識別。我們希望能夠?qū)崿F(xiàn)很多有創(chuàng)意的小游戲，依靠觸摸的操作來做很多有意思的事情。我們也希望我們的界面能夠交互起來更酷，可以操作控制的地方更多。那么操作一定不能只局限于區(qū)區(qū)數(shù)種，一定要在特定的游戲里就能通過代碼添加大量不同的全新操作才行。
3、操作對象的識別更智能。在scrollview 上面的button做scroll操作時，操作對象要能正確的變成scrollview。
4、根據(jù)操作對象所接受的事件有所不同，以及其父結(jié)點所接受的事件有所不同，對同一事件的處理可能會有差別。譬如一個button接受tap，當(dāng)觸摸并移動的時候，只要沒移開范圍，邏輯應(yīng)等待手指松開時再判定為tap成功（正如你在windows下按住一個按鈕然后小范圍拖動鼠標(biāo)，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)的操作。我們認(rèn)為應(yīng)該要有一個很好的手勢識別底層，僅僅把結(jié)點關(guān)心的信息拋給它。
2、像HTML DOM那樣的事件冒泡機制。因為觸摸處理的復(fù)雜性，在touch down的時候往往根本不能確定真正用戶想要進(jìn)行何種操作。而如果等操作進(jìn)行完了才給予反饋，那操作過程就很難得到非常及時的反饋。在上述scrollview和button的例子里，button必須首先獲得事件以立即展現(xiàn)被按下的效果，等到用戶的操作能夠明確為一個scroll操作之后，再由scrollview來處理后續(xù)的事件。再加上之前所述的期望4，已經(jīng)不是簡單的對同一事件的冒泡足以滿足的。
真的有一套框架能完美的解決我們的需求嗎？下一章起，我會逐步講解我們?yōu)榇怂龅呐Α?/div>
