公開日：2023/05/13

25th Season

#25-6　後出しジャンケンで遊ぶ

　オールインワンのマイコンボードM5StickC Plus(下図)を使って、前回から作り始めた後出しジャンケンゲームを完成させて、実際に遊んでみたいと思います。

音楽演奏

　ゲームを盛り上げるのに必要な音楽演奏は、M5StickC Plus用に移植したplay_mml()関数を使います(詳しくは以下記事を参照)。

　　「#25-2　M5StickC Plusでジュークボックス」

　play_mml()関数をゲームに使う場合、音楽演奏中にも、プレイヤからの入力を受け付けたり、TFTディスプレイの表示を更新したり、並列処理が必要となります。つまり、演奏が終了するまで処理をブロックしてしまう、現在のplay_mml()関数では使い難いのです。

音楽演奏用サブスレッド

　「#25-2　M5StickC Plusでジュークボックス」の記事にて予言しておいた様に、M5StickC Plusで稼働しているFreeRTOSのAPIでサブスレッドを起動して、並列処理させましょう。そうすることで、音楽演奏処理と、その他のゲーム処理を並列処理することができます。

　　音楽演奏用サブスレッド目標仕様：

スレッド関数名は、bgm_play_mml()関数。

※BGM(Back Ground Music)

bgm_play_mml()関数は、char　*bgm_mml変数を監視して、bgm_mml≠NULLとなったら、bgm_mmlが指す文字列をMMLと見なして、音楽を演奏する。

演奏中、bgm_rdy変数をfalseに設定して、演奏中であることを示す。
演奏中、一音演奏する毎にbgm_mml変数を確認して、bgm_mml＝NULLとなった場合、演奏を中断する。

指定されたMMLの演奏が終了または中断した時、bgm_play_mml()関数はbgm_mml＝NULL、bgm_rdy＝trueに設定して、待機状態に入る。

待機状態では、bgm_mml≠NULLと、なるまでポーリングする。

　もし、FreeRTOSが利用できない環境だったら、自分で割り込みなどを駆使しながら、並列処理を実装しなければならない所でした。

メインプロセスのBGM演奏

　前節で起動したサブスレッドは音楽演奏だけを専門に引き受ける専用スレッドなので、指示された通りの音楽演奏だけを実行します。
　メインプロセスは、以下手順でBGM演奏をサブスレッドに対して指示します。

　　BGM演奏手順：

bgm_rdy変数をチェック

bgm_rdy＝falseの場合：

現在、演奏中のMML(bgm_mml≠NULL)がある。
bgm_rdy＝true(演奏終了)になるまで待つ。
あるいは、bgm_mml＝NULLに変更して、現在演奏中のMMLを中断できる。

bgm_rdy＝trueの場合：

演奏準備が整っている。現在、演奏中のMMLは無い(bgm_mml＝NULL)。
bgm_mmlにMML文字列へのポインタを設定して、演奏を開始する。
必要に応じて、bgm_rdy＝falseになったことを確認する。

指定したMMLの演奏終了まで待ちたい場合は、bgm_rdy＝trueまでポーリングすれば良い。

待つ必要が無ければ、その間、メインプロセスは別な仕事を並列処理できる。

　bgm_rdy変数およびbgm_mmlポインタの値と、演奏の状態を以下図および表にまとめます。

状態変数		演奏状態
bgm_rdy	bgm_mml	演奏状態
false	≠NULL	PLAY	サブスレッドがbgm_mmlを演奏中。
false	＝NULL	STOP_REQ	メインプロセスが現在の演奏中断を要求。サブスレッドが演奏中断するのを待っている。
true	≠NULL	PLAY_REQ	メインプロセスが新しいMMLの演奏開始を要求。サブスレッドの演奏開始を待っている。
true	＝NULL	IDLE	サブスレッドは音楽を演奏していない。メインプロセスからの演奏開始要求を待っている。

※メインプロセスとサブスレッドは非同期に並列処理しているため、全ての状態が観測できる保証はありません。上表4状態の内、どの状態が観測されても誤動作(ハングアップ等)しない様にプログラムしてください。

　　状態変数：

bgm_rdy変数：

サブスレッドだけが更新(変更)する権限を持っており、
メインプロセスは参照のみ許可されています。

bgm_mml変数：

メインプロセス、サブスレッド共に更新・参照が許可されますが、
サブスレッドは演奏終了時にbgm_mml＝NULLへの更新だけを実行します。

　上のBGM演奏手順に従って、引数として渡したMML文字列を演奏する関数を起こして使います。

プロトタイプ：　play_bgm (const char *mbuf, int opt=bgm_OPT_DEFAULT);

mbufに渡された文字列をMMLと見なして、演奏を開始します。
引数optの値によって動作を制御できます。

opt＝0b_0000_00WB：
W＝1：　(定数bgm_OPT_WAIT)

サブスレッドbgm_play_mml()関数が、前のMMLを演奏中だった場合、演奏が終わるのを待ってから、mbufの演奏指示を出します。

W＝0：　(定数bgm_OPT_DEFAULT)

サブスレッドbgm_play_mml()関数が、前のMMLを演奏中だった場合、中断してから、mbufの演奏指示を出します。

B＝1：　(定数bgm_OPT_BLOCK)

mbufの演奏指示を出したら、演奏が終わるまで、処理をブロックします。
演奏が終わるまで処理がブロックされるのて、従来のplay_mml()関数と同じ動作となります。

B＝0：　(定数bgm_OPT_DEFAULT)

mbufの演奏指示を出したら、演奏の終了を待たず、直ちにreturnします。

サブスレッドに音楽演奏を任せて、他の仕事を並列処理することができます。

例）play_bgm ("C44,D44,E44", bgm_OPT_WAIT | bgm_OPT_BLOCK);

「ドレミ♪」の音階を演奏します。
bgm_OPT_WAIT：　現在演奏中のMMLが有った場合、演奏の終了を待ってから、「ドレミ♪」を演奏します。
bgm_OPT_BLOCK：　「ドレミ♪」の演奏が終わるまで処理をブロックします。

プロトタイプ：　play_bgm_init (void);

play_bgm()関数を使用する準備(初期化)を実行します。

本関数の実行によって、音楽演奏用のサブスレッドbgm_play_mml()関数が起動します。

play_bgm()関数を使用する前に、setup()関数内などで、予め実行しておく必要があります。

play_bgm_init()関数を実行すると、その後、play_mml()関数の実行はエラーが返って失敗しますので、play_bgm()関数を使ってください。

　setup()関数内で、サブスレッドを起動する初期化play_bgm_init()関数を実行したら、後は、play_bgm()関数で普通にMMLを演奏することができるインターフェイスです。

　なお、サブスレッドbgm_play_mml()関数では、M5StickC Plusの内蔵パッシブブザー(M5．Beepクラス)を占有リソースとして使っていますので、bgm_play_mml()関数以外の場所でパッシブブザーを使用してはいけません。パッシブブザーが共有リソースとなってしまうので、セマフォなどを使った排他制御が必要になってしまいます。

M5cp-PSライブラリへ収録

　今後、音楽演奏したくなる度に、play_mml()関数の定義をコピー＆ペーストするのは面倒なので、play_mml()関数および、play_bgm()関数をM5cp-PSライブラリへ収録しました。以下のリンクを辿って、最新版のライブラリに更新してください。

　　M5cp-PSライブラリ

　それほど難しくないはずですが、追加収録したplay_bgm()関数の使い方に関しては、次節でリンクする後出しジャンケンゲームプログラムを参照してください。

プログラム

　以下に、完成したプログラム(一式)をリンクしておきます。M5StickC Plus開発環境の立ち上げは、こちらを参照してください。

完成プログラム：	m5cp_rps_game.ino
ビットマップ定義(グー)：	rps_rock.h
ビットマップ定義(チョキ)：	rps_scis.h
ビットマップ定義(パー)：	rps_papr.h
ビットマップ定義(サムダウン)：	rps_down.h

　すべてのヘッダファイルは、プログラム本体(m5cp_rps_game.ino)と同じディレクトリに配置してください。

※コンパイルには、M5cp-PSライブラリが必要となります。リンクを辿ってインストールしておいてください。

　プログラム先頭付近のマクロで、TFTディスプレイの表示を英語版に切り換えることが可能です。必要に応じて、以下のマクロを有効化してコンパイル＆書き込んでください。

　　//#define　UI_SEL_ENG　　// u/i: select English

　コンパイル＆書き込むと、シリアルモニタから以下のコマンドを受け付けています。

　　シリアルモニタコマンド仕様：

gyr,<on1_off0>

約500ms毎にジャイロセンサからデータを読み出してシリアルモニタへ表示する機能を制御します。
<on1_off0>＝0では、表示機能は停止します。
<on1_off0>＝1では、表示機能は有効です。
起動時のデフォルトは【gyr,0】です。

その他、こちらのコマンドも有効です。

　全て、デバッグやプログラム動作調整用のコマンドなので、後出しジャンケンゲームとしてはシリアルモニタ無しで自立できます。

実験で遊ぶ

　前節で完成したプログラムをM5StickC Plusにコンパイル＆書き込むと準備完了です。下図は、ゲームプレイ中の様子です。

　メニュー表示(上図左側)には、無駄に(？)カラー表示を使って見ました。ゲームなので、単色のメニューより、カラフルな方が楽しげな印象になります。カラー表示に使ったのは、tft_kprint()関数に備わった、制御コードによる描画色指定機能です。

　まずは、シリアルモニタからコマンドを叩いて、確認作業を進めます。

　　実験サンプル：【】内はシリアルモニタからの送信データ

平らな所にM5StickC Plusを静かに置いた状態で：

　　【gyr,1】
　　OK: gyr ON
　　DBG: Gyro=(-136, 25, -18) [LSB]
　　DBG: Gyro=(-147, 33, -19) [LSB]
　　DBG: Gyro=(-152, 29, -15) [LSB]
　　DBG: Gyro=(-150, 27, -17) [LSB]
　　DBG: Gyro=(-165, 34, -20) [LSB]
　　DBG: Gyro=(-168, 31, -15) [LSB]
　　DBG: Gyro=(-155, 33, -19) [LSB]
　　DBG: Gyro=(-158, 29, -22) [LSB]
　　：

　500ms毎にジャイロセンサを読み出して、シリアルモニタに表示しました。M5StickC Plus(に搭載されたジャイロセンサMPU6886)は、一切回転させていないので、読み出した非ゼロ値は、MPU6886のオフセットです。前回説明した様に、オフセット値をキャンセルして、ジェスチャを判定する必要があります。
　オフセット値には個体差が有るので、機体毎に異なる値となります。上の値は、筆者手持ちM5StickC Plusでの計測値です。
　なお、オフセットはプログラムで自動的にキャンセルしたので、確認したオフセット値自体は無視します。

　続いて、【gyr,1】の状態でジャイロセンサの読み出し値を表示しながら、M5StickC Plusを振り回し、ジェスチャの判定閾値を決めました。

　　const　int　rps_GYRO_THSH=1024;　　// rps: gyro threshold for gesture

　この値で、入力時のジェスチャの大きさが決まります。

値が小さすぎると、少し動かしただけで閾値を超えてしまって、お手付きや誤入力が多発することになります。
値を大きくし過ぎると、野球のバットやゴルフのクラブを振るくらいの大きなジェスチャをしないと、入力できなくなります。

　一応、当方の感覚で、良さそうな値に設定してあるので、変更しなくても良いはずです。操作に違和感がある場合は、各自調整して適切な値に設定して見てください。

※ジャイロセンサのレンジ設定は2,000[°/ｓ]レンジなので、rps_GYRO_THSH[LSB]×2,000[°/s]÷32,768LSBで回転させた場合に、検出します。

　気が済んだら、【gyr,0】で表示を停止します。

　以上、シリアルモニタで確認すべき項目は終了したので、今度は独立動作で実際にゲーム🎮を遊んでみましょう。

　　実験サンプル：

メニュー選択

SW-Bでメニュー項目が1つづつ進んで行きます。
現在選択中のメニュー項目は赤い文字で描画されます。
SW-Aを押すと、その時選択されていたメニュー項目を実行します。

遊び方表示

メニューから、「遊び方(Manual)」を実行すると、簡単な遊び方が表示されます。

1画面のルール説明なので、舌足らずです。
詳しい遊び方については、こちらを参照してください。

ゲームスタート

メニューから、「遊ぶ(Game Start)」を実行すると、「標準(Normal)」難易度のゲームが始まります。
以下の難易度から実力に有ったゲームを遊ぶことができます。

簡易(Easy)：　コンピュータの指示発出から、入力までの制限時間3秒
標準(Normal)：　コンピュータの指示発出から、入力までの制限時間2秒
上級(Hard)：　コンピュータの指示発出から、入力までの制限時間1.5秒
困難(Tough)：　コンピュータの指示発出から、入力までの制限時間1.25秒

ゲームは、コンピュータが出題して、制限時間内に、応える入力をすると、制限時間の残り時間が得点となります。

出題する前に「最初はグー(A rock at first)」という音楽(以下リンク)が演奏されます。

a256_saisyowagu.wav

この音楽が演奏されている間は、「お手付き」と判定されない様、M5StickC Plusを静止させて準備してください。
「最初はグー(A rock at first)」の音楽が鳴り止むと、出題が表示されます。

出題中は「ジャンケンポン(R！P！S！)」という音楽(以下リンク)が演奏されます。

a256_zyankenpon.wav

この音楽が鳴り止むまでの間が、制限時間です。難易度に応じて、音楽のテンポが速くなったり遅くなったりします。
音楽が鳴っている間に、正しい答えを入力しましょう。

制限時間が経過すると、結果が示されます(下図)。

正解の場合は、画面が緑色となって、「ピンポン」という効果音が鳴ります。
失敗した場合は、画面が赤色となって、「ブブー」という効果音が鳴ります。

ここまでが1ラウンドです。

制限時間以内に応えなかったり、間違った答えを入力してしまうと、得点は加算されません(そのラウンドは0点)。
全部で3ラウンド繰り返して、得点を重ねて行きます。

3ラウンド終了すると、結果を表示して、SW-Aの入力待ちとなります。

SW-Aを押すと、メニューに戻ります。

ハイスコア表示

メニューから、「ハイスコア(High Score)」を実行すると、それまでに遊んだハイスコアが表示されます。
制限時間の残り時間が得点となるシステムなので、難易度の低いモードの方が高得点を取りやすくなっています。
難易度によって得点の取りやすさが変化するため、難易度毎にハイスコアを保持していて、表示します。
より高い難易度で、高得点を目指しましょう。

　では、実際に遊んでいる様子を、以下動画でご確認ください。

ゲームバランスの調整

　自分で実際にゲームをプレイして見て判った事があります。

「引分(DRAW)」が簡単すぎる。

コンピュータの手と同じ手を入力すれば良いので、少し早く反応できる。
次に「勝ち(WIN)」が簡単。昔から身に沁みついた、勝ちの手は連想が早い。
一番難しいのは「負け(LOSE)」。負けようとすると、いつもと違った思考が必要で、ワンテンポ遅れがち。

乱数でコンピュータの手と指示を決めるため、直前の手・指示と同じものが出題される場合がある。

コンピュータの手が3通り、指示が3通りの、計9通りだから、1/9の確率(≒11%)で直前の出題と同じ出題が発生する。
直前の出題と同じだった場合、早く反応できてしまう。

　上の様な出題は他の出題に比べて簡単なため、高得点を取り易い状態でした。限られた3回戦の合計点で競うため、ランダムに簡単な出題が連続すると容易に高得点を取得できてしまい、ちょっと不公平が過ぎると感じました。調整が必要だと判りました。

指示の出現頻度：

指示の難度は経験的に、引分(DRAW)＜勝ち(WIN)＜負け(LOSE)の順に高くなる。
そこで、指示の出現頻度を制御することにした。

const　int　frq_max=9;　　// WIN:DRAW:LOSE frequency control
const　int　frq_indc[ ]=
{
　　rps_INDC_WIN,　rps_INDC_DRAW,　rps_INDC_LOSE,　　// 1:1:1 frq_max=3
　　rps_INDC_WIN,　rps_INDC_LOSE,　rps_INDC_LOSE,　　// 2:1:3 frq_max=6
　　rps_INDC_WIN,　rps_INDC_LOSE,　rps_INDC_LOSE　　// 3:1:5 frq_max=9
};
rnd_indc=frq_indc[random (frq_max)];

frq_max＝3とした場合の出現頻度は、勝ち(WIN)：引分(DRAW)：負け(LOSE)＝1：1：1
frq_max＝6とした場合の出現頻度は、勝ち(WIN)：引分(DRAW)：負け(LOSE)＝2：1：3
frq_max＝9とした場合の出現頻度は、勝ち(WIN)：引分(DRAW)：負け(LOSE)＝3：1：5

最終版は、frq_max＝9と、してある。

同じ問題発出の抑制：

前回の出題を覚えておいて、次の出題を乱数で決めた後、前回の出題と同じだった時に、一度だけ乱数を引き直す。

rnd_hand=random (3);
rnd_indc=frq_indc[random (frq_max)];
if (idx>0 && (pre_hand==rnd_hand && pre_indc==rnd_indc))
{
　　// redraw random number
　　rnd_hand=random (3);
　　rnd_indc=frq_indc[random (frq_max)];
}
pre_hand=rnd_hand;
pre_indc=rnd_indc;

乱数の引き直しは一度しか実行しないので、低確率だが、前回と同じ出題をする場合は有り得ることに留意。

　テストプレイって、重要なんですね。
　上にまとめた様な事は、どんなに頭で考えていても中々思いつきませんが、実際に遊んでみると、すぐに気が付きます。

　市販ゲームでも、「これ、ちゃんとテストプレイしたのか？本当に面白いと思ってこんなバランスにしてるのか？」って、思う時があります。テストプレイは、「ポーズとして、とりあえず、こなしておく」のではなく、ちゃんとテストプレイヤの意見を取り込んで、ゲームバランス調整に活かさなくては、なりません。
　その場合、テストプレイヤ側の責任も重大です。Yesマンにならず、客観的かつ率直な意見を上げて、改定を促せる様でないとダメです。当然ベンダ側も、開発日程ありきではなく、本当に必要な改定を実施した上でリリースすべきです。
　そう言う大変さ、難しさの一端は、理解できたような気がします。

　任天堂スイッチなんかも、そうなのでしょうが、ジェスチャ(体)を使ったゲームって言うのは面白いのですよね～。後出しジャンケンゲームのテストプレイヤは、当方一人だけなので、調整しきれていない部分は、皆様がプログラムを調整・修正してお楽しみください。