Good evening !

Im currently developing an little "mmorpg" on my own. I started some months ago and i noticed that its pretty hard to add new content or features to it due to the complexity of the code, structre and the framework. Let me give your an little example...

In my game, players can build stuff. So theres a base class called "BaseEntity". It will be used for all entity related stuff, buildings, resources, duengongs and so on. Theres also a "BuildingEntity" which extends "BaseEntity" and a "TowerEntity" which extends "BuildingsEntity". So all in all this makes it very easy to add new Buildings to my game without writing the same base class ever and every again.

But there problems too. In many places i need to check if the "GameObject" holds an certain Class as a Component. For example, when my player clicks on the tower, i need to check if theres a building script assigned to it. And when i create new "branches" i need to add those to my existing codes every and ever again. This makes it very complicated at some point.

Are there any structures or tricks to make adding new content to a game much more easier ?

  • 2
    \$\begingroup\$ Look into the concept of "data-driven game design". One company was so data-driven, that you could take the .exe from one of their games, drop it into the folder of another, and it would work as the other game in the new folder. \$\endgroup\$
    – Almo
    Commented Feb 19, 2018 at 16:52

1 Answer 1


Unity already has a concept of "BaseEntity" - it's called a GameObject.

A "BuildingEntity" can be a GameObject with a Building component attached.

Rather than deriving "TowerEntity" from "BuildingEntity," see if it can be reduced to just the features it adds beyond the normal Building. For instance, if it's a watchtower with an attack like in an RTS game, maybe it's just a GameObject with a Building, Health, Faction, and TurretAttack component on it. You can re-use those Health, Faction, and TurretAttack components on a creature instead of a building to make an enemy that holds its ground and uses ranged attacks on nearby foes.

Maybe you have shop buildings too. Instead of a ShopEntity subclass of BuildingEntity, you could just have a GameObject with a Building and Shop scripts attached. Meanwhile, a roaming merchant character can also use the same Shop script.

This idea of breaking down your behaviours into modular chunks of functionality you can freely mix and match is called Composition Over Inheritance, and it's a style that component-based systems like Unity encourage. It helps us avoid encoding "is-a" relationships rigidly in code, and frees content creators to create new types of content by combining & reconfiguring existing behaviour chunks.

Once you have a good set of building blocks, new content can be defined in data: "This brand new enemy type? It's all the same building blocks as that old enemy, but with less health, higher speed, and the ExplodeOnDeath behaviour we used for the exploding barrels, so players are challenged to stop it before it gets too close."

And because each piece of content is self-contained, your old scripts (usually) don't need to get more complicated as you add new behaviours. eg. Each behaviour that does damage doesn't need to know how to damage a BuildingEntity and CreatureEntity and PropEntity and your brand new SwitchEntity - it just needs to know how to damage an object with Health and you can ensure all those types have that component attached.

You don't strictly have to work in this composition-focused way, but it's a methodology that was developed specifically to address the concern you raised: adding more content to a game flexibly, minimizing complexity bottlenecks.

  • \$\begingroup\$ Thats exactly what i searched for ! Thanks a lot :D \$\endgroup\$
    – genaray
    Commented Feb 19, 2018 at 22:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .