Create pyDynECS

[mason-bially]

Build and add the pyDynECS library. A library providing a dynamic entity system for the purposes of dynamic object organization, instead of speed. Designed to be eventually consumed by madz as part of a general ECS library (and then providing the best of both worlds).

This ticket is primarily finished when pyDynECS has been successfully added to this project for the plugin descriptions. Althought the pyDynECS library will be responsible for many of the other features used by madz (identity and nodes primary among them).

[mason-bially]

Changing the target of this ticket to be the finished pyDynECS library, moved other goal into a ticket. Finished includes:

• Graph
• Types
• Computed
• Serialization
• Documentation
• Examples
• Unittests

[mason-bially]

Cleaned up the syntax, some more changes:

• Automatically detect indices, so decorators aren't needed for them. May require a custom meta class for Managers.
• Move manager and index decorators into the syntax_for pseudo macro.

[mason-bially]

System Syntax

We should expand the system object to provide more syntax niceties, we can use __getitem__ to type check the argument and get the most useful thing out of it.

We may want to use decorators to abuse the class definitions for managers into actual managers and indices, but that might be going a little far.

Component Manager Expansions

There are some additions we need to component managers, we need an observable component manager so that index's can update their information. Part of this is in #47.

We also need computed component managers, which will depend on other component managers. Dependencies on other component managers should be handled by the depending component managers for the time being.

It may be useful to add a shared interface for dependencies between both managers and indices.

Finally for syntax, it may be useful to create a meta-class (or even just a very smart decorator) which automatically adds indices, component managers, etc.

Classes

Entity classes are the last big feature we need, an entity class is an object which can be created for entities matching certain conditions (primarily, existence of components). They have an implicit computed component manager which creates them.

Something to consider is storing state for these. There are some solutions:

• Require the creation and management of a manger by each class.
• Provide an implicit manager for the type class, with a dynamic store for the data.
• Use a meta-class to automatically store values into component managers generated just in time for the class.

An example of how an entityclass might look:

@class_for(ASystem)
class ExampleEntityThing(pydynecs.Class):
    managers = {
        "foo": ImportedModule.ManagerFoo
        "bar": ImportedModule.ManagerBar
    }

    def example_function(self, birds):
        self.foo = self.bar.transform + birds

def test_it(e):
    # Implicitly create entity classes on entity facade, and use
    ASystem[e].example_function(12)

    # Explicit
    ExampleEntityThing(e).example_function(12)

    # Internal
    ASystem[ExampleEntityThing][e].example_function(12)

Graphs

The final thing to add are graphs and trees.

Essentially a graph or tree class is created with a system in mind, and a way to traverse each entity. The classes merely manage the traversal of each entity. Graphs and trees can also provide component manager views of each entity, namely the traversal result, including parents.

[mason-bially]

Calling this one mostly done, splitting remaining work into:

• 49: Graphs

• 50: Sync

• 51: Processors