zoukankan      html  css  js  c++  java
  • ECS杂想

    昨晚敲代码时突然想到,为什么ECS架构能降低复杂度
     
    比如之前老出问题的死亡流程:
    、战斗系统的Loop里,扣血空了
    调Death接口
    、调统计计算
    、外部注册的战斗结束回调
    很可能Death的逻辑流牵扯很远,同“外部战斗回调”互斥了
    代码层级很难察觉到这类冲突
     
    为什么会有这种互斥呢?怎么发生的?
    常见的一种:Death中清理了某些数据,战斗结束回调的逻辑流里仍持有该数据的引用
    想想看,这一系列的动作(死亡、统计、各种回调)实际上发生在一条逻辑流中,互相间极易穿插
    PS:顺序式编程的思路下,逻辑流从搜集数据那就开始了,因为后续调用不会重新搜集那份数据(ECS最大的优点了吧),而这份数据的“中途更新”……没有很好的方式捕获到
     
    同一条逻辑流之中,我要主动去找寻“本次修改影响到的点”,依赖程序员对整体业务的熟悉度、细心度
    一旦没有找全受影响点……~囧
     
    ECS将这条逻辑流拆分了
    比如战斗扣血空了,就只是血量空了,不在本处调用Death逻辑,交给“Death System”处理
    这样战斗就是一条独立完整的逻辑流了,等它完毕后,再跑“Death System”的逻辑
    新的逻辑流起始于“遍历检查空血对象”
    ……
    每条逻辑流起始,均会重新搜集所需数据,接下来只跑本逻辑相关的一小部分,“修改影响点”不仅少了,且集中了

     

  • 相关阅读:
    Android学习路径(两)项目文件本身使用场景和文件演示
    A左右ndroid正在使用Uri监视数据库中的更改
    离PACKET_INp获取信息acket data
    curl 命令
    POJ 3177 Redundant Paths POJ 3352 Road Construction(双连接)
    Linux 下一个 Mysql error 2002 错误解决
    图片打水印 缩放 和一个输入流的转换
    qt Qt5开发
    qt 关于Qt中MVC的介绍与使用
    qt mvc3
  • 原文地址:https://www.cnblogs.com/3workman/p/7160350.html
Copyright © 2011-2022 走看看