R0J0hound's Recent Forum Activity

  • The expressions

    Sprite.bboxLeft

    Sprite.bboxRight

    Sprite.bboxtop

    Sprite.bboxbottom

  • Guess it would be tricky converting everything over. Usually I just round as a last step and keep the unrounded variable and apply all changes to that.

    Anyways, here’s another idea to convert it. I’m assuming on your machine it runs at 60fps, so if you put all your events as sub-events to this it may work. It just only runs when the time passed is a 1/60th of a second. Just an idea at least. Triggers and new object picking may throw it off.

    Variable prevtime=0

    Compare: prevtime+1/60 <= time

    — add 1/60 to prevtime

    — put all events here

  • Well it should be as simple as:

    Every tick

    — sprite: rotate 100*dt degrees towards (320,240)

    Where 100*dt means 100 degrees per second.

  • Just replace the random() stuff to whatever you like. Random can be defined as random(min, max) of that helps. All a box is a low and high value vertically and horizontally.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You do not have permission to view this post

  • There’s a “rotate toward position” action that lets you smoothly rotate to face a location.

  • For something simple like variable that only increases or decreases you can utilize the trigger once condition.

    Variable timer = 10

    Every tick

    — subtract 123*dt from timer

    Timer <= 7.5

    Trigger once

    — set text to “three quarters left”

    Timer <= 1/3

    Trigger once

    — set text to “a third left”

    Timer <= 0

    Trigger once

    — set text to “done”

    Something that counts up would be >= instead.

    Another option could be to still change the variable by whole numbers but use a dt multiplied one to control it.

    Variable timer =0

    Variable countdown = 10

    Every tick

    — add 100*dt to timer

    Repeat int(timer) times

    — subtract 1 from timer

    — subtract 1 from countdown

    — if countdown=5

    — — set text to “halfway”

    — if countdown = 2

    — — set text to “a fifth left”

    — if countdown = 0

    — — set text to “done”

    Anyways those are two ideas that come to mind.

  • One way is to just spawn the objects in random positions and if the object collides with the player move it to a random position.

    Here’s one possible example. Create it on the player, and repeatedly move it to a random position till it’s not touching the player.

    On function “add spear”

    — Create spear at (playerbox.x, playerbox.y)

    — while

    — spear: overlaps playerbox

    — — spear: set position to (random(windowWidth), random(windowheight))

  • One way to do it would be with a second array. So if A is the first one B could be the second. And you’d do this:

    On function “journal”

    — B: set size to (0,2,1)

    — A: for each xy

    — — B: push A.at(A.curX, A.curY, 1) to front

    — — B: set at (0,1) to A.at(A.curX, A.curY, 0)

    — B: sort

    Then B would have the sorted list in the 2nd column.

  • Possibly. The only physics part I touch is enabling and disabling it for a frame.

    Actually, the issue probably has to do when the polygons have an odd number of points. Distort meshes only have an even number of point with the way I’m using it, so it just sets two points to the same spot. Which is probably breaking the physics library’s collision response sometimes.

    Edit:

    That doesn’t seem to have fixed it. It seems to work fine without the physics behavior. Probably need to debug the polygons. Likely some numeric errors that are cropping up.

    This is assuming that the physics behavior, how the collision shape it generated, and how the collision polygon is distorted are working without bugs.

    Edit2:

    Found it can crash too. Seems to be in the physics behavior. Anyways, best I can do is add code to make sure the polygons are convex and ordered clockwise. Maybe on another date. If it still fails then the issue is out of my control. Guess there’s always event based physics if I can fit it in and get the inspiration.

    Edit3:

    Can't fix. My code is generating convex polygons. The mesh distort feature also seems to be giving the correct collision shape. The physics behavior seems to bug out sometimes?

  • So c3 has a feature that can let you distort sprites with a a grid mesh. The cool thing about it is it not only visually distorts the sprites but it affects their collision shapes too, which in turn is transferred to the physics behavior.

    Anyways, I finally got a chance to test it and confirm it lets you do that. Next I was able to use that as a tool to slice up physics object. The basic idea is each sprite is paired with an array making up the points of the polygon. From that with some math I was able to divide two polygons into two utilizing a line. The final step was to take that array of polygon points and setup the distort.

    Here's the example of it working. drag a line to cut the sprite.

    dropbox.com/s/r8lhe8sha0wa33m/poly_split.c3p

    One quirk with the physics behavior that I had to work around was when creating objects you need to disable them for a frame before enabling them again or they will jump. It's been there for ages.

    This only scratches the surface, and was mainly just to show how to slice objects up. I could be adapted to do dynamic breaking by running it in a loop where you'd set the line to be random angles from the collision point.

  • So the overall logic would be when a collision occurs see how hard of a collision it was and if it was hard enough break the object up.

    Seeing how hard the collision was should be a matter of looking at the difference of kinetic energy (KE=0.5*mass*velocity^2) of the object before and after the collision. You can do that by saving the KE to a variable at the end of a tick to reference later.

    Breaking the object up is either done with pre-made pieces or by somehow breaking it up dynamically.

    The pre-made pieces way is the more doable approach. There are two ways to do it though.

    1. Destroy the main object and create all the pieces.

    2. Just have all the pieces joined together with joints which are later unjoined.

    There are pros and cons of either. With 1 you’ll need to be able to place the pieces in the right position and angle, as well as set their linear and angular velocity from the original object.

    With 2 setting up the joints between the pieces can be tedious, and you’ll need a way to look at all the pieces as a group with events. Also joints tend to be springy, and you may need multiple joints between pieces to keep them from rotating.

    Now the fanciest approach would be to dynamically break the objects up as needed. For that we need to be able to change the collision polygon and what is drawn. For c2 you’re out of luck there with vanilla features, but in c3 you can in theory do it with the distort mesh feature. However it wasn’t meant for that sort of thing so some creative use will be needed.

    Anyways, using mesh distort as a tool we will want a way to slice a convex polygon into two separate convex polygons. With multiple cuts we should be able to break the objects up. There are many ways we can take the idea from there such as making the breaks originate from the contact points and use voroni cells to change up how it breaks.

    Anyways that’s a general overview. There are probably lots simplifications that can be done to make it more feasible.