Q&A
> 推奨していない質問
> コードをください・デバッグしてください等の丸投げの質問
> 何かを作りたいのでコードを書いてほしい、学校の課題を解いてほしい等の質問は、
> 具体的にプログラミングで困っている質問ではないと考え、推奨していません。
> 問題や質問は実際に調査や作業に取り組み、具体的なところで生まれると考えるためです。
> まずは実際に作業に取り組み、つまづいたところで投稿をしてみてください。
初めまして。私は学生です。
とあるプログラミングの課題が出て、それの回答を提案してもらいたいのですが可能でしょうか？
質問内容は
とあるゲーム会社にて開発中のプログラムにおいて、1つのint型の変数の値がオーバーフローして不具合の原因になっていることが判明しました。
これに対して変数の型をintからlongに変更することで修正を行ないましたが、その後、新人プログラマーのA君が次のような意見を言いました。
「そもそもint型を使うことのメリットがわかりません。毎回毎回オーバーフローを起こす可能性があるかどうかを気にして変数の型を決めるのは手間ですし、間違って判断すると今回のようにオーバーフローを起こして不具合の要因になってしまいます。それであれば、int型の変数など使わないことにして、すべてlong型で統一したら良いと思うのですが、どうでしょうか？」
【問1】
A君の言うように、もしint型を使わずすべてlong型で統一した場合に生じる問題点を思いつく限り箇条書きにして挙げてください。
※ ストーリーの中で触れられていない内容（開発言語など）は、任意の仮定を行なって構いません。
例えば、「Javaプログラムの場合であれば、○○したときに△△が××する可能性があることが問題」など。
※ 特殊な状況を仮定しても差し支えありませんが、ほとんどのプログラムについて当てはまる一般的な内容をなるべく優先して挙げてください。
宜しくお願い致します。
>プログラミングの課題が出て、それの回答を提案してもらいたいのですが可能でしょうか？
作業依頼に応えるコミュニティではありません。課題なら出題者かお友達に相談してください。
「プログラミングの基礎だ」という認識がありそれでも解けないなら基礎が足りてないということ。
であれば、どんな回答を得ようと理解できないことになります。それが分かっていてアドバイスしたい人はいませんよ。
"int"より"long"の方が文字数が多いではないか．
そんなことをしたらソースのファイルサイズが増えてしまうし，コーディング従事者の腱鞘炎の危険性が増すかもしれない．
Ａ君はまだ新人だから，特に後者側の問題を甘く見ている可能性がある．
棄却すべき意見である．
課題なんだから自分で考えてやんなさいよ。
ま，冗談はさておき……
「long とは何なのか？ int とは何が違うのか？ intをlongに変えたとしたら何がどう変わるというのか？」という事柄をまずは調べてみたらどうか．
やっぱりな無言退会。
作業依頼に答えるサイトではない事を、もっと公で主張した方がいいと思ってます。
（特に広告に、小さくでもいいから注釈出すとか）
回答4件
0
まず、intの大きさが何だったのかという所から考える必要があります。一般的なビットとデータモデルそれぞれのintとlongを見てみましょう。
| ビット | モデル | intサイズ | longサイズ |
|---|---|---|---|
| 16 | - | 16 | 32 |
| 32 | LP32 | 16 | 32 |
| 32 | ILP32 | 32 | 32 |
| 64 | LLP64 | 32 | 32 |
| 64 | LP64 | 32 | 64 |
| 64 | ILP64 | 64 | 64 |
intからlongへ変更することで修正できたいと言うことは、この二つが異なるサイズである必要があり、この中でそうなっているのはLP32とLP64のみです。一般的なx86(32ビット)環境でのよくあるOS(WindowsやLinux)ではILP32なので、LP32はちょっと考えにくいです。そうなるとLP64となりますが、これはx86_64(64ビット)環境のLinuxやMacでのデータモデルですので、十分あり得ます。また、今時のゲーム機(スマホ含む)はARM64なので、この場合でもLP64でおかしくないです。
さてintは32ビット符号付き整数だろうということですが、2の補数でない環境はほぼないので、その大きさは -2,147,483,647 ～ 2,147,483,647 です。20億ぐらいまではオーバーフローしません。ゲームで数が大きいステータスと言えばHPやダメージ量ですが、20億とか普通にたたき出すゲームってディスガイアぐらいでしょうか？いやいや、最近のソシャゲはインフレーション(インフレ)が激しいと聞きます(とあるガンダムのやつとか)ので、すぐに億、兆、京、富岳と大きくなっていくんでしょう。
あ、ここまで来たら気づきましたね。所詮、64ビットにしたところで -9,223,372,036,854,775,808 ～ 9,223,372,036,854,775,807 しか扱えません。たったの900京ぐらいまでしか扱えないのです。ソシャゲじゃないディスガイア6ですら9999京ダメージ出せるようになるそうですから、インフレしないと課金されないようなソシャゲでは京なんて単位では全然足りません。longにしたら全て解決とかちゃんちゃらおかしいです。そんなこというやつは日本一ソフトウェアにでも出向させて、プリニーからやり直しさせるべきですね。
ここは発想を変えるべきです。かつて、ドラクエでは力とかの最大値が255でした。そう、ステータスなど8ビットで十分だったのです。ダメージだって32,767を越えると逆に回復するのが普通だったのです。それでも十分遊べたのです。つまり、(ディスガイアのようなとち狂ったゲームシステムでもない限り)intの大きさはゲームとしては十分であり、それ以上必要になること自体、ゲーム設計のどこかがおかしいといえるのです。
さて、今時のゲーム業界で儲けるにはソシャゲしかありません。ソシャゲにはインフレがつきものです。そう、廃課金者達から金を巻き上げるには、以前よりちょっと強いやつをガチャに出し続けるしかないのです。毎週倍強い奴を出し続けると一年50週で2の50乗倍にステータスは跳ね上がります。longの限界まであと13週しかありません。結局、longで作っても1年とちょっとしか持たないのです。いや、1年ぐらいで消えていくこと前提のソシャゲならlongで十分とも言えます。
しかし、やはりパズドラのように長く続く物を作りたいです。そこで、私が提案するのがステータスのデノミネーション(デノミ)です。
ソシャゲにおいてインフレは止められません。例えば、曲芸士で7倍なんて数字をだしたら、次はより大きい数の倍率のキャラを用意しないとガチャは引いてくれません。そうやっていくと数はどんどん大きくなっていきます。そこで、大きすぎる値はデノミにすればいいのです。それは弱体化だ、ナーフだ、と炎上するのではと思ってませんか？違います。敵もデノミになるので、相対的に強さが変わりません。ただ、単位が変わるだけです。例えば、日本の円について100分の1のデノミをしたとしましょう。1万円札を明日から100円札と呼びことになりますが、その価値はかわりません。買えるパンの数も変わりません。ただ、見た目の数値だけが変わるのがデノミです。
ユーザーには何も影響しませんが、ゲームの内部は劇的に違います。いままでギリギリintで計算できていて、いつおーばーフローしてもおかしくないといった物が余裕で計算できるようになります。わざわざlongに直すなんていらなかったのです。そう、最初に言っていたオーバーフローの対応も、longにするのではなく、ステータスをデノミすることで対応できたということです。
ということで私の提案です。オーバーフローを気にする前に、デノミネーション可能な設計にすべきです。デノミこそが、ソシャゲにおけるインフレを解決する画期的な方法になるに違いありません。そのことに気づかないA君は、とりあえずアイテム神2から最強装備を盗んでから、ゲームにおけるデータサイズについて語ってください。
そうそう、最後にintではなくlongにした場合ですが、今の私の環境は64ビットのWindowsであり、LLP64なので、「何も変わらない」とだけ言っておきます。
投稿2020/10/14 13:09
総合スコア21823
なお、私の住んでいる世界線ではJavaは太陽(Sun)共に滅んだ言語だという認識なので、今さらJavaを使うこと自体があり得ないとして、Javaではないはずと判断しています。また、C#でintはSystem.Int32のエイリアスなので、きっとC#の話だったらSystem.Int32云々とい言っているはずなので、C#の話ではないはずと判断しています。よって、CまたはC++におけるintとlongに違いないと考えました。
整数型のままデノミしたら、初期のキャラの能力値が1を割ってしまう気がします。
初期キャラ同士なら同じように殴り合えないとユーザにももろに影響するような。
初期キャラは捨てて、1日1回無料のプレミアムガチャ(SSR～R)のキャラを使って下さい。なお、次回アップデートで、SRはR、SSRはSR、SSSRはSSRにデノミ予定です。(RのキャラはCとなり、ゴミになります)
なるほど。完璧なゲームバランスですね。
デノミというよりパージじゃないかという気もしますが、常に強いキャラを手に入れられる快感の下では些細な問題です。
0
あえて、直接的には質問の回答とならない範囲で書いていきます。
毎回毎回オーバーフローを起こす可能性があるかどうかを気にして変数の型を決めるのは手間ですし、間違って判断すると今回のようにオーバーフローを起こして不具合の要因になってしまいます。
その考えを突き詰めれば、全部の整数を多倍長整数（メモリが尽きるまで何桁でも演算できる型）にすることになります。Rubyなどそういう実装を行う環境も実在しますが、Javaではその考えは採用されていません（多倍長整数のクラスであるBigIntegerは存在はします）。
投稿2020/10/14 05:27
総合スコア146842
0
まず型の変換は慎重におこなう必要があります。
int <- int の代入だったのが、 long <- int や in <- long になったり
int と int の大小、同値比較が、 long と int の値比較になったときにどうなりか、その変化が
ゲームに影響をあたえないかの検証が必要です。
ビット演算(シフト、and/or マスクなど）をおこなっていたら影響がでる可能性が高いです。
私なら、すぐに
"long 型の変数など使わないことにして、すべてlong long型で統一したら良いと思うのですが..."
とか、
"整数型などつかわないことにして、、すべて String で数値を表したら良いとおもうのですが..."
と対抗案をだします。
質問者さんは、この提案についてはどんな問題があると思いますか？
＊ すべてlong型で統一した場合に生じる問題点
- long で収まらない(オーバーフローする) 値がゲームで必要になったときに同様の問題が発生する。
- プログラムの速度が遅くなる可能性がある。(CPU が 処理するバイト数が増えるから処理は遅くなる)
- CPU発熱が増える可能性がある(処理が増えるから発熱量は増えるかも。そして熱暴走するかもしれない)
- メモリー使用量、プログラムサイズが増える可能性がある。
(ゲーム機搭載メモリーに収まらない、DVD に収まらない、ネットでのデータ通信量が増えて速度低下、通信料増加する) - すべての数値変数が long とわかれば、ハックしやすくなるかもしれない。
- 関数呼び出しのパラメータのスタック使用量が増えるので、スタックサイズ変更が必要になるかもしれない)
- コンパイラの最適化結果が大幅に変化する可能性がある。
(byte, int では小さくて速度が速い命令にコンパイルできたのに、 long ではそれより大きくて遅い命令にコンパイルされる可能性が高い) - コンパイル時間そのものも増えるかもしれない。
投稿2020/10/16 03:11
総合スコア22328
0
そもそも、long型が存在しないから使えない。（PHP）
投稿2020/10/14 05:10
総合スコア10434
> これに対して変数の型をintからlongに変更することで修正を行ないましたが
という話が存在しているので，その範疇での話をしなければならないのでは？と思います．微妙に．
いちおう「Java」がタグにあるのでPHPの話にはできないかと
> ストーリーの中で触れられていない内容（開発言語など）は、任意の仮定を行なって構いません。
とあるので任意の仮定をさせて戴きました。
> intからlongに変更することで修正を行ないました
とストーリーで触れてますのでlongが存在するのが前提かと
あなたの回答
tips
プレビュー
