


DCC: 这个就在ACP这一层。

工具链就是调和不同层次的人的关系,不同使用者的习惯。




拓展性不好!
大部分人用的这个模式。


MVC:1987
数据之间的逻辑,
把数据流清晰化了,底层的model单向的到view,不能从view 到model。model的修改只能通过controller来做。将View和model分离开的架构。

所有的复杂度放到了Presenter,这个得听懂view的语言,有得听懂model的语言。

目前更推荐这个模式。
View不需要写逻辑,不需要知道别人的东西。
viewmodel需要程序员去写,
model和view彻底分离开来了。


缺点:对环境的要求高,而且不好维护。

序列化:把数据变成可以传递的二进制块。
反序列化:变成内存中可以处理的数据。
是network非常重要的一块。


text,容易懂,都可以打开。
.obj格式

XML:容器,废话太多。
Json:处理快,piccolo就是用的Json格式。

二进制是最快的,小很多。

资产引用:
所有的文件都关联在了一起。




数据可以 继承。


解析:



高位存在哪里,前面还是后面。

向下兼容。版本的兼容,非常重要的。



建议 的做法:
大量的模块维护,数据格式有上百种,如何保证工具的鲁棒。

如下两个问题: undo$redo和崩溃的时候数据的保存。


这个结构要早点做进去。后面加就会很麻烦。


UID是逐渐累积的,保证顺序





找出共性。



需要继承关系:像高级语言一样。

数据引用

两种方式:
一种是用xml,json等直接定义个shema。
另外一种是:定义了个c++类,

第一种方式非常好理解, 把数据实现和工程彻底剥离开了。但是她需要代码的生成器。
但是版本不兼容。
第二种方式:可以直接将方法包进去,不会出现版本不兼容。

一种是磁盘上的,
一种是运行中的,内存中是二进制的。
一种是给用户使用的。



在代码中是基于弧度的。工具中要让用户理解。




独立的工具:

游戏中的工具:



非常简单,edit数据和游戏的数据会混合。










软件架构