[心得] 沙漠商旅C的遊戲設計(6)

看板GameDesign (遊戲設計)作者 (溺於黑暗)時間15年前 (2010/03/25 18:38), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串1/1
作者:NDark 時間:201001 沙漠商旅C的遊戲設計(6)-其他與結語 http://wp.me/pBAPd-bE 底層的其他元件:方程式,遊戲字串處理,基本物件,存讀檔架構(含參數讀檔模組), 訊息傳遞架構(觀察者模式)。 方程式 方程式,也就是多少數值變成多少影響這種關係式。理當是企劃人員該設計的內容。 但礙於程式實際上是由程式設計人員掌控, 因此常常會發生企劃人員想要修改變動設計, 必須三跪久叩才請得動很忙正在火燒屁股的程式設計師來修改, 最慘的事情是當修改完畢之後,卻發現這個修正是有問題的, 造成程式或遊戲的錯誤結果。 因此如何建立一個企劃可反應可獨立操作的遊戲工廠一直是我的思考主軸。 至少,這些程式設計的部分,必須要獨立及透明,結構簡單到普通人也看得懂。 因此目前沙漠商旅C的方程式是一個簡易的全域底層函式集。 每個函式盡量作到只用基本的型態傳入,並用基本的型態回傳結果。 譬如 gCalWealthByBusiness-依照商業停工數計算城市住民的財富 就是由兩個整數參數傳入後計算一個整數結果。 gGenStrFromPhy-依照身體素質來計算成員的力量參數 則是傳入目前經驗值,目前力量,目前身體素質,以及亂數範圍及升級與否 來計算結果-結果力量。 這些函數必須將其簡單化, 提供程式設計師與企劃人員能夠將程式碼對照企劃的文件。 避免衝突與降低維護的難易度。 遊戲字串處理 遊戲中會有很多字串要處理, 這邊所說的字串指的是"棉花"與enum型態CCG_TYPE_COTTON的轉換。 因為我們在開發的過程中不能老抱著一個對應參數的表格在溝通, 因此人性化可閱讀的開發文件是很重要的。 但是到了程式中儲存時總要將他轉換為0123的整數。 因此這兩者之間的轉換就如同方程式一樣定義在一個底層全域函式集中。 除此之外,沙漠商旅的字串處理還負責產生一些遊戲中會用到固定格式的字串。 存讀檔架構 在說明沙漠商旅C的存讀檔架構之前要先說明兩種常見的存檔方法 一種是把存檔資料放在一個檔案裡面, 然後利用檔案內部的標籤來區隔檔案的區塊, 讀檔之後再將該些區塊指定給需要的物件。 好處是檔案管理方便,整合檔案可以進行壓縮編碼,避免資料被使用者改動。 壞處就是因為檔案都整合在一起,因此如果半途要特定的資料要從頭開始讀到該位置。 第二種方法是各物件各自管理各的檔案, 然後透過檔案內的一些機制把檔案內容指定到正確的物件上。 好處是檔案比較明確,開發時維護容易。 壞處是讀檔機制設計不易,增加開發風險。 我現在是採用第二種。但是如果未來有機會的話我是不排斥修正到第一種的架構。 沙漠商旅C是由讀檔清單開始的-系統物件中的玩家檔清單。 每個玩家檔中紀錄著玩家檔檔名,以及其他資訊。(如存檔次數,存檔時間) 當沙漠商旅C存檔時,除了會儲存各玩家檔之外,還會存一份清單檔。 因此相反地讀檔時就是依照順序 先讀清單檔:知道有幾個玩家檔,以及玩家檔內部資料。 再依照清單內容去讀玩家檔檔案,玩家檔檔案目前包含兩個字串, 分別是場景中商旅的清單檔案路徑, 場景中城市的清單檔案路徑。 商旅的清單中又分別有各商旅檔案的路徑,再分別把各商旅的資料讀入。 城市清單中分別有各城市檔案的路徑,再分別讀入各城市資料。 因此你會發現第二種架構檔案間的索引很複雜,但是單一個檔案的內容卻是很單純的。 讀入商旅資料後,系統會依照商旅資料內的成員名稱及路徑去讀入人員資料檔案。 然後依照裝備,動物,貨物的名稱自各原型清單中取得正確的物件放置在商旅物件中。 至此檔案讀入完畢。 參數讀檔模組 Parameter Loader(簡稱ParamLoader),其實是個陽春版的XMLParser。 我在還不知道XML的時候就因為自己要存讀一些參數方便 自己就開發了ParamLoader這個類別工具。 因此當我從別的地方了解到XMLParser的時候就有點懶得在拉進來。 雖然ParamLoader很陽春,但是如果不要太複雜的功能的話,是簡單又方便就是。 ParamLoader主要的功能是設定要讀取的參數(Item)關鍵字,然後將內容讀進來。 譬如說參數檔裡面有"Reload AP Cost : [ 3 ]"這段文字, 程式裡面在讀檔之前就先新增好"Reload AP Cost"這個關鍵字, 讀檔完畢就知道參數檔裡面有沒有讀到這個參數。 這個讀檔器的優點是在於它的彈性。 程式設計師不用去判斷目前檔案讀到哪裡這層的細節。 而是只需要決定關鍵字,然後最後把內容取回來即可。 ParamLoader的功能與特色 一個參數由關鍵字與內容物組成。 可設定檔頭檔尾,避免讀錯檔案,以及檔尾之後直接略過。 關鍵字不限一個單字,一串句子也可以, 但是關鍵字不可為其他參數的關鍵字的子集。避免混淆。 內容物可自由設定各種前後區塊標籤。 單一參數可以包含一連串複數個內容物。稱之為"多重內容"。 內容物讀入的時候是字串,要取用的時候才轉換為設計人員需要的變數型態。 但是這裡防呆還沒做好,因此設計人員請不要故意取用錯誤的變數型態。 除了多重內容之外,還可以有多行相同關鍵字的參數,稱之為"多重相同" 取值的變數型態包含string , int , double , bool。 沙漠商旅C的存讀檔大概60%都是使用ParamLoader。 其他多半是結構更簡單重複性的清單字串檔案。 訊息傳遞架構(觀察者模式) 設計模式這本書我是到了2009年末才因為有人推薦才去買入閱讀。 而剛好沙漠商旅中有一個訊息更新的模組需要完成,我就簡單照抄了一個觀察者模式。 觀察者模式的精隨在於: 攜帶(產生,發送)訊息的物件並不去更新收集訊息的物件的內容, 而是請(通知)收集者來拿資訊。請完之後舊的資訊就可以清除。達到散布的結果。 當真正要更新訊息到選單中的時候,收集者早就把訊息收集好了。 也就不用再多花時間去找誰有發出訊息。 因此沙漠商旅C中遊戲系統內部的物件(如商旅)就扮演著攜帶者的角色, 而選單中就有一個負責扮演收集者的物件。 物件建立之後,遊戲系統會將收集者註冊到內部各個攜帶者的資料中, 讓攜帶者可以通知收集者。 因此當遊戲進行過程,攜帶者出了什麼狀況,就會製造訊息,然後通知收集者來取得。 要更新選單時,收集者就從訊息串列中彈出一個來更新。 至此訊息傳遞架構說明完畢。沙漠商旅C也就說明完畢。 沙漠商旅C未完成的系統 包含 城市的商業系統及新聞系統。 板車與動物拖拉系統。 編輯器群的整合,把同質性的編輯器整合。 檔案處理的整合,以及合流到一個資料流上的機制,資料壓縮系統。 有幾種固定的攝影機模式,可以撰寫在一起呼叫,避免分開維護。 非玩家商旅產生時會依照等級決定人員及對應武器,裝備,貨物。 一般商旅的AI,會在城市中補足貨物,判斷買賣貨物的利潤,買進貨物,賣出貨物。 強盜商旅的AI,會攜帶較多的武器,主動襲擊玩家或其他商旅。 戰場AI,會判斷與玩家之間的距離及手中的武器來決定移動,攻擊,切換武器等。 瞄準系統根據人物資料來調整瞄準難度。 後記 說明部分到此為止,抱歉歹戲拖棚這麼久. 之後視我工作的狀況會有一些source code以appendix的方式釋出(但不是整個專案). 這些想法及那些程式碼希望對一些入門的朋友都有幫助. -- "May the Balance be with U"(願平衡與你同在) 視窗介面遊戲設計教學( http://0rz.tw/V28It ),討論,分享。歡迎來信。 視窗程式設計(Windows CLR Form)遊戲架構設計(Game Application Framework) 遊戲工具設計(Game App. Tool Design ) 電腦圖學架構及研究(Computer Graphics)論文代讀(含投影片製作) -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.96.77.176 ※ 編輯: NDark 來自: 140.96.77.176 (03/25 18:39) ※ 編輯: NDark 來自: 140.96.77.176 (03/26 11:32)
文章代碼(AID): #1Bgpqt26 (GameDesign)
文章代碼(AID): #1Bgpqt26 (GameDesign)