ArtemisD: A D port of Artemis Entity System Framework for games.

Kiith-Sa kiithsacmp at gmail.com
Tue Oct 8 03:35:52 PDT 2013


On Tuesday, 8 October 2013 at 05:24:13 UTC, Elvis Zhou wrote:
> On Monday, 7 October 2013 at 17:06:40 UTC, Kiith-Sa wrote:
>> On Monday, 7 October 2013 at 15:21:00 UTC, Elvis Zhou wrote:
>>> On Monday, 7 October 2013 at 14:19:20 UTC, Ali Çehreli wrote:
>>>> On 10/07/2013 02:18 AM, Elvis Zhou wrote:
>>>>
>>>>> ArtemisD:
>>>>> https://github.com/elvisxzhou/artemisd
>>>>
>>>> Just a little note: As it's more readable, you may want to 
>>>> use 1000.msecs instead of dur!("msecs")(1000) in the example 
>>>> program. 1000.msecs is the equivalent of the msecs(1000) 
>>>> function call, which returns dur!("msecs")(1000).
>>>>
>>>> Ali
>>>
>>> Done, thank you!
>>
>> I'm implementing pretty much the same thing in my project, 
>> although I'm probably
>> more in line with the original blog post (e.g. every system 
>> can only access
>> specific components of an entity, which are statically 
>> determined, entities are more lightweight, etc.). I'm using 
>> much less OOP and more of a generic/metaprogramming approach. 
>> Currently I'm trying to rewrite the code to add a concept of 
>> "past" and "future" state; a System processes past Components 
>> and outputs a future Component, past Components are const, and 
>> no two systems may write to the same future Component. This 
>> should allow very simple threading
>> with little synchronization.
>>
>> I'll look at your code if there are interesting ideas.
>>
>> The previous version of my entity system is used in my ICE 
>> game:
>>
>> https://github.com/kiith-sa/ICE
>>
>> It's quite messy, though; which is why I'm rewriting it.
>> The new version doesn't even compile at the moment, I'm 
>> working on it slowly as I'm studying and working at the same 
>> time right now.
>>
>> I'll look over the comment and post if I have any further 
>> feedback. The only thing I can say right now is that there is 
>> inconsistent tab-space indentation in some parts of the code 
>> (e.g. 
>> https://github.com/elvisxzhou/artemisd/blob/master/source/artemisd/entity.d 
>> )
>
> I'll give it a try, thank you!
>
> My main concern in the D port is, since getComponent is the
> most important and most used function, often in every frame,
> but caching it is not a good idea cause any component may
> be removed or added at any time, with an additional
> mixin TypeId in component definition, component then can be
> get with its TypeId(index of component list) in zero cost.
> In other ports, like Java or C#, even in C++, a ComponentMapper
> like stuff is used to hash a component type to find a registered
> index before you can get it efficiently.
>
> What do you think?


In my implementation I don't even use a getComponent equivalent; 
a process()
(or opApply() in the older version I linked) function directly 
takes component
references, and all components are in plain arrays. Processing of 
a System
is done (in generated code) by iterating over the components the 
System specifies in its signature, which is cache-friendly, and 
means the components needed are always available directly to the 
process() function without any lookup. However, this is a less 
flexible approach than what you're doing (although intentional, 
again, to eventually enable very easy threading).

That said, in my code, entities can only be added/removed between 
frames
(a System might create a new entity but it will only start to 
exist with the next frame), and components cannot be changed once 
the entity is created (although the new past/future design I'm 
working on now might enable that).




More information about the Digitalmars-d-announce mailing list