あ、追記します 1マップに26人までです。 種類はマップデータで定義し直すので 事実上無制限です (マップがある限りは)

拡張性の観点から見れば 相当酷い出来ですが、 元の機能で割と補えるかな、と 勝手に思っています

なるほど DATAなんだ 私のRPGの仕様、一応置いとく 「中間言語」（BASIC以上、独自言語未満の何か）で直接書く方法 @番号 MSG_CLR 'ウインドウを開く MSG_PUT "ないよう" BUTTON_WAIT 0 OUT B 'ボタン押下を待機 MSG_EXIT 'ウインドウを閉じる RETURN GOSUBで実行され、番号は話しかけたスプライトの管理番号。 複雑なイベントも「そのままBASICで書けばどうにかなる」けど、面倒でもある。

僕自身、DATAには限界を 感じていました… DATAだけでSLOTひとつ 使う構成なので… GOSUBはいい案だと思います。 他の方とも相談して、 高効率高拡張性なエンジンを 作れたらな、と思います

欠点は打ち間違えがあったとき、会話したときにいきなりエラーが起きる場合があることかな DATAなら無効な構文は無視すればいいだけなんだけど…

今日はGMプログラマーSHさんも 主さんも来ないですね… またメッセージウィンドウDEFは 機能増強しておきます

BIG側にいろいろ書いたけど、大人数開発系がどんな感じに完成するか気になるので顔出ししてみる（参加はしてません） ※プロジェクト全体がうまくいってる間は見てるだけ

＃報告＃ 現在の土台陣の方針だと ファイアーエムブレム的なSRPGになりそう。

だにえるさん、ありがとうございます 土台の件了解しました

しかし、そうなると僕のサンプルは 完全に方向性が変わってきますね。 フィールド上での自由な移動が なくなる、というイメージでしょうか

呼ばれたんで飛び出ました なんか用ですか？

システム的にはFEに近い →フィールド移動は限定的 →バトルシステムはコマンド進行式 →主人公キャラとその他全員に 　パラメータ割り振り →ストーリー重視 ということでしょうか

あのー、俺のコメント見ると分かると思うんすけど、クラフト機能って出来ますか？それとゲーム内移動でそこは初期ド○クエぽく、自由にダンジョンとか王国とかレベ上げとか行き来できて、野良モンスターとか魔王手下との戦闘でも初期ド○クエぽくランダム(確率)でモンスターが出てくる感じとかに出来ますか？出来ないなら別にやんなくて良いし、これはあくまで俺の意見なので…プログラム係さん、どうか意見を下さい！また、「ここはこうした方が良いよ」とかの意見も下さい…

公開キー出してるよって事

土台係の投稿に既に コメントしてあるのですが… FE的RPGという 土台ではないのでしょうか？ (いまいちフレームが見えてきません) クラフトやエンカウントなどの処理は 決してできなくはないですが、 土台が完成しないことには なんとも言えませんね

優先順位としては、 土台(フレーム)の作成 ↓ プログラムの基本形を作成 ↓ BGMや絵、細かい要素の追加 ↓ デバッグ、テストプレイ ↓ ゲームバランス調整 ↓ 完成 という流れでしょうか

クラフトやエンカウントなど 処理的にはとても興味深いのですが、 フレームがないと話が進みません。

SEKI22さんの言う通り、 こちらに公開されているサンプルには エンカウント処理が 実装されています。 (僕のサンプルだとまだ フラグ立てだけですが…) この投稿に公開されている サンプルコードを DLしてみてください。

あ、そうですよね！先に土台作んないとね…wはい、分かりました！土台(ストーリーなど)帰ったら投稿しまーす！

メインプログラム　Ver 0.0.2　公開キー【FDB3QD】 バトル実装済み(バグだらけ) エンカウント処理»制作中のPetitTopiaのコピーです。

（プログラムと土台が分かれてるのがややこしいような）

「土台」と言うニュアンスが あまりにも広義すぎましたね… 個人的には、どんなゲームを 作るのかが決まった時点で プログラミング班と統合すれば よかったのかなー… と、勝手に思っています

みんなカモーン！ とりあえずバトルシーンだけでも作ってください！ ストーリーはとりあえずこのままで

（まさかの主さんが一番投げやり疑惑…）

とりあえずって… 却下になったら悲しいやんって思う

主じゃないけどお願い事 ・要らないファイルは省いてほしい(@BACKUPを含む) ・ファイルサイズを書くか、公開キーを画像ではる 環境によってはインターネットの速度は違うので、どの参加者さんも快適に最新版を確認できるようにお願いしたいです。

申し訳ありません 開発経過から ロールバックしようとしていたら そのファイルをそのまま アップしてしまいました… 軽量化して再アップします

主さん≫ムリです、勘弁してください… フレームがろくにできていない状態で バトルシーンだけ作るのは かなり無茶が過ぎます… そして、今回のバトルシーンは モーションシーンが多そうで かなり難航すると思われます… 僕の現行ver.「PETITRPG_v1.1」では 対応しきれません

バトルシーンは「攻め受け」の 画面を言ってる? とりあえず、土台陣の方だと 簡略化するって方向になってますが…。

バグだらけのPetitGAME Ver 0.0.2だとバトルがゴミ過ぎますが実装済みです。

バトル画面がFEのような構成ならば 実装可能ですが、 GMプログラマーSHさんが 様々な案を出していたので 混乱しています… フィールド上のモーションバトルということではないのでしょうか

フィールドでバトルって意外とこんがらがりそうな気がする 画面をはっきり切り替えたほうが分かりやすいような

もうひとつ。 私の3DSのインターネットは常時ではないことを伝えておきます。 明日は見れそうです。

分類的にはSRPGっていうんね >ファイアーエムブレム なかなか知らないジャンルですorz...

じゃあ、やって欲しいことをまとめます ゲームルール ・キャラが体当たりするようなアニメ ・マップをアニメ付きで移動出来るようにする (・キャラパラメータ) 会話表示プログラムは僕が作ろうと思うのですが もう既に作ってあったりしますか？

…と思ったら会話作ってあった 僕も一応作っておきます

移動ってマスがあるのかな？ それとも1ドットずつ？

↑1ドットずつです

?? マスだよ

ん… ちなみにフィールドです 1マスずつ歩けるのか 1ドットずつ歩けるかってことです

たぶん、FEに合わせるとマスな印象だけど…

僕のはマスですね 移動スクリプト上では斜め移動もできます

メッセージウィンドウルーチンは作りかけですが完成しています あとはキャラの定義し直しだけです

あー、フィールドねー。 別にどっちでも悪くないけど マスの方がシンプルじゃないかな。

戦闘画面は こんなイメージで。 障害物や、 マスによる特殊効果(ステータス向上) があったり。 *自身と敵のターンを交互に繰り返す。 *1ターンに移動できる距離は それぞれのキャラのステータスに依存。 *FEとは違い、 味方が1体でもやられるとゲームオーバー ※僕が想像しているシステムです。 確定はしていません。

マス移動のアニメなら歓迎だよ MINIRPG_DBG【REDVQ3R4】 投げやり過ぎですみませんが、急ぎならこちらから（コピーの仕方が難しいので、明日、必要な部分バージョンが出せます）

スプライトの管理番号ゼロが主人公なので、変数なり管理しやすくするのが推奨

「動きを見たい」人はDLして こういう移動でいいよ、っていう人が多ければ必要な部分だけ抜き出したものを上げます

もうひとつ。 変数名は早めに固めたほうがいいけど、どうなってるんだろう？

移動アニメについて、必要な変更があればどうぞ スライドパッド・ボタン両対応だけど片方にもできる BGスクロール無しOK 速度変更OK 斜め移動封じOK （ネタバレ付けたのはミスです）

（プロジェクト全体を把握してまとめる人が居なかったり、プログラムをみんなで分担するためにみんなのサブルーチン管理や呼び出しするベースプログラムと共通データとのインタフェースの話が出てなかったりするけど、まだ様子見）

どうにかしてデータ形式を似通ったものにする必要がありそうですね…

特にBGレイヤーとSP管理番号、 配列のデータエリアと使い道 でしょうか

今更ながらですが公開します。 「PETITRPG_UP」 キー:4KE4NY サイズ:1078167バイト 改良点 ・まともに動作する 　メッセージウィンドウ

う、BGスクロールは辛い… こちらのプログラム上で BGスクロールするのは 仕組みと技術的にムリです…

(もうMiniRPGでいいんじゃ…) ※計画は投げてないです

結局「目的」が大事だよね プログラミングを学びたいので、基礎から作る or 楽に完成を目指したいので、使えるものはそのまんま使う ようは、完成が目的か、作る学びが目的か （ダウンロードが予定変更で明日になるかも…）

個人的には、 Unified Peticonersのメンバーとして 主さんの考えに従おうかと 考えています。 自分でRPGを作っている作業も それはそれでとても楽しいですが、 グループとして それはどうなんだろう、と考えると ある程度出来上がったサンプルに 付け加えていくほうが 良いのかもしれません。

今の所、PETITRPGの利点は 動作が軽いということでしょうか

俺なんて軽すぎてWAIT命令使ってる件

まあVSYNCは必須なんだけどね メインループは、後で凝りたいときのために、無駄を徹底的に省くのがおすすめ

PETITRPGの完成までの道のりが 見えなくなってきました… バトルシーンとフィールド画面の 移行がプログラム中でうまくいかず、 さらに何やら色々とバグもあり… すいません、 PETITRPGは断念させてください

DLしたよ なかなか設計はよくできてる感じ。 デメリットが3つほどあるのは、 ・エラー停止のバグが1つある。 ・DEFが1行に詰め込まれてるのがデバッグしにくい。 ・スロットを目いっぱい使っているので、DEFを分けることができない。 改良して使うこともできる感じだけど、高度なコード（ダジャレかよ）につき、読むのにちょっとお時間頂く感じ。

ちなみに、未定義SPが原因のエラーなので、SPUSED()でエラートラップすれば、エラー停止自体は解消できる。

あ、ローカル宣言が無いや… 少しいじって明日上げてみたいと思います。

変数宣言が無いのがとても惜しい感じはある それも含めて明日「PETITRPG 調整版」上げたい

あまさと しおんさん≫ すいません、ありがとうございます

1行にまとまっているDEFは 展開する必要がないかと思い まとめてしまっていました 展開しておきます

一部、妙に短縮できたところがある

（あ、上げるっていうのは私が上げるのでいいですよ）

すいません ビットシフト使えない人です SPHIDEバグの件と合わせて 修正しました

変数宣言も OPTION STRICTで なんとかしておきます

CHRMOVEのみ【2ZC3V3NJ】 ※プロジェクト写す時にnnid変わっちゃったのですみません

何か所かいじってみたものをとりあえず上げました 参考でも使ってもどうぞ

あまさと しおんさん≫ ありがとうございます！ さらに修正+STRICT化して 公開しました プロジェクト 　キー:1DR33K3E 　サイズ:1079070バイト ファイルのみ 　キー:2DNN83N4 　サイズ:25183バイト

新トピ立てました 僕のプロフィール→お絵かき投稿からどうぞ

おお、あと3コメだった 全然気づかなかった

今更ですが、 ウィンドウ表示DEFを 独立させています これによってメニューとメッセージウィンドウを共用できるようになり、 軽量化とデバッグ性の向上につながります

でも実際にコーディングするのは明日で…