2010年的夏天，我得到了一份offer，讓我做iPhone應用來推銷一本書。考慮到要進入遊戲行業是出了名的難，我決定抓住這次機會，在我的簡歷裡填上：釋出過遊戲。最棒的地方在於，我能全權掌控這個遊戲的設計開發。
現在，我已經不是班裡成績最好的學生了，現在我更想進入Tau Beta Pi協會（只有班裡前5才有資格加入）。我選了人工智慧，圖形學，遊戲開發等課程，並且都順利的修完了它們。
但學校歸學校，現實歸現實。我很樂意和你分享在寫程式碼階段鬧出的洋相。在寫iOS遊戲的過程中，我發現有些事情和我想的不一樣。
10) “快完成”和“完成”之間的距離比你想的更遠
不知道你有沒有見過這個遊戲，它是一個很古老的記憶遊戲，你需要翻開一張牌，然後，還要再找到另一張和它匹配的牌。不一樣的地方是，你只會在某張牌的上下左右找到與之匹配的牌。意思就是你匹配的兩張牌一定緊靠在一起。這就增加了一點難度，我必須保持所有牌的匹配牌都緊鄰著它們自己。
我花了幾個下午弄出了原型，期末考試快到了，擠出這點時間不容易。這遊戲現在看起來像這樣：
所有元件都在這了，想必不要幾天就能完成了。
僅就時間而言，遊戲內容本身只需要5-10%的時間就能做好。然而，對於遊戲的軟體架構和具體實現有相當多的內容需要做，紋理，動畫，儲存系統，成就，音效，計分系統，web結構，還有許多其他瑣碎的東西都等著編碼。你在學校做的大部分專案都是教學demo，而大部分的教學demo都不是一個完整的產品。
09) 簡單並不意味著它不消耗時間
在開發階段，我安排了整個週末來完成這個應用，當時我打算花一小時來完成一個牛逼的計分系統。但最後，那花了我一天。
這個高檔的計分系統要針對遊戲做各個方面的計算，給每個有需要的地方打分並賦值給變數，並把它新增到結果裡。但是，首先你必須先得到你要打分的裝置，校準裝置，保證它不會產生錯誤的分數，確保分數能儲存並且在有新的高分時替換之前的高分。噢，你還必須完整的測試它。
核心功能所花費的時間最好不要超過總時間的十分之一，想知道為什麼嗎？因為花費在應用上的50%的時間都是花在了你玩遊戲的時候不曾預料到的事情上。滾動GUI不難，我第一次寫圖形介面的時候就做了它，但是現在卻要常常維護它。
我之前做過更復雜的專案。這個春天，我寫了一個比這個遊戲複雜的多的遊戲引擎。它只是把很多小片段組合在了一起，最後它變成了一個很長的專案。
（伯樂線上配圖）
08) 細節也會絆倒你
回想你以前的程式設計經歷，當你的程式碼編譯完，但是卻無法工作，你一遍又一遍的檢查原始檔，最後你發現：
|
1 2 3 |
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%完成，並且能被使用者使用的軟體。也許不會大受歡迎，但它應該是一個完成品。你會知道學校學習和真實的軟體開發之間的微妙的差別。如果你是在學校做的遊戲開發的培訓，你是無法獲得一些真正的遊戲開發中需要的知識的。隨著遊戲行業的發展，需要你每一方面都有所瞭解。