Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Oct 2003
Offline Last Active Aug 01 2014 04:34 PM

Topics I've Started

Component based entity design example

23 August 2012 - 08:09 PM

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:
  • The entity that is a common aggregation of functionality.
  • Components that are individual composable units of functionality.
  • 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.

Component based design - what is state of the art?

24 July 2012 - 03:07 PM

I'm on the record for hating component based programming in current programming languages, but alternatives aren't production ready and I have a problem where it seems well suited:

I have a real life thing that has a number of capabilities/behaviors/features that may or may not be there. Those capabilities are static for each thing, but there are dozens of combinations of capabilities. Currently there are hundreds of capabilities. They're different enough that they can't be nicely abstracted. The biggest problem is that we add a few new capabilities, and 3-5 new combinations every few months; and need those deployed independently enough that it's not a giant mess.

So that's the background. It certainly seems like a good candidate for making the various capabilities into independent components.
We're using C#, but examples in other languages are fine. Mostly I'm wondering what the current state of the art is with component based programming?

Most of the threads here focus on idealistic design, and ignore the practical aspects of component detection, dependency resolution, inter-component communication, and probably a dozen other things I'm not even aware of. Where's info about actual implementations?

Interfaces vs Abstract Classes as a module boundary.

20 July 2012 - 01:03 PM

Yet another debate at work where I am interested in hearing a wider variety of opinions:

When designing a module boundary for C# code and you need to define 'what that module needs to provide so that mine may work', when/how/why should an interface be used and when/how/why should an abstract base class be used?

Again, I will withhold my opinions until there's been sufficient response as to not cause bias.

Interface Tagging?

13 June 2012 - 07:01 PM

I recently had a dispute over the use of empty (or otherwise duplicated) interfaces/abstract classes to 'tag' a class.

What do you guys think? Useful trick or bad practice?

I gave my argument in the context of mainstream languages that can even do this sort of thing (C++/C#/Java), but a wider discussion is fine by me.

RFC: Tangent Programming Language

04 May 2012 - 08:44 AM

Hey everyone. I have gone through and got the specification (doc, html) done to a point where I can (re)start work on it based on firm-ish requirements.

Some of the details around code generation and base framework interoperability are not there; mostly because I need to prototype things to determine what they should be. There's also a smattering of TODOs, but quite a bit of the core idea as well as details are there.

At this point I'm looking for more 'meaty' commentary rather than document critique. I want to know what you think. What do you like? What do you hate? Why?

I understand that the document is lengthy and pretty dry, and cannot express my appreciation for any feedback you can provide. I will look to answer any questions or provide any examples that come up.