• Advertisement
Sign in to follow this  

Unity Component based entity design example

This topic is 1974 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

So I wanted to follow up on [url="http://www.gamedev.net/topic/628509-component-based-design-what-is-state-of-the-art/"]my previous topic[/url] about component based entity design since that thread was... not super helpful for me, despite some attempts. Hopefully this can help others who come along looking for similar implementation details. This is for a non-gamedev project, but many of the basics fit.

Anyways, the implementation is broken into 3 distinct pieces:
[list=1]
[*]The [b]entity[/b] that is a common aggregation of functionality.
[*][b]Components[/b] that are individual composable units of functionality.
[*]And a [b]definition[/b] that is immutable and readonly. It defines what an entity is, and is used by the components to determine if the component is applicable, and if so, what flavor of component to use.
[/list]
The Entity in this design is very, very thin. It contains a definition, and a collection of components. Since the project is in C#, the component store ends up being a private list of dynamic, with public methods to extract typed instances.

[size=5][b]Composition[/b][/size]

This project requires the components be deployable independently of each other. They're more of a plugin at this point than conventional components. To make this work, components are separated into parts. There is a public interface that defines the component, and should be stable over time. And then there is concrete implementation(s), including a factory class for component discovery. There may also be component specific data/assets. The consumer of the entity, as well as other components only ever refer to the DLL having the public interface.

At composition time, the core code uses reflection (project requirements prevent our use of MEF, Unity and a few other IoC containers) to hunt for types that inherit from the common factory interface for component discovery. The Definition is then passed into the factories to spin up instances of all the components (where applicable).

[size=5][b]Dependencies[/b][/size]

[size=4]To get the components to talk to one another, the design calls for dependency injection. A common attribute exists that components can use to tag their fields/properties as a dependency. Once all of the components are created, a second step goes through all of them looking for the attribute. When one is found, it looks for a component instance that inherits from the tagged field/property. If one is found, reflection is used to assign the instance into the other component. They then talk directly to do their communication. [/size]

Reflection is okay here, since we have few actual entities and they're created infrequently. Direct communication is okay too, since our components are pretty tightly coupled (in a business sense) when coupled. They won't live on different threads/machines, so abstracting the communication only leads to unnecessary complexity.


And that's it in the nutshell. We've not actually [i]implemented[/i] too much of it yet, so it might be garbage; we'll see. Hopefully that helps. If anything is unclear, please ask and I'll be happy to elaborate as much as I can.

Share this post


Link to post
Share on other sites
Advertisement
The problem I typically have with the whole "entity/component" concept is that the idea is extremely general, but the specifics of how it can best be implemented [b]will[/b] vary widely based on the exact requirements of each particular project. Put another way, what works well for one design may totally fail to scale in even a slightly different situation.

That said, this sounds reasonable, provided you stick to your original design requirements fairly well and don't get carried away with feature bloat. For example, coupling entities and using reflection for entity creation is fine [i]in many cases[/i] as is use of "dynamic" for holding a "typeless" set of components for later concretization. For a business logic system this sounds like it could be a very good design basis, depending on what you need to do.

For other things, though, I would caution other adventurers who happen across this thread that [b]one size does not fit all[/b]. Entity/component designs are the M theory of software architecture; they're not really "a" design so much as a very, very broad family of possible designs, any number of which might suit the project at hand.

Just as an example, if you write a system that needs to spin up and destroy thousands of entities per second, this probably won't scale. If you need to distribute communication across process boundaries or machine boundaries, the whole thing just may not work. And if you need early-binding type information, you're out of luck entirely. Also, it's worth noting that a lot of this is really only possible as-is in C#; even a similar language like Java would have tremendous difficulty mimicking the way this works.


I don't mean any of this as a negative against your design, mind you; in fact I'd be inclined to believe that it's very well suited for what you want to accomplish. I just worry when people see a well-thought-out architecture based on components and immediately think that it will transfer en masse directly into their totally unrelated problem space.

Share this post


Link to post
Share on other sites
Absolutely. I perhaps should have made that more clear. I tried to list some of the requirements that impacted design decisions. The main ones off the top of my head are:
[list]
[*]We only make a few entities.
[*]Those entities tend to be long lived.
[*]The entities at most talk to one other entity.
[*]The definition of an entity is constant over the duration of the program.
[*]The mapping from definition to component is constant over the lifetime of the entity.
[*]Components aren't doing much constant work.
[*]Component communication is infrequent, but blocks operations until it completes (usually).
[*]Components cannot for business reasons be distributed.
[/list]
Really, if any of these change then the design will probably change to better accomodate things. But ideally people can look at this, think about how it doesn't fit with their needs and adapt (or discard!) it as necessary.

Share this post


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

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By RoKabium Games
      Custom coffee mugs have arrived... More caffeine!
      Have a great weekend everyone! 
      #gamedev #indiedev #sama #caffeine
    • By Atwo Studios
       
      Hey guys,

      Anthony here from Atwo Studios bringing you some new updates for the new year!
      In this video I go over our game ROY, the new games and some general updates to the company!

      If you have not checked out ROY feel free to give it a try! Many people have said they enjoyed the game thus far!
      ROY: https://goo.gl/o6JJ5P
       
    • By Affgoo
      https://play.google.com/store/apps/details?id=com.NE.Alien
      still a lot of work to do, but its pretty stable  please let me know what you think <3
      Atlas Sentry is a game of destroy everything. Using your turret, simply swivel and shoot your way to victory, upgrading your weapons to unleash destruction on the variety of spaceships. The bigger your combo’s the more score you get! Earn silver as you play and then purchase new weapons and abilities to better deal with your enemy. Different enemies use different tactics and weapons, work out your own priorities in their destruction order. 

      Features: 
      **2 different game modes 
      **A level select mode with 20 difficult levels including a final boss, can you defeat it? **Arcade mode of endless destruction, how long will you last? 
      **High scores to compete against others, see who can take the top spot. 
       
    • By Chamferbox
      Chamferbox, a mini game asset store has just opened with some nice game assets, 
      Here you can find a free greek statue asset 

      Also check their dragon, zombie dragon and scorpion monster out:



      They're running the Grand Opening Sale, it's 30% off for all items, but for gamedev member, you can use this coupon code:
      GRANDOPEN
      to get 50% off prices What are you waiting for, go to
      http://chamferbox.com
      and get those models now!

      View full story
    • By Dafu
      FES Retro Game Framework is now available on the Unity Asset Store for your kind consideration!
      FES was born when I set out to start a retro pixel game project. I was looking around for an engine to try next. I tried a number of things, from GameMaker, to Fantasy Consoles, to MonoGame and Godot and then ended up back at Unity. Unity is just unbeatable in it's cross-platform support, and ease of deployment, but it sure as heck gets in the way of proper retro pixel games!
      So I poured over the Unity pipeline and found the lowest levels I could tie into and bring up a new retro game engine inside of Unity, but with a completely different source-code-only, classic game-loop retro blitting and bleeping API. Months of polishing and tweaking later I ended up with FES.
      Some FES features:
      Pixel perfect rendering RGB and Indexed color mode, with palette swapping support Primitive shape rendering, lines, rectangles, ellipses, pixels Multi-layered tilemaps with TMX file support Offscreen rendering Text rendering, with text alignment, overflow settings, and custom pixel font support Clipping Sound and Music APIs Simplified Input handling Wide pixel support (think Atari 2600) Post processing and transition effects, such as scanlines, screen wipes, screen shake, fade, pixelate and more Deploy to all Unity supported platforms I've put in lots of hours into a very detail documentation, you can flip through it here to get an better glimpse at the features and general overview: http://www.pixeltrollgames.com/fes/docs/index.html
      FES is carefully designed and well optimized (see live stress test demo below). Internally it uses batching, it chunks tilemaps, is careful about memory allocations, and tries to be smart about any heavy operations.
      Please have a quick look at the screenshots and live demos below and let me know what you think! I'd love to hear some opinions, feedback and questions!
      I hope I've tickled your retro feels!



      More images at: https://imgur.com/a/LFMAc
      Live demo feature reel: https://simmer.io/@Dafu/fes
      Live blitting stress test: https://simmer.io/@Dafu/fes-drawstress
      Unity Asset Store: https://www.assetstore.unity3d.com/#!/content/102064

      View full story
  • Advertisement