網頁

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種日本麻將役種都判斷完成了,
多虧了維基百科,詳細而嚴謹的規則分門別類,
再加上圖文範例、極端狀況也列舉出來,
真是最好的規格書了。

這麼說起來,以前每當有人問我「遊戲企劃書該怎麼寫」的時候,
礙於職業道德,我沒辦法拿以前的公司作品給人看,
而我自己開發時又不會寫那種「給人看」的企劃書
(都只是寫給我自己備忘用,因此太過精簡),
因此都只能口頭講述大原則;

現在想想,雖然說企劃書沒有標準格式,
但若能夠寫得如維基百科般條理分明,
對程式設計師來講就已經很實用了。