單人遊戲

圖21、規劃階段

遊戲共分為四個階段：規劃、使用者設計、建構與交付階段，規劃階段是遊 戲的第一階段(如圖 21 所示)，主要是建立系統的基礎，首先玩家在規劃階段開 始時抽滿五張牌，抽滿後接著從計畫牌組中抽取一張計畫卡，並選擇是否放置在 檯面上，選擇完後最後丟棄不需要的手牌結束這回合。在規劃階段裡桌面上放置 計畫卡的多寡決定玩家往後可使用區域的大小，放置在場上計畫卡的種類也會影 響往後遭遇的事件與運用方法卡的條件，如果拿到較好的計畫卡可以取代較差的

手上的卡片皆無法使用，但玩家仍然可以在回合結束時丟棄不需要的卡片，當玩 家在桌面上放置適當數量的計畫卡時，就可以選擇進行下一個階段。

圖22、使用者設計階段-1

使用者設計階段即是需求階段，在此回合開始玩家必頇補滿上回合丟棄的卡 片數量，補滿手上的牌後，接著玩家必頇從需求牌組抽取需求卡(如圖 22 所示)，

如果需求卡是不容易達成的，則玩家可以選擇放棄這張需求卡，直到在下一個回 合再次重複上述流程。

圖 23、使用者設計階段-2

當玩家於下一個回合時首先補滿手中的牌，接著再次抽取需求卡，這回合抽 取的需求卡如果玩家認為卡片上所需求的程式碼長度是合理且可以達成的，則將 需求卡放置在檯面上的需求區域中(如圖 23 所示)，代表玩家答應了使用者的要 求，在此回合手上的牌同樣是無法使用的，但可以丟棄不要的手牌，當玩家丟棄 完手牌後，接下來就可以進入建構階段。

圖 24、建構階段-1

當玩家選定需求之後就可以進入建構階段，建構階段代表的是玩家根據系統 使用者的需求來做建構的動作，在此階段玩家必頇根據需求卡上的需求，運用手 中卡片來完成該需求卡的程式碼長度，此階段的步驟較前面的不同，當補滿手牌 之後則進入抽取事件卡階段(如圖24所示)，在此步驟玩家必頇從事件牌組抽取一 張事件卡，事件卡的條件不符合時則進入放置的步驟。

圖 25、建構階段-2

在放置的步驟玩家可以根據先前計畫卡所放置的多寡決定可利用的區域(如 圖25所示)，每張計畫卡上皆可以放置員工卡或方法卡，每回合限定只能放置一 張員工卡與方法卡，放置員工卡的時候需要注意專案卡所提供的預算金額，如果 預算不足時無法放置卡片，放置的該回合該名員工是無法進行工作的，但該回合 放置的方法卡如果滿足條件時可以立即發揮作用，如果計畫卡上已放滿卡片時，

可以用取代的方法來置換，當然在置換的該回合該名員工同樣也是無法工作的。

圖 26、建構階段-3

在放置完後則進入工作步驟，在此步驟玩家則可以令檯面上可以行動的員工 進行工作，員工可以進行四種工作：正常的建構系統、快速的建構系統、檢查系 統錯誤與修正錯誤，而員工工作的效率則是以卡片上的員工技能為主，玩家可以 根據員工所擁有的技能值選擇各種行動。員工進行正常建構系統時，依照員工卡 上欲建構的值抽取一般的程式碼牌組相應數量的程式碼卡片放置於場上，放置在 場上的程式碼卡是以覆蓋的方式放置(如圖 26 所示)，選擇快速建構系統時，則 是依照玩家欲建構的值從困難的程式碼牌組抽取相應數量兩倍的程式碼卡片覆 蓋在場上，玩家在建構後並無法查覺程式碼卡中有沒有錯誤，必頇運用員工卡的 檢查動作才可以進行程式碼檢查的工作，當玩家選擇檢查程式碼卡時，可以依照 玩家欲檢察的值從程式碼卡最底部開始翻開相應數值的程式碼卡，玩家可以透過 檢查的動作來了解程式碼之中是否有錯誤，當玩家發現錯誤時，則必頇運用員工 的修正技能來做程式碼的修正，程式碼的修正也因為程式碼錯誤的程度有所不

檢查後發現是簡單的錯誤時，玩家進行修正時則必頇消耗一點技能點數來進行修 正，修正後的簡單錯誤卡則從場上移除；當玩家遇到的是一般錯誤的程式碼卡，

玩家進行修正的方式首先必頇要耗費技能點數將一般的錯誤移至程式碼卡中的 最上層，每往上移動一次必頇消費一點的技能點數，直到一般錯誤卡片到達程式 碼卡的最上層，才能利用一點的技能點數來將之移除；當玩家檢查時發現嚴重的 錯誤時，修正也較其他兩種錯誤嚴重，玩家選擇修正嚴重錯誤時，首先玩家必頇 消耗技能點數移除嚴重錯誤卡上面所有的卡片，舉例來說：如果在一般錯誤卡上 面有六張程式碼卡時，玩家必頇消耗六點技能點數才將一般錯誤卡移動至程式碼 卡的最上方，最後才將之移除，過程中其他的程式碼卡並不會有所損失，但如果 嚴重錯誤卡上面的程式碼卡有六張時，玩家則必頇消耗六點技能點數將此六張移 除後，才能移除嚴重錯誤卡，玩家修正錯誤的順序是由程式碼卡最上方的錯誤依 序往下開始修正。

當玩家在建構系統時抽取的事件卡符合條件時，則必頇接受事件卡所造成的 影響，事件卡影響的條件會根據場上計畫卡的種類與在場上所雇用的員工，如果 在規劃階段時已經進行妥善的規劃，則不需要擔心事件卡會對遊戲過程造成阻 礙，如圖27所示，如果事件卡的條件符合，則必頇移除掉計畫卡上的卡片，事件 卡的影響都是立即的，在建構階段的每回合都必頇接受事件卡的考驗，當事件卡 的影響完成後，就可以進行接下來的步驟。

圖28、建構階段-5

當玩家所建構的程式碼長度達成需求卡的要求時，則可以選擇完成工作重新 回到上一階段接受下一個需求(如圖28所示)，然後再次進入建構階段，當玩家再 次進入建構階段時，無頇移除先前已放置在場上的卡，但如果玩家抽到更好的卡 片時，也可以選擇替換場上的牌，玩家必頇接受的需求數量取決於專案中的使用 者數目，直到玩家必頇完成專案卡上使用者需求的數目，才可以選擇進入到整合 階段。

圖 29、整合階段

整合階段主要是將所有使用者的需求進行整合成一個系統，是交付階段的前 製程序。當玩家進入整合階段時，即已進行到遊戲的後半段，首先玩家必頇先選 擇一名進行整合的員工，然後將原先需求卡所要求的程式碼卡依序放置在選定的 員工上，玩家在此階段可以選擇讓員工進行檢查及修正錯誤的動作(如圖29所 示)，但在此階段時，玩家無法再次更動檯面上的員工與方法卡，同樣事件卡也 不會影響玩家，員工在此階段進行的檢查動作如同建構階段，依照相應的數值翻 開未檢查的程式碼卡，而在整合階段時的修正也與建構階段時有所不同；在建構 階段時發現簡單錯誤後，需消耗一點技能點移除錯誤的程式碼卡，而在整合階段 時，發現簡單錯誤時則僅需要消耗一點技能點將錯誤的程式碼卡進行修正，修正 後將錯誤的程式碼卡置換成沒有錯誤的程式碼卡；若在建構階段發現一般錯誤 時，玩家必頇消耗技能點數將錯誤的程式碼卡移動至最上方，最後進行移除，若

作，修正後將錯誤的程式碼卡置換成沒有錯誤的程式碼卡。如果在建構階段發現 嚴重錯誤卡時，玩家需消耗技能點數將嚴重錯誤卡上方的卡片依序移除，直到嚴 重錯誤卡位於程式碼卡的最上方時才能將之移除。如果在整合階段發現嚴重錯誤 卡時並不需要移除上方的程式碼卡，但玩家需要消耗嚴重錯誤卡上方程式碼卡數 量同等的回合數才能將之移除，所以在整合階段發現嚴重錯誤時，修正比在建構 階段時候更困難。除了檢查與修正，玩家同樣也可以選擇不做檢查與修正的動作 立即進入移交階段。

圖30、移交階段

等玩家認為準備妥當的時候，就可以進入移交階段。到移交階段時，玩家先 將原先在檯面上的程式碼卡做洗牌的動作，洗完牌之後依照專案上面要求的品質 數依序抽取程式碼卡上方同樣數量的程式碼卡，如果抽取的程式碼卡中沒有任何 錯誤，則判定玩家獲勝，若發現錯誤時，則依照錯誤的大小懲罰；如果發現嚴重 的錯誤時則玩家宣告遊戲失敗；如果發現一般性的錯誤(如圖30所示)，則玩家達

簡單的錯誤則玩家必頇退回到整合階段進行修正錯誤的工作，直到玩家完成錯誤 的修正以後再嘗詴進行移交階段。