打败他们游戏空间管理？
我正在为 Beat'em Up 游戏制作 2D 引擎（Castle Crashers 就是我所说的 Beat'em Up 或 Brawler 类游戏）。
我将支持 2D 精灵和 2D 粒子发射器。现在这一切都在引擎中完成。但我遇到了一个问题，想征求意见：
这是关于“空间”管理的，我认为要做一些如图所示的事情：
alt text http://img337.imageshack.us/img337/9162/spacingprototype1.png
我的想法是制作一个网格（空间哈希或网格），我的粒子发射器/2D 精灵将居住的地面。在我的图片中，我从 1 到 N 列举了这个插槽（不必是 35，这只是为了显示目的）。我的想法是按照从 0 到 N 的顺序绘制“GameElements”（精灵/发射器）（从存储桶 0 到存储桶 N），这样我就可以让它们在屏幕上正确重叠地显示（从后到前）。
我知道这可以通过比较每个元素的较低 Y 轴并执行“快速排序”来完成，但是拥有网格可以让我以更好的方式执行碰撞检测，并且如果我执行类似 A* 的操作来实现某种人工智能，它也可以帮助我。
I am in the process of making my 2D engine for a Beat'em Up game (Castle Crashers is what I call Beat'em Up or Brawler kind of game ).
I will support 2D sprites and 2D particle emitters. This is all done in the engine now. But I have come to an issue that I would like to ask for advice:
It's about "space" management, what I thought was to do something as this image shows:
alt text http://img337.imageshack.us/img337/9162/spacingprototype1.png
My idea is to make a grid ( Spatial Hash or Grid ), of the ground where my Particle Emitters / 2D sprites will live. In my picture, I have enumerated this slots from 1 to N, (don't have to be 35, it's just for showing purposes ). My idea is to draw the "GameElements" (Sprites/Emitters) in order from 0 to N , ( going from bucket 0 to bucket N ) , so then I will get them to display correctly overlapped on screen (back to forward).
I know this could be done by just comparing the lower Y axis of each Element and performing a "quicksort" too, but having the Grid could allow me to perform Collision Detection in a better way , and if I do something like A* to implement some kind of AI, it could help me too.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您想对需要相互测试的对象数量进行某种优化，您可能需要考虑使用四叉树
http://en.wikipedia.org/wiki/Quadtree
这个想法是划分屏幕分成 4 个节点，将所有项目放入它们所属的节点中，然后将刚刚创建的节点划分为另外 4 个节点（如果其中有精灵/项目/任何需要测试的内容）。继续执行此操作，直到节点中的项目达到一定大小或数量。
然后，您可以询问顶部节点是否包含您要测试的项目。然后，该节点将询问子节点是否包含该项目，子节点又会询问其子节点。这样，屏幕的很大一部分就可以被跳过（如果它位于子 00 中，您可以跳过子 01、10 和 11）。然后，您将获得一个项目列表，您可以在需要时对其执行更具体的碰撞检测。
如果要使其可视化，它看起来有点像这样：
替代文本 http://geodata.ethz.ch/geovite/tutorials/L2GeodataStructuresAndDataModels/en/images/quadtree.gif
If you want to have some sort of optimization for the number of objects you need to test against each other, you might want to think about using a Quadtree
http://en.wikipedia.org/wiki/Quadtree
The idea is to divide the screen up in 4 nodes, placing all items in the node they belong, then divide the nodes you just created up in another 4 if there are sprites/items/whatever in there that need to be tested. Keep doing this until a certain size or amount of items in a node has been reached.
You can then ask the top-node if it contains the item you want to test. This node will then ask the child-nodes if it contains the item, which in their turn will ask their children. This way a large part of the screen can be skipped already (if it's located in child 00, you can skip child 01, 10 and 11). Then you get a list of items you perform more specific collision detection on when it's desired to do so.
If you were to make it visual, it would look a bit like this:
alt text http://geodata.ethz.ch/geovite/tutorials/L2GeodataStructuresAndDataModels/en/images/quadtree.gif
将它们发送到 Z 缓冲区并让其担心。
如果您发现将来它太慢（显然是通过分析），那么请考虑优化它。
采用最简单的解决方案并继续。
Fire them out to the Z buffer and let that worry about it.
If you find that in the future it is too slow (via profiling obviously) then look at optimizing it.
Take the simplest solution and move on.
如果您有两个精灵占据网格中的同一个框，则您的方法将失败。假设你有两个敌人都站在同一个盒子里。一个人稍微站在另一个人的前面。你先画哪个？您将需要两种算法 - 一种将精灵划分到网格中，第二种算法查看给定网格框中所有精灵的 z 坐标并根据该值绘制它们。
一种更简单的方法是拥有所有精灵的单一集合。它应该存储按 z 坐标排序的所有精灵（从列表头部的屏幕背面到背面的屏幕正面）。循环遍历集合并绘制出现的每个精灵。当精灵移入或移出屏幕时（即它的 z 坐标发生变化），您可以执行非常简单的排序来在集合中移动该单个精灵。继续将其与列表中的下一个精灵交换，直到下一个精灵的 z 坐标大于/小于（视情况而定）已更改精灵的坐标。
Your method fails if you have two sprites occupying the same box in the grid. Suppose you have two enemies both standing in the same box. One stands slightly in front of the other. Which do you draw first? You would need two algorithms - one which divides the sprites into the grid, and the second which looks at the z co-ordinates of all the sprites in a given grid box and draws them based on that value.
A far simpler method is to have a single collection of all sprites. It should store all sprites sorted by their z co-ordinates (from the back of the screen at the head of the list to the front of the screen at the back). Loop through the collection and draw each sprite as it appears. When a sprite moves into or out of the screen (ie. its z co-ordinate changes) you can perform a very simple sort to move that single sprite within the collection. Keep swapping it with the next sprite in the list until the next sprite's z co-ordinate is greater than/less than (as appropriate) the changed sprite's co-ordinate.