底层架构解决方案与应用层
例子:
feature?no!
架构?yes!
为什么?因为针对不同工种都会有不同的feature需求,它们的底层逻辑有一部分的联系和差异,如果都包装成一个个feature的组合,那么整个体系会变得非常臃肿,且不利于重构与迭代。
注意:编辑器方式代码不能编译到正式游戏种,否则开放的这些函数接口和指针会被写外观的进行恶意调用。
Viewport也可能不仅一个。
其实也就是OOP的思想。
MVVM架构下的可扩展性和可维护性:
数据冻结 再最上层 view层进行设计 针对游戏策划和游戏美术对于场景的编辑的需求进行设计,抽象出不同类型的属性出来,并对应不同的viewpoint。
这里的问题来源于基于文件的源数据组织方式,如果将源数据按照文件类型的方式进行切分,在对源数据进行继承的时候,那么这个基础的数据该放到继承前的文件呢?还是继承后的文件里呢?
而基于源数据冻结(数据库方式),再对Content Browser进行区分,扩展性更强,其实这也是重载的思想。
选取方式等交互细节也需要考虑操作者的工作流。
程序设计原则——局部性原理
这里针对的问题很有意思,也是我一直迷惑的地方,这个思路解决的是美术工作流和关卡策划工作流之间的冲突的问题。
程序化生成内容是游戏工业化很重要的一个部分,可以大大降低资源生产的效率,但是这种随机化应该加以限制,这种限制就是Layout。具体做法明天再看!
下一篇:好像能造什么句子