LÖVE

kexisse wrote:Basically my "Pushable" mixin should make some entity subclasses pushable, but not others.

Your problem is not a "tools" or "libraries" problem. It's a problem of understanding. You seem a bit confused about what some key concepts work in Object Orientation - or at least that is what the line above makes me think.

It is mostly regarding inheritance.

Inheritance is a double-edged sword; it cuts both ways. 80% of the time it is exactly what you need. But other times it brings more troubles than it solves. You are on that situation.

Think about it for a moment. Inheritance allows you to write a "tree of classes" for a "taxomony" - a main characteristic. Usually the main characteristic can be deduce by looking at the root of the tree. For example, you have Vehicle, with Car and Airplane as its children. The main thing on this hierarchy is that you are organizing vehicles. Etc.

In your case, however, you don't have that. Your root node is "abstract". This is not bad per se, but it makes deciding what the main characteristic of your hierarchy is very difficult.

Plus, you have have several "ortogonal taxonomies" going around - That is what Pushable, CarryAble, etc are.

Inheritance is what you want most of the time, because very often you only are interested in "One main characteristic" to organize your classes around. You are trying to use it to organize several orthogonal taxonomies, and that is what your pain is coming from.

Once you know inheritance is not the right tool for the job, you must look into other tools. Middleclass' mixins are one possibility. If I where you, I would go easy on inheritance, leaving it for the "main taxonomy" (Entities), and use mixins for all the "secondary traits". Here are some examples:

Thanks for the clarification!

Now I just have to work out how to serialize and store my world setup as simply as possible

Also I hadn't thought of that "inline" :include(), it's much neater.

I'm still trying to get my head around a decent architecture for my game.

Imagine the following game item: a pushable ladder (like the ones you get in a library). It has a pushable block on the bottom, and a climbable chunk on the top.

It seems to me it would have the following bits:

• A position, rotation
• A simple sprite for drawing the ladder
• A simple sprite for drawing the pushable box underneath
• A pushable area, maybe the same size as the box sprite. Probably a HardonCollider shape.
• A climbable area, maybe the same size as the ladder, maybe larger. Probably a HardonCollider shape for detecting collision.
• A particle emitter, that emits dust particle sprites when the entire object is moved.
• A sound, that is played when the entire object is moved.

Here's my dilemma, working out how to group them together.

When the player collides with the pushable box, that collision needs to update the center of the Object. All other components need to notice this change. I think changing the x/y of the parent is fine, but the particle and sound components would need to know when a change has taken place.

I'm wondering about using Beholder https://github.com/kikito/beholder.lua, and then there is FEZ https://github.com/perky/FEZ.

But I have concerns that I'm overengineering, or that there's a better way to do this.

What do other people think? How would you go about implementing something like I described?

I would keep the "box underneath the ladder" separated from the "ladder itself". And then I would create a "Boltable" mixin, for things that can be "bolted on" other things.
You may choose to bolt the ladder inside its constructor, or even create the box in the constructor too, but that's the main idea.