Component Based Objects?

KungFooMasta · Post by **KungFooMasta** » Thu Sep 17, 2009 6:03 am

Ok I guess I"ll share mine too. Its far from finished and the art is just for prototyping the game.

I'm using my version of a component based system, and I love it. In essence, it allows me to write lots of modular pieces of functionality and put them together in different ways. Easy organization and easy to let other people join my project. (Althought I only have 1 other person on the team, haha)

mirlix · Post by **mirlix** » Thu Sep 17, 2009 8:10 am

It seems everybody is still working on component system

.
Here is a screen shot of my university project which uses a component system.

My main focus is that the complete game can be described using XML. Below is the XML file for the game. How do you describe your game, in code, with scripts with xml?

Code: Select all

<!DOCTYPE Game>
<Game>
	<Packages>
		<game_d.dll/>
		<renderer_ogre_d.dll/>
	</Packages>
	
	<ComponentOwners>
		<ComponentOwner type="Player">
			<Model name="PlayerModel">
				<Parameters>
					<Modelfile type="String">stone.mesh</Modelfile>
				</Parameters>
			</Model>
			<Camera_3rdPerson name="PlayerCamera">
			</Camera_3rdPerson>
			<PlayerControl name="PlayerController">
			</PlayerControl>
		</ComponentOwner>
		
		<ComponentOwner type="Monster">
			<Model name="MonsterModel">
				<Parameters>
					<Modelfile type="String">monster3.mesh</Modelfile>
				</Parameters>
			</Model>
			<MonsterControl name="MonsterController">
			</MonsterControl>
		</ComponentOwner>
		
		<ComponentOwner type="Gameworld">
			<Gameloop name="Worldloop">
			</Gameloop>
			<Model name="Worldmodel">
				<Parameters>
					<Modelfile type="String">level1.mesh</Modelfile>
				</Parameters>
			</Model>
		</ComponentOwner>
		
		<ComponentOwner type="WorldLight">
			<Light name="Light1">
				<Parameters>
					<Position type="Vector3">0,0,0</Position>
				</Parameters>
			</Light>
			<Model name="Lightmodel">
				<Parameters>
					<Modelfile type="String">stone.mesh</Modelfile>
				</Parameters>
			</Model>
			
		</ComponentOwner>
	</ComponentOwners>
	
	<Instances>
		<Player name="Player1">
		</Player>
		<Monster name="Monster1">
		</Monster>
		<Gameworld name="Level1">
		</Gameworld>
		<WorldLight name="Light1">
			<Position type="Vector3">0,5,0</Position>
		</WorldLight>
	</Instances>

</Game>

oddrose · Post by **oddrose** » Thu Sep 17, 2009 11:36 am

I'm planning to use a binary scene-format and create an editor for the engine. So I won't use XML for that. Functionality is mostly defined in script since it is easiest to define new component types in scripts. I use some XML though, for storing key-bindings for example. I see that you litteraly mean the entire game in XML when you even load your dlls from there. I plan to set these things in the editor too so I'll have both scene and game configuration stored in binary format or in scripts.

mirlix · Post by **mirlix** » Thu Sep 17, 2009 12:32 pm

The only thing that isnt stored in xml are new components, these have to be defined in an dll/so and then loaded in xml or later you can use pythons scripts, but I haven't started the binding yet, hopefully after this semester I can start. Im also planning on using an editor, but right now we have a deadline to meet and my artists needed a relative easy way to define levels and an editor would have been to much work, so xml it was.

oddrose · Post by **oddrose** » Thu Sep 17, 2009 1:22 pm

Hey, it's great that you have a deadline! I don't, and therefore I can dream up whatever engine I want, but end up doing nothing. That's why I started creating the volleyball game to have something that needs the engine to have certain features.

mirlix · Post by **mirlix** » Thu Sep 17, 2009 1:26 pm

Its great, but it also means that I cant implement everything which would be needed. Its a simple tradeoff and after the project I have a long list of new features I want to implement. I hope that I can show a video of my first component oriented game at the forth of october.

KungFooMasta · Post by **KungFooMasta** » Thu Sep 17, 2009 6:29 pm

Nice screenshot! mirlix, I noticed the objects in the scene are at various positions, yet the xml doesn't set any positions except for a light. Or maybe we just saw a small snippet of the XML?

Its definately a task making everything data driven, but worthwhile. I'm using a script-like syntax I made up, similar to the Ogre material syntax. (except I don't really have any keywords, just Script Definitions and Definition Properties, and the code takes the data and makes use of it)

for example:

Code: Select all

UnitData Iron_Golem
{
	DisplayName Iron Golem
	Description ...
	DamageBase 30
	DamageVariance 3
	Armor 2 
	AttackRange 1.5 
	Strength 19 
	Agility 19 
	Intelligence 15
	IconSkinType IronGolemIcon
	Mesh Iron_Golem.mesh
	RightClickMove RightClickUnit
}

mirlix · Post by **mirlix** » Thu Sep 17, 2009 6:40 pm

The screenshot is already some days old and im changing my xml layout to right now one of the balls is missing in the xml which is in the screenshot, but you can see how you can modify the position in the xml, take a look at the WorldLigth, there the position get changed.
Couldnt post an up to date screenshot, because I was at work and they dont like it wenn I bring my hobby game to work ^^.

Edit: I will post a new screenshot shortly, just have to finish my university project first. We have to submit some documents today.

Edit2: Here a brand new pictures and the xml file for this game. Also added some new features today

Code: Select all

<!DOCTYPE Game>
<Game>
	<Packages>
		<game_d.dll/>
		<renderer_ogre_d.dll/>
	</Packages>
	
	<ComponentOwners>
		<ComponentOwner type="Player">
			<Model name="PlayerModel">
				<Parameters>
					<Modelfile type="String">sphere.mesh</Modelfile>
				</Parameters>
			</Model>
			<Camera_3rdPerson name="PlayerCamera">
			</Camera_3rdPerson>
			<PlayerControl name="PlayerController">
			</PlayerControl>
		</ComponentOwner>
		
		<ComponentOwner type="Monster">
			<Model name="MonsterModel">
				<Parameters>
					<Modelfile type="String">monster3.mesh</Modelfile>
				</Parameters>
			</Model>
			<MonsterControl name="MonsterController">
			</MonsterControl>
		</ComponentOwner>
		
		<ComponentOwner type="Gameworld">
			<Gameloop name="Worldloop">
			</Gameloop>
			<Model name="Worldmodel">
				<Parameters>
					<Modelfile type="String">level1.mesh</Modelfile>
				</Parameters>
			</Model>
		</ComponentOwner>
		
		<ComponentOwner type="WorldLight">
			<Light name="Light1">

			</Light>
			<Model name="Lightmodel">
				<Parameters>
					<Modelfile type="String">stone.mesh</Modelfile>
				</Parameters>
			</Model>

			
		</ComponentOwner>
		
		<ComponentOwner type="Switch">
			<Model name="Switchmodel">
				<Parameters>
					<Modelfile type="String">schalter_basis.mesh</Modelfile>
					<Position type="Vector3">50,5,0</Position>
				</Parameters>
			</Model>
			<SwitchControl name="SwitchController">
			</SwitchControl>
		</ComponentOwner>
		
		<ComponentOwner type="Gate">
			<Model name="Gatemodel">
				<Parameters>
					<Modelfile type="String">stone.mesh</Modelfile>
					<Position type="Vector3">-50,5,0</Position>
				</Parameters>
			</Model>
			<GateControl name="GateController">
			<Parameters>
					<Modelfile type="String">stone.mesh</Modelfile>
					<Position type="Vector3">-50,5,0</Position>
				</Parameters>
			</GateControl>
		</ComponentOwner>
		
		
	</ComponentOwners>
	
	
	<Instances>
		<Player name="Player1">
		</Player>
		<Monster name="Monster1">
		</Monster>
		<Switch name="Switch1">
			<SwitchController>
				<Position type="Vector3">-50,0,0</Position>
			</SwitchController>
			<Switchmodel>
					<Position type="Vector3">-50,0,0</Position>
			</Switchmodel>
		</Switch>
		
		<Gate name="Gate1">
			<GateController>
				<Switches type="ListOfString">Switch1</Switches>
				<Position type="Vector3">50,0,0</Position>
			</GateController>
			<Gatemodel>
					<Position type="Vector3">50,0,0</Position>
			</Gatemodel>
		</Gate>
		
		<Gameworld name="Level1">
		</Gameworld>
		<WorldLight name="Light1">
				<Lightmodel>
					<Position type="Vector3">0,5,0</Position>
				</Lightmodel>
				<Light1>
					<Position type="Vector3">0,5,0</Position>
				</Light1>
		</WorldLight>
	</Instances>

</Game>

oddrose · Post by **oddrose** » Sat Sep 19, 2009 10:20 pm

gotta love "<!DOCTYPE Game>" =)

I like that the game description is very readable because of the xml. I wonder though, why surround parameters with <parameter> tags?

mirlix · Post by **mirlix** » Sat Sep 19, 2009 11:43 pm

No special reason, I think I once just wrote it this way, if you look at the instances block, there arent parameter tags. One more thing to change, thanks for the tip. Sometimes old thing just survive way to long

Samuel033 · Post by **Samuel033** » Sat Sep 26, 2009 9:31 pm

I dont mind saying this is the hardest thing I have ever had to wrap my head around. I havent read through every single post in this thread... yet. On the surface the concepts seem relatively straight forward but making it work is not. In its basic terms it sounds like making all necessary components, registering them in a list within each particular game object, and iterating through the list. Or making copies of a single template list with all component names in the correct order and setting them 'yes' or 'no' in deciding if/when to call them. And then keeping the relevant variables someplace. There are certainly more complicated variations for more complex needs but does this sound about right for a simple 'starter' system to get things going?

mirlix · Post by **mirlix** » Sat Sep 26, 2009 9:40 pm

I think there are some details missing in your system, so it would be hard to decide if it will work or not. Maybe you could describe it in more detail for us?

Samuel033 · Post by **Samuel033** » Sat Sep 26, 2009 11:27 pm

That doesnt surprise me

There isnt much to show yet and its all in my head. Suppose for a basic example there are 2 enemies. One is smart and one is nothing more than a space mine. The first needs to fight and the other just needs to sit there. Both start off with the same basic GO class. They need position components so new instances (instance?) are created for each and pointers + IDstrings to them are assigned to the first position in their respective lists. component* = new positioncomponent() or something like that, syntax aside... then GameObject[something].addtolist(component*, "gocID_Position"). At least in reading thats a common procedure I tend to see.

The smart enemy also needs to move so it has another new component pointer + ID added to its own list using new+addtolist. Then both need different new behavior components. The space mine is very simple with just a proximity alert. The other is obviously much more complex. As before pointers to the new components are added to the next slots on their lists.

In the end the space mine component list has pointers to two. The other has three. Each will iterate through whatever is in its list and call the respective functions.

mirlix · Post by **mirlix** » Sat Sep 26, 2009 11:49 pm

This seems like a sensible approach for such a system. I think it will be a good starting point for further improvements and experiments

kraj0t · Post by **kraj0t** » Sun Sep 27, 2009 12:16 am

The BEST advice I could give you is:

www.unity3d.com

Just go there, get the trial version, install it. Then watch some tutorial videos, download the 3d platformer example... and you'll realise you suddenly understand A LOT about component systems. This will help you so much when you start your implementing your own system.

ps: I don't work at Unity, but that engine simply rocks :-]

mirlix · Post by **mirlix** » Sun Sep 27, 2009 12:37 am

Thats interesting, it kind of a component system, but I think one could make a lot more of it. Tomorrow I will install the trail version to take a closer look, my laptop seems to have to few texture units. But its good to know that the basic idea is working in a commercial product

Samuel033 · Post by **Samuel033** » Wed Sep 30, 2009 5:28 am

Thx.

Still working through all 25 pages of posts and as always it sounds like there are many ways to do this kind of system.

savuporo · Post by **savuporo** » Fri Nov 13, 2009 6:13 am

Two links on the subject, that seem not to have come up before
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=35666

And this is not directly component based, but its a skeleton MVC entity system which could easily incorporate components ( actually refactoring couple of already existing bits into components as well )
http://www.gamasutra.com/features/20050 ... e_02.shtml

Post by **jacmoe** » Fri Nov 13, 2009 6:33 am

savuporo wrote:Two links on the subject, that seem not to have come up before
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=35666

It came up three times, IIRC.

I posted a link to it on one of the first pages of this topic, and Trefall posted a link to his updated version not too long ago.
But thanks anyway. His work and his topic is awesome.

Trefall · Post by **Trefall** » Sat Nov 14, 2009 12:26 am

Hehe, you make me feel like a rockstar jacmoe

There's been some more talk on using properties with components over at GameDev:
http://www.gamedev.net/community/forums ... _id=551515
http://www.gamedev.net/community/forums ... ?jn=397730

savuporo · Post by **savuporo** » Sat Nov 14, 2009 1:47 am

i would support the rockstar label

I just pulled the model that you have into BOUML editor ( c++ mode, rev engineer ) swapped out CL_String, CL_Event primitives and couple other tidbits, created a couple diagrams, and regenerated compilable C++ code for the framework using different primitives in couple hours.
( namespace EntityEngine { typedef whateverstring String }; seems like a good idea , same for the SharedPtr and Signal to make it easy to experiment with without ClanLib )

Diagram attached

Trefall · Post by **Trefall** » Sat Nov 14, 2009 3:26 pm

Oh, that's really cool savuporo!

I'm aware of the issue with clanlib dependencies, which I'm sure puts off some people. I always intended it more as a suggested way of doing components than to actually be a plug and play component engine, but I've wanted to make the opensource version more user friendly with regards to that, among other things... I'm sure I'll get around to it some day.

Just commited a fairly large update to the component system. It breaks backwards compatibility, but holds a lot of cleanup and also adds a type serializer, written by Kenneth Gangstø aka Sphair, which I'm doing this component system with (we use it in our game project). It gets rid of the PropertyManager and EntityManager, so updating over properties now goes through your game object (was done over the PropertyManager before). EntityManager wasn't doing much, so no reason to keep it in there.

Trefall · Post by **Trefall** » Sat Nov 14, 2009 4:26 pm

Commited typedefs over CL_ types now, but couldn't get it working with templated types, even using the trick

Code: Select all

template<typename T>
struct T_Vector
{
     typedef std::vector<T> type;   
};

T_Vector<someType>::type someType;

If someone could get it to work like that, I'd be happy to add it in.

savuporo · Post by **savuporo** » Sat Nov 14, 2009 10:31 pm

Here's a patch that makes it compile without clanlib, it wont immediately link as SharedPtr and signal classes are just stubs. It should be easy to substitute POCO or Boost or QT or GTKMM or anything into it from here.
Only tested on VS2005 for now, not sure if it will immediately work with GCC

arggh ... cant attach diff/patch/txt files .. so 'ill copy-paste it inline

Code: Select all

Index: precomp.h
===================================================================
--- precomp.h	(revision 107)
+++ precomp.h	(working copy)
@@ -26,13 +26,16 @@
 #include <vector>
 #include <map>
 
-#include <ClanLib/core.h>
+#ifdef CLANLIB_TYPES
+#include "types_clanlib.h"
+#endif
 
-namespace EntityEngine
-{
-	typedef CL_String T_String;
-	typedef CL_StringHelp T_StringHelp;
-	typedef CL_TempString T_TempString;
-	typedef CL_Pointf T_Pointf;
-	typedef CL_Exception T_Exception;
-}
+#ifdef MY_TYPES
+#include "types_my.h"
+#endif
+
+#ifdef POCO_TYPES
+#include "types_poco.h"
+#endif
+
+
Index: Property.h
===================================================================
--- Property.h	(revision 107)
+++ Property.h	(working copy)
@@ -35,7 +35,8 @@
 	T value;
 	T_String name;
 	bool dirty;
-	CL_Signal_v2<const T&, const T&> valueChanged;
+//	typename T_Signal_v2<const T&, const T&>::Type valueChanged;
+	typename T_Signal_v2<const T , const T >::Type valueChanged;
 };
 
 template<class T>
@@ -75,7 +76,7 @@
 
 	virtual const T_String &GetName() const { return data->name; }
 
-	virtual bool IsNull() const { return data == NULL; }
+	virtual bool IsNull() const { return data == (PropertyData<T> *) NULL; } //cast to resolve operator ambiguity
 
 	virtual bool IsDirty() const { return data->dirty; }
 	virtual void ClearDirty() { data->dirty = false; }
@@ -84,7 +85,7 @@
 	virtual void SetFromString(const T_String &value) { TypeSerializer::FromString(value, data->value); }
 	virtual int GetTypeId() const { return TypeSerializer::GetTypeId(data->value); }
 
-	CL_Signal_v2<const T&, const T&> &ValueChanged() { return data->valueChanged; }
+	typename T_Signal_v2<const T, const T>::Type &ValueChanged() { return data->valueChanged; }
 
 	Property<T> operator= (const Property<T>& rhs);
 	Property<T> operator= (const T& rhs);
@@ -110,7 +111,7 @@
 	operator T() const { return data->value; }
 
 private:
-	CL_SharedPtr< PropertyData<T> > data;
+	typename T_SharedPtr< PropertyData<T> >::Type data;
 };
 
 template<class T>
Index: PropertyContainer.h
===================================================================
--- PropertyContainer.h	(revision 107)
+++ PropertyContainer.h	(working copy)
@@ -53,7 +53,7 @@
 	std::vector<IProperty*> &GetDeletedProperties() { return deletedProperties; }
 
 	void UpdateProperties(int deltaTime);
-	CL_Signal_v1<int> SigUpdateProperties;
+	T_Signal_v1<int>::Type SigUpdateProperties;
 
 protected:
 	void ClearDirtyProperties();
Index: testEntities.cpp
===================================================================
--- testEntities.cpp	(revision 0)
+++ testEntities.cpp	(revision 0)
@@ -0,0 +1,57 @@
+#include "precomp.h"
+#include "Property.h"
+#include "Entity.h"
+#include "Component.h"
+#include "Poco/Delegate.h"
+
+#include <iostream>
+
+class healthComponent : public EntityEngine::Component {
+public:
+	healthComponent(EntityEngine::Entity* entity, const T_String &name) : 
+		EntityEngine::Component(entity,name) {
+			AddProperty("life",0);
+			AddProperty("mana",0);
+		}
+	virtual void Update(int deltaTime) {
+		GetProperty<int>("life") += 1;
+		};
+};
+
+EntityEngine::Component* createFunction(EntityEngine::Entity* entity, const T_String &name) {
+	return new healthComponent(entity,name);
+	}
+
+class eventTarget
+{
+public:
+	void onEvent(const void* pSender, std::pair<const int ,const int > &ev)
+    {
+		std::cout << "onEvent: new " << ev.second << " old:" << ev.first << std::endl;
+    }
+};
+
+void do_test() {
+	eventTarget target;
+
+	EntityEngine::ComponentFactory factory;
+	factory.RegisterComponent("health",createFunction);
+
+	EntityEngine::Entity * entity = new EntityEngine::Entity(factory);
+
+	EntityEngine::Component * newComp = factory.CreateComponent(entity,"health","");
+	newComp->Update(1);
+	EntityEngine::Property<int> life = entity->GetProperty<int>("health:life");
+
+	newComp->Update(1);
+	
+	life.ValueChanged() += Poco::Delegate<eventTarget, std::pair< const int , const int> >(&target, &eventTarget::onEvent);;
+	newComp->Update(1);
+}
+
+int main(int argc, char* argv[])
+{
+	do_test();
+	return 0;
+}
+
Index: types_clanlib.h
===================================================================
--- types_clanlib.h	(revision 0)
+++ types_clanlib.h	(revision 0)
@@ -0,0 +1,23 @@
+#include <ClanLib/core.h>
+
+//typedefs
+typedef CL_String			T_String;
+typedef CL_StringHelp		T_StringHelp;
+typedef CL_TempString		T_TempString;
+typedef CL_Pointf			T_Pointf;
+typedef CL_Exception		T_Exception;
+
+template< typename T >
+struct T_Signal_v1 {
+	typedef CL_Signal_v1<T> Type;
+};
+
+template<typename T,typename U>
+struct T_Signal_v2 {
+	typedef CL_Signal_v2<T,U> Type;
+};
+
+template < typename T >
+struct T_SharedPtr {
+	typedef CL_SharedPtr<T> Type;
+};
Index: types_my.h
===================================================================
--- types_my.h	(revision 0)
+++ types_my.h	(revision 0)
@@ -0,0 +1,65 @@
+#include <string>
+
+//ad-hoc stubs
+template< typename T>
+struct my_Signal_v1{
+	void invoke(T);
+};
+
+template< typename T, typename Y >
+struct my_Signal_v2{
+	void invoke(T,T);
+};
+
+template< typename T>
+struct my_SharedPtr{
+	my_SharedPtr();
+	my_SharedPtr(T *);
+	T* operator->();
+	const T* operator->() const;
+	bool operator==(T *) const;
+};
+
+struct my_Pointf {
+	my_Pointf();
+	my_Pointf(float,float);
+	float x,y;
+	};
+
+class my_StringHelp {
+public:
+	static std::vector<std::string> split_text(std::string,std::string);
+	static std::string uint_to_text(unsigned int);
+	static unsigned int text_to_uint(std::string);
+	static std::string int_to_text(int);
+	static int text_to_int(std::string);
+	static std::string float_to_text(float);
+	static float text_to_float(std::string);
+	static std::string double_to_text(double);
+	static double text_to_double(std::string);
+	static std::string bool_to_text(bool);
+	static bool text_to_bool(std::string);
+};
+
+//typedefs
+typedef std::string			T_String;
+typedef my_StringHelp		T_StringHelp;
+typedef std::string			T_TempString;
+typedef my_Pointf			T_Pointf;
+typedef std::runtime_error	T_Exception;
+
+template< typename T >
+struct T_Signal_v1 {
+	typedef my_Signal_v1<T> Type;
+};
+
+template<typename T,typename U>
+struct T_Signal_v2 {
+	typedef my_Signal_v2<T,U> Type;
+};
+
+template < typename T >
+struct T_SharedPtr {
+	typedef my_SharedPtr<T> Type;
+};
+
Index: types_poco.h
===================================================================
--- types_poco.h	(revision 0)
+++ types_poco.h	(revision 0)
@@ -0,0 +1,69 @@
+#include <Poco/String.h>
+#include <Poco/Exception.h>
+#include <Poco/SharedPtr.h>
+#include <Poco/BasicEvent.h>
+
+template<typename T>
+struct my_Signal_v1 : public Poco::BasicEvent<T> {
+	void invoke(T args) { notify(0, args);}
+};
+
+template< typename T, typename Y >
+struct my_Signal_v2 : public Poco::BasicEvent<std::pair<T,Y>> {
+	void invoke(T  arg1, Y  arg2) { 
+		notify(0,std::pair<T,Y>(arg1,arg2) );
+	}
+};
+
+//just an example of elaborate wrapper class with accessors
+class poco_Pointf {
+public:
+	poco_Pointf() {};
+	poco_Pointf(float,float) {};
+	struct _x {
+		double myX;
+		operator float() const { return (float) myX;}
+	} x;
+	struct _y {
+		double myY;
+		operator float() const { return (float) myY;}
+	} y;
+	};
+
+class poco_StringHelp {
+public:
+	static std::vector<std::string> split_text(std::string,std::string) {return std::vector<std::string>();}
+	static std::string uint_to_text(unsigned int) {return "";}
+	static unsigned int text_to_uint(std::string) {return 0;}
+	static std::string int_to_text(int) {return "";}
+	static int text_to_int(std::string) {return 0;}
+	static std::string float_to_text(float) {return "";}
+	static float text_to_float(std::string) {return 0;}
+	static std::string double_to_text(double) {return "";}
+	static double text_to_double(std::string) {return 0;}
+	static std::string bool_to_text(bool) {return "";}
+	static bool text_to_bool(std::string) {return 0;}
+};
+
+typedef std::string			T_String;
+typedef poco_StringHelp		T_StringHelp;
+typedef std::string			T_TempString;
+typedef poco_Pointf			T_Pointf;
+typedef Poco::Exception		T_Exception;
+
+template< typename T >
+struct T_Signal_v1 {
+	typedef my_Signal_v1<T> Type;
+};
+
+template<typename T,typename U>
+struct T_Signal_v2 {
+	typedef my_Signal_v2<T,U> Type;
+};
+
+template < typename T >
+struct T_SharedPtr {
+	typedef Poco::SharedPtr<T> Type;
+};
+
+
Index: TypeSerializer.cpp
===================================================================
--- TypeSerializer.cpp	(revision 107)
+++ TypeSerializer.cpp	(working copy)
@@ -49,7 +49,7 @@
 	case TypeSerializer::TYPE_CL_POINTF:
 		return new Property<T_Pointf>(name);
 	default:
-		throw T_Exception(cl_format("TypeSerializer::CreateProperty - Unknown entity type %1", typeId));
+		throw T_Exception(T_String("TypeSerializer::CreateProperty - Unknown entity type ") + T_StringHelp::uint_to_text(typeId));
 	}
 }

EDIT: fixed it up a little and provided a small POCO-based sample on how everything wires together.

KungFooMasta · Post by **KungFooMasta** » Fri Feb 12, 2010 8:33 am

Hey all! I've recently taken more interest in messaging systems, and was curious to see if anybody was willing to share any recent developments. (Rather than review this thread full of old code) In particular I'm interested to know how people encapsulate their message data in a generic way. I've bought Xavier's book on engine design, and while its very useful and informative, seeing some real world references would be helpful. In the book he mentions the idea of a 'Variant', which basically reminds me of the Ogre/boost Any. But how does this work with messages/events that might contain dynamic data, a list of strings, for example?

Ogre Forums

Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?

Re: Component Based Objects?