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