cocos2dxで6ヶ月でテトリスを作る方法

私の記事では、2人が作ったゲームの技術的な部分を共有したいと思います。 cocos2dxエンジンを使用する際の主要なアーキテクチャパターン（設計パターン）とテクニック、追加のライブラリ、移植機能が考慮されます。 ソースコードはこちらです。







ゲームはビーバー時間と呼ばれます。 妹がデザインを担当しました。 開発は、C ++のcocos2dxエンジンで行われました。

ゲームプレイ

基礎は、テトリスゲームのメカニズムから取得されます。 同じ四角の水平および垂直の破壊（4行連続）、さまざまなプレイヤーの呪文、能力、さまざまな勝利条件、ゲームを複雑にするさまざまな不快な瞬間、および四角ボスを追加しました。

建築

MVC



ゲームコードで使用されるメインテンプレートはMVC（ Wikipediaの説明 、 Appleのドキュメント ）です。 テンプレートは、モデル、ビュー、コントローラーの3つの部分で構成されています。 コントローラーは、モデルとビューの間を仲介します。 さらに、各部分には独自の責任があります。 例は、ゲームボード（ゲームワールド）の実装です。



1）モデル。 メインゲームの次のエンティティが区別されました：正方形、正方形からの詳細。 ゲームにはゲームボード（ GameBoardViewDataSource ）もあり、各セルは座標に対応しています（たとえば（ 1、1 ）、（ 32、48 ））。 黒板は正方形のコレクションです。 ただし、これはデータモデルです。 アイテムは基本的に小さなボードです。



2）コントローラー。 ゲームボードのコントローラー（ GameBoardController ）は、モデルをいつ描画するかを決定します。 彼は、モデルの内部構造（配列、リンクリスト）を知りません。 彼は細胞の数と各細胞に関する情報を得る方法だけを知っています。 cocos2dxのコンテキストでは、これはNodeクラスの子孫です。



3）プレゼンテーション（スプライト）。 ビューは正方形（描画コード）を描画しますが、データ構造については何も知りません。 cocos2dxのコンテキストでは、Spriteクラスです。 コントローラーには、レンダリング用のデータ（テクスチャ、位置）を提供するスプライトのコレクションが含まれています。



ゲームの開発では、パッシブMVCが主に使用されました-コントローラー自体が必要に応じてモデルからデータを取得します。



ゲームにはメインコントローラー（ GameWorldController ）があり、ゲームボードのコントローラーとアニメーションコントローラーに状態を更新するよう指示します。 さらに、彼はゲームシステムのステータスも更新します。



1）Win-loseシステム（ WinGameSystem ）-プレイヤーが勝ったときと負けたときを決定します。



2）ゲームイベントのシステム-悪意のあるイベントをいつ開始するかを決定します（ゲームの速度を上げ、いくつかの不要な詳細を捨てます）。



3）ゲームロジックのシステム（ TetrisLogicSystem ）-正方形の行が組み立てられているかどうかを確認します。4つの同じ正方形が垂直または水平に並んでいます。



4）スペルシステム（ SpellRechargeSystem ）-スペルのステータスを監視します。



5）現在のプレーヤー部分の制御システム（ CurrentDetailController ）-部品を制御し、1ステップ下げるなど。



6）ボスのステータスを監視するシステム。



ゲームプレイの各要素には独自のシステムがあります。 アニメーションコントローラーは、システムごとに個別のコントローラーで構成されています。 これらは、Actionクラスとそのサブクラスに基づいています。 通常、アニメーションの後、何らかの種類のイベント（ポイントの増加、最下行の削除など）が発生するため、システムはコントローラーにコールバック関数（たとえば、c ++ 11のラムダ）を送信します。 これは、アクティブなMVCの使用例です。モデル自体が必要に応じてコントローラーにアクセスします。



このようなシステムの利点は、柔軟性です。 新しいゲームプレイ要素を追加するには、新しいシステムと場合によってはアニメーションコントローラーを追加します。 欠点は、その複雑さと実装のためのコードの量です。 更新順序により、システム間で暗黙的な依存関係が発生する場合があります。



ロナー



ゲームの開発では、Lonerテンプレート（ ServiceLocator ）もよく使用されました。 ソースコードでは、これは純粋なLonerではなく、アクセスメソッドによって隠されたグローバル変数です。 実際、それはモデルのコンテナでした。 たとえば、プレーヤーがマップ上のレベルを選択すると、ローダー（ GameLogicLoader ）が必要なモデル（現在のレベル、システムのデータ）をこのコンテナーにロードします。 そして、コントローラーはそこから必要なモデルを取得します。 コントローラーでモデルを直接作成することは可能ですが、これにより追加の依存関係が発生します。



工場



ファクトリー（ファクトリーメソッド）テンプレートは、ゲームでよく使用されます。ゲームには7つのシーン（スクリーン）があり、各スクリーンにファクトリーが作成され、必要なモデルをロードしてコントローラーからシーングラフを収集します。 たとえば、クラスLoadingGameSceneFactory 。



オブザーバー



また、パターンObserverを使用しました。 特定のイベント（ポップアップ）によって表示される非表示の要素があるシーンでは、オブジェクトが作成され、オブザーバー（ポップアップ）は特定のメッセージをサブスクライブします。 次に、イベントが発生すると、このオブジェクトに通知が送信され、オブジェクトは必要なオブザーバーに通知を送信し、ポップアップが表示されます。 たとえば、 RegulateSoundPopUpクラスは、初期化時にGamePopUpsControllerからのメッセージをサブスクライブします。



戦略



また、Strategyテンプレートも使用しました。 たとえば、ボスによって行動が異なります。何もしない人もいれば、危険から逃げる人もいます。 それらの動作を実装するために、一連の戦略が使用されました。 戦略のコレクションが作成され、必要なものが記入されます。 異なる戦略を追加することにより、上司に異なる動作を追加します。 たとえば、 AIMovementStrategyクラスは、ボスに移動能力を与える戦略の1つです。



追加のライブラリ。



プレイヤーの統計を収集するために、Google Analyticsを使用することが決定されました。 iOSおよびAndroid用のGoogleアナリティクスSDKがありますが、Windowsの実装はありませんでした。 SDKドキュメントを読んだ後、 Google Analytics Measurement Protocolを使用することが決定されました。 このようなプロトコルの使用例（ GATrackerpp ）は、インターネットでcurlライブラリを使用して発見されました。 その結果、分析を送信するクロスプラットフォームの実装になります。 ただし、情報を送信するには、GUID標準に従って一意のプレーヤー識別子が必要です。 また、クロスプラットフォームでGUID識別子を生成するためのライブラリ（crossguid）も見つけました。 確かに、Androidの最後には、すべての人に1つのGUIDを使用することが決定されました。 C ++をJavaに接続する方法がわかりませんでした。



レベル設定でxmlファイルを解析するために、クロスプラットフォームのpugiXMLパーサーを使用することが決定されました。 これは、大きなファイルを解析する必要がなく、cocos2dxフォーラムでアドバイスされたために選択されたDOMパーサーです。



移植機能。







最初は、通常のウィンドウアプリケーションであるウィンドウの開発が行われました。 その後、windowsストア用のポートが作成されました-windowsRT上。 その後、アンドロイド用のバージョンが作成されました。 クロスプラットフォームプロジェクトを整理するために、gitのブランチシステムが選択されました。 プラットフォームごとに個別のブランチが作成されます。 主なエラーは、ブランチのコードベースが少し異なることでした。 cocos2dxリポジトリなどの単一のカーネルはありません。 後で、プリプロセッサコマンドをファクトリクラス（ファクトリテンプレート）にカプセル化しながら、最初にC ++プリプロセッサを使用できることを学びました。 しかし、ブランチはまだ有用でした。 プラットフォームが異なれば、グラフィックやインターフェイス要素の位置も異なります。 同時に、Androidのすべてのコードは最初にWindowsでテストおよびデバッグされ、その後Android向けにビルドされました。



もう1つの重要なポイントは、異なるプラットフォームのファイルシステムにファイルを保存する方法を検索すること、およびAndroidでapkファイルをアーカイブすることでした。



サウンド形式は問題を引き起こしませんでした-すべてのプラットフォームでmp3が使用されました。



開発中の奇妙な点：



1）ポストインクリメント（i ++）が1つのクラスでコンパイルされなかったため、事前インクリメント（++ i）を実行する必要がありました-Androidのバージョン。

2）エンジンはキリル文字のパスをサポートしていませんでした。 Windowsユーザー名がロシア語で記述されている場合、ゲームはエラーを引き起こし、起動しません。

3）メソッドの実装がエンジンにないため、サウンドが機能しないことが判明した。 別のクラスを使用する必要がありました。



要約：



結論として、使用された主なパターン：MVC、Factory、Loner、Observer、Strategyに注目したいと思います。 主な追加ライブラリはcurlとpugiXMLでした。 ゲームの開発には6か月かかりました。 それらの：

• 2〜3週間、メカニックについて考え、技術仕様を作成し、
• アーキテクチャを熟考し、モデルクラスを記述する1か月、
• エンジンを構築し、レンダリングとアニメーションのクラスを作成する月
• ゲームのバランスをテストして調整する1か月、
• WindowsRTへの移植に2〜3週間（フルスクリーンでのゲーム）
• Androidへの移植に2〜3週間（プロジェクトを構築するための環境を設定し、シミュレーターでテストします）。

プロジェクト全体のソースコードはここで、フィルター付きのWindowsプロジェクト（ソースファイルのディレクトリ）はここで表示できます 。

最後に、私はゲームをリリースし、プロジェクトに取り組んだときに多くの経験と喜びを得ました。



ご清聴ありがとうございました。