第10章.調試
【開發期】
- 使用Assert(斷言)令程序崩潰以提前發現錯誤；對斷言分級，並可選擇關掉部分非常影響效率的部分；
- 將釋放的指針置爲空，空指針更容易把錯誤表現出來；
- 加入錄像模塊(記錄輸入數據到文件中)，出錯時便於重現；
- 使用分級log日誌，並跟蹤代碼運行流程，便於定位。
【已發行】
- 打開可以打開的Assert；
- 使用第三方調試器。
第13章.開發方法
【失敗經驗】
- 過多的工作壓在同一人身上；
- 過分的彈性工作制(彈性不代表無計劃)；
- 沒玩沒了的變化，沒完沒了的返工；
- 沒有及時的測試，如果Bug太多，不如推倒重來做更好的設計；
- 項目主導嚴重偏向某個職位(市場策劃程序美術應多溝通，共同努力)。
【成功經驗】
- 引擎和實現分離（客戶端應分出一人獨立負責圖像底層；服務端應一人獨立負責網絡和序列化，而不去管任何的遊戲邏輯）；
- 結對編程-有經驗水準差不多的兩人(一臺電腦，週期性打亂配對互換位置，提高效率提升能力，每天6小時即可)；
- 隨時方便的測試，不要吝嗇爲實現寫測試代碼；應自動化，可錄像回放。
- 儘早發現結構上的問題並及早重構；若發現太晚，及時凍結新功能加入，裁剪內容，保證現有東西不出錯；
- 必須使用SVN/Git進行版本控制，並分爲Realse/Dev兩個分支；
- 使用腳本語言實現客戶端UI，服務端劇情/任務等容易變動的部分。
【項目總結】
- 遊戲是策劃美術程序（細分爲引擎、工具、實現）等合作開發的，存在依賴性，同時開展這些工作有時欲速則不達；
- 策劃先寫案子，然後美術依此完成場景、人物甚至界面，程序再開始；若策劃/美術需改動，記錄整理後放入下一版本；
或者 程序製作和具體設定無關的東西，美術填資源，策劃按程序可實現功能做案子；不盡如意，迭代下一版本； - 許多工具開發初期都可先省略，如地圖編輯器可先用PS圖層暫代，維護期再做亦可；
- 策劃案完成後，先不考慮娛樂性，而應從平衡性考慮，把可刪除的都刪掉，以此基點，實現後再考慮擴展；
- 簡潔的界面和簡單的控制是受歡迎的，能儘快上手，是促使玩家儘快投入遊戲的關鍵；應反覆考慮:
- 鼠標點空地要做什麼操作，點敵人會有何反應，點不可達區域怎樣，點在物品、NPC上怎樣;
- 左鍵和右鍵點的區別，普通攻擊如何發出，魔法怎樣發出;
- 遊戲對玩家的操作會不會和玩家所想的有差異;
- 要增強玩家與遊戲交互的臨場感；避免人物走路打滑，角色與場景分離，攻擊敵人反饋不真實；
- 比如攻擊到強壯的敵人、攻擊被格擋時，使玩家角色受到震盪後退，並不能進行下一次攻擊。