Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
10
Help us understand the problem. What is going on with this article?
@do7be

ソシャゲエンジニアが機能開発で気をつけるべき5つのこと

More than 5 years have passed since last update.

本記事はマイネット Advent Calendar 9日目の記事です。

3日目も書きましたがエンジニアの@do7beです。

業務ではソーシャルゲームの運営を担当しています。インフラからバックエンドからフロントまでほぼ全てを扱っています。運営と言うと定常イベントをまわすだけに聞こえるかもしれませんが、実際は月に3~5程度の機能開発も行っています。我流ではありますが、今回はその経験で得られた機能開発において気をつけるべき5つのことについてお話していきたいと思います。

1. 定常コストを限りなくゼロに

ソーシャルゲームの特徴として、月に決まったイベントが数個開催されるというものがあります。基本的にこれを定常イベントと呼び、どのタイトルでも定常イベントの準備が運営メンバーの業務の主軸となっています。この定常イベントというものが厄介で、今月のイベントの準備を終えても来月、再来月と毎月毎月行わなければなりません。ここで毎回ソースコードを修正しなくてはならない運用は避けるべきで、全てDBにマスタデータを入稿することでイベントの準備が完了するようにすべきです。

気をつけるべき点

  • VIEWに今月のイベント特有のテキストを書かない
  • 定数に今月のイベント特有のIDを代入しない
  • DBにデータを入稿することでイベント準備が済むようにする

2. パフォーマンス無視は未来の自分を殺す

機能開発の中には、カードに対して新しい軸のパラメータを実装する、などの要件があります。ここで参照系の処理のパフォーマンスに気をつけないと恐ろしいことになります。なぜなら、カードを数百枚持てるゲームから数千枚持てるゲームまであるので、多少の計算量だったはずが、1画面表示するのに30秒かかってしまうなどの問題が発生したりします。

気をつけるべき点

  • N+1クエリを極力作らない
  • スキップ系条件分岐前で関係ないクエリを発行しない
  • どうしてもクエリが重い場合はKVSを用いる

3. ログには調査に必要なものを

障害時やユーザ側操作ミスによってお問い合わせが来ることがあります。この度にDBにSELECTを発行して調査していると、調査手順が煩雑になったりわかりづらかったりするのであまりよろしくありません。また、エラーログも重要で、アラートが頻繁に発生した際にどのデータが問題なのか、誰がどのタイミングでどの画面にアクセスした際に発生しているのかを探るための情報が必要です。

気をつけるべき点

  • 正常ログにはどこまで処理が終わったか、どんなデータを用いたかを残しておく
  • エラーログには誰がどんなデータでどのアクションを行ったか残しておく
  • ログは機能種別ごとに出力する

4. 本質的なテストを書こう

動くものが正義とおっしゃる方もいるかと思いますし、実際動かないものより動くもののほうが正しいとは思います。が、機能開発時はいいとして、問題は改修時です。例えば返却データの修正、チューニング、リファクタリングなどを行った際に、開発時と同様に隅から隅まで検証する必要があるでしょうか?検証する必要があるとしたら、確認が大変なのにリファクタリングなどを行いたいと思うでしょうか?こういった背景から、テストを動かすことで動作の担保がとれることに重要性が生まれてきます。長年運用するサービスだからこそ、より良くしていくためにもテストは必要です。特に、機能の本質的な要素を満たしているテストが必要です。

気をつけるべき点

  • 機能の本質的な動作を満たすこと(データの加工・DBインサートなど)
  • 様々なデータインプットに対応したアウトプットを予期する

5. データ参照・操作系ツールは必ず用意

ソシャゲ業界では、エンジニアがいちいちDBにSELECTクエリを発行してマスタデータを確認したりする、なんてことをしないためにDB参照用のツールを用意しているタイトルがほとんどかと思います。ここで、マスタデータのみならずユーザに紐づくデータの確認機能を設けることもあります。これは障害時・調査対応時などに特に役立ちます。チームには非エンジニアも多く配属されており、基本的に誰でもデータ参照を行うことが出来る環境にすることでチームの連携が取れ、チーム全体の効率が向上することになります。こういった背景から参照ツールは確保しておくべきです。

また、「間違えてゲーム内ショップでアイテムを購入してしまった。返却してほしい」などのお問い合わせに対応する際に、DBにUPDATE文をそのまま叩こうとすると、手順ミスでスレーブを更新してしまったり、作業手順が煩雑になるなどの問題が発生します。なので、機能開発時は必ず関係するデータ更新系のスクリプトを用意しましょう。ここで肝心なのが、「ゲーム内コードを動作させてデータを更新する」ことです。これにより、データ更新漏れなどの余計な障害を起こさずに済みます。

気をつけるべき点

  • データ参照ツールは必ず用意
  • データ更新系スクリプトは必ずゲーム内コードを動作させること

まとめ

私がソーシャルゲームの運営を行ってきた中で得た教訓や先人の知恵などをまとめてみましたがどうだったでしょうか。まだまだ気をつけるべきことはたくさんあるとは思いますが、とりあえず今回の5つのことを気をつけることで、ゲーム運営においてより良いエンジニアリングが行えることを願っております。

10
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
do7be
NodeとかReactとか好き

Comments

No comments
Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account Login
10
Help us understand the problem. What is going on with this article?