ボルガはかせさん かなり無理やりだな… 「〜今まではそれで十分でしたか、そうも"いか"なくなりました。」 とかね。

IKAさん 画力ね… キャラクターデザインとモンスターデザインを他の人に任せています。 私は、GUIのデザインをやっていて、 ゲーム画面を考えるのが好きです。 つまり、カクカクしたデザインが得意だけれども、キャラクターは私も描けません。 でも、大事なのはデザインではなくゲーム性です。キャラクターがいくら良くとも、ゲーム部分がいまいちだったら面白くありません! 画力がなくても、ゲーム性を求めれば、面白い作品ができそうです。

るかかさん ひらめいたんですか!? 期待できますね。 私は、ひらめきというよりは昔っから思っていたものを形にしていく作業になりがちです。 るかかさんに遅れを取りながらも…次のバージョン(UIの若干の変更)は公開します。 意見を大切にしていきます。

そして…残念ながら、るかかさんみたいに大喜利に向けて作りません。 というか、間に合いません。 その次の大喜利をお楽しみに！

よって、これからは、Part層(FILE,SEARCH,EVENT,MENU,BATTLE)の処理の先頭に、独立したInput処理を書く事にしました。(ボタンIDを保持する変数は別でCountを計算できるようにします。) FILE関数にて、ファイルセレクト画面や名前入力画面の入力処理をする。 EVENT関数にて、ウィンドウを進めたり、選択できるように処理を書く。 といった感じに各part(部)によって入力を取るようにしました。 入力処理は今作はこれくらいにしておきましょう。 書く処理にてタッチの座標を取得するのはできない(入力処理はまとめるというルールに沿ってない)ので、今作はボタンを"押す"だけになりますが、次回作は、スマートフォンのUXのようなフリック、スクロール操作などができるようにしますか！

"今まで"はそれで十分でしたか、そうもいかなくなりました。 ■選択画面の問題 最近、ウィンドウ上で、「はい」、「いいえ」、「……」(……は有無変更可)の選択ができるようになったのですが、 操作は右左ボタン。 メニュー画面の右左ボタンと被ってしまい、少し不自然です。 選択肢が表示されているときは…で条件判断ができなくもないですが、ボタンIDについて悩まされます。(単なる_ComLeft,_ComRightにはできないため。) ■沢山の条件判断 今までは、捜索パートとメニュー画面でしたかが、バトルパート、ファイルセレクトなどの画面が増えれば増えるほど、 スプライトの管理番号が変わって、それぞれのパートごとに条件判断しなければならなくなります。

ButtonCountにボタンを押してからの経過フレーム数 OffDecに離したボタンのID を計算で出し、そのループで行う処理を1つに決めています。(捜索パートでの移動は別変数で表しているのでそちらは独立している) こうすることによって、同時押しによる不安定な挙動について心配する必要が無くなるし、 その変数を制御することによって、プログラム上で、擬似的にユーザーの行うボタン操作ができます。(チュートリアルなどでメニューのボタンを制御でき、分かりやすい) 試しにメインループに ButtonNo=_ComL と入力すれば、下画面のメニュー切り替えが高速に行われます(ButtonCountで長押しを算出しているので、BottonCountか0のままだと高速に連打していることになる)

DESIRED ROUTE創作報告 もし、大作RPGを何も言わずコソコソ作っている奴がいたら怖い… いつの日かリリースされて、ズドンとシェアを奪われるのか… ある程度制作過程がオープンな方が、明るく、フィードバックを受け取ることによって作品の質を上げられるだろう。そういう訳で、あんまり関心のなさそうなことでも話します。 その点、「まじっくすと〜り〜」は安心できるな。なんだかんだいって楽しみです。

今、集中的に加筆訂正しているコードは、INPUT―ボタンやタッチの入力―の処理です。 各処理でいちいち IF BUTTON()==#B THEN …… とか、書かずに メインループの始めに、ボタンやタッチの情報を取得して、 ButtonNoにボタンorタッチで押す仮想ボタンのID ButtonGroupにボタンのグループ番号(タッチのボタン配置的にグループ分けしており、タッチし始めたボタンと違うグループのボタンが押された時はその操作が無効になる)

私は科学館に置いてあった、15パズルのゲームをやったのですが、 まれに解けない配置で出題されることがあり、「誰だ!こんなもの作ったのは!?」「どうやったら不可能な問題を生成しないようにできるのだろうか」とか思っていましたが、 この作品はちゃんと、シャッフルして不可能なパターンが出ないようになっていたので、関心しました。 並び替えの演出が綺麗です。

スプライト管理番号(SPSET)を整理するために、私は擬似的な定数を使っています。 例えば、 スプライト定義番号(SPrite)の捜索パート(Search part)の上画面(Upper screen)のウィンドウ(WINDOW)の枠(FRAME)は、 _SpsuWindowFrame プログラムの変数定義時にそういった変数に0から255まで入れていき、SPSETやSPOFSなどの命令でその変数を管理番号として使います。 こうすることによって、スプライトの数が変更になっても変数の値を変えることによって、全てのスプライトに反映することが容易にできます。 定義番号(SPDEF)のやつは、数に余裕があるので、仕様変更で、いらないものができても定義番号は詰めずに間が空いていてもそのままの数を使います。

あ、SPDEFで設定した画像の数じゃなくて SPSETで使用したオリジナルのスプライトの数か。 なら、捜索パートは上画面256個、下画面256個。 バトルパートは上画面312個、下画面200個です。

私の作っている「DESIRED ROUTE」では、今のところ、 英数字、記号、ひらがな、カタカナ、独自文字の領域で、256個。 漢字領域(画像は必要に応じて書き換えていく)は160個。 主人公達と街の人で396個。 マップ上の仕掛けで111個。 メニュー画面で46個。 バトルパートで31個使います。 合計して、まさかの1000個ピッタリ!!(自分でもビックリ) 上画面下画面というよりは用途別に分けますね。仕様変更に対応するために、用途の数が不定な所は定義番号を開けて一気に3000番とかにしている所もあります。 それと、自作の定義番号かデフォルトなものなのか分かりやすくする為に、1度、4096個全てを◆の画像で埋めています。 おそらく、完成する頃には倍近く、定義番号を使います。

大幅な仕様変更に強いプログラムを書いているのだが、それでも、つじつまを合わせる処理が多い…

最近文字化けするなぁ。 (なんか最近進みが悪い…) ASCIIの英数字、記号部分にRPGでは到底使わない記号があったので、独自の文字を別の画像領域から、使わない記号の所に移す。そして、文字画像を削減、位置調整したらこうなる。

うーむ、少しイマイチだなぁ。 うまく時間を探してうまくやって！ 顔が大きい？髪を短くして。

こめのこ、しておきます

そういうことでしたか、 理解していませんでした、すいません。

GOGUBではなく、CALLを勧める理由は、ローカル変数を使えることです。 変数の有効範囲を縮めることによって、名前がかぶる心配がなく、不用意に変数の値が変更されないようにできるからです。 BASICらしくないかもしれません。

なんかCALLを使えとか言ってしまいましたが、 つまりは、処理を細分化して、 わかりやすくして欲しかったからです。 人によっては、気にすることの無いかもしれませんが、つい大規模なプログラムを書いていると、プログラムの構造に関して言いたくなってしまうのです。GOTOは使うべきじゃないよ。