为什么大部分游戏中人物属性上限都是99，999而非100，1000或某个固定数值比如123？ 第1页

单纯的设计选择而已。属性上限常见的设定大致分为「2^n - 1」和「10^n - 1」两个流派，前者偏向以数据结构限制作为取值范围，后者偏向以UI显示宽度作为取值范围，但并不绝对，也有数据和UI都支持，只是程序逻辑做限制的例子。这两个从程序实现难度和性能上讲区别也不大，拍脑门随便选即可。实际作品中，9、15、31、63、99、127、255、999、9999、65535……之类的设计我都见过。

你们都拿FC超级马里奥说事，这游戏的数值系统其实很鬼畜的。

首先说命数，实际数据类型为标准ubyte，也就是很老实地用一个字节（地址0x075A）来表示0~255的数值范围，需要显示的时候再转成十进制。这是正常程序员最符合直觉的实现方式。

其特别之处在于，后台的实际数值是「不算当前这一命的备用命数」，而每次过关或死命后出现黑屏显示给你看的数则是「包括当前这一命的总命数」（80年代这两种表示法都很流行，街机比较喜欢用前一种方式表达残机数）。这两个表示方法不统一的结果就是，显示时要拿真实数值+1之后再现场换算成两位数。例如实际数值是0x02，显示出来的就是3。但是如果这里超过0x63（99）之后就会溢出造成显示出错。

金币的数据结构则是令人匪夷所思的所见即所得设计。屏幕上显示的金币数量（00~99），十位数和个位数分别用0x07ED和0x07EE两个字节控制，这两个字节不仅决定了显示内容（CHR地址），而且还直接参与游戏逻辑计算（大概意思就是吃金币时先检查个位数，<9就+1，>=9就归零且继续对十位数进行该计算）。如果你强行修改这两个地址的值，例如改成0x04、0x09，屏幕上就会显示你有49个金币。然后你再吃一个金币，就会变成50。如果你把个位数锁成超出范围的值，例如0x0A，则个位数会根据游戏CHR码表显示对应的字母、符号之类的内容，并且每次吃金币十位数都会相应进位。

每100金币奖命的逻辑跟这个显示无关，而是单独另有一个字节控制，地址0x075E。每当吃到金币的时候，这个地址的值也会跟着+1，随后立刻检查它是否==0x64（十进制100），如果满足条件就执行奖命同时清零。这个地址和上面说的显示用的两个地址是分开独立运作的。重复说一遍，奖命计数器这个隐藏数值存在并不代表游戏中的金币数值以它为准。两者是独立运作、分别累加的。

类似地，该作中的剩余时间数字也并没有像正常做法那样使用标准byte/ubyte记录，而是花了三个字节（地址0x07F8、0x07F9、0x07FA）分别表示百位、十位、个位。这三个字节也是直接参与游戏逻辑计算的，例如每一关开局的倒计时是400秒，如果你把百位数锁成0x00就会造成开局直接0秒，瞬间超时死亡。

分数同理，采用了0x07DD到0x07E2的六个字节分别来表示六位数字（另外0x07D7到0x07DC则是高分记录），并且直接参与计算。稍有不同的是这六位数字并不是从十万位到个位，而是从百万位到十位，其中百万位为0时隐藏不画。至于永远是0的个位数，呵呵，它根本就不是分数系统的一部分。个位那个0是直接画上去的图而已。尾数上直接画0这种障眼法在当年也很流行。例如魂斗罗，你以为自己打了几十万分，其实真实数值只有几千分，后边给你多画了俩0而已。

总之，一个1985年的游戏，为了表示一个百万级的数字，可以随手浪费6个字节（虽然8位CPU这样处理或许反而更方便），所以问题根本不在省内存上。机器内存容量是定死的，不用白不用。至于后来出现有存档的游戏，可利用空间也到了KB级别，也无所谓255还是999了。

至于为什么「很多游戏」选择使用「10^n - 1」类而不是「2^n - 1」类数字作为数值上限设计，这就没法回答了，具体到每个游戏上设计师都可能有自己的想法。在我看来这两个没有孰优孰劣，选哪个都可以有很多原因也可以没有原因。