|  | 
 
| 本帖最后由 tryourbreast 于 2015-6-18 12:55 编辑 
 前設:編程的和做遊戲的大多數學遊戲死得早。前設:分析漸近增長需要數學知識。
 結論:上述人通常無法駕馭漸近增長和平衡性調整。
 
 
 Everything is fast for small n.
 
 數值增長速度的問題源遠流長,傳統RPG界就有個著名的說法:"Linear Warriors, Quadratic Wizards",就是說數學方法沒做好,會導致後期一邊有些職業秒天秒地秒一切,一邊有些職業就只能打打醬油,還會被小怪一擊秒。
 
 這個問題現在並沒有消失;恰好相反,由於潮流變成了永無止境的掛機遊戲,大數遊戲和模擬建設遊戲,讓遠期遊戲平衡性這問題變得極其重要。
 開發者一時興起,決定把某個數值由c*a^n改成了c*n^n(n是等級,a和c是常數),如此一念之間的改變,也能嚴重改變後期平衡性,繼而決定遊戲能不能玩。
 
 算法也是一樣,誰用bubble sort而不是quick sort進行排序的,都可以綁起來燒了。
 
 
 
 讀過CS的一定有學過,漸進分析使用的是大O表示法:
 
 剛才說的RPG裡的Linear Warriors, Quadratic Wizards,就是因為近戰單位增長幅度是O(n),然而有些職業(主要是法爺)的增長幅度是O(n^2)甚至更高,後期近戰單位就不能玩了。复制代码如果當x足夠大時,g(x) 至多等於 k * f(x)(k為常數),那麼g(x) = O(f(x))
 (試想一下,n每次翻倍,O(n)的函數會變成原來的兩倍,而O(n^2)會變成4倍。只要持續幾次…)
 
 他們的解決方法是,在經驗值需求上也給予相應的增長曲線:能力呈O(n^2)增長的,每級所需經驗值也是O(n^2),這樣相除下來就是O(n^2/n^2) = O(1),平均獲得的力量就跟O(n)能力和O(n)經驗值的差不多(也是O(1))。
 
 然而這個世界上還有幾何函數(a^n),階乘函數(n!),甚至n^n的玩意,看似沒甚麼分別,但一個比一個長得更快。
 n不需要超過100多少,這幾個函數就可以相差googol級的倍數。
 對於算法或遊戲平衡性來說,都是個大災難。
 
 (更具體一點:
 多項式n每次乘2,都會增多2的某次方,取決於其級數;
 幾何級數n則是每次加上一個定值,函數都會乘以一個常數;
 階乘是定值增長導致愈來愈大的倍數增長;
 n^n的話連以前乘過的倍數都會變大了。
 )
 
 
 
 
 如果你回想一下,你玩的遊戲大多都是在重覆一件事情:
 你是一個O(n)的函數,在企圖追逐一個O(n^a)甚至是O(a^n)的函數。
 
 這當然是徒勞無功的,愈是追趕,愈是與你的目標相距更遠,每走一步都變得極其艱難。
 
 世間最大之絕望感,無非於此。
 
 
 以大數增長代替遊戲難度的做法,已經成為了這時代的潮流;上述的人生哲學不停在重覆。
 
 嗯,所以我覺得,逆個位當自己是玩家去思考,去想想這種追逐是否值得,然後做出來的東西就會更合理了。
 
 
 我相信還沒有人想用bogosort排序10個以上的元素。
 
 
 
 p.s 常見的大O表達式的排列:(a > b > 1)
 O(1) < O(log(n)) < O(log(n)^a) < O(n^(-a)) < O(n) (log可以是任何base)
 O(n) < O(n*log(n)) < O(n^a) < O(n^b)
 O(n^a) < O(b^n) (不論任何a和b均成立)
 O(b^n) < O(a^n)
 O(b^n) < O(b!) = O(n^(n+1/2) * e^(-n) )
 O(a!) < O(n^n)
 
 O(g1(n)) < O(g2(n))  -->  O(f(n)g1(n)) < O(f(n)g2(n))
 O(g1(n)) < O(g2(n))  -->  O(1/g1(n)) > O(1/g2(n))
 
 
 實在不會比較的話,最簡單的方法是相除一下看表達式的極限,或者用wolfram alpha。(喂
 
 
 
 當然,做大O分析時,除了看極限增長,還要看n的取值範圍。
 
 也許n取值1至100時還能接受,然後你決定取值改為10000了,有些部份可能就會因此變得過大。
 相反地,如果n的取值其實只有1至5,那麼大O分析就沒甚麼用了。
 
 | 
评分
查看全部评分
 |