首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Cesium与游戏引擎

    今天看了《百度终于也入了Cesium的坑》这篇文章,里面有关Cesium的评价,让我的阅读体验极度不悦,比如“但是无论从整个产品的成熟度以及可视化效果上来说,Cesium现阶段已经不能算是第一梯队的选择了,起码在可视化方向上。”,“整体上来说游戏引擎的效果和整个技术生态基本上可以吊打现在的Cesium,就是对于GISer来说上手门槛有点高。”,“所以现阶段,无论从哪个角度来看Cesium都不是一个值得长期投入的技术路线”。作者从自身的角度,比如产品,市场需求等方面,确实反映了Cesium产品的一些问题,但从技术角度,基于我自身的理解,无法认同这些观点。所以,也在此发表一下个人的意见,不对和不妥处请指正。

    09

    UE5的Control Flows

    在Gameplay开发过程中,常常会碰到一些流程非常复杂,由很多个子逻辑复合而成的业务,就比如最常见的客户端登录流程,可能要分这几步:要先走账号授权,访问平台SDK的API,等待回调取得对应token,再和游戏服务器建立连接,连接后将获取到的用户id和token发给游戏服务器,等待服务器校验成功后返回给客户端才算成功登录。中间会有好几个子步骤,每个步骤都可能是异步的回调。虽然流程看起来很线性,但当我们在实现时,会发现事情没这么简单。每一步都需要根据上一步的结果来决定下一步怎么做,过程中连接失败了怎么办,鉴权失败了怎么办,超时了怎么办?中间有非常多的异常逻辑要处理,最终的业务看似线性但实际是一个网。而且整个过程可能会因为策划需求变更,平台SDK更新,服务器重构等各种原因进行多次变更,每次修改流程,就要把业务的这张“网”重新编织一遍,“网”上的某个链路出现问题,就会导致整个系统出现瘫痪,无穷无尽的开发工作量就是这样出现的。经验丰富的开发者在写这些业务时,可能会考虑使用状态机,把这张网梳理成多个状态,在重构时只要调整状态机之间的关系即可,但业务在不符合状态机的运行模式时,强行套用可能会让业务变得更加抽象,当业务规模庞大时不但不能减轻业务开发人员的重构负担,反而会加重理解成本。

    06
    领券