Smooth Circular Frame Scrolling

I'm trying to make the screen scroll in a way that follows the ball in my latest game. I want it to be able to only scroll a certain distance from the center, and the camera object follows the ball, kind of like a tetherball. So far, I have the angle and distance between the center camera and the ball defined as:

Code:

---

Always Set ballTrackAngle("camera") to ATan2(currentY( "camera" ) - Y( "camera" ), X( "camera" ) - currentX( "camera" ) )
Always Set ballTrackDistance("camera") to Abs(X( "camera" ) - ballX( "camera" ) ) + Abs(Y( "camera" ) - ballY( "camera" ) )
Always Center Horizontal Display at X=X("camera")
Always Center Vertical Display at Y=Y("camera")

---

These work, and the code for the scrolling mostly works.

Code:

---

When Ball is in Play Area: Set X("camera") to ( Frame Width / 2 ) - Cos(ballTrackAngle( "camera" ) ) * 50
When Ball is in Play Area: Set Y("camera") to ( Frame Height / 2 ) + Sin(ballTrackAngle( "camera" ) ) * 50

---

The problem I'm having is that when the ball gets too close to the camera object, the camera swoops around it somewhat to adjust. A regular swoop is noticeable at lower speeds, around 8-16, but where I need it, at 32+ (currently 50) the screen shakes like CRAZY! That's not exactly where I want my Vlambeer effects. Can anyone point me in the right direction please?

I would post an example but the game has gotten way too big and in-depth to post. :(

I had a somewhat similar issue with a much simpler setup,
when the camera was supposed to simply follow the player in linear way,
but when the camera was getting too close to the player, it started shaking around to find the player center position.

The solution I implemented was actually stopping the camera upon reaching the player.
You could try adding a coordinate-proximity check to test wether the camera is too close,
i.e. adding this as a un-triggering condition in your events:


Ball is in Play Area
+X camera < X ball -5
+X camera > X ball + 5
---> Set X("camera") to ( Frame Width / 2 ) - Cos(ballTrackAngle( "camera" ) ) * 50

Ball is in Play Area
+Y camera < Y ball -5
+ Y camera > Y ball + 5
---> Set Y("camera") to ( Frame Height / 2 ) + Sin(ballTrackAngle( "camera" ) ) * 50


You could try to see how it would look like, don't know if this could give an acceptable effect for your app..

Oddly this has put the camera outside the field of play, toward the bottom left of the screen.

I feel speshul.

I was fearing that :(
fact is, as I said, mine is a much simpler setup,
this is supposed to work if your camera would get close to the ball in a linear manner
(i.e. the camera following the ball when it gets far from the center of the screen, simply by altering its X-Y coordinates towards the goal)

but from your code it looks like the camera follows circular (inverse?) paths along the ball,
and this of course is harder to track...
for a more accurate checking I guess we should have info on how you're setting variables currentX/Y "camera", ballX/Y "camera"
and possibly a cup of chamomile XD

I'll get the kettle going!

Basically ballX and ballY always store the current X and Y position of the ball. currentX and currentY are the "real" coordinates of the camera, as there is also screenshake included, so these help set them back and keep the arcs of the cameras curves based on those instead of the shaky coords.

The ideal path of the camera is to have it stretch out toward the ball and follow it at a maximum radius (currently defined at 50), then pull back in toward the center as the ball comes closer to center, then return back toward maximum radius as the ball flies away from it.

Think Breakout in 360 degrees, and with an arcing/shaking camera. Yeah, ambitious, I know, but it'll be out by July if I can figure this one last challenge out. The rest is basically done.

Best practice is to always simplify your logic as much as possible. My preferred approach is to use helper (or hidden) objects as much as I can, this most of the time works and gives me what I want without the hassle of complex math.

Try it.

Third cup of chamomile here, still no luck :O

I'd have to agree with Click_n_Create,
helper objects really .... help X) in this kind of situations,
also, physics may be the way to go for cool rotating/torqued effects.

It is still not completely clear to me how your camera should behave,
I'm thinking at it this way:
-follows the ball from behind (so if the ball aims direction down-right, camera follows from its top-left)
-follows the ball at increasing distance when the ball is further from the center of the screen, smaller distance when the ball gets closer to the center

Is it correct?


By the way, great and ambitious concept indeed!
Hope you will be going for July, even if it will be with a camera nailed to the ball XD

Actually the camera nailed to the ball works fine, it's just that it also makes me NAUSEOUS! That ball bouncing all over the place, the camera bouncing around with it, sometimes shaking... dear god, this is supposed to be a ZEN game, not a vomit-inducing one!

The way you described the camera is pretty accurate. Here is a quick JPEG version I whipped up:
Attachment 16535

So the idea is that the camera starts at the center of the frame, follows the ball in the direction it's going, but can only move out to a maximum radius. When the ball is in the center of the frame, it too should be in the center of the frame. If I added a variable that increased the camera's speed as it got further away from the center, that might help, but then it might also get stuck in the center.

If I were to add in helper objects, what exactly would they do? I don't want to be needlessly adding in tons of actives when I'm so close with just a few sines, cosines, and variables.

Yeah, I got what you're saying,
in this scenario only few (one) additional objects could help,
maybe by giving them an apt builtin movement and some additional corrections,
just to ease a little the math on coordinates.

Sorry for so many questions and so few advices till now,
fact is I'm actually having hard times simply recreating the basic nauseous XD movement,
so, knowing how this was supposed to work, I could have paved my own road towards that goal.

From your image I suspect my original idea was wrong, by the way,
since I thought camera would have always followed ball at a certain maximum distance from the ball (increasing at frame edges),
instead from your picture I realize that the camera has a maximum fixed distance from the frame center, and is bounded to that,
so that ball can also leave visible area when too far from screen center, correct?

This could be easier than the monstre thing I was thinking/trying to recreate XD
(but I'll go with stone foots on this)

If night will be long enough, I'll try anoter test to setup such a movement and see if I can manage to address the eventual resulting shakiness,
meanwhile, keep that kettle going! XD

So the way the game is set up, there are dynamically generated walls in different shapes that can bounce the ball back toward the center, but the walls also have holes. So if the ball goes through, game over, much like the bottom of the screen in classic Breakout. So yes, the ball CAN leave the frame area, but if it does, you lose. Although the game is set up very casually, so win or lose it just generates another level. Winning nets you more trophies to unlock more features of the game, though, and challenge levels are played every 5th win in a row. I'm building those this week.

Attachment 16539Attachment 16540Attachment 16541

For basic nauseous camera movement, pretty much just keep the camera object at or near the ball, and center the horizontal and vertical scrolling of the frame on the camera. You'll see what I mean.

But yeah, the camera needs to only be able to move a max distance from the center of the frame​, not from the ball. Its only relationship to the ball is the general direction it's moving at any given moment.

Am I completely mistaken, or is it supposed to do something like this?

Attachment 16542

A little bit, but not nearly as jerky. The reason I went for the trigonometry route was so that the camera could more smoothly arc between positions, instead of hitting sharp angles. Maybe this is translatable into what I already have, with the distance and angle variables already set and working fine.

Try this example:

Attachment 16543

It's not using trignometry to do any radious limit, but i believe that it's probably good enough.

The camera tracking limit is calculated relative to the CameraObject Active, so this way you can position it where you want.

There's also some variables that you can customize:
- speedX
- speedY
- maxDistanceX
- maxDistanceY

All other variables are calculated automaticaly, so there's no effect on changing them manually.

If you really must use a radious limiting i can try to do that, but my math skills are not that good so it will require some effort.

That's cool MPnetbox!

I was wondering about how to put trigonometry in,
since you (dsilvers) mentioned arcs before,
but I couldn't figure in my mind the correct behaviour...
because of maximum stretching distance toward a direction it always seemed like a linear vector transformation to me.

I still have hard times figuring this "arc" movement out,
so maybe better if I stop bothering this thread XD

No worries, schrodinger! It was a challenge and I appreciate your help.

MPnetbox, this system works just fine in the game and I've modified my screenshake code to match. Thank you!

While that is a cool example, I think any breakout style game would probably not be relaxing if you are constantly moving the camera around. It is already a challenge for players to set up their reflection angles when the objects are sitting still. If you can, I would recommend trying to get your whole play area into the frame. Or possibly try a zoom in/out (although that might be vomit inducing as well).

It might be better to move the camera only when away from a certain distance. Its kind of the reverse of what it is doing now.
If its X or Y pixels away from the center it should slowly track the ball, otherwise the camera goes back to the center.
But without seeing the actual game running, i'm just guessing that this way is better.

@Mobichan: the gameplay does fit into a single frame, but there have been some major benefits to adding in minor frame scrolling. The screen doesn't scroll much, just enough to look dynamic. You never lose any info, ie your paddle never gets lost. The camera can only pan 25 pixels in any direction (yes, I limited it WAY down from the example), but what it does do is make the game feel a lot more lively. Without it, levels feel like they get stale. Plus, the extra screen space on each side allowed me to implement a little bit of screenshake when you hit a block, and more screenshake when you hit a bomb. I'd also been having trouble with the ball sometimes slipping out of the play area at the corner of a wall before bouncing back in, and while I already coded in a timed failsafe for that, combining the failsafe with camera panning has eliminated the problem entirely. So having it like this has been VERY beneficial to the gameplay.