Push out a new release about esper HOT 14 CLOSED

There isn't really a single best way to do things, but I can give you some ideas.

For my personal projects, I tend to have a SceneManager at the top level, with several Scene instances attached. The main menu, options screen, and gameplay are all seperate Scenes. Each Scene has a reference to the SceneManager, so you can easily switch between Scenes. User Input in done at the Scene level. Inside the Scene is where the Esper.World instance goes. Every Processor I make usually gets instanced with a reference to the parent Scene. This is a flat, top down approach, and I find it gives me access to all necessary things without using globals.

For events, I tend to rely on the pyglet Event classes.

from esper.

Is there a list of features you wished to implement?

from esper.

Consolidating the Worlds was the main thing I wanted to complete before stamping v1.0, which is now done.

There aren't any features that I'm missing in my personal projects, but I'm open to any ideas that would be useful. The main point is that they shouldn't negatively impact performance.

from esper.

I think having kwargs in the process method will be kind of useful. It will gives us more options instead of just relying on positional arguments. process(self, *args, **kwargs)

from esper.

Nevermind. I've tested this out on my end, and I'm getting "parameter 'kwargs' value are not used" warnings everywhere in Pycharm.

from esper.

Hi @toptea,
That's actually possible to do. I've not personally use kwargs, since I tend to only pass delta time to my Processors. If it's useful to others, I can add this.

from esper.

@toptea I just added support for **kwargs to Esper. This is available in the master branch right now, and of course will be part of the upcoming 1.0 release to PyPI. This was easy to add, and has no performance impact if you don't use them.

Also, it should be said that the use of **kwargs in Python has a slight performance overhead. It's pretty small, but something to keep in mind if your game is very performance sensitive.

from esper.

Oh thanks @benmoran56. To be honest, this is my first time using ecs, and I'm still working out the details like where the event handling should go.

In the processor, I will use dummy variables for parameter I won't be using, and add *args at the end. process(self, _, event, *args) If I have loads of "global variables", I will probably start using **kwargs.

from esper.

That's surprisingly similar to the system I use, which involves States and a StateStack that manages these States, with the added benefit of being able to easily switch between states. I might just use your ideas as well now.

Also, one of the ideas I wrote down in my fork involved adding **kwargs to processing, good to hear it's been added now.

from esper.

I guess it's just a design that makes sense. I evolved into my current style over time. It is basically a state machine.

from esper.

Have you ever persisted your World data? I wonder if having ephemeral entity_ids is going to be problematic for me. Wondering if there's a way to persist the world data that would see everything intact after restarting.

from esper.

Hi @smartattack. I'm currently working on part 7 of the roguelike tutorial but with esper library instead. I had a quick peek ahead and it does look like it is possible to pickle or shelve any python objects. Another method I am more leaning on is to save world._components & world._entities dictionary into a something like a json file. Does this help?

from esper.

Yes, it might, and thanks for the pointer. I actually just tried using dill and was able to save and load a skeleton world. I'll have to flesh this out a bit to see if I can actually save and load all the ECS data in one shot like this once I have components with Real Data.

from esper.

I just pushed out v1.0, so I guess it's time to close this thread.

If anyone has any questions like this, please feel free to open up additional issues. Even if they are just simple questions and not bugs, that's still OK to use the issue tracker in that way for this project.

from esper.