概念和例子章，一定有學習的價值，遊戲產業基於一些問題，大部分的概念都是由軟體產業帶過來的。遊戲測試也是在公司內部技術含量和重要程度偏向弱化的，實際上是可以改變的。
我也被一些朋友戲稱為遊戲產業的cmm…呃慚愧，實際上只是可以勉強做得好=>cmmi3，4以上的級別我自己就沒有接觸過了。
但是不得不提的是，階段性和模型，你在查閱cmmi1~3裡就能看到國內包含已知大公司的工作流（工作流不是工作流程），接近一樣，所以可以驗證為暫時是科學的，實際就是科學的。
之前不少人覺得開啟成本大或者沒有必要及紙上談兵，我願意寫點東西分享部分和**是作用在**？結合了部分軟體工程，程式設計**向項。
測試成熟度模型(test maturity model)，他對應的是cmmi和cmm，通過成熟模型級別進行評估和改進。
已驗證通用於遊戲產業，我是用了差不多5年，拆分在公司中出來做的，整體依然完全遵循模型原本的東西，不做位置的修改，不過當你很清楚遊戲開發的階段性，你自己也可以調整下做的時間多少。
什麼是成熟度目標，很簡單0級別% ，公升到了100%就到了0級100%，1級包含了0級的內容，是在0級做了優化的，那麼最高端別，5級也就是最大的了。我這裡只有能力談到tmm2，經過驗證過。
舉個工程師的假定只有2級例子，這裡用肯定不恰當，但有一定參考性，工程師的技能假設有6專案，每專案的都是必須存在的，那麼123代表了初級工程師的，1456代表高階工程師的，按業務來區分的例子，那麼其中123代表的是初級的特徵，456代表了是高階的特徵。其中1是必須的，知道是什麼___（填空）？測試技能不分重要性，只由全面性和每項到一定的深度才能公升級，就和乙個技術天賦樹一樣。
回到原來話題，tmm的5個級別反映了不同測試過程的成熟度。
tmm等級1：
沒有目標；缺乏測試資源（用例，規劃和測試方法），工具和熟練的測試人員，沒有明確的計畫。
這個是很多公司存在的，概念混淆測試方法比較單一，也沒有防止漏測的行為。
比如一直跑遊戲，制定1個時候後，收集大家的問題，如果問題不多和不大，就要上線了。
或者完全依賴專案組的指派，要做什麼就做什麼。甚至把大量時間用於測試概率方面。
對理論方法比較缺乏，憑藉自己的遊戲能力進行測試。
做為1個苦逼青年，我前幾年的光陰阿。還好我失戀了後，奮發研究，老天雖然忙，還是比較公平的。
那麼如何改進呢，上面講的是相反的，如何轉換成正面不用說了吧，轉換成正面後，你會發現阿，原來這塊涉及到了前1~3的部分。相信看完這份文章後，我自領團隊的同事，也就明白了tmm1~5時什麼，實際都完全接觸到了。後續學到多深，加油吧。
tmm等級2：
階段性定級：
制定測試計畫與調式目標；
啟動測試計畫過程；
制度化基本的測試技術和方法。
Rogue遊戲（一） 遊戲框架搭建
rogue遊戲有著悠久的歷史，為了向經典致敬，我也打算自己編寫乙個類似的遊戲，這次先將遊戲的框架搭建起來。編寫和執行環境是linux，用到curses.h 終端圖形庫 編譯方法 先編寫makefile，然後make，執行方法 終端下輸入.rogue makefile rogue rogue.cpp ...
遊戲策劃關於遊戲概念和遊戲原型設計
遊戲策劃的職位分工，主要分為主策劃 系統策劃 執行策劃 文案策劃 數值策劃以及場景策劃等幾個職位。其中，主策劃負責整個遊戲的整體規劃，同時擔任著整個策劃組的工作分配和進度審核的任務。系統策劃更偏向於遊戲架構和核心系統的設計，是決定乙個遊戲遊戲機制的角色。執行策劃負責在實際工作中將整個遊戲的具體玩法進...
《遊戲程式設計模式》一1 3 效能和速度
你有時候會聽到關於軟體架構和相關概念的批評聲，尤其在遊戲開發中 它會影響到遊戲的效能。許多模式讓你的 更加靈活，但是它依賴於虛函式派發 介面 指標 訊息以及其他至少有一些執行成本的機制。乙個有趣的範例是c 模板。模板元程式設計有時可以讓你獲得抽象介面而沒有任何執行時開銷。對靈活的定義，不同人有不同的...