从我开始研究ECS算起, 到现在已经将近20天了。

第一版ECS库终于实现完成了。先不论性能如何，基本功能都实现了。

在我的理解中，ECS中最复杂的地方是EC部分的管理和查询。而S部分的复杂度主要是依赖关系的问题，这会取决于具体的项目。

因此，在这个ECS库中主要解决EC的问题，关于S的部分并没有提供。这也是我称它为库而不是框架的原因。

在整个实现过程中，由于我还没能完全克服性能强迫症，导致我的心路历程非常坎坷（每次实现到一半，总会因为这样或那样的原因，让我推倒重来）。

最开始，我认为守望先锋的ECS之所以那么复杂，是因为他们使用了C++这种强类型语言。为了解决动态组合（动态添加和删除C）的问题，不得不在API上做出一些让步。

如果拿Lua来实现，语言本身就支持动态组合，那添加/删除Component的行为，可以退化为添加/删除“标签”功能。

每个System只需要过滤出含有特定“标签”组的Entity, 然后加以处理就行了。

很快我放弃了这一想法，主要原因是我认为作为一个合格的框架或库，它应该提供一些限制。可以让我们写出符合ECS原则，更易读的代码。

在上面的设计中，客户程序员很容易就违反了ECS原则，他完全可以只过滤某一个ComponentA, 然后去修改这个Entity中的ComponentB, 甚至删掉ComponentB但是并不会删除ComponentB的标签。这会导致一些很奇怪的Bug。而且从代码的易读性上来讲也没有好处。

在后续的设计中，我又陆续纠结了，Eid的分配问题， Component的存储问题，同一个Entity中的Component的关联问题。

在经过陆陆续续几次推倒重来之后，直到今天才实现完第一个版本。

在这不断的推倒重来中，我总是在是否“需要暴露Eid给客户程序”之间摇摆不定。最终，我认为是需要的。

我们总是需要在程序的某处去New出一个个的Entity。同样我们也总会需要在程序的某处，去修改某个特定Entity的某个Component数据。

在我看来，整个ECS的运行机制很像一个巨大的“粉碎机”。 我们总是在某一个入口投入足量的Entity, 然后ECS库或框架将这些Entity粉碎成各种Component，供System查询并操作。

因此在这一版的ECS库的实现中，我把Component作为主角来实现的。Entity的作用在这里，将一组Component进行关联，以方便Component查询和生命周期的管理。

先简单介绍一下API：

--创建一个名为Admin的world对象。使用相同名字多次调用ECS.fetch_world, 返回的是同一个world对象
local world = ECS.fetch_world("Admin")

--注册Component类型。 其中world.register的第二个参数是为了方便建立Component缓存池和Debug阶段检查一些Component的合法性（暂时还没有实现）。
world:register("vector2", {x = 0, y = 0})
world:register("vector3", {x = 0, y = 0, z = 0})

--创建一个Entity, 这个Entity只含有一个"vector2"的Component
local eid = world:new { vector2 = {x = 2, y = 2}}

--向eid所代表的Entity上添加一个"vector3"的Component
world:add(eid, "vector3", {x = 3, y = 3, z = 3})

--向eid所代表的Entity上删除一个"vector3"的Component
world:remove(eid, "vector3")

--查询world中的所有类型为"vector2"的Component
for v2 in world:match("all", "vector2") do
    w:touch(v2) --将Component v2置为脏标记
end

--查询world中所有被w:touch过的类型为"vector2"的Component
for v2 in world:match("dirty", "vector2") do
end

--查询world中所有已经死亡的类型为"vector2"的Component
for v2 in world:match("dead", "vector2") do

end

--删除Entity
world:del(eid)

--执行清理操作，每调一次为一个逻辑帧
world:update()

整个设计大概是这样的：

每个Component类型都有一个数字id称为tid。每个Component实例都有一个数字id称为cid。我们总是可以根据tid和cid来找到某一个具体的Component实例。

在相同的Component类型中，新创建的Component的cid总是比旧的Component的cid要大。在world:update时所有Component的cid会进行重排，但是依然满足这一约束。这会提供一个便利，在我们使用for遍历world:match时，依然可以不受限制的添加任何Compoent实例。

当某个Component实例被删除时，仅将其挂在“dead”链表上，并不做其他操作。如果已经在“dead”链表上，则不做任何处理。这会产生一个限制，刚对某个Entity删除了一个Component之后,不可以立马添加一个同类型的Component。

当某个Component实例被touch时，仅将其挂在“dirty”链表上。

当某个Entity被删除时，将此Entity下的所有Component标记为"dead", 然后将Entity挂在"dead"链表，不做任何处理。

在执行world:update时会产生以下行为：

1. 释放所有的Entity及其eid（以备后面复用)
2. 释放所有标记为“dead"的Component, 并整理存活的Component的cid
3. 清除"dead"链表
4. 清除"dirty"链表

总的来讲，所有的添加都是立即生效，所有的释放都会延迟到world:update中执行。

ps. 在这次纠结的过程中，在一定程度上治愈了我的性能强迫症。