iPhone游戏黄金矿工地图格式破译及编辑器的编写

GF迷上了iPod游戏黄金矿工，所以平时也跟着玩玩。但这个游戏实在比较无聊，忍不住要让人折腾两下。
 
由于程序不是Windows平台下，反编译难度太大且不必要。主要的精力就放到了修改存档和地图上。用91手机助手查看MacOS下的文件，在/usr/Applications下面轻松找到乐GoldenMiner对应的文件夹，点进Documents文件夹就是它的存档。用XML写的，对修改者非常友好，用记事本就把钱改到了1,000,000，进度也可以随便改，好吧，游戏性彻底丧失了。进一步探索游戏文件夹，发现很多资源图片文件，又试了一下把金子图标换成GF照片之类。

当然这些都是一些低级把戏，来玩一些高级一点的东西。进一步搜索发现很多mapxxx.hmb的文件，毫无疑问是地图，看来有300关呢，看不出来这游戏规模还挺大~随便找一个文件用UltraEdit打开，可以发现文件并不复杂。
 
在玩的过程中发现第100关比较有挖掘的潜力，因为只有3种物品：炸药桶，跳跳鼠还有钻石鼠。打开第100关的地图，内容如下：

 
前面的结构很容易看懂，游戏的时间是60秒，背景是aozhou.png，过关所需金钱数是114794(这里有点不匹配，这个是map99.hmb的过关所需金钱数)。后面自然就是地图的结构了。这部分结构很简单，4字节为一组，显然是整型数，一共52个。破解地图结构的关键就在于了解这52个数是怎么描述物品分布的。考虑到这个地图有4个跳跳鼠，5个钻石鼠和8个炸药桶，一共17个物品，并不是52的约数，因此看上去并不像是按照"每个物品一个定长记录"的方式存储的。再观察一下发现，大多数整数是小于0xFF的，但有些数在第二低位字节是01而不是00，这些数是否可能是分隔符呢？短暂的兴奋过后就发现，一共有7个"01"，相当尴尬的一个数字，很难想出有什么特别的含义。推理一时陷入了僵局。

既然一条路不通，就可以从另一个角度来思考。如果我来开发这个程序会怎样设计呢？最直观的方案有两种，一种是将整个地图划分成同样大小的格子如10 * 8个小格，然后依次记录每一个小格中放置的物品种类。这种方案的特征是：所有的地图文件必然同样大小，而且会频繁出现某个表示"该位置什么都没有"的整数。这与地图文件的情况矛盾，因此不太可能。而另一种方案则是记录每一个物品的类别和其他参数如所处的坐标。虽然17不是52的约数，但考虑到并不一定后面所有的记录都用来描述物品的分布，因此这种方案仍然是可能的。由于游戏中物品的种类并不多，前100关仅出现了约20个，所以如果采用这种方案，记录物品ID的那一项必然会是一个比较小的数。从这个角度出发重看后面的数据，会发现一个很明显的规律：这些数字以3个为一组，第一个很小(一般小于0x10)，后两个则相对较大(甚至大于0x100)。最后多出一个0x0F。多出来的0x0F比较诡异，莫非是传说中的结束符？调出map1.hmb看一下发现最后一个数是0x0c，因此不像是固定的结束符。那看来多出来的是第一个数了。map100中第一个数是0x11，亦即十进制中的17。17，好熟悉的数字啊，正好就有17个物品嘛！好乐，游戏地图的秘诀也被攻破了。最前面一段记录游戏时间，背景，过关要求等参数，然后紧跟物品的个数，接下来以<物品类别，横坐标，纵坐标>的格式对每个物品的信息进行记录。根据测试可以知道，坐标原点在屏幕的右下角，单位为像素。

有了这些信息就可以造地图编辑器了。用WPF在20分钟内就可以写出来一个：

把生成的地图文件上传到iPod里就可以看到效果：

 

黄金矿工玩成这样也算比较尽兴了。计算机系的学生玩游戏就应该这样嘛~:-) 当然这里面有不少侥幸的成分，比如地图文件很容易找到，几乎是明文保存没有加密等等。如果要更深层地玩，还得痛下苦功才行。恩恩，还是在专业本行方面多玩玩比较好。:-)