Refactoring suggestions (I'll help)

[flowstate]

First off, I really appreciate you guys building and sharing this awesome engine. I am fully aware that the suggestions I'm going to make could all be bad, and could be going in a direction you don't want to go. I'm by no means implying that either of you aren't good programmers or that you've written bad code.

I'm merely relating some of my thoughts about the engine. If you're not interested in making any of these changes to the engine (or letting me do so), that's fine.

Anyways, this issue thread is where I'm going to keep making suggestions or describing how I'm refactoring the engine for my purposes. If you want to use any of it, or have any input on any of these subjects, please let me know!

TextEntity and Background

I don't see why TextEntity and Background are entities. The only thing they have in common with any other Entity is that they need to be rendered.

For things like text messages and background or other static images, I suggest that we make a separate subclass, or perhaps just create an interface for updating and rendering.

Use Movers for motion

I saw the movers used for Tweens, and I think that we should make it possible to extend these movers and use them for all entity motion.

That way you could abstract motion from Entities, and make our Entity classes smaller and easier to read.

Implement physics as an interface

If we implement physics as an interface, we can get rid of one level of inheritence. I feel that using an interface is more proper because PhysicsEntity is only different from Entity by behavior (methods), and that is the definition of an interface.

That's it for now, I'm going to get to work.

[Gornova]

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

[flowstate]

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.

[thaaks]

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.

[flowstate]

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.