unityの時間管理をサーバーでやりたい。

  1. ソシャゲとログイン時間のコントロール
  2. タイムスタンプの表示
  3. タイムゾーンを無理やり合わせる。
  4. タイムゾーンが異なる場所での時間管理。

ソシャゲとログイン時間のコントロール

例えば、時間を本体に保存した場合どうなるか?

30分に一回ゲームできるアプリだったとして、まず間違いなく不正が起きる。

(端末の時間変更で30分すすめると連続してゲームが可能など)

ましては、イベントタイマーなど設定していた場合はコントロールできない。

なので、基本はサーバーの時間を正として設定する。

 

 

Unixタイムスタンプ時間の表示

user_idのテーブルにログイン時間を記録し各問い合わせ操作時に最終操作時間として記述する。

もちろん時間については、サーバーの時間。

 

注意事項として、タイムスタンプはサーバーのタイムスタンプなので各サーバーによって厳密には、時間が正しくない場合、時差が含まれていない場合がある。

 

unity側では、タイムスタンプ文字列を変換してデートタイムにする

 

タイムゾーンを無理やり合わせる。

国内のレンタルサーバーを借りている場合は 32400秒たしておけば、時差を丸めることができる。

この辺タイムゾーンの設定とかあるけどこっちのほうがわかりやすい。

androidのタイムゾーンを信じてはいけない。

 

タイムゾーンが異なる場所での時間管理。

実際サービスを開始したとして 日曜日の0時丁度に新しくイベントを始めたい場合上記の時間設定では、まずい。

すべての地域のユーザーが東京の日曜日0時にイベントを開始できることになるためだ。

ただし、ソーシャルゲームという方向から見たら平等かもしれない。何時であれ相対的には同時にサービスを開始することができるから。

反面、負荷の分散という方向から見れば、個別にタイムゾーンを用意しておいて順次、該当地域のユーザーに対して新しいイベントを渡すほうがよい。ポケモンGoなどはこっちの方式だった。

Unity ソシャゲ ミッション作り方

Unity ソシャゲ ミッション作り方

ゲーム中に収集した累積にもとづき実績に応じて、アイテムをプレゼントする仕組みを実装した。

累積データの収集

  • agregateクラス作成    累積データをためておく場所。
  • agregateのクラスの永続化とサーバー同期    シリアライズしたデータのクエリ文字への変換。
  • サーバーデータの読み込み agregateクラスの再生成

上記3ステップを繰り返す。

累積データの収集タイミングは、メニュー画面中では随時、パズルゲーム時は、内部の変数に加算後リザルト画面でのサーバー同期処理とした。

日付の保持を行い、ログイン時に日付が更新されていれば、デイリーミッションの agregateを初期化

これで、 ゲーム中全体のミッションと デイリーミッションの実装を行った。

日付の管理方法は、以前の記事   unityで曜日の取得時に  曜日の文字列を保持し、当日と異なれば日付変更とした。

 

実際のミッション実装サンプル

まず、 ログイン時に agregateクラスを生成

agregate クラスはこんな感じ。長いので簡略化

 

そして、各累積データの更新がある場合は、下記のように 一つの項目で デイリーミッションと 全体ミッションに対して更新を行う

 

最後に 適切なタイミングでサーバーに送る送る処理を行う。受取サーバーでは、データのパースを再度行う

 

phpで$s 変数にクエリのパラメータを連結して update

 

日付の変更が起きた場合の デイリーのみの初期化 unity

 

大変長くなったが、ここまでで半分。次は、ミッション自体を設定する。

累積データの値が決めた値を超えたら、ミッションの達成をお知らせする。

ミッションで得られる アイテムや得点を配布する処理を作成する

 

ミッションリストのCSVの定義は下記で行う。 使い方はログイン時と同様

mission_day_dataの変数と同名のテーブルを sqliteに作成して使用する

 

ミッションクリアの評価関数。簡略化してます

 

 

この他、 ミッションリストの表示とミッション達成フラグの送受信が必要になる。上記コード sumi_fragが該当。

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

 

unity ソーシャル メンテ表示をしたい

スマホゲーのメンテ表示ってどうなってんの?

そもそもサーバーメンテは大きく2種類ある。

(予定されたメンテナンス)定時バックグランド処理のためのメンテナンス時間

一ヶ月のランキングを処理したり、一週間で溜まった、ゴミデータを削除したりするため、一旦すべてのユーザーをログアウトさせるメンテ。

(突発てきなメンテナンス)トラブル対応、などでサービスが行えない場合のメンテナンス

追加コンテンツなどでバグが見つかった場合や、そもそもサーバーがぶっ壊れた場合など中の人が大慌ての場合。世の中完璧なシステムは存在しないんですわ。

インムス ソシャゲと化した先輩にも両方対応のメンテ表示を追加した。

 

  1. そもそもサーバーに繋がらなかったらメンテ!
  2. プラットフォームごとでメンテ iphone  androidで個別にメンテ時間を設定する。
  3. 予定されたメンテなら終了予定時間を表示する。
  4. unityでメンテ用ダイアログを表示する。

 

そもそもサーバーに繋がらなかったらメンテ!

かなり乱暴な表示だけど、端末からサーバーに繋がらなかったらメンテナンス中とみなす。

もちろん端末がわのWifiが不調とかもあるのでそこは、下記のようにunityでチェックをいれる。

上記でネットが正しくつながる事ができるのにゲームサーバーにつながらない場合にメンテ中とする。

別にドメインなどを用意して、お知らせ用に飛ばす手もあるがそちらを手動で変更する余裕もないのが実情だ。

 

 

 

プラットフォームごとでメンテ iphone  androidで個別にメンテ時間を設定する。

プラットフォーム種類ごとでメンテが必要だったり、そうでなかったりする場合もある。

例えば、バージョンアップしたけど、iphoneは審査が有るためそれまでサービスを止めておきたい場合などだ。

unityで個別にプラットフォームの判別を行う場合は下記の様になる。

注意点は エディターも判定内容に入れるか入れないかを確認すること。

あとは、phpサーバー状態を返すページを作って内容に応じて、メンテナンスダイアログを生成する。

予定されたメンテなら終了予定時間を表示する。

今回は、現在のメンテ情報のほか、予定されたメンテも予告したいため

sqliteにメンテテーブルを作成し

  • メンテ開始時間 、
  • メンテ終了予定時間、
  • androidフラグ 、
  • iosフラグ、
  • メンテの理由のカラム

を作成し、

終了予定時間がなければ、無期限とし、現在のサーバーとの比較を行い現在の状態。 メンテ予定のリストの作成を行った。

 

 

 

 

unityでメンテ用ダイアログを表示する。

一旦 UIパネルで メンテナンス中を示すダイアログを表示し、メンテに関する情報、時間や理由を表示するためのスクリプトを指定する。

prefab化する。

メンテナンスの判定に引っかかった場合は、プレファブからメンテダイアログを作成して表示→

メンテ時間等を記述しておしらせする。

ダイアログは、全面UIPanelをグレーにして、その上にイメージで枠を作る

 

 

インムスでは、予定外のメンテではクッソ汚い石を侘び石してます。

 

unity 規約 ダイアログ作り方

いわゆる。同意してくださいダイアログ。

課金機能の実装を考えた場合、商取用のダイアログを表示する。

いわゆる。同意してくださいダイアログ。

unityがわのダイアログの設定は、前回の unityでメンテナンスダイアログ表示の使い回しでOK

表示文章をスライダーで全面表示できるように変更する。

 

規約文章を記入したtxtファイルをサーバーにアップロードする

unityがわからファイルの内容を取得するには下記を使用する

txtファイルの文章は、utf-8の文字コードを使用すること。windowsなら、サクラエディタ、terapad等使用すると楽。

 

unityでサーバーのテキストファイルから文字列を取得する。

 

unityでキャラクターデータを作ろう

unityでソシャゲ用キャラクターデータを作ろう。

キャラクターデータのクラスを作成して、unity側で表示します。

キャラのデフォルトパラメーターリストと、実際のユーザーが所持しているキャラクターのリストをわけて実装していきます。

こうしておくとデフォルトパラメーターリストを使用して、敵のデッキ情報からのキャラクター生成や、他のユーザーが所持するデータから

最小限の情報でデッキの作成が出来ます。

  • キャラクターのパラメーターを決めよう
  • キャラクターのパラメーターをcsvにしよう
  • キャラクターのパラメーター読み込みを作成しよう
  • 手持ちキャラクターの生成をデータベースに入れる
  • 手持ちキャラクターをunityでリスト化する

 

キャラクターのパラメーターを決めよう

どんなゲームにするか、ゲーム部分の実装をある程度勧めておく。

インムスでは、

  • 攻撃力
  • 体力
  • 回復力
  • スキル内容
  • スキル解除パズル数
  • 属性
  • 名前
  • 管理連番

などを設定。(細かくは、レアリティ、ステータス上昇率タイプ、ステースの上限値、紹介文など多くを設定。)

管理連番は、sqlite側でrowidを使用すると後日連番はずれた場合にわけがわからなくなるので、必ず手動で設定する。

管理連番.pngなどで、サンプルの画像を作成する。 インムスでは   ゲーム中の立ち絵を 管理連番_t.png   デッキ内容表示時の小アイコンを 管理連番_s.pngとして

管理することにした。

 

キャラクターのパラメーターをcsvにしよう

これらのパラメーターを記入したcsvを作成して、sqliteに流し込む。

 

キャラクターのパラメーター読み込みを作成しよう

基本的には、ログインの処理と同様。 csvを読み込み、パラメーターの設定を行い、

サーバー側には、パラメーターをカラムとしたカンマ区切りを表示させる。

 

unityからは、ログイン画面でログイン終了後に

データーの呼び出しを行う。

ここまでで、kyara_mapperクラスのインスタンス kyradataにアプリ内で出現するキャラクターのパラメーターリストが作成できる。

アクセスする場合は、kyradata.all[i].atkなどとしてしゅとくする。配列iの部分で繰り返し処理が行える。

なお、キャラクター連番で検索できるように

find_kyara_data関数を作成しておく

これで、カードの連番が分かれば、デフォルトのパラメーター単位で情報を取得することができる

 

次は、いよいよ手持ちのキャラクターを生成していきます。

手持ちキャラクターデータをデータベースに入れる。

キャラデータの時同様、手持ちキャラにも固有のパラメータを定義する。

ここでは、キャラ名は必要なくて、キャラクター連番のみ設定し、内容は先程作成したキャラデータから検索する仕組みとする。

なお、レベルや経験値を設定し、キャラクターデータと掛け合わせて、現在のパラメーターを作成している。

あと、持ち主であるユーザーのIDと

その他、取得時間

採用デッキ番号

デッキ隊列の順番もココで定義している。

同様にキャラデータを作成後、

サーバーからのダウンロード処理をおこなう。

インムスでは、メニュー画面にて、採用しているデッキの先頭キャラクターを表示しているため、

手持ちキャラクターの生成後、デッキの生成を行っている。

 

 

手持ちキャラクターをunityでリスト化する

ゲームの楽しみ方の一つに、キャラのコンプリートがあるので、キャラクターリストを作成。

user_idテーブルに取得済みの連番を保存するカラムを作成して、unityで該当があればキャラ表示、なければ影絵で表示するようにした。

メニュー画面→その他→図鑑で表示

 

 

unity ソーシャルアプリプレゼント配布

unity ソーシャルアプリプレゼント配布作り方

アプリをやってて、嬉しいのがプレゼント配布。

初回にくっそ汚い石を配らないと不評のインムスのプレゼント実装について書きます。

プレゼントの実装ステップ

  • プレゼントの種類
  • プレゼントの受取方法
  • プレゼントの定義
  • プレゼントをデータベースに登録しよう。
  • unityで受取を実装しよう。
  • プレゼント対象者の拡大
  • メンテナンスについて

プレゼントの種類や獲得方法の種類の定義

インムスでは、取得できるプレゼントの種類を7種類と固定で決めて実装した。

キャラクターカード、石、イベント用アイテム、いいぞコレボタンのアイテム、ガチャチケット数種等。

他に運営側の見方としては、実績を達成した個人に送るのか?全部のプレイヤーに送るのか?など各種の運用方法としてのプレゼント実装が求められた。

 

プレゼントの受取方法

インムスでは、ドロップアイテムで取得したカードやアイテムは、受取処理をユーザーがしなくてもユーザーのボックスに入る処理と

石の受取などユーザーが受取決定をした場合にボックスに入る処理の2つを設定した。

こんな二つの違いでも、ユーザーにとってのゲーム体験に大きく影響するって、田舎のばっちゃが言ってた。

 

プレゼントの定義

プレゼントの定義についてのツールはlogin、カード定義と同じくCSVで作成しsqlite登録後

unity側へもmy_plesent_data_mapper 名で構築した。

カラムの内容として、

  • プレゼント通し番号
  • プレゼント対象者 user_id
  • プレゼント_種類番号(0~6番)
  • プレゼントカード番号(カードのときのみ使用)
  • プレゼントPCS(プレゼントする個数)
  • プレゼント単位文字列(プレゼントメッセージ時の単位  枚とか個とか匹とか)
  • プレゼントタイトル文字列
  • プレゼントメッセージ文字列
  • プレゼント開始時間
  • プレゼント終了時間
  • プレゼント受け取りフラグ

プレゼントの受取フラグは、

受取前=0 受け取り後=1とかでもOK

これでプレゼントの定義とする。

プレゼントをデータベースに登録しよう。

プレゼントの定義部分を参考にsqliteに登録する。テスト用としては、テスト端末のuser_idを登録してテストする。

受取フラグは、受取前の状態に設定する。

 

unityでプレゼント有無を受信する。

ログイン時とメニュー画面でフラグ取得のコルーチンを回す。

コルーチンはサーバーから端末のuser_idのプレゼント一覧を取得し、サーバー時間と比較し、時間内のものを設定する

一つでも、受取フラグが受取前であれば上部のプレゼントうけとりボタンにチェックマークを表示し受取ボタンを有効化する

 

unityで受取を実装しよう。

プレゼント受け取り画面にて、ユーザーが受取ボタンを押すと、

プレゼント受け取りコルーチンを回す。

 

 

受取処理をサーバーに行わせ、プレゼントの内容をuserのアイテムに反映する。

同時に対象のプレゼント受け取りフラグを受け取り済みに変更する。

unity側でアイテムを更新してあげれば受取完了

なお、トップのメニューを開くたびにサーバーへ上記の処理を繰り返し行わせて

プレゼントの有無をチェックするために

プレゼント一覧のリスト、my_plesent_data_mapperの変数を毎回clearしてから使用する

 

プレゼント対象者の拡大

例えば、詫び石などでゲームのプレイヤー全てに同一のアイテムを配布する場合

上記のuser_id分のプレゼントレコードを登録すると、サーバーへの負荷が馬鹿にならない。

ユーザー1万人を超えるあたりから、一旦メンテ状態にしてからでないと対応できなかった。

そのため次を追加した。

user_idのテーブルにプレゼント受取済み連番カラムを作成。

プレゼントのテーブルの対象者に user_idでなく、allと記入し

一覧取得時 allも含めて取得→allのプレゼント連番が 受取済み連番でなければ、プレゼント一覧に追加

プレゼント受け取り時、対象がallの場合は、受取フラグではなく、user_idのテーブルにプレゼント受け取り連番を追加する。

これで、実際のプレゼントのレコードは1行で行うことができる。

 

メンテナンスについて

前回メンテの実装の記事を書いたが、実際のとこと今回のように受取済みや、期間を過ぎたプレゼントなどの

消去が具体的なメンテの内容だったりする。

 

 

 

unity ソーシャル アセットバンドル バージョンコントロールやり方

追加コンテンツを効率良く作るために、unityアセットを使用した。

アセットバンドルとは

AssetBundle システムは、Unity がインデックスできるアーカイバル形式にひとつ、または複数のファイルを保存できるようにするシステムです。このシステムの目的は、Unity のシリアライズの仕組みと互換性のあるデータ送信方式を提供することです。AssetBundle は、インストール後に非コードのコンテンツを配信および更新するために使われる、Unity の主要ツールです。これによって、アセットのサイズを縮小したり、ランタイムのメモリー負荷を最小化したり、エンドユーザーのデバイス向けに最適化されたコンテンツを選択的に読み込ませることが可能になります。

unityで圧縮したファイルとか画像とかシーンとかを保存して利用できる。

保存したデータは、アプリ内でも、サーバーに設置してダウンロードしてしようしてもよい。キャッシュとネットワークのコントロール(オープン・クローズ)もほぼ適切におこなってくれるため、メモリー操作が格段に楽になる。

アセットバンドルを使用するメリットとしては、

  • アプリインストール後にデータの追加ができる。
  • unityに最適化された圧縮解凍方法なので負荷が下がる
  • バージョンの管理、キャッシュの管理もついてる

もちろんデメリットもあって

  • デフォルトでスマホだとキャシュが半年程度で消える
  • データを作成するためにunityで作成するか、またはunityscriptを使用しなければならない。しかも、プラットフォーム毎に作成する必要がある。
  • 非コードようなので、あとでコードを足すことは基本的に出来ない(例外あり)

 

インムスでは、追加アセットとして、追加キャラクター画像と音声。追加イベント時のアイテム、追加イベント時の収集アイテムの画像のみを使用した。

シーン単位での追加コンテンツ作成は、毎回実装時間や手順が膨大になるためパラメーターはサーバーからダウンロードで取得し、その指定する画像データ、音声データは追加で取得できるよう設計した。

よくあるパターンでインストール初回にログイン時にデータをダウンロードし、

次回からは、追加コンテンツの有無に合わせてダウンロードする。

これらの仕組みを、ソーシャルでやる前提として、アセットの管理が別に必要になる。

なぜなら、自分が持っていない画像データーであっても、他のプレイヤーが持っている場合などが発生しないように常に、最新版のアセットバンドルデータと、そのコンテンツを指定するサーバーのデーターが必要になるためだ。今回はそのあたりを含めて制作した。

 

unityアセットを使った追加コンテンツ作り方

まずは、ちょっと前の記事で紹介した、「unityでキャラクターデータを作ろう」で作成した、

キャラの画像データをアセットバンドル化してみる。

フォルダ単位でも、ファイル単位でも指定できるが ここでは初期データ作成として、フォルダーをアセット化する。

下記のファイルをフォルダーAssets→Editor内に作成する。これで、メニューのAssetsの下部にBuild AssetBundlesが作成される。

 

圧縮されたファイルの置き場を作成する。

Assets→AssetBundlesフォルダを作成する。

 

圧縮するファイルを指定する

通常、ローカルの画像は、Assets→Resourcesに入れているはずなので Resource内にcimgフォルダを作成して

必要な画像データを移動する。

フォルダを選択後 unityのエディター右下のasset Labelsをクリック

Noneをクリックしてメニューを表示後 Newをクリック。

ここでアセット名を決定する。

別にcimgeにまとめなくてもここで設定したアセットバンドル名を別のフォルダでもファイルでも指定すれば同じパッケージにまとめてくれる。 (だけど、何入れたか忘れるのでまとめた方が無難です。)

アセット名を指定したら、メニューに先程追加した Build AssetBundlesをクリックすれば、後はしばらく待って於けば、出力先にアセットバンドルが出来上がる。

インムスは、android、iosで同じソースで制作しているのでプラットフォームを切り替えて再度Build AssetBundlesをする。

以上でAssets→AssetBundles内に iosフォルダ androidフォルダに同名の アセットが作成される。

なお、エディターで使用する場合も現在のプラットフォームに合わせたファイルが必要になるので注意。

アセットバンドルファイルをios androidともにサーバーにアップロードします。

 

unity アセットを使ってみよう。

アセットバンドルの使用には、リソースに入れたファイルと異なり、

一度、ロードする必要があります。

unityの アセットストアに アセットのバージョン管理、ダウンロード、ロードもやってくれる便利なアセットがあるので入れて使用。

https://www.assetstore.unity3d.com/jp/#!/content/45836

 

これで、アプリ側の管理化に画像アセットが追加される。

ここでは、作成したアセット名を  testassets     中にいれた画像ファイルを  カード連番_t.pngとする。

キャラクターデータベースに assetnameカラムを作り、testassetsと記入する

アセットの呼び出し方法は、単純でスプライトを作成して、UIimageに渡して上げれば良い。

表示したいキャラクターのUIimageをつくりchara_tとし同名でfind後

とすれば、以降は一行でキャラクターの画像を表示できる。

unityアセットでバージョン管理

実際には、初期アセット以外にも追加でアセットを作って行くことになるので、

sqliteに作成したアセットのリストを作る→unityがわでassetListとしてリストで保持して、

先程のデータの読み込みを下記のように変更した。(単に繰り返し処理を行い見つけたらブレーク。)

 

 

 

Unity ヌルヌル動くタイマー

今日から、Unity2017に更新した

Unity ヌルヌル動くタイマー作り方

新機能など、やっていく前に動作見るついでに、シンプルにヌルヌル動くタイマーを作ってみた。

こんなの↓

 

中央文字表示と、周りの枠でタイマーできるよ。

作り方は簡単。 タイマーバック画像、 タイマーオーバーレイ画像、 文字表示バックの画像を用意

文字表示の中にUI text置いて操作する。

 

タイマーオーバーレイは、画像設定時に Image Typeをfilledに設定 fillamountが表示される

fillamount スライダーで0~1の間の値でマスク。 コレを スクリプト側で操作して タイマーの表示を行う。

更新は、 updateでも コルーチンでも可 今回はupdateで描画更新

コードはこんな感じ

 

 

サンプル は、githubに置いとく。

https://github.com/jposaka/unity-timer/commit/7ebe084bf9a28375b4897fd14eb3ea10fb020db5

unity 端末引き継ぎの実装

以前の記事にてログイン画面のログイン手順の記事を書いたが、

今回は、ユーザーがスマホを買い替えたとかで引き継ぎが必要になった場合の

引き継ぎ実装をやりたい。 意外と簡単なので参考にしてね。

 

前提の条件

よくあるパターンとして、 IDとパスワード   または、メールアドレスとパスワードの他、

最近では、twitterやfacebookの連携機能を使用したログインのサービスも増えている。

 

しかし、サードパーティの認証や、 個人情報の保管を考えると腰がひけてしまうため、

インムスでは、初回インストールに自動で登録したIDと  引き継ぎ準備のためのパスワード生成機の情報以外は持たない使用にした。

最悪、プレイヤーネームや、所属ギルドの情報で対応する。

実装自体は、シンプルで

  • 引き継ぎパスワードの生成 変更
  • ログイン時の引き継ぎボタンの実装
  • 引き継ぎ後の再ログイン。

上記3ステップのみだ。

引き継ぎパスワードの生成 変更

まずは、古い端末で引き継ぎ用のパスワードを生成してもらう。

コレは、 userIDの生成方法に一部工夫をしてバリエーションをたしたような実装を行った。

パスワードは、何度でも生成できるが、最後に生成したパスワードのみを有効にする仕様にした。

ログイン時の引き継ぎボタンの実装

パスワードを生成して、 ユーザーに user_idと パスワードを控えてもらった上で 新しい端末に

 

インムスをダウンロードしてもらう。 アプリ起動後、初回の 動作を行うが、  ログイン画面上部二 引き継ぎメニューボタンを実装しログイン前に

新端末の user_idを旧端末のIDに変更してもらう。

引き継ぎ後の再ログイン。

あとは、再度ログイン処理を行えば引っ越しが完了する。

 

 

おまけ unityでアプリ制作する際にあったらいいもの

unityに限らないんだけども、スマートフォンアプリで

ソーシャルで android iosの開発を行う場合に必要なものをまとめてみた。

  • パソコン
  • スマホ android iphone
  • タブレット android ipad
  • ドメイン
  • サーバー
  • 何らかのデータベース
  • ペイントソフト
  • ペンタブ
  • HTML エディター
  • キャプチャーデバイス
  • 動画編集用のソフト
  • ちょっと良さげなキーボード
  • モニター
  • GIT代わりの、データサーバー

インムスをリリースするのに必要だった機材はこんなかんじ。

パソコン

パソコンに付いては、適当なデスクトップ。今風ならなんでもいいんじゃない?エンコードもしたからパワーいるかな?

unityが動作するならなんでも。 エンコードの部分さえ目をつぶれば何でもいいが、macでxcodeのbuildを行うため主要なHDDはすべてSSDにした。

 

スマホ android iphone

4Kとか8Kとか出てるけど、 基本は fullHDのサイズで作成した。 ちょっと前なら考えられないくらい大きい。当然作成する画像ファイルのサイズも大きくなりがちなので、リリース前に、軽量化は施した。

あと、androidのシェア一覧に cpu インテルが増えていたので念のため追加。

iphoneは、とりあえずなんでも。内部のバージョンが最新なら変な動作はしないだろう。多分。

androidに関しては、みんな好き勝手な感じがするので あきらめモード 、知り合いのケータイかりたりしてなんとかテストした。

タブレット android ipad

タブレットに関しては、 androidよりも ipadが難点だった。 とにかく2~3台ずつ用意した。

 

ドメイン

結構な数のドメインを取得したが、結局使わなかった。

サーバー

国内の専用サーバーを利用。 転送速度を比較して一番無難そうなところをチョイス。

何らかのデータベース

レンタルのサーバーに付属していたので、mysqlで作成していたが、サーバー移設が脳裏をよぎったため、sqliteに移行した。

かなり珍しいパターンだと思うけど。 ドメインと sqliteのファイルさえあればどこでも引っ越せるのは強みだと思う。

 

ペイントソフト

イラレ、 photshop、クリップスタジオ   どこに使ったんだよ?ってくらい適当なデザインの割に結構 活躍。 基本的にベクター派です。

ペンタブ

部屋のスミに転がっていたので使用。 ペン先が摩耗していたので、パスタ刺しといた。(マジ)

 

HTML エディター

dreamwever とか懐かしいの使っちゃう感じ。

なお、   専用サーバーのデフォルトのエディタにも使用。

あ、あとエクセルも。。;エディタ代わり。

キャプチャーデバイス

以前の記事で書いた、PCIEのキャプチャー   縦画像は取れないので注意してほしい。

 

動画編集用のソフト

適当にネット上で購入。

 

モニター

意外と大事。やっぱり端末ごとに配色に差がある。 イメージと違うことが多かったため、今回途中で購入。

モニター色とiphoneの液晶色の差の中間位になるように 手持ちのandroidは調整した。

 

 

git代わりの、データサーバー gitやめました。

最初は、Gitつかってました。 ええ・・・・こまごま、こまごま。

ひとりで開発してるのに何してんだろう?と考えて  メディアサーバーで終了!

 

ちょっと良さげなキーボード

インムス ソシャゲと化した先輩。実は、メインソースだけで1万行位有る。

なにをそんなに書くことがあったんだ?みたいな感じだけど、よく考えて欲しい。

サーバー同期をすべて書いたら、phpの行数が半端なかった。

同様に unityへのサーバーへのsend部分が大半を占める。

というわけで、 リアルフォース2代目。どんどん加重が軽くなっていく。。。

さようならメカニカルキーボードちゃん。酷使してごめんよ。あとコーヒーこぼしてごめんよ。

 

 

以上 よくあるブログやと、この後机とか椅子とか出てきそうだけど、あくまでアプリのリリースに関する部分でまとめてみました。

ライトニングケーブルとかusbのケーブルとかは、もう消耗品みたいな感じで使い倒しましたので除外しました。

いいよリアルフォース。!