プロジェクトは相も変わらず大忙し。
絶対に4人月くらいあるんじゃないかなってレベルのような気がします。
・ゲーム内のUI画面実装
・ゲーム内各演出の作成
・ゲーム全体で利用するデータ設計
・メインとなるゲーム部分
・サーバーとの連携作業
・課金処理

これだけの容量を1か月で実装しろって言われて、ちょうど来週がオールイン予定。
しかしこの短期間でここまでやれたのは良い経験なのかもしれない。
少しくらい自画自賛してもいいよね？
え、ダメ？そうですか・・・


ソーシャルゲームというのは世間的に嫌われる部類のゲームなのであまり作り方のノウハウが世の中に出回っていない。
なので具体的にソシャゲというのはどういう要素が実装としてあるのかを今日は書く予定。


まずソーシャルゲームというのは「生ものである」という点です。
ゲーム自体生ものなんだけどソーシャル系はリアルタイム要素がでかい。
データは全て可変なので、可変的にデータがやってきたときにアプリは対応できなければいけない。
ここがソシャゲの一番難しい部分で、かつ責任も重い。
例えば課金はAndroidならgoogle play、IOS系ならAppStore（だったっけ）で課金をするわけだけど
この課金処理、当たり前ですが常に成功はしません。
課金処理中に課金情報をサーバーに正常に遅れる保証はどこにもないということです。
google play側でエラーが発生した場合、そのエラー処理はgoogle側が勝手にやってくれるわけだけど、購入後の商品情報はアプリ側で管理しなければいけない。
これをSQLiteなどで管理して、アプリ起動時に在庫確認→在庫があれば課金処理の続きを行う→サーバーに正常に保存される
というこの流れはアプリ作成者がやらなければいけない。
もし商品情報が保存されず、ただ課金したという情報だけがgoogleに登録された日には大変なことになります。訴訟問題です


そして第二にソシャゲはカードなどを扱うゲームが多いですが、カードやクエスト・イベントなどは可変的に増える。
可変的に増えてもいいように作らなければ対応はし切れない。
だからこれはすべてデータテーブルで切られるわけです。
そしてデータテーブルに紐づけて今表示できるサービスだけを表示する。


次にゲーム内の演出
FLASHのような演出をゲームに取り入れる場合があります。
コンシューマ系だとものによってはメーカー側がデザイナー用のレイアウトエディタなんかを用意してくれますが、
携帯アプリだとなかなかそうもいきません。
一応前回の日記に書いたような仕組みがあるので演出は大方対応できましたが、できれば視覚的に作成できるツールに落とし込みたかった。

演出で思い出したのですが、携帯ゲームというのはFPSが安定しない。
演出系に関していえばフレームという考え方は捨てたほうが良いようです。
差分ミリ秒みたいな単位で動かすと辻褄が合うようです。


そしてゲーム内のデータ設計
これが一番重く、最もプログラマーが頑張らなければいけない部分です。
ゲーム内のすべての項目がこのゲームデータに依存するわけですから。
サーバーからのユーザー・マスターテーブルがあること前提で作る人が多いんですが、私はそれが違うと考えます。

アプリとデータベースは分離するべきと考え、すべてのデータベースに窓口を用意しました。
ゲーム内にはゲーム内用のゲームパラメータを作ります。
これはユーザーテーブルとは関係のないゲーム内のデータテーブルです。
そしてユーザーテーブルからSelectしてきて、取得したデータをゲームデータに上書きしていくわけです。
なので常にバックアップデータで動いている感じです。
本物のデータと直接結び付けない、ここが肝です。


私はこのようなゲーム内で管理するデータを「ゲームドキュメント」と呼んでいます。
サーバーからのデータをデータベース(SQLite)に保存→ドキュメントが引っ張ってきて管理→アプリ側が求めるデータはドキュメントから持ってくる

ゲーム内の一時データの保存もこのように行う。

【書き込み時】
ゲーム内の一時保存パラメータをドキュメントに書き込む→ドキュメントは今持っているデータをテーブルに書き込むだけ→対応するテーブルに設定して保存

【呼び出し時】
テーブルを持ってくる→ドキュメントに各要素の書き込み→ゲームはドキュメントの見るべきデータを見てその通りの状態になるだけ


このセーブロジックはゲームの各フェーズ中に一回のみ。
更新タイミングと呼び出しタイミングは決まった時にしかやらないようにする。
これを一つのシーケンス内で複数にセーブポイントを作るとハマりバグが発生します。



ローカルに保存するのは大抵の場合メインゲーム部分を遊んでいるときの途中データなどです。
例えばパズドラとかだとブロックの位置情報とか、現在何バトル目なのか、とかは一時データとしてSQLiteで保存しているはずです。
（開発者じゃないからわからないけど試した感じだとブロック操作が終わった後→ターン消費→敵行動評価→一時データセーブ→自分のターンみたいなローテーションになってるっぽい）



やっぱりゲームを作るうえで大事なのはデータ管理に尽きる気がします。
しかしすべてをひっくるめてもゲームを作るってのは難しいもんですね、クソゲーであってもね

せんちゃ さんが書きました:少しくらい自画自賛してもいいよね？
え、ダメ？そうですか・・・

すばらしいと思います。

できてしまうあたり、今後が怖い気がしますが。。
無茶が出来てしまうと、
「何だ出来るんじゃん」
となってさらに地獄にハマる可能性があります。

主張すべきところはしてくださいね。

最近はかなり口答えするようになりました。
会社の人からはもしかしたら生意気な奴とも思われそうですが、
ある程度強気でいかないとこの仕事はやっていけないんだなと実感しています(笑)

下手に出て何でも引き受けるのではなく
出来ないときは出来ないと言えるのもプロの仕事だという言葉の意味がわかってきた気がします。