R0J0hound's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • You're probably better off just duplicating obstacles off screen to handle that.

  • Use a separate identical sprite that you position manually.

    So say the screen width is 640

    player.x < 320

    --- clone: set position to (player.y, player.x+640)

    else

    --- clone: set position to (player.y, player.x-640)

  • YoHoho

    A simple way to do multiple would be to clone the band object, duplicate the events and change the old band of the new with replace.

    The length and location of the band is hard coded into the events. You'd have to change the positions of the bands, change the event that resets the band's angle and length when no can is on it (event 1), and change the event that sees if the can is on the band (three conditions on event 3).

    To appear and disappear it's probably as simple as destroying and creating the bands, and setting the length and position from what can be figured out with the previous question.

    Overall the capx wasn't really designed for a lot of that so it would have to be reworked. Maybe understanding what is done would be useful in making something that makes everything easier.

    basically it just checks if the can is between and below two points. When the can first falls in that area then the distance from the can to the the two ends is measured, this is the rest length of the two halfs of the band. Than after that both halves apply a force to the can. It's a spring force and both are calculated with F=-k*(length-rest_length) for each band half. We then apply those forces in direction to the endpoints and that's what moves the can. The spinning and slipping along the band are more of a fuzzy thing. The capx condenses that stuff and also using the band sprites as a visualization.

    Anyways a fixed capx or a redesigned one that supports what you want to do more easily is left to someone else to do. I won't get around to it.