ゲーム制作　雑談スレ【part39】

**名前は開発中のものです。** · 2025/09/05(金) 05:01:44.13

楽しく雑談しましょう
次スレは>>980が立てる

前スレ
ゲーム制作　雑談スレ【part34】
https://mevius.5ch.net/test/read.cgi/gamedev/1741076201/
ゲーム制作　雑談スレ【part35】
https://mevius.5ch.net/test/read.cgi/gamedev/1743150906/
ゲーム制作　雑談スレ【part36】
https://mevius.5ch.net/test/read.cgi/gamedev/1745938412/
ゲーム制作　雑談スレ【part37】
https://mevius.5ch.net/test/read.cgi/gamedev/1749042367/
ゲーム制作　雑談スレ【part38】
https://mevius.5ch.net/test/read.cgi/gamedev/1752362699/

**名前は開発中のものです。** · 2025/09/05(金) 07:56:39.34

皆で寄生虫berを駆除しようぜ！

**名前は開発中のものです。** · 2025/09/05(金) 09:29:33.27

景気の良い話題頼むぜ

**名前は開発中のものです。** · 2025/09/05(金) 10:29:22.63

たて乙

**名前は開発中のものです。** · 2025/09/05(金) 17:39:49.94

縦100キャラ×横100キャラの広さマップの、11キャラ×11キャラの範囲だけが表示されて
移動に伴いマップがスクロールする、て感じのゲームをpygameで作りたい
ファミコンのドラクエみたいな感じの

マップはその範囲の地形を描画すれば描ける、
スクロールは地形をちょっとずつずらしながら描いていけばできる、
ということは分かった

ただ、表示される範囲だけ・新たに現れる地形を描いていく、というのは、
低スペックなハードではそうする必要があるかもしれないけど
きょうびのPCでそこまでしてやる必要あるのか？という気がしてきた

最初から100キャラ×100キャラの巨大なマップ画像を作成して、
移動にあわせて表示させる位置をずらしていく、という方式をやろうと思ってるのだけど
性能は悪いかもしれないなと

ポピュラーな方法というと、どんなやり方なのだろう

**名前は開発中のものです。** · 2025/09/05(金) 17:49:58.94

pygame はタイルベースのマップをサポートしてるんじゃろ？
普通にそれを使えばいいじゃない

**名前は開発中のものです。** · 2025/09/05(金) 18:29:17.70

性能じゃなくて頭が悪いんだよ

**名前は開発中のものです。** · 2025/09/05(金) 19:07:51.90

必要なのはマップタイルのプーリング
最初から100x100のリソースを読み込んでたら固まるから必要に応じて使い回しと追加
まあ試してぶつかりながら解決していけばいいさ

**名前は開発中のものです。** · 2025/09/05(金) 19:11:18.21

表示される範囲だけ・新たに現れる地形を描いていく、これがもっとも多くのドラクエ風ゲームで用いられているポピュラーな方法です。
お役に立ちましたか？　今後のご活躍をお祈り申し上げます。

**名前は開発中のものです。** · 2025/09/05(金) 20:16:06.73

>>5
認識が間違ってるよ
後者のほうが処理軽い
そして当然のことながら後者がポピュラー

**名前は開発中のものです。** · 2025/09/05(金) 21:49:34.25

>>10
流石にそれは無い。100×100が11×11になるんだったら、単純計算でも処理が1/81になる

**名前は開発中のものです。** · 2025/09/05(金) 22:01:59.73

いまどき珍しいものを実装したいのにポピュラーさに頼るのってなんか勿体ないな

**名前は開発中のものです。** · 2025/09/05(金) 22:17:30.00

4K画像一枚絵で、タイルではできないマップを作りたいなら、それも面白そう
絵を描ける人じゃないとできないけど

**名前は開発中のものです。** · 2025/09/05(金) 22:17:38.07

>>11
描画処理を知らんのだな
ゲームみたいな動的映像は常に全領域再描画してるんだよ
11x11の領域しか再描画しなくていいなんて状況にはならない

**名前は開発中のものです。** · 2025/09/05(金) 22:24:59.27

最近はハードのスペックに頼りすぎて最適化のノウハウが積めないらしいな
UE製のコンシューマゲームとか酷過ぎるとか論争になってる

**名前は開発中のものです。** · 2025/09/05(金) 22:48:26.13

クソスペPCだし考えざるを得ない
まあ業界に入れるやつは金持ちなんだろうな

**名前は開発中のものです。** · 2025/09/05(金) 22:50:08.65

>>11
いや違うな
君は話そのものを何か勘違いしてるね
11x11を描画するか100x100を描画するかって話じゃないから
そもそもの>>5君のレスがちょっと意味不明な感じあるけど

**名前は開発中のものです。** · 2025/09/05(金) 22:58:34.11

>>5君が言ってるのは
描画領域外のマップを事前に保持してるかどうかの違いでしかないので
描画領域内に入るたびに描画処理する前者より
事前に裏で描画してある領域を表示するだけでいい後者のほうが当然軽い

**名前は開発中のものです。** · 2025/09/05(金) 23:10:03.40

LODは

**名前は開発中のものです。** · 2025/09/06(土) 01:48:37.59

A. 巨大なマップ全体を描画してスクロールする
100×100 キャラ → タイルサイズを 32px としても 3200×3200 ピクセルの画像。現代のPCではこの程度は余裕。
移動に合わせて Surface.blit() の描画位置をずらせば済むのでシンプル。メモリ的にも、数十MB程度なので pygame では問題にならない。

B. 毎フレーム「必要な範囲だけ」タイルを描画する
画面に見えているのは 11×11=121 タイルだけ。
毎フレームこの121枚を描画すればOK。効率的なやり方だけど、現代でも「マップが数千×数千タイル級」になるなら有利。

C. ハイブリッド
マップはデータ（2次元配列など）として持ち、画面更新のたびに「視界に入る部分だけタイル画像を描画」。
ほとんどのタイルベースのゲームエンジンがこの方式。タイル数が大きくても、画面に描画するタイル数は固定なので、性能は安定する。

AでもいけるがBCをつかう。

**名前は開発中のものです。** · 2025/09/06(土) 03:22:27.01

>>14
行ってることイミフ。毎フレーム全描画してるのはその通りだが、エンジンが内部で視野外カリングしてくれなかったら、全タイル描画は尚更重くなる
最近の低レベル描画エンジンは視野外をカリングしてくれるとはいえ、それでも100×100の内の11×11に限定すれば付随処理は1/81になる

>>18
裏で描画とかイミフ。上でも言ったが内部では毎フレーム、画面バッファをクリアして視野内を全部レンダリングし直している
マップ用テクスチャをあらかじめ描画しておいてゲームシーンで使い回すにしても、テクスチャサイズには限界がある。最近の高解像タイルには不向き

**名前は開発中のものです。** · 2025/09/06(土) 05:27:59.38

>5　固定のドラクエ固定マップ、テラリアのプロシージャルなマップ、リアルタイムステラテジーのマップ、自由に地形を変えれるマップを作りたいとかで作り方かわるから回答者が困らないようにもう少し情報くれた方がいい。

**名前は開発中のものです。** · 2025/09/06(土) 07:55:45.65

ピープホール型RPGという用語すら知らん奴らおるんか

**名前は開発中のものです。** · 2025/09/06(土) 09:12:16.26

才能の無いゴミがピーピー泣いてて草ｗ

**名前は開発中のものです。** · 2025/09/06(土) 09:30:33.97

>>21
部分描画も事前描画も知らないのはゲーム製作者として致命的では？
サイズがでかすぎるなら分割してメモリに保持してればいいだけ

**名前は開発中のものです。** · 2025/09/06(土) 09:45:37.47

100x100←マップサイズ
11x11←描画サイズ

この場合事前に描画した100x100のマップの必要な11x11領域をくり抜いて毎フレーム描画するんだから
余計な処理はしてないからカリングなんか必要ないし
1/81とか言われても何言ってるんだかって感じ

静的マップを事前に保持しないで毎フレームいちいち描画してたら描画回数が1回から121回(11x11)に爆増するだろ
ドット絵のくせに何でこんなに重いんだよ！って最適化不足ゲームの出来上がり

**名前は開発中のものです。** · 2025/09/06(土) 09:48:37.49

普通にゲーム作っててこんなアホな実装するわけないので
結局は話をよく理解してなくて何か勘違いしてるだけだね

**名前は開発中のものです。** · 2025/09/06(土) 10:17:46.86

質問者のPygameの練習で低ドットの迷路とか作るレベルじゃないのかな。
いつまでも揉めてないで、自作ゲームを自分のポリシーに沿って最適化すればいいんだよ。

**名前は開発中のものです。** · 2025/09/06(土) 11:11:18.34

質問した人は質問だけして消えたけど
話理解してない人が横から絡んできたんだから仕方ない

**名前は開発中のものです。** · 2025/09/06(土) 11:14:37.90

Unityででっかいマップを作った時って描画はカメラに応じて最小限になってんのかな

**名前は開発中のものです。** · 2025/09/06(土) 12:05:45.30

レンダリングパイプラインってのを調べるといい
そもそも上でもめてる内部処理と画面に表示されてるもの（たぶんお前が描画といってるのがここでごっちゃになってる）は別だから、その辺も含めて勉強するといい、隙間時間でも2週間くらいやれば理解できるだろ
基礎中の基礎だから、ここが自習できない理解できないわかんないならゲ製は無理マジでアキラメロン

**名前は開発中のものです。** · 2025/09/06(土) 12:51:08.18

まあこの程度のことを聞いてるって事は１枚絵だけじゃなくてキャラとかも全部100x100に乗せそうだから
画像１枚をスクロール描画するとかという前提での議論は無意味だよ

**名前は開発中のものです。** · 2025/09/06(土) 12:51:36.87

>理解できないわかんないならゲ製は無理マジでアキラメロン

流石に一言余計。忍者といい地罰信者といいマウント取りたいだけの人がいるなぁ

**名前は開発中のものです。** · 2025/09/06(土) 12:54:55.86

絡んでこられてもスルーが吉。息抜きの雑談スレで無駄な体力使うことない

**名前は開発中のものです。** · 2025/09/06(土) 13:28:04.34

>>20のＡが重いか軽いかという話なら、やっぱり>>20のＡの方が処理としては重いだろ
マップタイルを描画する場合、全体マップのテクスチャを使っても使わなくても、いずれにせよ描画コールは１回だけで済む。デカいテクスチャを使う方が重い
そもそも数千px四方に納まる全体マップという条件が特殊過ぎるので、レトロ作風か習作にしか通用しない。横に１画面程度スクロールさせるだけで世界の端かよｗ
反対に全体マップが数千px四方程度なら細かいこと気にせず、全体マップも作成せず、低レベルの視野外カリングに任せて、毎フレーム100×100描画で無問題

**名前は開発中のものです。** · 2025/09/06(土) 13:48:19.38

今のハードウェアなら、2Dスクロールなんか大した問題じゃない
誰か、PC8801SR でパララックススクロールを実装する技術でシメてくれ

**名前は開発中のものです。** · 2025/09/06(土) 13:49:14.31

>>35
いやその人の例えならBのほうが重いよ
GPU負荷はどっちも同じで気にするほどの誤差は出ない
大量のドローコールによるCPU負荷が段違い
描画以外にもCPU処理は必要だから間違いなくBは次第にフレームレートが稼げなくなる
アホなこと考えてないで両方実装して試してみなよ

**名前は開発中のものです。** · 2025/09/06(土) 13:58:12.33

>>37
だからドローコールはどちらも１回だと言ってるだろ。テクスチャサイズの方がネックとしてデカい

**名前は開発中のものです。** · 2025/09/06(土) 13:59:07.38

>>37
アホアホうるせえんだよ、このアホが。お前が試せｗ

**名前は開発中のものです。** · 2025/09/06(土) 14:10:48.91

>>38
どちらも一回なんてありえないだろ
Bは全チップをチップ枚数分描画してるんだよ
ドローコールはAが1回でBは121回
お前の仮定がおかしい

つまり話を何にも理解してない

ゲーム制作 雑談スレ【part39】

ゲーム制作　雑談スレ【part39】