今日は、モバイルアプリケーション、最初のゲーム、およびそのサムネイルの作成方法について詳しく説明します。
最初の記事はここにあります： リモートコントロールでボードゲームを作成した方法-パート1
注意！ 多くの写真。
最後の記事へのコメントで、彼らは、ゲームを作るのではなく、利用可能なメカニックを使ってゲームを作成することがすでに可能なプラットフォームを作る方が良いと正しく述べました。 当初、それを計画しましたが、結果として、ゲーム以外では何もできないことがわかりました。 ゲーム設計の経験が不足しているか、どのメカニクスをサポートすべきかを教えてくれる馴染みのあるゲームデザイナーがいるからです。
そのため、最初のゲームでプラットフォームのすべての基本機能（移動、動的な強調表示、プロンプト）を実装することにしました。 そして、得られた経験を使用して、本格的なゲームデザイナーを作成します。
モバイルアプリ
前述したように、すべてのプラットフォーム管理は、BLEプロトコルを介して接続するモバイルアプリケーションを介して実行されます。
いくつかのGIF 
実際、ゲームを実装するには、そのための本格的なモバイルアプリケーションを作成する必要があります。このアプリケーションでは、すべてのルールとメカニズムを記述します。
アプリケーションを作成する過程で、プラットフォームに接続してすべてのテストを実施しましたが、これはあまり便利ではありません。 そのため、デバッグを簡素化するために、アプリケーションのフレームワーク内に単純なソフトウェアエミュレーターを作成しました。このエミュレーターには、競技場で表示されるのと同じ方法でデータが表示されます。
最初に、アプリケーションを離れるデータが失われるという問題に遭遇しました。 BLEを使用する場合、送信できる最大パケットサイズは20バイトであることがわかりました。 したがって、BLE上のすべての送信データを20バイトのパケットに分割し、「Gate」パラメーターがヘッダーに書き込まれます。 このパラメーターは、Arduinoがこのパッケージが属するプラットフォームのコンポーネントを理解するのに役立ちます。 Arduino側から見ると、これらのパッケージの処理は基本的なものです。
if (NewCommandReady) { switch (CurrentGate) { case 1: processLEDCommand(); break; case 2: processDriverCommand(); break; case 3: processMagnetCommand(); case 4: // break; } // NewCommandReady = false; }
スマートフォンとBLEモジュール間のデータのストリーミングを20バイトのパケットに分割した後、データは消えなくなりましたが、多くの場合、歪んだ形でArduinoに届きました。 Arduinoシリアルポートに64バイトのバッファーがあることを考慮しなかったことが判明しました。 バッファがオーバーフローすると、データが失われ、後続のデータが歪んでしまいます。 サイズを増やして独自のバッファを作成しても、必ずしも助けにはなりませんでした。 確実にデータを送受信するには、BLEトランスポートの上にラッパープロトコルを記述する必要がありました。
このような「プロトコル」の使用により、送信されたデータの整合性をチェックすることでデータ交換がわずかに遅くなりましたが、ゲームにとって信頼性はより重要です-携帯電話で移動を確認するときに何らかの能力のAOE表示が不完全であるか、ヒーローが移動しない場合は残念です。
競技場にオブジェクトを表示するために、OSウィンドウサブシステムのレイヤーの原理を使用しました。
- ハイライトされている各オブジェクトまたはアクション（ヒーロー、障害物、ヒーローの移動方法、利用可能な能力の範囲、およびその他）は、独自のレイヤーを使用します。
- レイヤーが適用されると（たとえば、使用可能な範囲のAOE領域）、LEDの初期状態が記憶されます。 その結果、最上層が消えたときに元の色に戻すことができます。
モバイルアプリケーションとプラットフォーム間で転送されるデータの大部分は、LEDの再描画です。 最適化のために、いくつかのアルゴリズムが追加されました。
- ダイオードの再描画には、バッファが使用されます。バッファでは、物理ボードにこれらの変更が表示される瞬間まで変更が行われます。
- 同じコマンド内の単一のLEDの再描画は除外されます。
- 再描画するとき（たとえば、AOE能力の領域が1セルシフトするとき）、LEDボードの現在の状態が分析されます。 新しい状態のLEDの色が前のものと変わらない場合、再描画するコマンドはArduinoで受信されません。
ゲームプレイ
だから、プレイすることにしました。 以下に、側面からの様子を説明します。
- プラグをコンセントに差し込み、ゲームをオンにします。
- 起動するたびに、自動較正が行われ、1セルを移動するためのステッピングモーターの正確なステップ数が決定されます。
- 並行して、Bluetoothを使用してスマートフォンをゲームに接続します。
- モバイルアプリケーションでは、各プレイヤーがプレイしたいキャラクターを選択します。 全員が選択したら、「開始」を押します。
- 各キャラクターには独自の色があります。 ゲームは、ヒーローのフィギュアを置く必要があるセルを自動的に強調表示します。
- ゲームは順番に行われます。 最初の動きは最初にヒーローを選択したプレイヤーによって行われ、2番目は2番目などです。
- 各ヒーローには、アリーナ内を移動したり、能力を適用したりするために使用できるアクションポイント（OD）が一定数あります。
- 各能力には、ラウンドで計算される独自の回復時間があります。 モバイルアプリケーションのフレームワーク内には、2つの概念があります。移動-プレーヤーの現在のアクションの開始から終了までの間隔。 ラウンド-ゲームに参加しているすべてのプレーヤーの動きの合計。 現在、1人のプレーヤーのターンは30秒に制限されています。
- 障害物はフィールド上に置かれ、プレーヤーはほとんどの能力を通過したり使用したりできません。 現在、それらは競技場で単に赤で強調表示されていますが、将来的には物理的な具体化を持つことになります。
- あなたはすべてのヒーローが持っている特別な能力の助けを借りてフィールドを移動することができます。 たとえば、魔術師のテレポーテーション。 標準的な移動とは異なり、プレイヤーがヒーローのルートをセルごとに舗装する場合、これらの能力を使用する場合、プレイヤーはエンドポイントのみを示します。 その結果、衝突が可能なすべてのオブジェクト（他のヒーローのフィギュア、障害物のフィギュアなど）をバイパスして、指定されたポイントへの最短経路を見つけるアルゴリズムが必要です。
この問題は、グラフとBFSがセルを通過することで非常に簡単に解決されます。
要するに、アルゴリズムの本質は、ヒーローの現在の位置から指定されたセル（オレンジで示されている）までの距離でセルをマークし、そこにヒーローを移動させることです。
目的のセルを見つけた後、開始点から次のセルまでの距離が現在のセルよりも1短くなるように、セル内でリターンパスが検索されます（通路は黄色でマークされます）。 開始位置（緑色のセル）に戻ると、一連のポイントが形成されます。これが最短パスです。 ヒーローを動かすチームとしてArduinoに送信されるのはこのシーケンスです。
- ヒーローの死後、ゲームは彼のフィギュアを自動的に「ホームゾーン」に移動します。 ホームゾーン-ゲームの開始時にフィギュアが配置されるセル。 各プレイヤーは彼女自身を持っています。 ゲームを開始した後、ホームゾーンで能力を入力したり使用したりすることはできません。 これは、リバイバルでプレイヤーを捕まえることが不可能になるように行われます。 ヒーローが敗北したプレイヤーの場合、ゲームは1ラウンドで終了します。 彼が戦いに復帰した後。
- 現時点では、ヒーローが最後にフィールドに残って相手を打ち負かしたプレイヤーが勝ちです。 ただし、条件は異なる場合があります。たとえば、最初にN個のフラグメントを獲得した方が勝ちます。
これは、現在のバージョンで機能するゲームプレイです。 ゲームデザインの経験がないため、明らかな学校や機会は見当たらないでしょう。 たとえば、次の動きを待つのはつらいことです。 現在の実装では、待機時間は1.5分に達する可能性があります。 プロトタイプの次のバージョンでは、ゲームプレイを多様化するRFIDタグリーダーを追加する予定です。 たとえば、自分の番外で適用できるRFIDタグ付きのカードを使用します。
サムネイル
ミニチュアはすべてが大好きです！ そして、私たちも例外ではありません。 したがって、メカニックとプログラミングのコレクションと並行して、私たちは自分のミニチュアを発明することに従事していました。 写真から、私たちのゲームはアリーナで戦うファンタジー猫に関するものだと思います。
なぜなら 私たちは言葉からどのように引き出すのか全くわかりません。私たちは友人と向き合いました。友人は大きな喜びで「闘猫」を描き始めました。
彼女は私たちのペットを基礎としていました。 そのため、彼女の家には「海賊」と呼ばれる巨大で悪質な猫が住んでいました。ミニチュアの戦士の中心にいるのは彼です。
数週間後、最初のスケッチができました。
ボードゲームの制作に関する記事から、ロシアではミニチュアの作成は十分に悪く、多くの人がフィンランドやドイツで注文することに気付きました。
ミニチュアの生産を開始する前に、各ヒーローのマスターモデルを作成する必要がありましたが、これはプロトタイプには十分です。 最初はポリマークレイで作りたかったのですが、友人たちにはミニチュア奏者がいなかったため、当時はカスタムメイドが高すぎました。 そのため、最初に3Dプリンターで印刷することにしました。 これを行うために、私たちの友人は私たちにZbrushの最初のヒーローの3Dモデルを作成しました。
FDM印刷を使用すると、容認できる品質の数字を印刷することはできませんでした。
幸いなことに、私の妻はSLA 3Dプリンターを使用しています。
Stereolithography（SLA）は、光重合プロセスを使用して、レイヤーごとに光源を使用して液体材料を固体オブジェクトに変換できる3D印刷技術です。 SLAテクノロジーを使用した印刷中の層の厚さは、FDMを使用した印刷中の数倍小さいため、最終製品の品質は高くなります。
数日後、私たちは最初のミニチュアを受け取りました。
これらのミニチュアの品質ははるかに高いですが、プラスチック成形で得られる生産にはまだ達していません。 これの原因はサポートであり、削除後は目立つマークが残ります。 理論的には、サポートを使用せずに、フィギュアを個別のパーツに「カット」し、それぞれを個別に印刷してから、接着することができます。 しかし、それは多くの時間がかかり、さらに、将来的にも変化する可能性があります。
各図は独自のベースに基づいており、3Dプリンターでも印刷されています。 ベースの内側にはネオジム磁石があります。 磁石のサイズと厚さは、図がプラットフォームキャリッジの電磁石に静かに磁化されるように経験的に選択されましたが、隣接する図には反応しませんでした。
合計
現在、プラットフォームの物理的特性とすべてのコンポーネントの信頼性の向上に取り組んでいます。 合板をポリカーボネートとABSプラスチックで置き換え、プラットフォームコンポーネントの相互の固定を改善し、競技場を取り外し可能にして、別のフォームファクター（たとえば六角形）のフィールドに変更できるようにします。 次のステップは、本格的なMVPを作成することです。これは、人々に見せることを恥ずべきことではありません。
ゲームでは少し難しくなります。 もちろん、特定のゲームを参照することなく、プラットフォームの実装に完全に集中したいと思います。 ただし、ゲームのないプラットフォームに興味がある人はいないことを十分に認識しています。
あなたの批判/アドバイス/関心をありがとう。 メカニクスを使用せずに、フィールド上のフィギュアの位置とタイプを決定する機能を備えたバージョンを作成することを考えました。 次の記事はMVPの作成後に書かれると思います。