作者：NDark 时间﹔201001 沙漠商旅Ｃ的游戏设计(1)-简介与MenuEditor http://wp.me/pBAPd-aB 谈完了"容易被遗忘的游戏模组"之後 接下来说明的就是沙漠商旅Ｃ的专案内容。 简介 沙漠商旅Ｃ是移植自D-MAH的Flash游戏作品Caravaneer的Windows平台VC++专案。 沙漠商旅游戏连结：http://freegame.com.tw/flash/slg/slg_p_057.htm 作者官网：http://www.d-mah.com/ 自2008年年底，我开始进行此游戏的移植专案， 希望能藉着移植这个作品，来达到视窗游戏设计的自我训练与对於游戏层运作的探索。 专案最终完成度端看能继续投入到什麽程度为止， 是否达到100%并不十分重要，但希望能尽量完成原始游戏的设计范围。 选择沙漠商旅为目标的原因： 一。我不打算进行新的企划案的设计，沙漠商旅虽然是个小游戏， 但是游戏内充满各种元素，包含经营，战术，经济，角色扮演，剧情。 二。我不打算进行美术创作，因此不能空想一个新的游戏专案。 因此透过移植这个Flash游戏的过程来更了解游戏层的运作， 藉此了解一个视窗游戏游戏层的单纯架构与企划，美术之间的沟通流程。 因此在几篇文章中，我都不会提到这个游戏好不好玩，或是好玩在哪里。 因为我认为好不好玩是企划的工作，也是企划人员该有的担当，认知，以及被要求之处。 以一个程式设计人员来说，应该先完成的是快速实现企划的想法以及撰写模型来验证。 本专案仅进行学术研究及开发训练之用， Caravaneer游戏之所有素材及名称之权利为原作者D-MAH所有。 本专案之结果仅会作为本人经历及教学示范之用，不会进行贩售。 本人已去函徵求D-MAH之同意，但未获回音。 专案系统与特色（Project System & Features of Caravaneer C） . Windows CLR Form project . Visual Studio C++ 2005 . EZGL ( OpenGL on .net 2.0 ) . supported by Menu Manager（菜单管理器） and Menu Editor（菜单编辑器） . supported by Resource Pool（资源池） and Resource Editor（资源编辑器） . supported by Editors of all kind objects in Caravaneer C（各种物件编辑器） . using OpenGL windows font text drawing（画字系统） . using OpenGL select system（点选系统） . stage paragraphing & event-driven development（分段及事件触发开发流程） . save & load （可以存读档） . suported by Parameter Loader 时程 2008.09 进行核心类别开发 2008.12.28 开始进行版本控制及绘图平台设计 2009.02.25 进行Resource Pool的开发 2009.03.01 进行Story System的开发 2009.03.11 进行City Editor的开发 2009.03.17 进行Caravan Editor的开发 2009.03.24 进行Menu Editor的开发 2009.04.15 进行Resource Editor的开发 2009.05.09 进行Resource Editor与Menu Editor的整合 2009.05.11 进行城市选单的设计与实作 2009.05.16 进行城市购买选单的设计与实作 2009.06.18 进行关卡资源的释放与重读 2009.06.27 进行玩家与城市的摆放与简单移动 2009.07.09 进行Billboard的实作 2009.07.17 进行UID Updator的开发 2009.08 文件及游戏事件整理 2009.08.25 进行Individual Editor的开发 2009.09.07 进行Transporter Editor的开发 2009.09.18 进行Equipment Editor的开发 2009.10.02 进行Message Observer功能开发 2009.10.07 开始进行战斗系统开发 2009.12.03 战斗结束与战利品选单开发 2009.12.26 进行Cart Editor的开发 2010.01.03 进行文件的撰写 编辑器－Menu Editor Menu Editor（菜单编辑器）是沙漠商旅Ｃ专案中一个相当重要的开发重点。 起源於当年我在口古月游戏制作小组的时候就有的构想。 但是当年碍於人力与优先度并没机会完成。 主要目的是 建立一个图形化介面使得企划与美术人员可以自行设计游戏中的菜单（选单）。 不用把构想写在纸上，再由程式人员设定进程式里面。 减少管理与开发上的流程协调与冲突。 企划与美术人员可以自行调整选单的位置与其他参数，存成一个选单档。 程式开始时选单档读入後自动建立选单。 系统与特色 主要由菜单管理器（Menu Manager）来管理整个菜单系统， 菜单管理器内有选单（Menu State）阵列，而阵列内又有各类菜单物件 目前的版本菜单种类有图片，文字，与区域。 菜单物件资料有位置，颜色，大小，是否要画，识别编号，贴图关键字等属性。 区域菜单预定为是一个看不见的方块，是为了点选机制而设计的。 菜单物件资料中的识别编号是为了点选机制而设计的。 菜单系统目前还不支援2D Sprite等特效。 选单之间利用一个FSM-like的机制纪录选单的转换。 选单档目前是用文字模式来纪录，开发维护方便。 沙漠商旅Ｃ也透过菜单管理器来读入选单档。 由於是一个档案，所以读入後要怎麽作其实是看平台要怎麽处理。 不会受到菜单编辑器的限制。 菜单物件的编辑支援新增移除，拖曳移动，角落缩放，复制贴上，上一步。 编辑器会定期存暂存档避免程式当机。 内容 游戏的平面选单一向是开发上重要性不高的部分。 但是因为每个游戏其实都有平面选单的设计，因此其实选单开发流程化是被过分低估的。 这个菜单编辑器的开发期其实相当长，多半是实务上需要什麽就开发那个功能。 原本是想开发一个像是视窗程式设计可以用滑鼠拉来拉去的设计。 编辑器负责指定一些常见的参数，然後把这些资讯存档起来。游戏开始时读入。 这样企划人员及美术人员修改选单的设计的时候，就不用去麻烦程式人员作调整， 或是面对一个十分不容易了解的参数文字档。 比较设计不良的地方有几个地方： 分别是UnDo与ReDO并没有建立； 编辑器只能纪录移动或是缩放的上一步； 而且编辑器尚不知道目前的物体是否与上一步的相同。 程式流程在绘图的时候概念很简单，把每一个开启的选单中的物件都画出来即可。 请注意，选单管理器只提供资料，真正执行的时候是看系统怎麽处理这些资料。 如果是图片物件就依照指定的贴图标签画方块。 如果是文字物件就依照指定的内容来画字。 区域物件比较特别，有点像一个透明的板子，游戏的绘图模式不画它。 但是当要检查滑鼠点选的时候就要画出来（让滑鼠可以点到这个板子）。 因此实际使用的时候就是把选单档案读进来 gsMenuManager.ReadFile( ... ) ; 绘图的时候 for( i = 0 ; i < gsMenuManager.m_vMenuState.size() ; i++ ) if( true == gsMenuManager.m_vMenuState[ i ].Active() ) { ... 画Image ... 画Text ... 画Region（Select模式下） ... } 要取用选单物件,有很多方法. 我大部分是透过每个选单及物件都给一个辨别名称Rich Name. pState = gsMenuManager.GetStateByName( ... ) 然後再找该选单内的图片或文字 pImage = pState->FindImageByName( ... ) 文字物件比较特别的是存了字体大小与对齐等属性，提供给系统使用。 有关贴图关键字与贴图标签的指定会在资源编辑器的时候会一并说明。 选单间的转换是为了选单的开启／关闭／切换而设计的 FSM-like的设计纪录了选单中某一个物件（被按到後） 会否开启／关闭／切换其他选单的资讯。 这个FSM包含了物件来源标签以及他可能的对象及动作（开启／关闭／切换）。 譬如说 State i的Image a按下之後会关闭State i开启State j , k 这个FSM Link会纪录 active[ 0 ] = j active[ 1 ] = k deactive[ 0 ] = i （因为同时间可以开启多个选单，因此这不是一个标准的FSM。） 所谓2D Sprite我没有特别进行开发的原因是， 这个特色几乎是每个游戏引擎都已经内建的功能。 可以读图的游戏引擎都应该对Sprite进行设计。 -- "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 (02/26 18:22) ※ 编辑: NDark 来自: 140.96.77.176 (02/26 18:23)