Endless runner, custom movement, vivid camera feeling

Hello Scirra community,

I'm working on an endless runner with main focus on its mechanics feel, camera movement and story.

You can play the WIP here: http://www.hinz-art.com/testserver/Cassini_2/index.html

I have some trouble with the "Collecting System" (fly close to yellow circles and press "D"), sometimes the position lerp function does weird things. Especially when the LayerToCanvas coordinates (that tell the collectables the "true" position of the player on Canvas ("CanvasX" and "CanvasY") get negative.

Anybody got any feedback on that? (Or the overall early process)

Would be much appreciated <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

My project file is structured, labeled and commented. If you want to have a look:

https://www.dropbox.com/s/jscin0tpb5tg2 ... d.c3p?dl=1

Have a great day!

Chris

Whenever my lerps causes issues with odd values I use clamp () to prevent excessive values.

clamp (the_value, min_preset, max_preset)

thanks for your reply lennaert

This is what I found in the manual:

clamp(x, lower, upper)

Return lower if x is less than lower, upper if x is greater than upper, else return x.

But I still don't understand how it could look or how I could apply it to my:

X = lerp(Self.X,CanvasX,0.1)

Y = lerp(Self.Y,CanvasY,0.1)

Could you give a plain example please?

Do I get it right that the clamp function sort of gives the X (or Y) value sort of a frame between a min and max value?

Thanks,

Chris

This should be your fix.

https://www.dropbox.com/s/tbab6vf5mpdxo ... E.c3p?dl=0

Set the bullet speed in event 34 very low to see that it works flawless. (flawless as far as i understand your system)

I might have scaled the collector, i forgot (to debug easyer)

So, do not start from my version, all (and only) changes you will find in the collection group + a boolean in the cookies.

Problems ? The 'once while true' had no parent. Without parent it only happens once. Because there is no parent to be changed to untrue (to restart the cycle). The event that was supposed to restore 1 cookie to its default behavior when the sucking was interrupted, picked ALL cookies. I never use a logical 'OR' to filter the picklist, that is confusing and often dont work.

Hope this fixed your problem. Not sure though, dont understand everything in the events, although the flow is NEAT.

Example

A value which is suposed to be between 50 and 100. And occasionally you get a minus value or in the multiple 100s.

Clamp (value, 50,100)

So in effect yes, your framing the allowed value between 50 and 100.

Value = -50 makes it 50

Value = 1000 makes it 100

I didn't look at your events but from what I read from 99instances to go there was another issue.

An application of clamp could have been something along:

× = clamp( lerp(Self.X,CanvasX,6*dt), 0, CanvasWidth)

Which would return a value which actually exists within your canvas x coordinates.

Note I used 6*dt which is the same as your 0.1; but the 6*dt makes the lerping framerate independent.

Thanks a lot 99Instances2Go !

Your feedback helped me a lot with understanding "Trigger once while true" events and your solution seems really elegant <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

I implemented changes based on your suggestion and fixed the bug. Your way worked perfect until the point where the players position on the rotating layer (CanvasX, CanvasY) got into negative values. It started to confuse the set angle bullet behaviour and ignored the destroy on overlapping.

The fix: It seamed like a problem that the collectable object and the player object where on different layers for the lerp positioning to work (even though translating the position by LayerToCanvas etc). So I added a new Object on the same layer as the collectables (called "PlayersDestroyer") set it to CanvasX, CanvasY (the Players "true" location) and made the collectables die when overlapping this object. Works supa smoothly <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Here is the result:

https://www.dropbox.com/s/e17ienhb6h46u ... 8.png?dl=1

lennaert

Thanks for tip with the "clamp" function! I tried it out a little bit but since the current way works perfect It seems like I don't need it. But "clamp" looks really helpful. Now I can use it in the future <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

What was your "most creative way" of using clamp() so far?

Have a great day,

Chris

oh lennaert and I implemented your 6*dt instead of the 0.1 in the position lerp. That was a really nice tip Thanks!

I use them quite often really, often for use custom made movements using lerp and anglelerp and sometimes the calculations are a bit off due to input or coordinates, giving negative numbers or suddenly huge numbers .. or for instance with healthbars, and a player picks up something which increases the healthbar, and to prevent a healthbar becoming to wide, I can constrain the size, i.e.

healthbar.width=clamp(HealthVar*WidthMultiplier, 0, 100)

Making the formula to determine the width of the healthbar never go into a negative size or over the maximum allowed width. (player gets more damage then has health)

The "dt" bits can really make a difference across devices with varying performance, so they all look the same and or move the exact same amounts.

60 * dt = 1 second

lennaert thanks again!

I always used add X to Y unless Y is < 200 for example clamp() will make my life easier now.

And thanks for the 60 * dt = 1 sec

makes even more sense now