在 2D 横向卷轴中实现 z 轴

发布于 2024-08-18 15:08:45 字数 489 浏览 10 评论 0原文

我正在制作一个类似于 Castle Crashers 的横向卷轴游戏，现在我正在使用 SAT 进行碰撞检测。这很好用，但我想通过允许对象在屏幕上上下移动（基本上沿着 z 轴）来模拟关卡“深度”（就像这个屏幕截图 http://favoniangamers.files.wordpress.com/2009/07/castle-crashers-ps3.jpg)。这不是等距游戏，而是使用视差滚动。

我将 az 组件添加到我的矢量类中，并且我计划根据形状的“厚度”及其 z 位置来剔除碰撞。我只是不确定如何计算渲染形状的位置或如何添加重力跳跃。如何计算 z 位置变化时的最大 y 值（地面）？基本上是 z 轴和 y 轴的关系让我困惑。

如果有人知道这个主题，我将不胜感激资源链接。

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

九厘米的零° 2024-08-25 15:08:45

实际上可以使碰撞检测算法在维度上不可知。只要有一个沿一个维度工作的碰撞检测器，用它来检查每个维度，你对“这些是否碰撞”的答案就是沿每个维度的碰撞检测的逻辑“与”。
您的游戏应该进行组织，以保持游戏对象的交互和游戏在屏幕上的渲染完全分开。您可以将程序的这两个部分视为“模型”和“视图”。在模型中，您拥有一个具有 3 个轴的完整 3D 世界。在这一点上你不可能在没有一定程度痛苦的情况下半途而废。您的模型必须是正确的 3D。

视图将读取所有游戏对象的位置，并使用相机定义将它们投影到屏幕上。对于这一部分，您不需要完整的 3D 渲染引擎。您所谈论的透视的正确技术术语是“倾斜”，它可以在许多古代中国和日本的卷轴画和版画中看到 - 特别是寻找“源氏物语”的图像。

对象在屏幕上的位置（包括地面！）是这样的：

DEPTH_RATIO=0.5;
view_x=model_x-model_z*DEPTH_RATIO-camera_x;
view_y=model_y+model_z*DEPTH_RATIO-camera_y;

您可以修改为直线正投影：

DEPTH_RATIO=0.5;
view_x=model_x-camera_x;
view_y=model_y+model_z*DEPTH_RATIO-camera_y;

当然，不要忘记剔除相机定义的体积之外的对象。

您还可以使用此机制来为您处理视差层的定位。当然，这只是将相机更改为 1 点透视投影而不是正交投影的问题。您不必使用它来更改精灵的渲染大小，但它将帮助您实际管理对象的 x 位置。如果您愿意接受挑战，您甚至可以混合使用投影 - 对深层背景使用 1 点透视，对前景使用正交投影。

It's actually possible to make your collision detection algorithm dimensionally agnostic. Just have a collision detector that works along one dimension, use that to check each dimension, and your answer to "are these colliding or not" is the logical AND of the collision detection along each of the dimensions.
Your game should be organised to keep the interaction of game objects, and the rendering of the game to the screen completely seperate. You can think of these two sections of the program as the "model" and the "view". In the model, you have a full 3D world, with 3 axes. You can't go halvesies on this point without some level of pain. Your model must be proper 3D.

The view will read the location of all the game objects, and project them onto the screen using the camera definition. For this part you don't need a full 3D rendering engine. The correct technical term for the perspective you're talking about is "oblique", and it can be seen in many ancient chinese and japanese scroll paintings and prints- in particular look for images of "The Tale of Genji".

The on screen position of an object (including the ground surface!) goes something like this:

DEPTH_RATIO=0.5;
view_x=model_x-model_z*DEPTH_RATIO-camera_x;
view_y=model_y+model_z*DEPTH_RATIO-camera_y;

you can modify for a straight orthographic front projection:

DEPTH_RATIO=0.5;
view_x=model_x-camera_x;
view_y=model_y+model_z*DEPTH_RATIO-camera_y;

And of course don't forget to cull objects outside the volume defined by the camera.

You can also use this mechanism to handle the positioning of parallax layers for you. This is of course, a matter changing your camera to a 1-point perspective projection instead of an orthographic projection. You don't have to use this to change the rendered size of your sprites, but it will help you manage the x position of objects realistically. if you're up for a challenge, you could even mix projections- use 1 point perspective for deep backgrounds, and the orthographic stuff for the foreground.

回复收藏 0 原文

傾旎 2024-08-25 15:08:45

您应该将物理计算（碰撞检测等）使用的概念 Y 轴与您实际在屏幕上绘制的 Y 轴分开。这样就变得不那么混乱了。

只需按照正常情况进行计算，假装 Y 轴和 Z 轴之间没有关系，然后当您实际在屏幕上绘制对象时，您可以使用 Y 轴模拟 Z 轴：

screen_Y = Y + Z/some_fudge_factor;

实际上，这就是真正的 3D 引擎的工作方式。完成所有世界计算后，X、Y 和 Z 坐标通过函数映射到 screen_X 和 screen_Y（通常比上面的方程复杂一点，但只是一点点）。

例如，要在游戏中实现伪等距视图，您甚至可以将 Z 应用于 screen_X 轴，以便对象沿对角线而不是垂直方向移位。

You should separate your conceptual Y axis used by you physics calculation (collision detection etc.) and the Y axis you actually draw on the screen. That way it becomes less confusing.

Just do calculations per normal pretending there is no relationship between Y and Z axis then when you actually draw the object on the screen you simulate the Z axis using the Y axis:

screen_Y = Y + Z/some_fudge_factor;

Actually, this is how real 3d engines work. After all the world calculations are done the X, Y and Z coordinates are mapped onto screen_X and screen_Y via a function (usually a bit more complicated than the equation above, but just a bit).

For example, to implement pseudo-isormetric view in your game you can even apply Z to the screen_X axis so objects are displaced diagonally instead of vertically.

回复收藏 0 原文

~没有更多了~