とあるCocos2dx入門編

cocos-2dxアプリのサーバーサイド事始め
～入門編～

初めに
•本講演では、処理の流れをイメージしやすいように図をフンダンに盛り込んでいます。が、説明のため一部簡略化等を行っていますので、そのままこの実装になっているというわけではありません。
•大体のイメージを掴んでいただくことを目的としているので、一部違います
•本講演で説明する通信の仕方はあくまで発表者の経験した範囲内での事です。そうでない通信の仕方もあると思います。

本講演の対象者
•これからソーシャルネイティブアプリを作ろうとしている方
•クライアント(アプリ側）を担当しているが、サーバー側のプログラマーがどういう事をしているか気になる方
•サーバー側のプログラマーに成りたての方

作ろうとしているアプリについて
•いわゆるパズドラ系アプリでの通信の話
•セーブデータは基本は全てサーバー上にある
•プレイに通信環境があることが必須
•ただし、最近流行のリアルタイム通信は一切なし
•Web View も無いものとして扱います

本日のアジェンダ
•サーバーサイドのお仕事をザックリ紹介
•通信の内容をザックリ分類して紹介
•サーバーの種類をザックリ紹介

サーバーサイドのお仕事超ざっくり紹介

１．クライアント（アプリ）から来たデータを受け取る
データ

２．受け取ったデータを元にデータ書き換え等の処理を行う
サーバー内で処理

３．処理した結果をクライアントにデータとして返す
処理結果

cocos-2dxでも、Ｕｎｉｔｙでも、ネイティブでも、やることは一緒！
クライアントから上がってくるデータはcocos-2dxでも、
Ｕｎｉｔｙでも一緒。
どんなデータをやり取りするのかを設計するのが
エンジニアのお仕事！
※大体サーバーサイドの人が設計することが多い

大切なのは、どんなデータを、どうやり取りするか！

どういうデータをやりとりしているの？
•ざっくりと分類
•ユーザーアカウント発行
•ユーザーデータの取得系
•設定データや取得系
•リソースデータ（画像/音等)取得系
•ユーザー行動の送信系
•他ユーザーのデータ取得系
•課金系通信

データ実例紹介
•課金系通信

ユーザーアカウントの発行
•ユーザーデータをサーバー上に作るための通信
•大体のアプリが最初の名前入力時に行っている

ユーザーアカウント発行のイメージ
クライアント
サーバー
１．サーバーに名前を送って、登録要請の通信
｛”name”:”まゆ”｝

クライアント
サーバー
2．受け取ったデータを
元にユーザーを生成し、
ＩＤとパスワードを発行
(※IDにはUUIDなどを使用すると良いでしょう。パスワードはランダム文字列）

クライアント
サーバー
３．発行したＩＤとパスワードをクライアントに返す
｛”id”:” a7c4eab”,”passwd”:”te32BG”｝

クライアント
サーバー
４．受け取ったＩＤとパスワードをセーブデータに保存する

ユーザーデータ取得系
•ログイン時等にユーザーの情報を得るための通信
•ユーザーの名前/ランク等の基本情報
•ユーザーの所持しているカード一覧
•ユーザーのプレゼントＢＯＸ

ユーザーデータ取得のイメージ
クライアント
サーバー
１．サーバーに、ＩＤとパスワードを送って、ユーザーデータを要求
｛”id”:” a7c4eab”,”passwd”:”te32BG”｝ ※パスワードを、直で送ったりはしないのですが、ここでは話を簡略化するために、このような形にさせていただきます。

クライアント
サーバー
2．受け取ったデータを元にユーザー認証を行い、正しければサーバー内のユーザーデータを引っ張ってくる

クライアント
サーバー
３．サーバー内にあるユーザーに関するデータを返す
｛”name”:”まゆ”,”rank”:4,
”stone”:10,”gold”:100｝

クライアント
サーバー
４．受け取ったデータを変数に保存しておき、必要に応じて表示。
｛”name”:”まゆ”,”rank”:4,
”stone”:10,”gold”:100｝

設定データ取得系
•ゲームの設定データをサーバーからとってくるようにしないと、日々の運営が出来ないので、ゲームに関する設定をサーバーから通信で取得する
•お知らせデータ
•カード自体の強さ設定データ
•ダンジョンの設定データ

設定データのイメージ
ID
名前
レア度
ＨＰ
攻撃力
防御力
1
漆黒の騎士
Ｒ
100
50
10
2
青眼の白竜
ＵＲ
250
90
20
3
暗黒魔術師
ＳＲ
150
80
10
4
孤高の狼
Ｎ
80
40
5
5
赤眼の黒竜
ＳＲ
200
30
25
ＩＤを指定すると、特定のキャラクターに関するデータを一括で取得できるようになっている

リソースデータ（画像/音等)取得系
•50ＭＢ以上のアプリは、３Ｇ／ＬＴＥ回線ではダウンロード出来ないため、カードデータなど一部のデータを起動後ダウンロードしている
•カードの画像データ
•カードのボイスデータ（あれば）
•その他、50ＭＢに入りきらなかったデータ

設定データ・リソース取得のイメージ
クライアント
サーバー
１．URLで欲しい設定データやリソースデータを指定して、サーバーにデータを要求

クライアント
サーバー
２．サーバー内にあるデータを返す
※サーバーに置いたファイルをそのまま返すだけなので、特に何もしなくてよいはず
設定・リソースデータ

クライアント
サーバー
３．受け取ったデータをキャッシュとして保存しておく
設定・リソースデータ

設定データ・リソースデータでの注意
•設定やリソースデータなど、再ダウンロードが可能なデータをクライアント側で保存するときは、キャッシュ用の領域に保存しなければならない。
•ダウンロードしてきたデータをセーブデータとして保存するとiTunes/iCloudのバックアップ対象となり非常に無駄（再ダウンロードすれば良いという考えから）。最悪のケースとして、Apple申請にてリジェクト対象になる

設定データ・リソースデータでの注意
※CCFileUtils::WritablePathではセーブデータ用のパスが返って来てしまう。
発表者のタイトルでは、CCFileUtilsにCachePathという関数を別途自作で追加することで対応した

ユーザー行動の送信系
•ユーザーのデータを書き換える必要がある操作を、アプリ上で行われたときに行われる通信
•ダンジョンに入った（スタミナを減らす）
•コンティニューした（魔法石を減らす）
•ダンジョンをクリアした（クリアした報酬を受け取る）
•ガチャを引いた(魔法石を減らしてカードを得る）
•キャラを合成した（お金とカードを減らして、カードを強くする）
•スタミナ回復した（魔法石を減らして、スタミナを増やす）
•フレンド申請した
•フレンド承認した

クライアント
サーバー
１．サーバーに、ＩＤとパスワード、遊んだダンジョン、取得したスコアを送信
｛”id”:” a7c4eab”,”passwd”:”te32BG”,”
dungeon”:2,”score”:100｝
ユーザー行動の送信系イメージ(ゲームクリア想定)

クライアント
サーバー
2．受け取ったデータを元にユーザー認証を行い、正しければサーバー内のユーザーデータを書き換える
｛”id”:” a7c4eab”,”passwd”:”te32BG”,”
dungeon”:2,”score”:100｝

クライアント
サーバー
３．サーバー内で書き換えたデータ等を返します
｛”money”:20,”getCard”:[1,2,3]}

クライアント
サーバー
｛”money”:20,”getCard”:[1,2,3]}

他ユーザーのデータ取得系
•ソーシャルゲームなので、他ユーザーのデータを取得しないとソーシャルにならない…。
•ダンジョンに入る直前の相棒選択の情報取得
•ユーザーのフレンド一覧、申請した人・された人一覧取得
•フレンド検索通信

他ユーザーデータ取得のイメージ
クライアント
サーバー
１．サーバーに、ＩＤとパスワードを送って、ユーザーデータを要求

クライアント
サーバー
2．受け取ったデータを元にユーザー認証を行い、正しければサーバー内の他ユーザー（フレンド等）の情報を探してくる

クライアント
サーバー
３．サーバー内にある他ユーザーに関するデータを返す
[｛”name”:”まき”,”rank”:4}, ｛”name”:”ことり”,”rank”:10}]

クライアント
サーバー

課金系
•実際のお金を使った結果を通信するところ、ＡｎｄｒｏｉｄとiPhoneで実装そのものが異なるので注意
•魔法石の購入
※サーバーサイドの話をすると、課金とプッシュ通知以外は、ＯＳ関係なく実装できます。（ここではプッシュ通知の説明はしません。）

課金系通信(iphone)のイメージ
クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
１．商品購入する旨を伝える。
※開発者はiOSのAPIを呼び出すだけ。

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
２．購入を証明するレシートが
Ａｐｐｌｅから返ってきます
※開発者はコールバックでデータを受け取るだけ
レシート

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
3.課金時のレシート、ユーザーＩＤ、パスワードを送って課金したことを伝える
｛”id”:” a7c4eab”,”passwd”:”te32BG”,
“receipt”:レシートのデータ｝

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
｛”id”:” a7c4eab”,”passwd”:”te32BG”,
“receipt”:レシートのデータ｝
４.ユーザーの認証処理を行う

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
5.課金時のレシートをApple サーバーに渡して、何をいつ購入したかなどの情報を貰いにいく
レシート

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
６.レシートに関する詳細データを返す。不正なレシートだった場合はエラーを返す
{“status”:0,
”product”:”stone01”}

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
７.受け取った商品を元にサーバー内にあるユーザーデータを書き換える
{“status”:0,
”product”:”stone01”}

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
８.書き換えた情報をクライアントに返します
{“stone”:20}

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
８.受け取ったデータを変数に保存しておき、必要に応じて表示。
{“stone”:20}

クライアント
ゲーム
サーバー
Ａｐｐｌｅ
サーバー
１０.課金処理が全て終わったことを伝える
※開発者は、iOSのＡＰＩでトランザクションの終了処理をするだけ

ということで、通信の一覧をもう一度
•課金系通信

どうやってデータを受け渡しているの？
•ＨＴＴＰ上データをやりとり
•Ｊｓｏｎ形式のデータをやり取り
•※リソースデータ（画像・音声等）を除く

ＨＴＴＰ上でデータをやり取り？
•各クライアントフレームワークでの利用するクラス
•Cocos-2dx
•CCHttpClientクラス(ver3 では,HttpClientクラス)
•Unity
•WWW クラス
•iOS Native
•NSURLRequestクラス

Ｊｓｏｎ形式
•各クライアントで利用するもの
•Cocos-2dx
•spine/Json.h
•Unity
•MiniJson等

これで、ネイティブソーシャルゲームのサーバーは大体理解した！！

ちょっと待ったーー！！

サーバーは1台だけじゃない！！
•実際のサービスの裏側では、複数のサーバーが運用されています
•サーバー間でも通信しています
※テスト環境では、1台のマシンが複数台の役割を果たすことも多々あります

サーバーのザックリ分類
•フロントサーバー
•クライントから来たデータを実際に受け取って処理をするサーバー
•ＤＢサーバー
•ユーザーや、ゲームに使用する設定データを読み書きするためのサーバー

フロントサーバー
•開発者の書いたプログラムをミドルウェア上で動作させる
•ミドルウェアの例
•Apache + PHP
•Tomcat
•nginx+ node.js

ＤＢサーバー
•複雑な処理はミドルウェアにお任せ
•単に読み書きだけでなく、条件に合うデータを検索せせる等が出来ます
•ミドルウェア例
•MySQL
•PostgreSQL
•Oracle
•DB2
•MongoDB

流れで見て、それぞれの役割をイメージしましょう

サーバーイメージ（登録時）
クライアント
ＤＢサーバー
１．サーバーに名前を送って、登録要請の通信

クライアント
ＤＢサーバー
２．受け取ったデータから名前の文字抜き出す。ＩＤ用にＵＵＩＤの発行。パスワードのランダム文字列生成などを行う

クライアント
ＤＢサーバー
３．書き込むべきデータをＤＢに通達
ＩＤ「a7c4eab」： passwd「te32BG」
で「まゆ」という名前のユーザーを保存

クライアント
ＤＢサーバー
４．書き込みに成功したかを返す

クライアント
ＤＢサーバー
５．書き込んだＩＤとパスワードを返す

別のケースも見てみましょう

サーバーイメージ（フレンド一覧取得時）
クライアント
ＤＢサーバー
１．サーバーにID とパスワードを送ってデータ要求
｛”id”:” a7c4eab”, ”passwd”:”te32BG”｝

クライアント
ＤＢサーバー
２．ＤＢサーバーへデータがあるか検索してもらいます
ＩＤ「a7c4eab」： passwd「te32BG」
というユーザーが居るか問い合わせ

クライアント
ＤＢサーバー
３．ユーザーが存在していることを返します

クライアント
ＤＢサーバー
４．ＤＢサーバーへ対象のデータを検索してもらいます
ＩＤ「a7c4eab」のフレンド一覧を問い合わせ

クライアント
ＤＢサーバー
５．ユーザーのフレンド一覧を返します

クライアント
ＤＢサーバー
６．ユーザーのフレンド一覧を返します

サーバー側の中でもサーバー間の通信を行っています

まとめ
•ネイティブアプリの通信は、色々な種類がある
•大事なのは、どういうデータをやり取りするのかということ
•実際のサービスでは、サーバーは一台だけでなく、複数のフロントサーバー／ＤＢサーバーが動いている

とあるCocos2dx入門編

More Related Content

Similar to とあるCocos2dx入門編

Recently uploaded

とあるCocos2dx入門編