R0J0hound's Recent Forum Activity

  • Shift+enter to add a new line in comments.

  • If it helps all the motion equations are defined by this equation: 

    rate x time = distance

    vz is the rate that z is changing (the velocity)

    dt is the time is the duration of the frame

    so vz*dt is the amount that z changes in a frame

    In the same way we can apply gravity to the velocity, since gravity is an acceleration, which is the rate of change in velocity.

    So g*dt is the amount that dz changes in a frame.

    Or just simply: 

    every tick:
-- sprite: add g*dt to vz
-- sprite: add self.vz*dt to z

    Next we need to decide what z value would be the ground. This is fairly arbitrary, you can pick any value. I initially used 1, then changed it to 100, mainly to simplify the math with the perspective scaling. We also need to decide what direction z goes, whether into the screen or out of it. It doesn't matter which, but it does affect the values you'd use for vz and g.

    Let's be simple and say z=0 is where the ground is. Let's also say that into the screen is positive z, and for our physics lets consider positive z as down.

    So if gravity is down then we can make g = 10. So the object will accelerate down into the screen.

    To make a nice arc instead of a freefall we'd make vz=-10 so it goes up first.

    Here's a nice diagram of our setup showing where the ground is, and the directions of gravity and the initial velocity:

    Next we can figure out when and how to bounce.

    Well it makes sense that a ball would bounce when it collides with the ground. So a collision would be when z=0? Yes, but the calculations can make the z move past 0. That would make a collision when the z is greater than or equal to 0. So viola we now can detect when the object is on the ground, aka this can be our condition. 

    sprite: z>=0
-- ...

    Here's a visual of the z position frame by frame and a possible example when a collision is detected:

    Notice the object can have moved past the ground before the collision is detected. Let's fix it by moving it to be on the ground. 

    sprite: z>=0
-- sprite: set z to 0

    Note: this pretty much does what I used the max() expression for in my op.

    Now that the object is safely resting on the ground, even when it tries to move past, we can now consider how to bounce.

    Bouncing is really simple, just reverse the direction of the velocity. We do that by making the velocity negative. 

    sprite: set vz to -self.vz

    It will bounce to about the same height as it was dropped from. To make it bounce less we can just multiply the velocity by a number between 0 and 1 when we reverse it. Let's make each bounce go only half as high, so we'll use 0.5. 

    sprite: set vz to -0.5*self.vz

    Sweet. So that would make the whole collision detection and bounce event this: 

    sprite: z>=0
-- sprite: set z to 0
-- sprite: set vz to -0.5*self.vz

    All that takes care of the motion and bouncing, but it gives us no visuals. We want the sprite to scale as if it was getting closer or further from us as the z changes. So first lets look at how such scaling is done. A diagram is great for this:

    We see an eye, an object and the screen. The size of the object's shadow on the screen is the size we want to scale the object to to make it seem that close.

    Notice that the triangle from the eye to the object is a scaled version of the triangle from the eye to the screen. For those interested you can dirive the the equation for z scaling from this. I'll keep this simpler by just giving the equation: 

    sprite: set scale to eyeDistance/(self.z + eyeDistance)

    In similar fashion you can move the xy position with something about the same for more effect.

    eyeDistance is the z distance from the eye to the screen. We just choose a value for this. 100 works well for our purposes, but we can change that to adjust the strength of the effect.

    Anyways here is the whole example: 

    {Editor setup:}
Sprite:
z=0
vz=-10

{Events:}
global number g = 10
global number eyeDistance = 100

every tick:
-- sprite: add g*dt to vz
-- sprite: add self.vz*dt to z

sprite: z>=0
-- sprite: set z to 0
-- sprite: set vz to -0.5*self.vz

every tick:
-- sprite: set scale to eyeDistance/(self.z + eyeDistance)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • No reason really. Adding a negative number is the same as subtraction. Plus it’s faster to change.

    I don’t have Twitter. Just here.

  • There are more elegant ways to handle it.

    Basically I started with z is the distance into the screen and 1/z is to get the scale.

    Basically z=0 is the eye location.

    Z=1 is the ground

    And z<0 is behind the eye and should be hidden otherwise things scale up again negatively.

    If we just had stuff going away from the camera it would work fine. The objects would get smaller. The problem is the objects are going up and only have 1 unit to move before being behind the camera. So I just scaled everything down.

    A better solution may be to use z=300 and the ground level, and make vz negative, and g positive.

    Then the scale would be:

    300/z

    Yeah that would look cleaner.

    Further reading would be “perspective transform” on Wikipedia or elsewhere. I’ll see if I can make a simpler example/better explanation later.

  • That was the line where z was added to.

    I also forgot to take into account z scaling. Edited the op with the changes.

    It uses (100-1)/(100-z) for the scale now. Change the 100s to adjust the amount of scaling. It may be ok to just use z directly like before. It all depends what is acceptable.

  • Probably something like the following. Only considering one product but it’s basically the same for multiple. 

    Global number wallet=5000
Global number applePrice=45
Global number applesOwned=0
Global number quantityToTrade=10

Wallet < applePrice*quantityToTrade
— disable buy button
Else
— enable buy button

On buy button pressed
— add quantityToTrade to applesOwned
— subtract applePrice*quantityToTrade from wallet

quantityToTrade > applesOwned
— disable sell button
Else
— enable sell button

On sell button pressed
— subtract quantityToTrade from applesOwned
— add quantityToTrade*applePrice to wallet

  • Intuitively the one doing more steps would be slower, but here it is negligible so it doesn’t matter.

  • There isn’t a way to make a path in the editor, but as one possible solution you could place a bunch of sprite instances along a path and use that.

    Create a sprite and call it “node.” Give it and instance variable called “order.”

    Now just make multiple instances of node and position them in the shape of the path you want. Then set the order variables for each instance. 1 for the start, 2 for the second and so on. This is so we can move along them in order.

    Next we need to setup the object that will move along the path. Create a sprite and call it “follower.” Give it some instance variables:

    pos=0 for it’s position on the path

    speed=10 for the speed along the path.

    Anyways on to the events to make follower to move back and forth along the nodes:

    Every tick

    — follower: add self.speed*dt to pos

    Follower: pos<0

    — follower: set pos to 0

    — follower: set speed to -self.speed

    Follower: pos>node.count-1

    — follower: set pos to node.count-1

    — follower: set speed to -self.speed

    Global number t=0

    Global number id1=0

    Global number id2=0

    For each node ordered by node.order ascending

    — follower: pos<=loopindex

    —— set id1 to node.iid

    — follower: pos>=loopindex

    —— set id2 to node.iid

    ——stop loop

    Every tick

    — set t to follower.pos-int(follower.pos)

    — follower: set x to lerp(node(id1).x, node(id2).x, t)

    — follower: set y to lerp(node(id1).y, node(id2).y, t)

    That will change the followers pos variable with the speed. If it goes off either end then the speed is reversed and the pos is limited to the end.

    Next we loop over the nodes to find the instance right before and right after the object’s current pos.

    Finally we use lerp to get an actual xy position between those nodes.

    Note:

    Speed is how fast the follower moves from node to node. So for consistent speed keep the nodes evenly spaced.

    The events were done with only one path and one follower in mind.

    Barring any typos the above should work.

  • Use three instance variables:

    z =100 for the z position

    vz=-10 for the z speed

    g=10 for the gravity

    Then with events:

    Every tick:

    — sprite: add self.g*dt to vz

    — sprite: add self.vz*dt to z

    — sprite: set scale to 100/max(100,self.z)

    It’s still parabolic but simpler than using the parabolic equation because you’d have to do more on top of it.

    Anyways you’ll have to adjust the variables to get the effect you want.

    If the object gets too big, make vz smaller.

    If it happens too fast or slow, then adjust g. Keep in mind you’ll need to adjust vz after that too.

    The use of max() in the set scale action limits the scale to never be lower than 100.

  • You could turn webgl off in the project properties.

    With it off the text objects are drawn directly to the game.

    With it on the text is drawn to a hidden canvas and that is then copied to a webgl texture, which can then be drawn on screen. Of course the copying is only done when the text changes.

  • But why are you creating roads every tick?

    The straight parts of the road can be done with single stretched rectangle sprites, and the rounded turns can be done by putting a circle sprite at the turns. It ends up looking the same as in the video of your game anyway, plus only uses maybe 20 or so sprites at any given time.

    You shouldn't be generating road by time intervals anyway. Just add more as the end of the road gets too close to the top of the screen.

    Destroying the road should be as simple as just checking when the y is below the bottom of the screen and it's off screen.

    uc88e55a465077cdbd7d87ed981e.dl.dropboxusercontent.com/cd/0/get/CiAZ5BKUhq96l38_4k1e-3TSUQ_3QnVOIA_2DlCaj5L5V3N6pV0iBsmAFO8xAsEWlvdqcVxqXxKfsAueEY80xnsiNSFlFqsm-6VOdbLJ3_NWMR2MvZtAO42aRjhPjDj_5h8/file

    At any rate this is how any similar games you've seen would do it.

    In the example the view is fixed and all the sprites are moved down. You can do the opposite, leave everything fixed and just scroll down. The only real change other than not moving the road would be to to reference the top and bottom in the view instead of using fixed y positions.

    So instead of y>-100 use y>viewtop-100

    and instead of y>480+100 use y>viewbottom+100

    I apologize if that's not the names of those expressions, but the actual one's should be similar.

  • An array is just data, if it’s really big don’t loop over the whole thing at once and it won’t cause an apparent hang.

    You can look at the browser console for more details about what the “network error” may be.

    You could also look into compressing the data before sending it. Also if it’s tilemap data why not put it in a tilemap first before getting the json. It will be smaller that the json from the array object.

    Instead of using a separate program to generate the json that runs in the background, I’d reccomend doing it in JavaScript instead so you don’t have to deal with network file transfers.

    You could do the generating in events too. The key here is to do stuff over many frames instead of all at once to avoid long slowdowns that would seem like a crash to the browser.

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