• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Pixelated_Nate
      Hello all!
      I'm currently designing a 2D, Puzzle/Action RPG, in a similar vein to Legend of Zelda: Link to The Past, in Unity and require a Programmer partner in which to work with me.
      The project, yet to be titled, will feature:
      A semi-open world, represented through pixel art, in which the player traverses to enter dungeons and advance the story. A handful of side-quests that require memorizing details and using puzzle-mechanics. A fast-paced, melee combat system that will include dodging, blocking and utilizing four different attack types that can be switched on the fly. A simple inventory of "Key Items" to be used in order to advance the story. Day & Night system and Weather Effects, with weather effecting combat.  A very simple Dialogue System to convey information via colored text. Saving/Loading via exporting and importing a physical save file. Majority of the project is already planned out, with plans to release commercially and splitting the profits equally among the two of us. 
      I would request that the applicant is able to work semi-independently, following an outline, and that they have experience in both C# programming  *and* putting those scripts to use inside Unity, whilst I will be creating the Art, Music/SFX and doing Level Design (Though if you are also comfortable in assisting me with these, I wouldn't be opposed.).
      Work will be shared in either Github or Unity Collab (Applicants preference), with communication done via Discord. 
      For more information and to apply, please contact me at nathan.jenkins1012@gmail.com
      Thanks for reading! 
    • By Just4lol
      I'm looking for my dream teammate(s) to help me work on my Unity game. I still dont know where Im going with that project but I want to make a good final product that I would be able to sell or publish it for free on Steam.  Here a video of the prototype (The only thing I dint made is the skybox) https://www.youtube.com/watch?v=y2Otmt9jRkc
      My discord : Just4lol#46982
      I want somone at least as competent as me : 
      - I want somone with at least one year of experience in Unity (already worked with scriptable object and know oop).
      - Already worked with shaders or can do editors tools is a plus.
      - Can do 3d models in Blender or can do 2d art for the ui or particles effects.
      - Can make soundtracks or sound effects a bonus.
      Im a french Canadian so mind my english I will do my best to edit any errors I see. 
    • By Damnwing0405
      I am looking for talents to form a team of making a strategy base action game. Talents I am currently looking for are : -
      (I) Unity programmer (mobile)
      (II) Game designer
      (III) 3d Artist
      (IV) SFX Artist
      The attachment is some game concept for the game. All the concept will be turn into 3d or card form. The game will be strategy game where the players can form their own team and control the units in the battle field real time to fight against each others.  If you are interested to know more details please pm me or send an email to damnwing0405@gmail.com

    • By bsudheer
      Leap Leap Leap! is a fast-paced, endless running game where you leap from rooftop to rooftop in a computer simulated world.

      This is a free run game and get excited by this fabulous computer simulated world of skyscrapers and surreal colors in parallax effect. On your way, collect cubes and revival points as many as you can to make a long run.

      Features of Leap Leap Leap:
      -Option of two themes: Black or White.
      -Simple one touch gameplay.
      -Attractive art.
      -Effective use of parallax.
      To Download the game:
      Playstore: https://play.google.com/store/apps/details?id=com.avakaigames.leap
      Appstore: https://itunes.apple.com/us/app/leap-leap-leap/id683764406?mt=8

    • By BillyGD

      Play Flick Football 3D @ https://gamejolt.com/games/flickfootball3d/326078
      Check out our Facebook page @ https://www.facebook.com/FlickFootball3D/
      Flick Football 3D is a turn based football game inspired by the table top classic 'Subbuteo'.
      The game is currently in very early Alpha development. There is still a lot to be done before the first proper release but I have decided to release this playable version to get as much feedback as possible.
      The only game mode currently available in this release is the 'Practice Mode' which gives you control of both teams. Either play against yourself to get used to how the game works or play against friends and family on the same computer!
      Planned Future Features Include:
      -Take control of your own custom team in the single player campaign.
      -Play in online leagues and tournaments against other players in the multiplayer mode.
      -Fully customisable stadiums to make you stand out from the rest of the players.
      -Improve your players stats and skills by playing matches and setting up training sessions.
      Flick Football 3D is available for Windows, Mac and Browser.
      Thank you for viewing my game, all feedback is greatly appreciated. I can be contacted at; BillyGDev@outlook.com
      'Flick Football 3D' is also the development name for the game and I haven't yet decided what the full release will be called, so if you have any ideas please drop me a message!
  • Advertisement
  • Advertisement
Sign in to follow this  

Unity Component based entity design example

This topic is 2038 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 my previous topic 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:

  1. The entity that is a common aggregation of functionality.
  2. Components that are individual composable units of functionality.
  3. And a definition 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.

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.


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).


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.

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 implemented 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
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 will 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 in many cases 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 one size does not fit all. 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:

  • 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.

    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