インムス

unity 曜日イベント実装

日替わりで変化する曜日イベントの実装

  • インムス ソシャゲと化した先輩のイベント種類
  • 曜日の特定

今回は、短いです。

 

インムス ソシャゲと化した先輩のイベント種類

いつでもできる→ノーマルクエスト

決まった曜日だけできる → 曜日クエスト

決まった期間だけできる→ イベントクエスト

の三種類をメインに実装した。そのうち、 曜日クエストについては

平日を各属性ごとに振り分け、 土日 祝日を特別アイテムはコイン収集と設定した。

今回は、曜日でゲームの内容を切り替える方法について書く。

曜日の特定

unityで曜日を特定する方法は、下記

ほとんどC#に時間関係があるので、簡単。

あとは、 Dayofweekでリターンされた値に対して、Switchで状態変化を実装する。

 

ただし、以前の記事で紹介したとおり androidやiosの端末がわで取得した unix timeは、使用せずに必ず、

serverの時間を使用してください。

 

unity ios課金実装のやり方

unity側の設定はandroidとほぼおなじです。

課金実装手順  ios

  • unity側の設定
  • ストア側の設定 itunes connect
  • テスト用の ベータを作成

unity側の課金設定

unityの設定は、 unityサービスが実装されているので非常にスムーズだ。

ただし、プロジェクト初期状態では、有効化されていないので有効化する

unityのHelp→usnity servicesをクリックする

servicesが表示される  ここから unity IAPをインポートしてつかう実際のサービスのスクリプトは頻繁にアップデートされるので、内容の変更には気をつけたい所。 また、サービスの使用にはunityのアカウントが必要なるので作成しておく。 登録は、無料。

in-app Purchasingを選択を  トグルをONに変更する

inportボタンを押す。

アセットのインポートと同様の画面がでるので、 インポートする。facebook amazon androidなどの課金に対応する部分もあるが今回は使用しない。

 

次に unityに課金ボタンを作成する。

課金ボタンを作成する UIでImage 等作って メニューからコンポーネント Unity IAP→ IAPを選択してimageにコンポーネントを追加する。

追加が完了すると、 imageの インスペクターに下記のように表示される。

IAP カタログをクリックして設定画面を表示

 

itunes connect側で設定した 課金アイテムのパラメータを設定する。

 

 

ストア側の設定 itunes connect

 

itunes connect→ 仮にアップしたアプリ→ 機能→ アプリ内課金

+ボタンをおして、 新しい課金を作成する。

 

テスト用の ベータを作成

xcodeにて in-app Purchasingを有効に設定した アプリをビルドして アーカイブを作成し ビルドをアップロードする

TestFlightを開き、ベータとして公開する。

本番公開前に、一度はTestFlightでベータのチェックをする必要が有る。

 

インムスでは 7種類の クッソ汚い石の価格のほか、セール用の価格設定を予め行っておき、

イベントに合わせてセールを行う方式を作成した。ただし、itunes connectのセール機能を利用していないので

app stor上では、セール中のアプリに入らない。 今後改善したい点。

 

 

 

unity android課金実装のやり方

前回の記事でunityでのガチャ実装について、書いたので

ガチャに使用する石の課金販売について、androidとiosの両方を2回に分けて解説する。

ともに、 android→ googleplay console  ios→itunese conectの登録は、完了しているとする。

 

課金実装手順  android

  • unity側の設定
  • ストア側の設定 googleplay
  • テスト用の ベータを作成

unity側の課金設定

unityの設定は、 unityサービスが実装されているので非常にスムーズだ。

ただし、プロジェクト初期状態では、有効化されていないので有効化する

unityのHelp→usnity servicesをクリックする

servicesが表示される  ここから unity IAPをインポートしてつかう実際のサービスのスクリプトは頻繁にアップデートされるので、内容の変更には気をつけたい所。 また、サービスの使用にはunityのアカウントが必要なるので作成しておく。 登録は、無料。

in-app Purchasingを選択を  トグルをONに変更する

inportボタンを押す。

アセットのインポートと同様の画面がでるので、 インポートする。facebook amazon androidなどの課金に対応する部分もあるが今回は使用しない。

 

次に unityに課金ボタンを作成する。

課金ボタンを作成する UIでImage 等作って メニューからコンポーネント Unity IAP→ IAPを選択してimageにコンポーネントを追加する。

追加が完了すると、 imageの インスペクターに下記のように表示される。

IAP カタログをクリックして設定画面を表示

 

googleplay 側で設定した 課金アイテムのパラメータを設定する。

 

ストア側の設定 googleplay

 

google play console → 仮にアップしたアプリ→ サービスとAPIを開く。

ライセンスとアプリ内課金の部分のキーをunityに設定する。

 

google play console → 仮にアップしたアプリ→アプリ内サービス を開く。

消費可能アイテムの設定を行う。

テスト用の ベータを作成

google play consoleにて

google play consoleにて作成した、課金情報をIAPの登録に設定します。

課金単位をiosと同じにしておくと 管理が楽です。

テスト用にunityでベータ版のAPKをビルドします

 

次回は、iosでの unity課金について書きます。

 

 

 

unity ソシャゲガチャ作り方

unityでガチャを作ろう

ゲーム中に手に入れた、アイテムや課金のアイテムを使ってくじ引きできる仕組みを作りたい。

  • 石やアイテムの管理を作成しよう
  • unityのガチャランダム処理
  • 抽選方式と重み付け
  • ガチャの抽選内容の管理方法

石やアイテムの管理を作成しよう。

ガチャを回すためのアイテムの定義を行います。以前の記事unityでuserを作ろうなどで

課金アイテム のカラムを追加して作成し、同様にガチャチケットも追加します。

注意点としては、石の実装を行う場合、 ゲーム中で手に入った無料の石と、ユーザーが課金を行って手に入れた

石は、別々に管理することです。

インムスでは、その他のページの部分に現在所持している「くっそ汚い石の内訳」として表示しています。

メニュー側では、石の合計を表示し、石の仕様時は、ゲーム中に手に入れた石から使用するようにしました。

サーバー側の使用時の引き落とし方法(phpサンプル)

unityのガチャランダム処理

unityのとは書いたものの、実際の所unity側で抽選処理をしては行けない。不正の温床となるし

なにより、ランダム自体を極力さけるべき。

サーバー側でランダム処理を行い結果を返す

phpでは、配列のキー番号をランダムに返してくれる関数 array_randがあるので使用する。

explodeで アンダーバーで連結した ガチャの内容(0001_0002_0003とする)を渡してあげれば、いずれかのカード情報を取得することができる。あとは、 データベースに取得処理を入れる。

 

 

 

抽選方式と重み付け

上記の方法では、 ガチャの排出確率がどれも一定で当たりとかハズレなどがない状態なので重み付けを行う。

カード毎に排出設定を行うわけではなく、

抽選リストの抽選を行う方式をとる

  • 1等(0001_0002_0003)  10%
  • 2等(0011_0012_0013)    40%
  • ハズレ(0111_0112_0113)50%

 

ガチャの抽選内容の管理方法

以上でガチャの抽選方法の実装ができた。

イベントガチャや、チケットガチャなど 排出内容のバリエーションを増やす際も

sqliteにて抽選候補となる配列と その重みの設定にて作成する。

実際の演出は、是非 インムス ソシャゲと化した先輩をご覧ください。

 

unityで作るソシャゲの構造

大まかに分類した場合のゲームの構造。

基本的には、すべてのシーンは下のいずれかになるように設計する。

加えてこれらのシーン中には、 プレイヤーが操作するかサーバー処理または、バックグランドで処理が完了した場合に次のシーンにつながるように設計する。

  1. 起動画面
  2. ログイン画面
  3. メニュー画面
  4. ゲーム画面
  5. リザルト画面

起動画面

起動時に表示される画面、unityの場合、強制のスプラッシュがあるがそれとは別に

スプラッシュを用意する。ゲームデータ用のクラス読み込み、サーバーとの通信確認、音声の読み込み、

ゲームの起動に必要な処理を行う。 サーバーとの通信確認やサーバー時間の取得など、ゲーム起動後も繰り返し行う場合が多い処理は、スタティッククラスなど

でグローバル化しておく。

サーバー状態の確認では、 そもそも指定されたサーバーに接続できるか?サーバーがわで示す、アプリの最新版であるか?メンテナンス状態か?などを

設定しておくと運用時にアレコレできる。

 

ログイン画面

ログイン画面では、以下の処理を行う。

1、インストール後の初回起動かどうか?初回起動なら、サーバーに生成させた個別のユーザーIDを端末の

PlayerPrefsに登録する。同時に初回起動フラグを設定して、チュートリアルの起動や遊び方の説明を呼び出すきっかけにしておく。

整数でユーザーを管理した場合の端末登録

[c]

int userID = PlayerPrefs.SetInt(“userID”, server_from_userID);

[/c]

端末引っ越し等想定すると、初回起動フラグは端末でなく、サーバー側での管理にする。

2、端末のPlayerPrefsからユーザーIDをつかいサーバーにログインする。

[c]</pre>
int userID = PlayerPrefs.GetInt(“userID”, 0);//デフォルトキー0は取得失敗とみなす。
<pre>[/c]

ログインを行い、ユーザー固有のデータを取得する。インムスでは、プレイヤーデータ。レベル、アイテム個数、ミッションの到達、クエストデーター、

手持ちのキャラクターデータリスト。

手持ちでないキャラクターデータリストをダウンロードする。

こうしておくことで、アプリのバージョンを上げずに、新規にキャラクターを追加したり、クエストの追加を行えるようにする。

 

メニュー画面

メニュー画面では、プレイヤーが次に何をするのか?ゲームするのか、キャラクター育成を行うのか?遊び方をしらべるのか?という、プレイヤー操作とは別に

、サーバーに対してプレゼントがないか?運営側からプレイヤーにお知らせがないか?

HP、MP、ユーザーのステータスの変更をサーバーと動機させる

など、バックグランド処理も行わせる。そのため、トップメニュー、カード合成、カード進化、課金画面、ガチャ画面、ギルド画面をすべて同一シーン上に展開する。こうすることで、処理を途切れさせないでメニュー画面の操作が可能になる。

タイマー式の問い合わせは、フラグの管理が大変なため、各メニューの展開時に問い合わせる方式とした。(ex プレゼントがある場合→ログイン後トップメニューを表示時にチェック→育成画面を表示時にチェック→ギルド表示時にチェック)チェック時に同時にサーバー時間の取得を行う設計とした。

ゲーム画面

ゲーム開始前に、ゲーム内容のデーターを読み込んでおく。敵パラメーターや出現ドロップの内容、

ゲームの内容はおいておくとして、下記の状態遷移を想定する。

ユーザーがゲームに勝利した場合。

ユーザーがゲームに負けた場合、

ユーザーがゲームをリタイアした場合、

端末がアプリを切断した場合(電話がかかってきた、電池が亡くなった場合、ユーザーが他のアプリを使用した場合)

状態遷移では無いが、今回はアイテム石の実装が有るため、ユーザーがアイテムの使用を選択した場合の処理も追加。

 

リザルト画面

ゲーム後の結果処理を行い、再びメニューに戻る画面。メニューに戻る前に、

ドロップアイテムの受取処理(ゲームコイン、取得キャラクターのサーバー受け渡し等)のほか、

ユーザーパラメーターの加算処理を行う。ユーザーパラメータは、例えばパズルゲームなら何連鎖したか?赤の石を何個消したか?今日何回目のゲームか?

ゲームを始めて何回勝利したかなど詳細に収集する。  パズルゲームの途中で逐次サーバーに送っていては、データ処理が膨大になるため、

リザルトにてサーバーと同期させるようにさせる。

表示後、サーバーに実績の解除等を問い合わせる。ミッションの達成フラグ等を取得する。

 

まとめ

どうでしょう?普段あなたがプレイしているゲームも多分こんな感じ。

 

 

unity キャラクター選択の作り方

unity キャラクター選択の作り方 ソシャゲ

パーティ編成を作りたい

手に入れたキャラクターを選択し、戦術戦略をたてるのもゲームの楽しみ方の一つだ。

以前の記事で作成した、キャラクターを用い

デッキを作成。デッキの内容を変更できるようにする。

もちろん、ユーザー情報同様に端末の変更や他プレイヤーからの参照に対応するため、

デッキ情報、キャラクター情報もサーバーと同期するように作成する。

  • デッキの定義
  • 隊列の順番定義
  • デッキ選択画面
  • キャラクター選択画面
  • 同期処理

 

デッキの定義

インムスでは、手持ちのキャラクターを選択し、予め6グループ6体ずつのデッキとよばれる

パーティ編成にてゲームを行う。

デッキは、ゲーム開始前にどれを使用するか選択することができる。

キャラクター属性を定義しているため、属性間の有利不利を作成し、ゲームの戦略性を楽しんでもらうのが狙いだ。

ゲーム時デッキは1つしか使用できない。同じキャラクターを複数のデッキで使用して良いというルールのもと実装した。

 

 

隊列の順番定義

デッキの中でも、隊列をくみ先頭から最後尾までならび変えができるようにした。

ゲーム中の敵攻撃、効果や確率に利用する。

というわけで、今回は個別にデッキのテーブルをは、作らすに

手持ちのキャラクターテーブルのカラムに0番から5番までの6カラムを追加し、

その中に、デッキ入りしていれば隊列番号を入力してデッキの編成となるように構成した。

csvで表現すると下記図のような感じ。

ゲーム開始時の初期カードの登録時はすべてのデッキに0(先頭)を入れて空のデッキを作らないようにした。

デッキ番号が空欄の場合は、デッキに登録されていない状態。もちろん、同一のデッキ番号にたいして同じ値が入る矛盾が発生するが次のデッキ選択画面の実装によって回避される。

 

デッキ選択画面

上記の画像は、デッキ選択画面→ (1/6)をパネルごとスライドしてデッキの選択を行う。

横スクロールのListViewと 手を離した時のフィットによって表現した。

 

キャラクター選択画面

上部が選択できるデッキの空部分。トグル形式で選択後、デッキに採用できるキャラクターまたは、入れ可能なキャラクターを有効化する仕様(選択出来ない場合はグレーアウト)

インムスでは、キャラクターレベルの他にユーザーのレベルを定義し、デッキコストを少しずつ上昇させることで

採用できるカードの枚数や、強さの上限をもたせた。

キャラクターに限らずUIimageで表現するListViewの表示のスクリプトはこんな感じ

まず、リストのパネルを設定したら、基本子要素としてprefab化しておく。その際、子要素消を消さないで

スクリプトのstartにてdestroyを使って消す。→こうしておくと次に変更する際にどのprefabなのか見失わない。

リストビューの子要素のコピーを作成してリストビューに入れる。 高さ揃えて表示は完了。

子要素の中にボタン属性をもたせた場合は、リストビュー内にて onClick.AddListenerでボタン動作を設定する。(ラムダ式の部分)

 

トグルボタンの実装は、スクリプトが長くなったので割愛。

 

同期処理

ログイン時、プレゼントやドロップ獲得後にカードの内容に変化があった場合に

ロード処理を入れる。

処理方法は、loginのuser_idと同様。

その後、デッキの番号順にソートを行い。デッキを作成する

 

 

unityでcsvを使う ネットワーク越しで

シーンの構造ができたら、データの構造を作成する。

今回はcsvでデータ管理することにした。データのサーバー管理が必須なので、スマートフォン本体による、preferencesは使用できない。

unityには、ScriptableObject、json、クラスのシリアライズによるデータ永続化がよく使われる。

上記のデータは、最終的にunity内ではlist<T> dictionary、hash、array  などテーブルデータで使用する。

あえてcsv管理にすることにした。

csvにすることで、3つの利点があったからだ。

  • エクセルのオートコンプリートや式を使って、デモデータの作成をすれば多様なデータでも視覚的に楽に生成できる。
  • データベースの登録にcsvを流し込めば、一瞬にしてデータを更新できる。結果、最初から中間の運用管理ミドルウェアの作成をする必要がない
  •   xml系に比べてヘッダー文字等は無いため、すこ~しだけバイト数が減る。(時もある!)

もちろん欠点もある。

  • カンマとか、区切り等のダメ文字が存在する
  • xml系の管理に比べて、正規化に弱い
  • 暗号化時は更に高負荷がかかる。
  • 拡張性が弱い。
  • 文字コードによるトラブルに見舞われる。特にiosのescapeURLが沼

などなど、開発スピードを考えればcsvでの管理はなかなか有利で運用開始後は手間なことが多い。

今回は、検討した結果それでも 僕はCSVを使いたい!でやってみた。文字コード系はutf-8で統一してね。

 

unityでcsvを読み込む① アプリのリソースから読み込む

「utniy csv」で検索したら、

UnityでCSVからデータ読んでいい感じにクラスにつっこむ

を見つけたため、ダウンロードデータに対応するように変更する。

 

リストクラスも同様に変更を加える。set_csvを作成し ローカルの文字列で保持させる。

 

public class userid_data: MasterBase3内で指定した、カラムを持つcsvを流し込めばデータ構造の完成。

具体的な使い方は、
サーバー側で、カンマ区切りの文字列を返すようにページを作成する
もちろん、csvデータをライン読み込みで1行単位で表示してもいいが、今回はphp+sqlite3で表示してみた。別にカンマ区切りならなんでもよい。ruby+ポスグレでも
javascrit+mysqlでも。

csv表示サンプル
login.php?useri_d=xxxx

 

phpでのサーバー動作は、最初にヘッダー部の作成と改行。その後sqliteにたいして、カンマ区切りで文字列取得後、全て表示するというシンプルな設定。

実際にunityで使うには、下記の用になる。

 

 

login画面時 コルーチン呼び出で

 

すれば、 csvを変換し独自リストクラスにまとめてくれる。

データの呼び出しには、

でアクセスできる。

 

unityでユーザーを作ろう

ログインの処理を作成する。

ログイン画面をつくったので、次は実際のログインの処理を作成する。

  1. 端末にuser_idがなければサーバーで生成する
  2. ログイン成功をunity側に伝える。
  3. user_idをキーに、各データを取得する処理に移行する

 

端末にuser_idがなければサーバーで生成する

アプリインストール後には、user_idの初期登録が必要になる。

unity側で、起動時

 

ログイン成功をunity側に伝える

ここでは、phpでランダムに文字列を生成してサーバーに登録後、アプリの端末にもuser_idを登録する。

こうすると、アプリ起動時から生成したuser_idを使用してログインする事ができる。

phpでランダムな文字列を生成するには下記のような感じ。

生成したID文字列は、サーバーのuser_idテーブルに保存しておく

 

2回目以降のログイン処理

二回目からは、端末のuser_userをキーにしてログインする。

 

何らかの原因で端末から、user_idが消えた場合などは、当然idの再生成を行い以前のデータで遊べなくなるため

端末移行機能を別に実装した。

user_idをキーに、各データを取得する処理に移行する

unity側→  問い合わせUrlに?user_idを追加する

 

phpサーバー側の処理は下記 クエリにuseridがなければ何もしないでリターン

 

動作はインムス ソシャゲと化した先輩でごらんになれます。

unity で2Dゲーム(ソーシャル)を作ろう

スマホゲームを作りたかったので、企画してみた。

  1. スマホゲームを作りたい(android、iphoneで同じタイトルで作成したい)
  2. ソーシャルゲーム作りたい。(何がソーシャルかはココではおいとく)
  3. サーバーを自前で用意したい。
  4. 外部サービス系を極力取り除きたい。

 

 

 

1、スマホゲームを作りたい(android、iphoneで同じタイトルで作成したい)

iphoneならobjective-Cまたは、swift   androidならjavaと別々に作成する必要がある。

もちろん個別に作ったほうが、デバイスのライフサイクルや、個別の機能(例えばSDカードに保存する、アドレスリストにアクセスするなど)の使用ができ

動作もクオリティも上げることができる。

一度に作成できること、個別のバージョン管理を行わなければならないため、ゲームエンジンの利用がおすすめ。

有名どころだと、 cocos2d-xかunity3D で 動作は、未だにcocosのほうが軽いかなと思ったけど

最近の動向だと、圧倒的にunityが優勢になってきているため、unityに決定した。

特に、unity 4あたりからのUI系 2d表示がわかりやすく、解像度とレイアウトの設定が楽だったのと、書籍、ネットなど情報収集が多かった。

 

 

2,ソーシャルゲーム作りたい。(何がソーシャルかはココではおいとく)

何がソーシャルか?笑

他の有人のプレイヤーの存在があり交流が持てるようにしたい。そのため、ゲーム中のデータは、

サーバーで管理する必要がある。いわゆる、ソシャゲーパズルゲームのサーバー代、、、高い。

ゲーム専用サーバー等は、ここ1年位で仮想などでのサービスが登場しているため、下がってきている。移行も視野に入れる。

 

3,サーバーを自前で用意したい。

というわけで、サーバーは自前で用意することにした。現在自宅で公開可能なサーバー4台。linuxサーバーの利用を検討したが、回線が不安なので

(常時接続でどれだけ、エラーが出るか計測したら90%くらいだった)

有料のレンタルサーバーを借りることにする。 最低、phpが動けばいいかな?くらいだったが、rubyも動くようでホクホクになった。

作成期間等考えると、p2p、tomcat nodeJSも使用を控えた。特にJS系は、ハマると沼。

 

4、外部サービス系を極力取り除きたい。

前回制作した、webRTC系のコミュニケーションアプリでは、今回同様、デバイス個別の実装をさけるために、

音声、ビデオチャットのサービスを外部プラグインとしてラッパで実装し、データー関連もすべてその外部サービスの備考を書く部分にjsonで構造化して開発した。

結果、1年後にそのサービスが閉鎖されたためすべてが、終わってしまったので今回は、実装、 運用含め外部のサービスは利用しない。

niftyのノティフィケーションも、便利だけど我慢する。

ついでに、iphpneの64ビット関連のトラブルが予想されるため、cやc++でプラグインを作成するのも今回は控えた。

 

で、できたのがコレ↓w

(゚Д゚)ハァ?

かわいい女の子も、重厚なストーリーもすべて考えるのをやめた。

クリエイターがクリエイトをやめた結果がコレ。

ついでに、侘び石で「クッソ汚い石」を振る舞うゲスぶり。

そんな、ソーシャルパズルゲーム。

[インムス ソシャゲと化した先輩]

 

 

Unityでログイン画面作成

unityでログイン画面を作る

サーバーと通信取って処理が終わったら、取得したデータを処理後に

画面をタッチできるようにする。

unityのスクリプト処理

 

 

に変える

そして、ログイン処理、イベント取得処理、キャラクターデータ取得処理などの、コルーチンを呼び出す。

この時、スタートコルーチンで呼び出さずに

 

としてあげれば、順番を守って処理してくれる。一度に startCoroutineで発行すると、ログイン処理が終わっていないのに、カードデータを取得しようとしたり

キャラクターデータが揃っていないのに、キャラクターパラメーターを生成するような処理が走ってしまうため要注意。

 

unity最後に、タッチできるようにする処理

画面全体にuiでパネルを作成してbuttonを設定する

一度buttonを無効にしておく。

上記のログイン処理が終わったら、ボタンの有効化関数を呼ぶようにunityActionでコールバックを設定する

コルーチンのコールバック部分

コールバック返したいコルーチンの引数に unityActionを設定する(usingも必要)

 

で、呼び出し時にコールバック先を指定する

 

ボタンの有効化関数

 

実際の動作は、下記で見れます