The Daily Click ::. Forums ::. Klik Coding Help ::. Custom Camera System
 
Post Reply  Post Oekaki 
 

Posted By Message

Logiq


Registered
  09/04/2007
Points
  120
11th September, 2008 at 17:10:02 -

In my platform game I want to have a camera sort of like the sonic games where the camera follows the player. I saw a article the replicated this effect but only if my player is moving at a uber speed.

What I want is quite the opposite. When the character start to go fast(but not nearly as fast 'Sonic') I want the camera to move forward so the player can see what's ahead of him. I was able to achieve the effect.

I want but when the player stops I want the camera to come back to him. I achieved this effect. However, when I start running again the camera skips back to the last position is was going fast at. How can I get the camera to speed up relative to my players position?

 
Hello guys! I'm New! -- I've been new for a year now...haha

traugott.simon


Registered
  23/08/2008
Points
  91
11th September, 2008 at 17:58:49 -

Well, you could just say, that the camera has to be at 0 speed at 0,0 position of the player, at 0 - 20 speed at 40,0 at 20 - 40 speed at 60,0 .........

if you want to make it look smooth, just add 1 oder 2 pixels until the camera reaches the position you want. You can do this with a fastloop.

 
n/a

-Finn-


Registered
  28/08/2008
Points
  445
12th September, 2008 at 08:55:10 -

logiq, is nice that you want to do a nice game, but what you doing is like putting others to code your game. There are a lot of articles outta there...i viewed all in 9 days and there are 24 pages. And trust me, i found a lot of things that could help me in the future.

if you do not have spend time, read 3 or 4 pages per day...its hard but helps u much.

have a nice day!

 
Image

aphant


Registered
  18/05/2008
Points
  1242
12th September, 2008 at 11:51:05 -

Here's what I would do.

First, I would determine how much extra screen space I'll give the player.
Second, I would take the player's movement speed as a pixel unit.
Third, I would set the camera's horizontal position to be at the player's horizontal position.
Fourth, I would modify the camera's horizontal position relative to the player's movement speed (in pixels).

Now I'll define some variables for the coming examples:
w, window width (Pixel value)
z, player's stopped (0%) movement speed (Pixel value)
s, player's fastest (100%) movement speed (Pixel value)
x, player's current speed (Pixel value)
f, camera's offset from player (Pixel value)
c, camera offset at 100% speed (Percentage, use values from 0 to 100.)

Example Scenarios:
When the player isn't moving, the camera will be 0 pixels away from them.
When the player is at 25% speed, the camera will be 40 pixels away from them.
When the player is at 100% speed, the camera will be 160 pixels away from them.

In the example scenarios, we have the player in three different locations in the window. In the first scenario, the player is in the center of the window, at 320. In the second scenario, the player is slightly off center in the window, at 280 (we're assuming he's moving to the right). In the third scenario, the player is a quarter of the way to the center, halfway between center and the left edge, at 160.

The relationship (as an equation) between camera offset and player speed is, using the variables defined above:
x*(w/(s*(100/c)))=f

Here are some practical examples. They all assume the width of the screen, w, is 640px and that the player is running to the right (so all values will be positive):
s=8, x=s, c=25
2*(640/(8*(100/25)))=40

s=8, x=4, c=35
4*(640/(8*(100/35)))=112

s=12, x=12, c=40
12*(640/(12*(100/40)))=256


Applying (some of) the Concepts
To get w, we're going to need a way of getting the window's width. You could use a hard-coded value, but what if you decide to change resolutions later? The storyboard object doesn't return the actual screen resolution.
To decide c, you'll have to take into consideration the movement speed of the player relative to the human reflex.
You're also have to think about the size of hazards in relation to the screen size. For c, You shouldn't go over 40%, though, because then the player's character might get cut off by the edges of the screen; You also shouldn't go under 10%, because then the extra screen space will likely be negligble. To make a good s, you shouldn't have it be more than 2% of w, though you might be able to go up to 5%.

I'm going to leave it up to you to apply the methods practically and to actually code it.

Editted the language to be more clear. Several times.
Then, I decided to tell how I would do apply the above

Image Edited by the Author.

 

Eternal Man [EE]
Pitied the FOO

Registered
  18/01/2007
Points
  2955

Game of the Week WinnerHero of TimeLOL SignI am an April Fool
12th September, 2008 at 15:52:18 -

Originally Posted by -Finn-
logiq, is nice that you want to do a nice game, but what you doing is like putting others to code your game. There are a lot of articles outta there...i viewed all in 9 days and there are 24 pages. And trust me, i found a lot of things that could help me in the future.

if you do not have spend time, read 3 or 4 pages per day...its hard but helps u much.

have a nice day!


I understand your intention for writing that, but you see, Logiq did do the correct thing. Doing that kind of camera movement correctly isn't an easy task if you've never done it before, he's not asking people to make his game for him. In this forum you are supposed to ask for help with things you can't do by yourself and those replying are supposed to give their input/help or direct the asker toward a appropriate source to solve his/her problem, otherwise, don't bother replying.


Logiq: This method should solve your problem and supersmooth too. I didn't come up with this, all credits go to Dead Man Dines and Phizzy (if DMD remembered correctly).
It is the absolutely best way for all kind of scrolling in my opinion.

DMD quote:

The method I use is as follows:

Create a new active object, which we'll program to function as a camera.
The screen will follow this object, which softly follows the player.
In properties, give it these alterable values:
--- XPOS
--- YPOS
--- RATIO (set its default value to something like 300)

We're gonna do with this what we do with float-point custom movements. We'll store the camera's X and Y position in alterable values, so they can have decimal points. It makes movement smoother and more precise.

The 'Ratio' value will be the rate of delay. 1000 will follow the player exactly, the same as 'Scroll to Player' would do. I find 300 is a good value, you'll have to experiment.

So the events are:

//Set the XPOS and YPOS values at the start, to match where we put the camera.
//This enables us to place the camera object anywhere in the level,
// and at the start of the frame, the camera will migrate from that location to the
// player. So you could place the camera at the end of the level, and the player
// at the start, and the camera will swoosh back to the player, giving a brief
// preview of the whole level.

on START OF FRAME
--- Camera: Set XPOS to 'X("CAMERA")'
--- Camera: Set YPOS to 'Y("CAMERA")'

//Now, AFTER any custom movement events, we will use a simple formula to softly follow the player:

ALWAYS
--- Camera: Set XPOS to
Xpos("CAMERA") + (X("PLAYER") - Xpos("CAMERA")) * Ratio("CAMERA")/1000.0
--- Camera: Set YPOS to
Ypos("CAMERA") + (Y("PLAYER") - Ypos("CAMERA")) * Ratio("CAMERA")/1000.0

--- Camera: Set X position to 'Xpos("CAMERA")'
--- Camera: Set Y position to 'Ypos("CAMERA")'

And that's it. All the variables, like how much the camera must move per frame, are all calculated using alterable variables, so we can keep them precise to several thousandths of a pixel. And at the end of it, we position the camera to follow those variables. This way, the movement is smooth.


The actual formula we're using is this:

cpos = cpos + (target - cpos) * r

where:
cpos = the position of the camera
target = the target position (in this case, of the player)
r = the rate of movement (a decimal value between 1 and 0, like 0.3).

How this works:

(target - cpos) finds the distance between the target (the player) and the camera's current position.
Multiplying it by the rate value gives us a percentage of the distance. This is what gives the formula its smoothness.

Finally, we add this to the camera's current position, which has the effect of moving the camera.

It works wonderfully! I love it! Better yet, you can add ANOTHER object to function as the target, instead of the player. Then, during conversations, you can reposition this target object to whoever's speaking at the time, or to important objects or cutscenes.

This way, during conversations the camera will softly swing between the two speakers.

End Quote.

Hope you people can be bothered to read all this!

//EE


 
Eternal Entertainment's Code'n'Art Man

E_E = All Indie


...actually Ell Endie, but whatever.
Image
Image

Logiq


Registered
  09/04/2007
Points
  120
12th September, 2008 at 18:59:52 -

Originally Posted by Eternal Entertainment
Originally Posted by -Finn-
logiq, is nice that you want to do a nice game, but what you doing is like putting others to code your game. There are a lot of articles outta there...i viewed all in 9 days and there are 24 pages. And trust me, i found a lot of things that could help me in the future.

if you do not have spend time, read 3 or 4 pages per day...its hard but helps u much.

have a nice day!


I understand your intention for writing that, but you see, Logiq did do the correct thing. Doing that kind of camera movement correctly isn't an easy task if you've never done it before, he's not asking people to make his game for him. In this forum you are supposed to ask for help with things you can't do by yourself and those replying are supposed to give their input/help or direct the asker toward a appropriate source to solve his/her problem, otherwise, don't bother replying.


Logiq: This method should solve your problem and supersmooth too. I didn't come up with this, all credits go to Dead Man Dines and Phizzy (if DMD remembered correctly).
It is the absolutely best way for all kind of scrolling in my opinion.

DMD quote:

The method I use is as follows:

Create a new active object, which we'll program to function as a camera.
The screen will follow this object, which softly follows the player.
In properties, give it these alterable values:
--- XPOS
--- YPOS
--- RATIO (set its default value to something like 300)

We're gonna do with this what we do with float-point custom movements. We'll store the camera's X and Y position in alterable values, so they can have decimal points. It makes movement smoother and more precise.

The 'Ratio' value will be the rate of delay. 1000 will follow the player exactly, the same as 'Scroll to Player' would do. I find 300 is a good value, you'll have to experiment.

So the events are:

//Set the XPOS and YPOS values at the start, to match where we put the camera.
//This enables us to place the camera object anywhere in the level,
// and at the start of the frame, the camera will migrate from that location to the
// player. So you could place the camera at the end of the level, and the player
// at the start, and the camera will swoosh back to the player, giving a brief
// preview of the whole level.

on START OF FRAME
--- Camera: Set XPOS to 'X("CAMERA")'
--- Camera: Set YPOS to 'Y("CAMERA")'

//Now, AFTER any custom movement events, we will use a simple formula to softly follow the player:

ALWAYS
--- Camera: Set XPOS to
Xpos("CAMERA") + (X("PLAYER") - Xpos("CAMERA")) * Ratio("CAMERA")/1000.0
--- Camera: Set YPOS to
Ypos("CAMERA") + (Y("PLAYER") - Ypos("CAMERA")) * Ratio("CAMERA")/1000.0

--- Camera: Set X position to 'Xpos("CAMERA")'
--- Camera: Set Y position to 'Ypos("CAMERA")'

And that's it. All the variables, like how much the camera must move per frame, are all calculated using alterable variables, so we can keep them precise to several thousandths of a pixel. And at the end of it, we position the camera to follow those variables. This way, the movement is smooth.


The actual formula we're using is this:

cpos = cpos + (target - cpos) * r

where:
cpos = the position of the camera
target = the target position (in this case, of the player)
r = the rate of movement (a decimal value between 1 and 0, like 0.3).

How this works:

(target - cpos) finds the distance between the target (the player) and the camera's current position.
Multiplying it by the rate value gives us a percentage of the distance. This is what gives the formula its smoothness.

Finally, we add this to the camera's current position, which has the effect of moving the camera.

It works wonderfully! I love it! Better yet, you can add ANOTHER object to function as the target, instead of the player. Then, during conversations, you can reposition this target object to whoever's speaking at the time, or to important objects or cutscenes.

This way, during conversations the camera will softly swing between the two speakers.

End Quote.

Hope you people can be bothered to read all this!

//EE


Thanks for all the help everyone. I am making a platform game that exploration is the main gameplay point and I know that a good camera system is a key to that. I never want anyone to code my game for me. But when there is something that I can't do initially I look it up. If I can't find it, then I ask for help.

But to Eternal, The method that you gave me is the method I ended up coming up with myself last night. My is definitely more sloppy but it works. Now that I know that I am on the right track I can clean things up to be a lot more useful.

 
Hello guys! I'm New! -- I've been new for a year now...haha

Eternal Man [EE]
Pitied the FOO

Registered
  18/01/2007
Points
  2955

Game of the Week WinnerHero of TimeLOL SignI am an April Fool
13th September, 2008 at 00:56:08 -

Great!
The one I use only need 2 events! And it really is the smoothest possible scrolling I have ever seen. First time I had some problems separating all the variables, but it really is simple! Hope it makes any sense!
Good luck with your game!
//EE

 
Eternal Entertainment's Code'n'Art Man

E_E = All Indie


...actually Ell Endie, but whatever.
Image
Image
   

Post Reply



 
Advertisement

Worth A Click