■ ゲーム製作技術板雑談スレ03
そいやぁずっと横スクアクションでSTGとか作った事ないんだよなぁ
弾幕系は無理だけど、縦スクロールのSTGとか面白そうだね 横長のモニタが主流になった今、PCフルスクリーンでの縦シューは死んだジャンル 左右にイラストとか表示してるゲームはたまに見かけるな 横に広い縦シューとか、普通にステータス表示させておくとか まあフリーや同人なんかだとやっぱり東方式のデザインが多い印象。 >>49
そこだよねえ、コンボアニメは2〜3回見れば飽きてスキップしたくなるし
派手なエフェクトもスゲーと思うのは最初だけ、すぐ視界の邪魔になる。
多くのコマ数に合わせて動き作って操作とキャラクターの移動にラグが生じたら致命的ですし…… フルスクリーン表示にして、ゲームの全画面表示
なんかにこだわらず枠使えば良いと思うけどな
最近の人は枠の使い方知らないんかな? >>62
スマンが俺に、縦シュー画面のレスの流れと、その絵描き道具がどう関係してるか説明してくれ Steamに登録してきた、1日訪問50件じゃお先真っ暗だよなあ…
どんだけ作りこんでも見てもらわないことには始まらんし うちは一日の訪問者300位だな、ただし三分の一くらいはbot
宣伝とかは全くやってないダウンロード数は一年で400弱位 日本人しか興味を持たないようなテーマだとダメかもしれんねあそこ
ストア画面ではっきりわかる糞アセットフリップゲームでもアメリカ人向けに出せば買ってくれるよ多分
あそこの廃課金者は所有数で競い合ってるみたいだから >>68
廃課金者は所有数で競い合う…
海外の重度のレトロゲーコレクターも、プレイはど下手クソでゲームやってないのバレバレだけど
集めるだけ集めて積んでるからな
すんげー納得した まあsteamにはもともと日本人は3、4%しかいないからな、世界人口比では日本人は1.5%くらいだから、少し多めな割合とは言えなくもないが
基本アメリカ人となぜか中国人ばかりのストアよ
中国人は日本人以上にHentaiが多いからエロゲは意外と売れそうな気がしないでもないが
最低でも中国語と英語は必須だとは思う ストアページだけでも中国語用意しようとDeep翻訳したら親前音読とか射爆了みたいな文字列ばかりになった
中国人に通じてるのか怪しいが日本人には結構通じそうw 日本語と中国語は語順が違うから機械翻訳に弱いんだよね
英語で書いてから機械語翻訳に通すとけっこう自然に翻訳してくれる
技術情報が重要な業界なのに、英語が書けない奴はさすがにおらんよな? 最後に受けたTOEICは753点だったな……
ちょっと自信ないわ ヒント: TOEICの得点は5点刻み、つまり一の位は常に5か0 >>73 中国はSteam解禁なったの?
IT文化大革命がはじまってsteamに接続できないって記事は見たことあるけど・・・ 自分に置き換えて想像してみてくれ
自国のネットでは規制が厳しくて、VPN(中国の場合国内と海外2箇所は必要)など駆使して
わざわざDLするに足る魅力がその作品にあるかどうか?
まあエロならワンチャンあるけれど。
英語なんかはディープL先生辺りで十分だと思う、リアルタイムで対処する事なんてほぼ無いし。
あと、TOEFL で700点越えなら前人未到の記録なんで
あるいは海外の大学で教鞭を執ることだって夢じゃないかも、自信持ってよいと思う。 DLT日本語の作品ががDLsiteとかに散見される怪しい日本語のゲームだって言ったらどう思う? 雲の画像を縦に細切れにする。具体的には1ドット単位に。
その一つ一つを横に引き伸ばし、半透明にして高速でスクロールさせると高高度の雲っぽくなる。
・・・それだけの処理のハズなのに、5~6年前の俺を殴りシバきたいぐらいに意味不明な処理をしている。
落ちずに動いているものの挙動がおかしいなあと思いはしたものの後回しにしていたのだけど、やはり気になって覗いてみれば何だよコレ。 そんなカッコイイ、充実した話じゃないんだ・・・。
表示専用の設定/動作関数があるのに汎用関数で用意したパラメータを表示専用設定関数に飛ばして、汎用動作関数経由で表示専用の動作関数に飛ばす。
パラメータもちゃんと正しく用意していたのに、よく分からない決め打ちしていたり。
中間に無駄な処理を噛まして、しかも1回で終わる処理を数百回(雲の分割数)に分割するとか・・・ね。
#取り敢えず設定だけ汎用関数噛ませたままで、表示動作関数を直接呼ぶようにしたら動作が安定した。
#設定関数は用意するデータを改変しないといけないので、先送り。 2Dシューティング作ってます。
少し変化を付けようと、ボスをBlenderで作ってプリレンダ加工で使おうとしたら、いやぁまあそれなりの精度を確保しようとするとパターン数が青天井で目眩がしてきます。なんてアホな仕様を決定してしまったんだ・・・。
基本設計を完全2Dで施してあるので3Dを混ぜ込むことも出来ないし、そもそも基礎知識すら欠ける状態で3Dを利用するのも無理なので、データを減らす工夫だけで乗り切ろう・・・ここに仮アップして意見聞こうと思ったけど、現状で500MB超えだからなあ・・・。 >>90
テクスチャの圧縮が使えるなら、4分の1とかにできたりするけど、圧縮するとスプライトがすこし汚くなるんだよな
あとはファイルのフォーマットを色数の少ないものに変えるとか、
他にはちょっと大変だけど、一枚絵じゃなくいくつかのパーツに分けてアニメさせるとか 他人のエンジン使ってない人は、最初に必要となるヒープメモリを大容量確保して、ゲームアプリ起動中のnew/delete時に確保したメモリ領域を管理して、ゲーム終了時に一括開放する機構を実装してるのかな
最初にメモリ不足を検知できて、ゲーム起動中はOS場でのメモリ占有が約束されて、断片化もある程度制御できるから、実装するに越したことはないだろうが
最近の非ゲームアプリだと、コンポーネント生成が必要となったときに、その都度必要な分だけOSから確保するような設計になってるのが多い様な気もするんだが 基幹部分を組み直そうとすると、「できるだけ簡潔に」「できるだけ結合度を低く」みたいな意識が強く働いて、ちょっとの機能なのに思った様に進捗が進まん
昔に作った資産(と呼べるかどうかはともかく)の再利用にも時間が掛かる >>94
でもそれやらないと昔の資産の使い方が思い出しにくかったりしない? >>95
過去資産を再実装するより思い出す方が早いけど、過去資産を結合度の弱い独立ライブラリとして切り出す作業が重い
各種リソース管理が組み合わさる比較的表層の処理(描画など)も簡潔に切り出したいが、もうプロトタイプ実装で済ませて後で考えるかw 「やりたくないこと(=ライブラリのリファクタ)は後回し!」にしたら目に見える成果が増えていって、今の所「アレ」の再開発楽しいわ 下僕のやっかみ憐れ
しかも過疎版の埋没スレでかよw とりあえずアレのライブラリ化作業は完了したが、ジオメトリの形状の種類を増やしたいところ
そのネタだけでもゲームを作れそうだが、折角なのでついでにポータル窓も実装したい なるべく最小限かつ簡潔を心掛けてるつもりなんだが、いつの間にかアホみたいにクラスが増えてやがる
しかも一生、一次元配列を操作するコードばかり書いてるし、描画系ライブラリの詠唱ステップが1つでも抜けると半日溶けるし
完成する未来が全く見えんw #include <fbxsdk.h>
fbxsdk::FbxManager* p_fbx_manager = fbxsdk::FbxManager::Create();
p_fbx_manager->Destroy();
_CrtDumpMemoryLeaks();
これだけでメモリリーク出まくりなんだがw
天下のAutod〇skさんよぉ?一体どういうことだよ?w つうかさ、VS2022から仕様が大きく変わってるじゃねえか
コロコロ仕様変えるなよな全く。価値観押し付けられて服従を強制されてるみたいでイライラするわ