https://market.android.com/details?id=air.idv.davidlai.together2.android
各位若有Android 手機，可至MARKET搜尋「湊作伙!」關鍵字。
這是一個可以在Andorid手機上執行的小遊戲，只要把相鄰兩個以上的方塊圖案按下就可以消除，只要消除的越多，玩家在排行榜上的名次就越高。
YES，就這麼簡單。這是一個看似無腦，但若要有好成績還是需要動點腦筋的小遊戲。
開發平台的抉擇 iOS V.S. Android
眾人皆知現行Mobile兩大OS平台 iOS 與 Android (Mango就不在討論之內了，畢竟AIR目前暫時也不能publish，市佔率也……)。小弟的Smart Phone是 HTC Incredible S 採用Android系統。為何要選擇Android陣營呢？
並非我不喜歡iPhone(其實也很想要唉鳳啊~)，也不是Android比較好，而是基於這些理由：
1.對Develpoer來說，Google收取開發者憑證費用是25美金(終身)，而Apple則是99 美金/年(貴桑桑~)。由於目的不是要朝向獨立遊戲製作者邁進，所以不選水果選小綠人。
2.開發上傳測試，當申請好開發者帳號後，很快地就可以上傳*.apk檔案，再過沒多久(時間
不定，最遲不超過1HR)就可以在Google Market上看到你自行上傳的檔案，這樣你可以在短
時間(與水果商店相比)內從Market下載測試自己的檔案。但是水果商店不行，還是得先經過
官方審核……….(我得承認我沒有美國時間可以耐心等待
)3.價位問題，雖然我當初也曾想過是不是唉鳳比較水呢？但是價位讓我這小市民買不下手，
幾經比較之後，最後選擇了還算是中階價位的HTC Incredible S作為開發機種。
4.其他……….
雖然因為上述的理由而選擇小綠人的懷抱，但小弟並非因此而貶低水果。每種選擇都各有其優缺點，並非有絕對的優劣好壞，端看用什麼角度去看待如此。對Flash AIR for Mobile開發者來說，跨平台的開發能力當然是日後要邁進的目標，這也才是能夠真正發揮Flash cross platform的特性。
遊戲類型的決定，不是每個遊戲到哪都好玩!?
當初本來想要嘗試製作的是類似在Wii平台上所發行的像雷射曲棍球那樣的遊戲(就是在遊樂場需要2人才能進行遊戲，目的是將圓盤推到對方的陣營裡。)，需要即時反應、兩個人同時玩充滿著刺激互動性。
在Google Market上有搜尋到類似的遊戲，下載後馬上試玩了一下，很快地，馬上就發現同樣的遊戲類型在不同的環境下玩有著很大的差異，不論是在遊樂場或是在電視前使用Wii Remote玩，畫面上是絕對淨空的，但使用觸控的方式進行遊戲，尤其是在手機上，遊戲進行中最大的阻礙反而是自己的手!!自己的手指因為要不斷的移動遊戲中的物件，在要即時反應的情況下有時候反而會因為自己的手指擋住了佔據部份螢幕擋住視線，然後就這樣好幾次被電腦解決掉了…………….這讓我玩起來有點挫折，因為在玩實體與Wii的時候都不會有此情形發生(我才沒那麼遜啦)，
難道是因為手機螢幕只有4吋真的還不夠大？
或許換成平板情況就不會如此才是？
但是小弟並非家財萬貫，手中沒有銀兩買那麼多台實機測試；因此我決定更改遊戲類型，既然是在SMART PHONE上，那就應該以一直TOUCH的直覺式操作方式來進行遊戲才容易被大眾接受吧!
螢幕大小影響視覺感受
上面這行看起來好像廢話，但對於我這個龜毛的人來說，在設計過程中這卻讓我有深刻體驗。
當初設計藍本是以參考ZOO KEEPER(以下簡稱Z)為主，在設計圖像上我設計了幾個擬人化的蔬果圖案，在laptop上看起來當然是清楚又可愛啦~可是一但在手機螢幕上，要各自被縮小放在11*9 =99格的方塊中，任憑你畫的再怎麼漂亮可愛，看不清楚就是看不清楚，而且看起來還很雜亂。這可能放在平板上或許可以改善這樣的情形，但當時只有手機的情況下自然是希望有一款手機平板皆合宜的APP。
後來我分析了我的遊戲與Z的不同之處，在Mobile版本的Z，方塊(以動物為主角)，遊玩方式與我的不同，它並不需要非常多的格數來容納可以消除的方塊(只要適當即可)，所以自然可以將圖案放得更大一些，讓它可以更好清楚辨認，但我最初設計的遊戲方式卻是要方塊要越多才越有挑戰性，而畫面整體效果看起來也無法讓我滿意，幾經權衡之下，只好把當初設計的圖案捨棄，改用簡單的幾何圖形才能達到辨識度高的要求。
雖然不是每款遊戲都會有這樣的問題，但在某些地方細節上的處理我卻認為這是不能忽略的地方。儘管Z後來的線上更新版本也換成了較複雜的圖案，但我認為更新版本反而不如原先來得好，在辨識上更顯得不便，這樣會使得我對這樣的遊戲興趣缺缺。
點陣vs向量
雖然多用點陣少用向量的話已經快變成是老生常談了，但這邊還是分享一下給各位參考：
為求測試快速，我曾偷懶的直接使用Flash編輯工具畫出向量形狀充當方塊使用，在測試階段時，物件開始生成的那一瞬間FPS確實會往下掉，看起來似乎還好嘛？
但一但向量物件一多(假設整個背景圖都是向量線條)，即使沒有做任何運算，手機上的效能已經很明顯的低落到不行(大概是從40FPS→個位數這樣的差距)，簡直就像是要騎老爺腳踏車上45度以上斜坡那樣的吃力困難。
這故事告訴我們：出來跑的遲早要還，該節省的資源還是要儘可能的省下來。
多螢幕尺寸的顯示比例
當遊戲的大多功能都製作完畢後，還有個因應Andorid系統最常見的問題，就是每家廠商推出的螢幕尺寸都不一樣! 說實話在沒有實際的機器測試，根本無法得知正確的情形究竟是如何，但是誰又有那麼多錢錢可以每台都買來測試呢? 這無異是天方夜譚~
在茫茫網海上搜尋，有這兩篇文章的資訊可供參考：
http://www.adobe.com/devnet/flash/articles/authoring_for_multiple_screen_sizes.html
http://www.adobe.com/devnet/air/flex/articles/writing_multiscreen_air_apps.html
我沒有完全依照ChristianCantrell的做法(眼花撩亂啦><)，但原則上有幾點是可以參考的：
1. this.stage.scaleMode = StageScaleMode.NO_SCALE;
2. this.stage.align = StageAlign.TOP_LEFT;
3. 偵聽REZISE事件
小弟很幸運的向友人借得Samsung Galaxy Tab GT-P1000來作測試。詭異的是在Incredible S上時只會出現1次的resize事件，但是在Samsung平板測試上卻出現了3次，而且每次值都不一樣!! 為了搞定這個真的是吃盡了苦頭，最後用取得的場景寬度比例去做適度的尺寸縮放與位置調整，才能讓手機與平板兩個裝置上看起來是差不多的視覺效果，但因為沒有更多的實體機器去驗證我的想法是否100%正確，也就只能暫時如此了。
小弟在這邊分享一些自己個人在開發過程中的心得，雖然不見得都會是程式設計相關，但是有些經驗真的是要遇到了才知道呀~僅在此提供一些小小分享提供給需要的朋友，讓大家在一起玩Flash的路上多點陪伴、多點參考，若有謬誤不適之處，也懇請前輩指點一二。而上架過程那又是另外一回事了…….
此次篇幅已佔據過多版面，就留待之後有機會再分享吧~
沒有留言:
張貼留言