>> If my sprites need
>> to communicate with each other usually I will have a sprite manager object
>
> So this is, what, usually a global variable/list/proplist, ie a common well
> that they all draw from?
Colin (Kettenacker, that is) has a similar approach to mine, so I'll toss in
my 2 pence. It's an object, which is a different animal from a global. Think
of an object as a behavior instance without a sprite. There are a few ways
to store the object's memory address reference (one of which is in a global
variable) which allows you to communicate with the object.
Often, object-oriented programming involves a hierarchy of objects. What I
think Colin is saying is that he has a manager object which is higher up in
the hierarchy, and runs herd over the lower tier of sprite objects. This
essentially replaces the sendSprite and sendAllSprite calls - because the
manager receives all messages that might be sent to sprites in another
architecture, figures out which objects need to get a message, and passes
the info along. I favor this architecture, because it helps you to adhere to
a major oop tenant - encapsulation. For instance,
sendAllSprites(#someMethod) broadcasts the message to any sprite with the
"someMethod" handler to execute that method - often not a problem, but if
there are some stray sprites around with behaviors attached that have that
handler, you can get some confusing results. There are other advantages to
oop, but encapsulation is a major one.
If the manager object receives a method call that it will interpret and send
to only the sprites that it manages, then things are better encapsulated.
Behaviors are objects - if you take what you know about how behaviors store
properties, you can abstract that knowledge just a bit, and you'll be
thinking in terms of parent scripts as well as behaviors.
> I'm not specifically saying that sprite(1) would set a property of
> sprite(2), but that sprite(1) sending a sendallsprites would be received by
> a number of sprites listening for the call that would do certain things
> based on specific internal criteria. To me this is kind of the same way a
> movie script would work, in that different sprites could do certain things
> when getting a 'switchToThis" call. Based on intertal props within their PDL
> list, they could then choose to do 'something' or ignore it all
> together.....kind of like having an invisible global or sprite object
> handler...
>
> I'm not saying I'm RIGHT - hell I could be entirely wrong and would love to
> learn more -- but this is kind of the way I've been dealing with stuff..
I wouldn't begin to suggest that you are wrong - using behaviors and movie
scripts is a perfectly acceptable way to program. But if you can learn to
use parent scripts to create objects that live only in RAM, then you might
find other ways. I'm far from an oop purist, but over time, I've come to
embrace objects as I've learned how to manipulate them. You certainly don't
need oop - but you might come to like it.
Apologies for butting in,
Kurt
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
