R0J0hound's Recent Forum Activity

  • Parsing is a matter of converting text to a list of tokens, and verifying there were no syntax errors. Actually I've found the error checking to be the more involved part.

    Anyways here's my two cents on top of what has been mentioned. I'd go this route:

    1. Convert text to a list of tokens. Basically numbers and operators (+-*/).

    2. Convert the list of tokens from infix notation to reverse polish notation (RPN) using:

    en.wikipedia.org/wiki/Shunting-yard_algorithm

    That will eliminate the parenthesis and make it much simpler to calculate the result. An expression tree is another option but the code to do so in Construct will be more involved.

    3. Evaluate the RPN expression to get the result.

    Here's the current way I've gone about it. 61 fairly organized events although I can see shaving that down further. Handles decimal numbers, the five math operations (+-*/^), parenthesis and negation.

    dropbox.com/s/f7lzeykvp98j1mw/parser_test3.capx

    Older stuff:

    106 events. Same capabilities as the one above. The approach is fairly different. Error checking is done by looking at neighboring tokens to see if it makes sense.

    dropbox.com/s/36fg2ook2g0850o/parser.capx

    70 events with a similar error checking method. Doesn't have ^ but it lets you write expressions like you do on paper with some variables. ex: 2(3), 4x+5y, etc...

    dropbox.com/s/29i3dv40hk4ll1b/simpleEval.capx

    You can also just use the browser.execjs() expression to evaluate the expression. The main disadvantage of that is the user can run any js with it. Not really an ideal situation. You could use a complicated regex expression to verify it only contains stuff you want, or maybe there's other approaches. The second disadvantage is you lose the ability to show good error messages if a bad expression is written.

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

    dropbox.com/s/hryifbtpsgdskhm/scribble.capx

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

    dropbox.com/s/ruzajg48xq1qb6n/scribble2.capx

    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.

    dropbox.com/s/fssu2ujynyj3zia/simple_event_based_physics.capx

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

    dropbox.com/s/kpdxx2xge14fztx/road_gen.capx

    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.

    dropbox.com/s/rxus2szbpsfzlrv/loader_and_plot.capx

    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.

    dropbox.com/s/bya1jhzdtkrrufo/loader_and_plot_gridhash.capx

    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.

    dropbox.com/s/c2a2xy1yn78i0ql/path_follow_3.capx

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

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