C/C++ゲーム製作総合スレッド Part7 [転載禁止]©2ch.net

**名前は開発中のものです。** · 2015/01/11(日) 10:19:31.85

ゲーム製作におけるC/C++全般に関するスレです。

元スレ
DXライブラリ総合スレッドその18
http://peace.2ch.net/test/read.cgi/gamedev/1399459468/

前スレ
C/C++ゲーム製作総合スレッド Part1
http://toro.2ch.net/test/read.cgi/gamedev/1337516528/
C/C++ゲーム製作総合スレッド Part2
http://toro.2ch.net/test/read.cgi/gamedev/1351015269/
C/C++ゲーム製作総合スレッド Part3
http://toro.2ch.net/test/read.cgi/gamedev/1357899040/
C/C++ゲーム製作総合スレッド Part4
http://toro.2ch.net/test/read.cgi/gamedev/1376262450/
C/C++ゲーム製作総合スレッド Part5
http://peace.2ch.net/test/read.cgi/gamedev/1389798031/
C/C++ゲーム製作総合スレッド Part6
http://peace.2ch.net/test/read.cgi/gamedev/1404815419/

**名前は開発中のものです。** · 2015/01/11(日) 10:39:11.80

乙

**名前は開発中のものです。** · 2015/01/11(日) 18:56:29.39

おつん

**名前は開発中のものです。** · 2015/01/12(月) 16:06:35.67

基本的にゲーム内で使う文章を外に書くメリットはないよな？
で、セーブファイルは専用の構造体を用意して
そこに保存が必要な数値を片っ端からぶっこめばいいんだよな？
なら今のゲームでテキストファイルを使う場面って、
セーブデータ等のテキストデータのエクスポートくらいだと考えていいんだろうか？

**名前は開発中のものです。** · 2015/01/12(月) 16:37:57.91

文章校正のたびにいちいちコンパイルすんの？

**名前は開発中のものです。** · 2015/01/12(月) 16:41:38.11

海外のゲームやったことないのかね？
大抵テキストデータは外に置いてあって日本語化Modとか作られてたりする。
日本国内しか相手にしないならそれでも良いと思うけど

**名前は開発中のものです。** · 2015/01/12(月) 18:56:00.81

テキストデータでデータ構造作っておくと色々と便利だよ
テキストエディッタ使えばデータを書き換えられるから、
わざわざ専用エディッタを作らなくてもいいし

**名前は開発中のものです。** · 2015/01/13(火) 02:13:15.64

lua,Squirrelなどを使って、シナリオ・文章などを、
読み込んだりしているんじゃないの？

これらを修正する度に、
コンパイルするのは時間の無駄

**名前は開発中のものです。** · 2015/01/13(火) 02:51:46.58

ウチの会社では、基本的にゲーム内で使う文章は外のツールで作成してるな。
わざわざソース内に置くメリットがむしろ感じられない。誤字修正の度にプログラマが手を入れる必要が出てくるし、ビルドに時間もかかるし、別の言語に移植する際に面倒じゃないか。
あ、あと、文章の問題であればそのツールを開けばいいという、問題の修正箇所を局所化できるというメリットもあるから。

セーブは確かに専用の構造体(というかPODクラス)を用意して必要なデータをぶっこむ、シリアライズして吐き出す形だな。

それらの吐き出す形は結局単純なテキストではなく、何らかの形式に則ったバイナリ(テキストエディタで開いても意味不明な部分が交じるファイル)だけど。

**名前は開発中のものです。** · 2015/01/13(火) 08:36:10.29

プログラマ１人で造るミニゲームとかで、メニュー程度の文章量しかないなら
たしかにハードコーディングのほうが楽ではある

**名前は開発中のものです。** · 2015/01/13(火) 11:20:25.68

>>9
そういう文章ってどうやってプログラム中から識別するの
"会話0001"?

**名前は開発中のものです。** · 2015/01/13(火) 12:40:45.14

4 ：名前は開発中のものです。：1985/01/12(土) 16:06:35.67 ID:skthRk+e
基本的にゲーム内で使う画像を外に書くメリットはないよな？
で、描画手順は専用の構造体を用意して
そこに開始点・終了点の座標や塗る色の数値を片っ端からぶっこめばいいんだよな？
なら今のゲームで画像ファイルを使う場面って、
画面紹介等の画像のスクショくらいだと考えていいんだろうか？

**名前は開発中のものです。** · 2015/01/13(火) 18:27:31.65

>>11
ユニークな名前で管理するのが面倒な規模なら
ロジックの部分もある程度は外に投げるようになるんでね

**名前は開発中のものです。** · 2015/01/13(火) 18:40:16.59

画像ファイルでそれやろうって奴はいないだろ…
テキストは定義された物を書き出すだけだからやろうって考える人がいるだけで
あと、MOD作ってもいいよとか多人数でやるよとか
追加含めて大量に書くよってんならテキスト外置きなんだろうけど、
逆に言えばこのどれにも当たらないならいらないかなって
一部でもオープンソースにする気はないって人もいるだろうし

壊せる壁って破壊済み相当の状態で床などに変化するオブジェクトだけど、
これはダメージを与えていくと壊せる物はマップチップ扱いなのかキャラクター扱いなのかよく分からない
キャラクターをマップチップに正確に重ねてチップを隠すんならいけそうだけど、
そうするとマップ情報をキャラクター生成部に送る必要があるんだろうか？

**名前は開発中のものです。** · 2015/01/13(火) 19:39:05.23

>>14
普通に居るけど
Mod作りやすいってことは本編も作りやすいって事がわからんのだろうかね。
あとオープンソースの使い方おかしい

**名前は開発中のものです。** · 2015/01/13(火) 22:57:29.48

それ、一部の場面でレイヤーの代わりに使ったりする物のことを言ってるんだろ？
描画画像を全部内部で0から生成なんかやってたらそのコードだけでものすごい量になっちゃうよ
逆にそれが部品として小さいなら、外に置かなくても組み込んじゃえってのはありだとは思うし
それを実行しているのが一行目ってわけだ

非現実的な案ではあるけど、できるんなら画像の隠蔽は完璧だな
あと、一部ならオープンソースじゃなくてシェアードソースね、おk覚えた

**名前は開発中のものです。** · 2015/01/13(火) 23:22:24.12

お前は勘違いをしている

**名前は開発中のものです。** · 2015/01/13(火) 23:48:10.98

ソース違い

**名前は開発中のものです。** · 2015/01/13(火) 23:48:23.40

たとえ話は
通じなかった時に双方ともに間抜けなことになるのが辛いな

**名前は開発中のものです。** · 2015/01/14(水) 00:25:45.86

スレを流し読みしたが、>>14-16の辺りが話が噛み合ってないよな
これお互いに誤読してるだろ。推測するに大凡の所お前らの間には
目立った意見の食い違いはなさそうだから仲良くしろよな

**名前は開発中のものです。** · 2015/01/14(水) 01:05:05.22

>>14
＞壊せる壁って破壊済み相当の状態で床などに変化するオブジェクトだけど、
＞これはダメージを与えていくと壊せる物はマップチップ扱いなのかキャラクター扱いなのかよく分からない

本来は、昔のゲーム機の仕様(例えばOBJとかBGがあるやつね)の様々な縛り
の中での話なので、今なら好きに定義して自由に作ればいいんじゃねーかな

見当がつかなくて何か参考にしたいんならツクールの類でも触ってみて
内部の仕組みを推測して真似てみたりすればいいんじゃねーかな

＞キャラクターをマップチップに正確に重ねてチップを隠すんならいけそうだけど、

そういう手も当然ありだよね

＞そうするとマップ情報をキャラクター生成部に送る必要があるんだろうか？

どういう機能分割をしてるのかイマイチ分からんけど、座標系の概念が
考慮されてないなら取り入れたほうがいいんじゃねーの

**名前は開発中のものです。** · 2015/01/14(水) 01:50:18.20

え、俺はマップチップもキャラも一緒のオブジェクトなんだけど
お前らわざわざ分けてんの？

**名前は開発中のものです。** · 2015/01/14(水) 18:32:13.33

>>22
舞台装置と役者は似て非なる別物だからよ

>>14みたいなことをやる場合、
当たり判定まではキャラクターと同じでも
HPは持っていない壊せない壁をどう定義するかがな

**名前は開発中のものです。** · 2015/01/14(水) 20:11:23.18

>>23
同じオブジェクトで行けるってことは、似て非なる別物じゃないと思うが

**名前は開発中のものです。** · 2015/01/14(水) 20:25:50.33

好きなようにすりゃええがな
あんさんの方法を否定してる奴なんて誰もおらん
あんさんは他人を否定したくて仕方ないかも知れないがな！

**名前は開発中のものです。** · 2015/01/14(水) 21:38:06.89

例えどんな方法でも実現可能だったとしても
複数の手法の中からベストな物を追求するのは良いことである

**名前は開発中のものです。** · 2015/01/14(水) 22:19:18.87

>>25
まぁ、お前にゃ聞いてないがｗ
似て非なる別物の根拠を訪ねただけで、否定したように感じるってのは相当病んでるぞ

**名前は開発中のものです。** · 2015/01/14(水) 23:02:57.92

当たり判定の範囲をなしを含む特有の定義にして、
一番最初に横たわるキャラクターオブジェクトそれがマップ

他のキャラクターとは一部の要素が大きく違う分管理に差が出るし
無駄を承知で分けた方が分かりやすくはなる…かも

**名前は開発中のものです。** · 2015/01/15(木) 21:04:25.90

マップと言えば、マップチップタイプみたいな並びを記憶しておく必要があるマップは、
当然二次元配列を使うとして
たとえば現在の装備一覧のような、
同じ要素を指す数値の並びをしている物の塊も二次元配列にすべきなんだろうか

**名前は開発中のものです。** · 2015/01/15(木) 23:17:08.52

>当然二次元配列を使うとして
？

**名前は開発中のものです。** · 2015/01/16(金) 08:47:44.30

>>29
別にどう作っても良いけどマップも1次元の配列で持っていた方が楽
座標x、yも持たせておけばいい

**名前は開発中のものです。** · 2015/01/16(金) 12:23:34.85

二次元のビットマップ画像も普通一次元配列で確保するよな。

**名前は開発中のものです。** · 2015/01/16(金) 23:19:42.96

>>29
＞たとえば現在の装備一覧のような(…中略…)二次元配列にすべきなんだろうか

一覧表示にも色々あるけど
要求(される操作)に応じて適切なデータ構造(コンテナ)選ぶものなので
二次元配列でおｋ(な要求)ならそれで作るのが一番いいんじゃねーの

要素数がたかが知れてる場合、配列(std::vector)使ってるからって
何か問題が生じるような事はまずないわけだし

**名前は開発中のものです。** · 2015/01/17(土) 08:27:09.12

2次元配列でOKなものは1次元配列でOK
わざわざ2次元配列を使うメリットは何も無い

**名前は開発中のものです。** · 2015/01/17(土) 11:40:55.67

シンタックスシュガーでしかないもんねぇ
初心者に教えるなら積極的に使うけど

**名前は開発中のものです。** · 2015/01/17(土) 11:55:03.58

一次元配列で確保した上で行(or列)先頭にアクセスするための
インデックス(LUT)を用意するような内部実装でも二次元配列
なんであってだな(>>32)

ターゲットも実装も不明ならメリットねぇとは断言できんよ

**名前は開発中のものです。** · 2015/01/17(土) 11:57:15.65

>>35被ったスマン

**名前は開発中のものです。** · 2015/01/17(土) 17:31:33.18

たとえば縦スクロールSTGのマップとかで、
メモリ節約のためにマップを行ごとに細切れにして
表示範囲の上に一行足して下から一行引くような処理をしていたりする場合、
一行ずつ読み込んでるんだという事を示すためにわざとやるとか
試作段階で仕様が固まらなかった時の苦肉の策がそのままになっちゃったとか？
二次配列ってなんかあんまり使い道が浮かばない

**名前は開発中のものです。** · 2015/01/17(土) 18:57:09.16

3Dでキャラクターが技によって自由に地面の凹凸を操作できるようにしたいんですが
予め頂点を作っておかないとダメでしょうか？

キャラクターがここじゃーって指してる座標に一番近い面の上に
頂点をいい感じに窪ませるように配置して、
もともとあった面と入れ替わるような感じにしたいのですが、
当たり判定やハードウェアレンダリングしたいならやっぱり面倒ですか？

まぁハードウェアレンダリングなんてどうやればいいのかわからないですが

**名前は開発中のものです。** · 2015/01/17(土) 20:24:50.48

確かにあんまり、というか殆ど多次元配列使わないな
配列へのアクセス部分は、隠蔽する傾向にあるから、アクセス用インデックスが多次元でも、アクセスの内部仕様は１次元配列でやってることが多いな

また配列の次元数を増やすと、後から解読するのが難しくなって、可読性が下がる
だから次元が増える場合は、次元別にクラス定義して、一次元配列のメンバに下位次元を持たせるようにしてるな

そういやD3DMATRIXに2次元配列のメンバあるけど、自分で定義したものじゃないし、そもそもそのメンバって殆どアクセスしないなぁ

**名前は開発中のものです。** · 2015/01/17(土) 20:40:58.36

std::vector<std::vector<int>>とかやるじゃん？

**名前は開発中のものです。** · 2015/01/17(土) 20:55:17.63

Dictionary<Point, Tile> Mapしか使わん

**名前は開発中のものです。** · 2015/01/17(土) 21:10:19.92

>>41
enum定数でアクセスするのかな？
それにどんな情報を入れるんだろ

**名前は開発中のものです。** · 2015/01/17(土) 21:23:58.77

ベジェとか普通に書いたら多次元配列になるんじゃ…

**名前は開発中のものです。** · 2015/01/17(土) 21:56:16.62

>>41
やりません
コンテナ2つ重ねても無駄に複雑になるだけでしょ

**名前は開発中のものです。** · 2015/01/17(土) 22:50:59.20

>>41
リソースに余裕がある場面では使ってるな
規模が大きくなってくると細かいことまで気にしてられんからこれ使うとラク

**名前は開発中のものです。** · 2015/01/17(土) 22:59:23.12

>>39
テッセレータを使ったらいいのでは？
凹ませたい領域を4頂点の単純なタイルで表現し、それをフィールドに敷き詰めておく。
凹ませるときは、該当するタイルに対しテッセレーション（最大64分割）して、
高さマップを与えてディスプレースメントさせる。

**名前は開発中のものです。** · 2015/01/18(日) 00:08:51.85

>>45
やるぜ？
可変長CSVの読み込みとか

**名前は開発中のものです。** · 2015/01/18(日) 07:49:00.66

長さ不定のに多重vectorはしないかな

**名前は開発中のものです。** · 2015/01/18(日) 12:34:52.67

vector<vector<T>>は便利なときもあるけど、
コピーやトラバースのパフォーマンスがvector<T>に比べて著しく遅いんで、
そちらが重要なときは多少冗長でもvector<T>で扱うようにしてる。

**名前は開発中のものです。** · 2015/01/18(日) 12:40:46.60

vector<vector<T>*>

**名前は開発中のものです。** · 2015/01/18(日) 12:44:37.58

生ポインタ使うならdequeで良いだろ
とは言えないパフォーマンス差があるんだよな…

**名前は開発中のものです。** · 2015/01/18(日) 13:35:03.38

vector<unique_ptr<T>>

**名前は開発中のものです。** · 2015/01/18(日) 14:23:19.06

null_ptr

**名前は開発中のものです。** · 2015/01/18(日) 15:20:17.44

nullptrでは･･･

**名前は開発中のものです。** · 2015/01/18(日) 15:53:55.88

相当昔にC++触って、今と環境がかなり違いそうなのですが、
タスクシステムを実装する時、昔は固定長のメモリを予め確保したうえで、そのメモリを
newすることによって使っていたのですが、今のゲームもこのやり方が主流ですか？
それともスマートポインタ＋std::listでも速度出るのでしょうか？

スマートポインタとやらは、これはやってる事はガベージコレクションですよね？
速度に問題無しということですが、ヒープ領域から自由にnewdeleteして大丈夫なのかと不安になるのですが・・・