存储地形状态的最佳方式?
我正在使用 canvas
构建游戏。
我有在游戏初始化时随机生成的地形。地形可以通过游戏中的武器摧毁。
生成此 2D 地形时...
- 最好是简单地存储每个 x 坐标的峰值,还是存储地形的每个像素?
- 当一部分因武器伤害而被移除时,我是否应该将该像素关闭,然后重新绘制地形,或者重新绘制地形,同时通过存储的武器伤害检查每个像素是否打开?或者,在武器损坏时,我应该调整地形状态中的每个峰值,然后重新绘制吗?
I am building a game using canvas
.
I have terrain that is generated randomly on game initilisation. The terrain is destroyable via the weaponry in the game.
Here is an example of the terrain I want to generate.
When generating this 2D terrain...
- Is it best to simply store the peaks per
x
coordinate, or store every pixel that is terrain? - When a portion is removed via weapon damage, should I switch that pixel to off and then redraw the terrain, or redraw the terrain whilst checking if each one is on via the weapons damage being stored? Or, upon weapons damage, should I adjust each peak in the terrain state and then redraw?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我认为你可以安全地将地形存储在二维数组中。拥有大小约为 3000x1000 的 bool 数组可能看起来很可怕,但请放心,遍历这样的数组仍然非常快。您可以遍历整个数组 10 次,并且仍然保持平滑的动画速度。
I think you can safely store the terrain in 2D array. Having array of bools with size of like 3000x1000 may seem scary, but rest assured, traversing such array is still very fast. You can traverse this whole array 10 times and still maintain smooth animation speed.
是的,焦土!据我记得,你甚至可以炸掉原始地表以下的圆形地形(蛙跳!)。然后地形会崩溃并填补空白。因此,仅存储表面的多边形顶点坐标是不够的。每像素阵列方法似乎是一个更好的主意。
重绘问题仍然很困难。我猜想以 30fps 的速度重绘整个画布是不可行的。也许您只能重新绘制受武器影响/破碎的像素。
Yey, Scorched Earth! As far as I remember you could bomb away circle-shaped volumes of terrain even below the original surface (leapfrog!). Terrain will then crumble and fill the gaps. Hence storing only polygonal vertex coordinates of the surface will not suffice. A per-pixel array-approach seems like a better idea.
The redrawing issue remains difficult. I guess it is not feasible to redraw the whole canvas at 30fps. Maybe you can redraw the weapon-affected/crumbled pixels only.
假设您将地形分割成子方块。
之前:
之后:
这些小节可以有三种状态:
这应该会给您一个不错的优化,而不会严重牺牲代码的可读性。
Let's say you split your terrain into subsquares.
Before:
After:
You can have three states for these subsections:
This should give you a decent optimization without seriously sacrificing readability of code.