C++でＦＣのドラクエっぽいＲＰＧを作る

携帯はC言語だろ

このスレも終焉を迎えているようだな
この板の流れはいつもこうだ

>>933
おいおい。
いつの時代の話だｗ

今の携帯は、jarも100KBが最低線、MBアプリが標準の一角に入り込もうとしている状況だよ。
携帯/PC両用のJavaライブラリ（DoJa/MIDP2.0/Java2SE対象）だって、十分現実的（実際、やってみたことがある）。

>>936
どんなしょぼいアプリなの？
仕事でやってたら普通にキツキツ

>>936
似非オブジェクト指向乙

どんだけプログラムができる連中なのかは知らないが
スレ違いの話題で馬鹿みたいに盛り上がってるのを見ると
人間的には・・・だな
傍から見ててみっともない

>>939
まぁもちつけ。
スレの頭から読み直せ

1ってもう一週間くらい来てないのか？俺もゲーム作るの遅いけど頑張ろうぜ！！

はなす >>1
へんじがない。ただのしかばねのようだ。

選ぶのはC++でいいんじゃない？
どのみち色んな言語渡り歩くんだろうし。

スレ違いとも言われないしなｗ

なかなか修正が終わりません。
作業時間が減ったのも要因ですが、やっぱり力不足と作った関数の流れを忘れていて作業効率が落ちている感じです。

フィールドのFlipScreenを一つにまとめる、ということで修正してますが
メッセージコマンドの扱いで悩んでます。
扱いというか、文字の表示の仕方、っていうんですかね？

それとクラス構造で迷ってます。
シーンはオープニングと移動と戦闘の三つ。
FieldクラスとBattleFieldクラスの親クラスとして抽象的なクラスを作り、それを継承したOpeningFieldクラスを追加。
それぞれに対応したAgregateCommandクラスを持ち、
キー入力を受け付けるcontrol()関数と、描写を行うdraw()関数を実装する。

なんかよく分からない文章になってます。通訳が必要かもしれません。Orz

今までの今までの成果物上げておきます。
あと極端な脱線はスルーしますが、今まで位の脱線は好きです。
書き込みが無いのは分からない単語を少しずつ調べて飲み込もうとしてるからです。

へたれな１ですが、まだまだ続けます。よろしくです。
tp://sakuratan.ddo.jp/uploader/source/date80026.lzh

>>932
thx

>>933
これから趣味でやるなら何がいいかなと思っただけなので

タスクシステムやっとけ

>>945
全くの初心者ならHSPでも便利と感じてしまうし、
初心者でないならかえって不便に感じるし…
どの程度できるのか知りたいっていうのはそういう意味

旬は動的言語と.NETだけれども、初心者&ユーザー視点では抵抗あるだろうね

>>944
なんか、ファイルが開けないと出て
遊べないんだよね
俺の環境のせい？
ファイルパスのマルチバイト文字とか
そこら辺が問題の予感

>>948
Cの直下に置いてみた？

オブジェクト指向がよく分からん
１のコードをＶＢに移植しようと思うんだが
クラスに入力情報を受ける関数をぽんと作ればいいのかな

>>947
それはいえてる
俺たちおっさんは.NETすげーだけど
初心者は案外そうは思わないようだ

まず冒険の書とか選ぶ部分は
バイトリード＋コモンコントロール・・・を使うのがセオリーだって
僕なんかは思うんだが

↑のソースではループしながら入力を検知するみたいで
なんか・・よく分からん
結局元のコードは無視して冒険の書は１から作り直した。
まぁＶＢだから早い。１日で出来た

他にもある
戦闘シーンが出てきて全体攻撃などでＡＩ振り分け処理があるんだが
そのもともとのデータをポインタ参照で取得しているが
ＶＢにはポインタがなくてよー分からんｗ

だれかフォローおね

まだまだある
キャラクターの基底クラス？とかあるけど、変数データが山のように
だらだらと・・・パラメータをまとめるヘッダファイルとかもあるが
ＶＢだったらこれは多重継承に書き換えてＯＫだよね？

別に非難している訳じゃない
Field.cppとかよく出来てる
ここら辺は参考になった・・・けど、手元で別に開発している
ゲームプログラムとそっくりだ
結局マップチップの処理は愚直に場合分けする
しかないという結論になるのかな

>>949
ソース見てたら、ただ単に未実装なだけの気もしてきた
すまん

>>950-953
久々に触って熱くなってるのか知らんが少し落ち着いてくれ
いじるのも設計見直すのも勝手だが、連4レスとかがっつきすぎだろう
ポインタと同等な機能の実装はググったら参照渡しとか出てくるよ

>>950
僕ごときのソースを改変しようとか言われてちょっと嬉しかったりします。

冒険の書選択画面もフィールド移動も戦闘も、なるべく同じように扱おう、という考えでこんな感じになってます。
ちなみにバイトリードって何ですか？コモンコントロールはぐぐったらなんとなくは理解できました。

キャラクタの基底クラスの変数郡は…　
今のところ力、素早さ…　等のパラメータはＭｅｔａＳｔａｔｕｓクラスとしてまとめて持たせてますが、
どうやってまとめたらすっきりしますか？アドバイスいただけたら嬉しいです。

そういえばそろそろ次スレ立てた方がいいのかしら？

>>956
ＶＢですとクラスの多重継承の間にモジュール構造体をそのまま
取り込んだりも出来るんで、クラス数を抑えながら非常に複雑な
プログラミングが出来るんです

すいませんがＣ＋＋は詳しくは知りません
多分お作りの内容で最善に近いまとめかたではないでしょうか

要するに移植するにあたってのこっちの都合ってことです；
せっかく手間をかけて作業するんだから↑のようなＶＢの
メリットを生かして、ついでに元のコード量を大幅に
削減したいなということです

それだけです。すいません

>>957
は？VBで多重継承なんかできないでしょ？

FCのドラクエなんてアセンブラでしょ。 多重継承は使ってませんよ。

>>960
とりあえず黙っててくれないか

見事にスレを止めた>>961

960gj
俺たちは1の動きを待ってるぜ。

FCのドラクエといえば会話中、ウインドウ表示中は一切他のオブジェクトが動いてないから
C言語+DXライブラリでいうところの for(i=0;i<60;i++)ScreenFlip();
みたいな処理がいたるところにあるんだろうな・・・
色んな処理を各関数内で完結できそうで楽そう

モンスターの行動が【たたかう】以外もできるようになりました。
スライムべスがこうげきとメラを３：１の割合で使ってきます。

tp://sakuratan.ddo.jp/uploader/source/date80861.lzh

Flipの一元化ですが、挫折しそうです。 Orz
メッセージの表示で挫折。
イベント実行中で挫折、です。
よく考えたら、これってマルチスレッド処理にした方が楽なんじゃないか、というか
マルチスレッドっぽいものを自力で実装をするのに他ならないんじゃないか、という事に気がつきました。

いままでちまちまやってきたことが無駄になりそうですが
これはそのままにしておこうと思いました。
必要が出てきたら直します。

p.s.
またもやアク禁です。
次スレ立てられないけど、過疎スレだしなんとかなりますよね、きっと。

はじめてきたが、お前はだれだ？

次スレは有志が立ててくれるさ

ところで、描画は一つのクラスに纏めた方がいいかもね
Flip云々より、複数のクラスに描画処理があるのが問題だと思う
実際流れが把握できてないみたいだしｗ

はかせ名前名前ー！

思うままにマルチスレッド使おうぜ

>>963
何がgjなのかわからん

>>960って、詭弁の定義にモロあてはまってるから
そもそも何を言いたいのか俺にはわからねえ…

>>967

最適の手法なんてものは時と共に変化するよ

俺なんかはウィンドウズプログラミング始めるときに描画処理とゲーム処理で完全に分けるスタイルに変更したから
エミュレータとかにあるようなターボモードとかスローモーションとかも実装できたよ。
おかげでめんどいとこは飛ばせるぜ

描画処理はコールバックに、
ゲーム処理はメッセージループに書くとか？

ドット絵に足踏みさせないの？ｗ

>>971
それはそうかもしれないが、
この場合は纏めるとこから始めた方がいいと思うんだよね
基礎勉強の意味でも

>>967
描画を1つのクラスまとめるってどういうこと？
ゲーム内オブジェクトをPaintクラスが全て追跡して描画とか？
そんな極悪な設計は考えられん…

>>976
確かに一つのクラスてのは言い過ぎだったかも
でも、描画を分離することに意味はあるはず

ゲームプログラミングにおいては>>972のやり方が普通だね
描画と状態の更新は分ける、コレ基本
で、全てのゲームオブジェクトに更新メソッドと描画メソッドを追加する
そしてメインとなるクラスから
メインループ {
更新();
if (フレームスキップするか？) {
描画();
ScreenFlip();
}
}
とするだけ、あとは各メソッドが芋づる式に呼ばれる。

愛はいつだっていもづる式さ

恋はいつでもオブジェクト指向〜♪

別スレッドにするって意味だと思ってた。
>>978さんのやり方だと処理落ちしそうなときに描画をスキップするだけ。
前回描画から17msより多く経過してたら描画スキップ。

てかDXライブラリなのか。
普通に書く場合はメッセージループで一定時間経過したらゲーム処理＋描画呼び出し
コールバックでWM_PAINTが来たら現在の状態を表示だな。ライブラリはどうなのか知らんが、
こうしないとウィンドウの一部に無効領域（だっけ？）ができた時にそこが真っ黒になっちゃうからな

メインクラスの描画関数が呼ばれたら、そこから更にキャラの描画関数を呼び出すって感じで
芋づるすれば、各クラス内で完結した形になる。

>>979
ﾃﾗﾅﾂｶｼｽ