OO Game Architecture

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: OO Game Architecture

Post by kikito »

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:

Code: Select all

Entity = class("Entity") -- entity is the root. It has methods shared by all entities

-- blocks are Entities which are pushable
Block = class("Block", Entity):include(Pushable) 

-- Trees are Entities which are pushable and also animated
Tree = class("Tree", Entity):include(Pushable, Animated) 

 -- EvilTrees are just like trees; they have a different sprite. They are Pushable and Animated, because Trees are, too
EvilTree = class("EvilTree", Tree)

When I write def I mean function.
User avatar
kexisse
Citizen
Posts: 56
Joined: Wed Jun 13, 2012 2:52 pm

Re: OO Game Architecture

Post by kexisse »

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.
User avatar
kexisse
Citizen
Posts: 56
Joined: Wed Jun 13, 2012 2:52 pm

Re: OO Game Architecture

Post by kexisse »

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?
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: OO Game Architecture

Post by kikito »

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.

Code: Select all

local Box = class('Box', Entity):includes(Pushable)
local Ladder = class('Ladder', Entity):includes(Boltable)

local mobileBox = Box:new(100, 200)
local ladder = Ladder:new(100, 200)
ladder:boltOn(mobileBox)
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.
When I write def I mean function.
User avatar
adnzzzzZ
Party member
Posts: 305
Joined: Sun Dec 26, 2010 11:04 pm
Location: Porto Alegre, Brazil

Re: OO Game Architecture

Post by adnzzzzZ »

 
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 3 guests