tdzienniak / entropy

Framework for making games and not only games in entity system manner.

Hi there 👋

entropy's Issues

Wiki

Write some getting stared guide and tutorials:

• Getting started
• Concepts
• Components

Explain reversed start/stop of system event responses

In packages/entropy/src/System.js, the this.stopResponding(); and this.startResponding(); look swapped. The comments basically rephrase the code, explaining only that it's about events, but what I wonder a lot more is: Why should a system respond to events when disabled, and not respond when enabled?

BitSet API

Hi,

I'm the author of BitSet.js and as you rely on this lib (even a quite old version), I want to notify you, that I changed the API of BitSet with version 3.0.0 that method invocations no longer change the state of the actual object, but return a new object.

Making BitSet immutable was a big step, but I think it makes things more reliable. I just browsed your code and found 3 occurrences which should be changed in order to work with 3.0.

Sorry for any inconveniences.

Robert

Auto-detect/generate plugin "prop"

Hi, I wondered about the "prop" requirement in "Writing plugins" and for me it didn't "become clear, when [I saw] the code". Why won't the plugin system add the "prop" property to my plugin factory in case it's missing?
On most systems any function has a name property that can be used, but my gut feeling is that you should add some unique ID (e.g. counter) anyway to avoid conflict between multiple plugins that happen to have the same name, like when you use multiple copies of a "recoverSpellPoints" plugin for different kinds of magic.

Example:

function registerPlugin(plug) {
  var propUid;
  if (!plug.prop) {
    propUid = (+registerPlugin.propUid || 0) + 1;
    registerPlugin.propUid = propUid;
    plug.prop = (plug.name || 'anon') + '#' + propUid;
    console.log('registered with generated prop:', plug.prop);
  } else {
    console.log('registered with existing  prop:', plug.prop);
  }
}

var PluginA = (opts) => {};
var PluginB = (opts) => {};
var PluginC = (opts) => {};

registerPlugin(PluginA);    // prints: registered with generated prop: PluginA#1
registerPlugin(PluginA);    // prints: registered with existing  prop: PluginA#1
registerPlugin(PluginB);    // prints: registered with generated prop: PluginB#2
registerPlugin(PluginB);    // prints: registered with existing  prop: PluginB#2
registerPlugin(PluginC);    // prints: registered with generated prop: PluginC#3
registerPlugin(PluginC);    // prints: registered with existing  prop: PluginC#3

In an execution environment where functions don't have .names, they'll just be all "anon" but still get unique .props.

Update: Fixed to avoid repeated console messages. (They weren't silent, I just didn't see the "×2".)

Extend query capabilities

User should be able to write a query which will match entities with some component OR some other component.

Documentation for plugins

• state-plugin
• loader-plugin
• animation-plugin

Documentation

Documentation for modules:

• Engine
• ComponentStore
• SystemStore
• Entity
• Component
• EntityStore
• Entropy
• Query
• System

Tests

Tested funcionality:

• Engine
• ComponentStore
• EntityStore
• EventEmitter