Am I completely mistaken, or is it supposed to do something like this?
ball_1.mfa
Am I completely mistaken, or is it supposed to do something like this?
ball_1.mfa
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:
smoothTracking.mfa
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
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.
Posting Permissions
Reply With Quote