ECS架构笔记

本文探讨了ECS(实体-组件-系统)架构在3D引擎中的应用,指出其相比传统渲染树的优势。作者分享了从传统架构转向ECS的经验,并强调ECS的组合优于继承原则,以及在UI设计中的局限性。ECS中的Entity作为纯粹的存在,Component和System负责功能实现,体现了单一职责和面向切面编程思想。虽然ECS在隔离性上有优势,但数据汇总和通信可能会变得复杂,需要权衡设计选择。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

ECS的介绍 云风写的非常好: https://blog.codingnow.com/2017/06/overwatch_ecs.html#more

ECS不是银弹,但在3D引擎领域是一个比较合适的框架, 目前的大多数现代3D引擎,或多或少都采用这种设计思想,比如Unity, UnReal。当然后面应该会有更为先进的框架出现。

在这近一年的工作中,我基本经历了从传统渲染树到ECS架构的变化,感受到ECS在这个领域的相对先进性,记录一下。就自己之前做Android的经历,很多人只能接触到MVC/MVP/MVVM(因为它们够简单直白),架构思想被限制在一个界限内。ECS是不适合UI层设计的,但是它提供了一种新的视角和理念。

  1. ECS是一个典型设计思想的体现: 组合大于继承,Entity在这个体系里完全被剥离成一个最纯粹的锚点,他的属性只有一个:存在性。所有的功能都由Component和System协同来完成。Entity只提供了Component锚定和组织作用(组织作用其实也被极度弱化,可以理解为一个最简单直白的集合)。Component和System可以自由靠挂,扩展性很强。
  2. System和Component体现了单一职责的设计理念: 每种类型的System和对应的Component高度契合,两者结合在一起实现了某一类的特定功能(当然,一对一的关系不是绝对的,某些Component可能和会复数的System交互,这是合理的,Component是数据,而数据是中性的)。
  3. System和Component的协同关系某种意义上不是OOP,而是AOP。System是无状态的功能切片,而Component则作为
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值