I've read some about component-based game design but am still having some trouble figure out how exactly you'd go about implementing it. Are there any good examples of component-based games or game engines that I could read through to get a better feel for this?
Personally I don't think there are any good examples, largely because the definition of a "component-based system" for games is so loosely defined that it can mean next to nothing. You might find some of the discussion in this answer helpful: How to implement a component based system for items in a web game. On the whole though, the approach is simply to change any sort of GameObject or Actor from a large class that handles all behaviour into a simpler class that holds objects that perform behaviour. I think that working through this yourself and making different components that suit your game will often be the best way to proceed. |
|||||
|
Here are some resources you may like: To answer the original question, the Elephant framework in C# is precisely what you want: it has been discontinued, but still exists here for reference of implementation. |
|||
|
This site starts into a basic implementation. Most of the above is inspired by this article at T=Machine I started into a basic implementation inspired by the above two links. I'm pretty sure I've deviated a lot from the pure theory of component systems, and there undoubtedly bugs, but it might prove useful if you're looking for some simple examples. Bricle (C#/XNA) Right now it's just loading up some basic entities, handles some events, etc. The main locations you're looking for are the Engine.EntitySystem folder and probably the PlayScreen where entities are actually created. Creating a simple type-based component store and hiding that behind a common EntityManager was relatively straight forward. The first challenge I ran into was when individual systems might require multiple component types (ie, Physical components and InputMoveable). To use the relational database language, I had to find a way to do a JOIN query. For that, I made another collection type for entities built from the matching component type queries - each entity collection hooks into an OnEntityCreate event and checks if it matches. Still some bugs there. The second challenge was actually creating a 'game object' - I called them templates. Here I'm probably not very pure according to T=Machine's specs, but it seems to work. Templates group together component instantiations and allow easier entity composition (ie, the Ball is Drawable and Physical). Hope that's helpful - entity/component systems can be a challenge to get through some of the initial hurdles. |
||||
|
Another one, I haven't used, but looked through the code a bit, is Artemis. Well commented and quite active. Originally a Java framework but has been ported to C#/XNA. |
|||
|