Re: [F/GO][日服][閒聊] 推特課金26萬沒梅林

看板TypeMoon作者 (LaPass)時間6年前 (2017/10/06 11:19), 編輯推噓25(25推 0噓 43→)
留言68則, 27人參與, 6年前最新討論串6/8 (看更多)
先講一個概念 不論是方法一 (卡片在伺服器端早已序列產生好) 或方法二 (伺服器端即時產生亂數，再依照亂數大小生成卡片) 如果你使用的是「真亂數」 那麼，不論是用什麼樣的方式去生成抽卡結果 那對抽卡的人來說 期望值都不會有影響 1%的機率長期統計下來仍然是1% 會有影響的，是抽卡結果的常態分布 例如，方法一可以避免「連續N單大暴死」 以及「十抽十五星」這種狀況發生 所以，擔心被領石帳/工作室搶走的假設 完全是多餘的 因為對方也可能幫你把槓龜的卡通通抽走 一來一往，等於沒影響 接下來會針對兩種方式做更仔細的解釋跟分析 可能會有點無聊 方法一： 卡片在伺服器端早已序列產生好 這就像是聖誕刷箱抽襪子，從一個固定的卡池抽獎的概念 這裡先聲明 卡池的大小並不一定要能包含所有卡片 因為再生成卡池的時候，也可以使用亂數 例如可以生成一百張卡的卡池 其中那一張五星卡，隨機決定是哪一張五星等等 另外關於池的大小也是一個問題 當你的池子數量太大的時候，等於沒作用 例如以1000抽為一池 依然可能發生900抽沒五星，最後100抽10五星這種狀況 所以如果有用卡池功能的話 這卡池的數目不能太大 卡池又有分，多人(全伺服器或單一伺服器節點)共用一個卡池，以下稱公池 或是個人獨立的卡池，以下稱個人池 如果是個人池 那麼，這種設計主要是避免「連續N單大暴死」或是「十抽十五星」 這種狀況發生 但很顯然FGO沒這麼做 為常常聽過有幾百抽0五星之類的狀況 或是十抽好幾隻五星的狀況出現 如果是公池 那沒有討論的必要了 在一大堆人共用卡池的狀況下 跟方法二的效果是一樣的 方法二： 伺服器端即時產生亂數，再依照亂數大小生成卡片 這個太簡單，我不知道該怎麼解釋 總之就是丟骰子那樣的模式 每次抽卡都等於是丟一次100面骰，丟中就中獎 接下來講關於程式的部分 方法二在實作上是最簡單的方案 就叫系統生成一個亂數，再用亂數去查表 他們應該會有一個設定檔案，決定了卡池的機率，記錄了每張卡的機率是多少 再用那張表，決定該生成什麼卡片出來 這種程式不需要考慮其他節點，或是各種鎖定、同步問題 所以說這是最簡單的方式 方法一，在實作上比較麻煩一點 如果是個人池的話，你需要去儲存他的卡池狀況 在他下次抽卡時，再拿出看看要給他什麼卡 如果是公池，那是非常麻煩的事情 如果A、B兩個人同時抽卡的話 你需要考慮兩者的執行緒安全問題 因為這可能會導致A、B兩個人都抽到同一張卡 這個bug在抽卡上造成的影響，聽起來好像沒什麼 但如果用購物網站來當例子的話..... 商品的數量只剩下1個 A、B兩個人同時按下結帳，結果兩個人都同時成交了。 大概是這種層級的問題 所以，實際上在寫這段程式碼的時候要這樣： 1. A鎖定卡池 2. A抽卡 3. A釋放卡池 B要等A把1~3都做完，才能抽卡 同一時間可能有幾百，甚至上千上萬人在抽卡 每個人都要一個個排隊、抽卡 這對伺服器來講是吃力不討好的工作 而且沒有必要搞成這樣 同樣的道理，把亂數交給第三方也只是把系統搞得更麻煩，更複雜而已 另外關於這個影片 https://youtu.be/Nehvzf9esQs
發生的原因可能是這樣 有些程式語言中的亂數 在初始化的時候要給他一個seed 而同樣的seed會導致生成同樣的亂數數列出來 而程式設計師給他的seed 是用「時間」，而且單位只到「秒」 例如php當中就是 srand(time()); 這樣 這會導致同樣時間點擊抽卡 抽到的卡都一樣的狀況 我的工作雖然不是轉蛋遊戲 但也是線上機率遊戲，跟遊戲、機率有扯上點關係 像這種機率遊戲，常常會有人懷疑站方作弊 或是在機率上動手腳 但營運單位才不會搞這種麻煩事 因為規則上就已經寫白了 營運單位就是要賺你的錢 拿大樂透來舉例 如果你看得懂遊戲規則的話 你就能看出「買一張大樂透平均下來會損失20元」這件事情 但還是有人會去賭 所以在評估「最差的狀況」的時候 基本上拿營運方公告的數值下去估算就可以了 以FGO來講，就是「真隨機，1%SSR」 轉蛋遊戲跟線上機率遊戲，有本質上不一樣的地方 轉蛋遊戲的營運方跟玩家的對立，不像線上機率遊戲那樣強 反而是，防止極端值出現，比較能避免玩家棄坑 這也是為什麼B服之前搞了個120抽保底出來的原因 像是保底機制，比較有可能的實現方法 就是在沒抽中的時候，在他個人紀錄上+1 當這個紀錄超過某個數值的時候，偷偷調高抽卡機率，這樣 B服那時候的狀況是直接設成100%，所以看起來很明顯 這種做法比個人池的方式，還要來的簡單方便的多 我認為在推斷卡池的機制的時候 應該要把日服跟B服分開來看 嘛.... 因為B服有前科 -- -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.227.87.115 ※ 文章網址: https://www.ptt.cc/bbs/TypeMoon/M.1507259943.A.B30.html
→
10/06 11:22, 6年前 , 1F
B服很久以前就有在做人工保底了=w=
10/06 11:22, 1F
→
10/06 11:22, 6年前 , 2F
其實1跟2的差別只在於1抽完有沒有把卡放回去
10/06 11:22, 2F
推
10/06 11:22, 6年前 , 3F
10/06 11:22, 3F
→
10/06 11:22, 6年前 , 4F
水庫可以看看這個
10/06 11:22, 4F
推
10/06 11:25, 6年前 , 5F
好複雜，就想成50%就好了阿XD
10/06 11:25, 5F
推
10/06 11:26, 6年前 , 6F
台服的資料來自B服, 所以台服也有可能有保底機制??
10/06 11:26, 6F
推
10/06 11:26, 6年前 , 7F
B服150抽泳裝爆死~~~ 保底一去不復返
10/06 11:26, 7F
推
10/06 11:26, 6年前 , 8F
想成0%就好了抽中的都不會是你
10/06 11:26, 8F
推
10/06 11:27, 6年前 , 9F
阿，我說的B服不是指陸版，是指大陸手遊
10/06 11:27, 9F
推
10/06 11:27, 6年前 , 10F
方法一的鎖卡池(執行緒).. 嗚我的頭好痛...
10/06 11:27, 10F
推
10/06 11:30, 6年前 , 11F
保底是好文明
10/06 11:30, 11F
→
10/06 11:31, 6年前 , 12F
所以說1的作法是bullshit 抽個卡不會搞成這樣..
10/06 11:31, 12F
推
10/06 11:36, 6年前 , 13F
會啊 1.做法的好處就是有人來查時機率一定一樣啊 只
10/06 11:36, 13F
→
10/06 11:36, 6年前 , 14F
是讓玩家等個執行緒而已也不會很久啊
10/06 11:36, 14F
→
10/06 11:37, 6年前 , 15F
保底機制最簡單的作法，紀錄沒抽中次數，超過後換個只有四
10/06 11:37, 15F
→
10/06 11:37, 6年前 , 16F
星的池給你，然後歸零
10/06 11:37, 16F
→
10/06 11:37, 6年前 , 17F
"只是讓玩家等個執行緒而已" (燦笑
10/06 11:37, 17F
→
10/06 11:38, 6年前 , 18F
我豆頁痛
10/06 11:38, 18F
推
10/06 11:38, 6年前 , 19F
又不是沒等過 怎麼了嗎
10/06 11:38, 19F
推
10/06 11:39, 6年前 , 20F
不用多，想想看有一千個玩家衝進來要等執行緒時會怎樣
10/06 11:39, 20F
→
10/06 11:40, 6年前 , 21F
超過就炸伺服器啊 這不就是fgo嗎
10/06 11:40, 21F
→
10/06 11:40, 6年前 , 22F
這種東西理論上在大次數(來個一億抽) 機率會一樣啦
10/06 11:40, 22F
→
10/06 11:41, 6年前 , 23F
所以不用特地作1來防別人查
10/06 11:41, 23F
推
10/06 11:41, 6年前 , 24F
看了下來還是覺得有保底跟天井好一點點
10/06 11:41, 24F
→
10/06 11:41, 6年前 , 25F
自己東西出去前就會做這種測試了
10/06 11:41, 25F
→
10/06 11:42, 6年前 , 26F
不然就像現在日版SIF搞個200抽box，把內容物剩餘數量都
10/06 11:42, 26F
→
10/06 11:42, 6年前 , 27F
標示出來讓人流口水
10/06 11:42, 27F
推
10/06 11:43, 6年前 , 28F
('・ω・')那跟遊戲王的卡包一樣啊
10/06 11:43, 28F
→
10/06 11:43, 6年前 , 29F
現在10抽有保底阿(欸 其實我覺得可以用個30連抽保4星從者?
10/06 11:43, 29F
推
10/06 11:43, 6年前 , 30F
那是一番賞嗎
10/06 11:43, 30F
→
10/06 11:44, 6年前 , 31F
有保底或是天井機制總是比較好的
10/06 11:44, 31F
推
10/06 11:58, 6年前 , 32F
把抽個卡搞成mutex也太搞剛XD
10/06 11:58, 32F
推
10/06 12:00, 6年前 , 33F
很遺憾的是保底已經不復存在了
10/06 12:00, 33F
推
10/06 12:03, 6年前 , 34F
保底120抽超佛的，1.2倍期望值就保了
10/06 12:03, 34F
→
10/06 12:03, 6年前 , 35F
實際上機制1也無法防止個人N單暴死 因為共用卡池隨時在變
10/06 12:03, 35F
→
10/06 12:04, 6年前 , 36F
十抽十五星的狀況就要看卡池箱子大小 夠大也不是不可能@@
10/06 12:04, 36F
→
10/06 12:09, 6年前 , 37F
如果要真的做到常態分佈 那實際上就會調整 而不是真隨機
10/06 12:09, 37F
推
10/06 12:10, 6年前 , 38F
滿好奇十連保底的機制~
10/06 12:10, 38F
推
10/06 12:10, 6年前 , 39F
120保底的期望值大概比1.2再高一點 因為還要考慮前面的
10/06 12:10, 39F
→
10/06 12:10, 6年前 , 40F
機率
10/06 12:10, 40F
→
10/06 12:10, 6年前 , 41F
所以才需要驗證機制來取信說服玩家 避免黑箱疑雲
10/06 12:10, 41F
推
10/06 12:15, 6年前 , 42F
我在這裡宣布 哲學家用餐問題正式改名為御主抽卡問題
10/06 12:15, 42F
→
10/06 12:18, 6年前 , 43F
10連保底的機制並不難，只要排列成任意取10組必SR即可
10/06 12:18, 43F
推
10/06 13:10, 6年前 , 44F
御主抽卡問題www工程師可不會沒事自找麻煩
10/06 13:10, 44F
→
10/06 13:14, 6年前 , 45F
當你的池子數量太大的時候，等於沒作用<< 不懂問題在哪?
10/06 13:14, 45F
推
10/06 13:15, 6年前 , 46F
（體感）當按下去佇列就排訂好哪些東西給你了，所以
10/06 13:15, 46F
→
10/06 13:15, 6年前 , 47F
以才有換時段抽的說法
10/06 13:15, 47F
推
10/06 13:19, 6年前 , 48F
個人池要看會不會update，不然就是偽機率了
10/06 13:19, 48F
→
10/06 13:20, 6年前 , 49F
還要要看抽後是否放回
10/06 13:20, 49F
推
10/06 13:30, 6年前 , 50F
把你槓龜的抽走是你也抽很大才行啊
10/06 13:30, 50F
→
10/06 13:31, 6年前 , 51F
佇列中100張卡就依機率塞卡，100張就一張五星隨機英
10/06 13:31, 51F
→
10/06 13:33, 6年前 , 52F
然後再依你現有的酒桃量來切一段佇列給你抽
10/06 13:33, 52F
→
10/06 13:34, 6年前 , 53F
我覺得光是伺服器沒有爆,就足夠證明不會是先預先產生池
10/06 13:34, 53F
→
10/06 13:34, 6年前 , 54F
子了,100個執行緒同時搶一個記憶體空間,絕對塞爆
10/06 13:34, 54F
→
10/06 13:34, 6年前 , 55F
這概念跟池子沒關，要查驗也沒問題(?)
10/06 13:34, 55F
→
10/06 13:40, 6年前 , 56F
*每100張卡
10/06 13:40, 56F
→
10/06 13:42, 6年前 , 57F
每個請求剛好都沒切到那段含有五星英靈的佇列 就暴死
10/06 13:42, 57F
→
10/06 13:49, 6年前 , 58F
樓上不就要每人擺個100張牌，最近1000萬下載，嗯？
10/06 13:49, 58F
→
10/06 14:35, 6年前 , 59F
就想像有個接近無限生成的長鏈的佇列等著大家切?
10/06 14:35, 59F
→
10/06 14:37, 6年前 , 60F
拉長一算機率的確是對的 可是你切不到那段五星石頭
10/06 14:37, 60F
→
10/06 14:37, 6年前 , 61F
石頭就抽光了
10/06 14:37, 61F
推
10/06 21:56, 6年前 , 62F
我的看法同樓上
10/06 21:56, 62F
→
10/07 01:46, 6年前 , 63F
XD 我只是體感猜測
10/07 01:46, 63F
→
10/07 01:46, 6年前 , 64F
一次十抽內不知道會不會有三張五星? 目前只有看到雙
10/07 01:46, 64F
→
10/07 02:22, 6年前 , 65F
你要取的物事先在資料庫儲存沒有意義 做成公池沒必要
10/07 02:22, 65F
→
10/07 02:28, 6年前 , 66F
而且抽到卡片應該是產生以使用者區分的資料
10/07 02:28, 66F
→
10/07 02:29, 6年前 , 67F
如果先產生一個某從者的表單 然後玩家抽到就往裡面加
10/07 02:29, 67F
→
10/07 02:31, 6年前 , 68F
那PU的時候伺服器應該要爆 不然就是資料被覆蓋遺失
10/07 02:31, 68F
‣ 更多 LaPass 的文章
文章代碼(AID): #1PrlOdim (TypeMoon)
討論串 (同標題文章)
完整討論串 (本文為第 6 之 8 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 LaPass 的文章
文章代碼(AID): #1PrlOdim (TypeMoon)