Should I combine Controller and Animation?

I have a "design-related" problem in Construct.

For the longest time, I've always used a hidden controller which spawns the connected AnimatedSprite for all entities in the game, players, npcs, enemies, etc. Both the controller and animated sprite would have origins set to the "Center Bottom" of the images to keep things consistent.

I'm going to define a few terms so that my question is relatively clear:

Controller - An invisible sprite with logic, and behaviors of the actual entity itself.

AnimatedSprite - The sprite containing all animations for the entity which is pinned to the controller.

Animation - A single animation within the AnimatedSprite, such as "Walking", "Running", "Jumping", etc.

However, I've done three things recently that have made me inclined to change my mind, aka, to want to merge the Controller and AnimatedSprite together as a single Sprite. I will refer to this concept as a "SingularEntity".

• Fixed Dimensions - All dimensions within a single animation are identical, so all jump frames might be 32x52, all walk frames might be 32x50, etc. Everything is consistent for purposes of bounding boxes, and origins. I'm very careful about this.
• Origin Point Consistency - For an entire Animated Sprite, all animations have the same origin point, for example, a platforming character's origin point would be center bottom.
• Construct Family support - With family support, the first time I create a SingularEntity, I put it in a new family. The SingularEntity does not have any member variables, all properties/behaviors *ALWAYS* exist on the Family itself. This means that it is easy to create new Entities with the same behavior as the original.

What are the advantages of using a SingularEntity?

I don't have to worry about setting up any pinning behaviors. Easy to draw and change my bounding boxes, since the bounding boxes exist on each respective Animation within the SingularEntity. It is easy to check that my bounding boxes are drawn in the appropriate places since they exist on the actual animations themselves.

What are the disadvantages of using a SingularEntity?

The only disadvantage I can think of, is that if you wanted to swap out an entire AnimatedSprite for another AnimatedSprite. For example, let's say the player's character morphed into a completely different character. Having a distinct controller would mean you could replace the old AnimatedSprite with a new AnimatedSprite while preserving all player's stats which live on the invisible Controller itself.

It seems like the simplification afforded by using a SingularEntity make it worth using over keeping lots and lots of 1:1 controller sprite / animated sprite mappings. Although I'm fairly sure that either solution is viable, I'm hoping to gain some insight on the potential implications of using one over the other.

Thanks!

cacotigon I switched to a controlling object and separated animations because of some collision/getting stuck problems. It is an advice in some tutorial or manual entry, and it does indeed work smoother this way.

Yeah, I've always done it that way in the past. The problem is if you have a complex set of animations, you have to be careful with lining up collision boxes in your controller to match the animated sprite, since you'll have to change frames/animations in the controller itself to change the collision box which happens a lot in a character with lots of different styles of movement (example: ducking).

Finally you get all the collision boxes relatively the same and then later down the line you realize you have to alter some of the frames of the animated sprite.... So you have to go back in and change all the collision boxes in the controller again.

MultipleChoice - Regarding your animations getting stuck, hmmm, were you using fixed dimensions on each frame or did it change? You'll definitely run into problems on a platformer behavior character if origins/bounding boxes vary from frame to frame in a single animation. I actually noticed that if you have two frames of walking animation, Say F1 and F2, but each frame has a different dimension and you attempt to apply bounding box to whole animation, the bounding box vertices end up as slightly different floating point values - maybe this has to do with the fact that the underlying project XML stores these type of coordinate values as fractional ratios from 0-1 against the whole image.

I'm using a separate Sprite (PlayerDetect) for my prototype as well. I think its smoother this way. Although I ran across several problems related to this.

But its often a matter of small adjustments.

I agree, animations should have same frame size. I had exactly the same problem when using different animation sets which had different sizes.

Yeah all errors despite using the same sprite and collision-box size.

Hmmm, I just did some testing.

As I mentioned earlier, bounding box coordinates are stored as ratios in the XML. So for example, if you have an animation with two frames, frame1 is a 32x64 image, and your bounding box coordinates are (0, 32), (0, 64), (32, 64), and (32, 32) -- eg, the lower half of your sprite, then the XML will store these values as (0, 0.5), (0, 1), (1, 1), (1, 0.5). Frame 2 however is 32x128, twice as tall. If you right-click and apply the original bounding box to the entire animation, frame2's bounding box will be *twice* as high as frame1's bounding box.

Here's a picture to clarify:

It should be noted that image points are stored internally the same way.

Obviously this is exaggerated for purposes of explanation, but I'd wager it can lead to potentially subtle bounding issues when you factor in things like toggling pixel rounding, and if a frame's height changed from an even value to an odd value.

I think people get burned when they don't use fixed dimensions (or they do on import, but then let Construct crop transparent edges). Then they setup a single bounding box on the first frame of some given animation in a sprite and apply that bounding box to an entire set of animation's frames.

I just did a quick prototype using the SingularEntity (aka Controller also has animations) of Mario. I can walk, run and jump on flat and sloped surfaces without any problems at all. However, I was very careful to import all my animations as a fixed dimension sprite sheet. Seems to work perfectly. I'll post it up later if anyone's interested.

MultipleChoice, If you still happen to have the old original project with the jittery animation, I'd be willing to take a look at it and see what's going on with it.

cacotigon thanks, my project can be tested here - separated contol object though... I`m a bit surprised, nobody likes my favorite flawless animation style

Still I have a major problem: when you move, sometimes the control object (an all attached) are rather one pixel above the "ground", then, sometimes just by pressing down, which should not do anything, it does touch down correctly. The biggest problem is, sometimes it does not detect landing it seems. There used to be a landing detection bug in earler versions of construct2 , which should be solved. still, the movement is never really smooth. Any idea, why that happens?

Here is an example-file to my problem. cacotigon , —

The platform is shaking when moved. (Not moving constantly, but moving a bit back and forth one pixel while moved.)

I'm quite sure it is due to pixel rounding. Switching it of at least solves the problem. But I need to turn it on, for seamless textures and so on.

Do you guys have an idea how to solve this?

MultipleChoice

Hmmm, I didn't notice any shaking happening testing on Firefox/Chrome. I couldn't fit into the any of the corridors, so I adjusted the bounding box for the player by x +/- 0.5 and the top by -0.5 with pixel rounding ON or OFF this solves the problem and it seems to work okay. Here's the updated capx.

https://dl.dropboxusercontent.com/u/12667027/Construct%202/updatedtest.capx

If you want, PM me and we can discuss it further.

cacotigon

I also did like cacotigon. Also, I added lerp scroll to the movement. The movement should be smoother.

https://www.dropbox.com/s/zzhuwa7pzjv3jln/test_revision.capx?dl=0

Thanks guys!

cacotigon

Unfortunatly it does not solve the problem. It is rather based on the pixel-rounding adjustment, which does not seem to work properly. It looks, like the moved sprite is not rounding first down, then up, between two whole number as it is expected, thus causing the platform sprite and the camera shake back and forth 1 px on both, X and Y axis.

—

Good approach. The lerp movement causes combined with pixel rounding a better, but still uncool effect though. At the end of the movement when the values are less than a pixel. It looks also a bit odd, like jumping, since 1 px is too big for the last steps of the ease, and it takes ages before the last pixels snap to the final value.

In my experience it is better to use the sine-behavior, if possible of course, since it is behaving with pixel rounding a bit smoother, the movement being less eased, I guess. But this is obvious, and not the problem at all.

I already tried Scroll to ROUND(Sprite.X, Sprite.Y), which works for the cam itself. But the "Sprite"-platform itself is still not rounded properly and shaking

It seems, like a pixel rounding-bug in the platform behavior.

I also did another test with rounding the sprite position, but that has a strange effect. The platform now is 1 px above the ground, if you don't touch the arrow buttons. As soon, as you move HORIZONTALLY, the platform object snaps 1 px down on X, touching the ground.

Is this maybe a rounding bug altogether? (Also when I'm not rounding, a similar effect happens to my platform, which should be drawn at a rounded X/Y position.)

See here:

Why not just set it to Self.X instead of round(Self.X) ?

Also, what would you like to accomplish actually?

I was doing something similar on a cinematic platformer prototype. Except I was using a PlayerDetect Sprite.

Difference is I wasn't using behaviours at all, so it was mostly animation driven. I modified the right/left movement slightly to work with your system.

https://www.dropbox.com/s/052x0j4kv9rg5oj/movementTest.capx?dl=0

— First, I am looking for an explanation, why the standard platform behavior causes the 1 px shaking, as described.

Second, I would like to get rid of it I wish it would just work as expected, moving steady and smooth to different direction.

So mostly, since every time I start a platform I face this problem, I would like to have an explanation, to know if and how I can avoid this problem in the future.

I tried the "round" function, because since "pixel rounding" is on, its obvious, that the platform's sprite has to be displayed at a certain rounded position, which might not work perfect. But It seems to make it worse, so my suspicion is a rounding issue in Construct 2. This maybe a bug, but maybe due to a mathematical problem.

Do you experience these problems at all? In your own experience? With my example files, any of those?