R0J0hound's Forum Posts

  • You can do it that way but you won't be able to destroy it per pixel.

    Well unless you draw the tiles per pixel onto the other. This is probably as tedious as it sounds but you probably could make a system to do it easier

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • worm1

    Either destroy them all every tick before creating them or just creating the shadows once.

  • Also to explain why I used that:

    Chain.index is the order of the objects in the chain. 0 on one end up to say 10 on the other.

    Used with "for each ordered" it will loop over the objects from one end to the other.

    We can also make it loop backwards by multiplying chain.index by -1.

    I used the "dir" variable to specify what direction to use. In the first capx the direction is chosen so the end being dragged is first.

    For the fixed end version it loops twice. Once one direction, then once the other. You could just as well duplicate the loop event and use this instead if that helps.

    For each chain ordered chain.index*dir

    --- do stuff

    For each chain ordered chain.index*-dir

    --- do stuff

    I used equations to cram it all together. It probably would be more readable utilizing functions. Maybe.

  • Thanks dop2000

    I rather like how yours bunches up like a real chain, and letting two chains connect is a nice touch. I'll have to look at how you did that for ideas.

  • It surprised me too when I first saw it used.

  • tarek2

    This would be a case where it would be nice if C2 allowed you to step though the code with the debugger. Anyways it may be helpful to read about the A* elsewhere to see how it works.

    I use the 'done' variable to stop the looping. It's only set when the goal tile is reached. The reason it keeps looping even though it starts with only one object that's 'open' is the neighboring tiles are picked with a family and added to 'open'. To clarify node and othernode can refer to the same objects. Maybe that's where the confusion is.

    The return value is not used in this particular example isn't used but in cases where a path can't be found 0 is returned. That can happen when trying to find a path to a separate island of nodes.

  • Here's my approach. It's more like a rope than a chain. I wasn't able to get that nice loose link feel of dop2000's.

    https://www.dropbox.com/s/95ht71np5jrti ... .capx?dl=1

    Fixed end version. Basically pulls one way, minus the last, then pulls the other way.

    https://www.dropbox.com/s/ecjsc9mmn509i ... .capx?dl=1

  • tarek2

    1.

    This was made for hex tiles specifically, but if you remove the events to set the scale (8 and 12), and make the nodes square with octagon collision polygons it should work. There other examples elsewhere using square tiles i think.

    2.

    I'm not sure it's suitable for multiple objects as is since the path found is stored in the nodes themselves. I guess one idea you could pursue is to store the path in an array after the path finding is done so that the nodes can be reused and the sprite has a list of moves.

    3.

    I haven't really used it. Plenty of people have used it for what you want to do so whatever you find works for you.

  • If you don't want the pieces animated you could use the paster object to apply the blend once so that it's just a matter of drawing separate objects.

    https://www.dropbox.com/s/sdj85geci4y5g ... .capx?dl=1

    The only annoyance is the collision box of the generated pieces are bigger than the visual part of the piece. You could work around that by using a separate smaller square per piece and pin them together. Or if you wan to go crazy you could check is the tabs of the pieces are clicked as well. Could be tricky though and i foresee fighting with the dragndrop behavior with that.

  • My favorite way to do terrain is with a tilemap. You probably want to generate the terrain with events instead of using the editor. Destroying terrain is just one event as well.

    https://www.dropbox.com/s/4sv6lztqwvtxb ... .capx?dl=1

    For falling terrain you'd have to do something else. Perhaps a sprite per column of dirt that you'd slice up when destroying circles out of them. It wouldn't work if you wanted each pixel of dirt to have it's own color. For that you'd have to just move tiles around which will be slow so you'll want to use a very low res terrain and maybe change the idea entirely since looping over a lot of positions like that is not something that's fast in events.

  • Bare minimum you'd need to be able to read individual pixels of an image. The canvas plugin is the only addon that provides that. Then it's a matter of using any old pixel perfect collision detection online. You can also find a few examples on the forum with a search.

  • I can't open the capx since i don't have that third party plugin.

    I guess you could do face2 with events though. Use one object that you'd move around and then just position a second object with sines, using the first as the center.

    Here's the sine equation:

    magnitude*sin(period*time*360+offset)

    And the events:

    start of layout

    magX = 4 + random(2)

    perX = 0.2 + random(0.2)

    offX = 0

    magY = -4 + random(2)

    perY = 0.4 + random(0.2)

    offY = 0

    every tick

    sprite: set x to center.x + magX*sin(perX*time*360 +offX)

    sprite: set y to center.y + magY*sin(perY*time*360 +offY)

  • worm1

    This doesn't really work with any other behaviors. Motion should be done with the set isometric position actions. The example capx show some ideas how to do this. You'd basically be creating the behavior with events but this provides some useful things to make that easier.

    Actually using some other behavior to do the motion could possibly be done by using a separate object and setting isometric position with that, but eh, it's simpler to just do it with events than to wrangle something to do something it wasn't designed for.

  • No problem

  • Why don't you want to use "move at angle"?

    You can do it with:

    Set X to self.x + dist*cos(angle(self.x,self.y,door.x,door.y))

    Set y to self.y + dist*sin(angle(self.x,self.y,door.x,door.y))

    Where dist is however far you want to move.

    You can use 100*dt if you want it to move 100 pixels per second.