ゲーム制作 雑談スレ【part39】 (447ﾚｽ)
上下前次1-新
25: 09/06(土)09:30 ID:gj8crVsc(1/4)調 AAS
>>21
部分描画も事前描画も知らないのはゲーム製作者として致命的では？
サイズがでかすぎるなら分割してメモリに保持してればいいだけ
26: 09/06(土)09:45 ID:gj8crVsc(2/4)調 AAS
100x100←マップサイズ
11x11←描画サイズ
この場合事前に描画した100x100のマップの必要な11x11領域をくり抜いて毎フレーム描画するんだから
余計な処理はしてないからカリングなんか必要ないし
1/81とか言われても何言ってるんだかって感じ
静的マップを事前に保持しないで毎フレームいちいち描画してたら描画回数が1回から121回(11x11)に爆増するだろ
ドット絵のくせに何でこんなに重いんだよ！って最適化不足ゲームの出来上がり
27: 09/06(土)09:48 ID:gj8crVsc(3/4)調 AAS
普通にゲーム作っててこんなアホな実装するわけないので
結局は話をよく理解してなくて何か勘違いしてるだけだね
28: 09/06(土)10:17 ID:nuZTTbZ9(3/9)調 AAS
質問者のPygameの練習で低ドットの迷路とか作るレベルじゃないのかな。
いつまでも揉めてないで、自作ゲームを自分のポリシーに沿って最適化すればいいんだよ。
29: 09/06(土)11:11 ID:gj8crVsc(4/4)調 AAS
質問した人は質問だけして消えたけど
話理解してない人が横から絡んできたんだから仕方ない
30: 09/06(土)11:14 ID:ntBmkgul(1)調 AAS
Unityででっかいマップを作った時って描画はカメラに応じて最小限になってんのかな
31: 09/06(土)12:05 ID:hIKwuN7F(1)調 AAS
レンダリングパイプラインってのを調べるといい
そもそも上でもめてる内部処理と画面に表示されてるもの（たぶんお前が描画といってるのがここでごっちゃになってる）は別だから、その辺も含めて勉強するといい、隙間時間でも2週間くらいやれば理解できるだろ
基礎中の基礎だから、ここが自習できない理解できないわかんないならゲ製は無理マジでアキラメロン
32: 09/06(土)12:51 ID:EXmAikSr(1/3)調 AAS
まあこの程度のことを聞いてるって事は１枚絵だけじゃなくてキャラとかも全部100x100に乗せそうだから
画像１枚をスクロール描画するとかという前提での議論は無意味だよ
33: 09/06(土)12:51 ID:nuZTTbZ9(4/9)調 AAS
>理解できないわかんないならゲ製は無理マジでアキラメロン
流石に一言余計。忍者といい地罰信者といいマウント取りたいだけの人がいるなぁ
34: 09/06(土)12:54 ID:nuZTTbZ9(5/9)調 AAS
絡んでこられてもスルーが吉。息抜きの雑談スレで無駄な体力使うことない
35(1): 09/06(土)13:28 ID:gwr+bGfK(2/10)調 AAS
>>20のＡが重いか軽いかという話なら、やっぱり>>20のＡの方が処理としては重いだろ
マップタイルを描画する場合、全体マップのテクスチャを使っても使わなくても、いずれにせよ描画コールは１回だけで済む。デカいテクスチャを使う方が重い
そもそも数千px四方に納まる全体マップという条件が特殊過ぎるので、レトロ作風か習作にしか通用しない。横に１画面程度スクロールさせるだけで世界の端かよｗ
反対に全体マップが数千px四方程度なら細かいこと気にせず、全体マップも作成せず、低レベルの視野外カリングに任せて、毎フレーム100×100描画で無問題
36: 09/06(土)13:48 ID:7Km6Wgc5(1/2)調 AAS
今のハードウェアなら、2Dスクロールなんか大した問題じゃない
誰か、PC8801SR でパララックススクロールを実装する技術でシメてくれ
37(2): 09/06(土)13:49 ID:bbhijobr(1/3)調 AAS
>>35
いやその人の例えならBのほうが重いよ
GPU負荷はどっちも同じで気にするほどの誤差は出ない
大量のドローコールによるCPU負荷が段違い
描画以外にもCPU処理は必要だから間違いなくBは次第にフレームレートが稼げなくなる
アホなこと考えてないで両方実装して試してみなよ
38(1): 09/06(土)13:58 ID:gwr+bGfK(3/10)調 AAS
>>37
だからドローコールはどちらも１回だと言ってるだろ。テクスチャサイズの方がネックとしてデカい
39: 09/06(土)13:59 ID:gwr+bGfK(4/10)調 AAS
>>37
アホアホうるせえんだよ、このアホが。お前が試せｗ
40(1): 09/06(土)14:10 ID:bbhijobr(2/3)調 AAS
>>38
どちらも一回なんてありえないだろ
Bは全チップをチップ枚数分描画してるんだよ
ドローコールはAが1回でBは121回
お前の仮定がおかしい
つまり話を何にも理解してない
41: 09/06(土)14:24 ID:EXmAikSr(2/3)調 AAS
まだ地罰の話してたほうが平和だったなｗ
質問した奴もほくそ笑んでることだろう
42(2): 09/06(土)14:24 ID:nuZTTbZ9(6/9)調 AAS
喧嘩するなよ。俺が判定してやるよ３２Pixの場合
〜100×100 タイル（3200×3200 px）Aが有利（blit 1回 vs 400回）
300×300 〜 → B/Cに移行するのがおすすめ。
128PIXの場合 100X100でAは現実的じゃない。
想定するピクセルがわからない時点で喧嘩しても意味ないぜ
43(1): 09/06(土)14:25 ID:gwr+bGfK(5/10)調 AAS
>>40
つ 例：glDrawElements
何も理解してなさすぎワロタ
44: 09/06(土)14:26 ID:gwr+bGfK(6/10)調 AAS
>>42
失礼だな！喧嘩腰なのは奴の方だぞ
45(1): 09/06(土)14:41 ID:nuZTTbZ9(7/9)調 AAS
>>43 Pygame単体でタイル描画してるなら → glDrawElements とは無関係だよ。
君は PyOpenGL + pygame(OpenGLモード) で glDrawElements を使えといってるのだろうが、そもそも質問者はそのレベルにいないよ。
46: 09/06(土)15:00 ID:bbhijobr(3/3)調 AAS
>>42
Aをマップ画像をゲームフォルダに入れとくことを言ってるなら
そんなの最初から考慮しないでしょ
そのうちファイルサイズえらいことなるじゃん
最初から>>5の後者がCでしょ
視界に入る部分だけってのがどの範囲なのかよく分からないけど
47: 09/06(土)15:03 ID:i+R/pY0x(1)調 AAS
せっかくの週末にレベルの低い話をするなよ
こんなのは「好きに作れ」が答えだろ
48: 09/06(土)15:19 ID:nuZTTbZ9(8/9)調 AAS
そのとおりだよ。質問に対して「俺ならこうする」だけでいい。
質問者はお礼を言ってその中でいいと思ったやり方で作ればいい
49(1): 09/06(土)15:36 ID:w/QEgYfo(1/4)調 AAS
https://pbs.twimg.com/media/G0JLSr4a0AAHTZY.jpg
https://pbs.twimg.com/media/G0JLUtQawAAd_xV.jpg
カメラ範囲だけの処理にとどめてくれる機能はpygameにはないらしい
unityにはある
pygameで作るなら昔ながらのc言語のゲームの作り方で作る必要がある
2000年代によくあったゲーム制作本にはそのやり方結構載ってた
50(1): 09/06(土)16:31 ID:gwr+bGfK(7/10)調 AAS
>>49
pygameは知らんけど、どんな低レベル描画エンジン使ってるにしろ、低レベル描画エンジンがカリングしてくれるだろ
51(1): 09/06(土)16:36 ID:w/QEgYfo(2/4)調 AAS
>>50
ChatGPTによればpygameはないんだって
52: 09/06(土)16:54 ID:nuZTTbZ9(9/9)調 AAS
＞pygameは知らんけど
いままでの論争はなんだったんだ。
53: 09/06(土)17:28 ID:gwr+bGfK(8/10)調 AAS
>>45
「こんな所にS級が？！」とかあるあるやん
・・・アニメでは
54(1): 09/06(土)18:34 ID:gwr+bGfK(9/10)調 AAS
>>51
Pythonスクリプト層内での低レベルAPIへの描画コールは間引かれない（APIコールしても低レベルAPI内では間引かれるかも）、て意味じゃないの？知らんけど
55(2): 09/06(土)19:34 ID:w/QEgYfo(3/4)調 AAS
>>54
https://pbs.twimg.com/media/G0KCf9ja4AAhQ5i.jpg
だそうです
ChatGPTの答えはノー
56(1): 09/06(土)19:43 ID:7Km6Wgc5(2/2)調 AAS
そんなにChatGPT が得意なら、pygame のタイルマップのシステムをサクッと作ったら？
たぶん、どこかからコピペしてくるよ
57: 09/06(土)19:50 ID:w/QEgYfo(4/4)調 AAS
>>56
俺は野球ボーイで上の者ではない
上の者は上の者で自力で頑張ってください
58: 09/06(土)20:30 ID:gwr+bGfK(10/10)調 AAS
>>55
平行線だな。低レベルの描画エンジンが視野外カリング・テストを行わないのは考えられない
だから俺は、そのLLMの回答はPythonスクリプトレイヤの話だ、と言っている
59: 09/06(土)20:58 ID:/kpwELhX(1)調 AAS
今週もよく進んだ
着実に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
60: 09/06(土)21:17 ID:EXmAikSr(3/3)調 AAS
これからは質問されたらChatGPTに投げたほうがいいかもな
どうせ荒らしだろうし
61(1): 09/06(土)22:37 ID:zOtGPqEd(1)調 AAS
>>55
チャッピーに騙された可哀想な人がいる……
もう一度これで質問してみ？
Q: 以下の問いについて事実に基づいた解説をせよ。
1. pygameのSurface.blit() は、ソースのピクセルをdest Surfaceに転写する処理である。
2. この転写時にソースが出力先の範囲を超える場合、その領域は自動的にクリッピングされ、省略される。
3. ソースと出力先が完全に重ならない場合、描画処理は行われず内部的に早期リターンされる。
62: 09/07(日)00:45 ID:qucJSDY/(1/8)調 AAS
野球マンは、Unity使いなんだし朝から同じ話題に辟易してChatGptで調べただけだから、別にPygameがNinateやLumen使えてもどうでもいいだろう。
63: 09/07(日)00:54 ID:qucJSDY/(2/8)調 AAS
GoogleGeminiで聞いてみたよ
カリングとblit()の最適化
「カリング」という用語は、一般的にゲーム開発において、描画パイプライン全体で不要なオブジェクトを描画リストから除外する手法を指します。これには、フラスタムカリング（カメラの視錐台の外にあるオブジェクトを無視する）、オクルージョンカリング（他のオブジェクトに隠れて見えないオブジェクトを無視する）などが含まれます。
PygameのSurface.blit()は、このような広義のカリング機能自体は提供していません。つまり、開発者が自分でオブジェクトの座標を確認し、画面外にある場合は描画関数を呼ばないように制御する必要があります。
しかし、以前の回答で述べた「早期リターン」の機能は、blit()関数内部で行われる描画処理の最適化です。これは、特定の描画命令（この場合はblit()）の引数（ソースとデスティネーション）が描画対象として無効である場合に、GPUやCPUへの負荷をかけずに処理を終了させるためのものです。
まとめ
Pygame自体が、シーン全体の不要なオブジェクトを自動的に描画リストから除外するような、高度なカリング機能は提供していない
blit()の内部最適化：blit()関数は、引数で渡されたソースとデスティネーションの矩形が重ならない場合、内部的にピクセル転送処理をスキップするという最適化を行っています。
これは、Pygameの描画関数の効率を高めるための実装レベルの工夫であり、広義の「カリング」機能とは異なります。
64: 09/07(日)01:09 ID:qucJSDY/(3/8)調 AAS
すでに5の質問とはかけ離れてるし、平行線で続けて長くなるんなら別スレ作れば？
65: 09/07(日)01:30 ID:qucJSDY/(4/8)調 AAS
最後に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方式と性能差はありませんが、プロシージャルダンジョンなどゲーム開発のベストプラクティスとして最も推奨される方法です。
66: 09/07(日)01:31 ID:qucJSDY/(5/8)調 AAS
Geminiの総括
最終的な結論と最適な選択肢
100x100タイルの規模であれば、A方式とC方式はどちらも十分に高性能です。
手軽さ、シンプルさを最優先するなら「A方式」
巨大なSurfaceを最初に1回だけ作成すれば、あとはblit()のオフセットを調整するだけで済みます。コードが非常にシンプルになります。
拡張性、将来的な複雑なゲームシステムを考えるなら「C方式」
マップデータが配列として存在するため、ゲームの規模が大きくなったり、タイルごとに異なるプロパティ（通行可能か、イベントが発生するかなど）を持たせる場合に柔軟に対応できます。
どちらの方式も今回の条件では問題なく動作するため、あなたのゲームの要件や実装の好みで選ぶと良いでしょう。
67: 09/07(日)02:09 ID:w+4ozsCS(1)調 AAS
Geminiに聞いたことをコピペして意味なんか無いから
お前は荒らし
68: 09/07(日)02:19 ID:c3Q3zl9k(1/2)調 AAS
のたうちまわった末に出てきた歪なうんこ、みたいな回答
69: 09/07(日)04:34 ID:cdtbdgBv(1)調 AAS
AIの回答は質問者のレベル以上にはならないってのがはっきり分かるなぁ
70: 09/07(日)06:56 ID:qucJSDY/(6/8)調 AAS
一気に60ぐらいスレ進んだな。忍者みたいなのがいるのか
71: 09/07(日)10:53 ID:5TMUfK9O(1)調 AAS
>>61
問いになってないと思うのだが
72: 09/07(日)11:34 ID:4AU0/eMl(1)調 AAS
この時代に2Dスクロールが問題になるとはなぁ
73(1): 09/07(日)12:01 ID:ahzATgAC(1)調 AAS
2DLODによって
例えば32pixel*32pixelの画像が
画面の端に行くにしたがって
16*16, 8*8, 4*4,2*2の画像に置き換わる
これによってテクスチャ使用料は大幅に下がり
VRAMをより自由に使うことが可能になる
ドローコールは80%以上下がる計算だ
人間は画面のプレイヤーを表示する中心点の周りしか見ないため
このような技術を使っても実際の見た目はプレイ感ほぼ変わらずできる
74(3): 09/07(日)12:36 ID:c3Q3zl9k(2/2)調 AAS
# 低評価のレビュー
画面の端に向かって何故かボヤけが強くなっていくというバグがあって製作者に問い合わせしましたが、泥コーラがどうのこうのと意味不明な説明をされ、さらに見た目はほぼ変わらないので対応できないと返信がありました。
そのため即返金要求しました。
この製作者からは二度と購入しません。
こうなるだけだぞ、余計な最適化はすんな、もう一度言う、無駄な最適化はすんな
75: 09/07(日)12:48 ID:W/Q1K9c6(1)調 AAS
中心窩レンダリングかぁ？
76(1): 09/07(日)12:57 ID:8iqlIUfk(1)調 AAS
https://imgur.com/oNax2ZA
pythonでゲームを作ったよ
でもデプロイ先がねーよ（公開するほどのクオリティでもないけど）
やっぱりフリゲはUnityRoomに落ち着くな
77: 09/07(日)14:23 ID:emCB4qtY(1)調 AAS
>>74
急に泥コーラとか言われてもこっちだって分からんよ
単純に実装がバグってるけど開発者がアホだから直せないだけでしょ
それ最適化と何の関係があるの？
78: 09/07(日)14:41 ID:Z+uha7Ru(1)調 AAS
君はROMってなさい
79: 09/07(日)15:32 ID:EFCEmLLF(1/2)調 AAS
>>74は悪ノリレスであって
どう見たってこれがマジレスなわけないだろ
気付かないのはゲ製エアプだけだよ
これに対してそんなことしたらこうなるだけだ
余計な最適化はすんなもう一回言うぞとかクサすぎるでしょ
80: 09/07(日)15:36 ID:EFCEmLLF(2/2)調 AAS
>>74
>>73は悪ノリレスであって
の間違い
こんな意味不明な実装するやつ世の中に一人もいないよ
81: 09/07(日)16:17 ID:qucJSDY/(7/8)調 AAS
３Dカメラで写実的に見せるためにDirtLense（レンズ汚れ）、VignetteやChroma AberrationとかＤＯＦあたりをPostEffectsしたんでしょ
ポストエフェクトマテリアルは解像度で調整してないと４Kモニタでアウトラインが細くなったり見た目変わるから注意な
82: 09/07(日)16:22 ID:qucJSDY/(8/8)調 AAS
>>76 完成おめでとう。itchIoあたりにアップロードしてくれれば遊ぶよ
83: 09/08(月)03:58 ID:2dY4F7bt(1)調 AAS
市販のフィルターも画面サイズで見た目変わるのあるから結局自分で書くようになるね。
84: 09/09(火)21:22 ID:DuHc0YCK(1)調 AAS
『レポ with 館山4人衆2』
▽雑談→Steam
協力型ホラーゲーム「R.E.P.O.」
×UNKちゃん×布団ちゃん(活動休止中)
×天狗ちゃん×よっちゃん
https://iplogger.info/2TU4H7.tv
85(1): 09/10(水)00:48 ID:1yIDrEYz(1/2)調 AAS
ミラー編集機能作れた
https://i.imgur.com/XR3jQag.png
https://i.imgur.com/a3eRl6z.png
https://i.imgur.com/Yk0cO7d.png
86(1): 09/10(水)08:29 ID:Sv534i0u(1)調 AAS
>>85
それいずれ公開するん？
それとも自作エンジンの中で動的にオブジェクト作ったりするため？
87(1): 09/10(水)10:20 ID:1yIDrEYz(2/2)調 AAS
>>86
公開はしないかな
公開するとなると別の労力が必要だしメリットを感じない
エンジンを作る方が優先
88: 09/10(水)14:36 ID:WDmGH6fq(1)調 AAS
>>87
そらそうか
エディタの公開なんて無料は民度の問題で、有料は責任の問題で地獄の道だもんな
89: 09/11(木)09:40 ID:jxe0ipoG(1)調 AAS
Unity6でビルドした時に無料でもロゴ出さなくて良くなったらしい
90: 09/11(木)12:24 ID:WqCc2j+8(1)調 AAS
ワイはSteamで公開手続き中や
みんな遊んでくれよな
91: 09/11(木)12:56 ID:cTYvRrOH(1)調 AAS
ええね
Nextフェスに間に合うんか？
92: 09/11(木)13:05 ID:HVk6IEjA(1)調 AAS
日記
インディーゲームの開発規模のカテゴライズでほぼソロ開発は『keiゲーム』って呼ぶってどうよって記事みかけたわ
『軽』自動車の『kei』なんだっておもろ
そしてこの規模のゲームが星の数ほど出てるけどほとんど利益が上がらず世紀末の様相を呈しているらしい、まあ納得
93: 09/11(木)13:17 ID:5FhVSe/h(1)調 AAS
Youtubeとかで検索すると素人が１～３ヶ月でゲーム作って売ってみましたってのが多いな
Steamのデータベースが汚れるからそんなゴミを売るなよ。と思う
まあゲーム界の軽自動車と言われるのも納得
94(1): 09/11(木)16:17 ID:HetorVHb(1)調 AAS
個人だとフリゲと変わらない出来だろうし、とっくにSteamは「出せば勝手に売れる」場所ではなくなっていて埋もれるよなぁ。
面倒くさかったらパブリッシャーに任せてゲームに注力するという手もあるが、慈善事業で無いので普通の出来だと契約は出来ないし。
95: 09/11(木)20:43 ID:jye13JI5(1)調 AAS
パブリッシャーが口出してきたりもするので完全に注力できるかと言うとまたそれも難しいんよな
96: 09/11(木)20:51 ID:vW95VhvK(1)調 AAS
絵がイイのべるげーはうれるっしょ
97: 09/11(木)21:01 ID:jimPv/Nb(1)調 AAS
じゃああんでひぐらしはうれたんですか？
98: 09/11(木)21:02 ID:BGLBOM1+(1)調 AAS
ゆうて組織が作ったゲームも薄利多売でゲ製以外のネタでしのいでいて、社畜奴隷どもは魂に妬み・嫉み・僻み・やっかみしか残ってない実質世紀末だろｗｗｗ
99: 09/11(木)21:15 ID:3R5lIWYK(1)調 AAS
>>94
Unity Roomレベルの習作をSteamで販売して「売れないぢゃん！！」ってキレるのは違うと思うが…
100: 09/11(木)22:02 ID:8D+d4WUv(1)調 AAS
ゴミがあるからこそ良作や名作が輝くし、ゴミがあることでまともに作られたゲームの良質さがわかるってもんだ
ゴミらしく引き立て役として徹するなら売っても問題はないだろう
101: 09/12(金)02:03 ID:Sc4YKnOG(1)調 AAS
keiゲームとかそんな回りくどい造語じゃなく粗製でええんちゃう
んで個人ゲーム＝粗製のイメージって、だいぶ怪しい立場の意見でしょ
なぜなら制作者なら普通は俺はあいつらとは違うけどねってなるので
102: 09/12(金)08:31 ID:4xSizp8N(1/2)調 AAS
UnityRoomとかで定番人気の作品見るといわゆるクリッカー放置系なんだよね
リソースが時間で貯まるとかスタミナがあるとかは強力にユーザーを引き戻すんだなあと実感させられる
でも…
プレイ動機が「もったいない」なのって個人的には嫌い
嫌い！
103: 09/12(金)10:50 ID:0CaUcu5v(1/2)調 AAS
もったいないというか、ライブゲームの原点は習慣にできるかどうかだと思うんだよな
自分はもう（特にオンラインゲームは）デイリータスクないとログインするモチベーションすら維持できないって実感してるわ
オフラインだとストーリーとか目標や終わりがあるけどさぁ
でも、オフラインゲームにデイリータスクって意味があるかどうかだよなぁ、恋愛シミュ系とかはお誕生日イベントとかはあるよな
あー、日常シミュとかはライブゲームに近いかもしれないな
104: 09/12(金)13:16 ID:daQ6zJBz(1/6)調 AAS
数多くプレイしてもらうのならいい選択と思うけど、
Steam等の有料ゲームランキングを見るとわかると思うけどそれらは金出してまで遊びたい思う人はいない。
無料のクリックゲー放置ゲーは大衆がひまつぶしで遊んでいる。ソシャゲは課金させて金を巻き上げてるだけ
金を出してくれる人向けにゲームをつくりたいならブラウザの人気ランキングとか参考にしないほうがいい
105: 09/12(金)13:35 ID:4xSizp8N(2/2)調 AAS
自分はもったいない精神でゲームをさせられるのが嫌でスマホでも有料アプリしか手を出さなかったんだが
最近有料アプリも平然と放置育成要素突っ込んできて違う望んでいないってなる
ケムコのRPGおまえや
106: 09/12(金)13:38 ID:0CaUcu5v(2/2)調 AAS
まあ、ランキングにも参考にすべき部分としない方がいい部分はあるわな
それは各開発者が考えればいいだけのことで
いいじゃん、そう思うならそういう要素のないゲームを自分で作れば
それが世の中の流れとは違うとしてもニッチとして戦えるってことだぞ
107: 09/12(金)13:45 ID:daQ6zJBz(2/6)調 AAS
それだね。企業が作らないホラゲとか個人制作で少々出来が悪くてもYoutubeで配信から売れたりするからね
108: 09/12(金)15:12 ID:2GJMoZra(1)調 AAS
なんだろうなあ
志として、ケムコを参考にするかあ
それくらいなら作れそうって思ってケムコなのかなあ
109: [SAGE] 09/12(金)16:33 ID:daQ6zJBz(3/6)調 AAS
ケムコはナムコと関係あるのかなって思って調べたら一文字違いのナムコからではなく「Kotobuki Engineering & Manufacturing Co., Ltd.」の頭文字からとっていた。
110: 09/12(金)16:47 ID:daQ6zJBz(4/6)調 AAS
＞８番出口に続いてチラズアートの『夜勤事件』の実写映画化が決定！
やっぱ個人開発はホラーがいいのかもね
111: 09/12(金)17:35 ID:Q+yLgQ9h(1)調 AAS
じゃあナムコは何の頭文字なんだろう
112: 09/12(金)18:08 ID:2KYk8cAt(1)調 AAS
ちらズなんとかってゲームと感じた印象がない
ごく初期は3Dダンジョンゲ出してた気がするが
113(2): 09/12(金)18:10 ID:daQ6zJBz(5/6)調 AAS
「中村製作所」の英語表記「Nakamura Amusement Machine Manufacturing Company」
114: 09/12(金)18:12 ID:RIDsZYG7(1)調 AAS
太客の固定配信者やVtuberが居る個人開発サークルっぽいから参考にならん
配信をあてにした８番ライクやホラー作ってるとこの売り上げ報告は悲惨そのもの
115: 09/12(金)18:18 ID:daQ6zJBz(6/6)調 AAS
＞チラズアート（Wikiより）モデリング等の3D関連を兄、プログラミングを弟。「Night Security 夜間警備」では三男が主体となって開発。外国人と間違えられることもあるが、アメリカ育ちで日本在住の日本人である。
UnityやUE使ったり英語まで出来るとなるとスペック高いな
116: 09/12(金)22:53 ID:piBP8SqH(1)調 AAS
>>113
あれ頭文字じゃないよ
経緯を晒すと、最初は「manco」にしたかったらしい。勿論、これは申請却下になった
たまに例のロゴで「manco」と記載されたTシャツを着てるアホな輩を街で見かけるが、あれは登記前に早漏気味に先行販売されてたレア物らしい
それでもどうしてもアホな志を貫きたくて「mamuco」で再申請したけどやっぱり却下。結局「namco」でしか登記できなかった、てのがオチらしい
117: 09/12(金)23:11 ID:lBskxgO0(1)調 AAS
>>113
ケムコの真似っ子したんだな
118: 5 09/13(土)06:24 ID:T/TQC7uh(1)調 AAS
すいません>>5です
新種の新型コロナにやられてゲーム制作どころではなく寝込んでおりました
いろいろコメント・アイデアありがとうございました
作っていたものの思い出しを兼ねて、16384ピクセル×16384ピクセルの地形のsurfaceを事前に作成し、
開始位置をずらしながらウィンドウにblit()することでシンプルに実現できたのですが、
なぜかPythonのプロセスがメモリを800MBとか消費してしまい、厳しいなと…
60fpsでの処理には問題なさそう
引き続き、いろいろ試してみます
119: 09/13(土)08:39 ID:17RHWNFe(1)調 AAS
16384×16384のRGBAでサイズは1GBになるから、むしろ少ないな
120: 09/13(土)09:11 ID:/sY+99Ls(1/2)調 AAS
そうよなあ、今１Gは少ない時代なんよな
ブラウザゲーでもBGMはmp3で流しっぱなしにするのが普通になってFM音源はロストテクノロジーに
121: 09/13(土)09:59 ID:2+R2ARqA(1)調 AAS
Don't stop, Don't stop the music.
Don't stop, Don't stop the music.
ピーキーなナンバー聴かせてもっとー♪
パパがロケンロール！ ロケンロール♪
彼もロケンロール！ ロケンロール♪
チャチャチャチャイナ！
122: 09/13(土)12:16 ID:O3MfSZll(1/2)調 AAS
最もメモリや容量食う要素は音楽・画像データなんだよな
ステージごとにメモリをリセットしたりバックデータ再登録したりがめんどい
123: 09/13(土)12:25 ID:O3MfSZll(2/2)調 AAS
しかしPythonってバッファのことsurfaceっていうんだ
使ったことないので馴染みがない呼び方
124: 09/13(土)15:00 ID:Br85WM0Q(1/2)調 AAS
やだ、この人、javascript のこと java って言う人種と同じニオイがする……
上下前次1-新書関写板覧索設栞歴
あと 323 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s
