# Entity Component System

## Recommended Posts

In Java.

Would there be a point to making an abstract GameObject class for entities, and then making a GameObject2D class and GameObject3D class which extend it?

##### Share on other sites

Presuming that you're confident that you're going to have both of (or more than) the GameObject2D and GameObject3D classes, and--importantly--that they share a non-trivial amount of code or interface in your design, then it seems as though it could be useful. For one thing, any general changes that you want to make--say a change to a universal function call used to instruct your GameObjects to render themselves, or a common "update" method--are then propagated to both sub-classes (barring extra work incurred by any overloads), allowing you to reduce the repetition of work.

In short, the question is this: how much do your two GameObject classes have in common?

Edited by Thaumaturge

##### Share on other sites
Such separation is kind of the opposite of the point of an ECS or really any component-based architecture, but there can be a point if you're not aiming for a pure component design (non-component-based architectures or hybrid architectures are perfectly valid ways to solve problems, despite what the rabbid masses of armchair hobbyist game developers on the Internet will scream about).

##### Share on other sites

Seems like a perfectly valid approach. If it works, it works.

The approach the article takes on components are a bit inconsitent. e.g. SpellsPart is very 'fat' (what exactly does it do? does it include all possible spells? how do you control which spells are available, how the AI selects targets, and the strength of the spells?) while others like FlyingPart are very thin (is it anything more than a flag and maybe a flying speed? why is that not just a bit flag on a MovementPart?).

The createMonster function is bad. Make that all data-driven. Make everything data-driven that can possibly be made such.

##### Share on other sites

Would you recommend that approach for an MMO server?

##### Share on other sites

In Java.

Would there be a point to making an abstract GameObject class for entities, and then making a GameObject2D class and GameObject3D class which extend it?

I think it goes against using an ECS, and whether your Entity is a 2D or 3D entity should be defined by it's components.  Otherwise, you're going to be mixing how the objects are handled between handling components, and handing a specific entity type (in this case a 2D entity or a 3D entity).

I just don't see how it's going to benefit you, and I only see downsides to it.

##### Share on other sites

Would you recommend that approach for an MMO server?

Something pretty similar, sure. I mean, that's hardly the first or most pressing question I would ask when designing an MMO architecture. You could write the game objects in plain ol' monolithic monstrosities and still have a perfectly pleasant time compared to writing a beautifully component-based MMO server that doesn't handle all of the actual problems an MMO has.

Component-based design helps with iteration on game object configuration, and it _can_ help with performance (though you don't need components/ECS to achieve that performance). Components don't do a damn thing to help with any of the actually hard parts of making a game. The armchair Internet game developers focus way too much on components or ECS.

An MMO needs to focus way more on horizontal scalability, load balancing, cluster integrity, security, bandwidth management, patch deployment, telemetry and reporting, billing integration, and server cost/utilization. Those are the hard parts. They will make up _far_ more code and a vasrtly bigger portion of your development time and effort than your game objects or components.

I wouldn't even start thinking about game objects or components until you've got at least the basics of the actual _server_ architecture.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628377
• Total Posts
2982324

• 10
• 9
• 14
• 24
• 11