作者NDark (溺於黑暗)
看板GameDesign
标题[心得] 沙漠商旅C的游戏设计(6)
时间Thu Mar 25 18:38:44 2010
作者: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)