hexworks / amethyst Goto Github PK

Caves of Zircon has an attribute called Actions which is a command container, which is basically a special case of

if(hasAttribute)
dispatchCommandOnOtherEntity

Its a useful construct, but it feels like its a code smell and something is missing.

Actions could be hoisted up to be equivalent to facets, behaviors etc. but then you could only trigger them all. So having different triggers (bump vs shoot vs eat for example) wouldn’t work. Is there some missing concept?

Or is this the least worst idea?

kotlin/JS is moving to a new compiler, so libraries should use "BOTH" compilation mode to ease the transition. Some code changes may be necessary. Additionally, all dependencies (i.e. cobalt) will need to be built in BOTH mode.

I tried changing cobalt to BOTH and it seemed to build fine, but when I published to mavenLocal and tried to use it in amethyst ran into issues (Unresolved reference: cobalt on every import statement).

Using this library is slightly complicated by ProcessorsExample.kt publishing all of its types (like Entity, EntityType, Attribute) into the final artifact. Whenever I'm importing Entity in my own code, I need to differentiate between org.hexworks.amethyst.api.entity.Entity (the correct one) and the root level Entity (from ProcessorsExample.kt).

I'm not sure exactly what the right answer here is, but perhaps this entire file can be moved into jvmTest perhaps?

More akin to classic ECS systems like Global Actors, good for things like Field of View as it means you don't have to have a special case for the player, because you can loop through everything that has a Vision attribute.

Right now FOW in Caves of Zircon has a World Entity that deals with FOW. Having some kind of Global System would be more representative of reality.

Additionally, the FOW Entity also has to use a reference to a player Entity in order to get its Vision attribute. This means the player is being special cased vs other things with a Vision attribute. It would be better for FOW to be a global system that had access to all entities of a given type.

A possible solution would be for the Engine to use commands to send AddEntity and RemoveEntity. Then have global systems like FOW respond to those commands in order to keep a list of what entities have the attributes they care about.

Two potential ways to do this is to keep a list of systems, and pass the AddEntity and remove entity commands to those systems.

Alternatively those commands could be passed to every Entity. Which is more flexible but now adding entities would get more expensive the more entities there are regardless of how many listeners there are. This could be adjusted by only calling entities that care about a given message. Not sure how the engine would know which entities have which Facets though.

This lets us not send commands to things that can't take them, which lets us build global actors that can take AddEntity and RemoveEntity commands without adding ever increasing cost to addentity/removeentity for entities that don't care about those commands.

Example:

/**
 * A [Facet] is a [System] which performs actions based on the
 * [Command]s they receive.
 */
interface Facet<C : Context, T : Command<out EntityType, C>> : System<C> {

    /**
     * Performs the given [Command].
     * @return the [Response] to the given [command].
     * @see [Response] for more info.
     */
    fun executeCommand(command: T): Response

}

and then the compose function:

fun compose(other: Facet<C, Command<out EntityType, C>>): Facet<C, Command<out EntityType, C>>

This also means that facets can only take a single command. Which is a good thing.

What happens if I try and dispatch a command at runtime and an entity has no facets that intercept it?