DXライブラリ総合スレッドその8

**名前は開発中のものです。** · 2011/04/03(日) 17:17:11.99

Cを習得した程度のスキルでも、
GUIのゲームを比較的容易に作成する事を可能にする、
「DXライブラリ」に関するスレッドです。
DXライブラリに関するテクニックなどの情報交換などを行う事で、
多くのDXライブラリユーザのスキルの向上に役立てたら幸いです。

【公式】
http://homepage2.nifty.com/natupaji/DxLib/

【過去スレ】
DXライブラリ総合スレッド
http://pc11.2ch.net/test/read.cgi/gamedev/1197468399/
DXライブラリ総合スレッド 2008
http://pc11.2ch.net/test/read.cgi/gamedev/1224923873/
DXライブラリ総合スレッドその3
http://pc11.2ch.net/test/read.cgi/gamedev/1238429676/
DXライブラリ総合スレッドその4
http://pc11.2ch.net/test/read.cgi/gamedev/1249822550/
DXライブラリ総合スレッドその5
http://pc11.2ch.net/test/read.cgi/gamedev/1259912953/
DXライブラリ総合スレッドその6
http://hibari.2ch.net/test/read.cgi/gamedev/1267108154/
DXライブラリ総合スレッドその7
http://hibari.2ch.net/test/read.cgi/gamedev/1286180687/

**名前は開発中のものです。** · 2011/07/16(土) 09:25:09.75

細かいこと気にしすぎて進まなくなるよりはがんがん作って経験積んだほうがいいんじゃね
それとそんなに初心者の事考えてやれるなら作り方でもTIPSでもアルゴリズムでも設計方法でもブログなりwikiなりにアップしてやれｗ

**名前は開発中のものです。** · 2011/07/16(土) 10:36:00.59

GC付き言語は初心者を狂気の沙汰へ誘うけどな
フレーム更新のたびにnewしまくりとか

**名前は開発中のものです。** · 2011/07/16(土) 10:48:06.74

Cで書いてるったってC++コンパイラ使ってるんだろ?
コーディング量だってテンプレートライブラリ使うだけでも激減するし
変数を途中で宣言とか名前空間だけでも有用すぎる。
わざわざ純粋なC言語として書いてコンパイルする必要性も無い。

**名前は開発中のものです。** · 2011/07/16(土) 10:48:09.60

D言語ですねわかります。

**名前は開発中のものです。** · 2011/07/16(土) 10:58:50.91

Dなら効率的に書けるかわりに言語仕様の破壊的変更でコードそのものを粉砕してくれるよ！

**名前は開発中のものです。** · 2011/07/16(土) 11:20:23.22

D言語使ってる連中こそ宗教団体のようできもい。少ない仲間を集めて集会開いてるイメージ

**名前は開発中のものです。** · 2011/07/16(土) 11:40:46.67

そうだな
構造体に関数いれてみたら、なんと動いてしまったからな

俺はcだけをつかってるつもりで、知らず農地にc++を使っているのかもしれん

**名前は開発中のものです。** · 2011/07/16(土) 12:10:07.20

>>772
え？

**名前は開発中のものです。** · 2011/07/16(土) 12:35:42.10

コストとか本人の問題だし、Cに拘る必要が無いのもわかるけど
Cを理解せずにC++なんて無謀にも程があるからな
Cでゲーム作れとまでは行かなくても十分理解するための経験は必要

ところでおまえらは誰と戦ってるんだ。俺は初級者向けの話をしてるもんだと思ったけど

**名前は開発中のものです。** · 2011/07/16(土) 12:43:01.85

そら、あの方に決まっているだろう

**名前は開発中のものです。** · 2011/07/16(土) 12:51:32.03

メンバに関数持てるってだけで柔軟性が飛躍的に増すからな
そのためだけでもC++にする価値はある

**名前は開発中のものです。** · 2011/07/16(土) 13:06:31.10

C++を特別視する思考がサッパリ理解不能なんだが
C++は基本的にCを内包してるんだから、C++を選んで必要な部分だけを使えばいい
>>781みたいな考え方こそ初心者には害悪

**名前は開発中のものです。** · 2011/07/16(土) 13:14:54.83

アクセス権を学べないCから入ると設計をいちいち勉強し直さなければならないし、ここでへんな癖がつくと後々厄介
C++から入ればJAVAでもC#でもASでもあっさり習得できる。この３言語は使えるとなにかと便利
問題点は複数プログラマで作るときに規約をがっちり決めとかないといけないことぐらいなので個人製作ではまず問題にならない
わざわざCから始めるくらいならその時間でアセンブラかじったほうがゲーム制作にははるかに有益だよ

**名前は開発中のものです。** · 2011/07/16(土) 13:20:23.44

そろそろ

**名前は開発中のものです。** · 2011/07/16(土) 13:24:30.76

名人様、布教活動ご苦労様です。

**名前は開発中のものです。** · 2011/07/16(土) 13:29:09.59

>>787
お前は誰と戦ってるんだ？？？

**とんちゃもん** · 2011/07/16(土) 13:32:11.97

C++は最初は全部publicなクラスだけ使ってればいいと思いますね。
継承とかはあとあと覚えたら使うぐらいの気持ちで
とりあえずファイル拡張子を.cppにしておけばいいのですよ。

あとはjavaを少しずつ学んでいると
クラスのパターンとか名前のネタや無名クラスの使い方とかが身につくかも。
ちなみにC#ではなくjavaなのはググったときの情報の質です。。

**名前は開発中のものです。** · 2011/07/16(土) 13:38:42.88

経験積んでから～なんて言ってたらいつまでたっても始まらんよ。
案ずるより産むが易し。迷わず行けよ。行けば分かるさ。

初心者はまず手を動かすこった。

**名前は開発中のものです。** · 2011/07/16(土) 14:43:19.45

C++の細かい内容は
「うーん、○○したいけど上手く行かない・・・何か良い方法ないかな」
って思ったときに参考書パラパラめくる程度でおｋ

**名前は開発中のものです。** · 2011/07/16(土) 14:48:06.67

ほんとLoadGraph関数って面倒事起こしまくるな

なんで他の値は全部格納されてるのに、画像ハンドルだけ格納されてないんだ
ステルス機体ばっかじゃねーかよ

**名前は開発中のものです。** · 2011/07/16(土) 15:36:24.67

>>792
戻り値が-1になってないか？

原因としては
・初期化前に呼んだ
・ファイルのパスが間違ってる
・そもそも戻り値を取得してない
・取得はしたがスコープが変

って感じだと思うぞ

**名前は開発中のものです。** · 2011/07/16(土) 16:34:48.36

>>792
超初心者だけど俺も詰まった所
そしてあれこれ考えるのが嫌でDeleteしてからLoadするように組み合わせた
ググればもっといい対処方法がみつかったりもする

Deleteせずに同じ画像ファイルをなんども呼び出したり
Deleteのタイミング次第で、意図しないハンドルが消える

**名前は開発中のものです。** · 2011/07/16(土) 16:38:59.05

そもそもDeleteせずに同じ画像ファイルを何度も呼び出すのが良くない
そんなことやらないからどんな不具合が生じてるのか分からんけど

**名前は開発中のものです。** · 2011/07/16(土) 16:44:32.96

>>795
当初は

func()
{
gazou1=LoadGraph()

**名前は開発中のものです。** · 2011/07/16(土) 16:47:02.07

途中で送信してしまった

といった感じの関数を作り、同じ画像ファイルを呼び出だしたとしても
入れる変数は同じだから上書き保存！的な処理にしたつもりだった

まぁ、792がどういった感じで詰まっているかは知らんけど

**名前は開発中のものです。** · 2011/07/16(土) 16:48:35.02

>>797
それアウト
Deleteしないとメモリ領域が開放されないから、重複読み込みはそのままメモリリークになる

**名前は開発中のものです。** · 2011/07/16(土) 16:49:47.29

>>798
あ、ちょっと使ってるバージョンが古いから最新版では対策入ってる可能性もあるけどね

けど、動的に確保されたものはきっちり解放する癖をつけないとメモリリークに悩まされるよ

**名前は開発中のものです。** · 2011/07/16(土) 17:00:08.86

自前のCreateとDeleteするクラスor関数作って
mapでファイル名キーで参照カウンタ変数とハンドル保持して
Createで読み込み済みならそのハンドルでなければ新規読み込みしてカウンタ+1
Deleteでカウンタ-1してカウント0なら削除
という仕組み作ればOk

外部でdeleteされる対策とかスマートポインタみたいのは難易度あがるから言語が使えるようになってから。

**名前は開発中のものです。** · 2011/07/16(土) 18:15:05.42

何というか、やっぱメモリ領域の概念に関して「だけ」はきっちり理解しておいた方がいいんだろうなと思った
>>797みたいに落とし穴にはまって気付かないこともあるわけで

だからといって>>781みたいな意見には全く同意できないがｗ

**名前は開発中のものです。** · 2011/07/16(土) 18:19:43.25

ってか、使い終わったリソースって、開放しないのが初心者なのか
それ以前に、せっかくメモリに確保したハンドルを使いまわししないで
新たに同じ画像を読むというのが、どうしてそういう処理するのか理解できん

ゲームの基本処理って

データのロードと作成
↓
操作とか当たり判定とかの処理
↓　↓（ループ）↑
↓　画面の描画
↓
後片付け

って流れだと思うんだが、もしかして
AVG形式のエンジン部分で、1フレーム毎に必要な
画像をメモリにロードするとかって作業をしてるのか？

**名前は開発中のものです。** · 2011/07/16(土) 18:24:55.55

>>802
毎フレーム読み込みってのは初心者が一番最初にやらかすことはあるみたい
まあそれは流石に重くて気付くことが多いみたいだけどね

けど頭にメモリの概念が無いと、新たに画像を読むっていうことを躊躇無くやってしまうんじゃないだろうか
メモリ関係のバグは厄介だし、メモリに関しては概念くらいは理解しておいた方がいいと思う

**名前は開発中のものです。** · 2011/07/16(土) 18:27:33.65

CありきのC++だと言いたかっただけなのに
そりゃ俺だってC++なしでゲーム作ろうなんて微塵も思わないしやったこともないからｗ

**名前は開発中のものです。** · 2011/07/16(土) 18:29:59.03

LoadAllGraph( int Stage )
{
//すべてのハンドルに対してDelete
DeleteGraph( Handle1 );
DeleteGraph( Handle2 );
DeleteGraph( Handle3 );
…

switch( Stage )
{
case 0:
Handle1 = LoadGraph();
Handle2 = LoadGraph();
…
break;

case 1:
Handle1 = LoadGraph();
Handle3 = LoadGraph();
…
break;

…
…
}

へたれ趣味グラマだからシーンごとにこういう関数呼んでる

**名前は開発中のものです。** · 2011/07/16(土) 18:30:21.67

＞AVG形式のエンジン部分で、1フレーム毎に必要な
＞画像をメモリにロードするとかって作業をしてるのか？

それに近いことをやる事になっているな
ドット絵なんだけど1キャラあたり　400ｘ400　1動作あたり10モーション　1キャラあたり8動作　300ｘ300の画像が8*10で80枚
（数字は大袈裟にしているがそんな感じ）
そういうキャラを数十体同時に出そうとして、始めに画像情報を全部読み込んで～ってプランは早々に変更することになった

普通はそんな作りにしないんだろうけど

**名前は開発中のものです。** · 2011/07/16(土) 18:32:56.94

ポインタを理解しようとしたらメモリに対して理解深まるよ

**名前は開発中のものです。** · 2011/07/16(土) 18:38:16.42

>>805
俺は使う画像と使わない画像をフラグで管理して、立ってるものは読んで立ってないものは消すようにしてる
画像は管理用のクラス作って、自分がいじるのはそのクラスの内容

プログラム初期化時、画像管理クラスにファイルアドレスをセット。
別に画像管理クラスへのアドレスを一覧としてまとめた配列を用意して、ファイルアドレスセット時にこの配列にクラスのアドレスを登録
読み込み/消去はこの配列を利用してイテレート

ってやって取りあえず冗長な部分はなくせたと思う

**名前は開発中のものです。** · 2011/07/16(土) 18:43:54.57

概念的にはこんな感じ

class csImageInfo{
　char *addr;
　int Flag:
　public:
　int Set(char *addr);
};

class csImage{
　csImageInfo *list[num_max];
　public:
　int Update(){
　　for(int i = 0 ; i < num_max ; i++){ ... }
　}
};

**名前は開発中のものです。** · 2011/07/16(土) 18:47:06.91

>>805と>>808がよく言われる
完成一歩手前知識不足製作者
と
知識ばかりで実際にゲーム製作は頓挫する奴
の構図に思えるwwww

**名前は開発中のものです。** · 2011/07/16(土) 18:50:40.65

>>810
凄い節穴だなｗ
残念だけど、完成させたことくらいあるよｗ

ってか俺はずっと考えるよりも行動することが大事だって言い続けてるんだがｗ

**名前は開発中のものです。** · 2011/07/16(土) 18:55:34.93

むしろ「知識があるだけ」と「実践的なコードが書ける」の区別も付かない>>810は節穴ってレベルじゃない。
差詰め『「知識ばかりで実際にゲーム製作は頓挫する奴」をただ笑って何もしない野次馬』ってところか。

**名前は開発中のものです。** · 2011/07/16(土) 19:16:33.63

ID:0cJOmXZJにプログラムの技術がほとんどないってことだけはよく分かった

ずれたツッコミって怖いね。うっかりすると自分のバカさ加減をさらけ出してしまう

**名前は開発中のものです。** · 2011/07/16(土) 20:15:58.09

>>805
俺もほぼそれ
せめてシーンをクラスに分けて、ロードとアンロードできないか考えているが
今は別のことをしている

**名前は開発中のものです。** · 2011/07/16(土) 20:23:28.48

>>805
どう考えてもそれで十分。

**名前は開発中のものです。** · 2011/07/16(土) 20:34:33.66

私はRAIIでやってますね

**名前は開発中のものです。** · 2011/07/16(土) 20:36:47.12

>>805
それで十分なんだよね
なんかあれこれやってより高機能にしたがる人がいるけど

力を入れるところはそんな所じゃねーだろｗと良く思う

**名前は開発中のものです。** · 2011/07/16(土) 21:15:27.69

一番最初に作ったゲームは

if(scene==0)
{
　//タイトル画面
}
else if (scene==1)
{
　//プレイ画面
}

だったなあ。
第2作目でやっと関数分けされた。（それでも分岐はifのまま）

**名前は開発中のものです。** · 2011/07/16(土) 21:17:18.56

まあ作ってるゲームによるよね
ビッグスケールだと>>805の方法じゃ破綻するし

**名前は開発中のものです。** · 2011/07/16(土) 21:28:32.19

>>819
805で破綻するようなスケールを作ろうとする事が一番破綻する原因だと思うのｗ

数十時間プレイするような商業レベル物でも目指しているのかよｗってね

**名前は開発中のものです。** · 2011/07/16(土) 21:58:08.35

この手の資源管理方法は個人レベルだろうが商業レベルだろうが変わらんよ
出来る奴はできるし出来ない奴は>>805みたいにとりあえず動くものでお茶をにごすのが正解
俺は表示リスト作って呼ばれなくなったものから消すようにしてる（一般的なキャッシュアルゴリズムと同じ方法）
今のグラフィックカードを基準にするとよほど無駄なグラフィックの使い方をしない限りDeleteGraphなんて使う必要もないんだけどね

**名前は開発中のものです。** · 2011/07/16(土) 23:11:15.66

読み込み量がたいしたことないなら
画像と効果音だけ最初に全部読み込んでもいいと思う。
BGMなんかはサイズがでかいから全部ってわけには行かないけど
特別な使い方しないならストリーミングで再生できるし。

**名前は開発中のものです。** · 2011/07/17(日) 00:15:06.41

シーン毎に読み込みと解放するだけだわ

**名前は開発中のものです。** · 2011/07/17(日) 00:31:37.25

人が書いたソースを見るだけでその人の部屋の散らかり具合が
だいたいわかるようになった

**名前は開発中のものです。** · 2011/07/17(日) 00:35:45.23

あとはダブルポインタっていうやつは
だいたいiphone持ってる
これ定説

**名前は開発中のものです。** · 2011/07/17(日) 00:36:17.63

>>793
ついこの前に質問したんだけどね
前に言ってくれた>>701みたいにやってたんだよ

で武器データも欲しくてShip_t Ship(int a, int b){ return Ship[][] }みたいな感じで
Sshot_t Sshot(int a, int b){ return Sshot[][] }で作ることはできた

この二つをセットにしたくて
typedef struct{
Ship_t Ship;
Sshot_t Sshot;
}ShipPare_t;
ShipPare_t ShipPare[5][10]={
{{Ship(0,0), Sshot(0,0)},{Ship(0,1), Sshot(0,1)},{Ship(0,2),Sshot(0,1)},
};
ていうのを作って、引数で&ShipPare[][]渡すだけで船体と武器のデータを得ることができるようにしようと思った
んだが画像だけロードされなかった
今の俺のレベルで考えられる原因は、使う時にShipPareP->Sshot.image;って感じだから
結局ロードされてないんじゃないかって思ったりした

お願いします

**名前は開発中のものです。** · 2011/07/17(日) 00:37:19.82

一体何人のソースと部屋を見て統計をとったのだ。

**名前は開発中のものです。** · 2011/07/17(日) 00:50:18.31

>>826
つstatic
Cなんて一度忘れて素直にC++勉強しろってば
データの動的管理を根本的に理解できていないからLoadGrpなんかで問題起こすんだよ
自分の無能をいちいちライブラリのせいにされるのを見るのはいい加減うざい

**名前は開発中のものです。** · 2011/07/17(日) 01:35:00.08

>>826

構造体の初期化は関数のなかでやらないと。
void f(int a, int b){
static ShipPare_t ShipPare[5][10] ={{ ship(0, 0), Sshot(0,0) }};
return ShipPare[a][b];
}

まあ、これでなかでLoadGraph呼んでても
DxLib初期化したあとにこの関数が呼ばれて
LoadGraph成功するけどさ。
ふつうはこのやりかたはしないな。

**名前は開発中のものです。** · 2011/07/17(日) 02:21:32.77

>>829
・・・
そうだった、今日で思い知ったわ
でも動いたよ、ありがとう

ゲーム作り始めて１カ月だからノウハウとか全くない
本当は正当なやり方とかしてみたいけどさ、まとまった情報がないんだな

**名前は開発中のものです。** · 2011/07/17(日) 02:51:08.36

ゲーム作りかC++とDXLibを始めて3ヶ月だが、独学と資料はネットだけでも十分な物ができあがるぞ（正当なやり方なんて気にしたら負け）
ただ、ゲーム製作を投げ出す最初の壁みたいな物にぶつかった

プログラミング的に困っているわけじゃないけど、あれもこれもと作業が増えてきて
ゲーム製作の一番の醍醐味であろう色々な数値設定を決める部分の面倒さに投げ出したくなってきたｗ

「あの武器は攻撃力15ぐらいでいいだろ」
「あのユニットの価格は300Gでいいだろ」
「キャラ名。アイテム名。町の名前。スキル名」
あんな敵こんな敵。こんな攻撃。あんなスキル。こんな弾幕。あんなステージ。こんな敵配置etc

作る前は一番楽しい部分のはずだったのに、0から設定＆全キャラ設定となると超面倒という事を思い知らされた
そして糞バランスゲーができる原因を痛感させられたｗｗｗ

**名前は開発中のものです。** · 2011/07/17(日) 03:02:11.88

それわかる。
でも人と組んでゲーム作るのもわずらわしいジレンマ。。。

**名前は開発中のものです。** · 2011/07/17(日) 03:06:30.08

初心者が初心者に語っちゃだめだろ
何をわかった気になってんだよ

**名前は開発中のものです。** · 2011/07/17(日) 03:18:47.11

はしかみたいなもんだが
自分の黒歴史を掘り返されてる気分になる

**名前は開発中のものです。** · 2011/07/17(日) 03:52:53.44

同レベルぐらいの人のが目線を合わせて会話出来るからいいな
自称脱初心者様は役に立たない

技術的な事を掘り下げた話をしたいならプログラム板か
外部のそれ系の所で聞いた方が良い

2chは行き詰まった時の
「初心者プギャーwwww」
「あるあるwwww」
「知識だけでゲーム公開できねぇ雑魚wwwww」
とモチベを上げる場所

**名前は開発中のものです。** · 2011/07/17(日) 03:59:52.20

解説サイト作ろうと思ったがDxLibとVC++のインストールと設定だけで
めんどくさくなってきたｗ

**名前は開発中のものです。** · 2011/07/17(日) 04:20:08.41

こんな感じで
ttp://www.rupan.net/uploader/download/1310843423.zip

pass:sage

**名前は開発中のものです。** · 2011/07/17(日) 04:20:43.47

それは公式に解説あったようなw
龍神録プログラミングの館で入門は十分かなって感じだし
作るなら中級レベル向けがいいかもね

**名前は開発中のものです。** · 2011/07/17(日) 04:22:35.48

>>838は>>836のレスで

**名前は開発中のものです。** · 2011/07/17(日) 04:39:54.41

>>805方式の具体的な問題点って何？

**名前は開発中のものです。** · 2011/07/17(日) 04:52:48.10

>>840
ソフトの規模が大きくなると管理が大変になってバグが発生しやすくなる
>>820みたいなこと言ってる奴いるけど、普通にでかい規模の作品作ってる奴とかいるだろ
視野が狭すぎ

っていうかぶっちゃけUcTd5altはド素人なのに一体何を言ってるんだ、って印象ｗ

**名前は開発中のものです。** · 2011/07/17(日) 05:05:36.22

>>838
そうだね。。。でも中級ってどのくらいの人だろ？
Cでテトリス作れるけどC++で画面遷移のswitch文消したいとか
そう言う人には実際にアプリを組む流れを見せたいし、
Direct3D9知らないけどチューニングの大まかなコツ知りたい人には
プログラミングチップスがいいと思う。

**名前は開発中のものです。** · 2011/07/17(日) 05:07:47.47

お願いですから ID:UcTd5alt と書いてください。

仕様書(excel)などから自動でコード吐き出すような事してると普通に>>820みたいな記述になるけどなw
文字列リソースとかww

**名前は開発中のものです。** · 2011/07/17(日) 05:13:24.57

まあそんなに規模大きくない程度のものなら805で十分ってことだろ
規模が大きいものってなってくるとそれはまた別の話ってだけ

**名前は開発中のものです。** · 2011/07/17(日) 05:18:27.62

>>841
できればもう少し具体的に。

例えばStage数が増えると管理が面倒臭いとか。
これだと逆に言えばStage数が少なければ問題はないってことになるよね。
一般的にSTGならStage数は10以下だろうし、RPGなどでStage数をシーン数に置き換えても
多分５～６までに収まるんじゃないんだろうか。

**名前は開発中のものです。** · 2011/07/17(日) 05:23:55.08

>>845
で、お前は何がしたいわけ？
もう結論出ちゃってます系の人なんじゃないの？

**名前は開発中のものです。** · 2011/07/17(日) 05:24:56.49

>>840
シームレスな動作にこだわりがあるかどうか
場面転換ごとにいちいちブラックアウトすることやフィールドがいくつかに分断されてても疑問を感じないのならば問題はない
俺はステージの繋ぎで一フレームも落としたくないので>>805みたいなシーン管理はやってない

**名前は開発中のものです。** · 2011/07/17(日) 05:27:14.77

switchを使わない書き方をしろっていうことなのかな、よう分からんが
まあそれなら書きようがあると思うけど

**名前は開発中のものです。** · 2011/07/17(日) 05:29:18.32

てか>>805みたいに管理したい奴はしてればいいんじゃね？
ある程度慣れるとそっちのが手間だから、一回ちゃんとしたクラス作るのが普通だろうけど

>>805のやり方で困らない奴はその程度なわけで

**名前は開発中のものです。** · 2011/07/17(日) 05:29:45.40

まあ別に作る人毎に仕様が異なるんだから805で足りる人もいれば805じゃまずいって人もいるってだけでそんな大した問題じゃない気がする

**名前は開発中のものです。** · 2011/07/17(日) 05:33:10.51

実際にそこまで大規模な物を作っている人っているのか？
構想だけでそんなでかい規模のゲームなんてフリーはもちろん、同人でも中々見かけないぞ

ACT、STGなら6面
スクロール無しの1画面ACTパズル系？は30面ぐらい
RPGならDQ1弱（街少々洞窟少々。全体マップ小規模）
SLGなら8マップ程度

この規模でもちゃんと最後まで完成させたら賞賛する
この半分の規模でも完成させたら超糞ゲーでも拍手を送る

**名前は開発中のものです。** · 2011/07/17(日) 05:33:54.00

>>847
ああ、シームレスにする場合は
こうやって一気にロードするやり方じゃダメなんだな…

**名前は開発中のものです。** · 2011/07/17(日) 05:34:54.77

俺なら、大規模ゲーなら挙動は自作のスクリプトに書き出してるだろうし、
そのシーンで使う画像をスクリプト舐めて抽出してそれを読み込む、って感じでやるだろうなー
もしくは、シーンに関連付けた使う画像リストを外部ファイルで作る

大規模ゲーなのにプログラム直書きで画像を読み込むのが前提なのがおかしいと思う

**名前は開発中のものです。** · 2011/07/17(日) 05:41:08.12

まあ>>805の何が悪いって、>>849もちょっと言ってるけど生産効率
使い回し効かないしコピペで時間はかかるし修正するときに大変だしバグは出やすいしで良いことがない
最初から仕様がガチガチに固まっていて後で変更が絶対に起きないならまだいいけど、
何か仕様を変更したくなったときにこういう書き方だと大変なことになる

そもそも専用のクラス作ったとしても小一時間もかからんし、あとで使い回しが効くから最終的な効率は断然良い
まあ技術的な問題でクラス作るのに時間がかかるようなら無難に>>805の方がいいかもしれないけど

基本的にコーディングってのはスマートなやり方が一番作るの早いわけだから

>>851
その規模のを完成させてるし、委託販売もしてる
同人ならその規模で当たり前だろ。まあ俺がその規模の作品しか視野に入れてないって可能性も否定できんが

**名前は開発中のものです。** · 2011/07/17(日) 05:41:24.97

プログラミングを始める前
「ツクールゲーwww」
その後
「ツクールだろうがゲームを完成させた奴は俺より上」

1面作ったらそれで満足
ゲームと呼べるボリュームまで作り込む奴は偉い

**名前は開発中のものです。** · 2011/07/17(日) 05:51:05.57

>>854
いや、その規模なら805で済むという話であり、よくある同人レベルであって
大規模クラスっていうからそれ以上の物なんてそうそう見かけないというわけで・・・

それ以上のボリュームの同人ソフトで委託しているというとよくバナーでみかける東○のローグゲーでも作った人なんか？

STG、ACTでいえば6面ぐらいが個人製作目安で、それ以上は人が集まってガチ製作している集団だと思っている
そして集団でゲームを作っている人が、個人製作基準で語っている人が多いであろうこのスレで
集団製作基準であれこれ言っているとしたらちょっとKY

**名前は開発中のものです。** · 2011/07/17(日) 05:52:08.82

結局クラスって資産なんだよな。
俺は5年前に作ったユーザー入力を管理するクラスを今でも使い回してるわｗ

最初のうちは仕方ないけど、ある程度力が付いたら絶対に再利用を前提に作った方が良い。
開発のスピードが半端無く上がる。

**名前は開発中のものです。** · 2011/07/17(日) 05:54:12.32

いや、規模ってステージ数じゃないだろ
例えばポケモンみたいなゲームを作るとすると、モンスター画像が百以上必要になる
またそうなるとそれを配置するマップもそれなりの枚数になる
そうなると……って感じに考えた上で作業量が多くなるのがゲームの規模ってもんじゃないのか？

**名前は開発中のものです。** · 2011/07/17(日) 05:56:30.45

>>856
そもそもSTGは個人だろうが同人だろうが商業だろうが5～6面が目安です。どうでもいいツッコミだけど
あと別に集団製作基準なんて言ってないけど？
技術無い人はベタ書きすればいいし、ある人は論理的に作った方が都合がいい。ただそう言ってるだけなんだけど

**名前は開発中のものです。** · 2011/07/17(日) 05:57:13.52

ところで、今まさにこの瞬間にライブラリが更新されたよ

**名前は開発中のものです。** · 2011/07/17(日) 06:04:33.80

覚え方は人それぞれだがいきなり便利だからとクラスを理解させるのは反対だな
最初はとにかくわかりやすく、そうして「もっと汎用性と利便性を～」と不満を持ち始めた時
自ら新しい技術を求めて覚えた方が身に付きやすい

しかし形から入った方が覚えやすいと言う人は
本と一緒に覚えた方が無駄が無いから、最初から全部覚えた方が良いはず

結局、規模、コード共に熱意が冷めない物を選ぶのが一番重要
冷めた時点でゲームオーバーだから

**名前は開発中のものです。** · 2011/07/17(日) 06:04:43.76

何かざっと見てみたけど、まとめる力のない人間があーだこーだと屁理屈並べてるようにしか見えない。
どう考えたって小綺麗なプログラムを手早く書けるならそっちの方がいいわけで、それを否定すんのはおかしな話だろ。
それができないって理由で>>805みたいな書き方をするのは別にいいと思うよ。
でもできないのに>>805を正当化すんのはあまりに見苦しすぎるだろ。

**名前は開発中のものです。** · 2011/07/17(日) 06:08:34.72

>>861
概ね同意なんだけど、俺は別に冷めてもいいんじゃないかと思ってる
熱して冷めての繰り返しで段々前進していくわけだから
逆に熱しすぎた後に反動が来たりしたときの方が大変。ゲーム作りなんて長丁場だし、ずっと熱しぱなしって方が無理があるよ

**名前は開発中のものです。** · 2011/07/17(日) 06:17:52.38

まぁプログラミングって顕著に出来る出来ないが分かれるからな
このスレにも出来る人間と出来ない人間が混在してるわけで、そりゃ話も通じないだろうよ、と

結局、自分の技量にあった作り方をするのが一番
でも向上心を忘れたら終わりよ

**名前は開発中のものです。** · 2011/07/17(日) 06:21:50.27

同人で売り物レベルの作品を作るならそれでもいいけど
個人の趣味は冷めたらおしまい

集団製作っぽいけど、その場合良くも悪くも自分の担当という責任が発生するから
冷めても進まなければならないでしょ？

売り物ってのは今時なんとも思わないが
実際に絵や音楽担当と分業したプログラミングは怖いな
スランプやバグでハマったらどうすればいいんだろ

極端な話、絵や音楽は他人を使うで済むが
自分の糞コードを他人に引き継ぐなんて無理！

**名前は開発中のものです。** · 2011/07/17(日) 06:23:28.55

>>860
ちょ、マジだ。
http://homepage2.nifty.com/natupaji/DxLib/dxlog.html

関数がいくつか追加されてらぁ～。
ありがたやありがたや。

**名前は開発中のものです。** · 2011/07/17(日) 06:26:33.79

個人は貴重な時間費やしてるから成果物が目に見えないと萎え萎えだろん？

**名前は開発中のものです。** · 2011/07/17(日) 06:27:40.89

>>865
それ逆だわ
個人の趣味だったら冷めてもあとで暖まればいいけど、集団だったら責任問題だから冷ますわけにはいかない
「進まなければならない」で進むほど集団製作は甘くない。そうなったら高確率で空中分解する
企業レベルになると流石に話は変わるが

個人の製作なんて冷めていいんだよ。冷めちゃいけないなんて思うから重荷になる
冷めたって製作が好きならまた暖まる。暖まらないなら、所詮その程度の気持ちだったってことさ
暖まった後でコードが訳分からなくなったならまた作り直せばいい。前より上手く作れるから

**名前は開発中のものです。** · 2011/07/17(日) 06:33:37.76

シームレス以外の問題点は例えばどんなのがありそう？

**名前は開発中のものです。** · 2011/07/17(日) 06:38:28.12

＞集団だったら責任問題だから冷ますわけにはいかない
責任問題と重圧だけで冷めないもの？
表面的には頑張っていても冷めた（そこまでいかなくてもモチベダウン）らどうするの？
こればかりは精神面・肉体面・本業の多忙さ等で同人といえども維持が難しい所では

個人製作のモチベ維持に役立つかもしれないから、同人製作のモチベ維持方法についてｋｗｓｋ

仕事が多忙になって週末ぐらいしか弄れなくなると一気に熱が冷めるのが一番の悩みの種
再開すると継続せず、再出発してしまう

**名前は開発中のものです。** · 2011/07/17(日) 06:51:28.30

>>870
集団製作については、正直冷めるかどうかは指揮取ってる人間の力量次第だと思う
メンバーが冷めたりするのを監督者がきちんと把握して冷めない方向に誘導できるかどうかが鍵
まあ監督経験そんなに無いから上手い方法に関しては語れないけど。基本一匹狼だしｗ

そういうわけで個人製作のモチベ維持の話になるんだけど、自分の場合はユーザーとのコミュニケーションかな
自分の作ったものに対してリアクションがあるとやっぱりモチベ上がるよ
あとは自分の成長を逐一実感するとか。「ああ、今回この部分は前より上手く作れたな」ってのが地味に楽しい

俺も週単位で触らないときとかあるけど、モチベ回復させるのに困ったりはしないかなあ
間が開いたときには、やっぱりコードをある程度分かりやすく書いてるかどうかってのは大きいと思う
そういう意味で、身の丈にあった規模を目標にするってのは大事かも
技術が無いのに大規模なものを作ろうとしたら、コードが訳分からなくなってリセットの可能性が高そう

**名前は開発中のものです。** · 2011/07/17(日) 06:57:02.75

と読み返してみて、たまには身の丈に合わないものを作ってみるのも大事なのかな、とも思った
身の丈に合わないと色々と歪みが生じるわけで、その「歪み」を把握しておくことが、
後々に上手くやる方法を考え出すきっかけにもなるんだと思った。自分の例ではだけど

DXライブラリ 総合スレッド その8

DXライブラリ総合スレッドその8