通信ロジック、画面遷移の整理
基盤となる部品をちょっとずつ形にしていこうと思います。
まずは画面作成の基本となる、シーン遷移と、通信ロジック部分です。
シーン遷移
https://github.com/BiwaCoder/MVCSample/commit/a658aa78263c644c6287ae141a8cd00ccff9f17c
シーン遷移はまずSceneManager.LoadScene、でシンプルにシーンを切り替えるところから
あとでマルチシーンエディティングや、画面遷移のアニメーション、バックボタン対応も
仕組み化していきたいですね。
通信ロジック
https://github.com/BiwaCoder/MVCSample/commit/08109cd3f64ffec2e56eb49b501c303922330f12
通信は昔はWWWというものを使っていたのですが最近はUnityWebRequestというものが
できたためこちらを使えるように実装していこうと思います。
UnityWebRequestについてはこちら
https://docs.unity3d.com/jp/540/Manual/UnityWebRequest.html
色々機能があるので整理して汎用的に使えるようにしようと思います。
Unityでのゲーム開発のベストプラクティスを考える
Unityで本格的なゲームを作ろうと思うと案外色々なものが必要になってきます。
自分も作っていく上で、色々とこれでいいのかと悩むことが多かったのでこのブログでまとめることで、知識・技術をより確かなものにしたいと思います。
シーン内の画面を作成するときのルールについて
最初に画面を作成するためのルールについて考えてみます。
Unityはゲームオブジェクトにスクリプトを貼り付ければ動かせてしまうため
とりあえずで作ってしまい、あとで修正や把握が困難になることが多々ありましたこのようなことを防ぐためにまず、どう作るかのルールを考えてみたいと思います。
GUIのプログラムにおいて基本となるのはMVC
自分の場合はUnityにおいても、基本としてMVCで実装を行っています。
ViewはUIの参照をもって、その参照を使って値を変更する
ModelはSQLiteやPlayerPrefsそのたファイルやメモリなどストレージをラッピングしてデータを管理するためのクラスコントローラは画面の遷移を主に管理するクラスとして実装します。
サンプルアプリ
上記思想に基づきアプリを作っていこうと思います
https://github.com/BiwaCoder/MVCSample
こんな感じでViewとControllerを分離します
https://github.com/BiwaCoder/MVCSample/blob/master/Assets/Scripts/MvcController.cs
https://github.com/BiwaCoder/MVCSample/blob/master/Assets/Scripts/MvcView.cs
コードもView,Controllerをわけることで、デザイナーやUXエンジニアとプログラマの作業も分けやすくなるはずです。
ViewはデザイナーさんやUXエンジニアが触れる用に極めてシンプルにすることが一番重要なポイントです。
ロジックなどがあると、UIが変更しにくくなるので、極限まで依存性を減らしていきましょう。
アニメーションなどもViewに組み込むことになるのですが
動かない、静的なビューとアニメーションしているビューを同じコードに埋め込むとわかりにくくなるため
ビューもアニメーションレイヤ、静的構造データなど分離しておくのがいいかなと感じています。
飛んで行く方向に弾をむける
Quaternion.LookRotationをつかえばいけるらしい
Vector2→Vector3はOerator定義されているので代入すればそのまま変換される
http://docs.unity3d.com/ScriptReference/Vector2.html
// Use this for initialization void Start () { rigidbody2D.AddForce (Vector3.right *300.0f,ForceMode2D.Force); rigidbody2D.AddForce (Vector3.up *300.0f,ForceMode2D.Force); } // Update is called once per frame void Update () { Vector3 moveVec = rigidbody2D.velocity; Quaternion rotation = Quaternion.LookRotation (moveVec); transform.rotation = rotation; }
頭の上に文字を表示する
こういうことがやりたい
頭上に名前を表示してオンラインで同期【Unity】【NGUI】【photon】 - (:3[kanのメモ帳]
naochang | 3D上の得点をNGUI上の同じ位置に表示する
UnityのCameraが使う3つの座標系 - テラシュールブログ
3Dはワールド座標系で1とかそんな値になっているので
スクリーン座標系に直す必要があるもよう
こうするらしい
Camera.mainCamera.WorldToScreenPoint(transform.position);
あと画像の原点はPivotで指定されている
原点が下にあった時は画像のサイズを取る必要があるのでこんな感じでとってくる
2Dオブジェクトの幅を取得する方法 - Unity / VRゲーム開発日記@長崎
あとは、
Pixels Per Units倍して画面換算にする
画面サイズの比をかけあわせる
ui.transform.localPosition = new Vector3( screenPos.x+width*100*Screen.width/1136 , screenPos.y+height*100*Screen.height/640,0);
このあたりUGUIやNGUIの機能でやったほうがよさそう
NGUIプロパティ
http://hwks.hatenadiary.jp/entry/2014/10/14/034442
PixelPerfect : 基本的にそのまま表示する
FixedSize : 解像度の縦幅に合わせて表示する
FixedSizeOnMobiles : モバイル*1ならFixedSize、モバイル以外はPixelPerfect
今は上から
Flexible
Constrained
Constrained On Mobiles
になっている模様
Unityコルーチン
Unityのコルチーンのやつを動かしてみた
http://www.wisdomsoft.jp/656.html
using UnityEngine; using System.Collections; public class TownMenu : MonoBehaviour { void Start () { IEnumerator temp = Coroutine (); StartCoroutine(Coroutine()); temp.MoveNext(); //One temp.MoveNext(); //Two temp.MoveNext(); //Three StartCoroutine(RotateObject()); } IEnumerator Coroutine() { Debug.Log("One"); yield return null; Debug.Log("Two"); yield return null; Debug.Log("Three"); yield return null; } IEnumerator RotateObject() { var startTime = Time.time; Debug.Log("Begin Coroutine"); while (Time.time - startTime < 5) { transform.Rotate(0, 100*Time.deltaTime ,0); yield return null; } Debug.Log("End Coroutine"); } void Update () { } }
このコードをCubeに貼っつけるとぐるぐる回ります
StartCoroutineは自動でUpdateのたびに呼び出してみてくれるみたい
Time.deltaTimeがないと、RotateObjectの呼び出し頻度がばらつくので
回転速度が安定しないようです
自作サーバー同窓会
自作サーバー同窓会に行ってきました
自作サーバー同窓会 : ATND
5年前にあった自作サーバーカンファレンスの時は田舎でVisualStdioいじってましたが、今はいろいろあって東京でソシャゲを作っているので感慨深いです。
トピック
- さくらでは自作サーバー15000台作って、専用サーバーとかに使われていた
- PixivはXeonE5-2640x2 に56GBのメモリと960GBのSSDを2本のサーバーを仮想環境作って社内の開発サーバーにするそう
- 自作サーバーを今から教えるのは、アセンブラを教えるようなものかもとのこと、今日においては業務に貢献しない
とかいろいろネタがありました
詳細はこの辺
自作サーバ同窓会 - Togetter
- 今だとコストメリットなくなったので、自作サーバーを業務で使用するメリットはない
- 自作サーバーやってた時代も計画・製造・構築・調達・運用全ての能力が必要でそれをやっていくのが非常に大変で、またそれを出来る人が余りいないためスケールしないという話もよく出ていました。
オンプレとクラウド比較
懇親会では、ソーシャルゲームだとPVに対して得られる収益が高いからクラウドやioDriveという選択肢が取れるけど広告などPV単価が低いサービス、または動画・画像などの大量配信を行うサービスはクラウドだと転送量高くなるからオンプレミスがいるねーって話してました
本当にソーシャルゲームは、PVもイベントある・なしで大きく変わりますし、
まだ成未開拓の分野が多いため他社に先駆けてだすスピードが超重要なのでクラウドでコーディングと運用作業を最小限にして、最速でチャレンジを繰り返すことが重要なのは最近感じています。
自作サーバーの価値
自分は、前の自作サーバーカンファレンスみて
自作サーバカンファレンスを楽天で開催しました:「おれたち世界一になれますか?」:エンジニアライフ
自分でパーツを選んで、ネットワーク組んで、ハードウェアや設置的な問題も考えて直接ユーザーに提供するってまさにエンジニアって感じでめっちゃ楽しそう!使っているものは、個人で買えるものだし、知識と勇気があれば自分で世界を切り開いていける!
って思って、機械が主役となる工場系の受託から、技術やエンジニアが主役とWeb業界に転職したので、0から作れるっていう力をつけるって事自体が非常に価値があるものじゃないかなと思っています。
サーバーの仕様を決めて自分で発注できないと、googleと同じ規模になった時コスパで負けそうですからね。
Pixivさんみたいに自社に触れる開発環境として高い性能のサーバーマシンを置いておくのは、ハードがそこにあって自分が頑張れば凄いことを出来るんだって事を実感できて、現在における自作サーバーの使い方として理想的なんじゃないかなーって思いました。