Entities - Class Design

Game Play & Game Design
#1

Hi,
i’m currently working on an isometric, tilebased survival game. The landscape is 3D, the objects are pixelart 2D. I can post Screenshots later in this thread, if anyone is curious :wink:
My problem atm is, that i’m unhappy of how i implemented entities. My world consists of chunks, 64x64 tiles. Each chunk handles everything on it, for example drawing and updating animals. There are some different kind of entities: some are purely decorative (grass), some are static (a tree) and some are dynamic (an animal). On top of that, some may be animated and most of them have to be pickable (which i use colorpicking for). This classification into 3 parts made the most sense for me: Decoentities won’t be permanent or usable in any way, static entities are usable and stay where they are (like a tree) and dynamic entities will move around by themselves, so they have to check if they left their original chunk.
Currently i use inheritance. Here is a generated classdiagram:

http://imagebin.org/index.php?mode=image&id=204944

http://imagebin.org/204944

I didn’t catch the animation aspect with that because there would be too many constellations, it just feels wrong and too complicated. Does anyone know a solution to code this nicely? Is there a nice way to implement such “features” like pickable or animatable?
Should i simplify some aspects, for example just make everything in principle animatable and dynamic (the player will be able to move small static entities around, so they have to answer “did i leave my chunk” too).
I would be very thankful for some advice :slight_smile:

#2

Some quick thoughts:
StaticEntity seems just like a DynamicEntity with unchanged position. No class for it.
Pickable sounds rather like a simple property or an interface some entities may implement. No class either.
Animation is rather a presentation/view issue. No entity class, but maybe a view/renderer class used as composite object.

#3

There’s a lot you can factor out of an entity that’s truly static and undifferentiated, like a tree or a wall or a rock, to the point where they’re not really “entities” at all, being undifferentiated except for their location. A tree is a tree, maybe you might render one differently than another, but otherwise speaking, it doesn’t really have any state.

So you might just encode these simple “pseudo-entities” as a bit or two in a map layer, and only create entities on the fly when you request one from the map. This is called a Flyweight pattern, and it’s really useful for entities that don’t have any state. Stuff that does have state, such as players and monsters, you don’t use flyweights for.

#4

Thanks for the input :slight_smile:

I’ve teared down and built up the whole thing. Now i just have a class Entity which will be used for (usable) trees and stones and so on. Then i have an abstract class Animal that inherits from Entity and finally things like Bird, Rabbit or Player that inherit from Animal.
I thought that it doesn’t hurt too much to make every entity animatable and pickable.
For the rest, there ist still Decoentity which covers everything with no function or use. I’ll implement it just like sproingie suggested, no reason to keep little grassbushes permanent.

#5

Note, there’s no need to have separate classes for each of these thinker (Animal) types as they only vary by data. However if the total number is pretty small, then don’t worry about it.

#6

Thank you for the hint.
They have different behaviours and different abilities. For example a rabbit can stand up and look around, a bird can’t (atm). They have a “currentAction” what can be walk around, eat, look around and so on, and different probabilities for transitions from one state into another. It’s really a good idea to generalize this for all animals, it didn’t feel to good working with it already because i couldn’t really seperate what belongs to all animals and what is special. Thank you :slight_smile:

#7

The idea here is to use some method of “composition instead of inheritance” to build behavior.