Should I combine Controller and Animation?

Get help using Construct 2

Post » Wed Jan 14, 2015 9:53 pm

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!
B
31
S
7
G
8
Posts: 232
Reputation: 6,274

Post » Thu Jan 15, 2015 6:59 am

@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.
B
8
S
3
Posts: 197
Reputation: 1,207

Post » Thu Jan 15, 2015 3:17 pm

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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,274

Post » Thu Jan 15, 2015 5:35 pm

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.
B
43
S
12
G
14
Posts: 488
Reputation: 10,570

Post » Thu Jan 15, 2015 6:05 pm

Yeah all errors despite using the same sprite and collision-box size.
B
8
S
3
Posts: 197
Reputation: 1,207

Post » Thu Jan 15, 2015 7:10 pm

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:
Image

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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,274

Post » Fri Jan 16, 2015 3:04 pm

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

viewtopic.php?f=180&t=122597

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?
B
8
S
3
Posts: 197
Reputation: 1,207

Post » Sat Jan 17, 2015 2:19 am

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

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?
You do not have the required permissions to view the files attached to this post.
B
8
S
3
Posts: 197
Reputation: 1,207

Post » Sat Jan 17, 2015 2:51 am

@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.
B
31
S
7
G
8
Posts: 232
Reputation: 6,274

Post » Sat Jan 17, 2015 12:57 pm

@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
B
43
S
12
G
14
Posts: 488
Reputation: 10,570

Next

Return to How do I....?

Who is online

Users browsing this forum: brunopalermo and 27 guests