R0J0hound's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

  • One idea would be to loop over the tokens and rebuild the comma separated list.

    Var a=“1,2,3,4,5”

    Var b=“”

    Repeat tokencount(a,”,”) times

    — loopindex=2

    ——add 44&”,” to b

    — else

    ——add tokenat(a,loopindex,”,”)&”,” to b

  • Wouldn’t it be better to create a new replacement plugin than to port it?

    They aren’t that high quality. But I guess if you just want it to work the same by all means.

  • Some plugins will never be ported. Either the dev isn’t around anymore, they don’t use c3 for some reason, or they just don’t have any interest.

    Porting to the new runtime adds more obstacles to port from the above mentioned reasons. One being the plugin may have relied on some internals of constructs runtime that changed.

    The only situation where you could say a plugin dev was unwise to port a plugin was maybe if they were selling it. Still, that’s up to them.

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 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