Trying to copy KiwiStory's camera, can't get it to work.

0 favourites
  • 9 posts
From the Asset Store
Simple and easily editable template for a dynamic camera that zooms in and out based on how far apart the players are.
  • So I tricked myself into thinking that programming in Construct was way easier than it was. I thought after watching a bunch of videos and reading a bunch of tutorials that I'd be pretty set to go, but I'm still feeling pretty overwhelmed. What I'm trying to do right now is make a camera that follows the player so I'm trying to take the one from the KiwiStory sample game. It looks to me like I have all the stuff KiwiStory has, I've made all the variables and checked all the instances and the camera still will not follow the player. I tried to record a quick but comprehensive showing the problem:

    youtu.be/ONZpjCk7X9c

    This is meant to be a four-player game with each player being a different colored knight (red, blue, yellow, green) so I need to find a way to somehow make it so the camera is constantly accommodating all four entities without zooming out while also encouraging moving to the right. I'm guessing this would involve somehow making the camera's position some kind of average of each players' position and/or making the outside of the camera into collisions somehow to prevent players from wandering too far ahead or behind. This is totally an issue for me to solve another day (I don't even have a working camera or multiple players to begin with) but I thought it was something related so if anyone has any ideas or input that would help me future-proof this camera to accommodate four players that'd be great.

    Thanks in advance for the help. If anything is unclear or needs further clarification I'd be more than happy to respond.

  • A camera to follow a player smoothly for a side-scrolling platformer can be done in one event using:

    Set Scroll X - lerp(scrollX,playerobject.X,0.2) This will give you a smooth horizontal scroll using linear interpolation. You can adjust the speed by tweaking the 3rd number to a value between 0 and 1.

    For more than one player I have attached an example that, as you mentioned, finds the midpoint between the first and last player and then applies the same logic as the single player scroll. There are blocking objects placed at the left and right edges of the viewport to prevent a player from disappearing off-screen.

    The method also encourages moving right as the farthest right player will move the camera up until the point that the farthest left player is touching the screen edge. If the farthest left player then moves right, the camera will continue to move forward until it reaches its intended position.

    I have included a method for using families (if you have a license) and for not using families.

    Let me know if you have any questions :)

    1drv.ms/u/s!AkmrWgxeuxlKhIc3pPm0W1AeqXZWZA

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • A camera to follow a player smoothly for a side-scrolling platformer can be done in one event using:

    Set Scroll X - lerp(scrollX,playerobject.X,0.2) This will give you a smooth horizontal scroll using linear interpolation. You can adjust the speed by tweaking the 3rd number to a value between 0 and 1.

    For more than one player I have attached an example that, as you mentioned, finds the midpoint between the first and last player and then applies the same logic as the single player scroll. There are blocking objects placed at the left and right edges of the viewport to prevent a player from disappearing off-screen.

    The method also encourages moving right as the farthest right player will move the camera up until the point that the farthest left player is touching the screen edge. If the farthest left player then moves right, the camera will continue to move forward until it reaches its intended position.

    I have included a method for using families (if you have a license) and for not using families.

    Let me know if you have any questions :)

    https://1drv.ms/u/s!AkmrWgxeuxlKhIc3pPm0W1AeqXZWZA?e=5gMcpt

    Thank you so much. This is exactly what I needed and I learned a lot in implementing it into my own project; I hope you don’t mind that I copied it.

    The only thing is I can’t figure out how to get the screen edge blockers to move with the viewport. I didn’t code anything in that would make them follow, but I also couldn’t locate anything in your project that would cause them to move. What did I miss that causes the blockers to move with the camera?

  • Not at all, it was a demonstration for you to learn from and use however you like. If you look at the layers window in the editor you will notice that there are two layers. Layer 0 is the layer that most of the stuff is on and layer 1 is the layer where the blockers live. With that layer selected, up in the properties section you will see that parallax X&Y are both set to 0. This means that anything on this layer will remain where it is regardless of if scrolling is happening. Parallax at 0 is used a lot for UI elements etc.

    When setting up objects on a 0 parallax layer you have to remember that they are relative to the viewport, not layout. So in the editor make sure you set them to the correct position on the viewport, or position them accordingly using events at runtime.

  • Not at all, it was a demonstration for you to learn from and use however you like. If you look at the layers window in the editor you will notice that there are two layers. Layer 0 is the layer that most of the stuff is on and layer 1 is the layer where the blockers live. With that layer selected, up in the properties section you will see that parallax X&Y are both set to 0. This means that anything on this layer will remain where it is regardless of if scrolling is happening. Parallax at 0 is used a lot for UI elements etc.

    When setting up objects on a 0 parallax layer you have to remember that they are relative to the viewport, not layout. So in the editor make sure you set them to the correct position on the viewport, or position them accordingly using events at runtime.

    Thanks so much! This is super useful information for the future. However, I've got another problem now. When I was only using two player bases I thought it had something to do with their x-positions overlapping, but when I added the remaining two-player bases I realized that the way the camera seems to figure position as it relates to the viewport causes it to wig out when the player closest to the edge is airborne. I really have no clue why having a different y-position would mess with finding the x-position closest to the viewport and since the players in your sample only moved with respect to the x-axis, this problem did not pop up in your project.

    I tried to record a video replicating all of the weird bugs I had encountered: youtu.be/OqVXGO9A7Ks

    It's a few minutes long because I tried to get as many different iterations of the bugs as I could replicate, but to specify here are some of the common bugs related to this y-position viewport problem.

    - With one base positioned at the right end of the screen, another in the mid-right, and two more on the left end, if the base on the right end jumps and holds out into the edge barrier, they'll warp through it, resulting in the camera snapping to its new position and either dragging all of the player bases with it or leaving the two leftmost ones outside of the barriers and out of the viewport entirely.

    - If one base jumps over another so that at around the apex of the jump the two bases x-positions are overlapping the camera won't follow the jumping base. When the jumping base hits the ground, the camera snaps to a new position to accommodate it, as if the camera doesn't detect the jumping base when it's airborne.

    - These problems seem to common less common and less obvious if I shorthop instead of holding jump for maximum jump height, but that may just be because the base is airborne for a shorter amount of time.

    - Being on the top or bottom platform seems to influence whether or not a player base can push the viewport by holding into its respective edge barrier. The details of this bug are tough for me to articulate since it's a bit hard to tell what's going on, but I tried to get a couple of instances of it in the video.

    If you know anything about why changes in y-position would be messing with how the program detects x-position with respect to the edge of the viewport and how I might be able to go about fixing it, please let me know. I'm fresh out of ideas and this is a bug I would like to fix before I try to program something more complicated like health/damage and hitboxes/hurtboxes. If you want to see what kind of code I'm using for jumping or running, give me a shout and I'll put it here. Again, thanks for all the help so far.

  • Hey, the Y issue in the families example is because I was lazy and didn't think about jumping. As the player moves up the screen their distance to the middle of the closest viewport is reduced and the variable will be set to their position. Using the non-families method won't have the issue because it is comparing each players x position to the other and not comparing the distance to the edge of screen or any Y values.

    As for the warping through the blocker, no idea on that one sorry. None of the code for the camera influences the movement behavior in any way. The standard platform behaviour shouldn't be able to move through a solid. Even if the viewport was shifting position when a player was jumping, the jumping player should just be pushed backwards as the solid blocker moved back. It could be some edge of use bug when a platformer and a solid object are moving against each other.

  • Hey, the Y issue in the families example is because I was lazy and didn't think about jumping. As the player moves up the screen their distance to the middle of the closest viewport is reduced and the variable will be set to their position. Using the non-families method won't have the issue because it is comparing each players x position to the other and not comparing the distance to the edge of screen or any Y values.

    As for the warping through the blocker, no idea on that one sorry. None of the code for the camera influences the movement behavior in any way. The standard platform behaviour shouldn't be able to move through a solid. Even if the viewport was shifting position when a player was jumping, the jumping player should just be pushed backwards as the solid blocker moved back. It could be some edge of use bug when a platformer and a solid object are moving against each other.

    Thanks a million! The alternate method works great, no stuttering, warping, or anything funky as far as I could test for. Only thing is, after fiddling with it for a while, if two (or any number of) players are trying to push the camera in opposite directions by running against the barriers, the player(s) running to the left tend to be able to push the whole viewport left. I can change this by adjusting how much the barriers extend into the viewport, but even if they extend into the viewport an equal amount, you can still push the viewport (very slowly) left but not right. Do you know anything about this? I don't think it's much of a problem and I'm definitely ready to move on, but I wanted to see if you had any knowledge/guesses to why this may be the case.

  • I can't replicate that issue, I can see the variable values tweaking slightly as they try to reconcile the movement but it never results in more than a 1 px change from the original position of the viewport to either the right or left. I wouldn't worry about it considering it's unlikely to come up during normal gameplay unless someone was specifically trying to do it.

  • I can't replicate that issue, I can see the variable values tweaking slightly as they try to reconcile the movement but it never results in more than a 1 px change from the original position of the viewport to either the right or left. I wouldn't worry about it considering it's unlikely to come up during normal gameplay unless someone was specifically trying to do it.

    All cool. Again, thank you so much!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)