有点不一样的自走棋

前几篇讲系统和行为，这一篇讲棋子本身：怎么排出来、定稿后又改了什么。只写思路，不代表实现进度。
100个岗位，不是 100 个点子 第一版配置表的第一列不是名字，是「编号／用途」。用途代号就是岗位说明书，分组也按构筑方向排：组内棋子天然互相认得，所以不是孤立点子，是几条构筑方向上的零件。名字是后来才整批补的；造型定稿后又改过一轮，名字跟着最终轮廓走。
图标列不是美术备注，而是设计的一部分——体型表

1. 一开始是围绕玩法想机制的
顺着玩法去找机制是最自然的做法。 于是手上一堆点子。附身、叠加、眩晕、中毒、激励、魅惑、混乱、拉拽、交换……每一条都能单独讲通，甚至能写成配方。配方本身没问题。问题在别的地方：它们彼此孤立。一条点子只回答"这个能力怎么执行"，不回答"它和谁组合、组合之后长什么样、什么时候消失、归谁清理"。
2. 于是反过来思考先设计联动，再拆分细节
先回答"谁和谁要互相认得"，再回

上一篇减的是系统，这一篇减的是代码结构。行为系统原来是一个机制一个类，现在拆成动词、词条、行为、棋子四层。下面记的是这次怎么拆的，以及有序行为列表、Buff 即行为、连击独立判定、涌现式组合、行为预演这几件事是怎么保下来的。
删掉的和换掉的 端游那套行为是用类继承堆起来的：一个攻击基类，派生出普攻、突进、横扫，特殊棋子再各挂一套脚本。机制一多就出问题——每加一个"攻击之后再做点什么"，就得新开一个

开发者日志：从端游半自走棋到手游——围绕"涌现"的减法与重构
本日志记录本项目从已有的端游半自走棋原型（Chess 项目）迁移到手机端时，围绕"涌现（Emergence）"这一主题所做的设计决策、删减清单与大幅修改内容。
1. 立项思路：从"涌现"出发
关于"涌现"这个主题，最直接的想法是涌现新的机制——独立的个体上没有这个机制，只有当多个个体组合在一起时，才会涌现出个体所不具备的新能力。顺着这个