Refactoring suggestions (I'll help) about marteengine HOT 4 OPEN

Good points, need some time to think about it, but first ideas:

textEntity and Background: key point of MarteEngine is easy of use and simplicity. Thinking about all in our engine as Entity simplify all in your game, when you design it and when you debug it. So I think that these classes for now are ok: simply and easy to use. Maybe introduce an interface for updating and one for rendering could help, but I think that in the end the code will be not so readable.

movers for motion: same as above.. but we can think about this, can you provide some examples?

physics as an interface: this is a good idea and I'm thinking about this topic in version 0.4, see #18

from marteengine.

The problem about TextEntity and BackgroundEntity is that they only need to be rendered, but they're inheriting all this code they'll never use. I understand that we want everything to be simple, but if we make them inherit from something called Renderable, for instance, and give them all the same initialization and expose the same methods (for rendering and updating), then why not?

The reason I'm concerned about this is because I want to do some stuff with scrolling text and things like that, and that's going to have to render completely differently than an entity. What are your thoughts?

I think that movers for motion is better is that it works hand in hand with abstracting the physics engine (as mentioned here and in issue 18). There are two possible implementations: the Mover class, or the Mover interface.

If they're an interface, then you can define different motions for each class that moves uniquely.

Okay, now that I've seen that issue, I'm even more convinced that we need to make our current 'lite' physics a separate logic. We have to separate the functions of a physics engine and a mover:

The physics interface should only calculate forces and come up with that frame's animation, and then the Mover should handle actually moving the Entity.

from marteengine.

Not sure about movers and physics.
The simple physics entity stuff is kept in one package with it's only dependencies on Entity (I think).
Complex physics entities using Fizzy for example could also be based on Entity and use their own package.
So the user can choose between one or the other.

If you add an interface for physics behavior you'll have to force both approaches (PhysicsEntity and FizzyEntity) to fit the one interface which is bad design in this case IMHO.

Just offer two implementations that are independent of each other. My two cents.

from marteengine.

I'm doing it a different way. Basically, my PhysicsEntity holds nothing but data. The mover calculates the forces on an entity, updates their location, and does movement logic (like switching direction when you hit a wall).

In your example, you would simply have a different method for 'calculateForces()' depending on which engine you use. It would still only use one mover, and still be decoupled from the entity itself.

from marteengine.