ゲーム制作　雑談スレ【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(金) 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回
お前の仮定がおかしい

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

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

まだ地罰の話してたほうが平和だったなｗ
質問した奴もほくそ笑んでることだろう

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

喧嘩するなよ。俺が判定してやるよ３２Pixの場合
～100×100 タイル（3200×3200 px）Aが有利（blit 1回 vs 400回）
300×300 ～ → B/Cに移行するのがおすすめ。

128PIXの場合　100X100でAは現実的じゃない。
想定するピクセルがわからない時点で喧嘩しても意味ないぜ

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

>>40
つ　例：glDrawElements
何も理解してなさすぎワロタ

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

>>42
失礼だな！喧嘩腰なのは奴の方だぞ

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

>>43 Pygame単体でタイル描画してるなら → glDrawElements とは無関係だよ。

君は PyOpenGL + pygame(OpenGLモード) で glDrawElements を使えといってるのだろうが、そもそも質問者はそのレベルにいないよ。

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

>>42
Aをマップ画像をゲームフォルダに入れとくことを言ってるなら
そんなの最初から考慮しないでしょ
そのうちファイルサイズえらいことなるじゃん
最初から>>5の後者がCでしょ
視界に入る部分だけってのがどの範囲なのかよく分からないけど

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

せっかくの週末にレベルの低い話をするなよ
こんなのは「好きに作れ」が答えだろ

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

そのとおりだよ。質問に対して「俺ならこうする」だけでいい。
質問者はお礼を言ってその中でいいと思ったやり方で作ればいい

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

https://pbs.twimg.com/media/G0JLSr4a0AAHTZY.jpg
https://pbs.twimg.com/media/G0JLUtQawAAd_xV.jpg
カメラ範囲だけの処理にとどめてくれる機能はpygameにはないらしい
unityにはある
pygameで作るなら昔ながらのc言語のゲームの作り方で作る必要がある
2000年代によくあったゲーム制作本にはそのやり方結構載ってた

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

>>49
pygameは知らんけど、どんな低レベル描画エンジン使ってるにしろ、低レベル描画エンジンがカリングしてくれるだろ

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

>>50
ChatGPTによればpygameはないんだって

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

＞pygameは知らんけど

いままでの論争はなんだったんだ。

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

>>45
「こんな所にS級が？！」とかあるあるやん

・・・アニメでは

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

>>51
Pythonスクリプト層内での低レベルAPIへの描画コールは間引かれない（APIコールしても低レベルAPI内では間引かれるかも）、て意味じゃないの？知らんけど

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

>>54
https://pbs.twimg.com/media/G0KCf9ja4AAhQ5i.jpg
だそうです
ChatGPTの答えはノー

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

そんなにChatGPT が得意なら、pygame のタイルマップのシステムをサクッと作ったら？
たぶん、どこかからコピペしてくるよ

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

>>56
俺は野球ボーイで上の者ではない
上の者は上の者で自力で頑張ってください

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

>>55
平行線だな。低レベルの描画エンジンが視野外カリング・テストを行わないのは考えられない
だから俺は、そのLLMの回答はPythonスクリプトレイヤの話だ、と言っている

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

今週もよく進んだ
着実にBlenderに近づいてる
https://i.imgur.com/8I6EYjF.png
https://i.imgur.com/slj6d5E.png
https://i.imgur.com/38nLSIk.png
https://i.imgur.com/rQtAE6V.png

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

これからは質問されたらChatGPTに投げたほうがいいかもな
どうせ荒らしだろうし

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

>>55
チャッピーに騙された可哀想な人がいる……
もう一度これで質問してみ？

Q: 以下の問いについて事実に基づいた解説をせよ。
1. pygameのSurface.blit() は、ソースのピクセルをdest Surfaceに転写する処理である。
2. この転写時にソースが出力先の範囲を超える場合、その領域は自動的にクリッピングされ、省略される。
3. ソースと出力先が完全に重ならない場合、描画処理は行われず内部的に早期リターンされる。

**名前は開発中のものです。** · 2025/09/07(日) 00:45:01.10

野球マンは、Unity使いなんだし朝から同じ話題に辟易してChatGptで調べただけだから、別にPygameがNinateやLumen使えてもどうでもいいだろう。

**名前は開発中のものです。** · 2025/09/07(日) 00:54:55.61

GoogleGeminiで聞いてみたよ

カリングとblit()の最適化
「カリング」という用語は、一般的にゲーム開発において、描画パイプライン全体で不要なオブジェクトを描画リストから除外する手法を指します。これには、フラスタムカリング（カメラの視錐台の外にあるオブジェクトを無視する）、オクルージョンカリング（他のオブジェクトに隠れて見えないオブジェクトを無視する）などが含まれます。
PygameのSurface.blit()は、このような広義のカリング機能自体は提供していません。つまり、開発者が自分でオブジェクトの座標を確認し、画面外にある場合は描画関数を呼ばないように制御する必要があります。
しかし、以前の回答で述べた「早期リターン」の機能は、blit()関数内部で行われる描画処理の最適化です。これは、特定の描画命令（この場合はblit()）の引数（ソースとデスティネーション）が描画対象として無効である場合に、GPUやCPUへの負荷をかけずに処理を終了させるためのものです。
まとめ
Pygame自体が、シーン全体の不要なオブジェクトを自動的に描画リストから除外するような、高度なカリング機能は提供していない
blit()の内部最適化：blit()関数は、引数で渡されたソースとデスティネーションの矩形が重ならない場合、内部的にピクセル転送処理をスキップするという最適化を行っています。
これは、Pygameの描画関数の効率を高めるための実装レベルの工夫であり、広義の「カリング」機能とは異なります。

**名前は開発中のものです。** · 2025/09/07(日) 01:09:06.63

すでに5の質問とはかけ離れてるし、平行線で続けて長くなるんなら別スレ作れば？

**名前は開発中のものです。** · 2025/09/07(日) 01:30:11.02

最後にABCをGeminiに質問してみた
100X100　32Pix
A. 巨大なマップ全体を描画してスクロールする:3200x3200ピクセルの巨大なSurface（マップ全体）をメモリに作成し、そのSurfaceの描画位置をずらすことでスクロールを実現します。
描画負荷: 非常に軽い。画面に表示されるのは、その巨大なSurfaceの一部を切り取って描画するだけなので、CPUやGPUへの負荷は最小限です。
メモリ負荷: 非常に重い。3200x3200ピクセルの画像は、約40MBのメモリを消費します（RGBA形式の場合）。現代のPCでは余裕の範囲ですが、ゲーム全体のメモリ使用量によっては問題になる可能性があります。
今回のようにマップサイズが固定されている場合、最もシンプルでパフォーマンスが安定します。実装も非常に簡単なので、手軽にゲームを作りたい場合に最適です。

B. 毎フレーム「必要な範囲だけ」タイルを描画する。画面に見えている11x11タイル（121枚）を、マップデータから読み取って毎フレーム個別に描画します。
描画負荷: 毎フレーム121回のSurface.blit()呼び出しが発生します。メモリ負荷: 最小限。各タイルの画像データのみをメモリに保持すれば済みます。
今回の規模（100x100タイル）であれば、A方式と比較して目に見えるパフォーマンスの差は出ないでしょう。しかし、blit()の呼び出し回数が多いため、わずかにCPUへの負荷が高くなる可能性があります。

C. ハイブリッド
B方式とほぼ同じです。マップをデータとして保持し、画面に表示される部分だけを描画します。マップデータを配列として持つことで、ゲームロジックとの連携（例：タイルごとのイベント）が非常に簡単になります。
今回の規模であればB方式と性能差はありませんが、プロシージャルダンジョンなどゲーム開発のベストプラクティスとして最も推奨される方法です。

**名前は開発中のものです。** · 2025/09/07(日) 01:31:40.81

Geminiの総括
最終的な結論と最適な選択肢
100x100タイルの規模であれば、A方式とC方式はどちらも十分に高性能です。
手軽さ、シンプルさを最優先するなら「A方式」
巨大なSurfaceを最初に1回だけ作成すれば、あとはblit()のオフセットを調整するだけで済みます。コードが非常にシンプルになります。
拡張性、将来的な複雑なゲームシステムを考えるなら「C方式」
マップデータが配列として存在するため、ゲームの規模が大きくなったり、タイルごとに異なるプロパティ（通行可能か、イベントが発生するかなど）を持たせる場合に柔軟に対応できます。
どちらの方式も今回の条件では問題なく動作するため、あなたのゲームの要件や実装の好みで選ぶと良いでしょう。

**名前は開発中のものです。** · 2025/09/07(日) 02:09:34.75

Geminiに聞いたことをコピペして意味なんか無いから
お前は荒らし

**名前は開発中のものです。** · 2025/09/07(日) 02:19:50.05

のたうちまわった末に出てきた歪なうんこ、みたいな回答

**名前は開発中のものです。** · 2025/09/07(日) 04:34:32.88

AIの回答は質問者のレベル以上にはならないってのがはっきり分かるなぁ

**名前は開発中のものです。** · 2025/09/07(日) 06:56:06.71

一気に60ぐらいスレ進んだな。忍者みたいなのがいるのか

**名前は開発中のものです。** · 2025/09/07(日) 10:53:25.58

>>61
問いになってないと思うのだが

**名前は開発中のものです。** · 2025/09/07(日) 11:34:25.09

この時代に2Dスクロールが問題になるとはなぁ

**名前は開発中のものです。** · 2025/09/07(日) 12:01:46.10

2DLODによって
例えば32pixel*32pixelの画像が
画面の端に行くにしたがって
16*16, 8*8, 4*4,2*2の画像に置き換わる
これによってテクスチャ使用料は大幅に下がり
VRAMをより自由に使うことが可能になる
ドローコールは80%以上下がる計算だ
人間は画面のプレイヤーを表示する中心点の周りしか見ないため
このような技術を使っても実際の見た目はプレイ感ほぼ変わらずできる

**名前は開発中のものです。** · 2025/09/07(日) 12:36:54.18

# 低評価のレビュー

画面の端に向かって何故かボヤけが強くなっていくというバグがあって製作者に問い合わせしましたが、泥コーラがどうのこうのと意味不明な説明をされ、さらに見た目はほぼ変わらないので対応できないと返信がありました。
そのため即返金要求しました。
この製作者からは二度と購入しません。

こうなるだけだぞ、余計な最適化はすんな、もう一度言う、無駄な最適化はすんな

**名前は開発中のものです。** · 2025/09/07(日) 12:48:36.25

中心窩レンダリングかぁ？

**名前は開発中のものです。** · 2025/09/07(日) 12:57:46.12

https://imgur.com/oNax2ZA
pythonでゲームを作ったよ
でもデプロイ先がねーよ（公開するほどのクオリティでもないけど）
やっぱりフリゲはUnityRoomに落ち着くな

**名前は開発中のものです。** · 2025/09/07(日) 14:23:23.48

>>74
急に泥コーラとか言われてもこっちだって分からんよ
単純に実装がバグってるけど開発者がアホだから直せないだけでしょ
それ最適化と何の関係があるの？

**名前は開発中のものです。** · 2025/09/07(日) 14:41:29.07

君はROMってなさい

**名前は開発中のものです。** · 2025/09/07(日) 15:32:40.61

>>74は悪ノリレスであって
どう見たってこれがマジレスなわけないだろ
気付かないのはゲ製エアプだけだよ
これに対してそんなことしたらこうなるだけだ
余計な最適化はすんなもう一回言うぞとかクサすぎるでしょ

**名前は開発中のものです。** · 2025/09/07(日) 15:36:06.71

>>74
>>73は悪ノリレスであって
の間違い

こんな意味不明な実装するやつ世の中に一人もいないよ

**名前は開発中のものです。** · 2025/09/07(日) 16:17:43.49

３Dカメラで写実的に見せるためにDirtLense（レンズ汚れ）、VignetteやChroma AberrationとかＤＯＦあたりをPostEffectsしたんでしょ
ポストエフェクトマテリアルは解像度で調整してないと４Kモニタでアウトラインが細くなったり見た目変わるから注意な

**名前は開発中のものです。** · 2025/09/07(日) 16:22:13.46

>>76　完成おめでとう。itchIoあたりにアップロードしてくれれば遊ぶよ

**名前は開発中のものです。** · 2025/09/08(月) 03:58:28.50

市販のフィルターも画面サイズで見た目変わるのあるから結局自分で書くようになるね。

**名前は開発中のものです。** · 2025/09/09(火) 21:22:29.28

『レポ with 館山4人衆2』
▽雑談→Steam
協力型ホラーゲーム「R.E.P.O.」
×UNKちゃん×布団ちゃん(活動休止中)
×天狗ちゃん×よっちゃん

ttps://iplogger.info/2TU4H7.tv

**名前は開発中のものです。** · 2025/09/10(水) 00:48:07.52

ミラー編集機能作れた
https://i.imgur.com/XR3jQag.png
https://i.imgur.com/a3eRl6z.png
https://i.imgur.com/Yk0cO7d.png

**名前は開発中のものです。** · 2025/09/10(水) 08:29:59.69

>>85
それいずれ公開するん？
それとも自作エンジンの中で動的にオブジェクト作ったりするため？

**名前は開発中のものです。** · 2025/09/10(水) 10:20:18.53

>>86
公開はしないかな
公開するとなると別の労力が必要だしメリットを感じない
エンジンを作る方が優先

**名前は開発中のものです。** · 2025/09/10(水) 14:36:59.09

>>87
そらそうか
エディタの公開なんて無料は民度の問題で、有料は責任の問題で地獄の道だもんな

**名前は開発中のものです。** · 2025/09/11(木) 09:40:51.68

Unity6でビルドした時に無料でもロゴ出さなくて良くなったらしい

**名前は開発中のものです。** · 2025/09/11(木) 12:24:50.63

ワイはSteamで公開手続き中や
みんな遊んでくれよな

**名前は開発中のものです。** · 2025/09/11(木) 12:56:10.52

ええね
Nextフェスに間に合うんか？

**名前は開発中のものです。** · 2025/09/11(木) 13:05:20.24

日記
インディーゲームの開発規模のカテゴライズでほぼソロ開発は『keiゲーム』って呼ぶってどうよって記事みかけたわ
『軽』自動車の『kei』なんだっておもろ
そしてこの規模のゲームが星の数ほど出てるけどほとんど利益が上がらず世紀末の様相を呈しているらしい、まあ納得

**名前は開発中のものです。** · 2025/09/11(木) 13:17:31.17

Youtubeとかで検索すると素人が１～３ヶ月でゲーム作って売ってみましたってのが多いな
Steamのデータベースが汚れるからそんなゴミを売るなよ。と思う
まあゲーム界の軽自動車と言われるのも納得

**名前は開発中のものです。** · 2025/09/11(木) 16:17:48.68

個人だとフリゲと変わらない出来だろうし、とっくにSteamは「出せば勝手に売れる」場所ではなくなっていて埋もれるよなぁ。
面倒くさかったらパブリッシャーに任せてゲームに注力するという手もあるが、慈善事業で無いので普通の出来だと契約は出来ないし。

**名前は開発中のものです。** · 2025/09/11(木) 20:43:04.79

パブリッシャーが口出してきたりもするので完全に注力できるかと言うとまたそれも難しいんよな

**名前は開発中のものです。** · 2025/09/11(木) 20:51:20.57

絵がイイのべるげーはうれるっしょ

**名前は開発中のものです。** · 2025/09/11(木) 21:01:37.07

じゃああんでひぐらしはうれたんですか？

**名前は開発中のものです。** · 2025/09/11(木) 21:02:15.03

ゆうて組織が作ったゲームも薄利多売でゲ製以外のネタでしのいでいて、社畜奴隷どもは魂に妬み・嫉み・僻み・やっかみしか残ってない実質世紀末だろｗｗｗ

**名前は開発中のものです。** · 2025/09/11(木) 21:15:19.02

>>94
Unity Roomレベルの習作をSteamで販売して「売れないぢゃん！！」ってキレるのは違うと思うが…

**名前は開発中のものです。** · 2025/09/11(木) 22:02:23.44

ゴミがあるからこそ良作や名作が輝くし、ゴミがあることでまともに作られたゲームの良質さがわかるってもんだ
ゴミらしく引き立て役として徹するなら売っても問題はないだろう

**名前は開発中のものです。** · 2025/09/12(金) 02:03:01.37

keiゲームとかそんな回りくどい造語じゃなく粗製でええんちゃう
んで個人ゲーム＝粗製のイメージって、だいぶ怪しい立場の意見でしょ
なぜなら制作者なら普通は俺はあいつらとは違うけどねってなるので

**名前は開発中のものです。** · 2025/09/12(金) 08:31:29.36

UnityRoomとかで定番人気の作品見るといわゆるクリッカー放置系なんだよね
リソースが時間で貯まるとかスタミナがあるとかは強力にユーザーを引き戻すんだなあと実感させられる
でも…
プレイ動機が「もったいない」なのって個人的には嫌い
嫌い！

**名前は開発中のものです。** · 2025/09/12(金) 10:50:26.97

もったいないというか、ライブゲームの原点は習慣にできるかどうかだと思うんだよな
自分はもう（特にオンラインゲームは）デイリータスクないとログインするモチベーションすら維持できないって実感してるわ

オフラインだとストーリーとか目標や終わりがあるけどさぁ
でも、オフラインゲームにデイリータスクって意味があるかどうかだよなぁ、恋愛シミュ系とかはお誕生日イベントとかはあるよな
あー、日常シミュとかはライブゲームに近いかもしれないな

**名前は開発中のものです。** · 2025/09/12(金) 13:16:37.20

数多くプレイしてもらうのならいい選択と思うけど、
Steam等の有料ゲームランキングを見るとわかると思うけどそれらは金出してまで遊びたい思う人はいない。
無料のクリックゲー放置ゲーは大衆がひまつぶしで遊んでいる。ソシャゲは課金させて金を巻き上げてるだけ

金を出してくれる人向けにゲームをつくりたいならブラウザの人気ランキングとか参考にしないほうがいい

**名前は開発中のものです。** · 2025/09/12(金) 13:35:17.92

自分はもったいない精神でゲームをさせられるのが嫌でスマホでも有料アプリしか手を出さなかったんだが
最近有料アプリも平然と放置育成要素突っ込んできて違う望んでいないってなる
ケムコのRPGおまえや

**名前は開発中のものです。** · 2025/09/12(金) 13:38:49.12

まあ、ランキングにも参考にすべき部分としない方がいい部分はあるわな
それは各開発者が考えればいいだけのことで

いいじゃん、そう思うならそういう要素のないゲームを自分で作れば
それが世の中の流れとは違うとしてもニッチとして戦えるってことだぞ

**名前は開発中のものです。** · 2025/09/12(金) 13:45:25.14

それだね。企業が作らないホラゲとか個人制作で少々出来が悪くてもYoutubeで配信から売れたりするからね

**名前は開発中のものです。** · 2025/09/12(金) 15:12:21.96

なんだろうなあ
志として、ケムコを参考にするかあ
それくらいなら作れそうって思ってケムコなのかなあ

**名前は開発中のものです。** · 2025/09/12(金) 16:33:25.66

ケムコはナムコと関係あるのかなって思って調べたら一文字違いのナムコからではなく「Kotobuki Engineering & Manufacturing Co., Ltd.」の頭文字からとっていた。

**名前は開発中のものです。** · 2025/09/12(金) 16:47:03.83

＞８番出口に続いてチラズアートの『夜勤事件』の実写映画化が決定！

やっぱ個人開発はホラーがいいのかもね

**名前は開発中のものです。** · 2025/09/12(金) 17:35:55.14

じゃあナムコは何の頭文字なんだろう

**名前は開発中のものです。** · 2025/09/12(金) 18:08:25.69

ちらズなんとかってゲームと感じた印象がない
ごく初期は3Dダンジョンゲ出してた気がするが

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

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