tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/3327-go-modular-for-multiple-gamesRobotlegs: Discussion 2013-07-02T07:35:50Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-21T13:51:14Z2013-06-21T13:57:04ZGo modular for multiple games?<div><p>This works!!!</p>
<p>In ModuleConnectorConfig – only the receiveEvent is
set!!<br></p>
<pre>
<code>moduleConnector.onChannel('siblingChannel')
.receiveEvent(ModularConnectorEvent.SOME_TYPE);</code>
</pre>
<pre>
<code>[Inject (name='siblingChannel')]
public var siblingDispatcher:IEventDispatcher;
siblingDispatcher.addEventListener(ModularConnectorEvent.SOME_TYPE);
...
siblingDispatcher.dispatchEvent(ModularConnectorEvent.SOME_TYPE);</code>
</pre></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T08:28:05Z2013-06-22T08:53:49ZGo modular for multiple games?<div><p>I noticed that when a ModularConnectorEvent event is dispatched
in both your and my demo, it <em>initializes</em> the event five
times - or less when less modules are added, something I see when I
do a trace() call in the constructor of the event. The mediators
are receiving the event only once, so that's good. I'm sure this
has to do with the inter-modular relaying but was just wondering
how this globally works.</p>
<p>Btw, I'd love to see an extension that makes it possible to use
signals for modular relaying and receiving, wouldn't know where to
start :)</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T09:21:09Z2013-06-22T09:21:09ZGo modular for multiple games?<div><p>@Jeffw: yeah, that's the crappy event system, basically the
event is cloned for each redispatch. It's to make sure the
<code>currentTarget</code> has a dedicated value. If only there was
a way to override that behaviour...</p>
<p>Regarding the signals for modular communication, take a look at
this example:<br>
<a href=
"https://github.com/robotlegs/ModularRL">https://github.com/robotlegs/ModularRL</a></p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T09:21:29Z2013-06-22T09:21:56ZGo modular for multiple games?<div><p>One reason for this is the mediator re-dispatching the
event.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T09:28:49Z2013-06-22T09:28:49ZGo modular for multiple games?<div><p>@creynders yes, I just saw that example, thanks. It doesn't seem
to work with ModuleConnector. Hmm, so many options...</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T09:41:27Z2013-06-22T09:41:27ZGo modular for multiple games?<div><p>@jeffw no it uses solely signals, in which case you don't need
the ModuleConnector. Personally, I like signals for dedicated,
tight communication: view to mediator, abstract service to concrete
service, etc. but not for system-wide communication. Signals are
great because you can add them to the API, which makes the
communication method explicit. Events are better for system-wide
communication because they don't pollute the injector with tons of
mappings (sth which happens easily with signals) but obviously this
is a matter of preference and coding style.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T09:48:03Z2013-06-22T09:48:03ZGo modular for multiple games?<div><p>Does that mean you use both signals and events in one project? I
always tried to stay away from that, but maybe in this case I can
use signals within my module contexts and events for communication
between contexts.</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T10:15:45Z2013-06-22T10:15:45ZGo modular for multiple games?<div><p>Yes, I use both. But you need to be very strict about how you
use them, otherwise it becomes a mess. (i.e. signals are only for
<em>this</em> kind of communication and events are only for
<em>that</em> kind of communication. No intermingling!!) It takes
some experimenting to find the approach that feels 'right'.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-22T10:18:41Z2013-06-22T10:18:41ZGo modular for multiple games?<div><blockquote>
<p>I can use signals within my module contexts and events for
communication between contexts.</p>
</blockquote>
<p>That could be such an approach, but as I said, make sure you
don't violate your own rule.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-23T12:26:05Z2013-06-23T12:33:29ZGo modular for multiple games?<div><p>@JeffW Is it possible to add the Starling extension to your AS3
example? I've been trying but had no luck. I'm new to Robotlegs 2
so any advice you can give would help. Cheers</p></div>alanmtag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-24T10:16:12Z2013-06-24T10:19:27ZGo modular for multiple games?<div><p>@alanm I'm not sure if it is possible, I guess it should be. I
am pretty new to RL 2 myself. Have you seen this example? <a href=
"https://github.com/brean/robotlegs2-starling-clock-example/tree/master/src/example">
https://github.com/brean/robotlegs2-starling-clock-example/tree/mas...</a></p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-24T10:16:52Z2013-06-24T10:18:18ZGo modular for multiple games?<div><p>hi again,</p>
<p>I have been thinking about how I can work on different levels
(common, shell, modules) at the same time without having problems
with injections of for instance models into commands that share
code that both modules are using (Ondina's example does not contain
commands and models).</p>
<p>I would like to check if my thoughts are correct.<br>
My shell is responsible for adding and removing modules, and for
letting modules know some values based on the previously shown
module, for instance speed.</p>
<p>The modules have their own views, commands, models, services and
associative mappings.<br>
If the modules share code - in a command, model, service or view -
I write a super class that contains this code and a sub class for
each module with module-specific code.</p>
<p>For instance, I'll have a super startup command for both modules
that will add some views, and each module has a sub startup command
in which I inject their own state model, in which some variables
are set. If the state models share functionality I can extend them
from a super model.</p>
<p>I should not inject models or services into a super command,
because it will give errors.<br>
Unless both modules have mapped this model or service. Is this
correct?</p>
<p>The ModularConnection events are used when I need to change
modules.<br>
For instance, moduleA lets shell know it is finished, so shell can
add moduleB</p>
<p>Does this make sense?</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-24T11:23:58Z2013-06-24T11:23:58ZGo modular for multiple games?<div><p>Hi Jeff,</p>
<p>I’m not quite able to answer your questions right now,
because I’m busy writing a Readme for my demo, which is now
on github:<br>
<a href=
"https://github.com/Ondina/robotlegs-bender-modular-air">https://github.com/Ondina/robotlegs-bender-modular-air</a></p>
<p>Please take a look at it. Your feedback would be
appreciated.</p>
<blockquote>
<p>Ondina's example does not contain commands and models</p>
</blockquote>
<p>Yeah, this demo is concentrating solely on the inter-contexts
communication. I’m trying to keep it as simple as
possible.</p>
<p>Integrating commands, models and services could be the subject
of another demo, based on this one. But, let me finish this first
;)</p>
<p>Hopefully someone else will answer your questions today.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-24T18:30:09Z2013-06-24T18:30:09ZGo modular for multiple games?<div><p>hi Ondina,</p>
<p>I walked through the code in your github commit. You have not
changed much, right?<br>
Nice commenting, great diagrams!</p>
<p>No comments from my side, only thing I can think of is that the
name for ModuleBOrCContext.as may sound a bit messy.</p>
<p>All by all, still a great example for introducing modular
connection.</p></div>JeffW.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-25T09:31:14Z2013-06-25T09:31:14ZGo modular for multiple games?<div><p>Thanks Jeff, I’m glad you like it.</p>
<blockquote>
<p>ModuleBOrCContext.as may sound a bit messy.</p>
</blockquote>
<p>Tell me about it, very messy!! I got stuck at naming it, and
thought I just give it some name to be refactored later. There are
other classes, methods and vars as well, that I’d like to
rename.</p>
<blockquote>
<p>You have not changed much, right?</p>
</blockquote>
<p>Heh, I guess you're saying it jokingly, because I made lots of
changes, actually.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-25T09:49:28Z2013-06-25T09:49:31ZGo modular for multiple games?<div><p>@JeffW Thanks for the link, it helped me a lot with RL2 syntax.
Cheers.</p></div>alanmtag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-25T09:51:28Z2013-06-25T09:51:28ZGo modular for multiple games?<div><p>Hey Alan,</p>
<p>Adding to Jeff’s answer.</p>
<p><a href=
"http://knowledge.robotlegs.org/discussions/examples/20-links-to-robotlegs-v2-articles-examples-demos-utilities-and-tutorials">
http://knowledge.robotlegs.org/discussions/examples/20-links-to-rob...</a></p>
<p>There are a few examples using Starling and an extension (SARS).
Not sure if they are up to date, though.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-27T00:57:03Z2013-06-27T00:57:04ZGo modular for multiple games?<div><p>@Ondina Thanks for your demo.</p></div>alanmtag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-06-27T07:54:25Z2013-06-27T07:54:25ZGo modular for multiple games?<div><p>@Alan My pleasure! I hope it's useful.</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/274130762013-07-02T07:35:46Z2013-07-02T07:35:46ZGo modular for multiple games?<div><p>I'm closing this for now.</p></div>Ondina D.F.