優れたゲーム製品で、クライアントが考慮しなければならない問題があります.
3580 ワード
前言
この間、私は仕事を変えて、新しい会社に新しいプロジェクトグループに来ました.このプロジェクトはIPのあるカードゲームで、クライアントが採用しているエンジンはcococos 2 dx 2.XのC++バージョンで、UIエディタはcocosbuilderで、通信プロトコルはhttpです.実はいい製品ですが、クライアント全体のアーキテクチャには大きな問題があります.だから、このような文章を書いて、ゲーム製品のクライアントアーキテクチャに対する自分の考えを話したいと思っています.
アテンションアイテム
次に、クライアント開発に注意すべき点をいくつか羅列します.最も初期の段階で考慮しなければならないものがあります.開発の過程で、ゆっくりと最適化を調整できるものもあります.
クライアントエンジンの選択
まずエンジンの選択についてお話しします.今ではゲームエンジンがたくさんありますが、実際にはエンジンの選択では、特に多くはありません. Unity 3 d:3 D手遊び優先 Cocos 2 dx-js:2 D手游びの第一選択(実はLuaもいいし、C++バインドでは便利ですが、個人的にはJSが好きで、多くのエンジンがJSを開発言語としてサポートしています) Egret、Cocos 2 dx-js:2 Dページ旅行の第一選択(Egretは時間があって関心を持っていないで、今の機能がどうなのか分からないで、前にその機能を見て、実はそんなに強くありませんが、そのセットのツールはよくできて、私はその印象に対してやはりとても良いです) 開発プロセス
開発プロセスはプロジェクト全体の作業手配に関係し、プロセスが規範化されていない場合、効率は特に低くなります.信頼できるプロセスは、次のようなものです.
企画案->美術効果図->スペルUI(スペルインタフェースを担当するのが望ましい)->クライアント機能開発一般的にサービス側は美術効果図を見た後にプロトコルを確定し、プロトコルを確定した後、クライアントはプロトコル関連のコードを書くことができます(だからプログラムは基本的に美術効果図の後から着工し、企画して機能が間違っていることを発見したら、美術効果図のステップで修正するだけです)
また、企画案はゲームのいくつかのバージョンをリードしたほうがいいです.例えば、1.0は基本的な育成をしなければなりません.1.1は装備をアップグレードしなければなりません.1.2は労働組合システムをしなければなりません.1.3は新しい時間を殺す遊びを追加しなければなりません.特に細かくはありませんが、現在のバージョンをリードしなければなりません.繰り返し修正して、効率を遅らせるのはもっと士気に影響します.
美術、コード資源管理
ゲームで使用される美術リソース、クライアントコード、サービス側コードは、異なる倉庫の下に置くことが望ましい.このような理由は、次のとおりです.は一人一人の権限を区別することができます.例えば、美術は可能で、美術倉庫の権限 だけが必要です.美術資源、企画文書の変更によって、クライアントSVNバージョン番号 に影響を与えることはありません. ...
多言語バージョンの考慮
現在、ゲーム業界の競争は特に激しく、ある題材のゲームは大陸では人気がないが、東南アジアや北米で人気があるかもしれないので、多くのゲームに言語バージョンがある.ゲームの多言語バージョンの考慮は、非常に多くの仕事量を増加させるので、ゲームの初期には、必ず考慮しなければならない.多言語バージョンの中で文字の面は主に以下の通りである.コードの動的文字 企画表の中の文字 UIエディタで編集するテキスト UIのテキスト画像.(運営活動などの他の文字もあるかもしれません.UIレイアウトスタイルも考慮する必要があります) これらの文字の仕様は必ずカスタマイズして、後期の置き換えを便利にしなければならない.大体のルールは、これらの文字を最終的に1枚(または数枚)の文字表にインポートすることであり、後期は文字表を置き換えることで直接新しい言語パッケージを出すことができる.この中の文字画像は比較的特殊であるが、文字画像に接頭辞を付けることで置き換えるかどうかを区別することもできる.
ゲーム中の誘導と戦闘モジュールの設計
この2つのモジュールは最初は設計が悪いと、後期になると前者はメンテナンスが難しくなり、後者は拡張が難しくなります.強制誘導部分はコードに問題があれば、プレイヤーは基本的に直接流失します.戦闘モジュールは、1つのゲームが戦闘に対する要求が高い場合、戦闘論理の拡張性が非常に強い必要があります.(例えば企画でふと思いついたスキル「灼傷」、効果:人物攻撃時に30%の確率で敵を灼傷状態にする:毎秒100血を引いて10秒持続する.プログラム側はこのような状況をサポートしていないとは言えない、あるいは長い時間をかけてコード構造を変更するとは言えない)
ゲーム更新メカニズム
これもポイントです.現在、ますます多くの手遊びがシナリオ開発を採用しており、ゲームの更新プロセスを大幅に簡素化し、再配布する必要はありません.一般的には、ゲームにはc++コード、スクリプトコード、リソースファイルの3つのバージョン番号があります.更新には、クライアントの現在のリソースが最新であるかどうかをどのように判断するか、注意すべき点がたくさんあります.方(appstoreに新しいパッケージがリリースされた場合、ユーザーは更新によってインストールの操作を実現し、既存のダウンロードリソースを空にすることはありません).
画像メモリの最適化
ゲームメモリ最適化のソリューションは、ネット上ではすでに多くなっているので、ここでは展開しません.
トランスポートプロトコル
httpとsocketで通信方式を選択すると、私はsocketに傾いています.socketを通じてバイナリデータストリームを伝送するのは非常に節約でき、httpでjsonを伝送する方式の1/4~1/3と推定されています.そしてsocketはサービス側に自発的にクライアントにメッセージを送信させることができます.唯一注目すべきは、断線再接続です(iPhoneがバックグラウンドに退くと自動的に断線します).
クライアントUIの適切な問題
これは大きな問題で、どちらを採用しても特に完璧ではないので、具体的な案は美術設計と結びついています.
Android対応
Androidの機種が多様なため、私たちのゲームはAndroidデバイスによって表現が異なる可能性があります.比較的現れやすいのは以下の点です.画像による問題:一般的に1枚の画像のサイズは1024*1024を超えない(モデルAndroid機種のopenglはより大きなサイズをサポートしていない) メモリの問題 ...
シーン管理、ポップアップ管理
シーン、ポップアップウィンドウを区別し、2つのマネージャで表示と切り替えを制御することをお勧めします.
メッセージトリガメカニズム
便利なメッセージトリガメカニズムは、コード構造をより明確にすることができます.一般的に、このメッセージメカニズムはオブザーバーモードを採用し、コード実装は大きく異なります.
各種スクリプトツール
ガイドテーブルなどの必須ツールに加えて、開発にはさまざまなスクリプトツールが必要で、開発効率を向上させることができます.たとえば、SVN(GIT)の更新やバージョン番号の取得、小図の大図へのパッケージ化、文字抽出の置き換えなどの機能は、1つのスクリプトで実現できます.pythonで書くことをお勧めします.主にプラットフォーム間、サードパーティ製ライブラリが多いためです.
本文は同期して個人のウェブサイトxtuu.meに発表します
この間、私は仕事を変えて、新しい会社に新しいプロジェクトグループに来ました.このプロジェクトはIPのあるカードゲームで、クライアントが採用しているエンジンはcococos 2 dx 2.XのC++バージョンで、UIエディタはcocosbuilderで、通信プロトコルはhttpです.実はいい製品ですが、クライアント全体のアーキテクチャには大きな問題があります.だから、このような文章を書いて、ゲーム製品のクライアントアーキテクチャに対する自分の考えを話したいと思っています.
アテンションアイテム
次に、クライアント開発に注意すべき点をいくつか羅列します.最も初期の段階で考慮しなければならないものがあります.開発の過程で、ゆっくりと最適化を調整できるものもあります.
クライアントエンジンの選択
まずエンジンの選択についてお話しします.今ではゲームエンジンがたくさんありますが、実際にはエンジンの選択では、特に多くはありません.
開発プロセスはプロジェクト全体の作業手配に関係し、プロセスが規範化されていない場合、効率は特に低くなります.信頼できるプロセスは、次のようなものです.
企画案->美術効果図->スペルUI(スペルインタフェースを担当するのが望ましい)->クライアント機能開発一般的にサービス側は美術効果図を見た後にプロトコルを確定し、プロトコルを確定した後、クライアントはプロトコル関連のコードを書くことができます(だからプログラムは基本的に美術効果図の後から着工し、企画して機能が間違っていることを発見したら、美術効果図のステップで修正するだけです)
また、企画案はゲームのいくつかのバージョンをリードしたほうがいいです.例えば、1.0は基本的な育成をしなければなりません.1.1は装備をアップグレードしなければなりません.1.2は労働組合システムをしなければなりません.1.3は新しい時間を殺す遊びを追加しなければなりません.特に細かくはありませんが、現在のバージョンをリードしなければなりません.繰り返し修正して、効率を遅らせるのはもっと士気に影響します.
美術、コード資源管理
ゲームで使用される美術リソース、クライアントコード、サービス側コードは、異なる倉庫の下に置くことが望ましい.このような理由は、次のとおりです.
多言語バージョンの考慮
現在、ゲーム業界の競争は特に激しく、ある題材のゲームは大陸では人気がないが、東南アジアや北米で人気があるかもしれないので、多くのゲームに言語バージョンがある.ゲームの多言語バージョンの考慮は、非常に多くの仕事量を増加させるので、ゲームの初期には、必ず考慮しなければならない.多言語バージョンの中で文字の面は主に以下の通りである.
ゲーム中の誘導と戦闘モジュールの設計
この2つのモジュールは最初は設計が悪いと、後期になると前者はメンテナンスが難しくなり、後者は拡張が難しくなります.強制誘導部分はコードに問題があれば、プレイヤーは基本的に直接流失します.戦闘モジュールは、1つのゲームが戦闘に対する要求が高い場合、戦闘論理の拡張性が非常に強い必要があります.(例えば企画でふと思いついたスキル「灼傷」、効果:人物攻撃時に30%の確率で敵を灼傷状態にする:毎秒100血を引いて10秒持続する.プログラム側はこのような状況をサポートしていないとは言えない、あるいは長い時間をかけてコード構造を変更するとは言えない)
ゲーム更新メカニズム
これもポイントです.現在、ますます多くの手遊びがシナリオ開発を採用しており、ゲームの更新プロセスを大幅に簡素化し、再配布する必要はありません.一般的には、ゲームにはc++コード、スクリプトコード、リソースファイルの3つのバージョン番号があります.更新には、クライアントの現在のリソースが最新であるかどうかをどのように判断するか、注意すべき点がたくさんあります.方(appstoreに新しいパッケージがリリースされた場合、ユーザーは更新によってインストールの操作を実現し、既存のダウンロードリソースを空にすることはありません).
画像メモリの最適化
ゲームメモリ最適化のソリューションは、ネット上ではすでに多くなっているので、ここでは展開しません.
トランスポートプロトコル
httpとsocketで通信方式を選択すると、私はsocketに傾いています.socketを通じてバイナリデータストリームを伝送するのは非常に節約でき、httpでjsonを伝送する方式の1/4~1/3と推定されています.そしてsocketはサービス側に自発的にクライアントにメッセージを送信させることができます.唯一注目すべきは、断線再接続です(iPhoneがバックグラウンドに退くと自動的に断線します).
クライアントUIの適切な問題
これは大きな問題で、どちらを採用しても特に完璧ではないので、具体的な案は美術設計と結びついています.
Android対応
Androidの機種が多様なため、私たちのゲームはAndroidデバイスによって表現が異なる可能性があります.比較的現れやすいのは以下の点です.
シーン管理、ポップアップ管理
シーン、ポップアップウィンドウを区別し、2つのマネージャで表示と切り替えを制御することをお勧めします.
メッセージトリガメカニズム
便利なメッセージトリガメカニズムは、コード構造をより明確にすることができます.一般的に、このメッセージメカニズムはオブザーバーモードを採用し、コード実装は大きく異なります.
addEvent(eventType, callbcak)
trigger(eventType)
各種スクリプトツール
ガイドテーブルなどの必須ツールに加えて、開発にはさまざまなスクリプトツールが必要で、開発効率を向上させることができます.たとえば、SVN(GIT)の更新やバージョン番号の取得、小図の大図へのパッケージ化、文字抽出の置き換えなどの機能は、1つのスクリプトで実現できます.pythonで書くことをお勧めします.主にプラットフォーム間、サードパーティ製ライブラリが多いためです.
本文は同期して個人のウェブサイトxtuu.meに発表します