sayhisam1 / stitch Goto Github PK

Currently the only example is tetris.

Adding more examples (even if it's just small snippets of code to docs) would be immensely helpful in introducing newer developers to Stitch.

Currently there's no way to enforce that an entity should be of a specific type when a component attaches to it.

For example, you may want to attach the Equipped component only to Roblox Tools. Ideally there'd be an error if you tried to add an Equipped component to anything but a tool.

Currently, the validators property of ComponentDefinitions is a map from key to function. This means that arbitrary keys cannot be validated.

Proposed changes:

• rename validators -> validator
• validator is now a function that takes in the entire data dict, and returns a bool (similar to t library)

This change also has the neat side-effect of supporting t directly, since users can now pass their t typecheck directly to validator.

I'm not entirely sure what to name the argument - we may want to add support for validating the entity that a component is attached to.

It's often useful to have a quick reference of patterns one might want to use when building things with an ECS.
I've added a wiki (https://github.com/sayhisam1/Stitch/wiki/ECS-Pattern-Data-Dump) that contains some ECS patterns with some Stitch examples.

If anyone has any patterns they want to add, feel free to add it!

Immutability simply isn't performant enough for large games. I am re-adding observers and events to Stitch to solve this issue.

Observers should themselves be immutable though (see Rx)

Leaving this up as an issue for discussion on how this should be implemented

Currently, the ReplicationSystem only supports a simple on/off flag for each component.

It'd be nice to have a way to whitelist/blacklist which clients data should be sent to.