Next Steps. about esper HOT 8 CLOSED

Thanks for opening the ticket. The issue tracker is perfectly fine for ideas or proposals, so don't hesitate to open them!

1. That would be great. The docstrings should be fairly complete, but proper API documentation needs to be generated. I plan to set up automatic building via ReadTheDocs.

2. I have hesitated to do this for one reason. Currently the cache needs to be invalidated whenever anything is added or deleted. I wanted to investigate if it's feasable to implement caching on a per-Component or per-Entity basis. This would likely require a very custom cache implementation, or a change in the internal DBs. Maybe this is best left to the future, and just roll in the current implementation for now as you suggested (since it's pretty much faster in most cases).

3. This is not something I personally use, since I rely on pyglet's event classes for most of my games. However, I am open to this as long as it's not too bloated. The key thing is that it shouldn't cause any performance hit if it's not used.

from esper.

Oops. Accidentally pressed the wrong button :)

from esper.

Thanks for replying. I'll hold off on the Cached World for now. I have a few ideas for event systems, but depending on how things go I might can it or just create a new repo if it doens't fit the scope of this project. I'll check out ReadTheDocs and try and see if I can implement that myself.

from esper.

I was thinking of switching the readme from RST to Markdown, simply because of my familiarity with Markdown. Would that be alright with you, or should I stick to RST?

from esper.

Either one would fine for the README, but I would prefer to stick to RST. This is what Sphinx uses by default.

On another note, I have found a bug with the new CachedWorld. In a real application, try_component will sometimes throw a key error. I haven't yet tracked this down. Instead of rolling back the changes completely, I think I will just do idea # 2 instead.

from esper.

Just FYI, CachedWorld is now the default World. I'm happy about this now that I've done it, as things are much simpler.

I still want to investigate more advanced caching for the future, even though it will likely require some changes to the internal DBs. Implementing caching per component type seems like a good start to investigate.

from esper.

That's great to hear. I'll look into caching per component type when I finish with the Readme and event system prototype.

from esper.

Closing this issue to create more specific issues.

from esper.