恶狼战役

[Shian]

不知道大家有沒有聽過 恶狼战役 這個 project （ code.google.com/p/erlbattle/ )
大概在 2009 年對岸 erlang group 弄的，現在好像沈寂了一段時間
遊戲本身規則很簡單以至於遊戲容易出現絕對的贏家
我想如果遊戲中能加入一些環境的變數，如障礙物、天氣等等，且能多玩家同時參戰應該會更有趣吧
大家有興趣來玩看看嗎

[omusico]

有在關注 棋盤式回合式game 小房間的方式 適合erlang 的通訊方式 類會議室

> --
> 您已訂閱「Google 網上論壇」的「Erlang_Taiwan」群組，因此我們特別傳送這封郵件通知您。
> 如要在網路上查看這項討論，請造訪 https://groups.google.com/d/msg/erlang_taiwan/-/dZ9r5SU7dfEJ。
> 如要在此群組張貼留言，請傳送電子郵件至 erlang...@googlegroups.com。
> 如要取消訂閱此群組，請傳送電子郵件至 erlang_taiwa...@googlegroups.com。
> 如需更多選項，請造訪此群組：http://groups.google.com/group/erlang_taiwan?hl=zh-TW。

[Shian Wu]

這樣會不會太小看 erlang
我的想法是一個類似即時戰略的環境，每個單元是一個獨立的 porcess
每個玩家可以上傳自己的單元，運用 AI 來進行遊戲，甚至可以在不停機下 Hot-swap 自己的單元
這樣才能充分展現 erlang 的能力 XDD

---
Shian Wu

[黃耀賢 (Yau-Hsien Huang)]

你那想法像Cell War呢

Erlang War我有跑過一下，預設範本實在太簡單，攻防動畫時間太長，

看不出可以玩樂到什麼程度。

2012/3/15 Shian Wu <shi...@gmail.com>

--

Best Regards.

--- Y-H. H.

[黃耀賢 (Yau-Hsien Huang)]

Erlang War很像是Final Fantasy太空戰士遊戲晚期的亂數攻擊順序，戰隊成員

每個都有攻擊和移動二種動作可以選，然後做了動作就會有冷卻時間。

戰鬥二方陣營分別提出一組動作序列，二方二組動作序列互相參混合併為獨一的

動作順序。但如何在一系列動作順序中，自己組織出一些pattern構成某種戰術，

例如往前衝一段時間，然後左右閃躲，最後再往前衝擊三次，這一組動作是不是

一個合理的假動作及蓄勢猛攻，其實猜的成份比較大。遊戲感覺像真正的戰場一樣，

很靠經驗。

關於這個小型對戰遊戲，我的抽象觀點是像這樣：

剪刀、石頭、布，二方各自挑選三者之一，拿出來互相比較，就會構成三種情況，

輸、贏、平手。這是很攻守非常均衡的設局。

以Erlang分散計算來講，二個node各自提交一道動作順序給對方，動作順序是同時

而且以單位時間區隔。在前一單位時間收到對方來 "剪刀" 訊息，如果這一單位時間

你放出 "石頭" 可以攻破、放出 "剪刀" 可以抵擋，但是如果在這一單位時間你出

"石頭" 但對方出 "布"，就抵消你 "石頭" 的效果，所以前一時間的 "剪刀" 生效。

而如果這一時間，你出了 "剪刀" 而對方出 "布"，這一時間你的 "剪刀" 擋住了前一時間

對方的 "剪刀"，而這一時間對方出 "布" 得到反效果懲罰在對方身上。

這裡我提的是三種動作：

攻擊：前一時間的動作，對後一時間稱為攻擊。

反擊：後一時間的動作對前一時間稱為反擊。

抵擋：這一時間的動作，對同一時間對方來說，稱為抵擋。

像這樣子把原本的剪刀、石頭、布，以相對順序來解釋，就變成即時的攻防狀態。

有沒有很像網路通訊呢？

2012/3/15 omusico <omu...@gmail.com>

[Shian Wu]

我比較想做成像 Robocode (robocode.sourceforge.net) 這樣的遊戲
規則不用太複雜，應用 erlang 的分散式處理與 hot-swap ，一定很熱鬧
玩家可以隨時上傳更新 robot 的程式碼，即時看到戰場上的變化

---
Shian Wu

[黃耀賢 (Yau-Hsien Huang)]

如果要做，你會從哪裡著手呢？

我稍微想一下，遊戲中一部份程式碼是公平公正的評分機制，而每個人

提交的是自己avatar，avatar中會有一段傷害懲罰評分的程式是鎖定的，

不可讓各人自己修改傷害評分。這裡用像Java的OOP，就有可以配置的語法：

1. 各人avatar都繼承class Avatar，

2. class Avatar規定必須實作攻擊、移動等methods，

3. class Avatar提供受傷害懲罰的method，這種method不得override。

但假如是erlang，我覺得可能是各人的程式檔只包含上述 2. 實作若干methods的部份，

將程式檔提交到erlang平台上，平台接收到程式檔，就把methods hot-swap加進

預先定義好的robot模版。而攻防及傷害評分早已定義在模版中。

然後所謂分散處理嘛，我想可能是指那個英文字concurrency是嗎？

我想得到具體是erlang分散處理的，是平台上有至少二個robots，就是二個

erlang nodes，它們可以同時互相向對方送攻擊訊息，然後看看自己受損情況如何，

是這個意思？

2012/3/16 Shian Wu <shi...@gmail.com>

[黃耀賢 (Yau-Hsien Huang)]

我簡短寫了一段robot碼如下: 一個robot繼承robot的原型, 有 scan/0 (掃描/遠觀敵人),

see/1 (觀察敵人面向何方), go_ahead/0 (前進), stop/0 (停止腳步), head/1 (朝向某方),

punch/0 (攻擊), block/0 (抵擋) 等動作, 以及robot自己位置, 並且可以取得胴體物件

以提供對自己的命令傳送. 然後, 玩家必須寫 tactics/0 代表戰術或策略. 像我寫的策略

是追蹤敵人, 直到靠近時就背刺.

-module(robotA).

%% I inherits [scan/0, see/1, go_ahead/0, stop/0, head/1, punch/0, block/0].

%% I inherits [my_x/0, my_y/0].

%% I inherits [arm/0, leg/0, body/0].

%% I must export [tactics/0].

-export([ tactics/0 ]).

tactics() ->

    case seek_enemy() of

{found, {Enemy,X,Y}} ->

   trace_enemy(Enemy, X, Y)

   , tactics();

no -> ok

    end.

seek_enemy() ->

    case scan() of

[H = {Enemy, X, Y}|_] ->

   {found, H};

[] -> no

    end.

trace_enemy(Enemy, X, Y) ->

    X_off = math:abs( my_x() - X )

, Y_off = math:abs( my_y() - Y )

, if X_off < 1 and Y_off < 1 ->

 engage(Enemy, X, Y);

    X_off > Y_off ->

 head(X);

    X_off =< Y_off ->

 head(Y)

 end

, go_ahead().

engage(Enemy, X, Y) ->

    {head, D} = scee(Enemy)

, X_off = math:abs( my_x() - X )

, Y_off = math:abs( my_y() - Y )

, backstab(Enemy, D).

但寫到這裡就想到遊戲平台下一步的設計問題:

這裡我的程式是以普通的erlang程式順序書寫, 但是, 照理說, 玩家提交程式做為robot

而系統將程式hot-swap起來，是要能將玩家寫的程式拆解成一個又一個的單步動作,

才好做分散並交互處理. 是不是應該要將我的遞迴的 tactics/0 拆開放在 ets 供系統

操作? 或者是拆成適合餵給 lists:foldr/3,4 的單元? 

2012/3/17 黃耀賢 (Yau-Hsien Huang) <g9414002.p...@gmail.com>

[Shian Wu]

當初剛接觸 erlang ，了解到他的兩大特色：process 和 message 時，便認為這對用來寫模擬的程式非常有幫助，那時也就有了這遊戲的想法。

遊戲的核心便是將每個玩家的單位視為一個 process，透過 message 來溝通，目標玩家是像 Robocode 一樣鎖定在程式人員，透過編寫 AI 來進行遊戲。為了方便起見，下面我將玩家的 process 稱作 unit，遊戲中其他非玩家的物件稱為 object 或 obj，遊戲的核心稱為 engine 或 eng。

遊戲規則很簡單，玩家的 unit 在每回合必須計算出要執行的命令，然後交由 eng 來判斷，決定下一回合的狀態。每一回合分成兩個步驟：

一、策略階段。在這個階段 eng 分別將每個 unit 的視野資料（限制每個 unit 只能看到其視野範圍中的 obj/unit）、unit 本身的狀態（死、活、生命點等等）傳給各個 unit，讓各個 unit 開始根據其策略進行計算，產生下一步要執行的命令（移動、攻擊、防禦等等）。

二、執行階段。在這個階段 eng 開始回收各個 unit 的命令，如果 unit 不能即時計算出命令則會被判為 idle。回收完命令後將收到的命令先作一次亂數的洗牌，確保不會有人總是最先執行。洗完牌之後便按次序依遊戲規則執行命令，並將命令結果更新在 eng 中作為下一個回合的開始資料。

如此兩個階段交替執行直到剩下一個 unit 為止。

以這兩個步驟來執行，可以將玩家需要編寫的程式碼簡單成兩個回呼函式： update() , set_command() （這裡的名稱是舉例），玩家只要實做這兩個函式即可，玩家將可以專心在 AI 的編寫上。

我的第一步是為這遊戲想個名字.. XD

想名字是開玩笑的，這個遊戲要成功我覺得最重要的有兩點：

一、公平性：這個公平性指的不是遊戲規則上的公平性而是資源利用的公平性。在進行策略計算時每個 unit 都會運用到系統的資源（CPU, memory, disk），在某種程度上，資源運用的越多相對的可能就越容易獲勝，在遊戲規則中我們限制了每個 unit 的思考時間就是為了這個目的。並且為了不讓資源利用太過浮濫，讓玩家能寫出精要的程式碼，限制其系統資源的使用是有必要的，然而 erlang 本身沒有提供這樣的功能，所以我想只能用監視的方式來處理，當 unit 的資源利用超出限制便將其 kill 掉並於下個回合重新啟動，如果重啟次數過多便宣佈該玩家失格。

二、安全性：因為玩家是程式人員且會跑玩家的程式碼在伺服器上，安全性會是需要考量的重點。因為 erlang 中沒有沙箱機制，遊戲的 eng 必須要能夠辨識＼排除某些 api ，如 os:cmd 的使用，這部份可能在玩家提交程式碼的時候透過掃描程式碼的方式來處理。在 eng 本身也要能夠隱藏重要元件的 pid 避免遭到 DOS 的攻擊；對每一回合的時間控制也要確實，不會讓某些惡意的 unit 拖慢整個的節奏；系統資源也要監視，避免將記憶體或磁碟耗盡導致整個系統無法繼續。

這兩點是我目前研究的方向，比較安全的作法是將 eng 和 unit 各自放在自己的 erlang vm 中，甚至作實體機器上的隔離，僅僅透過 message 來溝通，這對 erlang 來說是小菜一碟，但是對遊戲的節奏可能會有影響。大家可以想想是否有比較好的作法。

---
Shian Wu

[黃耀賢 (Yau-Hsien Huang)]

2012/3/19 Shian Wu <shi...@gmail.com>

當初剛接觸 erlang ，了解到他的兩大特色：process 和 message 時，便認為這對用來寫模擬的程式非常有幫助，那時也就有了這遊戲的想法。

遊戲的核心便是將每個玩家的單位視為一個 process，透過 message 來溝通，目標玩家是像 Robocode 一樣鎖定在程式人員，透過編寫 AI 來進行遊戲。為了方便起見，下面我將玩家的 process 稱作 unit，遊戲中其他非玩家的物件稱為 object 或 obj，遊戲的核心稱為 engine 或 eng。

感謝你談了非常多。我將原文拆解成我理解的重組片段來談：

一、程式者的撰寫範圍

引文如下：

一、策略階段。在這個階段 eng 分別將每個 unit 的視野資料（限制每個 unit 只能看到其視野範圍中的 obj/unit）、unit 本身的狀態（死、活、生命點等等）傳給各個 unit，讓各個 unit 開始根據其策略進行計算，產生下一步要執行的命令（移動、攻擊、防禦等等）。

以及 

一、公平性：這個公平性指的不是遊戲規則上的公平性而是資源利用的公平性。在進行策略計算時每個 unit 都會運用到系統的資源（CPU, memory, disk），在某種程度上，資源運用的越多相對的可能就越容易獲勝，在遊戲規則中我們限制了每個 unit 的思考時間就是為了這個目的。並且為了不讓資源利用太過浮濫，讓玩家能寫出精要的程式碼，限制其系統資源的使用是有必要的，然而 erlang 本身沒有提供這樣的功能，所以我想只能用監視的方式來處理，當 unit 的資源利用超出限制便將其 kill 掉並於下個回合重新啟動，如果重啟次數過多便宣佈該玩家失格。

 

我想到的是之前我所想的追擊。如果unit認出視野中出現對手，程式者該如何撰寫

追擊？想必是馬上陷入一堆很凌亂的點陣地圖程式設計的工作。而如果系統提供了

簡便的動作定義，例如追擊模式可能定為do_it_s_best或death_march，然後實際

怎麼追擊，全丟給系統自己忙，這應該會讓程式者更專心於AI上。不過路線行走

本身也是一種AI的表現，或許也要開放給程式者自己定義路線行走的方式。

相對的，資源如何分配及管控，一方面對應為系統開放了哪些工具組讓程式者使用，

另一方面，具體的資源會虛擬而抽象地對應到遊戲中的環境(含地形或氣候等等)和

unit輔具(含角色能力值或配件等等)，unit加裝高速輔具，即為實際上配置較多CPU

計算量給它。

二、評估效果

引文如下：

二、執行階段。在這個階段 eng 開始回收各個 unit 的命令，如果 unit 不能即時計算出命令則會被判為 idle。回收完命令後將收到的命令先作一次亂數的洗牌，確保不會有人總是最先執行。洗完牌之後便按次序依遊戲規則執行命令，並將命令結果更新在 eng 中作為下一個回合的開始資料。

聽說過戰鬥牌類型的桌上遊戲，由牌的優先順序綜合著出牌的組合，評估得到不同的

結果。

亂數洗命令順序有點突兀。遊戲中一定會定義unit搭載輔具增加了多少能力，而能力強弱

可能對應一些命令順序，eng應該會稍微維護這命令順序的一致。

三、架構

 引文如下：

二、安全性：因為玩家是程式人員且會跑玩家的程式碼在伺服器上，安全性會是需要考量的重點。因為 erlang 中沒有沙箱機制，遊戲的 eng 必須要能夠辨識＼排除某些 api ，如 os:cmd 的使用，這部份可能在玩家提交程式碼的時候透過掃描程式碼的方式來處理。在 eng 本身也要能夠隱藏重要元件的 pid 避免遭到 DOS 的攻擊；對每一回合的時間控制也要確實，不會讓某些惡意的 unit 拖慢整個的節奏；系統資源也要監視，避免將記憶體或磁碟耗盡導致整個系統無法繼續。

我倒不認為如此。既然會跨在網路上，玩家電腦上的Erlang VM也會參與在遊戲中。

伺服器上執行的是包含評分機制的故事演繹引擎，而玩家電腦上執行的則是缺了

評分機制的故事演繹引擎。伺服器負責創作，而客戶端負責演出。

[Shian Wu]

Hi,

我想先從最後一點開始談，一開始我的想法是讓玩家上傳程式碼到伺服器上，由伺服器來執行程式並進行遊戲，並沒有想到讓玩家的電腦連上來，用玩家的電腦來計算策略。雖然 erlang 的特性讓這種分佈式的架構做起來非常簡單，然而就我自己的經驗，erlang 本身考慮的是在一個封閉的區網中，採用的連接方式是 full connected，也沒有考慮防火牆，可能不大適合直接暴露在網際網路上。當然，如果真的要作也不是不可以，可是要花一番功夫，且要玩家自己設定好 erlang 的環境，這也是一個門檻。我想如果遊戲到了一個規模，或許可以往這條路走，伺服器可以開放一些接口讓玩家在自己的電腦上運算策略，想想看到時如果 IBM 的深藍挑戰 Google 的伺服器叢集是多麼有趣的事 XD

其他我文中提到遊戲規則的部份只是簡單舉個例，至於有哪些命令，要怎麼排列攻擊順序都開放大家討論，也許耀賢可以先將想法寫出來讓大家參考。我是覺得不要太複雜，不然 AI 很難寫 XD

昨天我剛搞定用 nitrogen 的 comet 機制來讓網頁中的物件動起來，前端我是用 processing.js 這套函式庫來繪圖。等我有時間弄個 demo ，大家就會比較清楚整個遊戲要怎麼玩。

---
Shian Wu