场景编辑器开发第五天，设计架构重回flash，很多问题不是出在技术上而是策划上

经过昨天第四天的努力研发基本上把绘画功能搞定了，接下来就是对于场景编辑器操作部分的配置，为此我已经把大体架构设计写好了，本身准备今天就开工的，没想到决策又有了变化，不过我还是先把架构设计放出来吧~

1.首先有一个容器存放所有要放进来的显示对象。
2.单独有一个组作为操作器ui的层。
3.选择框功能，用鼠标拖动出一个区域，场景也是活动的，可以拖动，按下-move-抬起，确定一个拖动区域，这个区域算法计算覆盖。
4.每个显示对象都有活动状态和非活动状态，处于活动状态则可以对活动状态的显示对象进行各种操作。
5.活动状态移动，每个活动状态的每一个对象都有按下事件和抬起事件，移动的话就是移动位置，确定移动的量。

功能0：整体拷贝，取消原选择物品，创建副本，选择副本内容
功能1：整体还原变形
功能2：指定变量固定修改，输入改变量
功能3：指定变量随机修改，输入随机范围
功能4：依赖功能2,3，随机属性生成。

功能：依赖功能2,整体固定移动指定量
功能：依赖功能3,整体随机移动指定量

功能：依赖功能2,整体固定旋转指定量
功能：依赖功能3,整体随机旋转指定量

功能：依赖功能2,整体固定缩放指定量
功能：依赖功能3,整体随机缩放指定量
 

实际上一个场景编辑器系统对于目前在研发的兔宝世界来说冲突还是挺多的，玩法设计没办法适应当前的整体玩法设计，其中就包括了玩家恶意创造那种直接采集物资的场景，然后获取物资，这样最终导致游戏的平衡破坏，而避免这种情况的解决方法就是对玩家创作进行限制，但是限制了又就难以实现场景编辑器本身应有的创意设计，大量的为了平衡而设定的限制不管是对玩家还是对游戏平衡来说都不好，做下来都是一个挑战，曾经的想象太美好了，看上去没什么问题，感觉没问题就开工做了，没想到细致思考后问题会这么多，所以场景编辑器从对玩家开放回到仅对自己研发开放，作为内部工具实现，所以又大调矛头，放弃了在egret引擎上搭建的想法，改为继续在flash pro上开发，并且尽量降低成本，其中的目的无非就是为了，提高其他系统重要性而做出的边缘化决定，所以前面的努力都白做了，不过也不完全白做，毕竟有一个大的绘画模块完成了，以后可以无限利用，比如做画板呀，做一些特有的各种各样的融合进画板绘画的玩法也是很棒的。

参考我的世界游戏设计，我的世界是沙盒游戏，而兔宝世界是一个休闲养成游戏，我的世界开放了公开去开启服务器功能，而兔宝世界开放这种功能则会导致游戏裂开，因为太多关于这套系统整合物品等等内容的工具了，而我的世界则并没有这样的影响。

创作是工程师的事情，决策是老板的事情，但是决策往往比做一个项目难的多，可能大多数老板也是今天一个想法明天一个想法，后天又改一个想法，曾经合作的甲方，开始合作的时候说的是一种需求，做到最后变成另一种东西，这当然是一点点的去改出来的，所以就是这样哦。

 

我来继续说一下后续的研发架构实现吧，首先我要做的事情就是在flash中建立多个类，这些类是基础的类型，对应了20种un系统基础模块，然后具体物品是派生这些类实现的，派生类创建物品，然后全部依赖flash的类导出功能，直接放到flash pro中进行编辑，编辑完以后直接通过as代码写的算法导出场景配置表这些。这就是后续的实现逻辑了，这样简单也可以做成一个场景编辑系统，只不过，过度依赖flash技术。

场景编辑器开发，从选择flash到放弃flash又到重新拾起flash，整个过程充满戏剧性，太有趣了，那么今天就是这样了，而且我想吐槽一下actionscript3.0的面向对象重写方法真难受。