33,008
社区成员
发帖
与我相关
我的任务
分享恶魔城游戏中的地图问题
最近一直在考虑恶魔城里面的那种地图的结构是什么样的？如果用很大的矩阵有点不现实，因为其地形比较复杂，还有很多地方有曲线的地形出现，但是如果不是用大矩阵那又是什么呢？跟地图中的障碍物比如不同高度的楼梯之间的碰撞检测又是如何做的呢？请各位分析下看看，答的有道理者给高分！
...全文
请发表友善的回复…
发表回复
blackprogramming 2006-01-04
- 打赏
- 举报
我顶
blackprogramming 2006-01-03
- 打赏
- 举报
楼上的请问何解？
movieqiu 2005-12-21
- 打赏
- 举报
晕,用不着想那么多么
从FC上的超级马里奥设计时代就开始了,分块的场景设计思想,你仔细看一个平面游戏,都会发现原来场景是这种小方块一样的单元组成的,重复度其实很高的,当然这还得看美工的能力,让你初看看不出来
有些三维游戏的场景设计延续了这个思路,以立方体作为场景设计的基本单位,比较有代表性的是<古墓丽影>,有空可以去找个它的地图编辑器看看
从FC上的超级马里奥设计时代就开始了,分块的场景设计思想,你仔细看一个平面游戏,都会发现原来场景是这种小方块一样的单元组成的,重复度其实很高的,当然这还得看美工的能力,让你初看看不出来
有些三维游戏的场景设计延续了这个思路,以立方体作为场景设计的基本单位,比较有代表性的是<古墓丽影>,有空可以去找个它的地图编辑器看看
microfans 2005-12-17
- 打赏
- 举报
晕~~~~
dengsf 2005-12-12
- 打赏
- 举报
这样的数据量是不大的，
我估计从 FC 到 GBA 的都是这样做的，
顶多是优化一下减少一点数据量，但这样做的目的估计主要是为了减少内存，不是为了传输。
P.S：GBA不是不需要读盘，只是 ROM 的速度比 PS 的 CD2x 快很多而已。
CPU执行的指令都是通过MAPPER直接从ROM里读出来的执行的，无须进入RAM，可以想象速度有多快～～
我估计从 FC 到 GBA 的都是这样做的，
顶多是优化一下减少一点数据量，但这样做的目的估计主要是为了减少内存，不是为了传输。
P.S：GBA不是不需要读盘，只是 ROM 的速度比 PS 的 CD2x 快很多而已。
CPU执行的指令都是通过MAPPER直接从ROM里读出来的执行的，无须进入RAM，可以想象速度有多快～～
dengsf 2005-12-12
- 打赏
- 举报
我想 1 2 3 类的地形其实都类似，都是定制多一些格子的类型，
地图的界限就是用这些格子“拼”出来的。
可以的话还可以加参数，比如你说的斜线的斜率，或者曲线的关键点等。
每个格子有几个参数也不是问题。
第 4 种的碰撞其实跟“角色”的碰撞十类似的，
将它看成一个特殊的敌人就行了，不要算做背景。
地图的界限就是用这些格子“拼”出来的。
可以的话还可以加参数，比如你说的斜线的斜率，或者曲线的关键点等。
每个格子有几个参数也不是问题。
第 4 种的碰撞其实跟“角色”的碰撞十类似的，
将它看成一个特殊的敌人就行了，不要算做背景。
ZeroGts 2005-12-07
- 打赏
- 举报
还可以分成小块，小块有多种类型，曾有人就这样做过恶魔城同人游戏。
ZeroGts 2005-12-07
- 打赏
- 举报
可以用顶点构成多边形。
blackprogramming 2005-12-07
- 打赏
- 举报
我顶~
blackprogramming 2005-11-27
- 打赏
- 举报
那个黑屏只是为了过渡，如果单独处理？能否详细说说？
Bobby136 2005-11-25
- 打赏
- 举报
不同场景切换的时候明显看到闪黑屏了。
斜坡曲线这些东西也不一定要包含在地图中，单独处理更好
斜坡曲线这些东西也不一定要包含在地图中，单独处理更好
blackprogramming 2005-11-25
- 打赏
- 举报
to dengsf(decision bell)：说的有道理，呵呵。月下是一个分割线，之前的恶魔城地图和之后的完全不同，当然之后的要复杂的多。
关于多类型的格子我也考虑过这样的情况，但是有个疑问，就是计算的方法，我举几个特殊地形的例子：
1. 斜线。比如GBA的月轮里面存盘点的上坡和下坡，斜率很小，而且地图中还出现过其他不同斜率的格子，那么势必需要记录格子的斜率；
2. 曲线。比如很多作中都出现过的某些场景的弧顶，这种要记录他的曲度（不知道是不是叫这个）然后在碰撞时计算；
3. 特殊地形。比如月轮中有些地形会出现类似S的曲线，这样的判断就要复杂的多，不知道是怎么做的？
4. 移动地形。比如好几作中都出现的做曲线移动的钟摆，月下中礼拜堂会摇摆的钟等。这种地形就要不断的改变数个格子的数据比如斜度，可站立的范围等等。
上面只是几种特殊地形的代表。如果要记录所有格子的所有需要的数据那么问题就是数据量可能会比较大，还有就是比如不规则曲线的地形碰撞检测也比较繁琐，但是GBA几作比如晓月场景切换都是不需要读盘的，游戏速度也没有明显的延迟，不知道是用了什么机制来处理不同场景的数据（以上的分析仅仅是地图，主角，怪物等还要复杂的多）。不知道各位有什么高见？
关于多类型的格子我也考虑过这样的情况，但是有个疑问，就是计算的方法，我举几个特殊地形的例子：
1. 斜线。比如GBA的月轮里面存盘点的上坡和下坡，斜率很小，而且地图中还出现过其他不同斜率的格子，那么势必需要记录格子的斜率；
2. 曲线。比如很多作中都出现过的某些场景的弧顶，这种要记录他的曲度（不知道是不是叫这个）然后在碰撞时计算；
3. 特殊地形。比如月轮中有些地形会出现类似S的曲线，这样的判断就要复杂的多，不知道是怎么做的？
4. 移动地形。比如好几作中都出现的做曲线移动的钟摆，月下中礼拜堂会摇摆的钟等。这种地形就要不断的改变数个格子的数据比如斜度，可站立的范围等等。
上面只是几种特殊地形的代表。如果要记录所有格子的所有需要的数据那么问题就是数据量可能会比较大，还有就是比如不规则曲线的地形碰撞检测也比较繁琐，但是GBA几作比如晓月场景切换都是不需要读盘的，游戏速度也没有明显的延迟，不知道是用了什么机制来处理不同场景的数据（以上的分析仅仅是地图，主角，怪物等还要复杂的多）。不知道各位有什么高见？
Bobby136 2005-11-23
- 打赏
- 举报
用矩阵也没有什么不可，虽然地图很大，但是是由一个一个小场景组成的，每个场景又可以
分成很多小地图
碰撞需要时可以用像素碰撞，也可以用矩形
分成很多小地图
碰撞需要时可以用像素碰撞，也可以用矩形
ensoniq 2005-11-23
- 打赏
- 举报
楼上正解，顶
dengsf 2005-11-23
- 打赏
- 举报
月下之前那种楼梯就不用专门检测了。
月下之后的我发表一点拙见：
本身由矩阵组成，
但 格子 不是仅有 通过和阻挡 两种类型，
可以多定制几种类型，比如斜线型，曲线形。
角色移动时，
先判断它落在哪个格子里，
然后由该格子本身的类型或阻挡方式来决定它在该格里的移动范围。
当然，角色可能同时落在几个格子里，
但可以适当地调整边界格子的图像使得上面的方法能比较符合画面情况。
月下之后的我发表一点拙见：
本身由矩阵组成，
但 格子 不是仅有 通过和阻挡 两种类型，
可以多定制几种类型，比如斜线型，曲线形。
角色移动时，
先判断它落在哪个格子里，
然后由该格子本身的类型或阻挡方式来决定它在该格里的移动范围。
当然，角色可能同时落在几个格子里，
但可以适当地调整边界格子的图像使得上面的方法能比较符合画面情况。
blackprogramming 2005-11-20
- 打赏
- 举报
在碰撞检测时,那里您画了阻档了,哪里就不能通过,
这是最简单的地图碰撞检测，恶魔城里面的地图结构可远不止与此呢~
这是最简单的地图碰撞检测，恶魔城里面的地图结构可远不止与此呢~
chenzhichao2008 2005-11-16
- 打赏
- 举报
我大约看了别人写的地图编辑器,
里面有一个阻档数据结构
是用一维数组表示,再将一维数组映射为二维的
对于曲线,那是图素的事了,
在碰撞检测时,那里您画了阻档了,哪里就不能通过,
我了解游戏不深,说错了不要笑话
里面有一个阻档数据结构
是用一维数组表示,再将一维数组映射为二维的
对于曲线,那是图素的事了,
在碰撞检测时,那里您画了阻档了,哪里就不能通过,
我了解游戏不深,说错了不要笑话
blackprogramming 2005-11-14
- 打赏
- 举报
自己顶~
