Re: [FGO] 石頭回收完了 會顯示負數

[fish770130 (夕提)]

※ 引述《allen20937 (旅行者)》之銘言：
: ※ 引述《seer2525 (月月)》之銘言：
: : 標題: Re: [FGO] 石頭回收完了 會顯示負數
: : 時間: Fri Dec 27 12:57:25 2024
: : 你跟這張圖的主角應該比FGO工程師還厲害
: : https://i.imgur.com/BTC2EYz.png
: : 明明就寫得很清楚
: : 抽之前有償26 無償-149
: : 抽下去會變有償23 無償-149
: : 這就是扣有償啊 看不懂有償無償意思就算了
: : 不會連有跟無都分不出來吧
: 首先我要先澄清這篇文章不是在說實際上FGO就是這樣，我沒玩宇宙神遊也不在乎這件事
: 情到底是真是假。
: 我只是想解釋當某種情況下出現免費石變負數後還越扣越負這種Bug在遊戲程式邏輯上
: 是完全說得通，實際上也有可能會發生。
: 但我沒有說FGO就是這種情況
: 但我沒有說FGO就是這種情況
: 但我沒有說FGO就是這種情況
: 很重要所以說三次，免得有人亂扣帽子說我就是在指宇宙神遊
: 首先要先解釋的是通常這種結果預測的UI顯示出來的數字是工程師預期玩家做了某些動作
: 之後會產生這樣的結果。
: 因為實際上玩家還沒行動，所以一切的數字都只是預測，而不是已成事實的結果。
: 有做過實驗的人都知道吧，預測跟實際出來的結果有差別根本是家常便飯
: (我沒有說這種差別在手遊上很普遍，只是提出這種情況有可能會在現實中發生)
: 假設你身上有免費石A顆，課金石B顆，抽一次要花費X顆好了
: ・UI邏輯
: {
:     如果玩家的免費石A < X
:         顯示:A數量不變，B-X  → 免費石數量不夠，消耗課金石
:         (這邊實際上還要加入檢查課金石數量的條件判斷，但我省略了)
:     否則顯示:A-X，B數量不變 → 滿足一抽需要的數量，優先消耗免費石
: }
: 但像我剛才所說的這充其量只不過是預測，不是實際行動後的結果，實際上要等到玩家按
: 下了按鈕後才會執行轉蛋抽取的程式。
: 10個公司可以寫出11種不同的程式碼，如果有間公司把UI跟轉蛋執行的處理分開來寫的
: 話，可能出現下面這種東西
: ・抽取邏輯
: {
:     如果玩家免費石A >= 0，且 A < X
:         執行:扣除課金石X顆，且抽取轉蛋 → 免費石數量不夠，消耗課金石
:         (一樣省略了課金石的數量判斷)
:     否則執行:扣除免費石X顆，且抽取轉蛋 → 不考慮負數的情況下，A肯定會大於等於X
: }
: 上面兩種邏輯在正常情況下都是可以運作也不會出錯，但如果像這次一樣工程師沒事先
: 考慮到石頭變負數的情況，下面的情況就有問題了，因為免費石A是負的，所以直接執行
: 了下面的扣除免費石X顆且抽取轉蛋的處理。

不好意思小弟是文組，可能不太了解工程師的邏輯

想問一下如果工程師沒有考慮到石頭有負數的可能
為什麼要在判斷式寫if(免費石A >= 0)？

: 所以我說這種情況是「有可能」，不表示宇宙神遊的程式就是這樣寫
: 會不會發生端看工程師怎麼寫，但要說一定不會發生的話那就太過武斷了
: 解Bug的時候自認絕對不會出問題的地方就是問題所在的情況我實在見得太多了
: : 推 nineflower: 笑死，還在凹，你職業是檢察官喔                      12/27 13:14
: 不是，我的職業是遊戲工程師。
: 文章有錯誤的話歡迎指證，絕對不會凹

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.77.68.133 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1735286934.A.3F0.html
推 kaori9993: 正常是直接指定數值類型就好，比如uint這種沒負數的
→ kaori9993: 這樣也不用擔心會發生邏輯錯誤來著，不過這不重要了
推 s1129sss: 因為那行的邏輯只是在判斷免費石夠不夠而已
如果是判斷免費石夠不夠，用免費石A<X就好了吧？
工程師寫的這段
如果玩家免費石A >= 0，且 A < X
不就代表　免費石為正數，且免費石低於X
那麼既然都特地寫條件判斷免費石是否為正數了
為什麼會說沒考慮到變負數的情況？
※ 編輯: fish770130 (60.249.144.164 臺灣), 12/27/2024 16:22:21
推 w77899: 邏輯是有石頭才讓你抽 所以只判斷你石頭夠不夠
→ w77899: 多一個>0是fgo有分有償跟無償石 可能有總體石夠但無償不夠
推 winiS: 問題是有有償石還是可以抽啊=3= 幹嘛if免費石，直接when有
→ winiS: 償或無償就好了，大師就是大師
推 s1129sss: 有寫判斷免費石為正數 不表示考慮到免費石為負數的情況
哦...
我想說寫if(A>=0 and A<X) OOO else XXX
應該會考慮到如果A<0就會去執行else...
→ winiS: 根本不需要在判斷式這樣算正數，事實也是總計負數也給抽
→ s1129sss: 樓上說的對 但現實就是有人可能這樣寫
→ w77899: 這就是上一篇在凹的問題 講自己不是指fgo但一堆前提又直接
→ w77899: 套fgo的情況 混在一起做大雜燴
→ winiS: 當然有可能，但不需要紮個笨蛋稻草人然後打得很開心
→ a125g: 他文章說fgo工程師沒考慮到負數問題 可是圖中石頭明明就有
→ a125g: 扣對 然後開始硬凹
→ winiS: 實際就沒有靶在那邊，也可以嗨~ zz
→ w77899: 表示他自己為了辯自己邏輯都混成一團了
推 yellowhow: 前面不是有說他扣對嗎? 只是有人轉圖講錯
※ 編輯: fish770130 (60.249.144.164 臺灣), 12/27/2024 16:30:46
→ w77899: 他這個例子就是明明自己要舉一個假設 結果扣石頭的想法還
→ winiS: 原圖就沒看到下面列有償無償，只看到上面總計就嗨了
→ yellowhow: 非員工正常也看不到程式碼邏輯，所以沒法確認是怎樣吧
→ w77899: 是套用fgo這種會先扣無償再扣有償的作法
→ winiS: 上車就算了還要搞一篇來假設倒底要怎麼出錯，阿就沒出錯zzz
推 angel6502: 現在才發現原來中午還在爭"有可能"XD  也太歡樂了吧
→ yellowhow: 雖然她們系統爛但也不至於搞到抽抽扣錯石拉
→ AirPenguin: 這也不用通靈吧 結果都出來了還在假設一堆
→ w77899: 宇宙神遊屎的地方有一堆 偏要拿這種有長期營運最不可能出
→ w77899: 錯的地方酸 又雲又蠢被抓到還想顧面子
→ yellowhow: 一般來說有償跟無償石存的欄位不同，不管前面判斷是怎
→ AirPenguin: FGO文日常了 又雲又愛高談闊論酸
→ yellowhow: 樣，不太可能發生抽有償扣無償或者反過來的狀況
→ yellowhow: 除非這程式很久很久之前就寫反了
→ angel6502: 就很有趣  搞錯造謠的都下車了  結果還有人另外開XD
推 winiS: 先不講可能性，但之前每日一有償跟只負無償做得出來，就能
→ w77899: 就硬要扯罷了 現在哪個UI資料不是API傳過來接的 又不是十
→ winiS: 理解公司沒那麼蠢了吧，還可以if那麼多，只能期望他不在我
→ winiS: 玩的遊戲附近
推 w77899: 年前那種還會把資料放在客戶端的
推 s1129sss: 我也只是單純回答這篇的問題
推 oselisdu: 某a: 欸你這個程式output錯了 工程師f:我驗算完沒錯啊,
→ oselisdu: 是不是你看錯output format了 某a:你確定你的output是
→ oselisdu: 正確的嗎?我懷疑你程式邏輯寫錯才造成這個output看起來
→ oselisdu: 是對的 工程師f:所以哪裡有錯你能舉例嗎? 某a:我是說你
→ oselisdu: 有可能會寫錯不是說你真的寫錯啊,你這麼生氣幹嘛 工程
→ oselisdu: 師f:神經病
→ s1129sss: a<0確實會去執行else 但不表示else內執行的是你針對免費
→ yellowhow: 架構老又大的話是可能有些細節或特殊狀況，像這次BUG
→ s1129sss: 石為負時要處理的狀況
→ yellowhow: 但最基本的東西不太可能出問題的，畢竟這一按就知道
→ AirPenguin: 上面那種人還真的遇過 "我過程都對可是結果錯"
→ AirPenguin: "你是怎麼做對的 是不是過程有問題"
→ ARTORIA: 這麼簡單的東西 為什麼可以討論這麼多...
→ Gouda: 因為有沒寫程式的人在談啊 其實邏輯不好面試或試用期就直
→ Gouda: 接篩掉了 聽這些鬼扯邏輯很痛苦