Should static tiles and dynamic tiles share the same parent class?

Question

I want to make an abstract Tile class for all of the tiles in a platformer game - walls, platforms, floor traps, everything. This parent class has basic things every tile will have, such as width and height, position, and boundbox, as well as getters for all of these things. I want to make these attributes constants, because those things typically shouldn't be changing - a wall shouldn't have its width and height changed, for instance. However, in some special cases, those attributes may indeed change - a special platform may change its height when the player jumps on it, or another special platform may disappear after 1 second after the player jumps on it, for instance.

This presents a problem, because for the static tiles, non-constant attributes in the Tile class is bad practice, but for dynamic tiles, constant attributes will prevent them from being dynamic. Is the best method, then, to create two different parent classes, which are the same, aside from one with constant attributes and one with non-constant? Is there a special name for dynamic tiles (I've heard "entity" thrown around, but I really don't know)?

Answer 1

I suggest avoiding inheritance altogether. Inheritance hierarchies quickly become unwieldy, especially when you start layering on multiple differences:

• dynamic vs. static tiles
• destructible vs. invulnerable tiles
• normal tiles vs. trigger tiles
• invisible vs. visible tiles
• colliding vs. non-colliding tiles
• lethal vs. non-lethal tiles
• etc.

See where I'm going? If you start trying to model all these differences with inheritance, your class heirarchy will quickly become a nightmare.

Instead, model all these things as either properties or sub-components of a tile. You may want to look into:

• Prototype based object models
• Component-entity systems

For example, in a component-entity system approach, you might have a "MovingTile" component that indicates a tile is dynamic, and encapsulates the pluggable logic for moving the tile around in a predefined pattern.

Answer 2

Quick Answer: Depends heavily on your usage pattern.

You are, in fact, describing an entity in your question. Tiles are generally following a geometrically regular tessellation (Quads, Hexagons, Pentagons+Hexagons, Octagons+Quads, etc), and thus can gain the benefits of deterministic procedural layout.

If you have true tiles creating the majority of the world, definitely take advantage of the spatial structure and create a specialized system apart from the entities. On the other hand if your "tiles" are irregularly positioned or shaped, then it doesn't make sense to call them tiles at all.

In either situation, you probably should not differentiate between static and dynamic entities at all without a good reason! Your systems should decide how to organize and process the workload, not your data.

Example: Even if an entity is not "static" you might gain a benefit from letting it be considered static while it's inactive. (This time limit can be estimated from how long it takes to update your acceleration structure).

To reiterate, data represents what to do, the system knows how to do it.

PS: It's only bad "practice" if your skills don't improve by it.