R0J0hound's Recent Forum Activity

  • I’d say it mostly depends on the look you are going for.

    You probably could get by with a nice explosion animation on a sprite or side of a cube. You’d just need to make it face the camera.

    Making your own particle system with sprites or cubes is an idea too. But you would need to implement the 3d motion yourself. For example here is what it may look like with 3d motion with gravity and simple bouncing on the floor. 

    On click
Repeat 30 times
— create sprite at (mouse.x, mouse.y)
— sprite: Set vx to random(-200,200)
— sprite: Set vy to random(-200,200)
— sprite: Set vz to random(-200,200)

Every tick
— sprite: add -300*dt to vx
— sprite: set x to self.x+self.vx*dt
— sprite: set y to self.y+self.vy*dt
— sprite: set zelevation to self.zelevation+self.vz*dt

Sprite: zelevation<0
Sprite: vz<0
— sprite: set vz to -self.vz

    But you’ll likely what to do more such and slowing things down on bounce, fading/destroying the sprites eventually or even bouncing off walls. Although collision response is another can of worms.

    You could even make the size/speed change over time to maybe better mimic an explosion.

    Beyond that you could try the full on simulation route. Either Euler or sph fluid simulation could be a base. Then maybe model heat,fuel and oxygen within that. To make it faster you’d simplify from there. Maybe utilize some kind of fast local llm upscaling to get away with lower resolution or lower particle simulations.

    However, I suspect you can get pretty far with some clever artistic simplifications.

    You could also look at explosions in other games and see if you get any ideas from them.

  • I tried oosyrag's idea to remove the instances with the most overlaps first, and it seems to work alright. I used a detector sprite instead of a family but the family idea would work too.

    dropbox.com/scl/fi/jfsdmagr637wr6kqq7jgj/remove_most_overlaps.c3p

    Another idea could be to utilize blue noise to place the objects with a more uniform spacing.

    dropbox.com/scl/fi/tvgd8synoq75c9bsamdfw/blue_noise.c3p

    Here's a comparison of the two.

    Another idea to try is to place the objects randomly and push the overlapping objects away from each other.

    Also the Likely reason why jwilkins' events weren't working when he copied them into a function has to do with quirks regarding picking with newly created objects. Basically created objects aren't generally pickable till the next non-nested event runs. So usually we create all the objects in bulk in one event and manipulate them in the next if we can to work around it.

  • Impressive. Looks like you have a serious wave of productivity with building things to make doing cool stuff like that easier. I’ve always found I tend to start everything from scratch which slows things a bit when I first get started.

    If you can keep up these leaps and bounds of productivity I suspect you could do just about anything at this point. Perhaps even pivoting to make a custom engine for your own purposes.

    Anyways. Keep up the good work.

  • You do not have permission to view this post

  • Normally a physics orbit is done by applying a gravity force (roughly k/distance^2 toward the center object) and setting the tangent velocity just right so it stays in that orbit instead of falling down or flying off into oblivion.

    And while doing a setup like that is possible, it would be fragile in that the asteroid belt would fall apart once the player hit it once.

    Moving back into orbit after being bumped off isn’t realistic behavior so may as well do something unrealistic like applying a force to the asteroids to a location further along the orbit. 

    For each asteroid 
— set ang to angle(planet.x, planet.y, astroid.x, astroid.y)+10
— astroid: apply force 0.1 toward position (planet.x+200*cos(ang), planet.y+200*sin(ang)

    10 is how many degrees ahead in the orbit to target. You can fiddle with that.

    0.1 is the strength of the force. Adjust if too fast or slow.

    200 is the radius of the belt from the planet. Can be anything you like.

    You may or may not want to limit the speed of the astroid. Either by high linear damping or applying a force in the opposite direction of the velocity if the speed is too high. If the speed is uncapped I can imagine colliding with an astroid could send it flying off into oblivion.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • christina

    Until they add the ability to pass normals with the mesh data you could use derivatives to calculate the normals from the fragment shader. The only caveat is it would be normals per face instead of per vertex so it would be like flat shaded instead of smooth shaded.

    Found an example online that demonstrates that.

    webglsamples.org/WebGL2Samples/samples/texture_derivative.html

    Derivatives are included by default in webgl2 and as an extension in webgl1 (which c3 already loads as far as I remember). I’d assume it’s something in webgpu as well, but I haven’t checked.

  • A quick possible fix could be to scale down the acceleration a bit until it’s not adding energy to the swing.

    A likely difference between textbook physics and game physics is game physics is what you call discreet. Aka stuff is done in steps instead of continuously, which depending on the integration method can add or remove energy from the system over time.

    Anyways, I can’t spot offhand what’s amiss with your method.

    Here’s on strategy to do pendulum motion. Basically just let the player move as normal with gravity and whatnot, but once the distance is greater than the rope length it will correct the velocity and position of the player. The velocity correction is done by canceling the part of the velocity going away from the anchor, and the position correction moves it back toward the anchor till it’s at exactly the rope length. 

    vars dist, ang, relvel
Set dist to distance(anchor.x, anchor.y, player.x, player.y)
Set ang to angle(anchor.x, anchor.y, player.x, player.y)

Compare: dist>rope.length
— set relvel to player.vx*cos(ang)+player.vy*sin(ang)
— player: set vx to self.vx-relvel*cos(ang)
— player: set vy to self.vy-relvel*sin(ang)
— player: move rope.length-dist pixels at angle ang

    Just an idea at least. That rope will have a hard length limit to it.

    Instead of just canceling any velocity that would make the rope longer, you could do the acceleration idea with a spring, but I’m not sure it would come out to what you had.

  • One idea could be to move the thrown objects manually vertically then horizontally. Doing that allows you to have logic where if the block starts on the ground it will stick to the ground including slopes.

    A first iteration of that logic to make the thrown block stick to slopes when moving horizontally would be something like this: 

    Every tick
— block: move down

Block: overlaps ground?
— block: move up out of ground
— block: move horizontally
— block: overlaps ground?
— — block: move up out of ground
— else
— — block: move down till just above ground
Else
— block: move horizontally.

    The moving up out of the ground, or moving down till just above the ground is a sub problem that probably could be solved with a loop with overlap checks and moving a bit each step.

    Now I call that a first iteration of the logic since depending on the map you don’t want all the ground to be thought of as a slope. You’d likely want to be able to handle walls, ledges and ceilings too. But that’s mostly just busywork.

    Just an idea at least that you could explore.

  • Well with your current setup after you move things around in your array, you’d want to loop over the array, pick the objects by uid and update the position from the array.

    If that doesn’t make sense then maybe you want to move and wrap those objects around in another way?

    One possible way works if those five instances are the only instances of that object type and you places them in the editor from left to right.

    You’d then add an instance variable “oldx” to the object type and you’d swap the positions of all the instances to the one on the right (or rightmost with leftmost) with: 

    On key pressed
— sprite: set oldx to self.x
— sprite: set x to sprite(self.iid+1).oldx

    To move left instead you’d replace the +1 with -1.

    Or you could do something else entirely.

  • Events start with all the instances picked, so yes count will equal pickedcount before you use a condition to pick less instances.

  • Use cursor.pickedcount instead.

  • What users? What api? What database?

    Unless you make a game that requires a login and requires their email in the registering process you won’t get emails of people.

    Considering your post isn’t spam you haven’t written a complete thought.