入力の挙動
今までの方法
INPUT―ボタンやタッチの入力―の処理です。
各処理でいちいち
IF BUTTON()==#B THEN ……
とか、書かずに、
メインループの始めに、ボタンやタッチの情報を取得して、
- ButtonNoにボタンorタッチで押す仮想ボタンのID
- ButtonGroupにボタンのグループ番号
(タッチのボタン配置的にグループ分けしており、タッチし始めたボタンと違うグループのボタンが押された時はその操作が無効になる)
- ButtonCountにボタンを押してからの経過フレーム数
- OffDecに離したボタンのID
計算で出し、そのループで行う処理を1つに決めています。(捜索パートでの移動は別変数で表しているのでそちらは独立している)
こうすることによって、同時押しによる不安定な挙動やバグについて心配する必要が無くなるし、
その変数を制御することによって、プログラム上で、擬似的にユーザーの行うボタン操作ができます。(チュートリアルなどでメニューのボタンを制御でき、分かりやすい)
試しにメインループに
ButtonNo=_ComL
と入力すれば、下画面のメニュー切り替えが高速に行われます
(ButtonCountで長押しを算出しているので、BottonCountか0のままだと高速に連打していることになる)
問題点
"今まで"はそれで十分でしたか、そうもいかなくなりました。
選択画面の問題
最近、ウィンドウ上で、「はい」、「いいえ」、「……」(……は有無変更可)の選択ができるようになったのですが、
操作は右左ボタン。
メニュー画面の右左ボタンと被ってしまい、少し不自然です。
選択肢が表示されているときは…で条件判断ができなくもないですが、ボタンIDについて悩まされます。(単なる_ComLeft,_ComRightにはできないため。)
沢山の条件判断
今までは、捜索パートとメニュー画面でしたかが、バトルパート、ファイルセレクトなどの画面が増えれば増えるほど、
スプライトの管理番号が変わって、それぞれのパートごとに条件判断しなければならなくなります。
今の方法
よって、これからは、Part層(FILE,SEARCH,EVENT,MENU,BATTLE)の処理の先頭に、独立したInput処理を書く事にしました。
(ボタンIDを保持する変数は別でCountを計算できるようにします。)
FILE関数にて、ファイルセレクト画面や名前入力画面の入力処理をする。
EVENT関数にて、ウィンドウを進めたり、選択できるように処理を書く。
といった感じに各part(部)によって入力を取るようにしました。
入力処理は今作はこれくらいにしておきましょう。
今後の予定
各処理にてタッチの座標を取得するのはできない(入力処理はまとめるというルールに沿ってない)ので、今作はボタンを"押す"だけになりますが
次回作は、スマートフォンのUXのようなフリック、スクロール操作などができるようにしますか！