如何存储二维瓦片地图？
考虑《塞尔达传说：众神的三角力量》中的图块和图层。在图块编辑器中存储此地图的理想方式是什么？目前我正在使用矩形的多维数组作为单层。这些图块图层的列表组成了地图。每个矩形都与图块集中的矩形相对应。然而，这样做的问题是，在编辑地图时应该允许编辑地图尺寸（宽度、高度和图层数）。
目前，当有人编辑地图的尺寸时，我只是创建一个具有指定尺寸的新数组。这工作得很好，但现在我添加了撤消和重做支持，事情开始变得复杂，因为每次用户更改地图的尺寸时，我都必须在每次更改之前存储整个地图的副本。现在我正在考虑其他方式。
是否最好只拥有一个最大地图大小，并在启动时将数组设置为该大小，这样我就不必如此频繁地创建新数组并复制数据？也许使用列表的列表而不是多维数组怎么样？
我不确定我对当前设置的感受如何。最初我对此很满意，但现在我有了新的想法。我目前根本没有注意到速度变慢，所以也许我正在做过早的优化（这当然很糟糕），应该忘记整篇文章。我不知道。我想听听大家的想法。
Consider the tiles and layers from Legend of Zelda: A Link To The Past. What would be an ideal way to store this map in a tile editor? Currently I am using a multidimensional array of Rectangles as a single layer. A list of these tile layers consist of the map. Every rectangle corresponds with the rectangle from the tileset. However, the problem with this is that editing the map size (width, height, and layer count) should be allowed while editing the map.
Currently when someone edits the dimensions of the map I just create a new array with the specified dimensions. This works fine and all but now that I am adding Undo and Redo support it's beginning to complicate things because every time the user changes the dimensions of the map I have to store a copy of the entire map before the change each time. Now I am considering other ways.
Would it be better to just have a MAX map size and just make the array that size at launch so I would not have to be creating new arrays and copying over data so often? What about maybe using a List of a List instead of a multidimensional array?
I'm not sure how I feel about my current setup. Initially I was fine with it but now I'm having second thoughts. I am not currently noticing a slowdown at all so perhaps I'm doing premature optimization (which is bad of course) and should just forget about this whole post. I'm not sure. I would like to hear what you all think though.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
出于撤消/重做操作的目的，您可以放心地假设为此不需要优化，原因如下。
1) 撤消/重做操作不会经常用于更改地图尺寸。通常，编辑地图时，尺寸不会经常更改。
2) 即使使用撤消/重做操作，重新创建数组也不会是一个大问题。
您可以将“Tile”存储为其自己的对象，并使数组中的每个元素成为对“Tile”对象的引用。在 32 位计算机上，256x256 地图应需要 256 KB 用于图块引用，而 1024x1024 地图则需要 4 MB 用于图块引用。图块本身中的数据可以保留在内存中并且不能移动。
在现代计算机上，4 MB 的阵列副本不会花费任何明显的时间。
如果数据大小必须更大，那么最好的解决方案是警告用户更改尺寸无法撤消。用户应在更改尺寸之前保存地图的副本。同样，尺寸不会经常改变，并且由于尺寸改变后地图通常完全不同，因此用户可能倾向于拥有先前版本的副本。
For the purposes of Undo/Redo operations, you can safely assume that optimization is not necessary for this, for the following reasons.
1) It won't be very often that an undo/redo operation will be used to change map dimensions. Usually, when editing a map, the dimensions do not change very often.
2) Even if an undo/redo operation is used, re-creating the array need not be a large problem.
You can store a "Tile" as its own object, and have each element in the array be a reference to the "Tile" object. On a 32-bit computer, a 256x256 map should require 256 KB for the tile references and a 1024x1024 map would be 4 MB for the tile references. The data in the tiles themselves can stay in memory and not be moved.
A 4 MB array copy will not take any noticeable length of time on a modern computer.
If the data sizes must be larger, then the best solution is to warn the user that changing the dimensions cannot be undone. The user should save a copy of the map before changing dimensions. Again, the dimensions will not change very often, and since maps are generally radically different after the dimensions change, so the user may be inclined to have a copy of the previous version anyway.