| 這也是一篇類似提綱的東西，主要說明在寫策劃案的時候如何才能讓程式明白，或者說能讓程式更好的開展工作。 一、程式設計的瀑布模式
1、需求分析。程式本來就是代替現有的系統。確定程式實現的範圍，瞭解所有細節。
2、架構設計。遊戲設計中，大中型模式的架構工作量占程式工作量的20%~60%。
3、詳細設計。編碼。
4、測試。
5、維護。
6、前面步驟的修改，會造成後面步驟的返工。 二、策劃案的基本要求：
1、完整性：沒有不明確的地方。沒寫的功能可以不做。
2、一致性：不相互矛盾。
3、可行性：消耗不過大，當前技術能實現。
4、資源消耗：大量讀資料庫、一次性廣播大量訊息、使用過多圖片、工作量與增加的可玩性不成比例。 三、程式的對象
1、程式=資料+演算法。以對象為單位，將相關的資料和演算法放在一起。當前流行的設計方法。圖片與動作。
2、資料要求：細化到整數和字串。圖片和模型
(1)資料細化到整數(小數)和字串，明確整數的範圍 (位元組、短整、長整)，字串的寬度。
(2)服務端小數用定點小數表示(固定除以10000等)，用30000來區分加減和比例修改。
(3)百分比(千分比)的表示，時間的表示(日期、秒、毫秒)。
(4)複合欄位，data類。複用可減少表尺寸(對於靜態表無意義)，減少程式讀表的時間。
(5)ID。
(6)字串需要指定寬度。尾0要求內容=寬度-1。
(7)圖片的尺寸和格式。
(8)模型及其錨點。虛擬體定位、骨骼定位、頂點定位。各個模型間的組合關係(樹狀關係)。反例，兩個角色抬東西。
3、演算法要求：細化到公式。動作和動畫
(1)演算法具體到單個的數學公式。最大生命值=健康度*10。
(2)各個公式的前後順序，先用哪個，後用哪個。例子：武器和狀態都修正攻擊力，一個比例一個加減，誰先誰後。
(3)圖片運動的軌跡。例子：通常行走在格子裡。小鳥飛行軌跡。
(4)同時有幾部分做動作。拋出的物體。例子：火球、飛斧。
5、資料的分布特點： 三、概念(名)VS對象(一堆資料)
1、對象的內含項目關聯性是有限的。例子：把人裝入背包，
2、對象的組織通常是樹狀的。參考：程式二部論壇《信仰架構》
3、對象的組合。組合分為包含子物件和對象集。例子：CUser包含背包、裝備、擺攤，指標有召喚獸、誘惑獸、地圖。背包是物品的集。
4、對象的關係與參考關係。兩種參考模式：ID與指標。 四、架構的靈活性與速度。
1、需求變化，需要靈活性。機器限制需要速度。程式員需要平均兩者關係。
2、對象之間的各種複雜關係，造成了架構靈活性減小。例子：有許多個物件都會操作ITEM對象，所以一但ITEM的對外介面要進行修改，會造成所有使用ITEM對象的其它對象都要修改。修改量非常大，重新出錯的機率也會很大。例子：信仰的精靈
3、用指標加速。null 指標的危害。例子：玩家身上的地圖指標。
4、用位元組代替整數，合并欄位，開關量合并。節約記憶體。
5、不可能的分支可減少設計量和可讀性。例子：USER身上的MAP指標不可能為空白。
6、程式設計之後會被忘掉，重新修改需要許多重新回意的時間。因為少量細節的忘記造成錯誤的修改。太小的類會造成太多的關係。 五、樣本：擺攤 (一)關係
1、玩家：指標。架構問題：允許主人下線，指標可能為空白。
2、地圖：指標。架構問題：如果可以收合來切屏，比較麻煩。因為地圖指標可能為空白。
3、物品：ID。單獨刪除背包中物品，不會造成崩潰。 (二)屬性(資料)
1、攤位中的物品。包含ID、類型ID、價格。只是背包中物品的影子，並不把物品移過去。在擺攤對象中用ID或指標實現。因為程式中操作背包的代碼未封裝，所以許多地方直接刪除了背包的物品。所以這裡只能用ID而不能用指標。
2、玩家和地圖指標。
3、位置和吆喝。
4、收合狀態。 (三)演算法(操作)
1、ID產生。採用NPC的ID產生器代替。
2、對象的建立與初始化。需要主人的指標、主人的地圖、攤位的座標。自動放到地圖中。
3、顯示。下傳擺攤外形，同時下傳吆喝資訊。最佳化：吆喝是隨外形下傳，用戶端自己定時顯示。
4、添加物品，同時輸入價格。添加後需要廣播給周圍的玩家，因為有些玩家已經開啟攤位了。
5、刪除物品。從攤位上刪除後，需要廣播。
6、買東西。防作弊：同時上傳價格。物品轉移，存檔，記錄交易專用LOG，廣播文字訊息。
7、發送物品列表(開啟攤位)。同時要檢查背包中的物品是否還存在。
8、進入地圖。檢查座標點是否有其它東東。地圖對象中添加攤位的指標。廣播外形和吆喝。
9、離開地圖。廣播離開訊息。從地圖中刪除指標。 用戶端設計： 1、點擊一個空的攤位。
2、跑過去坐下。鎖定玩家的走動功能。
3、建立攤位對象。建立一個全域的攤位對象。地圖中顯示攤位元影像片。
4、增加收攤、擺攤、物品管理的按鈕。多態按鈕：顯示、隱藏、啟用、按下。
5、增加攤位介面。增加輸入價格介面。
6、增加別人的全域攤位對象。
7、增加其它玩家買東西時的確認介面。 四、遊戲資料分類
用戶端
即時資料：所有變化必須在0秒內看到。例如HP的變化。
非同步資料：資料在伺服器，用戶端等待伺服器返回資料。例如倉庫或公平交易等。
服務端
存檔資料
按產生方式
固定資料：由策劃製作的資料，在程式運行時不會改變。例如Cq_itemtype等。
玩家資料：由伺服器產生的存檔資料，玩家可能會隨時修改。例如Cq_item等。
可變資料：由策劃製作，但在遊戲運行中會被修改。例如幫派柱子等。
按載入方式
預先載入：在伺服器啟動時載入，通常和玩家無關。例如幫派資料等。固定資料通常是預先載入。
登入時載入：玩家上線時載入的資料。通常和玩家相關的都是此類型。
臨時載入：玩家需要資料時，才臨時從資料庫讀入。例如倉庫資料等。
記憶體資料：
臨時資料：在程式運行時產生的資料，不存到資料庫中。玩家下線，或者伺服器關機後，這些資料會消失。例如中毒狀態等。
存檔資料：從資料庫載入的，要存檔。
固定資料：從資料庫預先載入的，不存檔。
按計算方式分為：
原生資料：不能從其它資料計算出來。例如一個物品的數量、玩家等級等。
派生資料：根據其它資料，通過公式計算出來。例如背包中物品的總重量、幫派人數等。 |
