觀點：關於遊戲系統的規劃、設計與實現。 (轉)

觀點：關於遊戲系統的規劃、設計與實現。 (轉)[@more@]

 

觀點：關於遊戲的規劃、設計與實現。

1.遊戲的畫面形式大都是直接寫屏的。它的最大好處就是平臺無關性，而不用考慮紛繁複雜的window介面規範，不用考慮很多與介面相關的或者mfc。瞥開這些無謂的平臺特性，設計者可以非常自由的架構遊戲介面系統以及表現形式。如果用目前主流的OOD設計的話，體驗後的設計者的設計水平可以有非常大的提高。因此遊戲系統設計非常合適做學習軟體設計的案例。

2.如果想找一系列來概括遊戲系統設計體系來形成獨特的工程規律，其實是不必要的。從軟體系統的角度去觀察，遊戲軟體系統和普通的應用軟體一樣，它的核心就是資料，這個資料描述了一個狀態，這就是整個軟體系統的當前狀態。遊戲在執行發展，應用軟體也在被控制，這些現象的實質就是系統狀態的發展與----資料在變化與更新。是什麼觸發了狀態(資料)的變化呢，是獨特的軟體規律，也就是說每個軟體都有不同的系統狀態更新規律(例如輸入，事件觸發，系統行為或是狀態發展)，而這就是所謂的系統規律。每個應用軟體都有自己的系統規律，而每個遊戲軟體也都有自己的系統規律，而這就是軟體系統設計的依據，它需要被抽象、被規劃、被封裝。因此完全可以把遊戲軟體系統與別的其他的軟體系統同等看待，他們是一樣簡單的、或是複雜的。 ^_^
補充一點：其實遊戲系統很多之處都可以歸納出統一原理，例如精靈管理，地圖管理等等。我認為這些都是區域性設計與演算法，還未到系統規律的高度。

3.關於架構軟體系統，特別是以面向的方式。

我就簡單說說我的一些心得吧：

#.事先儘量將軟體需求做得詳細、完備。

#.先從全域性上規劃整個系統。特別要考慮需求的變數以及系統的重用性、擴充套件性。

#.接著構造系統的模組，劃分模組的功能及分佈。注意將相對穩定的系統狀態與系統 規律及系統變化分離，抽象出變化與聯絡將以封裝，使得系統某個方面的變化可以獨立與其他方面。MVC(model/view/control)方式是一個簡單而典型的例子，3者能獨立發展且重用。再針對你上邊的例子，怪物的外觀動作和怪物間的行為，前者描述了物件的外觀，後者可能描述了物件間的互動—這裡可能會存在變數。如果將怪物間的互動動作(例如“咬”)分離出來(可以構造一個識別Pacman類的PacmanAction類)，讓其與怪物本身外觀行為得以獨立發展，相信系統的變化就會靈活許多，譬如你可以填加各種行為例如Talk，Kiss或是FakeDead ^_^ 等等而不必再大肆修改Pacman類或類層次，讓這些動作與怪物自身的外觀行為進行自由組合，相信其樂無窮。抽象變化將其封裝就是這個意思。

#.有了模組圖後，再將其細化為類圖，這時類的繼承系統以及類之間的通訊關係一定非常明晰，經過一番精巧的區域性構造後，相信當前的系統就會非常合理、優雅且充滿能量。

#.接著……大概就是快樂或痛苦地編碼了吧，反正是體力活兒~~ 好處是同時你還可以一邊和mm。*_*

#.接著就是痛苦的了L，不過相信有了構造合理的系統，一切行為與變化都顯得非常清晰可以全盤控制，同時你還可以一邊和多個mm聊天。: J

篇幅所限，有些觀點說的比較抽象，希望大家得以指正。%_#