Comments on: Growing Ginkgo Pt. 1: The Reading List [...] integrated live-editing into Ginkgo some time ago by hooking up our component system and AntTweakBar. Now that the system has outgrown [...] [...] integrated live-editing into Ginkgo some time ago by hooking up our component system and AntTweakBar. Now that the system has outgrown [...]

]]>
By: The Quest for the Ginkgo GUI « #AltDevBlogADay/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-6370 The Quest for the Ginkgo GUI « #AltDevBlogADay Tue, 28 Jun 2011 18:30:27 +0000 [...] in C++. I covered the inspirations for Ginkgo in my first posting and the component system in the second [...] [...] in C++. I covered the inspirations for Ginkgo in my first posting and the component system in the second [...]

]]>
By: James Podesta/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-572 James Podesta Tue, 25 Jan 2011 14:40:41 +0000 Well. The idea was that I would get there in about 2 or 3 blog posts, but why not show how we're accessing components now: In our system, there is (a) a global messaging/event system that is delegate-based and makes symbol table lookups etc. to route a message and (b) there are direct function calls to other components. Usually you don't want those because they can trash your cashes and lead to strong coupling between components. But - as Fabrice points out - the system would be rather unwieldy without them. So in the case a component _requires_ another component it can acquire a pointer to that component and simply use _spatial->setPosition(x,y) to use the spatial component of the component's owner. It's not as straight forward as a fat game object, but once you have the right mindset, you can work quite productively with this mechanism. Well. The idea was that I would get there in about 2 or 3 blog posts, but why not show how we’re accessing components now: In our system, there is (a) a global messaging/event system that is delegate-based and makes symbol table lookups etc. to route a message and (b) there are direct function calls to other components. Usually you don’t want those because they can trash your cashes and lead to strong coupling between components. But – as Fabrice points out – the system would be rather unwieldy without them. So in the case a component _requires_ another component it can acquire a pointer to that component and simply use _spatial->setPosition(x,y) to use the spatial component of the component’s owner. It’s not as straight forward as a fat game object, but once you have the right mindset, you can work quite productively with this mechanism.

]]>
By: James Podesta/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-570 James Podesta Tue, 25 Jan 2011 12:39:13 +0000 ./altdevblogaday.org/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-569 The last component system I used,  you didn’t talk to components directly...  you just sent yourself a message and responses would come back in the message structure if you were expecting one.<o:p></o:p> So..<o:p></o:p> MsgSetVelocity  msg( newVelocity );<o:p></o:p> Message( msg );<o:p></o:p> Or to get current position<o:p></o:p> MsgGetPosition  msg(  getPosition );<o:p></o:p> Message(msg);<o:p></o:p> Vector3 result =  msg.position;<o:p></o:p> Any component could pretty much act as a delegate for any message.  It was then up to the person designing components to come up with a logical partitioning of which components should provide which services.<o:p></o:p> The entity itself  (or other components)   didn’t really care who provided the service as long as it was provided...  ie..  as long as the “object” can a concept of velocity,  it didn’t really care which component provided that concept.<o:p></o:p> You could have multiple components attached to one object if it made sense to do that...  like attaching 3 different particle systems – smoke, spark and flames...<o:p></o:p> Each component would have a name, so you could have messages like           MsgDisableComponent (  “smoke1”  )....  to disable the smoke particle system.<o:p></o:p> From: Posterous [mailto:comment-lpfDDvfkiwCEcza=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Tuesday, 25 January 2011 10:12 PM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Growing Ginkgo Pt. 1: The Reading List"<o:p></o:p> The last component system I used,  you didn’t talk to components directly…  you just sent yourself a message and responses would come back in the message structure if you were expecting one.<o:p></o:p> So..<o:p></o:p> MsgSetVelocity  msg( newVelocity );<o:p></o:p> Message( msg );<o:p></o:p> Or to get current position<o:p></o:p> MsgGetPosition  msg(  getPosition );<o:p></o:p> Message(msg);<o:p></o:p> Vector3 result =  msg.position;<o:p></o:p> Any component could pretty much act as a delegate for any message.  It was then up to the person designing components to come up with a logical partitioning of which components should provide which services.<o:p></o:p> The entity itself  (or other components)   didn’t really care who provided the service as long as it was provided…  ie..  as long as the “object” can a concept of velocity,  it didn’t really care which component provided that concept.<o:p></o:p> You could have multiple components attached to one object if it made sense to do that…  like attaching 3 different particle systems – smoke, spark and flames…<o:p></o:p> Each component would have a name, so you could have messages like           MsgDisableComponent (  “smoke1”  )….  to disable the smoke particle system.<o:p></o:p> From: Posterous [mailto:comment-lpfDDvfkiwCEcza=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Tuesday, 25 January 2011 10:12 PM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Growing Ginkgo Pt. 1: The Reading List"<o:p></o:p>

]]>
By: Fabrice Lété/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-568 Fabrice Lété Tue, 25 Jan 2011 12:11:42 +0000 Ah right , i had misread above in haste :) Makes more sense, then. Don't mind me. Ah right , i had misread above in haste :) Makes more sense, then. Don’t mind me.

]]>
By: Martin Pichlmair/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-566 Martin Pichlmair Tue, 25 Jan 2011 09:15:16 +0000 In fact, < pickup /> implies trigger, so <object> <box2dcircle /> <pickup /></object> In fact, < pickup /> implies trigger, so <object> <box2dcircle /> <pickup /></object>

]]>
By: Sven Bergström/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-564 Sven Bergström Tue, 25 Jan 2011 08:41:37 +0000 ./altdevblogaday.org/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-563 Yeah, that’s pretty much exactly how I would have structured your data.<o:p></o:p> It’s a little hard to read on one line, because you have objects starting and stopping and you need to track the context of those with your eyes.<o:p></o:p> I try to always start new XML nodes on fresh lines.  It takes up more screen-space, but is a little more human readable for identifying the individual components in your object.<o:p></o:p> <object><o:p></o:p></object>     <box2dbody /> <o:p></o:p>     <box2dcontactlistener /><o:p></o:p>     <box2dfixture><o:p></o:p>          <shape type="circle" /><o:p></o:p>     </box2dfixture><o:p></o:p>     <fastspriterenderer /><o:p></o:p>     <pickup /><o:p></o:p>     <trigger /><o:p></o:p>     <spatial2d /><o:p></o:p>  </object> <o:p></o:p> I don’t see why something like JSON would make that any nicer.<o:p></o:p> From: Posterous [mailto:comment-lpfDDvfkiwCEcza=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Tuesday, 25 January 2011 6:02 PM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Growing Ginkgo Pt. 1: The Reading List"<o:p></o:p> Yeah, that’s pretty much exactly how I would have structured your data.<o:p></o:p> It’s a little hard to read on one line, because you have objects starting and stopping and you need to track the context of those with your eyes.<o:p></o:p> I try to always start new XML nodes on fresh lines.  It takes up more screen-space, but is a little more human readable for identifying the individual components in your object.<o:p></o:p> <object><o:p></o:p></object>     <box2dbody /> <o:p></o:p>     <box2dcontactlistener /><o:p></o:p>     <box2dfixture><o:p></o:p>          <shape type=”circle” /><o:p></o:p>     </box2dfixture><o:p></o:p>     <fastspriterenderer /><o:p></o:p>     <pickup /><o:p></o:p>     <trigger /><o:p></o:p>     <spatial2d /><o:p></o:p>  </object> <o:p></o:p> I don’t see why something like JSON would make that any nicer.<o:p></o:p> From: Posterous [mailto:comment-lpfDDvfkiwCEcza=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Tuesday, 25 January 2011 6:02 PM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Growing Ginkgo Pt. 1: The Reading List"<o:p></o:p>

]]>
By: Martin Pichlmair/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-562 Martin Pichlmair Tue, 25 Jan 2011 08:01:42 +0000 Regarding inter-component communication: Our current opinion is that you need both: A messaging system for loose coupling and a straight-forward and fast direct calling system. You most likely end up with components that explicitly require specific other components to work, e.g. a physics body requires a spatial to write its data to in order to position a game object. We use exactly the same method that you've described in order to call functions of other components in that cases. But we only allow those for components that are initialized and alloced upon loading the level, so that we don't have to lookup and check validity for every call. The event system is an entirely different beast but I have to explain our Signals system before I can come to that and that requires a whole blog post on its own. Regarding inter-component communication: Our current opinion is that you need both: A messaging system for loose coupling and a straight-forward and fast direct calling system. You most likely end up with components that explicitly require specific other components to work, e.g. a physics body requires a spatial to write its data to in order to position a game object. We use exactly the same method that you’ve described in order to call functions of other components in that cases. But we only allow those for components that are initialized and alloced upon loading the level, so that we don’t have to lookup and check validity for every call. The event system is an entirely different beast but I have to explain our Signals system before I can come to that and that requires a whole blog post on its own.

]]>
By: James Podesta/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-560 James Podesta Tue, 25 Jan 2011 02:06:10 +0000 ./altdevblogaday.org/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-560 I find XML more readable than JSON.   You’re brain will adjust to just about anything.  (like Hungarian notation or sticking “m” in front of all your variables..)<o:p></o:p> My advice with XML is to avoid Text() blocks because wrapping your value in the same string twice really throws the brain.<o:p></o:p> Use mainly attributes and subnodes.<o:p></o:p> Some random examples of XML from my game...   I find them easy to read..<o:p></o:p>       <!-- LEVEL #8 --><o:p></o:p>       <enemy name="ogre" sprite="ogre" class="enemy" lvl="8" str="17" dex="10" con="25" int="1" ><o:p></o:p>             <flag value="stoneInDaylight" /><o:p></o:p>             <drop chance="10" minCount="10" maxCount="50" name="gold" /><o:p></o:p>       </enemy><o:p></o:p>       <spell_script name="FIREBOLT2" cost="200" desc="FIREBOLT II" longdesc="Upgraded firebolt does 20 points of damage" mana="20" targetType="single" projectile="p.firebolt" ><o:p></o:p>             <event name="OnHit" script="doDamage hit fire (power * 40)" /><o:p></o:p>             <req name="abrusseed" quantity="2" /><o:p></o:p>             <req name="bloodroot" quantity="2" /><o:p></o:p>       </spell_script><o:p></o:p>       <mission id="SnakeFrying" desc="Snake Frying" level="2" handInMap="magenta" handInObj="Mina" xp="50"<o:p></o:p>                   longdesc="Fry some snakes with your firebolt spell. Collect charred snake from their remains and return to Mina"<o:p></o:p>                   longresult="Frying a few snakes with your firebolt spell yielded enough charred snake drops to perform a stoneskin enchantment" ><o:p></o:p>             <task type="collect" target="CharredSnake" count="4" /><o:p></o:p>             <task type="collect" target="bloodRoot" count="2" /><o:p></o:p>       </mission><o:p></o:p> From: Posterous [mailto:comment-lpfDDvfkiwCEcza=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Tuesday, 25 January 2011 10:29 AM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Growing Ginkgo Pt. 1: The Reading List"<o:p></o:p> I find XML more readable than JSON.   You’re brain will adjust to just about anything.  (like Hungarian notation or sticking “m” in front of all your variables..)<o:p></o:p> My advice with XML is to avoid Text() blocks because wrapping your value in the same string twice really throws the brain.<o:p></o:p> Use mainly attributes and subnodes.<o:p></o:p> Some random examples of XML from my game…   I find them easy to read..<o:p></o:p>       <!– LEVEL #8 –><o:p></o:p>       <enemy name="ogre" sprite="ogre" class="enemy" lvl="8" str="17" dex="10" con="25" int="1" ><o:p></o:p>             <flag value="stoneInDaylight" /><o:p></o:p>             <drop chance="10" minCount="10" maxCount="50" name="gold" /><o:p></o:p>       </enemy><o:p></o:p>       <spell_script name="FIREBOLT2" cost="200" desc="FIREBOLT II" longdesc="Upgraded firebolt does 20 points of damage" mana="20" targetType="single" projectile="p.firebolt" ><o:p></o:p>             <event name="OnHit" script="doDamage hit fire (power * 40)" /><o:p></o:p>             <req name="abrusseed" quantity="2" /><o:p></o:p>             <req name="bloodroot" quantity="2" /><o:p></o:p>       </spell_script><o:p></o:p>       <mission id="SnakeFrying" desc="Snake Frying" level="2" handInMap="magenta" handInObj="Mina" xp="50"<o:p></o:p>                   longdesc="Fry some snakes with your firebolt spell. Collect charred snake from their remains and return to Mina"<o:p></o:p>                   longresult="Frying a few snakes with your firebolt spell yielded enough charred snake drops to perform a stoneskin enchantment" ><o:p></o:p>             <task type="collect" target="CharredSnake" count="4" /><o:p></o:p>             <task type="collect" target="bloodRoot" count="2" /><o:p></o:p>       </mission><o:p></o:p> From: Posterous [mailto:comment-lpfDDvfkiwCEcza=posterous.com@sendgrid.me] On Behalf Of Posterous Sent: Tuesday, 25 January 2011 10:29 AM To: podesta1971@gmail.com Subject: [altdevblogaday.com] Comment on "Growing Ginkgo Pt. 1: The Reading List"<o:p></o:p>

]]>
By: willedgette/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-559 willedgette Tue, 25 Jan 2011 00:37:44 +0000 . Unfortunately, I’m having second thoughts about the performance of this because it requires a lot of mapping and makes a lot of things more difficult.Component to component communication is an interesting problem and I’m looking forward to see how you’ve tackled it. Before I started my rewrite based on the previously mentioned entity system, I would do something like “Object->GetComponent<physicscomponent>().SetVelocity(X,Y,Z);” from inside of InputComponent for example. This really broke the separation and is the main reason why I started my last component rewrite. The solutions as far as I can tell seem to be to either use a messaging system, or have reserved data/attribute values with restrictions on when you can read/write.

]]>
By: Martin Pichlmair/2011/01/24/growing-ginkgo-pt-1-the-reading-list/#comment-558 Martin Pichlmair Tue, 25 Jan 2011 00:28:35 +0000 Great post! I'm actually looking for a lot of tips on building an engine and this helped out immensely. I do have a couple questions though: First, about how long did it take you to develop Ginkgo? Also, why did you decide on using XML as your primary data format instead of defining your own? These are a couple concerns that I'm going through trying to develop my own engine. Looking forward to your future posts! Great post! I’m actually looking for a lot of tips on building an engine and this helped out immensely. I do have a couple questions though: First, about how long did it take you to develop Ginkgo? Also, why did you decide on using XML as your primary data format instead of defining your own? These are a couple concerns that I’m going through trying to develop my own engine. Looking forward to your future posts!

]]>