俄罗斯方块规则设计修改版

_ElemeNt_

看了自己的文章，感觉还要修改很多地方，所以再次修改了一下，发上来看看。

花了我几个小时的时间，完成了，22：29分，吃饭去了。才知道自己没吃晚饭。郁闷

小小长空

x轴为何是纵坐标，y轴为何是横坐标捏。

ljt0000

中学里就是这样学的

爱之协奏曲

强，可以去写天书了

charmelf

楼主写的不错啊，感觉很多在职的策划都没有您分析的这么细致用心，呵呵……认识到游戏规则设计的重要性并且加以设计实践是绝对策划学习的正确途径！

不过感觉作为一个游戏规则设计文档，您的作品中有很多地方过多的写了一些程序实现细节、算法之类的东西。虽然说策划需要有这个层面的考虑和程序设计的意识，但是做为策划写的规则文档，还是应该把规则的细节说的更深入一些。

具体说来，您在积木生成、碰撞检测规则、变换规则三个部分就过多的写了很多实现算法……其实这个东西我相信一个普通的程序都会想清楚，您只需要把积木的规格、变化的情况描述一下即可；而另一方面，我发现你在规则设计中有些忽视了这个游戏的“时间单位”要素。

一般来说游戏都是有一个主逻辑循环，每走一次就是一个逻辑帧，各种什么检测啊，数据变化啊都会在里面执行，一个个逻辑帧堆砌起来就是整个游戏的时间流逝。限帧后，每秒逻辑循环走多少次就是这个游戏的逻辑帧率，那么这个时候就可以得出游戏的最基本时间单位了。

那么您写的变化规则、速度规则等都应该根据这个时间单位来制定一下。例如我规定游戏是20帧每秒，那么可能每10帧下落一格就是速度0的情况（0.5秒），9帧就是速度1……依此类推下去，速度规则的制定就更明确了。用帧去作为游戏的时间单位比秒要好，因为它直接代表了主逻辑循环的次数，两帧之间是不可能再有逻辑插入了，这样程序写起来会明确的多。同样，积木的变形是否需要时间，还是说下一帧就立即变形成下一个形状，也需要考虑清楚。

另外考虑时间后，您的碰撞检测规则也需要再深入考虑一下。我认为一般俄罗斯方块的碰撞规则是跟着移动走的，每次移动的瞬间才触发一次碰撞检测。而移动又是由下落速度和玩家操作触发的，也就是说是每下落一层的时候检测一下是否碰撞；玩家每输入一个方向的时候就检测一下是否碰撞……并不是每时每刻都在检测。同时在垂直方向上，如果检测到当前的活动积木碰到下面的堆积或者场景底部则判定积木放稳。之所以要强调这个检测碰撞的时机，因为实际上俄罗斯方块在活动方块碰到堆积或底部后，并没有立即放稳，如果玩家不输入下方向或者没有到下落的时间，还可以横向移动方块，形成从底部插入空当的技巧……这个细节必须把移动、碰撞这几层的规则考虑清楚，才能表现的到位。

noboo

ls的点评很到位，受益匪浅

AbsX

不错

yellowbigbird

看了下
对xy设定很让人晕
算法不用表示出来.
变形那里不用如此繁琐, 就是2种旋转而已.顺逆时针
lz可以尝试看看程序, 了解下游戏流程

ahalyb2000

5楼的评论不错~
LZ写的很详细，比起一些策划来，可说是非常用心的在写这个规则了。

不过，可能LZ对于文案的繁简控制把握的不是很好。
    说是“可能”，是因为我不清楚你写规则的初衷是什么。如果你自己有编程能力，想要自己编写出这个游戏，是从编程的角度在写这个规则的话，那么写的这么详细是没问题的。
    如果自己是策划，那么最好还是从玩法入手，尽量少涉及到底层算法这些东西。比如5楼提到的下落时的碰撞检测问题，如果你不是把重心放在方块旋转的坐标算法上，应该会发现那块需要再补充些文字。

    还有，出于感情上的考虑，如果你是策划的话，也不要涉及到算法。因为那是程序的范围。
    这就像是老板把一个案子交给你，你就要照着写，虽然目的很明确不会产生歧义，但却会产生很多别的问题：
1、你发现这个案子有问题——重写文档
2、你有更好的解决办法——没有用更好的解决办法
3、你被剥夺了思考的权利——没有利用到团队的智慧
4、你没有参与设计的感觉——团队其他成员主观能动性不高

这个事情应用在程序身上也是如此。

总之，不要把别人的事情揽到自己身上，找准自己要做的事情并做好，适当的监督和沟通。一个游戏就出来了。

小游戏还没有什么，如果是大型游戏……你是没有那么多精力去做这样的事情的。
而且，揽的事情越多，出错的几率越大。根据“破窗理论”，一旦某一个错误是因你而出现的，那么更多的错误就会接踵而来，因为跟你共事的程序员有很大几率也把这个错误推到你身上。

PS：“破窗理论”——许多窗户中有一块玻璃是破的，那么这块破窗会诱使更多的人去打碎更多的玻璃。

ymcelqq

把规则\游戏设定详细些,背景,动画,大小\尺寸\容量,声音\搞出来OK\其中数据有些没必要写得这得这么详细,加油,相当讲还是不错的,