序文
一般的に、この業界でゲームを作り始める人は、既成のコードに機能を追加したり修正したりすることが多く、自分でゲームサーバーの設計を完了する機会はほとんどありません。小規模な企業にはそのような機会があるかもしれませんし、通常はそうするでしょう。既製のコードを見つけて直接開発します。内なる力を養うために、ゲームサーバーを自分で作る方法について今日は少しお話しましょう
1. サーバーアーキテクチャ
高い建物を地面から持ち上げるには、まず骨組みを作り、基礎を設置してから上げる必要があるため、構造設計を行ってから始める必要がありますが、経験が浅い学生ならすぐに理解できるでしょう。
今回の対象はカードサーバーなので以下のような設計になっています。
各サーバーとミドルウェアの役割を説明する
クライアントについては多くを語る必要はありませんが、クライアントを表しており、さまざまなテクノロジーによって開発されたクライアントになる可能性があります。
Gateはゲートウェイサーバーとしての役割と負荷分散を行う場所で、プレイヤーはログインするサーバーを選択してログインし、ここでコーナーを作成することができます。
ルームはバトルサーバーでもあり、プレイヤーはバトルマッチング後にルームサーバーに送られ、バトル終了後にゲームに戻ります。
ゲームでは、カードの取得、カード デッキの作成、アップグレード、その他のメイン ロジックなど、主要なビジネス ロジックが発生します。
2 技術選択の基準
サーバー テクノロジの選択は、基本的に自分の言語経験に基づいて行われ、最も習熟している言語を選択し、対応する実装を選択します。
モバイル ゲームが最も人気があった時代には、多くのサーバーが PHP で書かれていました。
多くの古いゲーム会社は C++ を選択します。これは歴史の遺産であり、昔のゲーム会社は C++ しか使えないからです。しかし、今では多くの会社が Java や Golang を使用しています。
新世代のプログラミング言語、高い生産効率、便利な採用が待っています。
なぜなら、私は長年 Java を使用しており、数年間 C++ を書いたこともありますが、まだあまり好きではなく、習熟していません。Java は私の母国語であると言えます。
3 Javaサーバーテクノロジー
3.1 通信フレームワーク: WebSocket
ここで WebSocket を選択したのは主にカード Web ゲームを作りたいためですが、これは甲の要件であるため、通信には必ず WebSocket を使用することを選択します。
もちろん、モバイル ゲームを作成する場合は、TCP、UDP などの通信プロトコルを自分で切り替えることができ、Java の効率的なネットワーク通信フレームワークとして Netty が第一の選択肢となります。
Netty は tcp と udp を適切にサポートしています
3.2 フレームワーク シリーズ: springboot、spring data jpa、spring security
Javaをやる人にとってSpringは避けては通れない、今や最も便利な開発フレームワークはSpringbootであり、フレームワーク全体としてはSpringbootシリーズを選ぶことに迷うことはない。
Spring data JPaはデータベースの操作に非常に便利で、複雑なSQLについてはテンプレートを直接利用することで制作効率が向上します。あなたはmybatisを選ぶことができます、そして私はあなたを軽蔑しません、私はそれが好きではありません。
GMインターフェースへのアクセス制御にはSpring Securityを使用しており、パッケージを追加して簡単に設定するだけで権限を制御できます。あまり考えすぎずに、とにかく急いでください。
3.3 コンポーネント シリーズ: easyexcel、dubbo、jetcache、akka、fastjson、protobuf
EasyExcel は Excel の基本データをロードするために使用されます。Excel をメモリに読み込むため、効率的で手間が省けます。最も重要なことは、Excel は計画やプログラミングに非常に親しみやすく、問題を見つけやすいことです。
Dubbo はサーバー間でリモート呼び出しを行うために使用され、シンプルかつ直接的であり、設定は必要ありません。
Jetcache は主にキャッシュとして使用されます。ゲームではデータベースへのアクセスが多く、キャッシュのレイヤーがないとデータベースに大きな負荷がかかるためです。
Akka は主にルームサーバーで使用されます。各ルームは 1 つのアクターに対応します。マルチスレッドの問題を考慮する必要はありません。単純かつ暴力的です。
Fastjson は Redis にアクセスする際のシリアル化に使用され、並べ替えを容易にするためにいくつかのランキング データを保存できます。
protobuf はクライアントとの通信に使用され、効率的でトラブルフリーで多用途です。
3.4 ミドルウェア: mysql、redis
Mysql はプレイヤー データの永続化に使用されます。ほとんどのゲーム会社がこれを使用しています。実際、ここでは MongoDB を使用するのが良いです。私は切り替えるのが面倒です。主な理由は、後でビジネスをアップグレードする方が便利だからですが、MongoDB ではまだ試していません。
Redis は基本的に、主にキャッシュの問題やサーバー間データの問題を解決するために使用されます。
3.5 コンテナコンポーネント: docker docker-compose
21 世紀なので、当然コンテナーを使用する時代です。Docker と docker-compose はシンプルで問題なくゲームに最適です。
運用とメンテナンスも安心で、両方の長所を活用できます。
4. まとめ
ゲーム アーキテクチャの設計は、実際にはそれほど難しくありません。業界で一般的なアーキテクチャです。実装の詳細を自分で習得する必要があるだけです。作業にもっと注意を払えば、すぐに理解できると思います。ゲーム業界に入って数年。
山に出会ったら山を築き、水に出会ったら橋を架けるという完璧な方法はなく、まず第一次矛盾を解決してから第二次矛盾を解決する必要があります。
まずは離陸し、姿勢を整えて突進します。
