[BGA Studio] Hello BGA! その3
前回から続いて、クライアント側の各種処理と、サーバ側のnextPlayerの処理を実装していきます。
なお、今回の連載で制作したプロジェクトはこちらにあります。ご自由にどうぞ。
サーバ側：次のプレイヤーの手番へ遷移
状態遷移(states.inc.php)にて、次のプレイヤーへ遷移するためのステートはnextPlayerという名前を割り当てています。このステートには、typeにgameを割り当てていますが、これはプレイヤーの操作にはならず、ゲームの処理だけが行われるステートであることを示しています。
ちなみに、プレイヤーの操作は回ってきませんが、WebクライアントではonEnteringStateやonLeavingStateがコールバックで呼ばれるので、プレイヤーが交代する時にクライアントで何かしたい時には処理を入れられます。
typeがgameのステートはアクションの定義場所も特殊です。stNextPlayer関数は[ゲーム名].game.phpで直接定義します。
function stNextPlayer()
{
$lastPlayerID = self::getActivePlayerId();
$allData = self::getAllDatas();
foreach ($allData['players'] as $playerID => $player) {
if($this->cards->countCardInLocation('hand', $lastPlayerID) <= 0){
$this->gamestate->nextState('endGame');
return;
}
}
$playerID = self::activeNextPlayer();
self::giveExtraTime($playerID);
$this->gamestate->nextState('nextPlayer');
}stNextPlayer関数では、基本的は次のプレイヤーに手番が移るだけ(self::activeNextPlayer)ですが、誰かがカードを出し切ったら、ゲームが終了するように定義(endGameステートへ遷移)しました。(手番が早い人が最初に上がるので、ゲームにはなっていませんが…)
self::getAllDatas関数は、セットアップ関数以外の時は常にゲーム内の全情報を取得するのに使う関数です。基本的にはゲームに合わせて自分で定義する関数で、基本的な処理は最初から[ゲーム名].game.phpに定義されています。
ゲームで使っているDeckクラスのcountCardInLocation関数は、特定の場所にあるカードの枚数を数えます。誰かのカードが0になったら、その人が上がりなるので、そのように判定しています。
クライアント側：サーバからの通知の受信
前回の記事の作業で、サーバからクライアントへlogErrorとputtingCardを通知するようにしました。これらは各種状態遷移とは別にクライアント側でイベントとして発生するので、処理を実装していきます。
まずは、通知を受信するためにコールバックの登録を行います。setupNotifications関数が最初からsetup関数から呼ばれるように定義されているので、そこに追記します。
...
setupNotifications: function()
{
console.log( 'notifications subscriptions setup' );
dojo.subscribe('puttingCard', this, 'notify_puttingCard');
},
...dojoのAPIでコールバックを登録しています。これについてはよく使われる機能であるためか、BGA Studioのマニュアルに載っています。
サーバからの通知logError, puttingCardに対し、それぞれnotify_logError, notify_puttingCard関数をコースバックとして紐づけました。
プレイヤーの行動ログを残すようにするだけなら、コールバックを登録しなくても以下のように表示されますが、せっかくなので色々機能を盛り込んでいきます。
まずは、notify_logError。
...
notify_logError: function(notify)
{
this.showMessage(notify.args.message, 'error');
},
...サーバ側でlogError通知を使う時は、わざわざメッセージを渡さないようにしました。代わりに、ここでshowMessageを呼んでいます。これによって、同じメッセージがログに2度書き残されてしまうことを防ぐと同時に、ステータスバーにエラー表示をするようにしています。
...
notify_puttingCard: function(notify)
{
if(notify.args.player_id == this.getActivePlayerId()){
this.playerHand.removeFromStockById(notify.args.card.id);
}
},
...サーバからのputtingCard通知では、誰かがカードを出したことを伝えています。ただし、出した本人の場合は、手札からカードを取り除いています。
BGA Studio：プロジェクトページ・ウォークスルー
ここまで書いたら、FTPサーバに接続して、ゲームプロジェクトへファイルをアップロードします。その後、BGA StudioのControl PanelからManage games → デバッグするゲーム を選択します。開くページは以下のようになっています。
設定更新するためのボタンが並んでいるので、一つずつ解説していきます。
Reload game informations：
gameinfos.inc.phpを再読み込みします。それによって、ゲームの環境設定やプレイヤー人数を更新することができます。今回はその1の記事でプレイヤー人数を1～4人に更新しているので、リロードが必要になります。
Reload statistics configuration：
stas.inc.phpを再読み込みします。統計情報に変更を加えた時には更新する必要がありますが、今回は不要です。
Reload game options configuration：
gameoptions.inc.phpを再読み込みします。選択可能なルールを追加する時には、これを更新する必要があります。今回は不要です。
Reload game images：
ゲームのサムネイル画像等を再読み込みします。
Clear PHP cache：
サーバのPHPコードキャッシュをクリアします。これによって取り立てて何かが変わることは少ないとは思いますが、サーバの挙動がおかしい時には試してみてもいいかもしれません。
Delete this project：
読んで名の通り、プロジェクトを削除します。危ないので押さないようにしましょう。
さらに、チェックやリリース用の機能も用意されています。使ったことのあるものだけ解説していきます。
Check project：
プロジェクトのエラーやガイドライン違反、データ不足などをチェックできるWebアプリへ移動します。
Use minified JS / Revert to original JS,
Use minified CSS / Revert to original CSS：
アップロードされているJavascriptやCSSファイルの最適化、リフォーマットを行います。最適化は開発中に実行する必要はありません。リリースする直前に使用します。
最近(2020/8頃)追加された機能です。
せっかくなので、Check projectを押してプロジェクトチェックページに行ってみます。
BGAでよく見るゲーム画面っぽいページを開くので、ステータスバーにあるStartを押すと、チェックが実行されます。
各ファイルのエラーや警告、ガイドライン違反などが表示されます。
Board Game Geekに登録されているプレー人数(初回記事で登録した内容)までチェックして警告を出してきているのには驚きでした。ちなみに、イラストリーはこの警告を無視していて、BGA版では3～8人に設定しているので、警告はあくまで警告に留めているようです。
ここには翻訳テキストの一覧も出力されますが、翻訳テキストはアルファテスト段階まで行かないと入力できません。それまでは英語で頑張りましょう。
なお、ブラウザを閉じてもプロジェクトチェッカーは終了しません。画面にあるExitを押してください。
BGA Studio：ゲームのデバッグ
記事もようやくここまで到着しました。
ゲームを公開していない間は、BGAから直接ゲームをデバッグすることはできません。BGA Studio上でゲームを起動する必要があるので、まずはBGA StudioのPLAY NOWを開いて、ロビーに移動してください。
作っているゲームが並んでいるので、Createボタンを押してゲーム設定画面に移動します。
Express startを押すとゲームが始まります。基本的には開発アカウントが連番で使われていくようなので、マルチプレイをテストする時は、あらかじめ複数のWebブラウザやPCでBGA Studioにログインしておくといいでしょう。
普段はそれをやるのが手間なので、最大人数(I want between...の箇所の数字を両方とも)1人にしておくのをお勧めします。
他にも、追加ルールを設定している場合は、TABLE CONFIGURATIONにコンテキストメニューが追加されるのですが、今回は何も追加していないので持ち時間に関するレギュレーションしかありません。
さて、1人プレー設定にしてゲームを始めると、変なエラーメッセージが出てくるのですが無視してロードを待ち、ゲーム画面に入ります。
これまでの記事で機能を実装しているはずなので、カードやステータスバーに関しては自分で確かめてもらうとして、普段BGAで遊ぶ時にはないUIについて説明していきます。
Go to game database：
ゲームが使っているMySQL DBを開きます。アカウントは運営から送られてきたMySQLアカウントを使う必要があります。
ゲーム中の情報を確認するのに便利です。
BGA request & SQL Logs：
SQLクエリやサーバ側のデバッグ出力ログを見ることができます。過去のデバッグプレーをまたいでログが保存されているようなので、直近のログ以外も残っていて混乱しないように注意してください。
差し込んだログ出力が見つからない時は、PHPキャッシュをクリアしてみることをお勧めします。
BGA unexpected exceptions logs：
ゲームサーバ側で起こった例外のログを閲覧できます。クライアント側のエラーログは残りません。Webブラウザのデバッグ機能を使うなどして確認するとよいでしょう。
Save & restore state：
名前のごとく、ゲームの状態を保存、復旧することができます。
ゲーム序盤でなければ確認できない項目のテストや、ゲームが終わらないようにテストする時などに活躍します。
これらUIの下には、URLアクセス履歴やJSON応答結果などがログとして残ります。
デバッグ中のプログラム修正は、PHPやJavascriptを更新することでリアルタイムに行うことができます。ただし、DB更新の必要性が出た時や、サーバ側の状態がエラーでおかしくなってしまった時は、ゲームを再起動する必要があります。また、ブラウザキャッシュにJSファイルが残ってしまうような事態になった時は、Webページのハードリロードを行う必要があります。
ゲームをやめる時は、ページ右上のメニューからQuit this game(一人テスト時)かExress STOP(複数人テスト時)を選ぶと終了することができます。
まとめ
ずいぶん長々と説明してきましたが、作ったところまでがひとまず動くようになったので、ここまででHello BGA!の連載を終了します。
想像以上に内容が長くなり大変だったので、もしこれ以上BGA StudioやBGAでのゲーム公開についての情報に興味がある方がいらっしゃいましたら、Twitterなりnoteコメントなりでご連絡ください。また記事をやる気になって記事を書くかもしれません。
この記事が気に入ったらサポートをしてみませんか？