Hi Hans,
Sorry for the long reply on this subject,.. my previous mail got rejected at
hadn't notice it till now.. o_O
I think your algorithm is about how to search for puzzle pieces, but what
I'm looking for is how to tell pieces in the same group to move together..
Here's what I have:
For each piece, before randomly positioning them, I register every piece by
their location: north, south, east and west. So every piece has 4 properties
containing at most 1 MC name. I also added a group property (array class)
which will register pieces (mc names) as groups when combined together.
Here's a simple diagram of a 3x3 puzzle just to make it easy to explain
things:
A B C
D E F
G H I
So, for piece A, A.east is B, A.south is D. In B, B.west is A, B.east is C,
B.south is E, etc..
Initially each piece group property is an empty array, but for a group
something like:
A B C
D
then, A.group is an array of (B, C, D). B.group is an array of (A, C, D),
etc..
I've tried several attempts for piece movement... but none meets my
expectation
let me explain my case with an example,.. say we have a group something like
A B
D E
and we're moving piece E
First attempt, I iterate array members of E.group and calculate the distance
between each piece from piece E. On mouseMove, I update the distance for
every array member of E.group from the piece E current coordinate. This is
the easy way to move group members all at once, but having them stick to
each other is another thing since I get every piece displacing on every
movement. It seems like they're not updating as fast as the mouse move..
Second attempt, similar to the previous attempt but now I calculate the
delta of E and update the delta for each array member of E.group. Each piece
in E.group moves but displaces too, probably the same issue as the first
attempt..
Third attempt, I use the north, east, south, west (N-E-W-S) property in
every piece. So on mouseMove I iterate each array member of E.group and tell
them to update position by E as parameter. I provided an updating method for
each piece class to see if either their north, east, south or west property
is the moving MC (in this case, E). Then it updates their coordinates by
placing themselves from the moving MC (if north, then E._y + E._height).
This sticks the pieces real good, but somehow piece E sometimes slips off
and you can see a minor gap. But the problem with this attempt is that it's
hard to tell pieces not related directly with E to move as well. Like piece
A.
So the forth attempt, instead of telling group members to update by E, I'm
telling E to update it's own N-E-W-S MC and let it 'spread the word' besides
the source (tell B to update it's own N-E-W-S.. tell D to update it's own
N-E-W-S, etc... but not return it back to E). This is a better way to tell
every piece to move by E, but flash spits out an error about endless looping
and that's because A is being called by both B and D. The hard part is, I
can't tell which should A listen to.
now, i think i'm doing this the wrong way somewhere.. any ideas, anyone?
thanks,
Guntur N. Sarwohadi
On 7/15/06, Hans Wichman < [EMAIL PROTECTED]> wrote:
>
> Hi,
> great nice to hear, it's all starting to work now. With respect to the
> moving, are you moving the pieces to round _x, _y values, not sure, but
> this
> might have something to do with it. I remember building a panorama with
> hotspots area's that had to move along with the panorama, and I had the
> same
> problem, the area's slowly moved away from where they should be. I
> rounded
> all the delta x's and y's and the problem went away.
>
> With respect to the other problem, I think (but I haven't yet so sorry
> if
> this isnt the way to go!) I wouldn't use a ref and neighbour ref search,
> but
> actually define groups.
> After moving a piece, it can match on four sides. The matches could be
> groups themselves or single pieces. You could take the first match, and
> either join the new piece to an already existing group, or start a new
> group
> between the matching piece on the moved piece.
> You could make it more complex, for example, when the moved piece
> matches on
> both the left and right side, that you combine all those matches into
> one
> group, however that isn't strictly necessary, since if you use only the
> first match, you simply need to move it after the first grouping and it
> will
> group again.
> This still leaves a lot of questions to be answered though, but still
> the
> principle would be to update groups.
> I'm not sure which solution would be better, they both have something to
> say
> for them i think.
>
> ANYWAYZ: with respect to A*, it would be something like:
>
> - build a childlist for all children not already in the list
>
> in pseudo:
> var piecesToFind = new Array();
> var piecesToIterate = [masterPiece];
>
> while (piecesToIterate.length > 0) {
> var currentNode = piecesToIterate.shift();
> piecesToFind.push (currentNode);
> for each matchingPiece in currentNode {
> if (piecesToFind.contains(matchingPiece) {
> piecesToIterate.push (matchingPiece);
> }
> }
> }
>
> Does that make any sense? (i hope its right:))
>
>
> greetz
> Hans
>
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
