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

**名前は開発中のものです。** · 2013/08/12(月) NY:AN:NY.AN

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

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

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

**名前は開発中のものです。** · 2013/10/20(日) 17:30:33.91

>>515
8方向移動のコードですか
ちょっと考えてみました

//移動
void Idou(){
if( 上ボタン ) y--;
if( 下ボタン ) y++;
if( 左ボタン ) x--;
if( 右ボタン ) x++;
if( 上ボタン && 右上ボタン ) y-- , x++;
if( 上ボタン && 左上ボタン ) y-- , x--;
if( 下ボタン && 右下ボタン ) y++ , x++;
if( 下ボタン && 左下ボタン ) y++ , x--;
}

//エラー
void Idou_E(){
if( 上ボタン && 下ボタン );
if( 右ボタン && 左ボタン );
}

こんな感じの２つの関数を作って２つとも呼び出せばいいのかな？

**名前は開発中のものです。** · 2013/10/20(日) 17:35:02.87

>>517
http://c-games.main.jp/ckaihatu/ckaihatu7.html

俺はこんな感じにインストラクタで一括で読み込み
メンバ関数内でメンバ変数を呼び出して使用

他の方どうぞ

**名前は開発中のものです。** · 2013/10/20(日) 17:41:16.55

間違った（笑）
こうかな？

//移動
void Idou(){
if( 上ボタン ) y--;
if( 下ボタン ) y++;
if( 左ボタン ) x--;
if( 右ボタン ) x++;
if( 上ボタン && 右ボタン ) y-- , x++;
if( 上ボタン && 左ボタン ) y-- , x--;
if( 下ボタン && 右ボタン ) y++ , x++;
if( 下ボタン && 左ボタン ) y++ , x--;
}

まあキャラクターを移動するところになったら
もっとじっくり考えてみよう

**名前は開発中のものです。** · 2013/10/20(日) 17:43:24.26

このスレで聞くよりなんでも掲示板行った方がいいぞｗ

**名前は開発中のものです。** · 2013/10/20(日) 17:47:01.59

>>515
さすがに移動処理をまとめるのはないわ
それを言われてifだらけにするのもないわ

例えばAジャンプB加速C攻撃Dガードだとまとめることは不可能
同じキー処理なのにあっちではfor、こっちではifとか見にくいからifで統一すべきってこと
移動量なんかよりキー処理の方が大きい存在だから移動量側の都合に合わせたらあかん

**名前は開発中のものです。** · 2013/10/20(日) 18:04:48.98

効果音って結構使い回すからグローバルクラス作って全部押し込んでるな
よくないんだろうけど

**名前は開発中のものです。** · 2013/10/20(日) 18:14:32.71

>>520
Windowsから送られるメッセージを処理するで絶対間違いないって
なんならDXライブラリ作った人に掲示板で聞いてきてあげようか？

**名前は開発中のものです。** · 2013/10/20(日) 18:27:55.76

>>517
俺も>>523みたいな感じだな。マネージャクラスを作ってデータの実体はそこで一元管理してる。
ロードは各シーンに移ったタイミングで使うファイルを指定して全て一括ロード。
動的なロード／アンロードみたいなことはしてない。

古典的で単純な設計だけど、変に工夫しても複雑化するばっかで使いづらいだけだったので結局コレに落ち着いた。
今やメモリ2Gがゴミスペックって時代だし、個人レベルで作れる規模のゲームならリソースの容量的にもロード時間やメモリ残量がネックになることはないと思うし。
高度なリソース管理システムがないと管理不能な程リソース数があるわけでもなし。
なので、重複ロードだけ防げればいいかなって考え。

**名前は開発中のものです。** · 2013/10/20(日) 20:58:42.50

よく使う(かもしれない)リソースはキャッシュしている

使っている間はリソースが解放されないようにさえしておけば
キャッシュの最大容量を減らすだけで低メモリ環境に対応できる
メモリが十分あるなら最大容量を多めにしてロード時間を削減できる

バッググラウンドで次使うデータをロードし続けると、更にロード時間削減するのに良いが流石にこれは難しい

**名前は開発中のものです。** · 2013/10/20(日) 21:53:23.68

解説サイト作るならdoom3やquake3のソースを丁寧に解説してくれれば
すんげー便利なんだが…、まぁ読むのがめんどくさいだけなんだがな(´д`;)

**名前は開発中のものです。** · 2013/10/20(日) 22:32:36.98

グローバル管理はきついからなぁ…
キャッシュ機能追加してみよう

**名前は開発中のものです。** · 2013/10/20(日) 22:56:51.42

ボクは移動とかのキー入力に関しては携帯ゲーム機のキーコードを参考にビットで演算してる
ぶっちゃけそんなに使うキーも無いし特定のボタンを特定のビットに対応させてtrueとfalseで、判定させたい時に&で比較して押されてるか確認する

改行多いって言われたから連投する
画像のロードはたぶん誰かがすでに手法の公開とかしてると思うけど
res.h
#pragma once
#include <string>

namespace res {
namespace ID {
enum {
NONE = 0,
TEST_1,
TEST_2,
MAX
};
}

const std::string FILE_NAME[ID::MAX] {
//NONE用
"",
"res/test_1",
"res/test_2"
}

static int FileReadCount[ID::MAX] = {0};

std::string LoadFile(const int ID);

bool UnLoadFile(const int ID);
}

**名前は開発中のものです。** · 2013/10/20(日) 22:57:24.68

res.cpp
#include "res.h"
std::string res::LoadFile(const int ID) {
res::FileReadCount++;
return res::FILE_NAME[ID]
}

bool res::UnLoadFile(const int ID) {
res::FileReadCount--;
if(res::FileReadCount <= 0) {
return true;
}
return false;
}

すまんかなり見辛いな
ヘッダーとcppソースファイルの両方使ってる

それと外部テキストファイルに書き出してそのシーンで使うと思われるのを全てコンストラクタでそのシーン用のリソースが書いてある外部テキストファイルからロードして、デストラクタ時にそのファイルを全て破棄するってのもやってた
けど、前述のソース載せてる方の方が使いやすくて結局そっちだけしか使ってない

今は、今のシーンと次のシーンで同じファイルを使うなら使うファイルだけ破棄しないで使わないファイルは破棄して移行するってのを作ってる

**名前は開発中のものです。** · 2013/10/21(月) 07:52:17.59

これ見てちょっとオサレな多機能マネージャー思い付いたかもしれん
既存のと組み合わせて頑張ってみる

**名前は開発中のものです。** · 2013/10/22(火) 01:16:32.21

クラスでprivate宣言するものは全てcppファイルに書くのってどうなんだろう？

**名前は開発中のものです。** · 2013/10/22(火) 06:39:40.68

hに書いた方がいいんじゃね
cppをいじる時にパッとタブ切り替えた時にメンバ一覧として分かり易いしその程度だけど

**名前は開発中のものです。** · 2013/10/22(火) 07:16:23.97

メンバ定義をヘッダに書くとヘッダの依存関係がな…
実装の隠蔽とか以前に結局pimplとか使わんと作業上の支障が出てしまう。

**名前は開発中のものです。** · 2013/10/22(火) 15:19:36.10

>>534
boostさんをディスんなyo!

**名前は開発中のものです。** · 2013/10/22(火) 16:18:08.16

そういえば、ヘッダでメンバ定義する時の話だけど
メンバに、あるインターフェースクラスのポインタを持たせるときって
①インターフェースのヘッダをインクルードする？
②それともインターフェースの型を前方宣言する？

もちろん、相互に参照しなきゃいけないときは、片方は②を強制される場合もあるけど

**名前は開発中のものです。** · 2013/10/22(火) 17:23:07.33

テンプレートにする

**名前は開発中のものです。** · 2013/10/22(火) 18:00:19.46

>>536
ハーブサッターは②って言ってたな（gotwの7番、理由はコンパイル時間）
俺はよくヘッダ間のinclude関係忘れるからcpp側でも全部includeするけど
STLとかベンダでまちまちらしいし

**名前は開発中のものです。** · 2013/10/23(水) 23:23:36.36

>>520
それだと複数のボタンが同時に押されている場合、効果が相殺されてしまう
例えば上ボタンと下ボタンの両方が押されていると
y--した後に、y++するのでy座標はじっとしたままになる
2行目以降はifではなく、else ifにした方がいいよ

**名前は開発中のものです。** · 2013/10/24(木) 00:30:32.21

>>539
上下同時押しの時に相殺された方がいいかどちらかが優先された方がいいかは好みの問題じゃない？
それより斜め移動の速度が2の平方根の二倍になってるほうが問題あるだろ

ネタにマジレスしてしまったのだろうか

**名前は開発中のものです。** · 2013/10/24(木) 00:55:05.09

まっすぐよりジグザグ移動の方が速いゲームが確かあったな

**名前は開発中のものです。** · 2013/10/24(木) 01:05:12.14

0.9899って地味にいい数値だよな

**名前は開発中のものです。** · 2013/10/24(木) 05:23:32.15

飛行機にしろ自動車にしろ全方位に等速で動けると考える方がおかしい。
結局作りたいものによる。

**名前は開発中のものです。** · 2013/10/24(木) 07:07:41.21

縦横と斜めで三倍の差というのは流石に開きすぎとも思ったけど、クォータービューだと良いのかもな

**名前は開発中のものです。** · 2013/10/24(木) 09:00:36.97

マリオ系のアクションは左右と上下分割した方が扱いやすいし、シレン系とかのマス移動なんかは斜めの速度なんて考慮する必要ないし、
まぁケースバイケースか

**名前は開発中のものです。** · 2013/10/24(木) 10:10:01.88

>>520
これ、例えば環境具体的にして、winならば GetAsyncKeyState 使う等して、要は「その時のキーの状態を見る」って前提があれば
8方向移動でも2行で終わるし、

そうでない場合でも必要なキーがわかってるなら、前提としてこの関数呼び出す時点で複数のキー状態わかるようにしとけば
こうはならないかなと

**名前は開発中のものです。** · 2013/10/24(木) 10:33:48.39

4行ベタがき安定っすわ
マス型じゃなければ大なり小なりキー処理とは別の移動衝突判定作るだろうし
移動量を加算しておくだけ。

**名前は開発中のものです。** · 2013/10/24(木) 14:33:17.42

16要素のベクトルの配列用意してそこから引くってのはどうだろ
斜め移動の時の正規化の手間が一度ですむ
int index = 上ボタン | (下ボタン << 1) | (左ボタン << 2) | (右ボタン << 3);
const VECTOR &v = ARROW_VECTORS[index];

**名前は開発中のものです。** · 2013/10/24(木) 16:57:55.12

>>548
vectorと言うかbitでそれ表して同じ流れってのは昔からある方法

**名前は開発中のものです。** · 2013/10/24(木) 16:59:12.34

あ、ごめんちゃんと見てなかった
>>548 で合ってる。それ昔からある方法の一つ。キー入力に限らず。

**名前は開発中のものです。** · 2013/10/24(木) 17:32:47.33

８方向ってテンキー対応方式で数値化してると、実方向(ベクトルとか)との
互換が案外面倒なんだよねえ

1~9という数値に、数学のベクトル的なセマンティクス持たせるのが難しいから
専用のゴリ変換マッピングをしなければならないという

**名前は開発中のものです。** · 2013/10/24(木) 17:56:17.80

3の商と余りでうんたらって奴？

**名前は開発中のものです。** · 2013/10/24(木) 18:16:10.12

>>548が何が起きているのかまるでわからない

**名前は開発中のものです。** · 2013/10/24(木) 18:16:35.21

>>551
どんなの想像してるかアレだけど、正規化された二軸のベクトルと思えばそんな大変でも無いと思うけど

**名前は開発中のものです。** · 2013/10/24(木) 18:18:01.30

>>553
例えば4ビットそれぞれに意味を持たせて、それで得られる16通り分の定数を配列から拾ってるだけ

**名前は開発中のものです。** · 2013/10/24(木) 18:23:07.69

byte k=0;
k |= 上？8:0;
k |=下？4:0;
k |= 左？2:0;
k |= 右？1:0;
で、kには0から15の16通りの値が決まるから、
配列に方向値の構造体とか予め入れておいて取り出すのような。

**名前は開発中のものです。** · 2013/10/24(木) 18:27:35.86

一度作った後は使い回すだけだと思うけど
いろいろ考えるんだなｗ

**名前は開発中のものです。** · 2013/10/24(木) 18:49:05.84

うーんそれを使うと
if( 上ボタン ) y--;
が
if( 定数==上 ) y--;
みたいな感じになるの？

**名前は開発中のものです。** · 2013/10/24(木) 19:25:19.00

>>558
ifすら使わない
関数ポインタの配列でおｋ

**名前は開発中のものです。** · 2013/10/24(木) 19:29:40.79

というか、何でもかんでもifをアホみたいに並べるのは某バカｋだけでおなか一杯

**名前は開発中のものです。** · 2013/10/24(木) 19:40:35.94

普段そのやり方でやってる人って押してから20カウントごとに移動(選択肢移動みたいなの)とかどう拡張してんの

**名前は開発中のものです。** · 2013/10/24(木) 19:42:29.47

関数＿上　y--
関数＿右　x++
関数＿上右　y--;x++
みたいなのを作って関数ポインタ配列に入れて
関数ポインタ配列「キー入力値」
みたいな感じでアクセスするのか。なるほど

**名前は開発中のものです。** · 2013/10/24(木) 19:42:49.17

swichで定数で飛ばせば最適化がうまく働くんじゃないかね
でも使うのって秒間60回前後だろうし分かり易ければ何でもいいようなと思う反面
どうせベンチに現れない誤差でしかないのに
テーブルだとキャッシュ汚染するんじゃないだろうかと心配もしてしまう貧乏性が情けないわ

**名前は開発中のものです。** · 2013/10/24(木) 19:56:12.67

>>561
キーリピートのこと？

**名前は開発中のものです。** · 2013/10/24(木) 20:05:28.77

>>564
そう。
俺はif(keycount[num]%20==1)
みたいな感じでやってるけど
最初からカウントするなら利点消してそうだし
>>563のスイッチだと見にくくなりそう

**名前は開発中のものです。** · 2013/10/24(木) 21:13:20.89

vsync固定しないやり方でキーリピートってどうやんの

**名前は開発中のものです。** · 2013/10/24(木) 21:18:52.98

vsync関係ないと思うが

**名前は開発中のものです。** · 2013/10/24(木) 21:25:16.84

いや、下記のようにやって
キーリピートのカウンターが６０になってたら1秒経過したことにしたりするんでしょ
vsync待ちしないで全速力でぶん回してたらカウンターが６０になってても1秒経過したことにならないよね

while(1)
{
　　checkKey();
　　calc();
　　draw();
　　flip();
　　waitVsync();
}

**名前は開発中のものです。** · 2013/10/24(木) 21:42:18.44

普通そういう処理って、システムが持ってるタイマー利用して経過時間見るよ。環境によっては無いかも知れないが。
winで言うと、QueryPerformanceほげほげ系の関数

**名前は開発中のものです。** · 2013/10/24(木) 21:48:58.06

>>565
リピートはねー、俺の場合はそこで実装してないんだよね
キーボードとジョイスティックを管理するクラスでやってるので
リピート付きの取得関数と無しの関数をもってて
受け取る側はリピートのこと考えなくていい

**名前は開発中のものです。** · 2013/10/24(木) 21:49:20.44

>>552
それなりに工夫のしようはあると思うけど
たとえば、「9の逆方向」とかがアルゴリズムで処理しにくいよねってこと

あ、いや、まぁ、逆方向なら 10 - 値でいいんだけど、
左右反転とか斜め反転とか、ゲームだといろいろとそういう数学的な処理が
必要になってくると思うから、ベクトルと相互変換できるのセマンティクス無視の
ゴリマッピングメソッドは用意しておいた方がやりやすいよねってこと

**名前は開発中のものです。** · 2013/10/24(木) 21:59:29.58

流れで聞くけど「入力された瞬間」と「押しっぱなし」で動きを変えたいときははどう処理するんだろう
各キー毎に押しっぱなし処理があるから全部に関数_上押しっぱとか作ってられないし…

**名前は開発中のものです。** · 2013/10/24(木) 22:07:04.97

>>572
俺が昔実装した方法で言うと、入力ハンドリングの処理はキーの状態変化とその経過時間をFIFOキューに溜めていくだけにして、
入力に対して何か行動する処理はキューから結果をもらうって方法を取った。

短い時間の押し具合と、長押しや押しっぱなしの判断は、キューから取得したステートで判断てかんじ。

ポイントは経過時間(要件的には時計で言う時間でなくても良い、メインループの経過カウンタでも良い)で判定って所。

**名前は開発中のものです。** · 2013/10/24(木) 22:15:34.16

>>572
いろいろやり方あるけど俺はダブルバッファリング派
前回と今回が違う値だったら押した瞬間

**名前は開発中のものです。** · 2013/10/24(木) 22:44:08.63

あぁ押した瞬間とかの識別方法の話しじゃないんだ。処理を変える方法というか…

キー入力関数ポインタ[16]=｛関数_上,関数_下,…｝
さっき上で話してたやつ。こんなのがあるとして

関数_上()
｛
　if(押しっぱ)
　｛
　｝else
　｛｝
｝
みたいなことしてたら全部のキー関数でif文しないといけないじゃない？
そこで「関数_上押しっぱ」みたいなのを作りたいんだけど
そうするとキー入力関数ポインタじゃアクセスできなくなる…

どういう感じに判別して処理を変えればスマートだろうか

**名前は開発中のものです。** · 2013/10/24(木) 22:55:12.21

ボタンの押下状態を取得する関数に、
引数で「その瞬間のみ」というフラグを立てれるようにしてる。

キーリピートや、10フレーム以上押しっぱなしで真にする、とかも同じような感じで取れる

**名前は開発中のものです。** · 2013/10/24(木) 22:58:26.75

>>575
やりたいことによって違うので、それだけの情報じゃ何とも言えんが例えば

if(押しっぱ) おしっぱ関数ポインタ[キー入力値];
else おした瞬間関数ポインタ[キー入力値];

とか？

**名前は開発中のものです。** · 2013/10/24(木) 23:09:59.81

>>577
それだと「上をおしっぱの状態で右が初めて押された時」とかができないんだよね
そんなの使う時あるの？って聞かれたらなんとも言えないけど…

**名前は開発中のものです。** · 2013/10/24(木) 23:13:14.62

>>578
コマンド入力だな
それなら>>573のやり方がいい

**名前は開発中のものです。** · 2013/10/24(木) 23:13:24.13

押されてたらカウンタをインクリメントしていって
カウンタが１だったら始めて押されてたことにすればいいんじゃ

**名前は開発中のものです。** · 2013/10/24(木) 23:18:48.87

>>580
単純ならそれでいいが、複雑な処理になると死ねる
格闘系のコマンド入力を例にすると
間に変なキーが挟まっても処理できるように、履歴を参照できないとキツイ

**名前は開発中のものです。** · 2013/10/24(木) 23:41:07.44

ああ、そういうことか。
それなら自分が前にやったのは、>573とだいたい同じっぽい。

**名前は開発中のものです。** · 2013/10/25(金) 01:10:12.99

俺は格闘コマンドは入力部分はいじらずに入力を監視するオートマトン用意してるな
受理したら発動みたいな

**名前は開発中のものです。** · 2013/10/25(金) 02:46:25.90

入力履歴はそのまま記録すればリプレイにも使えるしデバッグにも利用できる。

**名前は開発中のものです。** · 2013/10/25(金) 09:05:50.59

>>583
その監視側が履歴を必要とするはずだから、多分それは遠回りな実装。
具体的にコードパス説明してみ

**名前は開発中のものです。** · 2013/10/25(金) 11:25:43.16

テンプレートとautoってどう使い分けんの？

**名前は開発中のものです。** · 2013/10/25(金) 11:58:14.26

>>586
使い分けるも何もテンプレートとautoは全く別
std::vector< std::map<std::string, int> > map_vec;
こういうのがあったとしてイテレータを取るには
std::vector< std::map<std::string, int> >::iterator i = map_vec.begin();
と長ったらしく書かないといけないが、autoで型推論させると
auto i = map_vec.begin();
でいいわけ

**名前は開発中のものです。** · 2013/10/25(金) 12:06:29.04

>>586
勘違いしてる可能性があるから一応念のため言っておくけど
auto型っていう型がある訳ではないからね

**名前は開発中のものです。** · 2013/10/25(金) 12:51:45.87

吐きそう

**名前は開発中のものです。** · 2013/10/25(金) 12:54:36.09

エラーが？

**名前は開発中のものです。** · 2013/10/25(金) 13:00:27.54

コアかもしれん

**名前は開発中のものです。** · 2013/10/25(金) 21:11:21.10

別にイテレータじゃなく適当なクラスのバッファにならないの？型推論で

void hoge(auto a,auto b);
とかでもいいのかなーと

**名前は開発中のものです。** · 2013/10/25(金) 22:18:46.67

template<class T1, class T2>
void hoge(T1 a, T2 b);

**名前は開発中のものです。** · 2013/10/25(金) 23:24:22.57

>>592
それに近い使い方は戻り値のautoかな
しかし確かに>>593みたいな糖衣構文が来ても悪くないような気もするね
ただ、C++のテンプレートだと特殊化が命みたいなとこもあるからなぁ

**名前は開発中のものです。** · 2013/10/29(火) 21:52:21.38

テンプレートメソッドをオーバーロードしたら自動的に
特殊化扱いになるようにしてくれたら良いのに
思わぬとこで「オーバーロードが曖昧です」とか言われても焦る

**名前は開発中のものです。** · 2013/10/30(水) 08:34:18.07

テンプレートってヘッダに定義書かないとダメなの？
せっかく美しく宣言と定義わけて書いてるのに

**名前は開発中のものです。** · 2013/10/30(水) 08:50:47.21

ファイルを分けるなら、ヘッダ内で定義をincludeすればいいだけ。

**名前は開発中のものです。** · 2013/10/30(水) 09:45:57.87

そういえばそんな宣言無かったっけ？正式採用されなかった気もするが

**名前は開発中のものです。** · 2013/10/30(水) 15:47:31.26

他のコンパイル単位でテンプレートの定義あることに期待して
自分のコンパイル単位ではテンプレートの定義をインクルードしないっていう
キーワードは追加されたけど、ぶっちゃけどういう時に使えばいいのかわからん

**名前は開発中のものです。** · 2013/11/05(火) 22:56:36.90

まあいいさ、そのうち、私の解説サイトで
RPGの作り方を解説してみるさ

そしたら、それほど難しくないことが解かることでしょう

**名前は開発中のものです。** · 2013/11/05(火) 23:48:42.84

私のってポナちゃんの？

**名前は開発中のものです。** · 2013/11/06(水) 00:29:19.16

レスが飛んでると思ったら

**名前は開発中のものです。** · 2013/11/06(水) 01:18:53.76

DXライブラリ総合スレと思って誤爆しているんだろw

ゲーム製作云々より自画自賛の解説サイトの宣伝に夢中で
あれがやりたいだのこれをやってみせるだのと
手を動かさず口だけ妄想と自分語りしか出来ないで
複数のスレッドに目をつけては書き込みするタイミングを伺っている

**名前は開発中のものです。** · 2013/11/06(水) 01:29:00.96

複数のスレっつーか
こことあそこがメインフィールドだと思う

今日(もう昨日か)は文体だけで識別することに成功したから
ようやく俺もゲ製の一員になれたような、そんな気分になれたよ

**名前は開発中のものです。** · 2013/11/07(木) 21:31:07.69

なあ、今作ってるゲームの実行ファイルのサイズって何kバイトぐらい？
俺のは280kほど。ちなみに画像とか音声とかは別にしてある。

**名前は開発中のものです。** · 2013/11/07(木) 22:21:58.37

ランタイムを実行ファイルに組み込むか外に持つかで全然変わる。

**名前は開発中のものです。** · 2013/11/08(金) 08:52:56.12

RPGよりノベルゲームの方が作るのは簡単だよ！
だからまずはノベルゲームの作り方から入ったら？

**名前は開発中のものです。** · 2013/11/08(金) 08:57:49.11

文章書かなきゃならないとか……高難易度すぎるだろ……

**名前は開発中のものです。** · 2013/11/08(金) 10:13:29.89

じゃあアドベンチャーゲームとかｗ

つ～かプログラムの作成難易度はノベルゲーム→アドベンチャーゲーム→RPGなんだがな

**名前は開発中のものです。** · 2013/11/08(金) 11:21:11.70

そういえば、文章の難易度は、RPG→アドベンチャゲームー→ノベルゲームかな？

**名前は開発中のものです。** · 2013/11/08(金) 11:51:10.76

戦闘シーンだけ、あるいは探索シーンだけなら、
他ジャンルと比べてプログラム自体が難しいわけじゃないと思うんだよね。

**名前は開発中のものです。** · 2013/11/08(金) 12:23:58.88

シーンの変更もそれほど難しいとは思わないが？

**名前は開発中のものです。** · 2013/11/08(金) 13:40:12.68

それでふと思ったが、ゲーム製作って言うより完全にプログラミングそのものの領分になるけど、
シーンの管理処理とか、表面的に目立たない屋台骨の部分について最初から自分の中で定番化するような物考えて持ってると、
正直どうとでも応用効くよな。

で初心者の人とか、初心者が開いた入門講座みたいな物コピペしてただ覚えたような人だと
その部分が自分の中で定式化出来ないから「難しい、わからない、思い付かない」になるのかなと。

あくまで一般的な話だけど。

**名前は開発中のものです。** · 2013/11/08(金) 14:24:03.36

>>612
シーンの変更というよりは、ミニゲーム２つ3つ作るようなもんじゃん？
もちろん使い回すコードはあるにしてもさ。

**名前は開発中のものです。** · 2013/11/08(金) 15:08:13.78

それぞれのシーンが難しくないならば、ふたつ作るのもたいして変わらない
一桁の足し算を100回やるのは面倒ではあるけど難しくはならないだろう？

**名前は開発中のものです。** · 2013/11/08(金) 15:08:15.81

ソースに文章書き込むなら簡単だけどスクリプトとか文字列操作熟知してないと難しそう
えんいー

**名前は開発中のものです。** · 2013/11/08(金) 20:11:46.11

スクリプトの作成ってインジェクション対策がめんどくさそう
ある程度適当な文法でもエラー出力作ってなかったら通っちゃうだろうし
外部に置くってなると他人に触らせること前提ってイメージがある