1. 此文目的：
吾希望深入讨论一下队列操作，及其在sc2中的可能改进....此文甚长，请耐心阅读....
2. 一些定义：
2.1. 序列操作SO指的是在选定一个或多个单元的前提下，先按住shift键，继而再进行一系列后继操作（如技能释放、移动M、坚守阵地H、和攻击前进A等）的过程。序列操作的对象既可以针对一个作战单元，也可以针对多个同类作战单元。一次序列操作将形成一个连续的操作队列。其对象将依次执行队列中的操作，直到队列为空。
2.2. 冷却时间CD。假设魔法值足够，某技能连续释放两次时，其间必须等待的一段释放不能的时间。
2.3. 吟唱时间CH。技能发动之后，在彻底生效之前所必须经历的准备时间；在吟唱过程中，技能可以中途取消而不费蓝。吟唱这一设计并不存在于sc1，作为一种复杂的非标准RTS行为，其更适合兵种数量少、对抗强度低的RTS游戏，或ACT-RPG动作游戏，如wc3和wow，而不太适合快节奏的sc2，所以本文不考虑这一因素的影响，并假设其在sc2中不存在。
3. 支持现状：
sc中只提供有限支持。wc3中支持较为全面，但还有进一步提高余地。
4. 典型示例：
序列操作的用途并不仅限于于如下方面，以下示例均假设sc已具备了完善的序列操作支持。
4.1. 一次性指定一系列临时性的连续操作，从而提高效率；如P农民先造建筑再采矿；如把坦克开到一个指定地点再展开
4.2. 一次性指定长期性的计划性连续操作，从而改善操作，如P按照某复杂路线的巡逻，如雷车在多个预定地域连续布雷
4.3. 以有限数量的单元对突发事件进行快速连续响应，如用一个电兵，以CD为0的闪电技能+序列操作，依次电一大片范围
4.4. 一次性指定某些重复性过强/需要频繁照料的操作，如运输机运兵渡河，反复地装载、卸载。
5. 序列操作优点：
5.1. 简化局部操作，缩短操作延迟
5.2. 减少不必要的单元重复选取、单元状态轮询，减少冗余的微操作
5.3. 使得玩家思路的连贯性能够体现在操作的连贯性上
5.4. 充分发掘高级玩家对局势的预测能力
5.5. 充分发掘高级玩家对时间的把握能力
5.6. 加大水平不等玩家之间的操作效率差异，拉开两者水平差距
5.7. 优化某些技能的应用效率，如自动化的大规模空运渡河
5.8. 进一步改善sc2中的战术要素，或者是在序列操作基础上，进一步提出更有趣的技能设计
6. sc序列操作存在的问题：
sc1可以说是对序列操作支持不加，一来操作队列过短，二来其技能操作不能很好与移动等普通操作结合使用，这使得在sc1中，序列操作的优越性没有得到充分体现，比方说不能雷车顺序布雷，闪电兵不能顺序闪电，运输机不能自动装载、移动、卸载等等
7. wc3序列操作存在的问题及其解决方案：
7.1. wc3序列操作的一般规则
WC3的操作队列中，技能操作与移动等普通操作是可以共存的，即，你可以“计划性的预先释放技能”，只要在真正释放技能的那一刻，单元的魔法值和CD容许，那么其操作便会成功，而如果当其操作需要被执行时，单元的状态不满足其技能释放的要求，那么当前操作将被cancel，单元继而去执行操作队列中的下一操作。
7.2. 第一个问题：cooldown对队列中预定释放技能的不利影响
考虑火焰王子场合，假设其魔法足够，指定如下序列操作（连续火焰烧）：按shift+F+F+多次右键点不同的地方，连续两次释放火焰技能，且烧的是不同的地方，然而在顺序移动到其他地方去。这两个挨烧的地方既可以相距很远，也可以很近。上述旨在实现两次火焰释放、然后再马上逃跑的序列操作是达不到目的的，原因在于，在第一成功释放火焰之后，由于CD的存在，导致第二次连续的火焰不能立即释放，因此在烧完第一把火后，第二次技能操作被直接cancel，王子直接开始执行后继的序列移动操作。上例表明：WC3中，对序列操作中连续技能释放的CD因素考虑不充分，或者说不够人性化。
根据上例，现在的问题是：难道我们就不能选择另一种处理方式么？其时序如下：
释放第一把火==>移动至下一技能释放的预备位置==>在移动过程中，嘿，CD恢复了，或者是，如果到达预备位置之后CD还没有恢复，则在原地等待其恢复==>成功释放第二把火==>继续后继序列移动
上述时序涉及到了两个改进，首先，移动到预备位置和CD恢复的时序优化，总不能放完第一把火，然后原地等待cd恢复，再开始移动到下一释放位置吧，如此甚低效。与此类似的还有sc1所谓的移动加速问题，导致序列移动速度很慢。这只是个别的具体例子，想说明的问题就是，BLZ应该尽可能优化队列中前后序列操作的衔接，令其更高效。其二，当在序列操作中指定耗蓝的魔法操作时候，类似CD恢复的情况同样也出现，因为头一次魔法释放有可能使得第二次释放的魔法不足。吾觉得，可以从操作上来反映二者差异，比方说，我按住shift+F，表明这个预期操作如果实施条件不足，可以cancel；但如果我按的是 shift+ctrl+F，这表明，无论如何，我都希望这个操作成功完成，我宁可等待其条件满足，比方说等待其CD恢复或魔法恢复等，除非实在是没有办法完成。
当然，上述讨论是基于技能释放的，而技能释放可以以等待方式处理的前提在于：其可释放状态的恢复是可以确定且可以预期的。然而，对于移动等其他操作而言，在某些情况下，我们却也许只能选择Cancel：比方说，你指定某农民预期移动到某处，但后来有人在那里造了个房子，让你不可能移动到预期位置，由于不能在确定的时间内预计到该房子被拆，因此在这种情况下，其队列中的当前移动操作要么只能解释成为"尽可能移动到离预期位置最近的大致地方"、要么就只能被取消，而绝不能等待，否则，你的农民将无限期等待下去。
7.3. 第二个问题：单元技能释放状态设计的不合理
随便举个例子，运输机运英雄。情况1：买个飞艇，两个英雄，选飞艇，按L键，点到英雄A身上，欲装载之，然后飞艇朝英雄A飞去，此时我按着shift想提前设定卸载地点，但因为此时飞艇空载，这个卸载的U按钮居然都没有显示......根本没法预先设置卸载地点，序列化操作根本指定不能，彻底失败。情况 2：再试试，这次吾先装一个英雄A，然后按shift不放，U一处，在飞行过程中L另一个英雄B，再U另一处，结果按慢了，在正准备第二次U时，第1个英雄已经被卸载了，结果又是按'U"不能.....一次思路连贯的序列化操作被打断.......吾xxxxx......
以上只是个具体的例子。要说明的问题就是：BLZ对技能状态与序列操作之间交互性的考虑不足。其实，在上述例子中，序列化操作指定是完全合理的，也就是说，在序列化操作过程中，指定空载的运输机在某特定地点卸载，这种操作是完全合理的，而且也不会造成什么不利影响，大不了飞到那地方停一下，发觉没啥可卸的，继而往另一个地方飞就是了。在卸载按钮的显示方面，BLZ只需判断一下就是了：当shift被按下时，无论空载与否，卸载按钮都显式，当shift没有被按下时，只有飞机里有人，按钮才显示。
以上只是些具体的例子，也许还可以找到更多例子，欢迎大家讨论补充。吾开此贴的目的在于：
a. 发现更多的已有的不合理序列操作
b. 提出有针对性的改进设计，以使得这种前置性的操作方式功能更强大，更有趣
c. 探讨利用这种增强了的序列操作，进而设计更有趣的技能的可能性，大家有什么新鲜想法，都可以提出。
最后值得指出的是，至于这种序列操作是否有必要存在，该问题在此贴中请大家不要讨论了，并非拒绝反对意见，而是因为：
a. 序列操作主要面向高级玩家，也许你用不到，自然不关心，但这并不意味着它不能提高别人的操作效率
b. 其涉及个人习惯，你属于反应型的抽筋选手，而非工于算计的腹黑型选手，习惯不了，自然不待见，我也能理解
c. 既然你一开始就认为这种想法不妥，那么直接无视即可，也请不要浪费那些真正关心这个问题的人的时间，比方说我
……