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/10/31(金) 10:05:54.22

>>422
自分もLua使ってて今作ってるけど、ロジックはC++で組んでる(組む予定)
Luaでやるのはキャラの初期値などのパラメータ値の設定やイベントの記述、
画面背景に表示するものをLuaで記述、くらいの予定かな

>>423の人も言ってるけど、Luaで書けるならC++でも書けるから、何をLuaに求めるかだと思うけど、
自分の場合はLuaでやるメリットはリコンパイルせずにレベルデザインの動作確認を行えるようになること
ロジック部分はLuaに追い出すと速度的なデメリットが大きそうなのと、
Luaで書けるようにすること自体の工数も大きそうなのでやめた

**名前は開発中のものです。** · 2014/10/31(金) 12:53:25.76

スクリプトの利点はコンパイルしなくても修正出来るところ

**名前は開発中のものです。** · 2014/10/31(金) 17:49:19.79

作り方によってはゲーム中にリアルタイムに変更できたりするよね

**名前は開発中のものです。** · 2014/10/31(金) 17:59:48.36

コンパイルは必要だけど動的変更ならC++でも出来るけどね

**名前は開発中のものです。** · 2014/10/31(金) 18:15:11.72

デバッガでぽちぽち変数の値いじるの？

**名前は開発中のものです。** · 2014/10/31(金) 18:24:36.01

ゲーム中にスクリプト書き換えてリアルタイムに反映？
いらねーよｗ

**名前は開発中のものです。** · 2014/10/31(金) 19:02:05.50

今の所スクリプトは、用途に応じて別のスクリプトを作って使ってるな
３種類ほど
一つはシナリオとかのイベント管理用
一つはレコード単位のデータ管理用
一つはツリー構造のデータ管理用

**名前は開発中のものです。** · 2014/10/31(金) 19:18:37.90

・高速なコンパイル
・クラスとヘッダーに分けなくていい
・importはC/C++のincludeより使いやすいと思う
C/C++だとどれをインクルードすべきか調べないと分からない事もあるし
・ネイティブの部分だけ予めコンパイルしておけば、変更したコードを複数のデバイスですぐにデバッグ可能
・GCでメモリ管理が自動に
・リフレクションでクラスの情報に実行時アクセス
・実行時の式評価(デバッグに使う)

実行時コード編集は確かにあまり役立ってないかも
デリゲート・・・はC++11なら使えるのか

**名前は開発中のものです。** · 2014/10/31(金) 19:23:51.37

>>429
実行中に変更出来ないと一回落として変更して同じところまで進めないといけないから
レベルの調整とかしてるとめちゃくちゃめんどい

**名前は開発中のものです。** · 2014/10/31(金) 19:24:16.18

VB.netのスレはここじゃないんだが？

**名前は開発中のものです。** · 2014/10/31(金) 19:32:27.85

>>432
まあ半分わかるけど、相当規模が大きなものじゃないといらないし、
代替としてその環境を作るスクリプトも組めるし、
途中で変えちゃったら、ユーザーがほんとにその条件に辿り着けるのかテストにならないから
やっぱりいらないな

**名前は開発中のものです。** · 2014/10/31(金) 20:11:52.54

>>422
ロジックをスクリプトで記述するなら汎用ゲームエンジンでいい気がするな
Unityとかめっちゃお手軽よ

**名前は開発中のものです。** · 2014/10/31(金) 20:42:19.68

スクリプト言語はやっぱ、コルーチンが使える点が良いよね？

**名前は開発中のものです。** · 2014/10/31(金) 20:58:16.81

yieldってなんて読むの

**名前は開発中のものです。** · 2014/10/31(金) 22:36:22.81

ヨィールドって脳内再生してうｒ

**名前は開発中のものです。** · 2014/10/31(金) 22:57:08.23

>>437
いーるどぅ

**名前は開発中のものです。** · 2014/10/31(金) 22:59:35.82

インバースキネマティクスについて書かれている書籍知りませんか？

**名前は開発中のものです。** · 2014/10/31(金) 23:09:11.23

>>440
シューティングゲームアルゴリズムマニアクスにあったように記憶してる。
手元にないから確かじゃないけど。

**440** · 2014/10/31(金) 23:15:42.18

>>441
ありがとうございます！
その本は持っているのですが、IKについて書かれていることに気付きませんでしたｗ
コードも書いているので参考になりそうです。

他の本も、ご存知の方がおられたら是非教えてください。

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

>>442
最近読んだのだとこれ
XNAのソースがサンプルであるけど今はXNA自体が使えない
http://www.borndigital.co.jp/book/94.html

**440** · 2014/11/01(土) 01:22:56.00

>>443
ありがとうございます！
XNAでも参考にはなると思うので買ってみます。

**名前は開発中のものです。** · 2014/11/01(土) 10:44:08.91

AがtrueならB、falseならC
BがtrueならD、falseならE
DがtrueならF、falseなら・・・
という感じで
if (A) {
if (B) {
if (D) {
F();
} else {
G();
}
} else {
E();
}
} else {
C();
}
というようなことになってしまいます
例えばAがゲーム開始フラグ、Bがプレイヤー出現フラグ、Dが敵出現フラグという時
最初にC()でカウントを回してAをtrueにしゲーム開始
E()でカウントを回してプレイヤーを出現
G()でカウントを回して敵を出現
F()でバトル開始
のような感じになるのですが、どうすればいいのでしょう
あまり良くないですがswitch caseなどでもいいのかなと考えてます

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

>>445
ステートパターン使うといいよ
IStateを実装した開始ステート、敵出現ステートなどをつくって、
unique_ptr<IState> state = make_unique<InitialState>();
while ...
state->update();
if (state->next)
state = state->next;

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

普通のクラスだったらプレフィックスにCってつける？

**440** · 2014/11/01(土) 17:17:01.83

>>443
買ってきました！
とても詳しく書かれていて大満足です。
ありがとうございました！

**名前は開発中のものです。** · 2014/11/02(日) 01:02:23.40

>>446
やっぱりStateパターンが良いですよね
ありがとうございます

**名前は開発中のものです。** · 2014/11/02(日) 10:54:46.91

Stateパターンと
Strategyパターンって
コードの書き方はまったくと言っていいほど同じじゃないですか？
Stateは状態的な切り替え、
Strategyは機能的な切り替え、
というふうに、どういう使い方をするかで名称が別れてるということですか？

**名前は開発中のものです。** · 2014/11/02(日) 12:52:42.92

ストラテジーはアルゴリズムの切り替え
状態遷移はストラテジーっぽい

**名前は開発中のものです。** · 2014/11/02(日) 13:07:10.08

どういう意図で組んでるか？という情報は
後から見た時に結構重要だったりするよね

**名前は開発中のものです。** · 2014/11/02(日) 13:26:08.13

だよなぁ
例えば遷移だと>>446のやり方はそれぞれのStateの中で自分に関係する遷移条件と遷移先だけ指定するから
ソースを見ただけじゃ全体の遷移一覧がぱっと見えてこないんだよなぁ

**名前は開発中のものです。** · 2014/11/02(日) 20:23:50.79

ソースに依存関係が少ないて部分では良い事だろ
偏移状態はUMLなりその他の手段で伝わればいい

**名前は開発中のものです。** · 2014/11/02(日) 20:58:59.62

状態遷移を記述するのに優れた外部ソースを読み込ませれば
その通りに動くっていう仕組みはスマートで憧れるなぁｗ
動かす側（エンジン側）のC++コードは一切変更しないでいい。

**名前は開発中のものです。** · 2014/11/02(日) 21:39:22.79

何を言ってるのかわからない

**名前は開発中のものです。** · 2014/11/02(日) 23:03:44.43

Lua使えってことだろ

**名前は開発中のものです。** · 2014/11/02(日) 23:46:34.29

WebアプリのフレームワークみたいにXMLでできたら良いなってところか

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

>>445の例みたいに順番に実行するだけの処理でstateパターンはちょっと大袈裟な気がする
各処理に番号付けてswitchで振り分けながら順番に処理した方がまだ見通しよくなりそう

**名前は開発中のものです。** · 2014/11/03(月) 12:22:49.27

内容と関連の無い連番の関数名て最悪のパターンじゃないか

**名前は開発中のものです。** · 2014/11/03(月) 12:27:51.68

まぁ、単純なステートで、かつ、再利用も考えないなら、ハードコーディングしちゃってもいいと思うけどね。

**名前は開発中のものです。** · 2014/11/03(月) 13:23:55.34

関数ポインタの配列とかステートパターンとか
１行ですっきり書けてかっこいいと思ってやってるんだろうけど
結局デバッグするときにどの関数が実際に呼ばれてるのか
分かりにくくなったりするだけなんだよなあ
状態変数使ってifelseとかswitchの方が分かりやすいし
そもそも状態遷移の処理なんかそんなに頻繁に書き換えないし
状態遷移の処理で致命的なバグになって開発が頓挫なんてしないし
結局プログラマーのオナニーでしかないんだよなあ
ファミコンなんかクラスどころか関数すらないのに神ゲーいっぱいあったわけで
オナニーに精力を出すくらいならもっと内容に力入れてよ

**名前は開発中のものです。** · 2014/11/03(月) 13:31:20.68

デザインパターンとか、スマートさと複雑さのトレードオフなところあるし、バランスが難しいよね。
ベタな書き方で十分なら、それでいいところは多いね。

**名前は開発中のものです。** · 2014/11/03(月) 13:33:27.09

まあ気分よく作業できるってことも重要だよ
他人と共同で作業してたりコードレビューしたりしないなら好きにすればいいさ
多少のわかりにくさはコメントでカバーすることもできるし
それが原因で時間かかっていつまで経っても完成しないとかだと目も当てられないが

**名前は開発中のものです。** · 2014/11/03(月) 13:33:31.87

でもOOP楽しいじゃん？

**名前は開発中のものです。** · 2014/11/03(月) 13:36:09.35

>>465
楽しいねｗ
ポリモーフィズムで、ほとんどコードをいじることなくなった基幹クラスがあることが嬉しいｗ
場合によってはベタ書きのほうが総合的にイイなぁ、と思うところも多々あり。

**名前は開発中のものです。** · 2014/11/03(月) 15:20:17.50

>>460
関数名じゃなくて数値と対応付けてswitchで処理するって事
複数のboolで分岐してるのをintひとつでやる感じ
列挙型でやればコードも見やすいかも
そもそも関数名でswitchなんて出来ないしね

**名前は開発中のものです。** · 2014/11/03(月) 15:42:10.04

簡単なトランスレータ(プリプロセッサ)を挟む事で、列挙型と感数名を
自動的に対応付けてCのソースコード生成とか、昔からよくあるサボりテク

STGの敵キャラや弾みたいな、簡易なシーケンシャル制御では重宝するかと

**名前は開発中のものです。** · 2014/11/03(月) 15:42:40.12

感数名→関数名

**名前は開発中のものです。** · 2014/11/03(月) 16:29:35.49

関数ポインタじゃなくて関数オブジェクトにしてメンバに名前を持たせればいいだけの話だと思うがなぁ

**名前は開発中のものです。** · 2014/11/03(月) 16:38:51.58

C++の話だよね
Cならまだしも、C++で関数ポインタって使いにくいと思うんだけど
非staticなメンバ関数使おうとしたらめんどくさいし(function<...>とかあるけど)

あと一口に状態遷移っていっても
アクションゲームの敵とか、個々のゲーム内オブジェクトの動作みたいな規模と
RPGでのフィールド/メニュー/先頭シーンの切り替えみたいな規模のものがあるけど
それによっても求められる要件は結構違ってくるんじゃないか

**名前は開発中のものです。** · 2014/11/03(月) 16:47:13.78

関数ポインタの配列とenumで分岐するくらいならC++やめて純粋なCでやったら？
関数付き構造体としてしかC++使えていないだろうし

**名前は開発中のものです。** · 2014/11/03(月) 17:15:54.38

c++はマルチパラダイムだしむしろOOPしか認めないならJAVAでやったら？
少なくとも>>445の例でstateパターンが最適とは思えない

**名前は開発中のものです。** · 2014/11/03(月) 17:30:10.15

例えば
http://boost.cppll.jp/HEAD/libs/mpl/doc/paper/mpl_paper.html
の、「5. 例: コンパイル時 FSM ジェネレータ」の辺りを読んでみると
>>445が抱いた疑問に対して、わりと明瞭に答えているような気が
しないでもない

「ネストしたif(またはswitch-case)を使ってFSMの構造を実装する
ことは特に間違いではないが」というように、状況によって最適な
実装は変わるんだよね

**名前は開発中のものです。** · 2014/11/03(月) 17:38:52.31

馬鹿の一つ覚えでステートパターン覚えたら
ステートパターン使ってない奴を見下し軽蔑し
ステートパターンを使うことを強要してくる
こういうやつがいるからソースコードをgithubに公開とかする気が失せるんだよなあ
日本人てほんと頭悪い民族なんだなと思う

**名前は開発中のものです。** · 2014/11/03(月) 17:40:45.30

何で日本人はそうなんだろうか？

**名前は開発中のものです。** · 2014/11/03(月) 17:43:52.24

公開されてるコードにステートパターンを強要されたことがあるのか
すごいなその日本人ってやつは

**名前は開発中のものです。** · 2014/11/03(月) 17:49:10.69

そういうの余所でやってくれませんかね(お願い)

**名前は開発中のものです。** · 2014/11/03(月) 17:56:31.99

正解なんてないんだし綺麗に整ってればなんでもええわ
商業ならそうもいかないだろうけど

**名前は開発中のものです。** · 2014/11/03(月) 18:00:07.61

我流でゲーム作ってたら、確かに作れるからいいんだけど「私はC++が使えます」ってスキルアピールできないんだよな。

他人のソース全く意味わからないし。

**名前は開発中のものです。** · 2014/11/03(月) 18:26:59.05

メッセンジャーとかでも外人は普通に顔写真フルネーム公開だが
日本人は絶対写真出さないしニックネームだからな
ネットゲームでも外人は気さくに話しかけてくるが日本人は基本無口だからな
晒しとか陰湿な行為を行うのは日本人という民族が劣ってるからなんだろう

**名前は開発中のものです。** · 2014/11/03(月) 18:34:22.56

で、ID:EKtPAmoI はもちろん日本人だよね？
もっと自分に自信を持ったら？

**名前は開発中のものです。** · 2014/11/03(月) 19:12:02.78

お引き取りください

**名前は開発中のものです。** · 2014/11/03(月) 21:02:33.52

C++入門書に書いてある程度のことが分からなくて逆切れなん？ｗ
頭悪いし才能ないから諦めたほうがいいよ

**名前は開発中のものです。** · 2014/11/03(月) 21:22:08.07

よしなよ

**名前は開発中のものです。** · 2014/11/03(月) 21:41:28.69

やめなよー

**名前は開発中のものです。** · 2014/11/03(月) 21:47:10.70

>>484
だからJAVAやってればいいじゃん
君にネイティブ言語はちょっと難しいんじゃないかな

**名前は開発中のものです。** · 2014/11/03(月) 23:31:40.14

ネイティブ言語わろた
継承ひとつ理解できないおつむじゃ諦めたほうがいい
もしくは独自のヘンテコなやり方をしたければ、ここで披露せずに一人でやっていなさい

**名前は開発中のものです。** · 2014/11/03(月) 23:48:43.67

stateパターンって、クラスつくるよりenumのメンバ追加の方が楽でいい。
でもstateパターン作るなら、状態遷移図は別にドキュメントを作る必要があると思う。
テーブルでやる場合はソースだけでもいいが、抜けがないかの確認がしにくい。

階層型の状態遷移はどうやるといいのだろうか。nestが2階層とか決まってたらまだいいけど、
自由に階層作りたいとか。

**名前は開発中のものです。** · 2014/11/03(月) 23:51:38.06

状態遷移はluaのコルーチンとかでやった方がいいのだろうか？
コードも見やすく、変更も動的にできるし。

**名前は開発中のものです。** · 2014/11/04(火) 00:05:07.98

なんで大手が採用してるか考えたら自明の理

**名前は開発中のものです。** · 2014/11/04(火) 00:09:15.45

独り言が激しいな　とりあえず階層型の状態遷移に話の焦点を絞ると、
親階層を子階層から遷移させる手法が考えどころになるだろうね

自分は独自のやり方でやってるけど、一般的にはどういうやりかたが
推奨されて普及しているのかよく分からない

**名前は開発中のものです。** · 2014/11/04(火) 00:40:17.63

コンパイルが待てないほど大きいの作るの？

**名前は開発中のものです。** · 2014/11/04(火) 01:00:57.23

自分のコードは大した量じゃなくても、ライブラリいっぱい使ってるとリビルド数分とか普通にかかる

**名前は開発中のものです。** · 2014/11/04(火) 01:25:54.32

boostのcoroutineとかcontextとかをゲーム製作で使ってる人いる？
興味があるので、できれば試用感を教えてほしいんだけど

**名前は開発中のものです。** · 2014/11/04(火) 02:14:53.36

コンパイルが待てないからスクリプト組み込むとか、
ライブラリいっぱい使うと時間がかかるとか、
なんでアホな話になるかね。

外部データとして扱えることが最大の利点だろうに。
移植のこととか考えてないんかねこの人たちは。

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

趣味だもの

**名前は開発中のものです。** · 2014/11/04(火) 02:33:18.69

ついでに、Luaじゃなくても別にかまわないがスクリプトでコルーチンを実装すると、
シーケンシャルな書き方で >>445 を書けて

GameStart();
ShowPlayer();
ShowEnemy();
BattleStart();

てことで、定型の処理は隠ぺいして保守しやすくスッキリ見通せる。
さらにスクリプトからスクリプトを生成して動的に実行するということも可能になるんで
非常にフレキシブル。

boostのコルーチンは使ったことない。

**名前は開発中のものです。** · 2014/11/04(火) 06:57:09.55

>>496
逆にC++だと移植大変だったりする？
OSのAPI以外でもコードに差って出たりするの

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

コルーチンとかコマンドパターンのベースクラス作れば同じことだし
コンパイル時間云々もDLLにすれば解決するよ

俺的には、Luaはユーザーに自作マップとかMODを作らせるものだと思ってる
洋ゲーだとMODツールキットにLuaがよく使われているしな

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

>>499
C++の中にハードコーディングしたイベントだらけだったら、
コードを把握するのも大変で移植するのに萎えないか？

その点実行部分とスクリプトで明確に分けれるのが大きい。
実行部分は作る人が仕様に沿ってつくるだけだし、どのプラットホームでも共通のスクリプトにできる。

ちなみにLuaはANSI C準拠なんで、C++がダメな環境でもOK。

**名前は開発中のものです。** · 2014/11/04(火) 21:00:59.89

それ移植どうこうとまた別問題じゃね
コード把握するの大変だけど移植するわけじゃないからおｋとはならないでしょ

**名前は開発中のものです。** · 2014/11/04(火) 21:03:11.80

結論先にありきのﾃﾞﾀﾗﾒばかり
移植以前に完成したことないだろ

**名前は開発中のものです。** · 2014/11/04(火) 21:09:55.86

普通にandroidとPCで出してるが、
とりあえず、>>503はどういう方法でゲーム作っているのか書いてから
どこら辺がデタラメか指摘してもらえるかな？

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

ハードコーディングと移植性に何の関係もないことくらい移植したら分かるだろ
見栄を張って嘘をついてもすぐにばれてしまうというこったｗ

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

ステートパターンだけど、
AIの行動パターンを制御する時みたいに、それぞれのステートが
共通の値（現在HPとか）を参照できる状態（ステート固有の値は持たない）で、
実行される処理だけ切り替えたい場合と、
シーンの切り替えみたいに、ステート固有の値を保管してシーンをスタックに詰んで戻ってきたい場合と、
実装方法は>>446で同じだけど、明確に意味が違うとして別クラス（インターフェース）にすべきだよね？

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

何言ってんだ？
外部にスクリプトで記述していたら、本体は機種依存や特殊な部分だけ移植すればいいだろうが。
ハードコーディングなんぞしてたら移植するたびに作り直しじゃないか。

**名前は開発中のものです。** · 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

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