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. 既然你一開始就認為這種想法不妥，那么直接無視即可，也請不要浪費那些真正關心這個問題的人的時間，比方說我