2017年12月19日 星期二
【社群】卡牌在效果處理前離開原本區域、又回到原本區域，決定讓它效果仍然有效
最近用腦量挺大的，過了一關又有一關。
這次是考慮到某些效果較特殊的牌，
舉例來說，像是爐石戰記的
「克蘇恩」「派奇」「弱效碧玉法術石」等等，
在處理效果到一半時，若正好因其他效果而離開原本區域、
又或者被奪取控制權，這種情況下當然應該要算作無效了
（克蘇恩例外，只有在被奪取控制權的情況下才會無效）；
但又假設，如果在效果處理到一半時，
該卡先離開原本區域、然後又回到原本區域，
到底該算作有效或無效？
在我以前常玩的卡牌遊戲中，
有的規則會將它視為不同卡牌而無效，
但這樣的規則，和我原本規劃的程式架構會有所衝突，
雖然是可以為它開特例，
但想想還是維持邏輯的簡潔、一致性比較好，
所以就決定讓它維持有效了。
（事實上，這種可能性發生的機率極低，
若不刻意去營造，可能完全都不會遇上，
所以更沒必要為它開特例了）
2017年12月17日 星期日
【社群】打算將Token獨立出來、不視為卡牌
這週進度做到一半時卡住了，
原因在於身為「企劃的我」和「程式的我」意見混雜在一起，難以抉擇的緣故。
簡單來說，問題就是在於
「卡牌產生的Token，是否要視為卡牌？」
這在許多遊戲中的做法都不同，
會影響到卡牌「回手」等效果的處理。
（若不視為卡牌，Token回手通常就直接消滅）
由於《無限技域》的手牌上限不高，
即時制的玩法也提高了思考難度，
因此目前是打算將Token獨立出來、不視為卡牌，
這樣即使以後設計了大量回手的效果，
也不必擔心被一堆廢卡塞爆了。
2017年12月4日 星期一
【社群】成功使用Unity新功能打包圖集並動態載入
由於卡牌遊戲的卡圖總數既多，
又會隨著玩家牌組不同而有非常多的排列組合，
如果每局都將所有卡圖載入肯定是不行的，
遊戲中動態載入的話，
也需要考慮到瞬間的效能消耗、以及Draw Call結合的問題。
因此上禮拜就是在研究這個了，
吸收大量資訊+實際測試後，
得出的結論是用<Image>取代<SpriteRenderer>，
在Layer管理上會直覺許多，
如Raycast Target、Filled Image Type等功能也較完善，
至於消耗效能稍多的問題就以Canvas動靜分離的方式來節省。
並且以uGUI新的SpriteAtlas來取代Packing Tag，
以新的AssetBundle、LoadFromFile + StreamingAssets
取代Resources.Load，
成功實現了將大量圖片打包成圖集後，
於每局遊戲開始前動態載入會用到的部分，
並且載入多張圖也都算是同一個Draw Call。
研究到此總算是告一段落，可以繼續往下寫了，
也順便跟大家分享一下這點心得，
若有更好的方式歡迎討論指教唷！
2017年11月26日 星期日
2017年11月16日 星期四
【社群】決定先把劇情割捨
其實上週日就已經把《麻雀點數計算乙女》改版完成了，
但iOS送審就等了兩天，
因為改版資訊被退回之後花了一天，
通過之後又等了足足一天才顯示在App Store上，
真是讓我等得好苦啊！
在這段等待的時間，我終於可以回來著手開發《無限技域》了！
仔細思考過後，我打算痛下決心先割捨掉劇情的部分，
第一版先推出玩法就好。
同時兼顧兩者的話，開發時程真的會拉太長，
而且難度不是相加而是相乘，這也是之前進度不斷走回頭路的原因。
2017年11月12日 星期日
【社群】Unity Log Viewer好用！
這週把《麻雀點數計算乙女》改版完成送審，
過程中其實遇到非常多意外狀況。
多虧一個免費插件「Unity Log Viewer」，
讓我在手機上也很方便查看Log，
找起問題來輕鬆許多，非常推薦使用。
（它唯一缺點是看不到錯誤發生在程式碼第幾行，
只能看到函式名稱，只好自己加Log來判斷）
而iOS送審依然是老樣子，
常常在Xcode匯出了一小時，最後才說某一個地方有問題，
於是又要重新再花一小時匯出新版本上傳...
這邊就遇到一個以前沒有的問題：
「遺失Marketing Icon」
https://issuetracker.unity3d.com/issues/xcode-9-ios-warning-missing-marketing-icon-is-thrown-when-uploading-an-app-to-itunes-connect?page=3#comments
查了之後得知，Unity 5未包含iOS這個新要求的Icon設定，
所以解法之一是更新到Unity 2017.1.1p2，
或者從Xcode中直接加入也可以。
https://stackoverflow.com/questions/44667434/how-to-solve-missing-marketing-icon-ios-apps-must-include-a-1024x1024px
2017年11月3日 星期五
【社群】非常感謝，來自好友的提醒
最近真是發生了非常多的事，
但都比不上一位好朋友的提醒來得重要。
要成就大事，可能真的需要執著到近乎瘋狂吧，
我也想找回從前那股不眠不休的拼勁。
最近在著手《麻雀計算乙女》的改版，
意外注意到App中的頂點數使用過多了，
原來是我在文字上使用了太多特效（陰影、邊框、漸層），
雖然關閉它們會讓文字看來較樸實無華，
為了效能也只好忍痛了。
2017年9月28日 星期四
【社群】打算將《麻雀點數計算乙女》做個小小的改版
最近過得真是超級充實啊！
做了大量的程式研究，
把uGUI的功能摸得更深入，
再將我的理解寫成筆記，
字數都超過一萬字了！
.
而App《麻雀點數計算乙女》的狀況也漸入佳境，
廣告和付費比例都在自然成長中，
因此我跟夥伴打算做個小小的改版，
加上提示用戶給五星評價、再贈送一點獎勵的功能。
.
至於爐石天梯還是有趁轉檔的時候爬，
但能不能上傳說就隨緣囉！
2017年9月2日 星期六
2017年8月17日 星期四
【社群】設計能夠達到目標的規則
這週先把想要達成的玩法目標給列出，
例如「獎勵攻擊」、
「劣勢方有機會逆轉」，
然後就開始記錄在文件上，
一邊設計出能夠達到這些目標的規則。
目前大概完成70%左右吧，
等到規則架構都差不多確定，
下週就要開始改用uGUI做出雛型試玩看看了。
2017年8月11日 星期五
【社群】繼續動工！
自從App《麻雀點數計算乙女》完成之後，
隔天立刻就回到我期待已久的《無限技域》開發。
在這半年忍著不做遊戲的過程中，
我也想清楚了幾個必要的方針，
首先最重要的就是將規模大幅縮小。
透過這次App的開發，
我更深刻地體驗到做出一款作品不難，
但要將它打磨至我能接受的程度會花上數倍時間，
所以第一版的規模絕對不能太大，
可能只會先做到劇情第一章為止，
就釋出給大家遊玩。
而平台也打算以電腦執行檔為主，
畢竟我想讓玩家能夠安心沉浸在全螢幕中體驗劇情，
而之前所使用的網頁版就只做個極小的體驗版，
用來讓好奇的新玩家能夠免下載體驗看看。
介面的部分，原本一直在苦惱要用NGUI或uGUI，
兩者是各有優缺，也各有擅長和不易辦到的事，
但朋友的一句話點醒了我，
「為何不兩者都用呢？」
雖然合併使用大概還需要熟悉一陣子，
但只要能夠順利運作，這可說是最好的結果了。
而之前遇到的一大瓶頸是，
玩法和劇情若非關聯性不足、就是互相箝制而無法有好的體驗，
因此在這半年間，我把研究新遊戲的時間大多改用在閱讀故事，
終於想出了不錯的解法。
（由於會嚴重劇透，因此無法在此透露，
非常期待大家到時親自體驗！）
其他還有許許多多的想法，
但總之還是先繼續動工吧！
2017年7月11日 星期二
【社群】Android的返回鍵功能比想像中費工夫
最近發生不少事，
真的是非常累，
不過App開發也幾乎完成了，
沒想到會為了Android的返回鍵功能，
費了這麼大的工夫。
因為在不同介面下，點返回鍵要有不同反應，
而且播動畫、等待回應時也要禁止點擊，
以及防止快速連點導致出錯等等。
現在只想趕快繼續把功能給完成，
早點讓App和大家見面！
2017年6月14日 星期三
【社群】沒想到系統還原會導致這麼多Error
最近系統越來越不穩，
於是花了一天進行系統還原，
但重新安裝Unity、VS等各種軟體時，
層出不窮的Error著實讓我費了不少力氣。
最後是把舊的Unity資料夾整個刪除、
VS用Repair的方式修復，
安裝就能順利通過了。
還有這個殘留的平台設定導致的錯誤，
http://answers.unity3d.com/questions/958342/cant-set-nonexistent-playback-engine-directory-and.html
最後是將C:\ProgramData\Unity\index-local.xml
這個檔案刪除後就能正常運作了。
祝大家軟體使用一切順利！
2017年5月31日 星期三
【社群】意外找出沒睡飽時寫出的日期Bug
今天意外catch到一條Debug.Log，
雖然不影響正常流程，
但總覺得哪裡不太對勁，
沿著Log抽絲剝繭下去才發現，
原來是我之前寫的某個類似「每日登入」機制的部分寫錯了。
.
為了計算出隔天0時的日期，
我寫了像是這樣的代碼：
System.DateTime l_datetimeNextDay = new System.DateTime (i_dateTime.Year, i_dateTime.Month, (i_dateTime.Day + 1));
假設原始時間是2017/01/05 15:30:00，
它就會得出2017/01/06 00:00:00的結果，
這在平常都能夠正常運作，
但相信大家如果有睡飽的話，可能已經看出問題了。
.
那就是當日期進入本月份最後一天時，
會得出2017/05/31 + 1 = 2017/05/32的錯誤日期！
應該寫成這樣才對：
System.DateTime l_datetimeNextDay = new System.DateTime (i_dateTime.Year, i_dateTime.Month, i_dateTime.Day).AddDays (1f);
真的很慶幸我每天都在認真工作，
才能在今天這個日子檢查出這個Bug。
2017年5月27日 星期六
【社群】自己的要求自己做！
過去在當遊戲企劃的時候，
從網路和周遭學習到不少發生錯誤的案例，
因此當時總是會在企劃書中特別加註
諸如以下的事項──
.
「數值都要設置上限，防止溢位」
.
「所有介面按鈕都要禁止玩家連續點擊，
以防產生重複或矛盾效果」
（例如重複領取同一份禮物N次）
.
「購買道具時，必須先扣錢再給道具，
而且扣錢之後就要先記錄收到、再播動畫」
（以免玩家在動畫途中跳出遊戲而白白損失）
.
我覺得像這些都是很重要的事，
但當時的我因為只是企劃，
所以每多寫一項，就是工程師要多費一份心力，
因此總是對合作的工程師抱著一份不好意思和感謝。
.
現在自己當工程師，
這些要求自己都能做到，
再也不用不好意思了，
對於我這種務求謹慎的個性來說，真是安心啊！
2017年5月14日 星期日
【社群】算機率算到記憶體爆炸
最近勒索病毒猖獗，
大家都把Windows更新，做好防範了嗎？
.
這週終於進入最後一個系統——
「御神籤」的製作，
抽籤非常講究機率與期望值計算，
自然又到了必須把高中數學拿出來的時候了。
.
而我為了多人協作、雲端備份、版本控管等好處，
平常就會用Google雲端文件來取代Office，
誰知卻在這時候遇上了瓶頸——
.
計算的資料太龐大，網頁把記憶體吃光啦！
.
幸好最後把表格移到Office上就夠用了，
這樣就不用花力氣去簡化公式了，
科技始終是為了滿足惰性 (喂)
2017年5月5日 星期五
【社群】送審版相當順利地通過了
幸好事前有詳細讀過Apple的App規範，
送審版相當順利地通過了，
中間只被兩個小問題退回來過：
1.Apple人員找不到在哪裡消耗遊戲金幣，請我說明。
2.遊戲拍照沒有完整表達出App功能
（因為只是送審版，沒有要真的上架，我就隨便拍一張而已）
美術夥伴的進度也正急起直追，
離正式上架不遠了！
2017年4月29日 星期六
【社群】iOS送審版成功送出
目前開發中的App《麻雀點數計算乙女》，
iOS送審版終於排除一切問題，成功送出了！
走到這一步，真是期待了很久哪。
這一版是用來確認是否完全符合Apple規範，
即使通過也並不會真的開放下載，還請大家再等一會了。
而實際上，App還有收集麻將乙女的系統要製作，
介面也尚未改為優化版，只等美術夥伴趕上進度，
這些完成後就離正式開放不遠了！
2017年4月22日 星期六
【社群】IAP與iOS版本測試中
初版的功能已經都完成了，
目前在測試IAP（應用程式內付費）與iOS版本。
不過就只是為了要把我的iPhone加入開發人員裝置清單，
它的UDID卻很不好取得，
既不能從手機上直接看到、
現在也無法像以前一樣從iTunes查詢，
最後還是透過Xcode才終於取得，不好用的介面真是會讓人爆血管哪！
2017年4月16日 星期日
【社群】這真是一條好長，好長的路啊...
日本麻將的計點App開發到今天，
正好是兩個半月，比當初預估的還多花了半個月。
這兩個半月來，我幾乎是過著一週工作七天、每天工作8~16小時的生活，
如今終於把Android版檢查過沒有Bug，
開始著手做細節優化和iOS版測試了。
雖然只有短短兩個半月，
但卻不禁令我覺得，
真是一條好長，好長的路啊...
2017年4月9日 星期日
【社群】維基百科真是最好的規格書了
昨天終於把48種日本麻將役種都判斷完成了，
多虧了維基百科，詳細而嚴謹的規則分門別類，
再加上圖文範例、極端狀況也列舉出來，
真是最好的規格書了。
這麼說起來，以前每當有人問我「遊戲企劃書該怎麼寫」的時候，
礙於職業道德，我沒辦法拿以前的公司作品給人看，
而我自己開發時又不會寫那種「給人看」的企劃書
（都只是寫給我自己備忘用，因此太過精簡），
因此都只能口頭講述大原則；
現在想想，雖然說企劃書沒有標準格式，
但若能夠寫得如維基百科般條理分明，
對程式設計師來講就已經很實用了。
2017年3月31日 星期五
2017年3月26日 星期日
【社群】期限前的優化
距離當初設定的兩個月期限剩下五天，
我跟夥伴都在努力趕進度，
但途中又忍不住做了許多優化，
雖然讓時間變得更緊迫，
但看到品質的提昇也覺得非常值得。
接著等Logo完成，
就可以開放粉絲頁讓大家一起看看了！
2017年3月20日 星期一
【社群】於是乎森林又恢復了往日的和平
剛解決一個程式問題，
有種「學得越多，反而越把事情想得太複雜」的感覺XD
若將那個問題描述成情境，大概像這樣：
「森林中有藪貓、小背包、朱鷺、幸運獸和拳四郎，
平常大家都相處得たーのしー，
但是當下列幾種動物(?)聚在一起時，
會引來邪惡的盜獵者：
藪貓+朱鷺
河馬+幸運獸
藪貓+拳四郎
藪貓+幸運獸 且 小背包不在
etc...
」
然後我就花了大量時間修改和測試，
想寫出讓盜獵者完全不會出現的簡潔公式，
搞得我豆頁都快爆了。
但是最後想到的解決方法，其實非常簡單──
盜獵者出現時，叫拳四郎把他秒殺就好啦！
天下太平。
2017年3月19日 星期日
【社群】預計為App建立粉絲頁
當初預定的兩個月開發時程，
很快就要過去了，
內容也越來越有完成品的樣子。
之後打算為這個App建立粉絲頁，
預計釋出一些開發中的畫面、
以及進行內部測試等等，
有興趣體驗看看的朋友歡迎留個言，
等粉絲頁建立後我再把你們加入囉！
2017年3月8日 星期三
2017年3月3日 星期五
【社群】快，還要更快
和夥伴一起決定做個App的那天正好是2/1，
到現在過了一個月，就來做個回顧吧。
第一週：
主要用在發想主要及次要功能，
規劃收費模式和UI雛形。
這時候還沒有明確分工，許多事情是共同討論完成的。
第二週：
方向大致確定，就開始試做原型了。
UI和美術的職責也在此時放手交給夥伴去決定，
我則是將專案和基本功能框架完成，
讓夥伴可以實際試用過App再優化設計，
然後我再次匯出App給他試用，如此不斷調整。
第三週：
規格中添加了許多必要的項目（如防弊機制等），
並將部分功能移至次要，
目標是在當初預期的2個月內左右完成。
這週仍在配合調整UI，
而等待夥伴調整的時候我就繼續寫核心功能。
核心功能雖重要，但因為屬於我的獨立作業，
並且我有把握能完成，所以不急著做完，
而以需要兩人配合的部分優先。
第四週：
由於規格和功能已經不會有較大變動，
就可以讓夥伴自行把UI規劃完成，
我則處理了各種核心功能以外的雜事，
包括申請信用卡和雙平台開發者帳號、
完成本地儲存的簡易加密機制（因為不打算架Server）、
加入Analytics & Unity Ads的基本使用、
優化專案效能及整理程式碼、
在App上方顯示系統資訊（網路、電量、時間...）、
還寫了篇個人網誌。
說起來，
這個月幾乎都處在「快，還要更快」的趕工狀態，
但為了更遠大的目標，
我們還得更快才行。
總之，繼續衝刺。
2017年2月15日 星期三
【社群】太過自信的做法
有點生自己的氣...
目前開發中的App，
由於某個功能的操作改成另一種模式，
感到興奮(?)就直接改下去了，
結果越改越亂（還好有保留舊程式碼）。
浪費了快兩小時後，
才想起我應該先把邏輯整個重擬一遍，
這下子五分鐘就搞定了...
這種太過自信的做法，下次得記得別再犯才行。
2017年2月10日 星期五
2017年2月1日 星期三
2017年1月29日 星期日
【社群】次要角色的呈現
新年快樂！
最近一邊過年，一邊也把劇情越寫越完整了。
我想用比較遊戲化的方式，
讓玩家親身體驗這個世界發生的種種，
而不是翻書似地看完一大篇故事，
但如果登場角色太多的話，
立繪甚至CG的數量也會大增（我可負擔不起那麼多），
所以可能會直接使用卡圖或者剪影的方式，
來呈現次要角色吧。
2017年1月22日 星期日
【社群】原創比二創辛苦多了
我是個在乎劇情合理性的人，
因此在述說一個故事時，會希望角色們的行動都合情合理，
每試寫一段劇情，就會代入各角色的立場，
看看這樣發展有無違和感。
但這種完全自由的企劃空間，對我來講也是最燒腦的事呢，
反而不如限制多多，只要在限制內思考怎麼做來得輕鬆了，
這也就是原創比二創辛苦之處吧。
2017年1月11日 星期三
【社群】才華洋溢的年輕人
看到周遭許多才華洋溢的遊戲人都比自己年輕，
認真覺得自己還努力不足啊。
以前的技能點幾乎都點到研發企劃上了，
後來加點了程式能力，
而最近開始要用到劇本能力，
光靠以前累積的文筆還不足以應付，
又做了一番吸收消化才找到方向。
之後還有行銷、營運...等許多考驗呢，
我想這些恐怕也不是我一個人能做得好的，
但我重視的結果是「完成」而非「賣錢」，
所以剩下的就等完成之後再考慮吧！
2017年1月5日 星期四
【社群】聽《月薪嬌妻》的OP、ED提神
最近為了學生，
幾乎都專注在做教學用的格鬥遊戲，
由於是沒試過的類型，
所以也做得非常有樂趣。
包括2.5D的呈現和判定、
搓招式的判定等等，
偶爾有想不透的時候，
只要帶著它睡一覺起來就自然有答案了。
缺點是一想透之後就睡不著，
所以作息變得非常亂，
這時候就要聽《月薪嬌妻》的OP、ED提神啦！
（其實片尾的舞蹈才是這部的本體吧）
訂閱：
文章 (Atom)