一、工具链
底层架构解决方案与应用层
例子:
- 如何架构一个地图编辑器?
- 插件机制为什么是工具体系最核心的一个机制?
- 一个线性叙事性系统在工具体系怎么表达?
- 反射系统为什么是工具链里面做gameplay的重要基础?
- 协作式编辑的重要性?
- 如何处理不同类型游戏,gameplay,关卡组织规范的不同对于工具的挑战?
- 工具链体系设计的最大问题是解决不同思维方式的人员之间协同工作的问题,达到最终目标——所见即所得。
- 如果把工具直接包在引擎外面会带来什么挑战?
(一)世界编辑器
1.Editor Viewport
feature?no!
架构?yes!
为什么?因为针对不同工种都会有不同的feature需求,它们的底层逻辑有一部分的联系和差异,如果都包装成一个个feature的组合,那么整个体系会变得非常臃肿,且不利于重构与迭代。
注意:编辑器方式代码不能编译到正式游戏种,否则开放的这些函数接口和指针会被写外观的进行恶意调用。
Viewport也可能不仅一个。
2.万物皆可编辑原则
其实也就是OOP的思想。
3.大批量数据怎么管理
MVVM架构下的可扩展性和可维护性:
数据冻结 再最上层 view层进行设计 针对游戏策划和游戏美术对于场景的编辑的需求进行设计,抽象出不同类型的属性出来,并对应不同的viewpoint。
这里的问题来源于基于文件的源数据组织方式,如果将源数据按照文件类型的方式进行切分,在对源数据进行继承的时候,那么这个基础的数据该放到继承前的文件呢?还是继承后的文件里呢?
而基于源数据冻结(数据库方式),再对Content Browser进行区分,扩展性更强,其实这也是重载的思想。
4.操作方式
选取方式等交互细节也需要考虑操作者的工作流。
5.Terrain
- 高度图
以地形生成为例,在生成不同的高度图的时候,对于美术而言,往往会关注地形的变化以及一些模型的结构是否符合美感,而对于关卡策划而言,地形的生成更倾向于组件化的生成方式,更关注的是如何快速将layout转换为包装好的场景,以方便策划对于关卡结构的验证。 - 实例化笔刷
包含的就对象实例化的思想,对应于批量处理。 - 环境
天空盒,灯光,道路,河流
6.环境系统
程序设计原则——局部性原理
这里针对的问题很有意思,也是我一直迷惑的地方,这个思路解决的是美术工作流和关卡策划工作流之间的冲突的问题。
程序化生成内容是游戏工业化很重要的一个部分,可以大大降低资源生产的效率,但是这种随机化应该加以限制,这种限制就是Layout。具体做法明天再看!
待续: