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