
ゲームプログラマーになりたいあなたに!ポケコロクライアント開発紹介
-
2021年5月13日
はじめまして、ポケコロクライアント開発の T です。
今回はゲームプログラマーになりたい学生さんやそれを目指す方に向けて、開発のフローや実際の企画を踏まえて、ポケコロクライアント開発ではどのようなプログラムを組んでいるか紹介していこうと思います。
開発の流れ
下記のようなフローで開発を行います。
特に難しい手順ではなく、学生さんでもすぐに把握できる内容となっております。
また、新入社員には、メンターと呼ばれる開発中の疑問やトラブルなどに対応する人を 1 人以上つけることで、安心して開発できる開発環境を目指しています。
実際の企画書
基本的には Confluence で企画の作成を行います。
フローチャートに書かれていた「企画とのすり合わせ」では、実際にそのページと企画者が作成したスライドシートを見ながらすり合わせを行います。
リモートワークなどで会議室などに来れない場合でも Google Meet などを用いて画面共有を行うため、特に問題は発生していません。
下記はポケコロのバイトイベントで用いた実際の企画書です。スライドは大体 30 ページ前後で各種シーンの遷移や詳しい状態が記載されています。
その他にも、以下のような内容も事前に記載されます。
- リリースまでの日程
- 各種リソースの納品予定日
- 今後の拡張の予定
- NPCの情報
- 画面遷移各種
- サーバーのすり合わせ
など
プログラムの流れ
まず、必要な画面について把握した後にクラス設計を考えます。
一般的に、シーン(画面)が複数ある場合、ステートパターンで行うことが一般的です。メッセージ型などで実装しても問題はないのですが、後から作業する方のことを考えて実装を行います。
これらを考慮すると以下のようなクラスツリーとなり、実装することになりました。
- 後続が開発しやすい
- 類似のバイトイベントがでた場合、使いまわせる
- シーンをチェンジした時に、どのシーンからでも別のシーンにつなげることができる
など
プログラムの流れ②
ソースコード内は自社ライブラリによる Cocos2dx 並びに C++11 を利用したソースコードとなっております。
void (BaitoAutumnOrderPopup::loadData() { auto pokecoloResource = ApplicationContext::getInstance().queryComponent<ResourceCache>(); ResourceSymbol::Ptr symbol = pokecoloResource->load("pokecolo_baito/popup"); main_symbol_ = symbol->extractInstance("mainframe"); main_symbol_->clearAdditonal Transform(); auto winSize = VectorObjectDefines::getScreenSize(); CCNode* node = main_symbol_->asNode(); node->setPosition(0, winSize.height/2); addChild(node); }
こちらはリソースファイルを読み込む処理となっています。単純で扱いやすいものとなっており、ロードしたファイルを中央に配置する内容となっております。
今回の場合では、リソースの元々の中心点が中央上となっているので、 setPostion で height / 2 の高さを追加しています。
void CBaitoAutumnOrderPopup::init() { order_symbol_ = info_symbol_->getInstance("img_orderslip"); make_button_ = interface_cast<PokecoloButton>(info_symbol_->getInstance("btn_make")); make_button_->setPushHandler([this](PokecoloButton* button) { end_closure_(TYPE_MAKE); close(); return true; }); make_button_->setTouchPriority(ResourceModel::kTouchPriority_BUTTON_ON_POPUP); }
あとは適当にボタンを追加していきます。
各種 node の先にボタンなどがついているノード型なので、こちらはリソースに合わせてそのシンボルの中を潜っていく形になります。そこまで難しくないですね。
プログラムの流れ③
UIの表示は先ほどのプログラムで問題はありませんが、各種パラメータはサーバーと通信をして取得する必要があります。
ポケコロでは、通信に websocket, パラメータの設定に Protocol Buffers(プロトコルバッファー) というフォーマットを用いています。
プロトコルバッファは *.proto と呼ばれるファイルの中に、通信に必要なパラメータを追加してコンパイルを行い、メインのプロジェクトに含まれるソースコードから呼び出しを行います。
message Request Harvest { repeated CmdList cmdlist = 1; message CmdList { optional int32 itemno = 1; optional int64 seq = 2; } }
定義に関しても上記のように簡単で扱いやすいものとなっています。
また、下記のように適当にシェルを作って*.protoをまとめてビルドするのも良いかもしれません
(※適当に作ったので中身はご愛嬌)
#!/usr/bin/env sh for i in `find_def | grep .proto` do echo $i ../../tools/protobuf/sbin/protoc --proto_path=./def --cpp_out=./c++ --java_out=./java $i done
最後に websocket の動作をラップした CP1Rpc から通信を投げて完了です。
CP1Rpc<RegHarvest, ResHarvest> rpc(context, "/api/harvest"); auto req = rpc. req().get(); req->set_ownermid( ownermid ); req->set_frommid( frommid ); req->set_cnt( cnt ); rpc .set_fail([this,doneCallback] (bool hasMessage, remote_result_t r) { Res Harvest dummy; doneCallback( false, dummy); }) .smartRequest([this,doneCallback] (std::shared_ptr<ResHarvest> msg) { doneCallback( true, *msg); });
最後に
今回はポケコロ開発における実際の流れをご紹介しました。
もしかしたらみなさんの想像通りの開発工程で、目新しいものはなかったかもしれません。
ただ、このような工程を思い浮かべられているということは、今学んでいることが必ず開発現場で生かされるだろうという確信につながったのではないかなと思います。
また、最近はデザインパターンなどは当たり前の話になっており、やれメッセージ型などもてはやされています。
が!やはりこういう基礎や古い知識を改めて確認することは新しい技術を取得するにあたりかなり必要になってくるので、これからも精進していきましょう!
ココネでは一緒に働く仲間を募集中です。
ご興味のある方は、以下のリンクから是非ご応募ください。