Thank you for your reply, zyrolasting.
I'll make sure to edit and fix the line that indicates that components own entities, since it's most definately the opposite, which I'm also sure is the impression all readers would sit back with after reading the whole text here.
I understand where you're coming from though, and I also understand that we like to approach defining game objects in two different ways. In fact, the code example I showed:
GameObject *objectRobot = new GameObject(entityManager, zone);objectRobot->AddComponent("Examine");objectRobot->AddComponent("Movement");objectRobot->GetProperty<CL_String>("Description") = "It's a useless robot!";objectRobot->GetProperty<float>("MovementSpeed") = 50.0f;
is only the hardcoded way of defining this robot object, while in fact the whole point with a component-based approach is to make object definition data-driven. Like I said in the text, it wouldn't take a lot of programming effort to allow a designer to define new object types via XML.
<object type="Robot"> <components> <component>Examine</component> <component>Movement</component> </components> <properties> <property name="Description">It's a useless robot!</property> <property name="MovementSpeed">50.0</property> </properties></object>
Imagine how simple it would be to create a flavourish graphical UI that would allow designers to string together components and edit the available properties? No recompilation, no nothing, your designers can define completely new object types 100% outside sourcecode.
Now, it also takes little effort to expose the required functionality to a scripting language, that would allow you to define new component types in script. Now scripters could define new game logic, and immediately test this new logic without ever having to recompile the game.
So, I'm very excited about the possibilities of this approach, because I don't want to shut down the server, recompile the game and run the server again every time I make a change to it's data or it's logic.
I think that every game have different requirements, and for some projects this component-based approach can be a real benefit.
There's a problem with component-based designs, however, and that is that there probably are as many ways to approach it as there are programmers in the world. This is great in some ways, because it makes this a topic of endless discussion. There have been some clear disadvantages with using components, like dependency chains between components (if you're going to use this component, then you have to use this and that, and those components too)... I'm quite excited about the fact that this does not apply to my approach, since there's no dependency between components. Multiple components may have a common data type stored in the Entity that they use, but this is perfectly fine. Just make sure your components react to when it changes...
Another drawback is that you have to iterate over a container of components every time you're updating each entity. This is a sacrifice you'd make for getting the possibilities of the data-driven and modular approach.
Quote:but please note your engine isn't doing anything C++ can't do. We have all the means to declare and define what we want to begin with. If we want a managing object we also write that, as well as any ABCs that can group like objects under a pointer type. Please note one of the LAST things we want to do is to build each and every member of an object one by one each time we want to instantiate it! That's the kind of thing high-level languages hide from us.
You're totaly right. Like I said, my approach is for those who'd like to make object definition data-driven, because they are working on a project where such an approach would save their team time. And you're absolutely right. You don't want to define every single module and give every single property data every single time you're instanciating an object. Like I explained above to my best ability, you do the definition in XML, from there on you'd just want to do something like
entityFactory->Create("Robot");
or more likely, through some scripting language like
entityFactory:Create("Robot")
Certainly my code does not contain this functionality yet, so you're more than right to point this lack of functionality out. But neither does the open source code here give you XML or Scripting support. You could even do a ton of optimization on that codebase if you'd want to.
I'll be updating and improving this code throughout it's life in the project I'm currently working on. When script support arrives, I'll open up that sourcecode too, when XML support arrives I'll open that up too and when we're in the optimization stage, the sourcecode will surely be updated.
Getting through enums/integers instead of strings is certainly a good optimization. We haven't bothered with this yet, since our game hasn't really required it yet. Same thing goes for using std::map instead of a hashmap for instance... I'm also sure we could approach our virtual methods a bit differently, reducing the number of virtuals.
I appreciate your input. The component-based approach seems to always be a source for a lot of discussion and opinions :)