R0J0hound's Forum Posts

  • Here's a simplified version. The units go around the wall when they collide with it. "Overlaps at offset" could be used to get the units to start avoiding prior to overlap. In the capx above i was checking for an overlap in the range from where the unit is to where it will be later.

    Sprites:

    "Wall"

    "Unit" with variables i, targety

    Events:

    Global number starty=240

    Start of layout

    --- unit: destroy

    Start of layout

    Repeat 10 times

    --- create unit at (0, starty)

    --- unit: set i to loopindex

    Every tick

    --- unit: set x to self.x + 100*dt

    --- unit: set targety to starty+(self.i-5)*16

    Wall: is overlapping unit

    Pick all unit

    ===unit: targety<wall.y

    --------unit: add -wall.height/2 to targety

    ===unit: targety>=wall.y

    --------unit: add wall.height/2 to targety

    Unit: y < self.targety

    --- unit: set y to self.y+100*dt

    Unit: y > self.targety

    --- unit: set y to self.y-100*dt

  • Try the bullet behavior with gravity instead. It would look the same only without collisions.

  • Here's one possible idea. When you create the objects calculate their spread out position, that will be the target position. Next see if the path from the current position to the target hits any walls. If it does shift all the targets up or down depending on if they're above or below the line. Finally move toward that target and repeat next frame.

    Here's a basic example that spreads units up and down around walls.

    https://dl.dropboxusercontent.com/u/542 ... _line.capx

    Another idea would be to looking into boids or flocking behaviors.

  • I don't think you can, but I'm curious, why you need it? If it doesn't have the solid behavior and if you aren't checking for collisions with it in events then no collisions are checked with it.

  • This example here is applicable, although I forget if varying costs is implemented in it.

  • AllanR

    TELLES0808

    I'm glad it was useful and amusing to tinker with. I had fun making it.

    Concave terrain like that would cause the algorithm to run longer, but it's only an issue if pathfinding for all your ships ends up being too slow. A simple thing you could do is avoid concave terrain in your levels.

    Or if you're feeling ambitious you could reference this fun site for other pathfinding ideas.

    http://theory.stanford.edu/~amitp/GameProgramming/

    One thing I've done in the past is calculate the path over multiple frames instead of all at once. It helped spread out the pause when a large amount of nodes were used.

  • Any reason for using a corner of the hexagons instead of their centers?

    If done manually with events you'll use this for finding the path:

    https://en.wikipedia.org/wiki/A*_search_algorithm

    The difference between a hex grid and a rectangular grid is just how the neighboring grids are found. For simplicity collision detection can be used.

    Here's an example:

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

    /examples29/astar_hex.capx

    In it it defines a function "astar", which you call with two iids: a start and and end node. After the function the start node's node.next will be the uid of the next node in the path. This can then be repeatedly followed to the end node. For smooth motion you'll have to use the moveto behavior or devise your own method.

    Event #9 is where you control the cost to move to a node. Right now it uses the distance times the average of the node costs, but there's no reason you couldn't tweak it to be based on other factors.

  • tunepunk

    There is also redat, blueat, greenat and alphaat expressions to get individual components of color. That said, it only reads the color from the canvas object itself so you need to paste stuff first to read it's pixels.

  • Look here for a list with links:

  • You could, but it would be hard to get the 20fps you want.

    For an initial test you could try just sending an array as json and see how it performs. Since it's all text the size of the data could vary a lot. Sending only the pixels that changed would be less data to send up to a point. Since you'd need to send color and position, you could actually need to send more data.

    Getting the colors into the array is the next slow bit. Grabbing pixels is kind of slow, and the only plugin that does it somewhat is the canvas plugin. You'll want to do this in straight javascript for an acceptable speed. Same with arrays. Even looping over them in javascript is much faster than with events.

    Compression is possible, but with that amount of data you'll need to use javascript instead of events.

    A better solution would be to leverage html5 video streaming, but still javascript would be needed.

    But you could go a simpler route, like just sending the player's input so both sides can recreate the same image.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I center the track with the baseDx variable, so maybe you could modify it somehow when turning.

  • Here's a bit of experimentation with the idea. The main issue it has is the curving of the road isn't synchronized with the speed, so right now it kind of drifts.

    https://dl.dropboxusercontent.com/u/542 ... _race.capx

    It's requires a bit of math and fiddling with the formulas to tune it. That said it's not exactly simple and I haven't really scratched the surface of what that guide covers. At the very least this provides something to play around with.

  • You could do it that way, it could be tedious though.

  • The shape of the line is done with the sum of multiple sine waves.

    A single sine wave would look like this:

    y = a*sin(b*time+c*x+d)

    a is the amplitude of the wave

    b is the speed of the wave

    c is the frequency of the wave

    d is just an offset

    The interesting slopes can be done by adding more than one of those waves together as long as they have different values for a,b,c and d.

    So then we have an equation that gives a y position from a x position. That can be used to place the trees, since they just move up and down.

    Getting the angle of the curve at any point just requires some basic calculus. Just take the derivative of the equation above with respect to x and we get:

    slope = a*cos(b*time+c*x+d)*c*pi/180

    Then the angle can be found from the atan of the slope:

    angle = atan(slope)

    Here's an example:

    https://dl.dropboxusercontent.com/u/542 ... rrain.capx

    I used iid but I could have just as well used x, also the lines have gaps which could be fixed with better line drawing.

    That pretty much covers what it looks like is done in that video. To have other objects move about on that surface you'll need to do it manually. I make a ski example a while back that probably could be referenced.

  • To eliminate the sprite getting caught you need to lengthen the slope sprites. If you look close as it is now they don't extend far enough so there's corners to catch on.

    An overlaps check could be better than a on collision check. Just keep in mind you could overlap more than one wall. One way to deal with that would be to use the average angle of the wall's bossAngle.

    +------------------------+
|                        | set sprite angle to 0
+------------------------+
   local number count=0
   local number sum=0
   +---------------------+
   | sprite overlaps wall| set count to wall.pickedcount
   +---------------------+
      +------------------+
      | for each wall    | add wall.bossangle to sum
      +------------------+
      +------------------+
      |                  | set sprite angle to sum/count
      +------------------+[/code:3kmqslf2]

The first action that set's the angle to 0 may not be necessary, but it might give some more consistency to it.  Probably a better idea than setting the angle of the platform object would be to use a seperate object that you'd position to the other one, and then just change the angle of that.