Sign in to follow this  
Tristan Patrick Richter

Entity Component System

Recommended Posts

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 this post


Link to post
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 this post


Link to post
Share on other sites

Sean, what's your take on this versus a traditional ECS?


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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this