之前在学校做的那个,当时还是比较满意的。现在越看越别扭。
说的是1.1版本,其实是重新开发的。不过也没有什么新意,主要想把NEOGEO上面的炸弹人游戏完整的模拟出来。计划今后可能还会把魂斗罗之类的旧游戏都做一做,当技术达到一定层次的时候。再实现自已的游戏,不过那都是以后的事了,扯得远了。
游戏用的是clanLib开发库,说来惭愧,游戏制做从开始到现在已经过个三个月了。实质上还没有什么进展,竟然连个游戏地图编辑器都还没有完成。尽管前面的时间是用来了解这个开发库,不过时间也太长了点吧,原因应该就是自已的懒惰了吧。(看来还得找份工作干一干才行哪)
(注:下面neogeo通指在neogeo上的炸弹人游戏,bomman通指我现在所做的游戏)
游戏设计:
1.人物的平滑移动
经过观察,发现NEOGEO在640X480象素的情况下,人物移动是以每4象素为单位。一个方格要移动5次才能走完,即每个方格为20X20象素的面积。而且我在试验的时候,在64fps以及速度调成与NEOGEO中人物的最快及最慢速度,画面还是平滑的,都没有问题。
另外还有一个原来比较头痛的问题就是人物移动速度的指标,本来打算把人物移动速度分成10个等级。但是我发现就算是最快的每个fps都移动(每次移动定死为4个象素),人物还不能达到NEOGEO中的那种最快速度,可是如果提供的移动不是以4个象素为单位,那么当人物移动的时候就会有差几个象素的麻烦情况出现。人有时候就是会犯傻,后来我注意到,其实每个fps不一定只调用一次人物移动,可以根据时间,有时可以调用两次,有时也可以不调用,那么对于人物移动的碰撞检测就不会造成什么麻烦。使用这种方式就可以达到上面所说的效果啦。
2.碰撞检测
1.0的碰撞检测做得很次,当每做一次碰撞检测都要遍历所有的物体,所幸的是当时游戏中的物体数据并不多,大约50个左右。根据上面所说的,移动的最小单位为4象素,所以这次打算以160x120的数组保存碰撞检测的数据。因为在大多数情况下,我们只要知道是否发生碰撞,而不是知道与谁进行碰撞。它的结构体在概是这个样子的:
struct {
int hard_box; //格子的硬性碰撞物数量
int box; //格子有多少碰撞物,为了支持后面的穿墙功能,近而区分是否可以穿透的墙
int man; //当前格子的人物数量
int prize; //格子的奖品数量
};//嗯,算下来数据量也只有300k,还是可以接受的哦。
但是有些特别的对象可能会需要知道,碰撞的是谁,比如火焰,这个时候就可以根据格子中的数据线性的搜索相关的类别。
4.移动时人物的调整
在内存中的数据可能是这样的(只列出人物数量的数据,假设一个人占用2x2的格子)
0,0,0,0,0,0,1,1,0
0,0,1,1,0,0,1,1,0
0,0,1,2,1,0,0,0,0
0,0,0,1,1,0,0,0,0
如果最左边的人物一但移动,数据可能会变成这样:
0,0,0,0,0,0,1,1,0
0,1,1,0,0,0,1,1,0
0,1,1,1,1,0,0,0,0
0,0,0,1,1,0,0,0,0
3.游戏中部分主要数据的组织
一个包含所有物体ID的排序,用于绘图
一个包含所有人物ID数组,用于接收输入数据
一个包含所有炸弹ID的数组
一个包含所有BOX ID的数组
一个包含所有奖品 ID 的数组
4.一点点的优化:
也许可以把所有物体的各种表都进行排序,那么寻于查找碰撞物体应该有个加速。
而且各种排过序的物体再近行总排序是很快的,所以之前的排序对显视物体的排序并不
会增加太大的负担。
不过对于物体数量不超过 150 个的游戏 , 分了类之后就更少啦,是否是必要的呢?