max damage 的最大值 - 神魔之塔

Table of Contents

手機回文

印象中好像在板上看過不少次相關討論了
覺得好像可以來簡易科普一下
不知道發了會不會有點掃興,不過還是簡介一下

關於算術這件事情,其實就理論而言都很理想跟直觀
但真的牽扯到實作的時候,就會衍生很多細節
先來簡單舉個例子:

假設現在要做算術運算,而你只有一張紙
上面只有10個格子,而且你只能寫下0-9

最直觀的方法就是寫下多少就是對應的十位數整數
然後此時就可以推論出一些限制:
1. 範圍為0-9999999999的整數

然後就會問說,那負的怎麼辦?
所以我們把第一格寫1表示負0表示正
於是範圍變成 -999999999~999999999
雖然可以表示負數了,但最大值也被壓縮

但可能目前實務上不太可能超出上下界
於是乎開發人員就這麼決定了表示式

而過了好幾年,數字運算上開始會有超出範圍的需求
可能就會有人提出建議
「用科學記號不就好了,國中沒畢業嗎?」

好的,於是我們改變表示式的定義:
前八碼為科學記號前面的數字,後兩碼為10的次方
比方說 1 2 3 4 5 6 7 8 9 9 表示 1.2345678 * 10^99
若是有負的需求就再讓一格,而這樣改進以後
上下界的範圍被大大提升了,感謝這位聰明的先知
其實類似的概念就是變數型態裡面的浮點數

而為什麼這麼簡單的道理人家卻不採用呢?
現在我們回來思考一個問題:

以上述例子而言,表示式是怎麼對應到值域內的?

十個格子,無論怎麼表示,都最多只能表示100億個數字
而只有整數表示是可以在範圍內全部列舉的
這也是浮點數運算一個危險的地方,精準度

對電腦運算上,(1e50+1) - (1e50) 答案可能不會是 1
通常浮點數也是拿來算個近似值而已
以算傷害的需求而言我想並不太適當


最後做個總結:
1. 數值運算有上下界是因為實作限制
2. 整數運算較具有精準性


但回歸目前的使用狀況,要能不怕超出範圍也不是不可能
定義一個變數型態,然後覆寫四則運算及比較邏輯
讓它可以動態擴張自己的記憶體大小應該就可以達成

畢竟怪的血量目前不會超出int的範疇,而是否打死也只是一個比較邏輯而已



-----
Sent from JPTT on my Google Pixel 2.

--

All Comments

Enid avatarEnid2018-08-27
如果傷害沒有膨脹這麼多應該比較不會有這種問題
Cara avatarCara2018-08-28
好像在看我同事的code review 長篇大論一長串(讚美)
Margaret avatarMargaret2018-08-31
推一個 不然別人以為我看不懂
Blanche avatarBlanche2018-09-04
長知識了
Carol avatarCarol2018-09-07
我是覺得不錯啦樓下怎麼看
Andy avatarAndy2018-09-10
所以為什麼要用int而不用跟實際傷害顯示一樣的code
Jack avatarJack2018-09-11
我幫樓下問有沒有文組版本
Skylar Davis avatarSkylar Davis2018-09-16
推一個假裝自己看得懂
Regina avatarRegina2018-09-20
嗯嗯,跟我想的差不多
Adele avatarAdele2018-09-22
他是說小字已經可以顯示超過21e,max damage卻還是用int
Daph Bay avatarDaph Bay2018-09-22
長姿勢了!!
Vanessa avatarVanessa2018-09-24
文組問個,為啥堅持要用int 不用long long之類的
Kelly avatarKelly2018-09-28
跟資源規劃有點關係,傷害值的資料型態在非常早期就
必須決定,那時無法預測傷害的範圍,為了不知多遠的
將來(誰知道這遊戲活這麼久?)先把傷害值的資料型態
調整成 long 甚至更大範圍,只是浪費手機的資源而已
,因為即使數字很小,花費的空間都是相同的。極端一
點來說,甚至有可能因為這樣的資源浪費,造成某些較
低階的手機無法進行遊戲。
Annie avatarAnnie2018-09-28
以一個大型project來說,底層的code基本都沒什麼人想
動,因為很容易搞出大問題,比較經典的例子,應該是W
oW(魔獸世界)的16格包包問題,有興趣的話可以查查看
Odelette avatarOdelette2018-09-28
自己寫個物件然後overload實作operator = =?
Yuri avatarYuri2018-09-29
會造成這樣的原因很簡單 code不是一個人maintain的
Heather avatarHeather2018-10-02
有些東西就是牽扯太多不好改
Andrew avatarAndrew2018-10-04
因為不同資料型態之間運算容易出錯,能避免是最好
Emily avatarEmily2018-10-06
沒錯,你把我想講的全部講完了
Queena avatarQueena2018-10-09
推專業
Linda avatarLinda2018-10-10
快推免得别人以為我們看不懂
Poppy avatarPoppy2018-10-11
應該很快就會有21億血量的怪,然後21億的防禦,再無視破防..
Ingrid avatarIngrid2018-10-13
假借科普 偷鞭科學記號
Edward Lewis avatarEdward Lewis2018-10-15
英文系畢業表示完全看不懂
Oscar avatarOscar2018-10-17
無視破防? 傷害盾不就是了嗎?
Jack avatarJack2018-10-20
不太一樣。防禦力是牆(低於防禦傷害為0),傷害盾是比例弱化
Audriana avatarAudriana2018-10-21
資工系大一C語言就教了
Faithe avatarFaithe2018-10-23
推 不明覺厲
Suhail Hany avatarSuhail Hany2018-10-27
好奇這種手遊都是用C實作的嗎?我學的code很多都不用
自己宣告變數型態
Callum avatarCallum2018-10-30
左轉code板
Oliver avatarOliver2018-11-01
看不懂。先推
Candice avatarCandice2018-11-02
其實就是太多了難改 但這個功能應該比小字的晚吧 小字都用
大數存了 max damage沒辦法很怪
Eden avatarEden2018-11-06
整數用int真的很直覺 更何況還比long好打多了 打long還
要動到無名指 超不方便 ㄎ
Damian avatarDamian2018-11-10
new int[1000];
Robert avatarRobert2018-11-14
還特別幫那個科學記號同學釋疑,推個
Jessica avatarJessica2018-11-18
進位簡單啦 MCU的資料都是兩個8接一起 只是這樣寫有浪
Mary avatarMary2018-11-21
費空間的嫌疑
Cara avatarCara2018-11-26
資料沒大到需要封裝 這樣接不是很好
Oscar avatarOscar2018-11-28
嗯嗯跟我想得一樣
Kama avatarKama2018-11-30
對於會寫出風暴這種智障技能的工程師,我是不會指望他們
能把事情做得多好啦
Victoria avatarVictoria2018-12-02
這是歷史共業
Brianna avatarBrianna2018-12-05
其實有個很實際的考量,就是畫面長度
在畫UI的時候,上面能夠提供寫數字的範圍是有限的,
Hedda avatarHedda2018-12-07
位數增加時勢必會讓字體變小或是其他狀況,導致UI效果差
你看他在寫超過21e的時候並不是overflow,表示工程師有考慮
Daph Bay avatarDaph Bay2018-12-09
超過時的狀況,評估結果後捨棄精準的數字 反正這數字只是爽
Ida avatarIda2018-12-12
這樣的UI設計理念事實上很清楚也很簡單
Kumar avatarKumar2018-12-12
我想樓上是對的 畢竟沒有overflow
Kelly avatarKelly2018-12-14
當然 當你的Data因原先的Container總是會有不正常行為
Megan avatarMegan2018-12-19
本來就需要繼承或定義新的物件來封裝
不過我覺得這玩意不太會造成UserConfuse/異常終止
Gilbert avatarGilbert2018-12-22
也不用這麼認真啦 XD
Faithe avatarFaithe2018-12-23
但認真覺得他們工程師蠻混的就是
Brianna avatarBrianna2018-12-23
這篇好認真 推一個
Lauren avatarLauren2018-12-27
快推 不然別人以為我們看不懂
Kama avatarKama2018-12-31
https://i.imgur.com/69edHi4.jpg 支援超過21億的圖
Ingrid avatarIngrid2019-01-04
Una avatarUna2019-01-07
哈哈 小字的 我暫無存w