はじめに
はじめまして、OX ENGINEER STUDIO でサーバーエンジニアをしています、森本と申します。
私は転職してサーバー開発業務に携わるようになりましたが、普段業務をしている中でも業界全体として見てもクライアントエンジニアが占める割合がかなり多く、業界のサーバーに関する情報が探しにくいと感じたため「新卒の頃に知れていたら就活の方法も違っただろうに！」という思いから本稿を執筆させていただくことになりました。今回はサーバーに携わる職種の中でも業界でも広く募集しており、筆者の職種でもあるWebサーバーにおけるサーバーエンジニアについて触れていきます。
サーバーって何をしているかよくわからない方や、情報系の大学に所属していてゲーム業界を目指したい方、web開発などの他業種でサーバーに触れていてゲームが大好きだという方、本稿がそういった方々がゲーム業界を目指す一助になれればと幸いです。
サーバーの仕事とは
サーバーの仕事とは基本的には「データを守る仕事」です。ユーザーがいつでもどこからでも遊べるようにデータを保存しておく、チートやバグによって作成されたデータを弾く、そういった業務を普段行っています。
もう少しユーザー目線に沿った話をすると、普段スマホゲームやオンラインゲームをよく遊ばれている方であれば、すぐにイメージができるかと思いますが、機種変更の際に行うデータ引継ぎやスマホごと紛失してしまったなどのアカウント復旧が「ユーザーがいつでもどこからでも遊べるようにデータを保存しておく」にあたります。具体的には以下のような管理の仕方をするのですが、筆者はこういった設計を考える業務が一番好きなポイントかなと思っています。
ユーザー情報の管理テーブル
| user_id | name | login_date |
| 1 | chibito | 2025-03-21 00-00-00 |
ユーザー所持アイテムの管理テーブル
| user_id | item_id | count |
| 1 | 4 | 1 |
アイテム情報の管理テーブル
| item_id | atk | def |
| 4 | 5 | 0 |
一方で「チートやバグによって作成されたデータを弾く」というのは実際に目にすることが無いのでわかりにくいと思いますが、希少なアイテムを運営の意図しない方法で大量に入手しようとした場合などがあてはまります。具体的には以下に示すようなデータの比較を行っているのですが、クエストクリアで1個しか入手できないアイテムを100個手に入れたことにしようとしているので、ダメですと突き返すようにしています（実際に例示したようなデータを弾きましたよという通知は毎日のように拝見します）。ほかにも様々なシチュエーションがありますが、このようなデータを許すと、ゲームのバランスが崩壊して寿命を短くしてしまうので、絶対に許さないようにしないといけません。
保存しているデータ
| user_id | item_id | count |
| 1 | 7 | 1 |
クエストをクリアした際に送られてきたデータ
{
user_id: 1,
item_data: [
{item_id:7,count:100}
]
}
サーバーが与えるゲームの面白さとは
前項でサーバーの仕事が現代社会において必須であることを説明したつもりですが、中には「せっかくゲームを開発するのであれば面白さを作る仕事をしたい」と思う方もいらっしゃるかもしれません。実際にそんな話を耳にしたこともあります。私としてはデータ設計や綺麗に処理が流れるとパズルみたいで面白いと思うのですが…
そういったこともあり、サーバーの技術を学ぶことで開発できるようになる、ユーザーの遊びに直結するゲームの機能についても触れていきたいと思います。それが「データの共有」、「マッチングシステム」、「動的データ同期」になるのですが、これらはサーバーがないと成り立ちません。
「データの共有」の「マッチングシステム」に関しては説明するまでもないかもしれませんが、お互いの接続先を交換するよりもサーバーを立てて、ユーザーは接続先が固定された場所にデータを取りに行ったりマッチング相手を問い合わせに行ったりする方が、運営をコントロールしやすく実装も容易になるかと思います。マッチング後はユーザー同士で通信する方が早いため、昨今ではサーバーへのマッチング相手の問い合わせと、その後はユーザー同士で通信するハイブリッド的な手法が一般的となっています。
また、「動的データ同期」というのはあまり聞き馴染みが無いかもしれませんが、ゲームプレイ中に突発的に運営からゲーム内にアクションを起こすようなことを指します。配信者をよくご覧になる方であれば、目にしたことがあるかもしれませんが、称号（公式マーク）などの付与やゲーム内通貨の付与がこれにあたります。仕組みとしてはデバッグ機能と変わらないかと思います。こういったデバッグ機能は基本的には悪用されないよう本番環境で使用できないことが多いですが、ユーザーとのコミュニケーション手段として面白いと思いますので、個人的にはリスクとのトレードオフをしっかりしたうえで実装したい機能だと思います。
最後に
今回はサーバーの普段の業務内容とサーバーの面白さについて紹介させていただきました。少しでも興味を持っていただける内容になっていたでしょうか。
長々と文章を書き綴ってしまいましたが読者の皆様に伝えたいこととしましては、一人でゲームをするより皆でゲームをするのが好きだという方や、配信者の配信中に称号をプレゼントするといったような、開発側からユーザーへアクションを起こしたいという方は、是非サーバーについて学んでいただければ幸いです。
次回は実際に使用されるPHPやSQL、HTML、JavaScript、シェルスクリプトを勉強する方法について紹介できればと思います。
ここまでご覧いただきありがとうございました。次回もよろしくお願いします。
