早期开发日志

之前在学校做的那个，当时还是比较满意的。现在越看越别扭。

 

说的是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 个的游戏 , 分了类之后就更少啦，是否是必要的呢？