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