R0J0hound's Forum Posts

  • Aher0

    Here's the capx:

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

    The motion is jarring at times but the players run back and forth trying to kick the ball to their goal.

  • The idea should work. You can calculate the angle from the ball to the goal with the angle() expression and then calculate a position behind the ball to hit it to the goal with this:

    X+radius*cos(ang)

    Y+radius*sin(ang)

    This is basically all the trig you need for games. For x and y use the ball's position in this case.

    So with this you'd move to that position then to the ball. The next issue to address is the car can hit the ball accidentally when moving to that position. To fix it you'd need to move left or right of the ball first.

    At this point it becomes a bit tedious to describe but a picture would help a lot.

    Basically

    Angle2ball is from the player to the ball

    Angle2goal is from the ball to the goal

    If both angles are Within 90 degrees of each other then move to the point behind the ball

    Otherwise

    If clockwise go to left point

    If counterclockwise go to the right.

    I got it working in a capx but I can't post it for a day or so.

    Here are the points:

    Behind ball

    Ball.X+radius*cos(angle2goal+180)

    Ball.y+radius*sin(angle2goal+180)

    Left point. Right can be found by making 90 positive

    Ball.X+radius*cos(angle2ball-90)

    Ball.Y+radius*sin(angle2ball-90)

    The radius can be whatever looks good. Also I was able to get a more pleasing result by using 135 instead of 90 for the left and right points. I apologize this doesn't cover exactly how to make it work but it should be good enough to get the idea across.

  • Ah, true. I missed that forward momentum bit.

  • irina

    If you scale the crossword by a factor "scale" you could do this:

    crosswordgrid: set size to (self.width*scale, self.height*scale)

    letter: set x to (letter.x - puzzlegrid.x)*scale + puzzlegrid.x

    letter: set y to (letter.y - puzzlegrid.y)*scale + puzzlegrid.y

  • You could just scale the layer the crossword is on.

  • The one formula to know for motion is:

    speed*time=distance

    Take the red bullet as and example. You know the time (1 second) and the distance (90 degrees). so the equation is:

    speed*1 = 90

    You want to know the speed of the rotation so isolate speed on one side and we get:

    speed = 90/1

    or

    speed =90

    then you can do the motion with an event like:

    every tick:

    --- rotate red 90*dt degrees counter-clockwise

    --- rotate green 40*dt degrees counter-clockwise

    --- rotate blue 70/2*dt degrees counter-clockwise

    My next question is do you want the bullets to continue turning after that of just continue straight?

    If continue staight use "rotate toward angle" instead.

  • Probably not. The ragdoll bit is doable with the physics behavior and adding joints between the limbs with events. Before that you could use Spriter or Spine to create the controlled animations. Both have plugins I believe.

    I know little about either since I'm not so much of an art guy, but presumably you'd disable that and enable the physics to cause a ragdoll effect.

    Edit:

    Looking at the spriter plugin it looks like you'll have to do a bit more. You can access "action points" from spriter animations so the best you can do is put a lot of those in the animation, and then when you want it to ragdoll you'd create a bunch of sprites in position of the limbs by using the action points as a guide.

  • The runtime itself can be modified since its c++ source is available on sourceforge. All the runtimes are already pre-built in a folder dx9.exe, app.exe, ... Etc.

  • it's very similar to how c2 does it. The exe is the runtime and everything else: plugins, events, layouts and images are added as data in a format the runtime can readily use. So no it's not really possible to do what you want as the data is specific to the runtime.

  • To me it just looks like a delay before the blocks move.

    Like this:

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

    The interesting bit is how the delay is staggered. In the example above it was don manually but you could set it with events.

  • You need three points and a sprite. The first and last point are the endpoints and the middle point controls the curve. In the most simple example you would setup the events like this:

    global number t=0

    every tick:

    --- set t to min(1, t+1*dt)

    --- sprite: set x to qarp(p1.x,p2.x,p3.x,t)

    --- sprite: set y to qarp(p1.y,p2.y,p3.y,t)

    the "1" in t+1*dt is the number of seconds it takes to move.

    The min() expression is used to make it stop at the end. otherwise it would keep going.

  • Here's a capx with it working:

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

    The expression (rand-1)%4+1 was actually a typo, I wanted rand%4+1.

    What it does is give the next number after rand or 1 if rand was 4.

    1 -> 2

    2 -> 3

    3 -> 4

    4 -> 1

  • This site has a formula for it.

    http://paulbourke.net/geometry/pointlineplane/

  • Good catches. It wasn't fully tested. That -1 shouldn't be there. And the other issue should be fixable with min() and max().

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could maybe use a smaller sprite pinned the the player sprite and use that instead to check for overlaps.