淺談人工智慧 (轉)
淺談人工智慧 (轉)[@more@] 在去年十二月的雜誌中,筆者曾經就遊戲的人工智慧和各位探討過一些人工智慧的設計問題,沒有想到在雜誌
出刊的幾天後,就從網路上接到幾位讀者詢問這些問題的信件,因此趁著大家對前一篇文章的記憶還深的情況
下,我們就再來看看關於人工智慧的設計方式。
網路上的網友問到,到底在設計人工智慧的時候,是如何來決定出每一行判斷式的重要性。其實筆者可以很輕
松的告訴各位,在設計人工智慧的時候,先想想自己是如何去思考的,然後就依自己認為的重要程度來劃分每
一行判斷式的重要性。這種設計方法的優點就是會相當的「人性化」,設計者很容易就可以在遊戲中看到
以自己的思考方式去進行各項行動,但是相對的缺點就是若是設計者的本事很差,那麼人工智慧所表現出來的
一定也會很差,因為這樣子的人工智慧完全會反映出設計者的思路。由於這種設計方式所表現出來的是設計者
的思路,因此在一些國外的西洋棋遊戲中,設計公司經常會和某些高段的棋手配合,讓他們來提出各項的建議
,使整個遊戲的人工智慧更加精確,這就是為什麼他們會這樣做的原因。
但是現在問題又來了,西洋棋遊戲可以這樣作,戰略遊戲怎麼辦呢?有那一個人是真正的戰略天才呢?因此筆
者在這裡提出一種比較法讓各位能夠了解設計時會碰到的問題。我們就以戰略遊戲為例好了,也就是目前市面
上最流行的所謂RSLG。在遊戲中,當一名電腦控制的角色要行動的時候,它需要考慮以下的幾件事情:
1. 行動範圍內有沒有可以到的敵人。
2. 移動到地理位置較好的地方。
3. 生命是不是已經低到會死的地步。
4. 本身是不是擁有什麼特殊的能力可以使用。
以上是筆者粗略的將可能會發生的情況歸類成四項,現在我們就一項一項的來看看。首先是第一項的行動後可
以攻擊到敵人,光是這一個情況我們就必需要做比較仔細的推算,像是不是隻有一名可以攻擊到的敵人?若是
不只有一名可以攻擊到的敵人時,要怎麼挑選攻擊的目標?以及這樣的攻擊是不是可以將敵人擊斃?是不是要
以可以在這一次就擊斃的敵人為目標?以及在這一次攻擊之後是不是會在下一個回合就遭到敵人的回擊等等。
如果先將這些情況加以判斷,那麼可能會歸類出以下的幾條判斷式:
A. 若是隻有一名可以攻擊到的敵人,那麼目標就是它。
B. 若是有數名可以攻擊到的敵人,那麼選擇最弱的一名。
C. 若是有可以在攻擊後擊斃的敵人,那麼它會是目標。
D. 在攻擊後在多少名敵人的攻擊範圍內。
還記得十二月的文章中筆者曾經提過條列式以及積點式兩種人工智慧的設計方式嗎?現在我們就以這兩種方法
來看看關於這一部份的判斷式重要性。以筆者主攻的眼光來看,若是有一名敵人可以被擊斃,那麼這名敵人一
定是最重要的目標,接下來才是攻擊最弱的敵人,接下來是可以攻擊到的敵人,最後才去判斷會進入多少敵人
的攻擊範圍內。因此這四條判斷式若是以條列式的判斷法來排序的話,將會是以下的情況:
C > B > A > D
在這樣子的設計下,這些由人工智慧所控制的角色將會展現出相當強悍的主攻個性,就算是這一次的攻擊後可
能會遭到敵方的圍攻也毫不在乎。若是各位讀者覺得自己並不喜歡由人工智慧控制的角色會這樣子行動,希望
它們能夠適當的避開一些會遭到敵人圍攻的情況,那麼判斷式的排列順序可能會變成:
C > B > D > A
在這樣的情況下由人工控制的角色不會一看到有可以攻擊到的敵人時,就會像瘋狗似的追著打,而會考慮一下
這樣子的行動會不會就遭到敵人的圍攻。但是當有敵人會被擊斃,或是生命相當低的時候,就會不考慮那麼多
了。如果各位讀者覺得這樣子還是不好,那麼也可以將判斷式的排列順序改成如下:
D > C > B > A
在這樣的情況下,由人工智慧控制的角色將會相當的小心,就算是可以將敵人擊斃,但是若在下一回合有被其
餘的敵人圍攻的可能,就不會發動攻擊。
接下來我們看看以積點式來設計的話,會是什麼樣子。同樣的判斷式用積點式來設計的話,就必需要給每一行
算式不同的積點,但是同時必需要將算式做一點修正,因為在積點式中會有複數計算的情況發生,因此這些判
斷式會變成:
A. 可以攻擊到一名敵人的位置。
B. 可以攻擊到的敵人中最弱一名的位置。
C. 攻擊時可以擊斃敵人的位置。
D. 一名敵人的攻擊範圍內。
各位讀者可以看到,其中的第四條就是可能會複數計算的。在程式進行判斷的時候,這一條可能會因為有多個
敵人角色都合乎這個條件,而導致積點的重複計算,因此若是重複計算的次數夠多了之後,反而可以將原本一
些有利的情況抵消。以前面的這四條算式來舉例,若是A的積點是+2、B的積點是+4、C的積點是+8、
D的積點是 1,那麼當一個地點雖然可以將一名敵人擊斃但是又會被五名敵人圍攻的話,那麼這個地點的重
要性就會低於一個生命力較低的敵人的位置。也由於積點式的計算方式比較精密,因此人工智慧所控制的角色
就不會那麼的死板,而會顯得比較聰明。雖然條列式的作法可以用增加判斷式的辦法來達到相同的目的,但是
比較起來就是差了些。
由以上的這個例子中,我們可以看到不論是一種人工智慧的設計方式,整個人工智慧的表現都是控制在設計者
的手上。條列式表現在判斷式的排冽順序,而積點式表現在積點數的不同,這些都是人工智慧有「人性」的地
方。
網路上有網友問到,像筆者在十二月號中拿賓果作說明,但是並沒有很詳細的以例項說明,所以他實在是不明
白為什麼在那篇文章中會說(No A) = 4 x 2 > (No B) = 7 x 1 。因此現在筆者就將那
一期的範例拿出來詳細的解說一下。
首先各位看看以下的這個積點表,在這個表中列出了各種情況的重要性。至於為什麼積點設定為這樣,也就是
要讓積點真正的能夠發揮作用:
┏ ┳ ┓
判 斷 式 績點
┣ ╋ ┫
劃一個號碼後能夠完成一條線 31
┣ ╋ ┫
劃一個號碼後在這一條線中出現四個點 15
┣ ╋ ┫
劃一個號碼後在這一條線中出現三個點 7
┣ ╋ ┫
劃一個號碼後在這一條線中出現兩個點 4
┣ ╋ ┫
劃一個號碼後在這一條線上只有一個點 1
┗ ┻ ┛
現在我們看看下面的這個賓果盤,上面的那些「 」符號表示這個地點的數字已經被劃掉了。
┏ ┳ ┳ ┳ ┳ ┓
6 11 16 21
┣ ╋ ╋ ╋ ╋ ┫
12 17 22
┣ ╋ ╋ ╋ ╋ ┫
3 8 13 18 23
┣ ╋ ╋ ╋ ╋ ┫
4 9 14 19 24
┣ ╋ ╋ ╋ ╋ ┫
10 15 25
┗ ┻ ┻ ┻ ┻ ┛
現在各位看看這個賓果盤,有兩條已經有三個點的線以及兩條有兩個點的線,因此現在應該要劃那一點比較好
呢?我們就用上面的那積分表來計算每一個點的重要性,可以得到以下的數值:
o 03:9+1=10
o 04:9+1=10
o 06:3x2=6
o 08:3+1=4
o 09:3+1x2=5
o 10:5+3=8
o 11:3+1=4
o 12:5+1=6
o 13:5+3+1x2=10
o 14:3x2=6
o 15:5+1=6
o 16:3x2=6
o 17:5+3x2=11
o 18:3+1=4
o 19:3+1=4
o 21:3x2+1=7
o 22:5+1=6
o 23:3x2=6
o 24:3x2=6
o 25:5x2+1=11
從這些算式中,我們可以看到若是劃下17或是25將可以賺得最多的積點,因此這兩個數字就是我們現在要考慮
的。接下來再以這兩個數字在賓果盤上的重要地位來判斷,25的位置要比17要好,因此就可以決定劃下25這個
數字。這種計算方式就是積點式的典型演算法,人工智慧會將整的盤上的所有數字都做一番推算,然後才選出最
好的一點。
網友還問到,在上一次的文章中筆者曾經說過積點式的人工智慧在進行判斷的時候為什麼會花掉比較多的時間
。以下來說明:
各位讀者可以想想看,若是每一格的計算需要花掉一分鐘的話,那麼在積點式的判斷中,每一次不論如何的行
動,都需要花掉相同的時間。而條列式的判斷方式會因為當時判斷的位置不同而略有不同。或許各位讀者會說
,不過是幾個步驟而已嘛,時間上能夠差多少?但是各位不要忘了,在這篇文章中筆者只不過是舉例,所以看
起來判斷式好像不多,但是在真正遊戲中的人工智慧卻不只是這麼短短几行的判斷。試著想想看,若是每一行
判斷式是十秒鐘,那麼當判斷式一多了之後會是怎麼樣呢?
這一次再向各位讀者解釋人工智慧的運算方式,希望各位讀者都能夠看得懂,若是各位對遊戲企劃有任何問題
,或是對筆者所介紹的地方有疑問,都歡迎各位來信詢問。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-987301/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 人工智慧分類淺談人工智慧
- (一)淺談人工智慧:ChatGPT人工智慧ChatGPT
- 淺談微服務轉型微服務
- 轉載分享:淺談引導盤
- 淺談JavaScript的型別轉換JavaScript型別
- 淺談人工智慧精益生產落地之道人工智慧
- 淺談人工智慧下智慧交通的深入應用人工智慧
- 淺談測試生涯如何轉型升級
- 淺淺談ReduxRedux
- 淺談文字詞向量轉換的機制embedding
- 淺談人工智慧在流媒體領域的應用人工智慧
- 淺淺淺談JavaScript作用域JavaScript
- 淺談 PromisePromise
- 淺談mockMock
- 淺談ViewModelView
- 淺談PWA
- 淺談Disruptor
- 淺談反射反射
- 淺談vuexVue
- ElasticSearch淺談Elasticsearch
- 淺談NginxNginx
- 淺談promisePromise
- 淺談visibility
- 淺談flutterFlutter
- 淺談JMM
- Celery淺談
- 淺談JavaScriptJavaScript
- 淺談IHttpHandlerHTTP
- 淺談HTTPSHTTP
- 淺談SYNPROXY
- 淺談WebSocketWeb
- 淺談HTMLHTML
- ZooKeeper淺談
- ElasticJob淺談AST
- 淺談RMQMQ
- 淺談iPaaS對企業轉型的重要性
- 淺談Go型別轉換之間的那些事Go型別
- 淺談 Go 型別轉換之間的那些事Go型別
- 淺談 Java執行緒狀態轉換及控制Java執行緒