http://www.qidian.com/BookReader/14004,384059.aspx

　　如果事情仅仅如此，恐怕就不会出问题。

　　遗憾的是，同时还发生了另外几件事。

　　第一件，游戏摇杆和按钮的输入是有缓冲区的。当初是为了在来不及相应控制信息的情况下暂时保存用户操作，以待处理器空闲时逐步按照顺序处理。只不过编码的时候草率了一些，没有及时清空缓冲区。就是说，在一个构件已经落下，另一个构件还没出来的时候进行输入，下一个构件出现后就会按照刚才的输入进行动作。

　　消息队列的设计在软件里面司空见惯，范含在这个地方犯了一个想当然的错误。可能是平时模拟器玩惯了，把摇杆的消息和按钮的消息统一起来当作 “KeyDown”处理。实际上，摇杆作为指点设备，应该像鼠标那样。在Windows里面，大部分消息都是一条当作一条，直接放进队列。但是 “MouseMove”例外，仅仅是做一个标记，表示当前鼠标正在移动。对于这种极为频繁的消息，这么处理是相当妥帖的。否则的话，只要鼠标划过屏幕，队列就会被填满。就是因为这样，范含当初在向德州仪器交待需求的时候说的就是“压住摇杆不动就要连续不断地发出信号”。

　　第二件，Emacs的俄罗斯方块游戏是在按“下”的时候直接将构件落到底部。范含写源代码的时候照猫画虎，FEEE的工作人员当然不会擅自改动，说不定都以为这个游戏本来就是这样的。不像后来红白机上那样，按住“下”不松开是加快下落速度，松开后速度恢复正常。平心而论，后来的这个设计更是合理，操作性更强。但是在现在，范含和其他FEEE的人员都是闭门造车，发布之前就没有征求过玩家的意见。用户和程序员看待问题的角度是不一样的，程序员怎么看自己的作品怎么觉得顺眼，用户则不然。像软件开发中的“用户体验”，“人性化”这种东西，必须向闲杂人等们收集意见。于是，只要一个“下”，构件就会直接到达底部，不管中间有多长。

　　虽然这一点没考虑到，但是范含考虑到了另外一点“人性化”的需求，就是允许构件在到达底部的时候还能左右移动。这是一个相当合理的设定，许多悬空的空格就是由于这种技巧的存在而能够被填充。但是，编码的时候范含又犯错误了，犯了一个和某一款早期“文曲星”产品上面俄罗斯方块游戏相同的错误。这种底部的左右移动式是没有时间限制的。原来玩文曲星上面的方块游戏的时候，一旦没考虑好，就可以不停的“左右左右左右……”移动，直到考虑好了再进行下一步动作。后来的修正版本里面，构件到达底部之后，有且仅有一拍的活动时间。

　　第三件，伪随机数的设计过于简单。下一个构件是什么样的形状，是根据一个随机数从七种形状中选择的。这里的随机数实际上是伪随机数，根据一个“种子”由发生器按照某种规则生成的序列。范含编码的时候，用的是随机数函数，但是硬件人员设计的时候，必须做成电路。最终的机器里面，只有一种规则。按理说，只要种子不同，随机序列就是不同。只不过，一个4位字长的机器，只用了一个字表示种子，仅仅有16种可能。

　　这就是说，只要见到第一个构件出现，同时还能看到旁边的下一个构件的提示，就足以知道后面所有的构件出现的顺序。玩过一段时间的有心的玩家，就已经能够记住所有的16种可能的出现规律。一个依赖于随机性的游戏，一旦随机性不存在了，剩下的就纯粹是技巧的较量。无数玩家都设计好了每一步的行动，就看谁玩的时候反应快了。

　　第四件，和前面三件不同的是，这个不是错误，而是正常的功能。每过一关，就会有一段音乐，屏幕上还有一些闪烁的文字，祝贺玩家什么的。这段时间大约十几秒钟。每填满一行方块，该行就会闪烁一下，然后再消失。这段时间大约一秒钟。

　　这四件事情连在一起，使得经典俄罗斯方块从娱乐变成了锻炼。

　　一个精明的玩家，完全可以从开始就判断出构件序列，按照预先设计好的方案，四行四行的得到每关最高分。由于摇杆缓冲区的缺陷，玩家完全可以不管屏幕上出现什么，只要按部就班的将方案中的操作序列输入，保证没有错误即可。到了后来，速度变快，仍然有每关之初的十几秒钟和每消掉四行就能争取到的四秒钟用来输入。

　　使用这种策略，美国玩家的最好纪录就是打到第十二关……最后一关，但是从来没有通关，因为即便加上所有赚来的时间，仍然超过了人类的最快输入速度。但是在日本就不一样了，由于频率是50Hz，六十拍大约是1.2秒，比起美国来慢了百分之二十。这百分之二十的额外时间就足以使得一些顶尖玩家通关。

　　所以，计分器溢出了，分数重新从零开始。



这么稀奇古怪的桥段怎么想到的啊！！

[ 本帖最后由 md2 于 2011-3-14 23:57 编辑 ]

只为沙发

挖槽 好内涵啊 看不懂啊

写的不错的穿越爽文阿.....

posted by wap, platform: HTC Bravo

这书很内涵

````````````完全看不懂``

原来是《电子生涯》

一个程序员写的小说，在我看过的所有小说当中最严谨的了。

厉害，这个真内幕，寓教于乐的典范啊

posted by wap

麻痹，喷了……

刚好在果壳网上看到一篇关于PACMAN的，节选一段：
http://www.guokr.com/article/12562/

当你玩“吃豆人”的时候，你很可能会有一个感觉：小豆人一直在被幽灵们追赶！事实上并非如此。岩谷彻特地没有这么编写的原因是，如果这样的话就会使所有的幽灵满屏幕地追赶小豆人。真相其实是这样：

红色幽灵Blinky：游戏中只有它是才会锲而不舍地追赶小豆人。

粉色幽灵Pinky：它的目标是小豆人嘴前方32像素的位置。

蓝色幽灵Inky：同样也是一直在努力让自己跑到某个特定的像素位置。

橘色幽灵Clyde：它完全是随机运动的。

由于小豆人需要不停地到处吃豆豆，所以幽灵们会随之不停地改变方向达到自己的目标，这就给玩家们带来了更大的挑战。



编程思路真是有趣:D

posted by wap, platform: Nokia

这才是好文