...have a camera follow a player's finger

Ok this question has two very important parts. I had worked it out well in GameSalad, but C2's approach is so different I've have had trouble applying the same logic / approach to C2. I'm sure its basically doing the same thing, but expressed in a way i'm still not used too.

This is what i'm looking to do..

1. have a camera object (this would be an invisible object with the scroll to behavior attached to it) follow a player object that moves around the screen. the player object being essentially the finger of the player.. on the screen it would be the shadow of the player's finger..

NOTE: using a pathfinder example on the forum i kinda hacked a way to make this work, however this feels over engineered because there are no objects in my game that would require true pathfinding.. i would just want the camera to constantly be attracted to the players finger.

2. in addition to being attracted too the finger, how fast the camera moves should be slower as it gets closer to the finger and faster when the finger gets further away.. this helps create a nice sense of control where the player can move faster or slower through the obstacles..

here is the game via GameSalad that i'm trying to explore building with C2

youtube.com/watch

I think an answer to this would greatly help my understanding of "how C2 thinks" which i'm trying to learn and unlearn my assumptions from GameSalad.

Thanks!

Caleb

This is actually quite simple. You need to add a small, invisible sprite to your game. I call it camera. Give it the "Scroll To" behavior. The game will always scroll instantly to that sprite, so you're really only concerned with how that sprite moves.

+Every Tick | set camera position to

............lerp(camera.X, touch.X, 3*dt)

............lerp(camera.Y, touch.Y, 3*dt)

Lerp does half the distance between the starting point (where the camera currently is) and where it should be (touch). This creates a natural deceleration the closer it gets to its target, and is extremely simple to set up. You can change the "3" to whatever you want. 3*dt means it will arrive in 1/3 of a second. Make it a bigger number to go faster, smaller to go slower (decimals even, if you wanted).

Dude that rocks! totally worked.. plus you just taught me about "every tick".

thanks so much!

Where could I learn about Lerp and other important stuff like that?

Sincerely,

Caleb

The "Manual" link at the top of the page, of course!

It's actually quite helpful, isn't too dry, and is practical. It doesn't read like a manual, it reads like tutorials.

There are essentially two types of conditions--they're all variations on those. Every Tick and Trigger Once. Every tick is something that is a process or continues over time (moving an object over time, for instance). Trigger Once happens when a certain condition is met once. You'll use other things like "is X> 40" or whatever to narrow it down. You can add "trigger once" under "system" to a normal event to make it happen once while that condition is true. Those two types of actions can build a game--and eventually you'll get fancier and add loops and arrays, etc.

But read the manual, check some tutorials, look at the example files that come with C2. It's all helpful stuff.

BTW, before you do it any other way, do all of your movement or anything that happens over time *dt (multiple by delta time). This will make your game smoother and framerate independent--which you want.

Every Tick | Set X to (X+20) works, but now how you want. Will run differently on each computer.

Every Tick | Set X to (X+150*dt) works how you want. Will run the same on any computer, is smooth.

dt can be confusing at first, but you don't really need to know how dt works. The best way to think of dt is how many pixels you want an object to move in a second. So in the example C-7 gave (X+150*dt), the object would move 150 pixels in a second, and that's why it's consistent across all computers / devices.