R0J0hound's Recent Forum Activity

  • An event based AStar algorithm is quite doable. If you search for posts by me that mention “astar” you’ll find a lot of examples. I’ve seen other users post examples too on here.

    If you want to make your own I’d recommend the site redblobgames. It is one of the best references of how to do it.

    The part of the algorithm you’ll want to modify is the part that looks at the neighbors of a location. For grid based it’s the four directions. For hex based it’s six. For node based it’s whatever other nodes that are connected. And since it will be event based you can have the obstacles different for different purposes.

  • Event sheets are their own thing. I just call it construct event sheets. It has similarities to other programming languages. The expressions are very similar to c/JavaScript, but the conditions and picking are fairly unique.

    Html5 and JavaScript is mainly how things are implemented behind the scenes. But that’s mainly an implementation detail. They could’ve implemented it in anything. But since the primary export is html5 that’s what they decided to focus on.

  • Construct 3 isn't a 3d engine. Easiest would be to just fake as much as you can. But here are some thoughts on various ways to do shadows such as "shadow mapping", "shadow volumes" and "ray casting". In construct there are limits but we do have math, distort meshes, canvas and shaders that can be used in creative ways.

    Shadow mapping

    This is a common way to do shadows where you first render the scene from the point of view of light to a depth texture and then use a shader when drawing from the camera's view to tell what is in shadow.

    Construct can only render one view at a time and the canvas has no depth. However you probably could make an effect that takes the depth and draws a color. Then you could change the view from the light, use the effect to draw the depth as colors, snapshot the screen, then use that texture with another effect to draw the shadows.

    - you need to have the camera and view matrices. It's not readily accessible but you can calculate them manually.

    - you have to write shaders. You are also limited number parameters in C3 shaders so you will have to adapt any online guide about shadow mapping.

    - not suitable for Realtime since you have to dedicate a frame to draw the depth.

    - on top of that capturing the screen can take a bit.

    - Lastly and most importantly It can't work because we can't access multiple textures in shaders in C3. I can't think of a workaround for this.

    Shadow volumes

    Uses polygon clipping to find what area of each polygons are in shadow. Often done along with BSP trees to be more efficient.

    - you need a list of the vertices and faces. C3 does not provide access to those so we'll need to calculate and provide them ourselves.

    - BSP trees are needlessly complex to implement in events, but even with them this shadow method doesn't scale as well with higher polygon counts.

    - will give perfectly crisp shadow edges, and will be 100% black without further trickery.

    - will have to draw the shadows over the mesh with distort meshes. Probably will have to move slightly toward the camera to avoid z fighting.

    - This is the closest to being feasible in vanilla C3 solution, but it may not fit in 25 events.

    - may only be fast enough for Realtime with low poly counts, but it would have to be made first to find out.

    Ray casting

    This is an alternate idea to make the 3d objects from canvas' wrapped with distort meshes. The idea is to shoot a bunch of rays from the camera and when the mesh is hit you'd calculate where on the canvas object was hit and color that.

    - it would be pretty slow so you'd only be able to shoot a few hundred rays per frame. But over time it would be better shaded.

    - It would also not scale well with higher poly counts.

    - as with the other approaches it would take a fair amount of 3d math with matrices and vectors.

    Overall even without the limits of the 3d in construct those are all fairly involved to do. The second way seems almost doable but likely just as a novel demonstration.

  • Html5 and JavaScript is what the engine is made in. But as a user you are typically using the event sheet to do the logic with the option to use some JavaScript.

    So unless you’re using some JavaScript you’re just programming with construct’s event sheet which isn’t JavaScript.

  • That's close to what I meant. I think the 8direction behavior just gets in the way.

    The 8direction behavior already limits the speed to the maxSpeed so all you need to do should be:

    1. set velocity of x and y to 0.

    2. when a direction key is pressed add to the velocity a direction vector:

    maxSpeed*cos(a), maxSpeed*sin(a)

    That should handle diagonals and such, unless something I'm not aware of occurs in the behavior.

    An alternate idea is to have a hidden object with 8dir that you move normally but without collisions. The rotate that object's velocity and set the velocity of a visible object. It would give smoother speeding up and slowing down, but it still wouldn't update the velocity when hitting solids.

    ucdf704448b26b08880cbc18f52f.dl.dropboxusercontent.com/cd/0/get/Ch80ScNDV0U_0KdQTs8AW5JO1aJVnDRoPs8v8wPzT9_fh62h6DtK1yZKBJa2Ifm5MSI14O9e7NlK8GZSbXaihV25_kmJZljOUpFELI-JP3k2PO3x77pTTWj9i6Vbh6r_BsIfzoBHwrG8msk-gWim1K-a/file

    Or here is an older example of the 8dir behavior done with events sans collisions. You just set the angle of the sprite and motion will be relative to that.

    There may be a simpler way. I guess I didn't really answer your question. But having a few example of various ways to do it could be useful?

  • First the distance(0,0,vx,vy) is correct. Vx,vy is the velocity vector and that gets the magnitude of that vector. For velocity the magnitude is the speed. You can also calculate it with sqrt(vx^2 + vy^2).

    Anyways for motion logic you’d set vx and vy to zero and just add any directions you want.

    The final step is to limit the speed to a max speed.

    Here’s another possible way to do it. I mean you can apple the speed of 100 as a last step.

    every tick
    -- vx=0
    -- vy=0
    
    if up pressed
    -- set a to player.angle
    -- add cos(a) to vx
    -- add sin(a) to vy
    
    if right pressed
    -- set a to player.angle+90
    -- add cos(a) to vx
    -- add sin(a) to vy
    
    ... etc for other directions
    
    if vx<>0 and vy<>0
    -- set mag to sqrt(vx^2+vy^2)
    -- set vx to 100*vx/mag
    -- set vy to 100*vy/mag
  • You can find a list of words in a file online. You can then parse and load them into construct.

    construct.net/en/forum/construct-3/how-do-i-8/store-check-english-words-168954

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Looked in your file briefly. I don’t have a whole lot of feedback other than it’s very different than what I did in my capx.

    I tried to move all the logic in the click function. Yours has it multiple places.

    In mine it doesn’t refer to the mouse or touch at all in the click function. The idea is that function is called for every click xy. Can be modified for touch xy as stated in my previous reply.

    Sounds like you may just want to record the keys instead. Just the time a key changes to pressed from not pressed and vise versa. You wouldn’t have to worry about recording input then and you’d have more freedom with using any input events you like.

    Anyways, just some thoughts.

  • You can set the velocity in a specific direction with a bit of trig:

    Vx=100*cos(a)

    Vy=100*sin(a)

    You can also combine two velocities by adding them.

    Vx=100*cos(a)+100*cos(b)

    Vy=100*sin(a)+100*sin(b)

    Then to limit the max speed you can do this

    Speed=distance(0,0,vx,vy)
    If speed>maxSpeed then
    — vx = vx/speed*maxSpeed
    — vy = vy/speed*maxSpeed
  • You can set the velocity in a direction with

    a = angle(sprite.x, sprite.y, mouse.x, mouse.y)

    Set velocity to 100*cos(a), 100*sin(a)

    Impulse is more like adding to the velocity so that could be done with:

    Set velocity to sprite.platform.velocityX+100*cos(a), sprite.platform.velocityY+100*sin(a)

    Or something like that. I may have the names wrong.

    For either 100 is the strength of the impulse.

  • I mean you can fiddle with the collision more. It may work better if the ball has a box collision and isn't rotated at all. You can use the "set angle of motion" to let you shoot where you aim.

    If the bullet behavior's bounce still isn't acceptable you can use the physics behavior instead to move the ball. Give the tilemap and the ball the physics behavior, make the tilemap immovable, and when you launch the ball you'd set it's velocity with:

    set velocity to (speed*cos(angle), speed*sin(angle))

    You may need to fiddle with some of the ball's physics properties to tune it. Stuff like collision shape and elasticity. You may need to disable collisions between balls or change the gravity with events.

    If that still isn't satisfactory you can calculate the surface normal of a collision and do the bounce with math. Here it bounces a perfect ball with a tilemap. This gives more control but isn't as simple to drop in.

    uc4427a938fe6f01645b9097f6aa.dl.dropboxusercontent.com/cd/0/get/Ch5dfrJQI33Cz8oujegvSjaIiSboVO05Ktn6d0q_TPb-uQ-COolBJF3GxUzRhRCP-nrc6MpEJKawB-ncWX_TLuzUWpQxo9RCPKsXf31hFBTXOZFUusA653mZP1Ayb6IpM-T7n1D9Jv1vaHaUlus5aJ7G/file

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 155 followers

Connect with R0J0hound