R0J0hound's Recent Forum Activity

  • Sorry for the late reply. I can’t say what’s amiss. I have the bad habit lately of not verifying my ideas work correctly. I just haven’t had time to test or debug anything.

    I don’t think I’m much help very often on here anymore. The issue could be with how the conversions are applied, or maybe the conversions are off, or could be the top of my head math and logic are flawed. I’ve buried myself to solve all that and I’m not able to work though it at this time.

  • No idea what topic it was.

    As a quick idea you can loop over all the tile positions, place a square sprite on the tile, and then check for an overlap between that sprite and the other object. If it overlaps, then the current tile is touching the object.

  • Here’s the math for it where dist is the distance to move before stopping and f is the braking force.

    Global number f = -200

    Global number dist = 2000

    Start of layout

    — apply impulse self.mass*sqrt(-2*dist*f/self.mass)

    Velocityx > 0

    — apply force f

    Anyways that would work fairly well. However the units are off with the physics behavior. Here is the info on how to convert the units so the formulas above would work.

    construct.net/en/forum/construct-2/general-discussion-17/math-physics-83966

    As a personal view I find it annoying to convert even though I found the conversions. It’s often simpler to just not use the physics behavior.

    For instance if you used the bullet behavior instead you could set the acceleration to -200 and set the initial velocity to sqrt(-2*dist*-200) and get the same result.

  • I stumbled upon this cool tweet here:

    twitter.com/3blue1brown/status/1145344403210289155

    It's a way to draw shapes with just rotating vectors, or just basically sine waves.

    Here's my initial test. It will scribble random pictures again and again. Nothing too interesting but I found it fun to watch.

    uc603db4f9c924d4df257645b5ea.dl.dropboxusercontent.com/cd/0/get/CiFKqMcm3RAfl_sCUuMNJsSqGd12g3fphfUNnESWTnuLlRZbYlM_UpcB3miTgw38dokQovxrw5B-hmy_yCVyFm1nxF3pi5lbKascrdmeXh6uUPN7mpqz9QbqoD75OKasTNo/file

    Second go utilizing a user made path. Use the mouse to draw a new path while it runs.

    ucf23082fba1348ff6b1a6589b6f.dl.dropboxusercontent.com/cd/0/get/CiEVPohF0UZEqbnyLz1CGU1ZS9dpnMjFOrKpnl_9CWxYrFTnwlzaPgEGZOYYIcKVv_0sls_TTr8X-0019ngK7XfsOd4gqh5KnueiqRbD5HnL4QXWz2EXaRhg3Sjtm1qGUC4/file

    The cool thing about this is it can be easily used to approximate a path with less data points and still be smooth.

    At the very least it is entertaining and actually has a sketchy look to it.

  • Here is an update with rotations, contact point calculations and friction. Although the friction model seems to not be working because when objects are pushed apart it causes sliding. Maybe next time I'll go deeper down the physics rabbit hole.

    uceaf59cfd56c63bf4dcffe576eb.dl.dropboxusercontent.com/cd/0/get/Ch_FcpiCNO08bRhgbqcUrVX60Nq2kAg324-GcbxNkQ8TY11CIEuvDoUKXEnneyIXW-cacADkhwiEZG0lmh_1LHrbE5fkx0xW1MODBdm1TLhLNFvXSSK3jl6HSu-J3WPfIvQ/file

  • Glad it works! I always thought it was a cool equation.

    There are a few ways to improve it later.

    For one I just used the angle from one object to the other for the collision normal. Realistically it should be the angle from one contact surface to the other.

    The other thing you can do is actually calculate the point or points of collision and then adding the rotational motion stuff.

  • Here’s the actual math to do it. Equation 5 to calculate the impulse and 1a,1b to set the new speeds.

    en.m.wikipedia.org/wiki/Collision_response

    You don’t have to do the angular stuff so it can be simpler.

    Sprite collides with other

    Set a to angle(sprite.x,sprite.y,other.x,other.y)

    set j to -(1+e)*((other.vx-sprite.vx)*cos(a)+(other.vy-sprite.vy)*sin(a))/(1/Sprite.mass+1/other.mass)

    Sprite: set vx to self.vx-j/self.mass*cos(a)

    Sprite: set vy to self.-j/self.mass*sin(a)

    Other: set vx to self.vx+j/self.mass*cos(a)

    Other: set vy to self.vy+j/self.mass*sin(a)

    That’s with three variables

    a = the angle from sprite to other

    e = bounce amount. 0 to 1 range

    j = the impulse

    Also I used vx and vy for the velocities. You can get that from angle and speed with:

    Vx=speed*cos(angle)

    Vy=speed*sin(angle)

    And vice versa

    Speed = distance(0,0,vx,vy)

    Angle = angle(0,0,vx,vy)

    Anyways hope that helps.

  • Hi, here are some further thoughts and experiments.

    Road types and intersections:

    It's probably simpler to use uniform width roads initially anyway. Here is one hack attempt to do the roads with edges and center dashed line. The dashed lines could be made to go to the center of intersections by using another object with this setup, although i realize that's not how intersections look. Any look can probably be achieved with some thought. doing the drawing with polygons could be a cleaner idea possibly.

    ucb0d3a10fffe65eacbc503ed13d.dl.dropboxusercontent.com/cd/0/get/CiDrv1bj8v2Aw2dGXB5FXa5eDsoKl8-CJKkHwWe-SAG-cGGB21TbNapUqJ47RacQPBIT3jKrKdSpBcFvqRWF4kvqkmKllcEAKMuyXOT8fhNwU79wZyouLVYA6_rY8NvMw6s/file

    Different levels would probably be easier with 3d polygons, but those don't really exist in construct. I see you did a layering+zelevation way of doing it in your other posts though.

    Also, by drawing roads in game, i meant it as an idea to make a dev tool in your game to make placing and designing roads easier for yourself. They could be used for the player to utilize later i suppose, but primarily it would be so you wouldn't have to do it all in construct's editor.

    Finally here are some tests about dealing with a large amount of roads. I wasn't going to design all that but i did find that i could get real road layouts with Open Street Map. It lets you export an osm file of the current view. It's just xml inside, and i could convert the relevant parts to something i could parse in construct easier.

    uc59b33dc3c7073eddeb8edcfae6.dl.dropboxusercontent.com/cd/0/get/CiDR52DKrsw6gXRXCQRjJ4823i_5PwtzYr6M3QzLRSH7ImiHy02PlQ6gVO9IAGDQXIQ65OZZGZDvcOs4Z-DhwKQULsg1bztfUsUjZ4CJFfVtdjoajnYo7BZ8fwrC5VrTA8A/file

    That's clearly a lot of sprites to draw, so I scaled it up and did an initial first pass at splitting the map into grid chunks, and only drawing the chunk the player is on. Normally the transition would be seamless, but it was only a rough test. I wonder though if Construct's built in hashing would be acceptable enough.

    uc3b711383c4418bd71cbc92120c.dl.dropboxusercontent.com/cd/0/get/CiAQb0LdBndZniMQ-TpG8K8KuW1qyZC5GFd3At3EyuN28jciqobtLrD9fp8cF7BgKMwcWYyNXKMS-E8Qz-fba7m-PEPl61PEv3LRnPc5uwGyZvjCZstjrivdEkI3ua7w_YY/file

    Anyways i thought those capx were fun to share. I do think i missed the mark in making something completely useful. Hopefully it's helpful or interesting.

  • Before settling on a way to tackle this I'd try to better define what I want to do. Go full hog at first and then whittle down features till it's more reasonable and doable.

    Will I want all the roads to be the same or would I like variations like driveways, multi-lane highways, country roads, etc...

    From the above I'd want to try to think up how I'd want the intersections and transitions between the roads to look. Probably make lots of diagrams as examples.

    Would you want different road heights? Bridges and tunnels?

    To define the roads you could just make up a bunch of building block images of road pieces. They don't have to be grid based but in practice it's hard to have them match up otherwise, although I'd imagine it's possible.

    For full analog with roads going every which way I'd go with generating the road graphics with code. The intersections would be trickier but then again I'm not really sure how I'd want them to look. Roughly off the top of my head a straight road would be a solid color rectangle with two fog lines on the side, and a dashed yellow line in the middle. Curved roads are just multiple straight roads, and intersections could be done by drawing a solid color polygon over the intersecting part. Again I'd need to figure out the different looks for intersections and maybe make it so you could choose form different styles.

    To define the roads I'd want to keep the tedium to a minimum. You could probably simplify defining roads to just drawing lines and have the intersections figured out with code. The constuct editor isn't suitable for defining a bunch of lines like that, so I'd either make an in game editor or utilize some vector drawing app and pick a save format that I can pull the lines from with minimal coding effort.

    For in game you'd want to be able to draw all that reasonably fast, and since you would usually be pretty low you'd only need to draw the roads with all their details around the player. You wouldn't want to have to check every road so you could just have large squares that roads are part of, and if the square is in view just draw all the roads in them.

    Anyways just some ideas. I'd do a lot of mini tests with the different aspects to see if they are achievable. I'd probably simplify things down a lot to make everything more doable in a reasonable amount of time.

  • Here's another example. With it you can either define the path with the order you create the nodes, or set the node.order variable to define the order and event 4 with recreate them in that order. They don't have to be sequential numbers, just as long as the next one is higher than the previous.

    uc5d9de4213f67648139a7470441.dl.dropboxusercontent.com/cd/0/get/Ch7iwxw00-n0JjuRT9WsCsd9v8YsLzjN-PGAIWYNFok_3ktoBEj7P24Cczkzeppv-wQPUBQbGuPk2QOccXisrGONvfb5_zMkMsnk_yAdtWtZSTOLszGZTXXtI_O4PY5GVZ0/file

    The con with this method is it only allows one path.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The nodes have an instance variable “links”, which is a comma separated list of the Uids of the connected nodes.

    So say you wanted a path through four nodes with uids 2,5,3,6 you’d do this:

    Node 2 links = “5”

    Node 5 links = “2,3”

    Node 3 links = “5,6”

    Node 6 links = “3”

    If that makes sense.

    Since you just want to be able to move forward and backward on the path my capx isn’t quite suited for it. It can be made simpler but I’ll have to look at that later.

  • The upside down T sounded interesting, which is basically a path that has branches. Here's what I came up with. Defining the paths is pretty tedious since you have to place a list of the uids of all the connected nodes in each node, but the events are fairly simple albeit dense.

    ucb8dff92cb2ba20a0fd0871cf44.dl.dropboxusercontent.com/cd/0/get/Ch5bQtc9eC1ICBVUevMQJSRYXSTbtTzEeHUAEjrevrBv0fjZ2A0qpVEcUHc6HuPynjoaL4JafrvXlGSM3UFGliimDG8YjG5rE9uxbEcwNoS-4Y7shG0b0FZnPuxih4-wkHc/file

    The motion is driven by the the input angle. If the object is between nodes the object will move forward or backwards depending if the input direction is pointing more in one way or another. Also when a node is hit it will look at all the connecting nodes and pick the one with the lowest anglediff with the input angle to move towards.

    The events a mostly easy enough to follow I think. The exception is probably the formula in event 13:

    obj: add (cos(inputDir-self.ang)>0?1:-1)*speed*dt to d

    inputDir is the angle from the keyboard input

    self.ang is the angle between the current pair of nodes.

    cos(inputDir-self.ang) is the dot product between two unit vectors made from those angles. It just simplifies to that. If the dot product is positive then the inputDir is mostly in the same direction as the angle between the nodes. And if it's negative then it should go backwards.

    The conditional ...cos(inputDir-self.ang)>0?1:-1 is to make it only positive or negative 1. That is to keep the speed constant.

    The remainder is to apply the speed in that direction with dt.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 156 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies