"Following camera" and physics

Games
#1

Im making a basic platformer game and have run into a problem that Im having a hard time figuring out how to work out.

Im trying to have a scrolling game where there are various obstacles, such as boxes on the ground, and platforms in the air. The problem Im encountering is that I dont know how to properly use the physics engine to accomodate all of this with the camera following. The simplest approach Ive taken for the camera is to just have the world move behind the character, either having the ground act as a physics object which moves smoothly or as having something simple like world.x=world.x-5.

Using the second method(world.x-5) causes the physics to get all wonky and things arent where they’re supposed to be, obviously because that doesnt actually have any bearing on the physics itself but only the object. Using the first method, I dont know how I can have floating platforms because static objects dont seem to respond to movement, and given my current situation, I dont know how to bring them onto the screen. Kinematic objects react weirdly to a change in velocity and they dont seem to ever stop moving no matter what I try.

Any suggestions? Im totally baffled here. [import]uid: 67886 topic_id: 13045 reply_id: 313045[/import]

#2

Don’t move the world, move the camera. Think of the physics world like a giant fish tank. Very difficult to move without disrupting everything inside it, or the whole thing crashing to the floor. Instead move your head (the camera) around and the world will appear to scroll by, though it’s your head that’s really doing the scrolling.
[import]uid: 9422 topic_id: 13045 reply_id: 47910[/import]

#3

That would make sense, but how do I move “my head”? I just threw the word camera out there instead of viewport, but if theres an actual way to have a better “camera” view that doesn’t mess up the physics, Im very interested to know how as that would help tremedously. [import]uid: 67886 topic_id: 13045 reply_id: 47911[/import]

#4

Sure, just insert everything in the physics world into a new display group called, say, cameraGroup. Then you can move the group around with simple commands like cameraGroup.x = cameraGroup.x-5, etc, and the world will scroll around your viewport.

You could insert that group into another parent group called, say, zoomGroup and perform “zooms” on it by simply scaling zoomGroup (I prefer to separate my scrolling and zoom into separate camera groups for easier control).

Put your UI objects in another group (but don’t insert it into the other groups) and they won’t be affected by any “camera” movement.

Just remember to keep all of your physical objects together in one group. The physics engine can barf trying to intermingle obects in separate groups. [import]uid: 9422 topic_id: 13045 reply_id: 47922[/import]

#5

Oh I think thats kind of what I was doing. Similar to the egg breaker one right? I just called all of it world instead of cameragroup. Hmm, but how would you be able to move the physics objects properly? Whenever I try to do any object.x=object.x-5, it moves the image of the object but the physics box stays invisible where it was previously. Or maybe its cause I have things in too many intermingling groups… Ill take a look into this and see how it all works out. [import]uid: 67886 topic_id: 13045 reply_id: 47983[/import]

#6

Hard to say where the problem might be without seeing your code, but the physics engine is a finicky beast. A few things to keep i mind:

  1. While the debug and hybrid draw modes are great for diagnosing problems, they can also be misleading. For example, if you “zoom”(scale) a group with physics objects, they’ll still look and act correctly, but the debug physics bounding boxes won’t scale correctly. Hopefully Ansca will squash that bug soon.

  2. Physics objects in different display groups may not interact correctly with each other, especially if you move or scale one group relative to the other. To avoid problems all objects in the simulation need to share the same coordinate space. The easiest way to ensure that is to insert them ALL into the same group.

  3. trying to move an object under physical simulation directly with object.x = object.x-5 could potentially cause all kinds of problems. I think static objects should be ok to move that way, but dynamic and kinematic objects could behave unpredictably. There are physical ways to move physical objects using physical forces, and special joints used for dragging physical objects around with the pointer. This might be the root of your particular problem.

I’ve found it’s best to treat any physically simulated objects like a delicate flower; Push or pull them too hard and they will break in all kinds of irreparable ways. [import]uid: 9422 topic_id: 13045 reply_id: 47987[/import]

#7

camera viewport should be very easy to implement, it is just a basic function of openGL… [import]uid: 12088 topic_id: 13045 reply_id: 47988[/import]

#8

So after a week or so break, Im still trying to figure part of this out. As you said, grouping certain physics objects together made everything spaz out. It still needs a bit of tweaking to look normal but I have everything move in relation to the character. I’ve managed to move the world smoothly using physics rather than the rigid looking object.x-5. As it is, I have the player as an object in the middle, but as the world moves it tends to push him out of normal orientation, is there a simple way to have him stay centered by limiting the X?

I was looking at the egg breaker example again at the camera function, and Im having a difficult time figuring out why it does what it does, or rather why I cant have it do the same on my game.
The game.x decreases as the boulder.x increases with 80 inbetween(the gap to the left of the boulder), yet the boulder stays in a constant rigid position in the viewport.
In my game, I cant figure out how to implement a similar system, because I use left/right/up/down controls, and the player.x is always within 1 and 800(the width), so the world would move WITH the player.

P.S. I have no idea how to use openGL [import]uid: 67886 topic_id: 13045 reply_id: 49253[/import]

#9

I’ll see if I can break down the egg breaker “camera” simply:

  1. All the game objects are inserted into a new group called game. by default game.x is 0.

  2. A new boulder is spawned and also inserted into the game group. It is a dynamic physical object so it reacts to gravity, bounces off the spring board, flies through the air, etc. As it moves its x position property changes. If you don’t make the camera follow the boulder then game.x would remain 0 while boulder.x would increase every frame as it moves left to right through the coordinate space of the game group.

  3. To make the “camera” follow the boulder perfectly, on every frame make game.x the negative value of boulder.x. (-boulder.x) That would keep the boulder centered on the left edge of the screen. To move it away from the edge the example adds 80 pixels to that value. There are a couple other logical rules to the camera, but this is how the camera follows the boulder.

Why use the NEGATIVE value of boulder? To keep the boulder on screen you want to move the entire game group, filled with all the game objects, in the opposite direction at exactly the same rate the boulder moves since the “camera” (Corona’s display, which can be thought of as another display group on top of all the other groups) isn’t moved.

It IS like moving the entire fish tank of objects past a stationary viewer, which I realize contradicts what I said in a post above. Sorry for the confusing analogy earlier. Maybe a better analogy would be; imagine you are standing on a train platform. A train speeds by you, not stopping. Someone in the train throws a ball down the isle at exactly the speed the train is moving, but in the opposite direction. From the platform it looks to you like the ball is frozen in front of you even though from inside the train the ball is moving down the isle realistically. In that analogy you are the camera and the train car is the game group and the ball is a physical object inside the game group.

The upshot is, putting all your game’s display objects inside a group allows you to move the group without upsetting the objects, and moving the group in the opposite direction to an object inside the group will make the “camera” follow that object. [import]uid: 9422 topic_id: 13045 reply_id: 49281[/import]

#10

Oh no I somewhat understand why it does what it does, but I cant figure out how I can effectively use that in my game. I appreciate the time and effort you’ve put into this thread though, its helping me a lot so far with what I originally assumed would be a simple task.

Ahh I keep going back and forth, switching code around to figure out what works one way and what works another way and what doesn’t work and I think Ive found various solutions that help me move the world around, none of them are perfect yet, but that will come with some tweaking.

The problem with the egg breaker was that I was trying too much to strictly orient it around the player, given that in my game if he touches something, it moves him out of center. This was by giving the left and right controls a function like world.x=world.x-5, since having it like world.x=-player.x would cause the player to be affixed to the background(There are no forces that would push him to change his x value). If I keep running into a box or something, the world could continue to move at the same pace but the character would probably fall off the side. The egg breaker camera seems to be practically welded onto the boulder in such a way that if the boulder moves, so does the camera. But now I have other plans on how to fix him to the center.

Again, thanks for the help.

[import]uid: 67886 topic_id: 13045 reply_id: 49286[/import]