ソシャゲ サーバ開発時に気をつけること

サーバAPIの開発時に気をつけた方が良いことを、思いついたままにまとめました。

■ ユニットやアイテムの配布

運営に必要がなくとも、基本的にはゲーム内に登場するユニットやアイテム、コインなどの所有物はすべてプレゼントとして配布できるようにしておくと便利です。また、ユーザ作成時に所持しているユニットやアイテムなども、基本的にはすべて配布できるようにしておくべきです。これは開発時や負荷テスト、QA時に特定のユニットやアイテムを持った状態を作りたい時にすごく使えます。

■ユーザ単位でサーバ時刻を調整できるようにする

イベントのスケジュールを確認するときに便利です。ユーザ単位とする理由は、QAでスケジュールをチェックしてもらう際、複数の人で同時にイベントの開始と終了をチェックしてもらえるようになるからです。スケジュールの登録は思ったより大変な作業で、量と間違いも多いことから、効率よくチェックしてもらう仕組みを作っていると喜ばれます。

■負荷試験の事を常に念頭に置いておく

重いクエリを書くな! といった初歩的な事でなく、たとえばバトル時のスタミナ消費など負荷試験を行う上で障害となりそうな処理を書くときは、回避策を検討しておく必要があります。例えば、システムに負荷試験モードフラグを追加しておき、そのフラグがたっている場合は消費スタミナ数を0にするなどです。(処理事態を飛ばしてしまうと負荷試験にならないため、必ず 0 で更新するといったように処理が行われるよう工夫をします。)

MySQLのスレーブを使わない

スレーブサーバは遅延の関係上、ソーシャルゲームでは思ったより使えません。安価なサーバでマスタを多く作る設計をおすすめします。

漢字の勉強を始めました。

  • なぜ、漢字の勉強をするのか

社会人になると文字を書く機会は意外に多く、その最たるものは打ち合わせの場などでの白板です。このとき常識的な漢字が書けない事が続くと頭の悪い人として思われてしまいます。

私は専門学校卒です。

それも、やりたい事があって専門学校にはいったのではなく、勉強をサボり大学受験から逃げるようにして専門学校にはいりました。そのため学がなく、一般常識的な漢字でさえ書けないことが多いです。

そのため、打ち合わせの場や新人教育の時、書くことを恐れてしまいます。

このままではまずいため、漢字の勉強を始めることにしました。

目標は漢検準2級レベルです。

ソーシャルゲームのチュートリアルについて思うところ

無料のソーシャルゲームは、プレイするのに対価を払っているわけではないため、「せっかくお金をはらったんだし」という「もったいない感」がないため、売り切りのゲームに比べて簡単にやめることができます。

そのためソーシャルゲームでは初プレイで「良い印象」を与え、2回目をプレイしてもらう動機を作る必要があります。

Wikiに以下のような文章があります。

------------

三幕構成

通常、2時間映画の場合、こういった設定は第一幕のうち最初の10分ほどで行われる。この10分間はセットアップ (Set-up)と呼ばれる。セットアップの10分は全体で最も重要である。観客は多くの場合、最初の10分程度で映画の評価を決めてしまうためである。ここで退屈だったり、分かりにくかったりすると、観客は映画に集中することをやめてしまう

--------

ソーシャルゲームで言うとダウンロードしてからの最初のプレイのことで、ここでこのゲームは面白いという「印象」を与える必要があるのではないでしょうか?ですが、ほとんどのゲームが初プレイでチュートリアルに入り、そしてその中でバトルや合成などのやり方がメインで説明され、そして最後にガチャがおこなれます。

これで、ユーザに良い印象を与えれるのであれば良いのですが....

過去に複数のソーシャルゲーム案件を経験している身からいうと、ゲーム序盤のチュートリアルラッシュができる背景は、開発時のチュートリアル軽視にあると考えます。

よくある開発の流れは、

1. プリプロ .. バトル周りの実装

2. α版作成  .. バトル & メニュー、キャラなどの実装

3. β版の作成 .. チュートリアルを追加しパラメータなどの詰めを行う

4. β版によるQA

5. リリース

となり、チュートリアルは 開発終盤に作成することがほとんどです。

これは、メニューやバトルの実装ができないとチュートリアルが作成できないことにあります。

ですが、チュートリアルの仕様もこの段階で決めることが多く、合わせて開発終盤の忙しい時期となるため、その結果 「ゲーム序盤のチュートリアルラッシュ」ができやすくなります。

※この段階で合成の説明をされても...と思うゲームが多いです

ですのでゲーム序盤はチュートリアルと別物として扱い、α段階に含める必要があると考えます。 

GPS時計を購入しました。

ジョギング用にGPS時計を購入しました。

GPS時計とはその名の通り、GPS機能がついた時計です。
速度/距離をリアルタイムに確認したり、後でパソコン等で通った道を確認することができます。
また、手首にはめた状態で静脈から心拍数を計測してくれるものがあります。

ジョギングするのに、速度/距離を見れると嬉しいのは何となく分かりますよね。
では心拍数はなににつかうのでしょうか?

日頃から運動している人とそうでない人、同じ速度でジョギングしても疲れがちがいますよね?
自分にあったペース、これを把握するのに心拍数はピッタリなのです。
特に私みたいなジョギング初心者にとっては、今のペースが早めなのか遅めなのかが分かりません。
心拍数がでると、それが数値できちんと見ることが出来ます。
またトレーニングにちょうど良い心拍数もネットで調べるとわかりますので、今のペースで走り続ければ
トレーニングになるという安心感も得られます。

おすすめですよ!

情報のメタ化

情報のメタ化

「思考の整理学」を読んで、「情報のメタ化」という部分に大きな感銘をえました。

情報には、具体的・即物的なものを示す 一次情報と、
それらを抽象化した 二次情報、三次情報.. があり、
抽象化を進めることが、高度な思考となり普遍性が高まる

といったもので、
具体例として新聞を挙げると、一次情報は「個々のニュース」となり二次情報は「社説」。

抽象化の方法には、「ダイジェスト」や「要約」などがあり、
論文は「二次情報」もしくは「三次情報」で記載されるべきである と書いてありました。

これは、思考だけでなく仕事(ドキュメントやプログラム作成)、
コミュニケーションを行う上でも役に立つ考えで、日ごろから意識していかなければなりませんね。

ネットワークの品質を擬似的に落とす方法

リアルタイム通信のプログラムを書いていると、ネットワークに遅延やロスが発生した場合の挙動をチェックしたくなる時があります。

その場合は、tc コマンドを使うと便利。


例えば、ポート 32320に対する通信に 100ms のラグと 2%のデータロスを加えたい場合は以下のようにすると出来ます。

tc qdisc add dev ens32 root handle 1: prio
tc filter add dev ens32 protocol ip parent 1: prio 3 u32 match ip dst 0.0.0.0/0 flowid 1:3
tc qdisc add dev ens32 parent 1:1 handle 10: netem loss 1% delay 50ms
tc qdisc add dev ens32 parent 1:2 handle 20: netem loss 1% delay 50ms
tc filter add dev ens32 protocol ip parent 1: prio 1 u32 match ip dport 32320 0xffff flowid 1:1
tc filter add dev ens32 protocol ip parent 1: prio 2 u32 match ip sport 32320 0xffff flowid 1:2

元に戻す場合は

tc qdisc del dev ens32 root handle 1: prio