遊戲開發進度、情況以及結果的關係（我的感言）

首先，賺錢的遊戲不必定是管理、開發很給力的。
賺錢的遊戲的代碼可能很爛。

詞語定義：
自理：作好事情，管好本身或小組或部門，不會由於作錯了致使對其餘關聯的人、小組、部門產生任什麼時候間代價。

可是，若開發、管理流程很好，不是更好麼？

初期的項目，注重養成良好的流程、開發規範並落實，以後基本上就比較順了，把控一點：重要的技術點確保健壯。

一、最高原則，數據要儘量文本化，設計要儘量簡單。（好比策劃表儘量使用xml，數據庫存的時候，複雜的對象用json格式）
二、數據表必定要作足檢測，值範圍、表關聯邏輯，服務器開機時，若數據錯誤，那麼寫錯誤日誌，退出。客戶端也如此。
各類命名儘量的統一爲小寫。
三、當出錯時，必定要退出並報告爲什麼錯誤，方便排錯，而不是默默地繼續運行，等詭異問題發生時，傻眼。
四、服務器必定要注重協議文檔、數據庫表設計。 表必定要有註釋，協議號必定要統一併惟一，協議規則必定要簡單明瞭，協議描述不要使用位域來節省流量 -- 這件事交給壓縮吧。
五、入職規則的重要性，習慣是養成的，初期必定要儘量的全的寫好規則文檔，而後花時間監督落實。
六、與數據庫交互時，慎用存儲過程，看起來簡單，可是遇到性能問題時就傻眼了；必定要寫sql語句執行日誌，就算與mysql鏈接斷開，也可經過日誌來保證數據的不丟失。（建議拼sql語句方式操做）。
七、服務器組間，必定要有一個約束、管控規則，好比全局性的服務器、網關等，每一個的職責、以及當與某個服務器鏈接斷開時的善後處理等。
八、玩家行爲日誌儘量的文本方式存，一樣若與日誌服鏈接斷開時，寫本地日誌，此處不要實時寫。
九、過渡濫用任何東西都會產生問題。 好比，你想過當把當前的日誌系統屏蔽後，性能提高極大嗎？
十、有些東西應該以庫的方式來包裝、體現，而不是和邏輯柔和在一塊兒，這樣當其出問題時，一團亂麻，沒法理清。
十一、不要過早優化，實現時所自覺得是的優化多是未來的性能瓶頸！！！ ---  除非極其肯定。
十二、客戶端要有一個機制，能夠把一些日誌、錯誤等上傳到服務器，供開發人員分析。
1三、代碼將來必定會最少兩個版本，資源版本最少須要4個。程序開發版資源、定版穩定版資源、策劃版資源、QC版資源， 不然。。。會有多糟糕沒法預知。
1四、再次強調文檔，客戶端、服務端的技術文檔、庫文檔，沒有這些，那如何讓一塊兒開發的同事瞭解該調用哪些接口呢？ 或者，由於不知道，由於沒溝通，因此本身實現一個？這樣的最終結果是亂，亂，亂！！！
框架、庫接口文檔、模塊接口文檔，各類規範文檔必定要有，不然，後期的維護是噩夢。（中後期也各類蛋疼！！！）
1五、關鍵點：落實，首先要有文檔，你們都能看到，接着，要實現所指望的流程，按所指望的行進。
此時：督促、監督，或者招個項目助理定時統計彙報啊， 目的在於：養成習慣，當每一個同事都習慣的按着既定的規則來作時，那麼此時有多麼高效、多麼輕鬆愉悅？？？
1六、開發中，遇到的一些問題，要儘早、儘快的解決掉，不管是技術問題、管理問題。不然。。。會成爲所謂的「歷史問題」，代價極大的包袱。
有時候要冷血，所謂的大局，當開發都出問題時，要大局做何？ 除非都在混日子。
有時，須要做出轉變，殺雞儆猴，強力暴力的推動流程，改掉已經養成的壞習慣，此時，很沒人情味，也很招人嫌。
1七、每一個部門要主管，小組要組長。遊戲開發不是靠一我的的，是靠你們的，部門出問題，主管有責任，小組組員出問題，組長有責任，不然，要組長幹啥？要主管幹啥？ 管理，是劃地而分的，管好本身的一畝三分地，並保持自理，那麼是最優的。
1八、各部門要並行，程序、策劃、QC&QA。
1九、技術選型，必定要作好調研，技術細節坑的預測、攻克。不要期望每一個人都和本身同樣靠譜，不要認爲有錢，而後很容易就能招到靠譜的人，服務器要穩定！穩定！！！ 用腳本、用java，必定不要用c/c++等。 遊戲邏輯是高度複雜而且容易變化的。 c/c++能夠作底層庫、框架，遊戲邏輯必定要用不容易錯、容易掌握的技術，切記性能不是第一優先。  （關於服務器原則方面：參考這裏）
20、開發時，任何事情都有優先級、和不一樣的代價，如何肯定當下作什麼，能夠根據當前的里程碑來評估，或者經過剩餘事情的定位，好比邏輯，好比底層、框架等基礎性設施、工具等。 能夠根據當前的需求來定。
2一、開發時，要考慮總體流程的便捷性，不能方便了程序，結果策劃工做量大增，實際上不少東西均可以自動化的，要思考，如何作，才能減小總體制做的成本，要的是整套解決方案，而不是一個部門的。記住，遊戲不是一我的、一個部門能夠作出來的。
2二、版本合併必定要在一臺電腦上、而且一我的來作，不然。。。 好比，依賴機器時間的打包工具，好比，要生成總的索引等，那麼，，，
2三、開發中，不少最壞狀況原本就能預料到，可是就由於不夠重視，認爲「不會有問題的」，而後就草率的進行了，結果呢？這原本是能夠避免的，這不該該成爲昂貴的教訓！！！
2四、要長記性，不少錯，犯一次就夠了，不要第一次、第二次、第三次、第四次。。。   這樣還能作出東西嗎？？？  不要想着撞大運，要腳踏實地一步步堅實的前進。
2五、要多記，不要養成依賴心理，不要老期望別人說，這個東西怎麼弄，別人欠你什麼嗎？爲什麼不本身解決？ 當你諮詢別人一個問題時，爲什麼不記起來？結果了，隔了一會，又來問。。。 而後，隔了幾天，又來問。。。   拿個筆，記到紙上，或者電腦的記事本上不行嗎？ 這樣的習慣、這樣的態度，如何成長？？？
2六、學會主動，學會成長。一年前，我是那樣的，一年後，我是這樣，我成長了多少呢？是否虛度了一年？ 假若只是爲了工資，抱歉，你能夠無視此文章。人都會犯錯，都有不會的東西，那麼當須要時，學，當犯錯時，銘記，下次力爭不犯（寫手上不行嗎？），習慣，是從一點一滴的小事養成的。 成長，也是從一個個小事、一個個時間空閒，得來的。
2七、還有什麼？ 不知道。 忽然有感而發，隨意胡亂寫的，不少事情，沒那麼難，在於專一，在於執着，在於行動。

總結：
陸陸續續，經歷過好多短時間的、稍長的開發時間，經歷過各類狀況。也由於想經歷一下後期的項目，而去嘗試，發現很難很難，時間緊，問題多，項目負責人想盡快看到改變的結果，可是又要考慮所謂的「大局」，不破不立，是繼續艱難的從遲暮到老人向精神奕奕的小夥轉變呢，仍是繼續維艱難的向稍微步入遲暮的狀態？

一直明白，事情不會徹底按照本身的意願而發展，事實確實如此，可能在我看來很簡單的事情，可是套上所謂的大局觀等等其餘的因素，那麼，太過複雜。
不要輕易選擇，得與失有時候不那麼重要。

繼續鑽技術，儘可能去參與剛立項的項目吧。