System / Data API suggestion about sim-ecs HOT 6 CLOSED

Hi @vmwxiong ,
wanted to update you on what I am working on right now, since you may be interested in the change! I am reworking how querying a world works. I finally found a satisfying alternative to the type boilerplate, which may even lead to very simple queries you can easily use everywhere with caching benefits (but sans the life-cycle). The new queries come with better type support, less typing and allow for some new good stuff under the hood. The status is: WIP. I still have to update some under-the-hood things to make it all work, but the Query class has come a long way, so I feel comfortable to share a bit :)

Also, I want to get some feedback from you, if the below demo code is closer to what you would love to work with.

Say goodbye to type boilerplate for Systems:

• Just write a query and do not worry about types, it will work out as expected

Deverloper convenience is still a goal:

• Auto-complete and checking at dev and compile time
• Even read-only status is now enforced by the type system
• Choose the field name yourself for consistency, control and stability, without any surprises when changing fields
• Queries can be written anywhere and will still be cached and updated automatically (if they were registered at world creation)
• Queries can also be one-shot and created dynamically by passing a world object to the iter() method

from sim-ecs.

Your snippet is a nice idea and solves the problem with the field order and type. Writing a method for a callback is simple and straight forward, now So, I did it and will include it as alternative :)

Thank you for the feedback!

from sim-ecs.

I think I experimented with this before, but was not able to get it entirely right (also asking around). But I think I just saw one missing piece in the puzzle to a struct-less System in your code. I will play around with it. However, I don't think I will change how a system looks entirely. I would like systems to ideally

• be self-encapsulated, meaning it can have its query next to its private fields next to its logic
• have an opinionated architecture, so that systems always look the same. Enforcing a class with implemented interface is very helpful to that end
• be manage-able, so that I can distribute them (across several workers) and instantiate or destroy them without relying too much on user-code

Systems being functions would be a counter to that end imho. It may also be just my preference. I will give this another go and see if I can make the current API simpler, ideally removing the extra struct :)

from sim-ecs.

Yeah going with fully functional Systems would definitely be a pretty specific take on things.

You might want to check out the API that Ape-ECS is going with if you haven't already, might give you some ideas: https://github.com/fritzy/ape-ecs/blob/master/docs/System.md

It's a very different direction, but basically the idea is to think about whether or not you want the notion of multiple Queries vs a single, purely matched system. Both approaches have their pros and cons. Multiple queries allows for easier to implement batching of functionality by interacting with multiple types of entities in one go. On the other hand, it drastically alters separation of concerns, and makes it immediately more difficult to tell what components a system is even capable of "messing up". Just food for thought.

from sim-ecs.

I messed around a bit with the type system, and still was not able to come up with a good way to statically type a generic query without generics. While going functional, like in your example, might work, it still does not provide any way for a system to build a cache or be optimized, especially when running in a distributed way - which is the ultimate goal. So I think it is best left to ape-ecs to go down that route, while I try another direction 😉

If you or anyone else comes up with a better plan on how to achieve all goals, then I'm all for merging a PR and make it happen!

from sim-ecs.

Ooooh, very interesting. I like the direction for sure.

I think I'd personally want to be using some kind of syntax that would still look like a callback in the end, sort of like

this.query.execute(({info, test}) => {
  info.count++;
  console.log(test);
});

But that might just be me. This would probably be some syntactic sugar on top of what you already provide here, since there may be occasions when you would want to halt prematurely. I just think this kind of format is easier to understand semantically, given my preconceived notions of what a query is and does in general.

Looking good!

from sim-ecs.