ArtemisD: A D port of Artemis Entity System Framework

About Artemis

  Artemis is a high performance Entity System framework for games, written in Java,
and is a framework to manage entities in a game world. It is inspired by
Entity Systems are the future of MMORPG blog series by Adam Martin.
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/

  We also borrowed ideas from Ted Brown who implemented a simple high-performance
Entity System in Processing based on Adam Martin's blog.
http://www.openprocessing.org/sketch/18023

  The framework is based on the concept that entities in a game world exist as pure
identifiers,their components contain only data, and systems process entities based
on their aspects.This promotes separation of concern and simplifies game design tremendously.

ArtemisD:
https://github.com/elvisxzhou/artemisd
http://code.dlang.org

Refer to http://gamadu.com/artemis for more info about Artemis.

Any suggestion or PR is welcome!

Elvis

Am 07.10.2013 11:18, schrieb Elvis Zhou:
> ArtemisD: A D port of Artemis Entity System Framework
>
> About Artemis
>
>     Artemis is a high performance Entity System framework for
> games, written in Java,
> and is a framework to manage entities in a game world. It is
> inspired by
> Entity Systems are the future of MMORPG blog series by Adam
> Martin.
> http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
>
>     We also borrowed ideas from Ted Brown who implemented a simple
> high-performance
> Entity System in Processing based on Adam Martin's blog.
> http://www.openprocessing.org/sketch/18023
>
>     The framework is based on the concept that entities in a game
> world exist as pure
> identifiers,their components contain only data, and systems
> process entities based
> on their aspects.This promotes separation of concern and
> simplifies game design tremendously.
>
> ArtemisD:
> https://github.com/elvisxzhou/artemisd
> http://code.dlang.org
>
> Refer to http://gamadu.com/artemis for more info about Artemis.
>
> Any suggestion or PR is welcome!
>
> Elvis
>

seem nice - BUT it seems too java oop like and very ungeneric, is there a real need to derive from component?

On Monday, 7 October 2013 at 09:31:15 UTC, dennis luehring wrote:
> Am 07.10.2013 11:18, schrieb Elvis Zhou:
>> ArtemisD: A D port of Artemis Entity System Framework
>>
>> About Artemis
>>
>>    Artemis is a high performance Entity System framework for
>> games, written in Java,
>> and is a framework to manage entities in a game world. It is
>> inspired by
>> Entity Systems are the future of MMORPG blog series by Adam
>> Martin.
>> http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
>>
>>    We also borrowed ideas from Ted Brown who implemented a simple
>> high-performance
>> Entity System in Processing based on Adam Martin's blog.
>> http://www.openprocessing.org/sketch/18023
>>
>>    The framework is based on the concept that entities in a game
>> world exist as pure
>> identifiers,their components contain only data, and systems
>> process entities based
>> on their aspects.This promotes separation of concern and
>> simplifies game design tremendously.
>>
>> ArtemisD:
>> https://github.com/elvisxzhou/artemisd
>> http://code.dlang.org
>>
>> Refer to http://gamadu.com/artemis for more info about Artemis.
>>
>> Any suggestion or PR is welcome!
>>
>> Elvis
>>
>
> seem nice - BUT it seems too java oop like and very ungeneric, is there a real need to derive from component?

It's simple enough without over design IMO.

Am 07.10.2013 11:57, schrieb Elvis Zhou:
>> seem nice - BUT it seems too java oop like and very ungeneric,
>> is there a real need to derive from component?
>
> It's simple enough without over design IMO.

yes - if the need of beeing part of the hierachy is not a problem :)
most D libraries try to be more generic and not that strong coupled - but that comes from the java background of the project

still nice

On Monday, 7 October 2013 at 10:35:32 UTC, dennis luehring wrote:
> Am 07.10.2013 11:57, schrieb Elvis Zhou:
>>> seem nice - BUT it seems too java oop like and very ungeneric,
>>> is there a real need to derive from component?
>>
>> It's simple enough without over design IMO.
>
> yes - if the need of beeing part of the hierachy is not a problem :)
> most D libraries try to be more generic and not that strong coupled - but that comes from the java background of the project
>
> still nice

Really, generic programming in D is easy and fun, ArtemisD also benefits
from it with original design retained.

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

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!

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 )

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 )

*look over the code, not comment

On 10/7/13 2:18 AM, Elvis Zhou wrote:
> ArtemisD: A D port of Artemis Entity System Framework
[snip]

Limelight on! http://www.reddit.com/r/programming/comments/1nxlxt/artemisd_a_d_port_of_artemis_entity_system/


Andrei