• Advertisement
Sign in to follow this  

Unity Component Based Architectures

This topic is 3578 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Inspirations for this post: Component Based Game Architectures - GDNet Post Outboard component-based entity system architecture - GDNet post Object Oriented Game Programming: The Behavior System 301: Introduction to Dungeon Siege Architecture Various Bilas presentations Some stuff written by Jeremy Chatalaine So, now to begin with the actual post. :-) I'm toying around with writing a purely component-based architecture, perhaps making something crazy data driven, and I was wondering what other people were doing here. I haven't read the GPGems articles on the topic, so I'm probably missing some details, but I'm grabbing everything I can find online. My knee-jerk idea was to create one master "GameObject" class which consisted of a list (or map, more technically) of components and never subclass that, simply define various schemas via XML or some other mechanism. Communication between components would either be done via a signal/slot mechanism or by providing a QueryInterface in the GameObject class such that a component could search for another component if it wanted that information. Signal/slot seems cleaner design-wise, but QueryInterface seems more compact. For instance, if something needed a Position component (hypothetical example - something so granular may not be a good candidate for its own component) to do its rendering at the right location, with the signal/slot mechanism the new position would have to be stored until needed, whereas with the QueryInterface it could just be used and discarded on demand. That was the knee-jerk reaction, of course, and it left me with all sorts of questions about how certain things would be handled. For instance, what happens when game objects need to know about each other (when pathfinding, for instance)? It seems like the common way is to have some master database and run queries on that database to find entities with the appropriate components? Further, what do I do about entities that should be added to the scene graph versus those that shouldn't? Upon creation of the entity, should the scene graph check its components and add it as necessary? I think I'm missing some key piece here. What about entity-specific behaviors? A person with a bow attacks differently than a person with a sword or gun, hence a general 'Attack' component doesn't seem practical. Is this where different kinds of Attack components (Attack_Sword, Attack_Gun) come into play, or is this where subclassing becomes the only pragmatic possibility? So it seems like having one master GameObject class is a little impractical, and that I'll be forced to throw in game-specific code, which is not necessarily a bad thing of course. I wonder about things like managing a bunch of interacting entities (for instance, parts of a window in a GUI). It seems like if I fit some scripting solution in, game-specific code would turn into scripted code, which may be ideal. So, again, I was wondering how other people were implementing their solutions. I realize right now that I'm trying to treat component-based design as a golden hammer or magic bullet, so where are you guys drawing the line? Or are you even using this at all? Cheers, --Brian

Share this post


Link to post
Share on other sites
Advertisement
Quote:
That was the knee-jerk reaction, of course, and it left me with all sorts of questions about how certain things would be handled. For instance, what happens when game objects need to know about each other (when pathfinding, for instance)? It seems like the common way is to have some master database and run queries on that database to find entities with the appropriate components? Further, what do I do about entities that should be added to the scene graph versus those that shouldn't? Upon creation of the entity, should the scene graph check its components and add it as necessary? I think I'm missing some key piece here.
I've laid out my thoughts on this in a couple of the threads you linked, so I'll abstain from these questions.

Quote:
What about entity-specific behaviors? A person with a bow attacks differently than a person with a sword or gun, hence a general 'Attack' component doesn't seem practical. Is this where different kinds of Attack components (Attack_Sword, Attack_Gun) come into play, or is this where subclassing becomes the only pragmatic possibility?

Compare these two situations:

class FooBase {
public:
virtual int exec() = 0;
};

class FooOne : public FooBase{
public:
virtual int exec() { return 1; }
};

class FooTwo : public FooBase{
public:
virtual int exec() { return 1; }
};



class Foo {
public:
Foo(int i) { m_i = i; }
int exec() { return m_i; }
private:
int m_i;
};


It's pretty clear which one of these approaches is clear and elegant, and which one is rigid and overly verbose. But the situation can go the other way:


class FooBase {
public:
virtual int exec(int a, int b) = 0;
};

class FooAdd : public FooBase{
public:
virtual int exec(int a, int b) { return a+b; }
};

class FooSub : public FooBase{
public:
virtual int exec(int a, int b) { return a-b; }
};



enum Operation { OPERATION_ADD, OPERATION_SUB };

class Foo {
public:
Foo(Operation o) { m_o = o; }
int exec() {
switch(m_o) {
case OPERATION_ADD: return a+b;
case OPERATION_SUB: return a-b;
default: assert(false);
}
private:
Operation m_o;
};


Here, denying the fundamental difference between the two operations leads to less readable, less trackable code. So there's no easy answers, except "try it out, and if it doesn't work out, try it the other way". As you get more accomplished, you'll learn to get it right the first time most of the time, but at least for now you'll get it right the second time.

One dimension, however, that does have a simple answer, is that this sort of subclassing should be confined as tightly as possible. See the strategy pattern for more details on this.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
I've laid out my thoughts on this in a couple of the threads you linked, so I'll abstain from these questions.


Ah, so you do. Very first post in that second link, as it turns out. I think I managed to interpret a large portion of the discussion as pertaining to inter-component communication, and by the time I'd hit the end I'd forgotten all about that first bit.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Tags

  • Advertisement
  • Popular Now

  • Similar Content

    • By Manuel Berger
      Hello fellow devs!
      Once again I started working on an 2D adventure game and right now I'm doing the character-movement/animation. I'm not a big math guy and I was happy about my solution, but soon I realized that it's flawed.
      My player has 5 walking-animations, mirrored for the left side: up, upright, right, downright, down. With the atan2 function I get the angle between player and destination. To get an index from 0 to 4, I divide PI by 5 and see how many times it goes into the player-destination angle.

      In Pseudo-Code:
      angle = atan2(destination.x - player.x, destination.y - player.y) //swapped y and x to get mirrored angle around the y axis
      index = (int) (angle / (PI / 5));
      PlayAnimation(index); //0 = up, 1 = up_right, 2 = right, 3 = down_right, 4 = down

      Besides the fact that when angle is equal to PI it produces an index of 5, this works like a charm. Or at least I thought so at first. When I tested it, I realized that the up and down animation is playing more often than the others, which is pretty logical, since they have double the angle.

      What I'm trying to achieve is something like this, but with equal angles, so that up and down has the same range as all other directions.

      I can't get my head around it. Any suggestions? Is the whole approach doomed?

      Thank you in advance for any input!
       
    • By khawk
      Watch the latest from Unity.
       
    • By GytisDev
      Hello,
      without going into any details I am looking for any articles or blogs or advice about city building and RTS games in general. I tried to search for these on my own, but would like to see your input also. I want to make a very simple version of a game like Banished or Kingdoms and Castles,  where I would be able to place like two types of buildings, make farms and cut trees for resources while controlling a single worker. I have some problem understanding how these games works in the back-end: how various data can be stored about the map and objects, how grids works, implementing work system (like a little cube (human) walks to a tree and cuts it) and so on. I am also pretty confident in my programming capabilities for such a game. Sorry if I make any mistakes, English is not my native language.
      Thank you in advance.
    • By Ovicior
      Hey,
      So I'm currently working on a rogue-like top-down game that features melee combat. Getting basic weapon stats like power, weight, and range is not a problem. I am, however, having a problem with coming up with a flexible and dynamic system to allow me to quickly create unique effects for the weapons. I want to essentially create a sort of API that is called when appropriate and gives whatever information is necessary (For example, I could opt to use methods called OnPlayerHit() or IfPlayerBleeding() to implement behavior for each weapon). The issue is, I've never actually made a system as flexible as this.
      My current idea is to make a base abstract weapon class, and then have calls to all the methods when appropriate in there (OnPlayerHit() would be called whenever the player's health is subtracted from, for example). This would involve creating a sub-class for every weapon type and overriding each method to make sure the behavior works appropriately. This does not feel very efficient or clean at all. I was thinking of using interfaces to allow for the implementation of whatever "event" is needed (such as having an interface for OnPlayerAttack(), which would force the creation of a method that is called whenever the player attacks something).
       
      Here's a couple unique weapon ideas I have:
      Explosion sword: Create explosion in attack direction.
      Cold sword: Chance to freeze enemies when they are hit.
      Electric sword: On attack, electricity chains damage to nearby enemies.
       
      I'm basically trying to create a sort of API that'll allow me to easily inherit from a base weapon class and add additional behaviors somehow. One thing to know is that I'm on Unity, and swapping the weapon object's weapon component whenever the weapon changes is not at all a good idea. I need some way to contain all this varying data in one Unity component that can contain a Weapon field to hold all this data. Any ideas?
       
      I'm currently considering having a WeaponController class that can contain a Weapon class, which calls all the methods I use to create unique effects in the weapon (Such as OnPlayerAttack()) when appropriate.
  • Advertisement