2017-02-28

UnityのコーディングにVisual Studio for Macを導入して一週間が過ぎた

誰か俺にVSforMacを入れる勇気を
— ザツヨウペンギン (@YutaDevelop) 2017年2月23日

入れました、導入した後にやった設定と感想をつらつらと書きます

とりあえずPreview版とはいえ、まあなかなかでした

導入・インストール

New Release Preview: Visual Studio for Mac | Visual Studio

ここからインストールしてください

導入・Unity側の設定

f:id:yutakaseda3216:20170228112214p:plain

Preferences を開いて

f:id:yutakaseda3216:20170228112319p:plain

External Tools からExternal Script Editor でインストールした Visual Studio for Macを指定してあげる。

これでスクリプトファイルを開くと動くぞ！

とはいかない、このままだとインテリセンス(補完)が効かない

導入・VSforMac側の設定

f:id:yutakaseda3216:20170228112608p:plain

※機密プロジェクトがあるので名前がバレないように「あ」を入力してます

Open から、Unityのプロジェクトディレクトリの中にある.sinファイルを選択して、ソリューションを開こう

.sinファイルがない時は、Unityでスクリプトを選択して開けば多分自動生成されるはず

これでインテリセンスが効くようになる

ただこのままだと死ぬほど使いづらいので色々カスタムする

カスタマイズ・エディタカラー

まずはエディタのカラーを変える、白背景とか、謎の文字色とかゴメンだし

f:id:yutakaseda3216:20170228113052p:plain

Visual Studio からユーザー設定を開く

余談だけど日本語のメニューなのいいよね。

f:id:yutakaseda3216:20170228114613p:plain

インターフェースをエンジニア大好き Dark にした

f:id:yutakaseda3216:20170228113156p:plain

テキストエディターからColor Themeを選択、選択すればエディタが変更されるので好きな色を選ぼう

現状Theme編集機能はないらしい

自分でカスタマイズしたテーマがあるときは、MonoDevelopなどからエクスポートして持ってこよう

自分はOblivion派なので、今回は割愛

カスタマイズ・ポリシー

ソリューションごと、あるいはグローバルでコードフォーマットなどを定義できる

f:id:yutakaseda3216:20170228113452p:plain

f:id:yutakaseda3216:20170228113520p:plain

ここから新しくポリシーを作る

基本的にはコードの書式設定から、C#の設定項目を変更していく

自分の好きなようにやろう

ソリューションごとにポリシーを適用できるので、プロジェクトを複数抱えてても安心

ポリシーにAttribute改行の設定項目がない件について

VSforMac
アトリビュートの自動改行マジで何とかしろよ…_:(´ཀ`」 ∠):
こいつさえなければ…
— ザツヨウペンギン (@YutaDevelop) 2017年2月23日

あとアトリビュートの中身にインテリセンス効かない
— ザツヨウペンギン (@YutaDevelop) 2017年2月23日

KUSO

Unity使ってると頻繁に出てくるSerializeField変数を一行で宣言したい時、アトリビュートで勝手に改行されるのでその度にCmd+Zを押すことになる

その上アトリビュートで囲むと補完されないので一回一回手打ちになる

カスタマイズ・コードテンプレート

とりあえず上記の問題を解決するためによく使うアトリビュートをテンプレート化した

f:id:yutakaseda3216:20170228114225p:plain

追加する時はユーザー設定からCode Snippetsを選択して、追加をする

また、$class$などの記述を行うことでフリー入力を作ることもできるので活用する

今回、アトリビュートでよく使うSerializeFieldを登録した

ただ、テンプレートに

[SerializeField] $class$ $field$

みたいな感じで記述すると勝手に改行されたのでやらないことにした

わけわからんので製品版で早く設定追加してほしい

ただ海外フォーラム見てると超昔から言われてるのに開発者がResharperを使ってるからいつまでも追加されないとかなんとか

カスタマイズ・パフォーマンス

とりあえずで上記の設定を終え、使ってみると

インテリセンス遅すぎワロタ状態

だった

とにかくクッソ重い、ちなみに使用してるmacは2015年モデルのフルカスタマイズなのでスペックが低いわけじゃないと思う

なので、パフォーマンス改善をする

f:id:yutakaseda3216:20170228114922p:plain

まずは何はともあれテキストエディタからアニメーションを無効に

強調表示とかも消す

他にも視覚効果をOFFっていく

f:id:yutakaseda3216:20170228115041p:plain

効果があるかはわからないものの、コードの動的コンパイルが走るので解析も毎回走るんじゃないかと思い解析も切った

だいぶ早くなった

カスタマイズ・キーバインド

人それぞれすぎるので割愛、設定しとくと楽やで(提案)

最後

頻繁に落ちる上に操作不能になるMonoDevelopよりは使いやすい

VisualStudioCode、Atom、VimとかのエディタよりIDE派なので今後に期待したい・・・特にアトリビュートとパフォーマンス

メモリ2GB食われるのでメモリの残量には気をつけよう

もうしばらく使ってみる

2017-02-22

昨今のUnity開発におけるMVP設計思想についてと、それの適用可否の話

こちらも合わせてどうぞ

yutakaseda3216.hatenablog.com

はじめに

こちらの記事を読んで、最近Unity開発でよく言われるようになった

MVPについてだいぶ浸透(あるいは導入)してきたのではないかと思った。

developers.cyberagent.co.jp

ただ、すべてのゲームがこの思想でカバーできるかというとそうでもないと思っている。

「そりゃ仕様によって最適解は変わるだろw」と思うかもしれないが

言いたいことはそういうことではなく

MVP設計というのは元々Web業界で浸透した設計であり

WebのフロントはユーザーがUIを操作するものであるということだ。

つまりこの設計思想をそのまま、あるいは少しのアレンジを加え適用できるのはユーザーがUIを操作することが基本となる

モバイル向けソーシャルゲームアプリということである。

それを意識せず、ユーザーがコントローラを持ち、キャラクターを操作するタイプのゲームなど（あくまで、など）で

「MVPっていうのがいいらしい」

「とりあえず導入しよう」

でどこまでがModelでどこまでがViewでPresenterをどこまで定義すれば良いのかが曖昧のまま設計が迷走する例をよく見た。

MVPの具体的な活用法に対しては先ほどの記事を読んでもらえばわかると思うので

今回はModel-View-Presenterに対して、各レイヤーの解釈について特にUnityゲーム開発における持論を書こうと思う。

ある人にとっては間違っているかもしれないが、ある人にとっては正解への道標になるはずだ。

先に結論を書くと、Viewは積極的に拡大解釈しろという話だ。

あとUniRxとMVPの理解は前提で。

レイヤーの明確な責任

まずModel-View-Presenterにおける役割を明確にするのと同時に

ゲームを作るために必要なレイヤーを全て洗い出す。

MasterData

一応書く。

ゲーム中の経験値テーブルや、アイテムのId、価格などのデータ。

Model

ゲームを構成するマスターデータをもとに、ユーザーの現在所持しているアイテム数や、経験値などのいわゆるセーブ対象になるデータを管理しているもの。

ゲームを進行するごとに、書き換えられていく。

役割として

データを保持する
データの書き換えロジックを、メソッドとして外部に公開する
データが書き換えられた時、通知を発行する

この役割さえ守っていれば、中身でどれだけインスタンスを生成しようと、どんなロジックを持とうと構わない。

逆に言うと、これ以外で役割を持ってしまってはいけない。

そしてModelは依存先を持たず、どんな状態でも自身をインスタンス化できるようにしなければならない。

View

プレイヤーが実際に見る画面と勘違いされやすい（名前的に）。

本質的な役割は

ユーザーが実際に見る画面を構成し、表示する
画面を更新するメソッドを外部に公開する
ユーザーの操作を通知する

最初に書いた通り、UIを操作するだけであるならこのUIが操作されたという通知を飛ばすだけで済む。

その通知の結果、Viewの更新を受け取るだけで済むからだ。

ただ実際にはそうはいかない。

なぜなら、キャラクターを操作できるゲームであるなら、キャラクターの位置が更新され、その結果アイテムを拾えたりする領域に入ったりするなど、複雑であるからだ。

そして愚直にMVPに当てはめるのであれば、コントローラ操作というViewが通知を発行し、キャラクターのモデルが位置の変更を通知で管理しなければいけなくなる。

はっきり言ってそんな設計は冗長すぎてクソだ。

なので後ほどViewの拡大解釈と自由設計について記述する。

ただ、上記3つの役割自体は変わらないので厳守しなければならない。

そして、Modelと同じく、Viewはどんな時でもインスタンス化可能でなければならない。

Presenter

具体的な機能の提供者である。役割として

Viewからの通知を受け取り、Modelが外部公開しているメソッドを呼ぶ
Modelのメソッドを呼んだ結果、Modelからの通知を受け取り、Viewが外部公開しているメソッドを呼ぶ

単体では機能しないViewとModelをつなげ、ゲームとして成り立つような機能をロジックとして提供する

となっているが、例として

アイテムを拾える領域に入った通知がViewから飛んでくるので
その通知が飛んできた後で他のViewからボタンが押された通知が飛んできたら
Modelが公開しているアイテムを一個増やすメソッドを呼び
アイテムが増えたという通知を受け取り
Viewが公開している「アイテムを拾った演出」を出すメソッドを呼ぶ

という処理を行うといえば、わかりやすいだろうか。

Viewが作り込まれれば、あとはPresenterを量産するだけでゲームを拡張していくことが可能になる。

以上がレイヤーの責任の話。

Viewを積極的に拡大解釈していく

ここまでの話で、何が一体問題なのかというと

ゲームはユーザーの操作がバリエーション豊富すぎてViewの役割がブレやすい

というところだ。

例として、ゲームの操作キャラクターについての話をした。

ここで考えたい

キャラクターとはどこのレイヤーに属するのか？

ゲームの1機能としてキャラクターを見るのであれば

Model-View-Presenterにまたがって処理を書かなければいけない。

でも、ユーザーの操作だし、キャラだって要は画面の1要素なのだからView単体で記述しなければいけない。

どっちだろうとなる。

結論としては、どっちも正しい

なので

Viewとしての役割を厳守できれば、内部の処理はView内で完結されたMVPで記述されても良いのでは

と考えることも可能である。

そしてさらに拡大解釈するなら

Viewとしての役割さえ守れていれば、中身の設計はなんでもいい

だ。

例として、クラス図を書いてみた。

f:id:yutakaseda3216:20170222145935p:plain

ViewがCharacter全体の各コンポーネントで、ゲームに関連するHpなどをModelに移譲することで見通しが良くなる。

CharacterPresenterはCharacterの各コンポーネントの通知を使って、Modelを更新すれば良くなるが、既存のPresenterとは違う点がここで生まれる。

それは通知を発行したViewは自身で更新を行うということだ。

ダメージを受けた時に、ダメージモーションの遷移などをいちいちPresenterから発行されていては、Character自身が独立して動かなくなってしまう。

なのでPresenterの役割としては

Viewの通知を使い、Modelを更新した結果、必要であれば他のViewに対しての更新を行う

になる、ダメージの結果HPゲージを更新する処理を呼ぶとかね。

最後

蓋を開けてみればなんだそんなことかと思うかもしれないが

責任を明確にしないままMVPを導入するとカオスになるのを身を以て経験している。

うまくレイヤーを定義してやり、そのレイヤーに属するものは何なのかを考えよう。

そして、責任さえ守れていれば、レイヤーの中身は自由に解釈して構わない

そういう結論を今自分では出している。

推敲されておらず、勢いだけで書いた文なのでわかりづらいかもしれないが

許してね＾＾

何かあればTwitterまでどうぞ。

あとこんなこと書いてる暇あるならゲーム作れって言われそうなのでゲーム作ります・・・。

2017-02-20

UniRxでObservable -> IEnumerator -> Observable変換した時のライフサイクル

コード

gist9ab1097554ad9f37a8931f82cfdcb467

破棄されない話

.SelectMany()にCoroutineを使用するとうまく破棄されない。

.ToYieldInstruction()を使ってObservable -> IEnumeratorに変換したCoroutineを実行中にコンポーネントを削除するとエラーを吐き出す。

.ToYieldInstruction()したCoroutineはどうやら源流のObservableに紐づけられないようなので

別途.AddTo()でライフサイクルを定義してあげる必要がある

CompositeDisposableなどを使用したライフサイクル管理をしている場合は

引数でライフサイクルの依存先を渡す
Observable.FromCoroutine(_ => Coroutine()).AddTo(依存先)

でなんとかできるのではないでしょうか。

追記

@YutaDevelop ToYieldInstructionにCancellationTokenを渡すのが、伝搬方法になっているのですが、SelectManyでは繋ぎにくいですね、一応模範解答はこうですが、面倒くさいのは否めない。 https://t.co/qPPtEVrtOG
— neuecc (@neuecc) 2017年2月20日

作者様

neuecc (@neuecc) | Twitter

よりご回答いただきました、模範解答はこちらのようです。

gist.github.com

CancellationTokenと言う仕組みがあり、引数にそいつを渡してあげることでライフサイクルを定義できるようです。

ｼﾗﾝｶｯﾀ・・・

使うときはちゃんとオペレータの実装も見ないといかんですね。

neuecc様有難うございました。

終わり