As some of you know I have been doing a course from Udemy on creating a 2D platformer and have been learning a lot.
Now in this course the instructor has set some assignments to do at the end of the each chapter and in one of the assignments he said basically, for advanced students (I don’t consider myself advanced) to try writing a script which forces one of the camera boundaries to gradually move towards the end of the level forcing the player to keep up with it. I have done the main components of the assignment and I have been trying to think how I might go about this.
So, I have a camera that has set min and max boundaries set - doesn’t really help that this was never really really explained how we did this, I just followed the code given, but, ok. I am assuming that the:
min boundaries is the vector to the upper left co-ord of the camera
max is the vector to the lower right co-ord, again we are not really told how the camera operates just that it has a shape.
So, I was thinking this, set a speed for the camera to move to the right * delta to keep it smooth and then subtract this value from the min co-ord (left co-ords) until it reaches an arbitrary value so the camera doesn’t shrink to nothing. And then subtract this value also from the hero character as well, so, it doesn’t end up off screen as well.
Now is this a good way to go about it? Would it work? Is there a better way? I know the character could get caught in a situation that it can’t move out off and should be “crushed” and “die” but I haven’t gotten around to killing the character off yet, or how to go about that when stuck behind a tile and the camera is coming. Just trying to get one thing done at a time and the moving camera is it.
If you can help here is a big thankyou in advance.
One thing I totally forgot is changing the location of the hero character programmatically, sure I could’ve done that manually but I think it is better to do that based on the level and it’s function. And it not very hard to do.
Ok, I implemented a scrolling like effect with the camera moving through the level. But I am having a behaviour that I wasn’t expecting at all. When the player character is moving with the level (camera) everything is fine … until … the character charges through the stage moving ahead of the scroll and scrolling the stage itself, until the camera scroll catches up and then continues moving.
I am not sure I want this to happen, because it’s quite jarring when the camera stops scrolling completely or it was to me when it first occurred.
Using pseudocode what would be the way to resolve this problem so the background is continually scrolling or is this just the way it has to be. I have never done anything like this before and can’t really remember any games I have played with this behaviour.
NB: I haven’t set up any code to force the player along with the camera movement.
The camera movement script is completely separate to the player. In this course the camera is using tweening as an effect because it alleviates motion sickness or something like that , just don’t think about it - anyway it looks cool. And in that we have min and max vectors, so, it was relatively easy to set up camera movement. It still follows the player but with scrolling.
basically this without going into too much specifics:
min-bounds.x += speed * delta
then:
set the position values of the camera based on that using a clamp value:
position.x = character.x
position.y = character.y
position.x=clamp(position.x, min_bounds.x (which moves), max bounds.x)
position.y=clamp(position.y, min_bounds.y, max_bounds.y)
Maybe I should leave it as it is - and just speed up the camera movement, so, there is less of a gap between stopping and moving and put a goal of something you have to get during the level before you can finish it so you can’t just charge to the end.
In this project those camera properties are never touched. Well as far as I know
But I did have an idea, I have clamped the values of the camera, so, it is always moving (scrolling on x), and I was wondering if it would be possible on stages where there is camera scrolling to clamp movement of the player in the x direction based on the camera position? In that way it cannot get too far ahead of the camera?!? I am not very used to the idea of clamping in every programming class I have ever done the idea of clamping was never used and if it was it could be handled another way. The first time clamping came up was with the character falling too fast off a ledge that it fell off the bottom of the camera - because of the camera is not being attached to the player in which case it would never be a problem, but, here it can be.
Everything I learnt in the Brackey’s tutorial is being turned on it’s head, and my grey matter is feeling it . Even the idea of trying the clamp the player to the camera makes makes my head spin!
I think you need to use clamp and camera limit together like if you are clamping the position of player then you have a min_position_limit and max, so set the camera limit left to this min and right to max for making smooth, also use position smoothing
If I was doing my for myself I would look into everything you have said, but I am worried that I will break the tutorial if I start playing around with other tools. Also this has a whole other set of variables making it harder for instance the player isn’t dead center in the screen, there are offset variables in the camera in both the X and Y direction and the tweening used and the clamping in the Y position if it falls to fast which pretty much destroy the tweening in the Y direction anyway.
Oh dear, I need a break from this course. I did get it working the way I supposed, but, I had to hard code variables because I don’t really know how the camera works. Goodness know what would happen if it were run at a different resolution. And while it is slightly better than the no scrolling version it’s not how I would like it. But I can’t describe how I would like it. At the moment it’s like the old Scramble arcade - oh well.
Thanks again for giving me things to look at when I finish this course.