youtu.be/GDSQtva6U0Y

I came across this problem yesterday and tried some more fixes today, but I’m really stumped on this one. I’ve got a little bug enemy that walks around and his walking animation has his head bobbing up and down. However, since I use the same canvas size for all my character sprites, the little bug was on a large canvas so I used Construct 3’s cropping tool. Upon doing this, it cropped the sprite so that the frames with the bug’s head down closer to the ground (the vertically shorter animation) was centered inside the same box the taller animations were. When I changed the collision box to line up with the bug’s feet, this caused him to jitter into the air every frame he put his head down.

I’ve tried using the resize and crop tools, but I can’t get that thin black rectangle that contains the sprite to go flush to the bug’s bottom on all frames. The best solution I can think of is go back to where I made the sprite and fiddle with the canvas size and the position of the bug, but I’d prefer not to do that because I have some more dynamic animations lined up and I think it would be a lot more efficient to figure out how to position each frame so a character’s body doesn’t jitter when it changes height.

The most puzzling thing about this is the red knight (also shown in video) gets some significant air in his walking animation, but I never had a problem with his sprite being where it’s not supposed to be on a given frame.

Does anyone have any insight on how I can fully control the alignment of my sprites or manually edit the black rectangle that contains them, or if I should just reduce my canvas size? If anyone needs some clarification, I’d be happy to show my more of the Construct project and/or sprite animations. Thank you in advance for the help!

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!

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.

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.

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?

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.

I tried to hold off on changing the knight's image point because he moves around so much, so I just messed with the center of the base and now it looks like the knight is standing, running, jumping, and falling normally on solid ground. Thanks a million!

Turns out that was the problem. Thank you! My logic for pinning the two together is just "System -> Every Tick -> Player (the collision-less animations) -> Set Position to Base.X, Base.Y"

So I guess off the top of my head there are two ways to fix it. I'm assuming one is changing the last step to "Base.X-??, Base.Y-??" and just jimmy it until it looks right. The second would be to ditch the mask-base separation and give the player sprite all the collisions. However, something I plan to attempt to implement pretty soon is combat and the player's disjointed hitboxes. Since he's got a flag to attack, his flag swing should not occupy the same area as his body, so I was told I would need the mask-base separation to make two separate collision polygons, one for terrain collision/hurtboxes and the other for hitboxes. Is this true or do you know if there is an easier way to create a hitboxes-hurtboxes separation that would allow me to ditch the mask-base separation, provided ditching the mask-base is the best option?

My "Base" for the player's collision and the pink collisions both have collision polygons that occupy the entirety of the sprite. I thought the collision of the "Mask" (the red knight) might be the issue but he has no collisions and exists purely to represent the position and motion of the player, as of now. Maybe it's something to do with how I stretched one of the collisions, but I've tried messing with it and the results seem to be the same. I'm thinking it's got to be something to do with the collision polygons that I don't know about.

I believe he meant create multiple sprites (boxes) with their own collisions pinned to the character. Enabling/disabling when needed.

Ohhh I see. Thank you!

The most straight forward approach to this is to create multiple collision boxes for the same character and pin them to his fists and legs, disable their collision check and only reactivate on specific a frames when the animation indicates that the character should inflict damage to the enemy. You don't need to eliminate them everytime you need to do damage check, just disable the collision of these boxes.

So I guess there is a way to create more than one collision polygon. I will have to look at this. Thank you!