舞台代理人

此外，上述規則藉由 scene 樣板事實之 role-number 欄位值來控制 ACLMessage 樣 板事實中有關字串轉換成 token 的數量，進而影響 scene 樣板事實相關的欄位值。 (MyAgent (name ?n))

?m <- (ACLMessage (sender ?n))

=>

圖 50. 舞台代理人的知識基礎元素

基本上，StA 的工作記憶主要放置整個舞台劇本（play，或稱遊戲）的腳本內容與 訊息傳遞的相關資訊，規則基礎則是儲存 StA 進行想法連結的溝通規則，而推理 引擎是控制整個溝通規則的流程，另外，StA 知識庫則儲存一個完整想法連結工作 中，所有場景的設計結果（外部 IE 地圖）與其整個連結過程的訊息流程。

5.3.4.1 工作記憶

StA 的工作記憶由劇本樣板與 ACL 訊息樣板所構成，而這兩種樣版是 StA 在外部 相互作用中，進行想法連結的主要資料。

劇本樣板

劇本樣板的名稱是 play，其主要功能是 StA 根據 DA 所編輯的外部相互作用之腳 本內容，提供 DIM 的代理人進行相互作用的依據。基本上，劇本樣板包括

“play-name”、“user-number”、“user-order”、“scene-number”、“scene-order”、 “time”、

“role-number”和“role-skill” 八個欄位。

所謂 play-name 欄位係指劇本的名稱，而 user-number 欄位是使用者（UA 與 DA）

的數量，user-order 欄位是這些使用者的身分與順序，scene-number 欄位是場景的 數量，scene-order 欄位是所有指定議題的名稱與其順序，time 欄位是不同場景進 行的時間，role-skill 欄位是不同場景所需要 RA 的設計技能，role-number 欄位是 指每一位使用者在不同場景中扮演角色的最大數量。此 play 樣板的語法定義如下：

(deftemplate play (slot paly-name) (slot user-number) (multislot user-order) (slot scene-number) (multislot scenes) (multislot time) (multislot role-skill) (multislot role-number)

)

而在 play 樣板中，這些不同欄位名稱所包含內容的順序，彼此之間有相互對應的 關係。例如：在一個名稱為 cyut-studio 的劇本中，使用者包括 DA（DAlai）與二位 UA（UAtengwen和 UAjesse），而進行外部相互作用的順序為 UAjesse、DAlai、UAtengwen， 而劇本內容主要包括二個指定議題的場景（light 和 circulation），其順序是先 light 而後 circulation。

在 light 場景中，其進行想法連結的時間限制是 20 分鐘，而每一位 UA（包括 DA）

最多只能扮演兩位角色，同時，此場景需有住宅設計（house）之設計技能的 RA。

而在 circulation 場景中，其進行想法連結的時間限制是 30 分鐘，而每一位 UA（包 括 DA）最多只能扮演三位角色，且此場景需要住宅設計之設計技能的 RA。因此，

此劇本的內容可以藉由下列的 play 樣板事實而呈現：

(play (paly-name cyut_studio) (user-number 3) (user-order UAjesse DAlai UAtengwen) (scene-number light circulation) (scene-order light circulation) (time 20 30) (role-skill house house) (role-number 2 3)

)

除了上述的場景樣板外，想法元件樣板也是構成 StA 知識庫的主要資料，另外，

ACL 訊息樣板提供 StA 在外部相互作用與 ScA 和 DA 進行訊息傳遞的相關資料。

有關這些 StA 樣板的機制與語法相同於上述 RA 工作記憶的樣板，其內容詳見 5.3.1 章節。

5.3.4.2 規則基礎

在 DIM 係統中，StA 負責將 DA 編輯的劇本內容傳遞給不同的 ScA，同時，StA 儲存每一個場景進行相互作用的過程，因此，StA 的規則基礎主要以溝通規則為主。

溝通規則

基本上，StA 的溝通規則主要發生在兩個階段，第一階段是 DA 要求 StA 開始進行 外部相互作用，第二階段中則是 DA 要求 StA 將 ScA 產生的想法元件告知所有的 UA。

在 第 一 階 段 規 則 的 LHS 中 ， 是 當 StA 接 收 到 ACLMessage 樣 板 事 實 之 communicative-act 欄位值是 REQUEST，且 play 樣板事實中 scene-number 欄位值 和 user-number 欄位值是某指定之整數值時（如場景的數量是 2，使用者的數量是 2），在此規則的 RHS 中，則宣稱（assert）一個 play 樣板事實和 ACLMessage 樣

板事實。

在此 play 的樣板事實中，主要根據 play 樣板事實的欄位順序，將原先 ACLMessage 樣板事實 content 欄位之字串值轉換成目錄的 tokens，並放置在此事實的相關欄位 中。而在 ACLMessage 樣板事實中，主要將 communicative-act 欄位值與 content 欄 位值分別由“INFORM”和“I will start the play”所取代，同時將此訊息內容回傳給 DA。因此，此階段之規則的語法定義如下：

(defrule request_when_external_interplay_2_2

?m <- (ACLMessage (communicative-act REQUEST_WHEN) (sender ?s) (content ?c) (receiver ?r)) (scene (scene-number 2) (user-number 2))

=>

(assert (play (play-name (nth$ 1 (explode$ ?c))) (user-number (nth$ 2 (explode$ ?c)))

(time (nth$ 3 (explode$ ?c)) (nth$ 4 (explode$ ?c))) (user-order (nth$ 5 (explode$ ?c))(nth$ 6 (explode$ ?c))) (scene-number (nth$ 7 (explode$ ?c)) (nth$ 8 (explode$ ?c))) (scene-order (nth$ 9 (explode$ ?c))(nth$ 10 (explode$ ?c))) (role-skill (nth$ 11 (explode$ ?c))(nth$ 12 (explode$ ?c))) (role-number (nth$ 13 (explode$ ?c))(nth$ 14 (explode$ ?c)))))

(assert (ACLMessage (communicative-act INFORM) (sender ?s) (receiver ?r)) (content “I will start the play”))

(retract ?m) )

在上述的規則中，藉由 play 樣板事實之 scene-number 欄位值和 user-number 欄位值 來控制 ACLMessage 樣板事實中有關字串轉換成 token 的數量，進而影響 play 樣 板事實相關欄位值。在第二階段中，StA 根據 DA 的要求把產生的想法元件傳遞給 所有參與的 UA，此規則的語法定義如下：

(defrule request_ie_users

?m <- (ACLMessage (communicative-act REQUEST) (sender ?s) (content ?c) (receiver ?r))

=>

(assert (ACLMessage (communicative-act INFORM) (sender ?s) (receiver ?r)) (content “?c”))

(retract ?m) )

這些接收規則皆經由之前論述的發送規則將相關訊息傳遞給指定的接收者。最 後，StA 推理引擎中的 Matcher 藉由相關訊息的模式比對方式，決定此 StA 對目前 的工作記憶內容所採取的溝通規則，予以採取適當的行為互動於外部相互作用。

有關上述 DIM 系統代理人的知識基礎之主要程式碼詳見附錄 A。