Dirty Coding Tricks by Brandon Sheffield
================================================
今天在Gamasutra上看到的一篇文章。
遊戲開發有時程壓力,而當我們發現一個很難解的Bug,時間又已經來不及的時候,我們該怎麼辦? 這篇文章就舉出了幾個偷吃步的故事。
頭一個故事就很慘了。
在一個PS2遊戲即將要發行的時候,測試團隊發現,在第一個關卡裡,玩家只是靜靜的站著就偶而會造成crash,而且更不幸的是,是在燒成光碟之後,這個問題才會出現。
於是開發團隊為了解決問題,不斷的修改程式,燒成光碟,然後測試,弄了十幾個小時( 為了等程式 crash,只好拿 World of Warcraft 打發時間.... )。
後來奇蹟出現了。有人發現,一開始攝影機向右轉個90度的話,程式就不會出問題,於是乎,PS2的版本,就在攝影機轉個角度之後,順利通過測試而發片。而已經上架的另外兩個平台的版本,攝影機角度還是維持原先的設計。
我的結論是:寫程式,也需要奇蹟。
第二個故事,真的就是偷吃步了。
遊戲程式中所用到的資源,例如一大堆的檔案,在檔案系統中通常會想些編碼的方式當作索引來存取這些檔案。這個故事裡的團隊很倒楣,他們將檔案的檔名CRC32編碼,同時也將檔案內容做CRC32編碼,用這兩個值組成64位元的索引來存取檔案內容。
開發了兩年,處理了幾萬個檔案,從來沒有發生索引值衝突到的狀況。
可是,它真的發生了。兩個不同內容的檔案,卻有完全相同的檔名(也不知道為什麼要這樣設計....),而且檔案內容在編碼之後也得到相同的CRC32編碼--這下子事情大條。
改檔案系統,改索引方式,都是個大工程,而且誰知道改了之後會不會發生同樣的狀況? 這時候,再怎麼完美的編碼方式,都沒辦法給人信心了。
沒時間了,只好用一個最簡單的偷吃步解決這個問題 -- 把其中一個文字檔案打開,在最後面加一個空格,然後存檔。
於是乎,遊戲如期發行。
當然啦,這些方法都不是好的解決方式,而且會帶來後續的問題,不管是程式穩定度還是程式維護上的問題。
不過,對我們老是在有限時間跟疑難雜症打仗的人來說,這些故事是會讓人會心一笑的。
5 則留言:
扯~不過管用!
同感,ps2真的常常會有奇蹟般的bug啊~~~
我們自己遇到過跟第二個故事類似的狀況。原先我們的檔案系統索引值沒那麼嚴謹,只是用檔案大小來附加計算,結果就常常會發生索引值衝突,一開始也是加一些無意義的資料來改變大小,後來實在受不了,就把索引方式徹底改掉了....
莫非定律:當我們認為絕對不可能發生衝突時,就會在完全意想不到的時候發生衝突。
另外,我認為原文中最後一項 static buffer 的做法,真的是個很黑暗又可以學起來的好招耶! XD
crc等雜湊碼本來就一定會碰撞了,不然就可以做資料壓縮了。
張貼留言