2D“游戏”开发：游戏逻辑和绘图的坐标答案

【问题标题】：2D "game" development: coordinates for game logic and for drawing2D“游戏”开发：游戏逻辑和绘图的坐标
【发布时间】：2020-07-14 08:48:18
【问题描述】：

我已经完成了游戏逻辑的实现，现在是时候将其可视化了——为此我选择了 SFML。但是，我一团糟：如何避免硬编码游戏对象的坐标来制作整个系统：

此外，我想知道在“真实”游戏和其他应用程序中使用了哪些方法。我想出的最佳解决方案是：

class Screen_promille由游戏逻辑操作，用于存储x和y作为屏幕使用部分的int promilles（例如{500, 500}是中心点而{999, 999}是右下角）；李>
sf::Vector2<float> convert_to_pixels(Screen_promille const) 获取屏幕上实际位置的函数（可能在绘制之前）；或者改成Screen_promille::operator sf::Vector2<float>()；
sf::Rect<float> const used_screen 用于后者的实现。

应该^足够聪明？

P。 S.：

【问题讨论】：

【解决方案1】：

简而言之，当您考虑所有可能遇到的问题时，不值得麻烦。硬编码坐标要容易得多。

解决您提出的问题的最佳方法是实施letterbox view。信箱视图应该允许您舒适地调整游戏大小而不会出现任何视觉失真，并且它应该能够自适应任何屏幕尺寸。

【讨论】：

我是否正确理解信箱视图是将整个图片放在窗口中心？这就是我现在直觉地做的事情。 :) 我的Screen_promille“发明”怎么样 - 我可以期待它与信箱视图一起很好地扩展吗？
@passing_through 信箱视图的目的是防止游戏对象在用户调整窗口大小时出现拉伸。例如，如果您有一个正方形并且您垂直调整窗口大小，那么该正方形将被垂直拉伸成您显然不想要的矩形。只要新调整大小的图像的纵横比（宽高比）与原始图像的纵横比不同，就会出现这种拉伸效果；换句话说，正方形不再是正方形，因为它没有被水平和垂直拉伸相同的量。
@passing_through 关于你的“发明”，这取决于你想要创造什么样的游戏。例如，对平台游戏的坐标进行硬编码会更有意义，例如，与游戏更“基于界面”的空闲点击器相比，如果这有意义的话。