mTropolis Refugees

[Scott Rossi]

Recently,Janus Jakaterina wrote:

> Are there many mTropolis folk now residing in the land
> of Revolution?

Not a refugee, more like a second cousin's nephew, twice removed, who
visited once in a while...

 
> If so, how is Revolution for behaviors, aliasing, and
> messaging? 

Again, I'm no mTropolis expert (mTropolis was a long time ago by the way),
but you can give objects their own behaviors that allow them to live, act
and die on their own using something like "send xyz to me..."  Messages can
also be passed from objects to the "environment" of the card and stack,
either using the previous "send..." command or automatically via Rev's
message hierarchy (see here for a good explanation of Rev's message path:
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>).

The issue you have to watch out for is having dozens of things happening on
screen at once; Rev is not really optimized for this kind of thing across
the board (low end graphics cards and/or processors can affect performance),
but with careful design (and lots of testing) you can get away with some
decent animation/movement.

 
> Other than the arcade engine, which seems to be a 3rd
> party product, can Revolution handle multiple moving
> objects or collision detection?

Yes to both.  You can search the list archives for more info on this, and
the following was posted just the other day:

Date: Mon, 14 Nov 2005 20:01:57 -0800
Subject: Re: maze wall algorithm
From: Scott Rossi
To: How to use Revolution

Recently,N Cueto wrote:

> If given a maze in the form of a
> grid
> ...
> then, what would be the
> ideal scripting for limiting
> "movement" between only
> contiguous squares that are
> not separated by a wall

The way I've done something like this in the past is to use physical
boundaries, in other words, using the intersect and/or within functions to
prevent/constrain movement in certain directions.  From your example, it's
not clear if you *need* to limit movement based on numerical progression,
but this could be handled easily via the loc property, as you guessed.

You could use rectangle "wall" graphics combined with the above functions to
allow for moveable obstacles, and test for collision with the graphics on
the current maze/screen.  Alternatively, if you were able to use a single
image as your maze, this would allow for testing intersect/within results
within a single object -- the image.  This is the benefit of using images
for collision detection in that you can test for non-transparent pixel
collisions, as opposed to using graphics which only allow for rects.  I
don't know if images would work in your situation but that was the technique
I used and it's reliable.

Let me know if this makes sense (or if not, maybe I can dig up an old demo).

Of course, one must also keep in mind Malte Brill's Arcade Engine...

[end post]


Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & Design
-----
E: scott at tactilemedia.com
W: http://www.tactilemedia.com