R0J0hound's Recent Forum Activity

  • Looks like the “start animation” action isn’t functioning, but setting the animation from the current frame does work.

    So instead of

    Start animation from current frame

    Do

    Set animation to self.animationName (play from current frame)

    Looks like it’s a bug even in C2. Probably worth reporting.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • With just straight and 90 degree turns and intersections I figure you’d need 18 unique tiles (or 6? if you eliminate the mirrored and rotated versions)

    For other angled roads with tile maps you’d usually do something like what asmodean suggested. However you do lose keeping the width of the road staying constant.

    For tiles that can have 45 degree roads with every combination of bend and intersection I figure you’d need 258 tiles before removing the rotated and mirrored versions. It would be way more but as a simplification you’d draw all the tiles within an octagon, and for the corners you’d have a separate tilemap with two tiles for the corners.

    It’d opt to generate all the tiles somehow, and take that opportunity to remove the rotated and mirrored varieties. You probably can get away with less tiles if you limited what intersections were allowed as well. Seems like a bit much to draw them all, and even then it seems like it may be a bit too many tiles to sort through to design levels with manually without some kind of auto tile assistance.

    Here’s a rough template I’d use to draw the tiles. The square is the tile size, and you’d draw the tiles in the octagon within that. The diamonds would be the separate tilemap that would handle connecting diagonals.

  • You do not have permission to view this post

  • Yeah I meant to write variable there

  • Pressing a button to launch a hook and pivoting where it hits an obstacle verses just clicking where to pivot around seems like a minor difference.

    Breaking the problem up into simpler pieces I’d imagine you’re able to see how to launch a hook and see where it hits an obstacle? If not, wouldn’t pressing a button, creating a hook sprite with the bullet behavior from the player, setting the angle of motion up left or up right depending on the direction the player is facing, and finally stopping the hook when it collides with an obstacle work?

    Once you have a hook position you could just use the swing logic from any of the examples you mentioned. I can’t imagine it too hard to just isolate the swinging portion and removing the input method they use.

  • Since it’s vertical you could give the slider called oldy and do an event like: 

    System: pick by comparison: sprite: abs(sprite.y-sprite.oldy)>=10
— play sound
— sprite: set oldy to self.y

    Which means every time the difference between the old and current y position is greater than 10 (the step you’re using for snapping) it plays a sound.

    An alternate way to do the condition would be with an “or” with two y checks, however the abs() lets you handle both at the same time. 

    Sprite: y>=self.oldy+10
Or
Sprite: y<=self.oldy-10
— play sound
— sprite: set oldy to self.y

    Also, you’ll want to set oldy to y at the start of the layout to avoid it making noise when the game starts.

    For a more deluxe version you could handle the case where the slider moved more than one step in a frame so you’d get to hear multiple tick sounds. For that you’d want to mess with the audio action to schedule when a sound will play to offset the sounds from each other. I’d think you’d want to space out the sounds playback time over the next frame which may look something like this: 

    Variable count=0

For each sprite
— set count to int(abs(sprite.y-sprite.oldy)/sprite.step times)
— sprite: oldy to self.y
— repeat count times
— audio: schedule play tick sound at self.currentTime+loopindex*dt/count

    You’d have to look at the manual to verify how to use the schedule playback action.

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

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