推 AmosYang:這篇文章 1.值得推薦 02/16 08:11
推 biowave:推 02/16 12:36
推 yuxio:非常棒的一篇文章，受益良多 04/17 11:53
※ 引述《zxcmoney (lol)》之銘言：
: >可能用到的函式
: 自然改革時間(NreformT(a,b,c))
: a為改革力的增減 b為改革進度 c為改革成本
: 回傳自然改革所需時間
: 加速改革(VreformT(a,b,c,d))
: a為改革力的增減 b為加速改革次數
: c為改革進度 d為改革成本
: 回傳加速改革能縮減的日數
: …嗯 可能用到的非常多
: 我看還是看過資料結構 寫好函式再寄給你好了
: 建成的函式會附上如上的說明
: 此外這部份看要不要開放有意願的編寫
其實我想最最基本的問題是, 論遊戲開發, 永遠是求諸人不如求諸己.
如果自己不寫的話, 那任何的提案或者企劃, 都不可能超越紙上的. 主
要問題在於, 每人心目中都有自己理想的「遊戲」或者「系統」, 沒有
人理想中的遊戲是完全一樣, 能夠實現自己理想中的系統的, 哪怕只是
部份也好, 基本上也只有自己一個人會去完成.
而人會願意自己完成的, 就只有自己的那一套系統.
在用別人的系統時, 那往往不會是 100% 合乎自己所想的, 但是如果能
有 70% 以上合乎自己的想法, 大部份人就會接受了. 畢竟這是使用者
的接受範圍, 但開發者的接受範圍的話, 如果是免費的人力, 那是十分
狹窄的, 這是我常說同人遊戲開發中, 「免費的人力比起受薪的人力更
昂貴」的原因.
如果要將一件工作交予別人, 那麼不論那是甚麼工作, 也等於將那件東
西的設計的權利, 也交予了對方. 這才有可能交予別人, 自己設計東西
然後讓別人實現, 一般來說只有給錢才可能做得到.
所以如果要設計一個系統出來, 最好是自己去實現它, 這是我說為何要
寫(即程式碼)出來的原因. 主要是, 如果自己不寫的話, 那會停留在設
計階級然後流產的可能性是很大... 在這個 GameDesign 版, 之前也有
不少人說過一個重要的問題, 就是其實最難的事情, 就是「開始然後完
成」, 半途而廢是遊戲設計最常出現的問題. 這往往是因為我們都會喜
歡做一些自己有興趣的部份 (例如企劃) , 避開自己不感興趣的部份 (
例如除錯) , 但大家有興趣的部份其實往往相同, 不喜歡的部份也往往
相同, 要完成遊戲和開發遊戲, 只能在做自己喜歡的部份時, 也去做自
己不喜歡的部份.
除了寫之外, 寫本身也包括了自己測試的過程, 像人工智能這種東西,
推理時往往和實際執行時有落差, 如果不去寫 code , 應該是沒有機會
證實一個人工智能是否可行或者有破綻.
所以這其實是避不過的.
所以我十分鼓勵你去實現他, 我願意開放我的 source code 給你, 我
的人工智能其實大部份都放在了幾個大的 procedure 裡, 有些會細碎
, 雖不能說容易修改, 但是直接改下去應該最方便.
: >現在可能需要更動程式的地方
: 我不知道你現在設計的ai行動到底怎麼運作的
: 不過要讓玩家來修改的話 我想應該會需要改成這種方式
: 1.輪到此ai行動
: 2.讀取ai行動決策樹
: 3.將行動內容存入行動陣列
: 4.扣除行動陣列所用的行動力
: 5.重複2-4直到行動0
: 6.實行行動陣列內容
: 7.回合結束
: 其中ai的行動決策是開放玩家編寫的部份
: 雖然決策的方向與行動大至分成
: "改革"
: 方向:依現在 或 預定達成的情況 決定改革方向
: 行動:決定推動改革 決定加速改革
: "建設"
: 方向:依照現行體制 改革方向 軍事狀況 外交狀況 決定建設行動
: 行動:建設建築 開發 投資
: "外交"
: 方向:依照現行體制 改革方向 軍事狀況 建設狀況 外交狀況 未來目標 決定外交行動
: 行動:朝貢 宣戰 請求資援
: "軍事"
: 方向:照現行體制 改革方向 軍事狀況 外交狀況 未來目標 決定軍事行動
: 行動:整備 訓練 強化 轉職 解散
: 但依狀況不同決策樹的各方向的子決策樹優先權也不同
: 基本上這是受ap制的影響 使各方向的行動的互相影響其次數
: 如果是獨立出來的話 這些決策樹可以分開
: 觀察其他的決策樹的決策 然後獨立運作
: >其他
: 開放玩家編寫的話可能會有不合設定的行動出現
: 例:
: 對戰力低的國家進攻5次(0+1+2+3+4)總計10AP
: 或TP不足的國家仍可以建設.補給或強化部隊
: 為了避免玩家設計的ai行動出現這種錯誤
我想最基本的問題是截取資訊本身, 人工智能要實現, 基本上以上
含糊的部份都必須要精準的變成實際的算法.
比方說, 「軍力強過對方就攻擊」, 這是看起來簡單, 實現卻很複
雜的, 因為這包括了一個重要的問題, 就是「電腦怎樣判斷自己軍
力的強弱」, 判斷本身就已經是一個人工智能了.
舉例, 以我目前的 source code, 部隊有一個 function 叫
battlevalue , 用途就是為每個部隊定一個戰力指數, 方便部隊判
斷是強是弱.
function TUnit.BattleValue(seed : Integer) : Integer;
var i : Integer;
begin
// 1 general 綜合戰力指數
// 2 front 前排戰力指數
// 3 back 後排戰力指數
if (seed = 1) then
begin
i := MaxHP;
end else
begin
i := Strength;
i := i div 2 + (i * Morale div MaxMorale) div 2;
end;
if (seed < 2) then
begin
i := i * (BS + WS) div 6;
end else
begin
if (seed = 2) then i := i * (WS * 2 + BS) div 9;
if (seed = 3) then i := i * (WS + BS * 2) div 9;
end;
BattleValue := i;
end;
大概你可以從數值的名稱, 看出那代表是甚麼, 這是目前對戰
力判斷的形式. 但這十分的陽春, 自然會產生缺憾, 例如把戰
力較弱的部隊看成是戰力較強的部隊, 或者低估了實力, 這就
是人工智能真正麻煩的地方, 而這種麻煩是寫成了程式碼後才
能夠發覺出來的.
而這種算式本身就是人工智能重要的一部份, 可以說, 如果電
腦要進行任何判斷, 至少先要有判斷部隊強弱的能力. 如果欠
缺了這種能力, 任何對戰力的判斷的人工智能都不會有意義,
無法成立, 因為欠缺了最重要的「源頭資訊」, 「可比較的資
訊」.
這些工具是最重要的, 能否準確的判斷部隊的強弱, 對戰略和
戰術智能的影響十分大. 因為根據誤判之下作出的決定, 無論
過程是否複雜或者合理, 結果一定會是錯誤的. 這是工程上常
說的一個問題, Garbage in, garbage out, 進去的資訊品質
不高的話, 根據那資訊進行的決定也不會好.
那就是說, 如果你要設計人工智能, 就必須要動到函數的內容
和運作, 而不能單純的依賴遊戲裡提供給你的函數. 而如果你
不動這些相關函數, 你幾乎是無法開發出任何可用的人工智能
, 但這些東西如果要用編輯器放出來, 如我之前所說, 這等同
「設計一個程式語言和編譯器」.
因為這和其他 custom 的部份不一樣, 其他 custom 的部份,
你改的是「參數」, 參數只是一種「資料」.
但人工智能不能只看成一種「資料」, 人工智能是「邏輯」,
你要向電腦輸入資料, 讓它應用是容易的, 但你要讓電腦理解
一個邏輯, 寫程式, 已經是最快, 最方便, 最有可能達到的方
法, 不可能捨近求遠.
: 在實行行動陣列內容要作好判斷並在出錯時回報玩家
這本身就是人工智能.
問題就是為了開放讓玩家做人工智能, 本身就已經需要很多人工智能.
事實上, 要判斷一個人工智能的錯誤, 需要的是比那個人工智能更優越
的人工智能.
這就像你寫一個象棋的人工智能, 和寫一個「能找出你的人工智能的錯
誤的人工智能」, 後者其實比前者還要複雜.
這是我說這為甚麼是人力黑洞的原因, 你想想, koei 的三國志威力加
強版, 也不可能去到讓你修人工智能的地步, 這不是興趣的問題, 是成
本和效果的問題.
程式語言本身就是最好的「人工智能編輯器」, 要修人工智能, 最好是
直接修 source code.
把遊戲實現是最重要的第一要務, 合理地運用自己手頭上能用的所有資
源去完成它, 將效益發揮至最大. 不奢望有任何目前沒有的資源會突然
出現, 這點是遊戲設計中很重要的, 不論是商業遊戲還是同人遊戲都一
樣, 如果我們的設計中要有一些目前不存在的資源(例如人力)才能夠完
成的, 那個設計是一定不能完成的, 因為目前不存在的資源, 未來九成
也是不存在的.
只要你能寫程式, 不要浪費這技能, 這就是資源. 好好利用他.
--
基於飲水思源的理念, 還是該打的廣告,
hkday.net --- 碩果僅存還願意和其他地區轉信的香港 BBS
--
※ 編輯: chenglap 來自: 218.252.90.21 (02/15 23:40)