FreeGameDev

StefanP.MUC {l Wrote}:Yeah, I know. But when using interfaces we have to implement the same code several times. Every subclass then needs to implement it's own get/setName(), get/setPosition(), get/setLevel() ... functions, for example.
The whole refactoring process was started with the intention to avoid these kind of code duplication. If we now start to re-implement these functions we wouldn't have to start the refactoring in the first place...

StefanP.MUC {l Wrote}:Let's make a table of what object types we have and what properties they need, including possible use cases:

Creature
Attackable - Yes.
Movable - Yes.
Active - Yes, but currently has its own doTurn(), could be replaced/renamed by doUpkeep()

Trap
Attackable - Yes.
Movable - Probably. Ideas: Mimics. Something like the Stomps from Super Mario (stone blocks that move back and forth on a fixed way)
Active - Yes.

Room and RoomObject
Attackable - Yes.
Movable - No. Maybe RoomObject moving on the Room, but generally not, I believe.
Active - Yes.

Tile
Attackable - Probably. Digging/Mining a wall/gold could be handled like attacking.
Movable - No.
Active - Probably. Ideas: Lava tiles maybe shoot out a fireball. Tiles that have a Geyser on them. Mana sources.

Weapon
Attackable - Probably. Ideas: Creatures can be disarmed if the enemy attacks the weapon instead of the holder. Destroyable weapons.
Movable - Probably. Ideas: self-returning throwable spears or axes.
Active - Probably. Ideas: Guns or similar need to reload. Magical weapons that need to recover after using their special feature (e.g. magical wands).

MissileObject
Attackable - Probably. Ideas: Cancel/weaken a fireball with water. Fast creatures could redirect arrows by hitting them.
Movable - Yes.
Active - Yes.

Conclusions:

• Probably everything can be attacked. So merging GameEntity with AttackableEntity should be fine, flag "isAttackable" is provided for non-default cases.
• Probably everything can be active. So merging GameEntity with ActiveEntity should be fine, flag "isActive" is provided for non-default cases..
• Movable has the biggest uncertainty. Rooms, RoomObjects and Tiles are fully static, some other things probably, too. Merging this is not logical. But how to handle actions like "change position/move"? The property "position" is common to all objects, but the class MovableEntity would have no access to it then.

Maybe making GameEntity a big class handling and providing attacking, moving and activity and solving the individual property availability by flags (simple bools) is really the best solution to get a clear structure. This would also be the most easy way to get scripting done, I think.

This would lead to

{l Code}: {l Select All Code}

           GameEntity
               |
   --------------------------------------------
   |           |          |        |          |
Creature    Building    Weapon    Tile    MissileObject
               |
           --------
           |      |
          Room   Trap
//And somewhere RoomObject, either also a Building or directly a GameEntity


Any opinions on this?

StefanP.MUC {l Wrote}:Ah, you were faster with replying than I did my edit. Added the same question for level:
Does a level make sense for non-Creatures? It's currently only used for Creatures and I can't imagine any case where non-Creatures could have a level.

I think it would be better to use exp and level only for Creatures. And if later evolving of buildings is needed then we can introduce some kind of "upgradeStage" ("wooden tower -> stone tower -> canon tower" as an arbitrary example).

StefanP.MUC {l Wrote}:The Strategy pattern is new to me. But after the first look it looks rather complex for our game. After all, the amount of classes and code we have is not very much, compared to large scale projects. So, not sure if it would be worth the effort (especially now after we already started the big refactoring and proceeded very much).