移动棒图，锚点，动画或其他什么...？ [英] Moving a Stick figure, anchorpoints, animation, or something else...?

问题描述

好吧，所以我在用cocos2d在游戏中制作一个游戏。
不同的东西需要动画，所以请给我一个建议，什么是最好的方式去完成这些东西的运动：

1. 主角 - 他是左下角的弓箭手，除了他会移动他的上半身，因为你需要改变你拍摄角度的角度...




2. 敌人 -

如何使1和2移动？我应该掌握锚点并使用那些？ （我真的讨厌愚蠢的锚点，他们是那么难以工作...但我会使用这些，如果他们更好）
或制作吨的动画，或有另一个更简单的方法来组合许多精灵单运动？

解决方案

我的一般建议：从来没有修改默认锚点（0.5f，0.5f），除非你有一个很好的理解它的作用，它如何帮助你完成的事情。在所有其他情况下，请修改position属性。

特别是如果您使用边界框或基于半径的碰撞检测，修改定位点会产生负面影响。

让我们假设你的矩形精灵图片使用一个默认的锚点，它在纹理的中心：

  ._______。 
 | | 
 | | 
 | * | 
 | | 
 | | 
°-------°
  

*标记纹理的anchorPoint 。如果你把这个精灵放在位置（250,100），那么精灵的anchorPoint将在坐标（250,100）。

假设您将anchorPoint移动到（0.1f，0.1f）：

  ._______。 
 | | 
。 | 。 | 
 | | 
 | | 
 | * | 
°-------°
 
°°
  

子画面的位置保持不变（250,100）。 anchorPoint位置也不会改变。什么变化是纹理如何围绕该点居中。在通过查看浮点修改锚点之前，可以看到先前的图像位置。实际上，所有你通过修改anchorPoint是移动（偏移）相对于节点的位置绘制节点的纹理。

在上述情况下，纹理现在以其左上角位于节点位置的中心。你不能再依赖于精灵标记精灵图像中心的位置。如果您为游戏中的每个节点任意修改anchorPoint，则节点的视觉表示与其位置之间不再有任何相关性。因此，为游戏对象修改anchorPoint是不好的设计。

此外，旋转或缩放将始终以anchorPoint为中心。修改anchorPoint在旋转或缩放节点时可能会导致不希望的行为。

让我们假设一个奇怪的，最坏的情况，但是完全可能的情况下，anchorPoint不再在纹理内：

  ._______。 
 | | 
 | | 
 | | 
 * | | 
 | | 
°-------°
  

这意味着该精灵的位置偏移到实际图像正在显示的位置的左边。这可能导致冲突检查差异，特别是上述情况将完全使基于半径的冲突检查无效。这也是一个在开发过程中困惑的情况。

如果你可以确定sprite的位置总是在它的纹理中心，而不是一些任意点，你的游戏将会更容易开发，

问题依然：

我只在以下情况下这样做，并且在所有其他情况下避免使用：

1. 将非动画纹理与屏幕/窗口边框或类似物对齐


2. 底部对齐标签，按钮或图像


3. 可以对齐修改的图片（即艺术家更新），而不修改节点位置。

1）很容易解释。假设您有一个全屏背景图像。要覆盖整个屏幕，您可以执行以下两项操作之一：

• 将位置更改为：（screen width / 2，screen
  height / 2）


• 将anchorPoint更改为（0,0）aka CGPointZero

你可以想象后者更容易做到。如果你永远不会移动背景，这是很好的。但是，对于滚动背景，我不会更改anchorPoint。

2）假设您的菜单系统调用各种按钮和图像完全正确对齐右边框的屏幕。所有按钮和图片宽度不同：即玩游戏，信用，设置，更酷的游戏！

不是找出每个图像/按钮的个别位置，通过将anchorPoint修改为（1.0f，0.5f），然后将图像/按钮精确地定位在屏幕宽度（和可变屏幕高度）：position =（screen width，100）。 >

让我们假设以下图像的位置是（屏幕宽度，屏幕高度/ 2），默认锚点（0.5f，0.5f）。您可以看到图片的右半部分位于屏幕区域之外：

  __________。 
 | 
 .___ | ___。 
 | | | 
 | | | 
 | * | 
 | | | 
 | | | 
°--- | ---°
 | 
 ----------°
  

1.0f，0.5f），图像可以整齐地右对齐右侧屏幕/窗口边框，而不管其纹理的宽度。位置保持不变：（屏幕宽度，屏幕高度/ 2）。

  __________。 
 | 
 ._______。 
 | | 
 | | 
 | * 
 | | 
 | | 
°-------°
 | 
 ----------°
  

想要在不修改anchorPoint的情况下右对齐此图像，菜单按钮或标签，则必须根据以下公式设置其位置：

 （screen width  -  contentSize.width * anchorPoint.x，screen height / 2）
  

公式仍然相当简单，但是如果节点的contentSize发生变化（这通常是标签的情况），则它变成一个杂烩，例如分数从1位开始，但随着时间增加到2,3和4位。在这种情况下，通过修改anchorPoint来对齐节点是合理的，因为它避免了每次节点的contentSize改变时重新计算位置。

3）罕见的情况下，艺术家为我提供了游戏对象的更新的图像。图像大小已经改变，所以它不再自然地适合游戏的图形。在另一方面，对象的位置已经通过游戏测试已经很好地建立，不应该改变，以避免重新测试游戏。

在这种情况下， anchorPoint，以便新图像与其他图形对齐，而不影响游戏性，是有保证的。这是一个安全的，最后一分钟的修改。不要在生产阶段开始这样做，否则你将在项目的整个生命周期中结束于anchorPoint-tweaking-hell。不要去那里！

总括：

只有在更容易对齐时才修改anchorPoint节点与其他节点或屏幕/窗口边框，或微调最终艺术而不影响游戏。

在所有其他情况下，仅使用位置移动节点。

Ok so I am making a game with stick figures with cocos2d in objective c... Different things need to be animated so please, give me a suggestion of what would be the best way to go about accomplishing the movement for these things:

1. The main character- he is an archer in the bottom left corner who does not move around, except he will move his upper body because you need to change the angle of where you are shooting the angle...

2. The enemies- hordes of stick figures coming at you that have collision detection and die when shot by an arrow sprite.

How should I make 1 and 2 move? should I master anchor points and use those? (I really hate stupid anchorpoints they are so hard to get to work... but I'll use these if they are better) or make tons of animations, or is there another simpler way to combine many sprites into a single movement?

解决方案

My general advice: never, ever modify the default anchorPoint (0.5f, 0.5f) unless you have a really good understanding of what it does and how it helps you accomplish things. In all other cases, modify the position property.

Especially if you do bounding box or radius based collision detection, modifying the anchor point is counter-productive.

Let's assume your rectangular sprite image uses a default anchor point, which is in the center of the texture:

._______.
|       |
|       |
|   *   |
|       |
|       |
°-------°

The * marks the anchorPoint of the texture. If you place this sprite at position (250, 100) then the sprite's anchorPoint will be at the coordinates (250, 100).

Let's say you move the anchorPoint to (0.1f, 0.1f):

  ._______.
  |       |
. |     . |
  |       |
  |       |
  | *     |
  °-------°

°       ° 

The position of the sprite remains unchanged at (250, 100). The anchorPoint position also doesn't change. What changes is how the texture is centered around that point. You can see the previous image position before modifying the anchor point by looking at the floating dots. In effect, all you do by modifying the anchorPoint is to move (offset) where the node's texture is drawn relative to the node's position.

In the above case the texture is now centered with its lower-left corner over the node's position. You can no longer rely on the position of the sprite marking the center of the sprite image. If you modify the anchorPoint arbitrarily for every node in the game, you no longer have any correlation between the visual representation of a node and its position. Thus it is bad design to modify the anchorPoint for gameplay objects.

Furthermore, rotation or scaling will always be centered on the anchorPoint. Modifying the anchorPoint can result in undesirable behavior when rotating or scaling nodes.

Let's assume an odd, worst case, but entirely possible scenario where the anchorPoint is no longer inside the texture:

                     ._______.
                     |       |
                     |       |
                     |       |
  *                  |       |
                     |       |
                     °-------°

That means the position of that sprite is offset far to the left of where the actual image is being displayed. This can lead to collision check discrepancies, in particular the above situation would entirely void radius-based collision checks. This is also a confusing situation to be in during development.

Your game will be far easier to develop if you can be sure that a sprite's position is always in the center of its texture, rather than some arbitrary point that you can't even see without the help of some debug drawing.

The question remains:

When would you want to modify the anchor point?

I've done so only in the following situations, and avoid it in all other scenarios:

1. to align non-animated textures with the screen/window borders or similar
2. to right/left/top/bottom align a label, button or image
3. to align a modified image (ie artist update) without modifying the node position.

1) Is easy to explain. Assume you have a full-screen background image. To make it cover the entire screen, you can do one of two things:

• change the position to: (screen width / 2, screen height / 2)
• change the anchorPoint to (0, 0) aka CGPointZero

You can imagine the latter is easier to do. If you'll never move the background, it's fine doing that. However for a scrolling background I wouldn't change the anchorPoint.

2) Assume your menu system calls for various buttons and images to be right-aligned exactly with the right border of the screen. All buttons and images differ in width: ie Play Game, Credits, Settings, More Cool Games!

Instead of figuring out the individual positions for each image/button, it is easier to simply right-align them by modifying the anchorPoint to (1.0f, 0.5f) and then position the images/buttons at exactly the screen width (and variable screen height): position = (screen width, 100).

Let's assume the following image's position is at (screen width, screen height / 2) with a default anchorPoint (0.5f, 0.5f). You can see the right half of the image is outside the screen area:

__________.
          |
      .___|___.
      |   |   |
      |   |   |
      |   *   |
      |   |   |
      |   |   |
      °---|---°
          |
----------°

With a modified anchorPoint of (1.0f, 0.5f) the image can be neatly right-aligned with the right screen/window border, regardless of the width of its texture. The position remains the same: (screen width, screen height / 2).

__________.
          |
  ._______.
  |       |
  |       |
  |       *
  |       |
  |       |
  °-------°
          |
----------°

Just for comparison, if you wanted to right-align this image, menu button, or label without modifying the anchorPoint, you would have to set its position according to this formula:

(screen width - contentSize.width * anchorPoint.x, screen height / 2)

The formula is still pretty simple, it becomes a chore however if the contentSize of the node changes, which is often the case for labels, for example the score starts with 1 digit but increases to 2, 3 and 4 digits over time. In such cases right-aligning a node by modifying the anchorPoint is justified because it avoids having to recalculate the position every time the contentSize of the node changes.

3) There are rare cases where an artist provided me with an updated image of a game object. The image size has changed, so it no longer fits naturally into the game's graphics. On the other hand, the object's position has already been well established through gameplay testing and should not be changed to avoid re-testing the game.

In such a case tweaking the anchorPoint so that the new image aligns well with the other graphics, without affecting the gameplay, is warranted. This is a safe, last-minute modification. Don't start doing this during the production phase or you'll end up in anchorPoint-tweaking-hell throughout the lifetime of your project. Don't go there!

In summary:

Modify anchorPoint only if that makes it easier to align nodes with other nodes or a screen/window border, or to fine-tune final art without affecting gameplay.

In all other cases, use position exclusively to move nodes.

这篇关于移动棒图，锚点，动画或其他什么...？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！