C/C++ゲーム製作総合スレッド Part6

**名前は開発中のものです。** · 2014/07/08(火) 19:30:19.51

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

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

前スレ
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/

**名前は開発中のものです。** · 2014/11/04(火) 22:48:00.93

>>506
するべきだと思う
じゃないとシーンの制御にAIのオブジェクト渡せるみたいなわけわからん事になる

**名前は開発中のものです。** · 2014/11/04(火) 23:07:53.61

イベントなんかをハードコーディングすると機種依存が発生するって言ってる？

**名前は開発中のものです。** · 2014/11/04(火) 23:17:05.61

極端なたとえ話をすると、エミュを作成する場合で
ゲーム固有のイベントをその汎用的なエミュに組み込むのか？組み込まないだろ？というのとあまり変わらない。

**名前は開発中のものです。** · 2014/11/04(火) 23:18:46.07

もうUnity使えばいいんじゃないかな

**名前は開発中のものです。** · 2014/11/04(火) 23:36:33.23

移植するつもりがあるなら移植を考えたコードにすりゃいいし
別に移植考えないなら考えてないコードでもいいんじゃない？
まぁどっちでも好きな様にすりゃいいんだけど

**名前は開発中のものです。** · 2014/11/04(火) 23:41:58.41

やっとわかったけど
多分大抵の人はスクリプトの用途をもっと限定的なものとして話してると思うわ

**名前は開発中のものです。** · 2014/11/04(火) 23:48:24.99

分かりにくくてスマンかった。ついでに移植で話がそれたのもスマンかった。
要はstateパターンやswitch振り分けのほかにDSLという選択肢を示したかっただけ。

**名前は開発中のものです。** · 2014/11/04(火) 23:50:26.53

もうエンジン部分以外はほとんどスクリプトでいいと思うけどね
処理速度が必要な部分が判明したときだけコードをC++に移すかんじで
FFCCはソース見当たらなかったがほとんどがスクリプトだったと見た記憶がある

http://www.inside-games.jp/article/2009/09/07/37504.html
http://game.watch.impress.co.jp/docs/20080224/ffcc.htm

**名前は開発中のものです。** · 2014/11/04(火) 23:52:06.45

>>507
スクリプトを使うかどうかと何の関係もないのだがｗ
ボロがでるばかりｗｗｗ

**名前は開発中のものです。** · 2014/11/05(水) 00:01:59.05

>>515
まさにそう。使ってるライブラリが開発停止になっても、エンジン部のすげ替えもできるし。

>>516
キミは分からないならもういいよ、独自の路線を走ってくれｗ
たぶん一人だけで開発してるだろうから、いまのままでも特段不便はないだろ。

**名前は開発中のものです。** · 2014/11/05(水) 00:12:09.01

まず、OSやOpenGLのAPIをアプリロジック内にハードコーディングしちゃうアホとか君だけだからね
それと組み込みスクリプト言語を使用することに何の関連性も無いのよ

**名前は開発中のものです。** · 2014/11/05(水) 00:21:14.06

薄いラッパー書いて使ってるが何か？ｗ
で、俺の主張は>>514だが、キミの主張はなんなの？過去発言から意図が見えないのだが？
単に俺に突っかかって来るだけなら、相手しても無駄なので遠慮したいんだが。

**名前は開発中のものです。** · 2014/11/05(水) 00:27:01.07

嘘デタラメを書き散らすウザイやつを笑ってるだけだよ
あまり背伸びをするなよｗ

**名前は開発中のものです。** · 2014/11/05(水) 00:28:29.32

ああ、そうｗ

**名前は開発中のものです。** · 2014/11/05(水) 00:36:27.94

かくしてスクリプト言語を使わないと移植が困難になるとかいう根拠なきトンデモ説が論破され
しったか君が大恥をかいたのであった♪

**名前は開発中のものです。** · 2014/11/05(水) 00:45:38.59

ゲーム自体をスクリプトでつくれば移植するときエンジンを交換するだけで済むって話でしょ
前提が共有できてないのに知ったか吹いてると大恥かくよ

**名前は開発中のものです。** · 2014/11/05(水) 00:50:14.08

ってか、スクリプト使ってる人って多いのかな？
個人で作る小規模ゲームでもよく使われるの？
オールC++の人も多いのかな？

**名前は開発中のものです。** · 2014/11/05(水) 00:55:37.53

交換だけったって結構C++で書き換えるコードもアリそうだけどな

移植先がC++ならOSのAPI叩く部分とエンジン駆動部分を綺麗に分離しとけば、
移植性に関しては大して変わらないようにも思うし、
スクリプトの最大のメリットが移植性とか言われるとやっぱすごい違和感在るわ

つうかゲーム自体をスクリプトで書くならもうすでにこのスレで話す内容じゃないな

**名前は開発中のものです。** · 2014/11/05(水) 00:56:41.89

マルチプラットフォームのエンジンなりラッパーを挟めば何も交換する必要もない
遂にその程度のことも分からなかったID:23olDi5Xが大恥かいたということだね

**名前は開発中のものです。** · 2014/11/05(水) 01:16:22.19

winのしか作る気ないしな
c++だけで何の問題もない

**名前は開発中のものです。** · 2014/11/05(水) 01:19:11.85

自分もC++/Win/DirectXオンリー派。
移植とか気にせんでえーし楽だ。

**名前は開発中のものです。** · 2014/11/05(水) 01:33:14.61

スクリプトは覚えるのめんどくさいかもしれんけど便利だよ
データの分離は常識だけど、それをさらに進めて制御も分離できる
データとそれを使うコードは密接なことも多いから
まるごと分離できると何も考えなくて済むし

**名前は開発中のものです。** · 2014/11/05(水) 02:09:12.31

>>525
いや、>>496 で言ってるように最大の利点はデータとして分離できること。
移植が注目されてるが、質問から思わず伸びたに過ぎない。利点の一つではあるが。
ちなみに>>422は俺ではないが、ほぼ同じ経緯をたどっているね。

特に複数人で開発するときスクリプトはかなり便利。
割と簡単に使えるようにしてから、デザイナーが演出とかいろいろ直接いじったりできる。
※あいつら、結構シビアなんでいちいち要求に応じて、こっちで作業してたらめんどくっさい。

また、前は書き換え専用の実行ファイル持ってたが、
データとしてゲーム部分を持っているのでリリース後、ゲーム中にアップデートすることもできる。
某プロテクトの関係で実行ファイルを書き換えられないので、これ地味に結構良い。

**名前は開発中のものです。** · 2014/11/05(水) 02:22:26.32

>>529
ほんとこれだね

**名前は開発中のものです。** · 2014/11/05(水) 02:24:59.33

なるほど。
覚えとこ。

**名前は開発中のものです。** · 2014/11/05(水) 03:13:21.00

スクリプトってよくわからない。素人で申し訳ないが。

例えばキャラクターの行動を外部データ（テキスト形式）で設定するとして、俺がどうやろうかと考えると
テキストを読み込む→書かれてた文字を判定→それに従ってキャラを設定する
という単なる外部データ読み込み処理になるわけだけど、
これだと特に意識しない限り独自形式でやることになるから、スクリプト言語とか関係なくなる。

んじゃよく聞くスクリプト言語ってのはなんなんだと考えると
誰かが考えたスクリプト言語にしたがって自分で実行プログラムを組んでいる？
しか思いつかないんだが、これだとあまりにも非効率で、一般に広まるとは考えにくい。

んじゃライブラリみたいな形で配布されてるの？　とも思うんだが、それを自分のプログラムに組み込むのって
最初に挙げた、自分の独自形式でテキスト読み込むほうが楽でしかも早くね？　と思ってしまう。　

**名前は開発中のものです。** · 2014/11/05(水) 04:02:31.79

テキスト読んで設定するだけでも立派なスクリプト。
独自だろうが何だろうが、スクリプトを見て処理の流れが一発でわかるとベスト。
ノベルゲーのテキスト処理のスクリプトは想像しやすいんじゃないかな？
これはいくらなんでもハードコーディングはしないでしょ。

ただ、自分で四則演算や変数・関数を実装しようとすると、
テキストの構文解析、意味解析、スタックマシン等を勉強して
yaccやbisonでコンパイラを作る大変な羽目になる。

んで、そんなことせずとも簡単にそういう機能を組み込めるように
LuaやSquirrelがある。それにこの二つはメジャーで、かなり広まってる。

**名前は開発中のものです。** · 2014/11/05(水) 04:45:23.73

BulletMLとか、こういう説明には向いてそうな感じがする

**名前は開発中のものです。** · 2014/11/05(水) 07:24:36.56

テキスト形式のデータ構造とスクリプト言語を同一視するのは、なんだかな
xmlとかをデータ構造と言われると納得できるがスクリプト言語と言われるとなんかモニョる
いや、スクリプト言語をデータ構造として使える事は理解しているし、
データ構造をスクリプト言語の代わりとしては使えない事も理解しているが……

**名前は開発中のものです。** · 2014/11/05(水) 08:24:52.84

ノベルゲームの場合はプログラミング言語としてのスクリプトって言うかまんま台本だな

**名前は開発中のものです。** · 2014/11/05(水) 08:58:45.06

ノベルゲーごときにこんな議論してたのか
通りでスレの流れが理解できんわけだ…

**名前は開発中のものです。** · 2014/11/05(水) 19:54:47.73

>>533
キャラクターの行動を記述できるような表現力のある
実質的にスクリプト言語と呼んで良いようなものを簡単に書けるなら
他の人が作ったものを学習して使う方が面倒に思うのでは
他の人が作ったスクリプト言語を使うにしてもブラックボックスで使うのと
中身を検査して使うのとでは手間が大幅に違う
まだお互いに無意識な認識の違いがかなりあるのではないか

**名前は開発中のものです。** · 2014/11/06(木) 01:14:24.74

外部データの代わりとしてのスクリプト（初期化の時に呼び出すとか）はわかるんだけど
処理としてのスクリプトってのはどういう風に使うかわかんねぇや

例えばDXLibとLuaを使うとする。
DXLibは基本的にシングルスレッドで、ゲームループ中にupdateとdrawを交互に呼び出すっていうのが主流だけど、
そのupdate中にLuaスクリプトを呼ぶとすると、その処理中、ループはそこで止まってることになる。

AIのルーチンとか、ウェイト無しでひたすら処理すればいいやつはそれで良いけど。
コルーチンを駆使するような挙動（※）を記述する場合って、意図したように動かすの難しいよね？
（※四角形を右に３秒かけて30ドット移動させた後に、上に２秒かけて50ドット動かす、など）

コルーチンを２段重ねにして、
obj.move(30, 0, 3000) //xに30ドット、1000ミリ秒
obj.move(0, -50, 2000)

//moveの実装
void move(int x, int y, int time) {
　int frame = time * FPS / 1000;
　float dx = (float)x / frame
　float dy //略
　for(i = 0; i < frame; ++i) {
　　time / FPS
　　this.x += dx;
　　this.y //略
　　yield();
　}
}

こんな感じ？（これじゃズレるけど）

**名前は開発中のものです。** · 2014/11/06(木) 02:25:22.77

最後合わせればそれでもいいんだけど、時間で考えたらいい。
float delta = （now_time - begin_time） / (float)time で 0～1まで変化するので、
x(y) * deltaでその時点での移動量が出るから初期位置に足してやる。
終了条件は1以上になったときで、強制的に初期位置にx(y)を足して処理を抜ける。

**名前は開発中のものです。** · 2014/11/06(木) 03:09:54.65

LuaとC++のデータ橋渡しとか、C++書く側が結構面倒くさそうだな

**名前は開発中のものです。** · 2014/11/06(木) 14:42:03.47

おい、姿勢制御にクォータニオンを使う方法が特許取られてたぞ

特開２０１１－２２０８２５

でググって一番最初のリンク
今更こんなんで特許申請するとか頭おかしいし、なぜ取れるんだろうか…

**名前は開発中のものです。** · 2014/11/06(木) 15:30:14.91

周知の技術って特許にならないんじゃなかったっけ。
ホントにそうなら取り消されるんじゃない？

**名前は開発中のものです。** · 2014/11/06(木) 15:41:51.54

訴えれば取り消せる
訴えなければ取り消されない
ちなみに低額訴訟なら簡単に訴えれる

**名前は開発中のものです。** · 2014/11/06(木) 15:46:35.49

間違えた。低額訴訟じゃなくて少額訴訟だった。
ちなみに3Dゲームに興味の無い俺は訴えないけどな
まあ訴えるなら頑張れ

**名前は開発中のものです。** · 2014/11/06(木) 15:53:35.47

申請者はトヨタ自動車になってて、最初は工業用ロボット制御の事で始まってるが
最終的には一般的なプログラム上での話しになってる
これは酷過ぎるな…

何の価値もないこの申請がトヨタの誰かの業績になってると思うと腹立つな

**名前は開発中のものです。** · 2014/11/06(木) 15:56:19.75

特定の特許申請に対して異議申し立てとか再審請求とか出来るんだろうか？

**名前は開発中のものです。** · 2014/11/06(木) 16:08:27.82

実際は、相手から訴えられない限り特許無効申請なんて誰もしないだろうね

そしてこういう下らない特許は山ほどあって
ゲーム特許訴訟
でググると結構色々あるな

**名前は開発中のものです。** · 2014/11/06(木) 16:13:48.30

訴訟起こされるほど拡散力の強いゲームを作ってみたいもんだね

**名前は開発中のものです。** · 2014/11/06(木) 18:44:11.46

よくわからんがゲ製には関係ないじゃろ

**名前は開発中のものです。** · 2014/11/06(木) 19:53:55.97

特許で思い出したけどコナミだかどっかの
ロード中にミニゲームが遊べる
って特許が12月で切れるんやな

**名前は開発中のものです。** · 2014/11/06(木) 20:31:37.28

実際に訴訟を起こされたら>>550みたいな考えは吹き飛ぶだろう
それも、どこから出てきたのか見当もつかないサブマリン特許みたいな物ならなおさら

**名前は開発中のものです。** · 2014/11/06(木) 21:01:35.08

>>552
ミニゲームだったらナムコだろ
リッジ7のロード中にゼビウスが遊べた時はびびったw

**名前は開発中のものです。** · 2014/11/06(木) 21:11:28.90

なぁ、特許って本当に社会の発展に貢献してるんだろうか･･･？
>>543みたいなゴミ特許が効力あるとか、唖然とするわ･･･。

**名前は開発中のものです。** · 2014/11/06(木) 21:19:10.59

特許を審査するメンバーってちゃんと仕事してるのか考えさせるよな。

審査過程をチェックする機構もあるのか怪しい。

**名前は開発中のものです。** · 2014/11/06(木) 21:25:50.58

永久機関そのままは駄目だけどちょっと表現変えるだけで通るみたいだしな

**名前は開発中のものです。** · 2014/11/06(木) 21:40:44.92

特許の審査ってなにやってるんだろうと考えると、
まず考えられるのは今までに同じ特許がなかった事を調べる、くらいだろう。

次に既知の技術として存在してないかを調べるんだろうけど、
これいちいち調べてられないよな。漏れがでるのはしょうがない。

ネットが発展した現代では、調べるのもかなり容易になってきたのではないかと思うが、
審査官が来る日も来る日もググってると考えるとなにか悲しいものがあるな……。

**名前は開発中のものです。** · 2014/11/06(木) 21:53:29.21

その特許を調べるためのシステムをつくるような話があった気がしたけど頓挫したんだっけ

**名前は開発中のものです。** · 2014/11/06(木) 22:55:27.98

この特許はフィードバック制御が必要だから、
新規性の判断はそこでされたんじゃないの？

**名前は開発中のものです。** · 2014/11/06(木) 23:20:16.77

よし、車輪でも申請してみるか

**名前は開発中のものです。** · 2014/11/06(木) 23:37:08.84

>>541
あーいや、そういう話じゃなくて、
DXLibだとメインループ回ってるから、いくらLuaでコルーチンがあっても
１ループ間の時間に合わせて処理返さないといけないよなって話

**名前は開発中のものです。** · 2014/11/07(金) 00:36:18.17

c++側とlua側ともにもう少し詳しく書いてみ

**名前は開発中のものです。** · 2014/11/07(金) 00:41:45.93

わからんって言ってるのに書いてみとはアスペしかいないのかよ

**名前は開発中のものです。** · 2014/11/07(金) 01:43:20.36

プログラマはアスペ気味の糞が多いからねｗ
そいつらを上手く奴隷として扱えるようになるのが社会の勝ち組。

**名前は開発中のものです。** · 2014/11/07(金) 01:53:01.03

ていうかマルチスレッドで描画てどうやんの？
座標はupdateスレッドでロックしてるし描画するにしてもdrawスレッドでロックしないといけないだろ
メモリを2倍使ってダブルバッファリングで交互にリソースを入れ替えてもいいけど1フレーム遅れるし
要素ごとにロックとアンロックしてたらそっちのほうが処理重いでしょ
モーションブラーとかドロップシャドウみたいな、書き足すようなシェーダとかなら分かるんだけど、ゲームの要素そのものを描画するのにマルチスレッド？ってすごい疑問なんだけど
どんな風にやってるの？

**名前は開発中のものです。** · 2014/11/07(金) 02:53:09.53

俺、マルチスレッドってさっぱりわからんけど
マルチスレッドで描画するのに「１フレーム遅れる」って関係あんの？

**名前は開発中のものです。** · 2014/11/07(金) 03:13:07.36

片方はとにかく更新する
片方はとにかく描画する
ロックアンロックで同期させるならマルチスレッドをやめる

**名前は開発中のものです。** · 2014/11/07(金) 06:56:56.78

マルチスレッドを理解してない奴が多いな、まあ自分もあんまり理解はしてないが
というか、マルチスレッドだけでも本がいっぱい出てるからそれを参考にしたらいいかと

**名前は開発中のものです。** · 2014/11/07(金) 07:32:03.69

マルチスレッドの場合、普通は描画と更新を別々にするわけじゃない
それぞれのスレッドに別々の役割を与えて異なる処理を分担させる事になる
あと、マシンに対する負荷を減らすには同期処理しまくらないと意味がないし
ロックアンロックが重くなると言ってる奴はマルチスレッドを根本から誤解してる
というかとにかく本を読め

**名前は開発中のものです。** · 2014/11/07(金) 07:53:25.81

とにかく1フレームの中に時間は8msぐらいはあるんだ
その中ですべての作業を終わらせる事を考えろ
重い処理は役割分担して複数のスレッドで終わらせばいいし、
軽い処理はわざわざ役割分担する必然性は無いからな

**名前は開発中のものです。** · 2014/11/07(金) 08:07:38.45

120fpsがデフォなのか

**名前は開発中のものです。** · 2014/11/07(金) 08:58:33.47

じゃあ描画要素ごとにロックアンロックして、
もし描画スレッドで更新スレッドがロックしてる描画要素を描画しようとしたらアンロックされるまで待つのか？

**名前は開発中のものです。** · 2014/11/07(金) 09:08:00.46

描画スレッド分けるのは描画中にメインループ止まるの防ぐ為だと思ってたけど
そんな事しなくても並列処理してくれるもんなの？

**名前は開発中のものです。** · 2014/11/07(金) 09:22:31.34

>>570

javaとかだと排他ロックするのすごい重い気がするんだけど
C++だとそんなことないの？

**名前は開発中のものです。** · 2014/11/07(金) 11:15:34.21

ロックすると重くなるんじゃなくてロックの割り当てというかスレッドの割り当てを間違えてるから重くなる
ロックしている間に別のスレッドをフルに動かすのがデフォ

**名前は開発中のものです。** · 2014/11/07(金) 11:42:28.34

描画をマルチスレッドにするには自前の描画コマンド(のようなもの)を作らないと駄目だね
で、コマンドの作成を出来る限りマルチスレッドで行なう
最後にメインスレッドが自前の描画コマンドを解析しつつ各種API(DirectXやOpenGL)を呼び出していく

**名前は開発中のものです。** · 2014/11/07(金) 11:53:44.31

そこでluabindですよ

**名前は開発中のものです。** · 2014/11/07(金) 12:23:40.03

そういや、描画範囲が違う場合は別々のスレッドで別個に書き込み出来るけれども、
描画範囲が重なる場合はこの手段が使えないね

あとスレッドって、何度も起動させて使うよりも、
一度起動させたらロックさせながら使い回す方が処理が早いね

**名前は開発中のものです。** · 2014/11/07(金) 15:24:47.03

ごめん、いまいち分かってないんだけど
今の話ってどのプラットフォームを想定して進行してるの？
DirectX？ OpenGL？ソフトウェア描画？それとも特に規定しない全般？

**名前は開発中のものです。** · 2014/11/07(金) 23:07:57.05

特にしてないはずだけど、DirectXはユーザが多いだけに暗黙な前提にしてる人が多そうなイメージ

**名前は開発中のものです。** · 2014/11/08(土) 10:52:03.60

最近はマルチコアなCPUも珍しくないからなぁ
ウチのタブレットは4コアだ
PCはシングルコアだが
PCはわりと長持ちだらなぁ

**名前は開発中のものです。** · 2014/11/08(土) 11:16:44.54

よく考えたら背景だろうがエフェクトだろうがキャラクターだろうが
カメラの射影行列使いまわすんだからカメラのインスタンスロックしないと危ないよね
で、カメラのアップデートは更新処理するスレッドで回すんだから結局更新スレッドと描画スレッドで占有権を撮り合う形になるから
アンロック待ちが当たり前なのか

**名前は開発中のものです。** · 2014/11/08(土) 11:30:01.41

プログラム内であまり時間を使っていない部分までマルチスレッドにしてもパフォーマンスが落ちるだけ

**名前は開発中のものです。** · 2014/11/08(土) 12:09:00.67

DirectX11のDeffered Contextとか使うとうまくマルチコア化できるんかな
気になってはいるんだけど試せてないんだよな

**名前は開発中のものです。** · 2014/11/08(土) 12:09:24.51

>>583
1フレーム内で不整合起きなきゃいいんだしそんな神経質にやることないと思うけど
描画スレッド内で他スレッドから書き込まれる領域とスレッド内で使う領域分けておけばいいんじゃない

**名前は開発中のものです。** · 2014/11/08(土) 12:10:50.95

マルチスレッドを使ってドヤ顔したい年頃なんだろう

**名前は開発中のものです。** · 2014/11/08(土) 12:11:13.95

綴り間違ってた、「Deferred Context」だった
まさにGPUへのコマンドリストの構築と発行をやってくれるっぽいんだが

**名前は開発中のものです。** · 2014/11/08(土) 12:11:48.40

自分もいまいちDefferedContextの使いどころが分からんくて
ImmediateContextしか使ってない。

DefferedContextは並列化の点で少し中途半端なものらしく、
この点を改善するのもDirectX12の目的みたいよ。

早くDirectX12を触りたいなぁ。

**名前は開発中のものです。** · 2014/11/08(土) 12:51:36.67

そもそもウィンドスレッドとゲームスレッドにすら処理を分担できてないゲームが珍しくないけどな
重い処理をやってるとウィンドが動かなくなるとかｗ

**名前は開発中のものです。** · 2014/11/08(土) 13:25:48.11

そもそもマルチスレッドでプログラムするのは良いけれど、コア数いくつのマシンを前提にしてる？
あと、コア数の足りないマシンは切り捨てるの？

**名前は開発中のものです。** · 2014/11/08(土) 14:33:58.84

コア数少なかったらOSが勝手にスレッド振り分けてくれるんじゃないの？

まぁそうじゃなくても、今どきPCでゲームやろうって人がシングルコアなんて無いと思うけど

**名前は開発中のものです。** · 2014/11/08(土) 14:46:37.18

>>592
おまえは>>582を読まなかったのか？
あと、PCはネットに繋ぐための道具とかワープロの代わりとしか思ってない人は珍しくないし、
そーゆー人はPCが壊れるまで買い換えない

**名前は開発中のものです。** · 2014/11/08(土) 14:50:59.54

ゲーム用途じゃないじゃんｗ

**名前は開発中のものです。** · 2014/11/08(土) 14:54:18.14

DVD再生装置にインディーズゲーム、使い道はまだまだ広いぞｗｗｗ
2Dゲームの信者はまだまだ多い

**名前は開発中のものです。** · 2014/11/08(土) 15:00:01.75

エロゲじゃないんだｗ

**名前は開発中のものです。** · 2014/11/08(土) 15:46:47.80

2Dっつーか古いOSでしか動かないゲーム？

いいこと思いついた、お前ら古ゲーを新型OSでも動くように移植しようぜ
え？俺？ソースもないのにそんなのやる気ないです

**名前は開発中のものです。** · 2014/11/08(土) 17:38:42.74

みんなはC++でゲーム開発するときシーン制御ってどうやってやってる？
王道とかあるの？

**名前は開発中のものです。** · 2014/11/08(土) 17:52:05.59

そのシーンについて、もう少しｋｗｓｋ

(ジャンルによって、ツールによって)意味が異なるので、そこんとこの絞り込みを

**名前は開発中のものです。** · 2014/11/08(土) 18:03:53.69

>>584
ですよねぇ…

>>591
個人的なケースでは、自分が使ってるi5のノートPCのバッテリ駆動状態で
できるだけ長く動かせるように仕方なく組んだ事ならありますねぇ

即売会でのデモ用(試遊用)として、予備バッテリーを何個も持って行きたく
なかったので。あと夏なので、あまりアッチッチーになるのも困るんで

**名前は開発中のものです。** · 2014/11/08(土) 18:11:24.52

>>599
例えばRPG作るとして、タイトル、セーブデータ選択、マップ、戦闘、またマップ、町のマップ、お店で購入、みたいなシーンの管理
今あげた奴の中でも、戦闘までシーンとして管理していいのかどうかとか

**名前は開発中のものです。** · 2014/11/08(土) 19:04:20.72

例えばRPGのマップ画面で戦闘になると、戦闘画面へと切り替わるじゃん
でもマップ画面でショップ画面になっても、画面とは名ばかりの操作できるウィンドウが表示されるだけなのかもしれないし

**名前は開発中のものです。** · 2014/11/08(土) 19:26:18.89

戦闘シーンこそ別個で管理しないとややこしいことになりそうなんだが……

**名前は開発中のものです。** · 2014/11/08(土) 20:42:42.63

ウィンドウ出す程度なら分けなくていいんじゃないの
こうしなきゃいけないなんて決まりはないんだから複雑さ見て決めりゃいいと思うけど

**名前は開発中のものです。** · 2014/11/08(土) 21:13:23.69

自分の場合、マップシーンでは、セリフはメッセージウィンドウ、
メニューはメニューウィンドウ、買い物は販売メニューウィンドウ、
所持金は金額ウィンドウ、ってな感じに分けてるが、
戦闘シーンは別プログラムで処理している
タイトルシーンではメニューウィンドウ出してるし
あと、フィールドマップと町マップとダンジョンマップでは、
データを変えて同じプログラムで処理している
この辺はわざわざ別個のプログラムにする事は考えもしなかったな

**名前は開発中のものです。** · 2014/11/08(土) 21:33:54.63

セガ本はStateパターンって話は聞いた

**名前は開発中のものです。** · 2014/11/08(土) 22:19:46.15

そういやゲーム関連での定番、デザパタって決まっているもん？
やっぱりGoFの流用？