Outline and basic implementation for the Actor sub-system

[hogsy]

We cannot proceed with implementing level objects or other objects until we have a proper outline for this, which also means a rough idea of how things will operate over a network.

From discussions we're leaning towards a client/server model at the moment, but each client will have a copy of all the entities?

---

Some other random thoughts.

• Actors should be registered via an 'actors.manifest' file which has an entry for each actor and it's properties (e.g. is it a 'weapon', 'item' or 'decoration', what model does it use?) - means internally entities should be implemented as basic types; 'ActorWeapon', 'ActorDecoration', 'ActorVehicle' etc.
• Is it worth implementing a component system?
• How will the JS scripts come into play with the actors? Maybe actor declaration specifies which script to use for logical operations?

---

One possible implementation for 'actors.manifest'...

{
    "classes":[
        {
            "name": "DynamicScenery",
            "script": "classes/dynamic_scenery.js",
            "dependencies": [
                "Physics"
            ],
            "properties": [
                {
                    "name": "rotation_degrees",
                    "description": "Rotation overtime",
                    "type": "vector3"
                },
                {
                    "name": "block_explosions",
                    "type": "boolean"
                },
                {
                    "name": "enable_physics",
                    "description": "Enable physics on death",
                    "type": "boolean"
                }
            ]
        }
    ],

    "actors":[
        {
            "name": "WINDSAILH",
            "class": "DynamicScenery",
            "properties": {
                "rotation_degrees": "16 0 0",
                "block_explosions": true,
                "enable_physics": false
            },
        },
        {
            "name": "BOOTS",
            "class": "StaticScenery",

        }
    ]
}

[hogsy]

This is done, really. At least a basic implementation + outline anyway.

@solemnwarning what changes do you want to make to the actor sub-system, at least for this milestone? Otherwise remarks about actor manifest etc will be moved onto a separate milestone.

[solemnwarning]

Only thing that comes to mind right now is that I'd expect the classes themselves to be declaring their properties, rather than the manifest that happens to be loading them. But I don't think we're doing any kind of dynamically loaded classes stuff for the time being anyway?

[hogsy]

Only thing that comes to mind right now is that I'd expect the classes themselves to be declaring their properties, rather than the manifest that happens to be loading them. But I don't think we're doing any kind of dynamically loaded classes stuff for the time being anyway?

I would like to get it done for this release, but realistically I don't think that's going to happen. Below are a list of things I would like to do; not sure if they're things you might be happy to look at?

• Actor class name registered to factory class as opposed to the objects descriptive name; so we spawn based on class name string provided by manifest
• Actor classes exposed list of variable names + descriptions ... no idea how this'd work right now
• Loader for Actor manifest data... Whether individual files for each actor or a manifest with all actors, don't know

We can probably discuss it in more detail later.

[hogsy]

I will be taking over some of this for the next milestone as we haven't made as much progress in this area as I wanted.