永遠緬懷開始從事遊戲開發的日子

學校裏永遠以爲事情都很簡單，只要願意，就會水到渠成，但學校歸學校，現實歸現實。我很樂意和你分享在寫代碼階段鬧出的洋相。在寫iOS遊戲的過程當中，我發現有些事情和我想的不同。

10) 「快完成」和「完成」之間的距離比你想的更遠

不知道你有沒有見過這個遊戲，它是一個很古老的記憶遊戲，你須要翻開一張牌，而後，還要再找到另外一張和它匹配的牌。不同的地方是，你只會在某張牌的上下左右找到與之匹配的牌。意思就是你匹配的兩張牌必定緊靠在一塊兒。這就增長了一點難度，我必須保持全部牌的匹配牌都緊鄰着它們本身。

我花了幾個下午弄出了原型，期末考試快到了，擠出這點時間不容易。這遊戲如今看起來像這樣：

                              全部組件都在這了，想必不要幾天就能完成了。

僅就時間而言，遊戲內容自己只須要5-10%的時間就能作好。然而，對於遊戲的軟件架構和具體實現有至關多的內容須要作，紋理，動畫，保存系統，成就，音效，計分系統，web結構，還有許多其餘瑣碎的東西都等着編碼。你在學校作的大部分項目都是教學demo，而大部分的教學demo都不是一個完整的產品。

09) 簡單並不意味着它不消耗時間

在開發階段，我安排了整個週末來完成這個應用，當時我打算花一小時來完成一個牛逼的計分系統。但最後，那花了我一天。

這個高檔的計分系統要針對遊戲作各個方面的計算，給每一個有須要的地方打分並賦值給變量，並把它添加到結果裏。可是，首先你必須先獲得你要打分的設備，校準設備，保證它不會產生錯誤的分數，確保分數能存儲而且在有新的高分時替換以前的高分。噢，你還必須完整的測試它。

核心功能所花費的時間最好不要超過總時間的十分之一，想知道爲何嗎？由於花費在應用上的50%的時間都是花在了你玩遊戲的時候未曾預料到的事情上。滾動GUI不難，我第一次寫圖形界面的時候就作了它，可是如今卻要經常維護它。

我以前作過更復雜的項目。這個春天，我寫了一個比這個遊戲複雜的多的遊戲引擎。它只是把不少小片斷組合在了一塊兒，最後它變成了一個很長的項目。

08) 細節也會絆倒你

回想你之前的編程經歷，當你的代碼編譯完，可是卻沒法工做，你一遍又一遍的檢查源文件，最後你發現：

if( var = THAT )
{
}

這種小而氣人的bug不會由於你在作一個大項目而消失。他們每每會蹦出一大堆怪異的API錯誤提示，說這些形成了你的程序出錯，而不是真正錯誤的那行代碼

因此，若是你想要一我的完成RPG遊戲做爲你的第一個項目，請記住類裏的這種單行bug有多讓人厭煩。被煩多了，你就知道要如何避免這種類型的bug，無論項目是大是小。

07)瞭解和理解是不同的

項目的早期，我用OpenAL給iOS作了一個音樂播放器。我再windows上作過類似的東西，徹底沒難度。流程就是你讀取音樂採樣，而後放到音樂隊列裏，播放它們，若是採樣播放完了，你能夠加載更多的音樂文件。

看起來沒啥問題，iOS SDK有一個解碼器恰好有全部我須要的功能，可是不知道什麼緣由致使了音樂不能循環。在調試運行後，我發現音樂播放完後應用會讀取0採樣，可是我明確的告訴過它要讀44100採樣。幾回重編譯和Google一下之後，發現是讀取採樣的函數結構有問題，這個結構有一個可變的採樣尺寸。當音樂播放完時，他就會讀取0採樣並把相同的結構回送，形成了這個函數讀取0採樣。

當你坐一個項目時，你可能會想「我知道怎麼作」。然而，除非你以前作過，不然你僅僅是有怎麼作的想法。「我知道」和「我有一個如何作的想法」是不一樣的，它們的區別可能會讓你頭疼好幾個小時。

06) 理論不能代替經驗

有一個觀點是：患病的計算機科學界真的須要酒精來消消毒了。在你上Java數據結構課的時候，他們總會大言不慚地跟你說：「（數據結構跟語言無關），不管你用什麼語言來寫都是同樣的。」不對！媽蛋的，徹底不是這樣！

記住，你是在用計算機工做。若是拼寫錯誤，就算同一臺電腦也沒法編譯你的代碼。那些最雞零狗碎的細節會形成你的程序沒法運行，包括那些與你使用的編程語言或操做系統相關的怪異細節。

在這個項目以前，我曾作過GUI，圖形學，多線程，音效，C++和遊戲編程。這個項目也和我之前用其餘工具作過的項目在概念上相似。我想說的是，編譯器沒法靠理論來編程，它要靠代碼工做而且會在遇到許多小錯誤時拋出異常。這就是軟件工程師不懼怕機器人啓示錄的緣由。誰會懼怕一個由於引號錯位了就會崩潰的東西呢。

毋庸置疑，理論很重要，但個人目標不是像教授同樣教理論（或者得到終身職位，我就能夠中途退休了）。我要獲得軟件必須動手去作。理論理解和動手實踐是不同的，動手實踐意味着電腦前的無數個不眠夜。

05) 編寫軟件不是部分的簡單疊加

即便你會圖形學，媒體編程，GUI編程，但這並非說你必定知道如何把他們整合到同一個應用裏。你不只要編程其中某一部分，還必需要把它們組裝在一塊兒而且流暢的運行。噢，說比作簡單多了。

你設計/實現/測試A部分，而後又設計/實現/測試B部分。直到你意識到它們須要重構才能一塊兒工做以前，一切看起來都很完美。因爲時間不夠了（你老是時間不夠），你想着用很是規的方法來組裝它們實現功能，這樣反反覆覆，噢，像滾雪球同樣越滾越大（愈來愈糟）。隨着其餘人加入到你的開發團隊，你就會要面對設計上的挑戰了。

設計不是一項能在課堂上就教會你的技能。須要經過經驗，嘗試，試錯，以及遭受過幾回意大利麪條式的代碼，你才能學會設計的訣竅。

04) 遊戲開發不只是編程

爲了讓這個站點的設計能引發讀者的注意，我已經藝術得可以七十二變了。對於遊戲編碼來講，我認爲必需要有藝術設計規範。我特別瞭解藝術規範的必要性。由於每一次（和美工）的理解偏差都會致使美工設計人員不得不去畫板面前再解釋一遍，這麼作又費時又費力，公司管理層對這種事情但是很不爽的。（做爲美工設計人員，）你不能僅僅就是說「我須要一個按鈕」，由於程序員和美工之間關於「這個按鈕」的想法極可能是千差萬別的。

當你爲遊戲公司工做時，你還須要記住一件事，你是在爲遊戲公司工做。他們是來掙錢的，你得和這些生意人有交流。你可能要接觸市場，還要處理他們搞出來的臭狗屁。他們在經歷了New Coke（譯者注：可口可樂失敗的營銷案例）同樣徹頭徹尾的失敗以後，名聲盡失也是能夠理解的。但他們也帶來了美味的Betty Crocker的蛋糕粉（我依然留着）在20世紀50年代，Betty Crocker的蛋糕粉雖然看的人不少，可是買的人不多。後來被僱來營銷的銷售公司想出了一個提升銷售量的辦法。他們發現若是家庭主婦的飯作的不是很好，她們會以爲內疚。銷售公司爲了解決這個問題，開始指導用戶如何添加雞蛋和蛋糕粉。這帶來的成果就是這種蛋糕今天依然在賣。你可能只是但願你的遊戲能運行就行了，由於遊戲好很差賣和遊戲開發者不掛鉤。

在遊戲行業中，你必須和那些不懂循環（編程）的人打交道。這些人說着稀奇古怪的需求，理解他們說的是什麼，很重要。

03) 專業的測試人員很重要

遊戲快完工時，須要爲遊戲在AppStore的上架審覈作準備。你聽到的全部關於遊戲測試很乏味的消息都是真的。一旦你開發併發布了本身的遊戲，你就知道爲何了。

若是你是一個程序員，而且你讀到這了，你就知道要如何精確的編碼了。在不熟悉的領域裏，大多數雜事都會讓你焦頭爛額。有一個團隊來幫你解決這些事能夠節約你編碼的時間。

做爲程序員，你要學會說「個人已經作完了」。使用其餘的團隊來尋找、記錄bug，你能夠與它們發起一個（針對遊戲bug）的比賽，它們破壞，而你修復。最後，你就能得到一個強勁的，流暢的，bug不多的遊戲。

02) 最後期限是你的頭號敵人

全部問題看起來彷佛都只是小事。就他們單個而言，多是這樣。可是當他們放到一個app裏時，這些問題就會迅速積累。時間是有限的資源，知道如何準確的預判時間（項目週期）是頗有價值的。

學習估算項目週期是一項軟件工程課不會教給你的技能。之前，我和同伴有過一個新項目，我沒有跟蹤進度，項目團隊一個夏天都耗在了RPG的討論裏。

有句商業名言「所測即所得」。在作項目時，保持每件事的進度跟蹤很重要，甚至能夠畫一張簡單的對照表：

這會鍛鍊你（自我管理）的能力，尤爲是管理你最重要的資源：時間。

01) 學校的學習是最起碼的

咱們都聽過比爾蓋茨輟學的故事。而且老是忽視一個事實：他十三歲就接觸了電腦，而且開始日日夜夜的學編程了。比爾蓋茨輟學的故事之因此有那麼大的吸引力，是由於人們老是想要不通過努力就成功。

可是不要只是努力學習，要聰明地學習。教學Demo不夠。你想要開發一個100%完成，而且能被用戶使用的軟件。也許不會大受歡迎，但它應該是一個完成品。你會知道學校學習和真實的軟件開發之間的微妙的差異。若是你是在學校作的遊戲開發的培訓，你是沒法得到一些真正的遊戲開發中須要的知識的。隨着遊戲行業的發展，須要你每一方面都有所瞭解。

牢騷到此爲止，還請持續關注更新，更多幹貨和資料請直接聯繫我，也能夠加羣710520381，邀請碼：柳貓，歡迎你們共同討論