Comments (4)
This is intentional, and the behavior is mentioned in the readme.
Event dispatchers do not own the instance of the attached handler/observer, and should not hold a reference to keep it alive.
Within the current design, there would be no other way to remove the handler that is set in _dummy_init
. A more sophisticated design could be done, but it's out of scope for esper
. The included event dispatching is really on here to facilitate event passing between Processors, which is the common use case.
from esper.
Got it. Thank you for helping me understand.
I find that processors are really meant to handle game architectures it seems, as by design they are intended to vertically transform a grouping of entities en masse at each frame tick. My use case is almost exclusively events and events usually are the interaction between singular entities within the model, therefore making Processors almost overkill, especially in light of v3.0.
Before 3.0 I was creating individual worlds just to handle individual types of transformations and I imagine my code base would have become polluted with floating one-off worlds just perform process calls of a certain family or event. To migrate to 3.0, I've had to dissolve all these worlds and combine them and introduce "Handlers" in conjunction with the event system. With use-cases that advance event-driven state by state vs fixed time interval, avoiding Processors seems to be the favored pattern (now that worlds aren't explicit)
Do you have any thoughts on this? Apologies for all the questions. I am just really excited about using the esper library and while I've used other languages I'm still relatively new to Python (< 9 mo).
from esper.
I find that processors are really meant to handle game architectures it seems, as by design they are intended to vertically transform a grouping of entities en masse at each frame tick.
Essentially, this is the main design point of ECS libraries, and what dictates the design of esper. The Processors themselves don't even care about entities as a whole - they are only interested in performing specific operations on single (or specific combinations) of Components.
My use case is almost exclusively events and events usually are the interaction between singular entities within the model, therefore making Processors almost overkill, especially in light of v3.0.
What you're describing is not really an Entity System. Which isn't to say it's wrong, but it's something different. Not every game fits the ECS pattern well. Lots of games use a combination of patterns in the same package. Writing the scene management code in ECS doesn't make sense IMO.
As an aside, you might find this talk by Bob Nystrom interesting:
https://www.youtube.com/watch?v=JxI3Eu5DPwE
from esper.
Thank you! Loved the video! Very interesting and it certainly gives me some food for though.
from esper.
Related Issues (20)
- enhance `get_component` HOT 4
- Create an entity with a specific id HOT 4
- Try another ECS implementation - ecs_pattern library HOT 2
- Typing of world under the processor class HOT 3
- Testing esper HOT 4
- mypy `get_components` gives "object" type HOT 1
- Relationships HOT 8
- `World().create_entity()` does not create entity if no components are given HOT 1
- `remove_component()` method removes entity if no more components left HOT 3
- Add mypy to unit tests HOT 2
- Querying entities with denylist of components HOT 5
- API Design : Why so much OOP ? HOT 20
- "Quick start" in README is targeting old version HOT 3
- Seeking Guidance on Persisting and Loading Esper from a Database HOT 2
- Is esper Thread-Safe for Multi-threaded Environments? HOT 5
- Why roll up world into esper module? HOT 4
- Event System does not preserve event handlers upon switching context HOT 4
- esper.current_world not usable as a module-level property HOT 2
- Initializing the world is not working HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esper.