01 关于游戏中的坑
很多朋友抱怨：“程序员故意挖坑制作死关卡”。其实不然，他无须故意挖坑，因为这个游戏本身就有很多“天然的坑”，如果不使劲填坑，它们自然而然就属于你了。而这里就隐藏了几个可致命的坑：乍一看，待发牌池中所有的图案都可以被3整除那么一定可以通关？那可不一定：
- 只有桌面牌堆中牌的数量和待发牌池牌数一致，所有的牌才能“落地”，而游戏中桌面牌堆到底有多少（层）本身就是个迷。并且如果没猜错的话，在每一局设计者先要确保牌堆形状好看，然后再使堆牌数和待发池的牌数一致。二者哪怕差1个，也会造成死局。
- 上文说了，桌面牌数和待发牌池的牌数一致只是过关的必要而非充分条件。即使该条件满足，如果相对于牌桌上的牌数以及图案数量,窗口牌数太少，也会造成死局。比如下面这个极端的例子：假设游戏共有 15种花色，而牌桌上只有这个模式A牌堆，它有90张牌。那么玩家只要在连续7次拾牌时没有遇到3个相同图案的牌，就“必死无疑”了。
其实这个游戏，一方面要控制关卡的难度，另一方面又要保证能通关本身就是一个相当困难的问题（至少老王没有想出办法）。
而设计者反其道而行之，（可能）没有花力气去设计算法，把坑留给玩家，得到了极低的通关率，反而制造了话题并形成爆款。
如此说来，这确实是个抖机灵的“设计”。但老王认为这种“设计”在游戏策划中是不宜被借鉴的，就像现在市面上泛滥的悬疑剧，开始埋坑无数，吊足观众胃口，最后烂尾不了了之一样，长此以往观众（玩家）对于悬疑剧（游戏）的信任感就被消费殆尽了。
02 洗牌道具的实现
洗牌的实现原理很简单，把当前桌面的牌记录在一个数组tiles中，当需要洗牌时，先打乱一下数组中牌的顺序，然后让桌面上每一张牌到tiles中重新取一个值。再来个眼花缭乱点的动画，还真挺像那么回事儿。
funcshuffle_tiles:
tiles.shuffle
tiles_index = -1
funcredistribute_face-> int:
tiles_index +=1
returntiles[tiles_index]
03 遮罩文件的读取
这里要夸一下Godot Engine，它的很多功能真是方便，比如下面这个str2var它可以简单粗暴地直接把字符串转换成对象类型。
class_nameFileReader
staticfuncread(path,default_data):
vardata = default_data
varfile =File.new
file.open(path,File.READ)
varcontent :String= file.get_as_text
ifnot content.empty:
data = str2var(content)
file.close
returndata04 对象间的通信
这个小游戏中存在大量的对象间的通信需求：牌和牌之间、牌和牌堆之间、牌和关卡之间、牌堆和关卡之间。为了快速实现游戏，我大量使用了Godot Engine的Group机制，不得不说Group是Godot Engine最赞的设计之一。
04 总结
小游戏《羊了个羊》，从策划和开发的角度来看并不困难，然而“瑕疵”竟然能够成为“噱头”，也让人不得不感慨“游戏世界真的一切皆有可能啊”。
来源：游戏葡萄
