恐怖遊戲P.T.場景觀察

因為本身頗喜歡恐怖遊戲，最近在研究恐怖遊戲場景，所以把PT的一些場景細節記錄下來。

1. 地上的不平順的水泥，貌似有把什麼東西埋在裡頭，又草草的重新封住。

2. 微弱的光線，讓玩家只能往唯一有光明的地方走，加上一條草率牽出的電源線，屋主連佈線都懶的處理了嗎!

3. 牆上剝落的水泥裂痕。在不同的地方都有些微的裂痕，像是下面2張圖都有勾狀的裂痕，但只要轉個角度，放在不同地方就不會有明顯的重複感。

4. 牆邊的木質裝飾，接縫處有著不規則的塗料痕跡，讓人感覺十分真實。

5. 牆角邊剝落的水泥漆，似乎因受潮的關係，或因在角落容易被人刮到而掉落，加深場景真實感。

6. 搖曳且昏暗的燈光，加上若隱若現的閣樓，似乎有什麼東西會躲在上面的感覺。

 7. 散落在角落的垃圾及擺飾，這房間似乎沒有人在收拾。

8. 門口玄關處，還吊有2件外套，難道這地方還有住人嗎? 

9. 週遭牆上掛有莫明奇妙的黑白畫作，說不出是什麼東西，加深恐怖感，

光從這些場景還無法看出遊戲恐怖的地方。還是要加上劇情的安排，讓奇怪的事件慢慢浮出，加上場景的加入，讓整個遊戲更加完整。

遊戲企劃文本處理技巧

有時候基表內有許多文本，可能需要批次處理。

有時候這些問題並不需要特別寫程式來解決。

就像檔案內的特定文字需要置換，用notepad++的全部取代就可以解決。



這次要介紹的幾個常會用到檔案處理需求，並且會分別介紹mac與win 10下的處理方式

1.獲得資料夾內檔案名稱。

mac

圈選多個你所需要的檔案，command+c，再去你需要的地方貼上即可

win 10

開啓Powershell移動到你所需的資料夾。

dir /b /on >list.txt

接下來那個資料夾中就會出現list.txt這個檔案，開啟他，裡面有你所需的全部檔案名稱

2.批次改檔名，或置換其中名稱。

mac

mac有內建autoMator，非常簡單，基本上可以做到檔案管理的許多事情。

win 10

批次改檔名可以直接選擇後重新命名。

如果你想要修改其中名字，開啓Powershell移動到你所需的資料夾。

Dir | Rename-Item -NewName { $_.name –replace "搜尋的字", "取代的字" }

3.文字檔案搜尋

win 10有 notepad++而Mac有Sublime Text，都俱有資料夾內搜尋的功能。
如果遇到比較困難的狀態。

例如：在這個資料夾中有我人物在遊戲內所講的台詞，因為介面修改使得文字顯示的內容變少了，該怎麼辦？又或者我想知道對話文本裡面最長的一句話？

這時候你可以利用正則表達式。

你不需要真的非常精通他，只要知道如何完成你的目標即可。
以上為例，我想知道文本中的人物台詞的字數最多是多少？

打開NotePad++使用搜尋。

"[^x00-xff]{10,}"
因為我的文本中人物的台詞都是以「"台詞"」這樣的形式出現，因此我要找的是以「"」開頭和結尾，中間都是中文。
x00-xff其實是涵蓋了雙節字符，包含了日文與標點符號，{10,}則代表10個以上。
這個意思是說，我想搜尋「以"開頭，然後串接著10以上落在x00-xff編碼內的符號，至少10個以上，然後以"結尾」。

這細部技巧可以再去研究，不過這個正則表達式在我最近的工作上幫了很大的忙！

Unity 點選及拖曳2D物件(click and drag 2D game object)

為了要實作在2D環境下點擊及拖曳物件的功能，

但是網路上分享的片段沒有完全符合我的需求，

所以寫了一份自己的版本。

主要分為2個部份

1如何判斷點擊到物件

2在按住的時間內，讓物件跟著滑鼠移動

1
在判斷點擊的方法和3D空間的作法類似，

先求出滑鼠在空間上點擊的位置，
再由此位置取得世界坐標系上，
因為2d 座標要轉3d座標會缺少一個維度資訊，
所以要需要另外再給定一個z值。

再用ray cast判定是否有撞到物體，
當滑鼠點擊時，開始判斷ray是否有打到物件，
為了加速ray cast的效率，
我們可以為物件分層(layer)，這邊是放在Unity的Layer 8。



2
最後在Drag的函式內完成每次更新都會再檢查物體位置，
如果滑鼠不再按著時，即離開函式。


Demo:

source code

PS:
1.在chrome,Vivaldi無法直接由檔案檢視結果
2.放到google drive 分享的方法。https://www.youtube.com/watch?v=c431DEshk4U
3.webGL分享同上。只是build時改成選webGL.

遊戲設計的好書 The Art of Game Design: A Book of Lenses

通常我自身是比較不建議用純看書的方法來瞭解遊戲設計，
因為"讀萬卷書不如行萬里路"，
遊戲設計由實作來得到驗證會比看書來的深刻。

當然也不是說看書一定沒有幫助，
有的時候參考別人的想法也是對自己有一定的助益。

在台灣遊戲業待了6年，會好奇別人是怎麼遊戲的，
所以就去找遊戲設計相關的書來看。

那時候就挑到了這本The Art of Game Design，
在網路上試閱了前面幾章後，感覺寫的不錯，
就立刻去天瓏把它買下來了。

如書名A book of lenses，提供各種透鏡(lenses)，讓我們以多種角度去審視遊戲。

本書在前面幾節也提到了親手做遊戲才是真正成為遊戲開發者的方法，

所以妄想從某本書籍就能做遊戲是不切實際的。

雖然書籍作者Jesse Schell參與的遊戲我都沒玩過，

但是作者的經歷還滿有趣的，

曾經做為馬戲團員、魔術師助手、作者、喜劇演員、軟體工程師、大學教授。

本書是以傳統的電玩遊戲為範本，將遊戲分為四個部份，

Aesthetics(美學)、Mechanics(機制)、Story(故事)、Technology(科技)。

美學是指遊戲的外在呈現，包含了畫面、音效、感受等外在因素。

機制則是代表了遊戲的規則。

故事是一連串不同的事件，讓玩家一步步進入遊戲。

科技則是目前製作電玩遊戲所須的基礎知識。

建議有做基本遊戲製作能力的人來閱讀這本書，

若對遊戲製作還很陌生的話，可以先找做遊戲的教學，

如果英文比較不熟的人，有另一本簡體中文的書籍可以看

通關遊戲設計之道 (Level Up!: The Guide to Great Video Game Design )。

但是上面這本書我就沒有全部看完了，

因為製作遊戲需要的知識太多了，還是從實作去學習知識比較快。

遊戲設計相關的書籍有繁體中文的相當少，

可以多找找國外的資源。

我想成為成為遊戲作家

這次分享一篇關於「I Want to Write Video Games」，並且參雜一些個人經驗談。因為我的英文實在不怎麼樣，信達雅是沾不到邊，想知道細節請看原文，我個人想法會以「我認為」開頭


在開始之前……
問自己這個問題，你覺得遊戲作家是甚麼？

想當哪一種？

文中將這個職缺分為兩種：
 比較複雜的那種，稱之為敘事設計師（narrative designer ），創作整個遊戲故事的人。故事的進展、時間節奏、角色弧線。簡單的說，就是負責設計玩家體驗（player experience）
而那些不參與設計的稱為寫手（writer），寫手的工作相對單純，在既定框架下寫出符合規範的劇情、人物、教學、提示等等。除此之外，遊戲中還是有大量的文字等著你寫。

這兩者都不是埋頭寫完就將稿件交出去，然後等著團隊將其實現。而且也不能隨心所欲的想怎麼寫就怎麼寫。

你的文字不是最終成品，而是要透過遊戲展現。你必須反覆與團隊商量，依照預算、時間的限制，遊戲中實際的呈現方式來修改。

我的故事超讚！

即便你是敘事設計師，負責整個遊戲故事的創作，也不能保證故事情節必定如你所想的發展。

在遊戲開發的過程中有太多不可控制的因素。
像是你寫了城堡，但是城堡這個場景在美術的排程上來不及完成，或是你的城堡金碧輝煌的不符合製作成本。

文中說得很直白，你要花很多時間在重寫，刪減橋段、修改情節、斟酌對白用字，大概80%的時間是在修改這些大便，是的，在遊戲完成前的大部分時間你都在做這些事。

如果你這麼堅持原則、無法妥協，甚至無法忍受這些不可控制的因素，去寫小說會比較好。

該怎麼找到這種工作？

你可以不用找了，並不是所有的遊戲都有「龐大的文字需求」，不是所有的遊戲都像GTA、Last of us，所以很顯然的這種職缺很少，甚至用外包的方式來處理。
這樣的專門職缺越來越少，很重要的原因是寫作這種技能很難展現出來。

美術看作品集，程式看程式碼。這個職缺會被歸類為企劃，而企劃正是最難獨自展現能力的一群，寫作技巧固然可從作品中看出一點端倪，卻不容易鑑別出好與優秀。

去觀察你期望的那間公司，玩遍它所製作的遊戲，了解他們的風格，掌握這種風格，這樣在你投遞作品時更有機率獲選。

加入新創團隊，因為他們什麼都缺，也沒什麼人可以挑。只要你能證明自己夠格，並獲得青睞。

該如何精進？

如果你還是學生，想知道有什麼課程可以幫助你。

好吧，沒有！

沒有課程教你如何成為遊戲作家，所以你就什麼都去學習吧！
除此之外，持續的閱讀，廣泛的閱讀，因為所有你所看過、經歷過的，都能轉化成你創作的靈感與養分。
玩遊戲，分析那些故事性強烈的遊戲，看他們怎麼鋪陳，怎麼將文字轉化為遊戲，如何與玩家互動，哪部分做得好，那部分做得不好。
然後練習，寫作需要持續練習才能進步。將故事轉化成遊戲也需要練習，試著製作遊戲，將心中所想的呈現出來。

不要寫同人當作品，因為既有的角色已經成形，這些角色並不是被你的文字賦予血肉，並不因為你的文字而變得生動，而是原作的努力。

嚴格來說，這還會會掩蓋你的表現，展現技巧這件事已經很困難了，別給自己找麻煩。

我認為

故事超讚，真的需要改嗎？
大概就像看過多場籃球比賽覺得自己能去打NBA，或是老饕吃過很多美食，突然語出驚人：「我想到一種新菜色超好吃，戈登拉姆齊也會讚嘆！」

你知道要像《百年孤寂》在結尾來一場同步大毀滅，這在實際上非常難做。

即使你已在出版業小有名氣，甚至是職業作家，也不代表你的作品能變成好遊戲。

哈姆雷特，西遊記等可列為經典的文學作品，可不是每部翻拍成電影都很賣座。

而像巫師這樣小說改成遊戲並且成功的案例可就更少了。

關於寫作的練習上，一開始我沒預設要用什麼方式書寫，但是現在我會建議用劇本的方式書寫。
這是我個人經驗，故事在轉化為遊戲演出前，要先被製作團隊理解然後才會產出，我覺得劇本是很好的溝通格式。

例如：「他走過一條小溪，溪水清澈的能看到底下的鵝卵石。」
只有設計者知道這段文字要帶給玩家什麼樣的體驗
而不同人閱讀這段文字後，心中呈現出的圖像並不相同。
畫面上的人是面對鏡頭呢還是背對？小溪是要流向哪邊呢？鵝卵石數量很多嗎？這個畫面是要凸顯他過小溪？還是溪水很清澈？還是小溪中的鵝卵石有什麼異狀？基於心象的一致性，最好讓閱讀者心中呈現想像沒有太大的差距，而劇本則能表示幕與幕的連接關係。

我不建議運用實驗性寫作手法或技巧。
例如意識流，除非你能確實驗證，讓最後的演出呈現出意識流效果。你所呈現的故事並不是直接以文本的方式呈現，即便以電子小說方式也有音樂與美術搭配閱讀節奏來展示，特殊技巧只是徒增困擾而已。

後記

遊戲業界總是有單人開發出卓越遊戲的案例，不否認這些開發者真的相當優秀，程式美術企劃兼具！很可惜我們大部份都沒有這樣的才能，所以我認為遊戲開發是一群人合作產生的，團隊成員的協調、溝通能力應該更重要。

近日我的朋友圈中有人出國健行，他們背著重裝在北極圈走了一百公里。他們說了一句話，特別有感觸，於是記了下來。

一個人可以走很快，但是一群人可以走很遠！

共勉之，那麼下次再聊。

基表設計

遊戲中有關人物素質、關卡資訊以及一大堆雜七雜八來控制用的文件，這些文件稱為「基表」。

基表的用途

舉例來說，《爐石戰記》每週會有旅店大亂鬥，每次的規則都不太一樣。

或是有些手機遊戲，每週都會有更新，開放新的人物，還有提高營收的活動。

「本週只要參與OO活動？就能得到XX！」「限時加價購！購買XX只要再加OO即可獲得限量XX」「稀有角色出現機率超大提升！」

那應該會有一份文件來控制這件事的發生與結束。

簡單的說，基表控制著遊戲的的可變化內容。

這些基表在輸出前可能是這個樣子。

ActivityName	TimeBegin	TimeEnd	Case	Value
商店打8折	2016/7/26 8:00:	2016/7/26 上午 14:00:00	store	80
轉蛋機率提升2倍	2016/7/26 9:00:	2016/7/26 上午 15:00:00	gacha	200
經驗1.5倍	2016/7/26 10:00:	2016/7/26 上午 14:00:01	exp	150
金幣2倍	2016/7/26 11:00:	2016/7/26 上午 15:00:01	coin	200

(表一)

為了方便討論起見，我定表格橫行直列，第一行的欄位稱為key，以下的欄位稱內容。

基表的key與內容，是在遊戲開發時，由企劃根據所需功能設計，並且與程式討論實作的意見後進行修改。

例如今天需要一份基表來控制遊戲中人物素質以及等級的成長。

一種簡便的方式如下

LEVEL	HP	ATK	DEF
1	100	60	18
2	120	72	32
3	140	84	50
4	160	96	72
5	180	108	98

(表二)

直接顯示每個等級的狀態，程式在實作上可以直接讀取相應數值。

最後輸出Json，Html，或是其它支援的格式。

可能的疑問像是……人物的屬性成長是有差別的呢？多開一張表嗎？

要怎麼表示一個防禦力更低的狀態？可以填成負數嗎？

總之，請先弄清楚你的需求，再來談論這些問題。基表的設計就是依照需求來調整。

在單機遊戲中，基表是在遊戲釋出以前就修改完畢，不再變動。

而在需要長期營運的遊戲時，則依據營運團隊的建議製作、修改相關設定，並在每週的定期維修更新時，上傳至遊戲伺服器。

基表的製作

製作基表前有幾個要點。

1.確認需求

通常基表的限制來自需求的彈性，需求的變化彈性越高，基表在設計上的精確度也越低。

「人物只有一個技能」

那麼可於表二再開一列key為Skill,型態int的資料。

「雖然這個人物目前只有一個技能，不過在之後，我希望他擁有多個技能……」

基本上，程式聽到這樣的需求後，就應該將Skill,改用陣列來儲存相關資訊。

「技能本身還有熟練等級可以提升」

那麼欄位內容又會更加複雜。可能本身就是巢狀結構。

2.控制基表的欄位與內容深度

通常欄位越多代表修改與檢查的難度也相應提升。
這時可以考慮以資料縮減，例如相關資料以陣列儲存，或是以巢狀結構儲存。
不過需要注意的是，如果巢狀結構就相當複雜，使得可閱讀性降低，就應該考慮其他方式。

可閱讀性，是指內容在無說明下可直接理解其代表意義，像表一的case代表的是活動項目，但是實際效果是什麼呢？不過這個可閱讀性比起

3.關聯性
這是很容易理解，你可能會在怪物與怪物掉落物品放在同一張基表。
但是不會把武器的售價跟人物等級放在同一張表吧？
...
..
.
難道人物等級提升會使得賣物品價格更高？

好吧，如果是你想做的話，首先你需要在人物的基表中設計到達一定等級會惜得技能的欄位。然後在技能基表中設定可以使販售特定物品的金額提高的性質，然後再去物品基表設定物品會因為技能提升多少售價。

(來自好色龍)

4.輔助工具與防呆機制

在單機遊戲時代，基表的範圍相對單純，無非是單位數值、物品技能一類。而且在上市前都有足夠的時間做平衡調整與檢查。

到了MMO時代，偶爾會聽到某遊戲出包，錢亂噴，寶亂掉，玩家趕快上線去拿啊。
這通常是基表填錯造成的問題。也代表有企劃要飛高高了！

「填表而已，有這麼困難嗎？」
「填表工具人連表都填不好，要你何用？」

等等，墨菲定律這麼說：「可能會發生的錯誤總會發生」我們能做的，是將機率以及後果降到最低，避免不可挽回的災難。

(來自Please Don't Touch Anything)

哪些稱得上是不可挽回的災難？
玩家資料遺失，然後沒有任何備份。
釋出了稀有物品，然後沒有任何備份。
不小心刪除了基表，然後沒有任何備份。
更動到玩家client端出錯無法進入遊戲，然後除了砍掉重裝，沒有方式可以修正。

定期備份雖然可以解決大部份問題，但是屬於補救方法，預防的方法是「細心的檢查」以及「防呆機制」。

什麼防呆機制呢？
可以從基表本身以及遊戲內的程式來改善。

在企劃方面，google spreadsheet或是excel本身都有函式功能，可以預防欄位上出現不合法的數值，例如負數、空格等等，或是可以跨表交叉參照比對，避免不存在的值出現。

在程式方面，則是善用預設值，讀表之前先做判斷，不要傻傻的，表填什麼就讀什麼，把null讀進來炸掉。

與其相信企劃的手不會抖，不如相信自己寫的程式吧。

最後確認遊戲client端的基表更新流程，總是維持著更新優先，這是為了保證任何寫入的錯誤值都有可修復性。

題外話

基表的更新維護，常常都是企劃與程式間發生衝突的地方。
有程式認為企劃會使用基表填寫出非原先預定功能，只是為了湊出新功能。這是在無法變更程式下的權宜之計，可能是上頭壓力。但是最後這些拼湊的功能必須導正，不然會成為某種技術債。

需要營運的遊戲，會有後台操作界面，用來將基表上傳至server。曾經聽過有人在後台按上傳卻按到旁邊的刪除，將資料庫的該表drop掉。
這件問題發生，首先是人員，再來是怎麼會有如此危險的按鈕在後台人人可按到的地方？
如果有個按鈕出現，請預設在最糟的狀況按下會發生什麼事吧！

大概就是這樣，下次再談。

PBR Physically-Based Rendering

Physically-Based Rendering翻作基於物理的算圖，縮寫為PBR。
因為要瞭解電腦是如何算圖，下面記錄基礎知識。

光-基本原理
光控制了人類可以看見什麼，光是複雜的物理現象，有波動、粒子兩種特性。所以有各種模型來表現光。對於做材質的人來說理解這些行為是很重要的，越了解光在虛擬世界運作，越是能讓畫面好看。

當物理表面十分平滑時，入射的光線會由相對的角度完全反射出去。入射角會等於反射角。

Absorption and Scattering 入射光線會被表面吸收或發散，
透明與半透明(Transparency and Translucency):上面這兩項特性可以表現透明與半透明的材質。下圖右全透明的材質即完全不被吸收而穿透過去，圖左則有部份被吸收及發散，有部份光線透過來但看起來是模糊的。

Diffuse and Specular Reflection: diffuse即是光射到物體表面後均勻反射，而specular則是在直接反射至相對的方向。下圖即是兩種狀況。

Microfacet(表面的粗糙程度):
理論上diffuse及specular是取決於表面的細微起伏。通常不會直接將細微起伏放在模型上，而是會由另一張roughness map來表達起伏呈度。

Color 顏色

顏色取決於光源的波長，接觸到表面之後，一部份會被吸收，一部份會反射。反射到我們眼中的光，即是我們所看見的顏色。像是上圖各種波長的光照到了蘋果上，橙黃綠藍靛紫光都被蘋果的表面吸收了，只有紅光反射到我們眼中，所以我們看到蘋果是紅的。

BRDF 雙向反射分佈函數(Bidirectional Reflectance Distribution Function)
一組用來描述表面反射性質的函數。

例如上面左右張圖採用不同的函數，在光線反射的表現就不相同。左圖的光線直接反射的亮點有較大的範圍的光暈。

Energy Conservation能量轉換
若符合物理原理之下的能量轉換，那由表面反射出的光總合不會大於入射的總合，因為符合物理定律，美術人員可以不用去擔心能量轉換，專注在其它項目。

菲涅耳現象(Fresnel Effect)
人眼接受到物體反射的光線取決於其觀看的角度。

而F0就是指以垂直角度看物體表面所見光線。下圖是F0在不同材質呈現的顏色，左列是非金屬材質，右列是金屬材質。

Metals and Non-Metals(金屬與非金屬)
金屬大多反射效果良好，我們不需要給他Diffuse Color(物體本身顏色)，相對的我們要為他設定specular map來呈現金屬效果。
如果是生鏽的部份則屬於非金屬，下圖是部份生鏽的金屬球。

Linear Space Rendering
在Linear Space下運算才可以得到正確的結果，而顯示器並非是在Linear Space下，所以調整到Linear Space.

參考文章:
https://www.allegorithmic.com/pbr-guide
http://blogs.unity3d.com/2015/02/18/working-with-physically-based-shading-a-practical-approach/

VR遊戲試玩心得

等了N個月，終於把兩台VR設備都搞到手了。很意外的VIVE在1週就送到手上，而Oculus竟然2個多月才拿到。

Oculus的遊戲還在貨送到的2週後才將遊戲代碼發出，服務品質真的很差。

下面對各遊戲簡評一下

Oculus:

Valkyrie

目前畫面最好的3A大作，操控也很便利，一定要體驗一下VR的3A大作。
優點:畫面佳
缺點:在VR太空劇烈移動會造成不適感

Vive:

Project Cars

很可能是另一款畫面很好的遊戲，當AA調高的時候會造成主機完全死當，用較低畫質玩也還不錯。
優點:操作很便利，跑道都有指引標示教你跑。
缺點:和我的980Ti有點衝突，畫面不能調最高。

theBlu

海底世界體驗(可能不算遊戲)，在HTC攤位有體類過了。
優點:完美發揮了Room Scale的強項，體驗感十足。
缺點:只有3個場景，全看過只花了1小時以內。

Job Simulator

很有趣的小遊戲，靈活運用了Vive的控制器，達成各式操作。
優點:可以玩的場景很多，很多道具可以互動。
缺點:因為是小遊戲，不耐久玩。

Final Approach

玩了第一小關可以畫線讓飛機沿著軌跡移動，很有趣的設計。
優點:畫飛行路線的體驗滿有趣的
缺點:他有另一個以手把操作飛機的模式，攝影機跟在飛機後面，在移動時十分不舒服。

NEKOPALIVE

體驗3D日式角色演唱會的魅力，全視角的演唱會果然和影片有差別。
優點:VR演唱會體驗
缺點:只是Demo

The Lab

Valve做的各類小遊戲Demo,而且還有放出Renderer的Unity Source Code,很適合開發參考。
優點:大部份可以嘗試的基本功能都可玩到，投擲、射箭、高空風景、修理機器人等。
缺點:只是demo

Custom Maid 3D 2

3D的H Game，雖然只有部份互動，但讓人感到VR在成人產業可以有很大的發揮空間。
優點:可以摸頭髮、裙子、胸部
缺點:也只有上面3項有互動，主體還是本來的遊戲。

快速評分一下兩台裝置:
服務品質: Vive勝
因為等待時間及客服使用的經驗，Vive大勝Oculus
架設便利度: Oculus勝
Vive還要架設兩個在2M高度的基地台，而且還要空間允許，便利度大減。
穿戴舒適度: Vive 勝
Oculus對於載眼鏡的人來說太不舒服了。
遊戲內容: Oculus 勝
雖然我在Steam買了許多Vive的遊戲，但是實驗性質較高，比較少像EVE:Valkyrie各方面都很完美，而且Oculus的遊戲都開發一陣子了，Vive還相對晚出。
如果Vive的遊戲再多些，那Oculus的地位將很危險。

另外特別提一下關於VR中暈眩的感覺，在Vive玩Room Scale的遊戲幾乎不會有暈眩的感覺，在玩Project CARS及Valkyrie、Final Approach才有比較強烈的暈眩感，猜想大概是因為遊戲中的移動和自己身體的移動對應不上，所以造成不適感。

若要以手把操作的遊戲類型，就會需要特別調整人體移動的舒適度，像是Oculus的商店就會對商品的舒適度分級，算是滿貼心的標示。

之後有機會再來看看VR的成人影片，看VR是否能帶另一種的體驗。

Elo Rating System

有時候在競爭式的遊戲中，可以看到系統對於玩家目前表現的評價。例如《英雄聯盟》的排位，《皇室戰爭》的積分。還有先前與南韓棋士李世乭對弈的人工智慧AlphaGo，在賽後的排名迅速竄升。

在開始討論之前……

先來談談實力這件事

撇開實際看到的數字之前，我們是如何評定實力的高低、技巧的優劣？

例如：朋友之間打牌，如果彼此之間牌技相差懸殊，很容易就「看」得出來誰是會玩的，這是因為他贏得多、輸得少。
反過來說，一群實力差不多的人，反而很難決定誰的實力高低。

表現不是絕對的，實力強的不必然贏過實力弱的，只是獲勝機率相對高而已。

假設我們將玩家a,b的表現量化，稱為Xa,Xb，且該競技沒有和局。則a,b的表現跟勝率有關。
令Ea,Eb為玩家a,b的勝率，則：
Ea=Xa/(Xa+Xb)
Eb=Xb/(Xa+Xb)

這只是我隨意提出的表現量化方式，不必深究。

關於機率分布

複雜數學在此不提，用維基百科中做簡單舉例，下列函數為二項分布的p.d.f(機率密度函數)

當n=3,k=0,p=1/6

可以描述

在擲3次骰子中，不出現6點的機率

機率分布可以描述機率參與其中的實際現象。

從西洋棋說起

在1960年前，西洋棋的計分方式為Harkness System，這套系統並不能很好的評價出選手的表現。於是，物理學家同時也是西洋棋棋士的Arpad Elo，提出Elo Rating System。

假如一位棋手在比賽中的真實得分${\displaystyle S_{A}}$（勝=1分，和=0.5分，負=0分）和他的勝率期望值${\displaystyle E_{A}}$不同，則他的等級分要作相應的調整。具體的數學公式為

${\displaystyle R_{A}^{\prime }=R_{A}+K(S_{A}-E_{A}).}$

公式中${\displaystyle R_{A}}$和${\displaystyle R_{A}^{\prime }}$分別為棋手調整前後的等級分。

 其中K為常數，如下：

$$
{\displaystyle R_{B}}為對手等級分

(What the F...)

前面的公式還可以理解，但是這個
這個……



Ea destroy everything

Elo一開始是使用常態分佈作為選手實力的近似（常態分佈要另開主題），但是後來發現logistic distribution 更近似現實所有選手實力的結構。

而logistic分佈函數的樣子就長得很像上面那樣。Elo建議當選手等級分差距200時，其勝率為0.75:0.25（10^0.5=3.162）高能注意


回到Ea的公式，這可以理解成：當玩家a,b的等級分差距400，a,b的勝率比為1:10。
選手A等級分1200，選手B等級分1600。則B的勝率是A的10倍。（對賭盤來說很重要。）

而K是作為結束後，雙方等級分的增減，一方加多少另一方就減多少。

假設K=32

A等級分為1400,B等級分為1700，則Ea=0.151,Eb=0.849

賽後等級分變化

	A勝利	B勝利
賽後A等級分	1427.168654	1395.168654
賽後B等級分	1672.831346	1704.831346

強勝弱：「啊不就好厲害，虐菜嘛？」所以只加一點點分數。

弱勝強：「這就你一直不肯教我的遇強則屈，借花獻佛！」大加分！

K訂太高，則每場比賽導致的等級分變化太大，一不小心就鑽石掉到銀牌。
K訂太低，則超級新星的等級分成長太慢，還要再砍很多雜魚才能到達應有水準。

在西洋棋現行規則中，新手期的K比較大，老手比較小。
而K值可以根據實際情況自由決定。

實際應用上的問題

這裡就我遇到的問題，提出目前想到的解法，可能並不正確。

5v5的比賽怎麼辦？
做兩隊的平均等級分，如果有不一樣的K值做平均的K，比照雙人競賽，最後計分依比例分配。

該怎麼劃分區間？
長久來看，人數會集中在平均等級分附近，所以依據需求可以給出定值的等級分，1000分以下叫noob，1000~1200稱為菜鳥以此類推。

每場競賽後的增減分等價，這不就代表很多人會落在起始分數附近嗎？
因為新手還沒有經過足夠的競賽使其逼近他應有的等級分，透過第二層資訊例如10場之後才公佈分數，或者定期決定牌位。

玩家不玩，對整體的影響？
如果玩家不玩了，不再被配對到，整體可流動的分數減少。LOL的做法是定期reset，清空判定為無效的玩家。


大概就是這樣子～
我們下次再聊。