読者です 読者をやめる 読者になる 読者になる

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

 

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

とりあえず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改行の設定項目がない件について

 

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、AtomVimとかのエディタよりIDE派なので今後に期待したい・・・特にアトリビュートとパフォーマンス

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

 

 

もうしばらく使ってみる

 

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

はじめに

こちらの記事を読んで、最近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

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

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

 

役割として

 

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

 

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

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

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

 

View

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

本質的な役割は

 

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

 

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

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

 

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

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

 

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

 

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

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

 

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

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

 

Presenter

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

 

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

 

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

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

 

  1. アイテムを拾える領域に入った通知がViewから飛んでくるので
  2. その通知が飛んできた後で他のViewからボタンが押された通知が飛んできたら
  3. Modelが公開しているアイテムを一個増やすメソッドを呼び
  4. アイテムが増えたという通知を受け取り
  5. 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までどうぞ。

 

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

 

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

コード

gist9ab1097554ad9f37a8931f82cfdcb467

 

破棄されない話

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

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

 

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

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

 

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

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

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

 

追記

 

作者様

neuecc (@neuecc) | Twitter

 

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

gist.github.com

 

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

シランカッタ・・・

 

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

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

 

 

終わり

Monodevelop - UnityでVersionControlが消えた時の対処

 

はじめに

 

MacOSX 10.11.2

Unity 5.4.2f2

MonoDevelop-Unity 5.9.6

バージョン管理はGit

 

BlameやDiff、Changesをワンクリックで見れるので重宝してる、こんなやつ

f:id:yutakaseda3216:20170111112414p:plain

 

ただこいつはよく消える

 

消えた時

Monodevelop-Unity > Add-In Managerを開いてこれをenableにする

f:id:yutakaseda3216:20170111112604p:plain

 

これで復活

する時もあればしない時もある

しない時はSolutionWindowを開いて(View > Pads > Solutionで開ける)

スクリプトファイルを選択した時に出る歯車アイコンクリック、DiffとかBlameとかLogとか選択すると復活する

 

それでも復活しなかった時が来たら対処法調べて追記します。

【windows】何も考えずに最速でsshkeyを作ってgithubと連携する

Gitをインストールします

Git - Downloading Package

チェックボックスはこんな感じで

f:id:yutakaseda3216:20170105211036p:plain

f:id:yutakaseda3216:20170105211116p:plain

後は全部一番上にして、デフォルトのままでおk

 

インストール後

デスクトップにできたGitBashのアイコンをダブルクリックでBash開く

sshkeyを作る(下記をそのまま打ち込んでEnter)

ssh-keygen

ここに作りますか?って聞かれる。(ディレクトリ階層が表示されてる)

Enter押す

passphraseは?って聞かれる。何も考えないのでいらない

Enter押す

もういっかい入力してねって言われる。何もいれてないのでいらない

Enter押す

 

GitHubと連携

sshkeyは初期状態のままならUser/自分のアカウント名/.sshフォルダ内にある

隠しフォルダになってる場合があるので隠しフォルダ見えるようにしとこう

.sshフォルダの中にある、id_rsa.pubをテキストエディタで開くと謎の文字列が生成されているのですべてコピーする

 

f:id:yutakaseda3216:20170105212411p:plain

github開いて、右上の自分のアイコンからSettingsを選択するとこんな画面が出る。

その中のSSH and GPG keysを選択

 

New SSH Keyボタンを押してこんな感じで作成

f:id:yutakaseda3216:20170105212610p:plain

後はリポジトリクローンするときにsshでクローンして快適なgitライフを送ろう!

 

終わり

CUI慣れてからSourceTreeとかKrakenとかのGUIに移行しないとgitの内部的な動作ちんぷんかんぷんで終わるので気を付けような(もちろん内部知らなくていいよって人はKrakenをぜひオヌヌヌします)

コミケに参加して&SleepWalkerの今後

 

はじめに

PhantomIslandのブースまで、朝早くに来てくださった方、ご購入していただいた方

大変ありがとうございました。

動画を見ましたと言ってくれる方や、デジゲー博でプレイしていただいていた方など、多くの方に直接販売することができました。

私は、人に直接モノを売るというのが初めての経験でしたので、とてもうれしかったです。

30枚の用意でしたが、午前中早々に完売してしまい、ゲームを目当てにブースに来てくださった方に完売してしまいましたというのが心苦しかったです、数を用意できず申し訳ありません。

しかし海外の方が数名いらしていただいた際に、買えなかったですが今後に期待していますと言われ、とても身が引き締まる思いでした。

ありがとうございました。

 

コミケの活気はすごいですね!デジゲー博の時も思いましたが、素晴らしい場だと思います。

参加できて本当によかったです。

 

頒布したもの

今回頒布した体験版ですが

オープンワールドで自由に探索(本編)

・ボスとの戦闘モード

の二種類のモードをつけさせていただきました。

 

オープンワールドでは、様々な人と話をしたり、依頼をこなしたり、広大な世界を探索できます。

ボスとの戦闘は、一筋縄ではいかないものを用意させていただきました。

ご購入された方はぜひお楽しみください。

 

今後のSleepWalker

 

製品版としては、まだまだ未完成な部分も多く、システムすら乗っていないものもあります。

完成は来年の夏を予定していますが、その前に一度展示をしようと思っています。

BitSummitへの申し込みを予定していますが、予定は未定です。

 

また、今回の体験版で数多くの課題が出ました。

それを一つずつ潰していこうと思っています。

 

また。製品版へ追加するシステムはこのようになっています

・キャラクターの強化システムの作成

・敵キャラクターの追加

・必殺技追加

・攻撃技の追加

・新たに6ワールド追加、7つのダンジョンを作成

・アイテムの追加

・装備品(装飾品)の追加

 

キャラクターを育てる、世界をより仕上げていく、という部分をこれから開発していきます。

ご期待いただければ幸いでございます。

 

最後に

同人でオープンワールドゲームを開発しているということで、国内外で少しだけ注目していただけているようです。

少しプレッシャーもありますが、周りの開発者さんががんばっているところを見て、自分も頑張ろうという気持ちになれています。

ありがとうございます、これからもよろしくお願いいたします。

 

ゲームの完成をお楽しみに!

UnityでGitLFSを使用する際にTrackするべきファイル

 リポジトリが爆発したので背に腹は変えられないとLFSの導入を決意

Trackする画像や素材拡張子

*.png

*.psd

*.tga

*.jpg

*.fbx

*.anim

*.mp3

*.ogg

*.wav

 

git lfs track *.~するより、.gitattributesに直接記述した方が早い

 

追記(2017/03/10)

.animはアニメーション編集しない前提なので、編集する場合は.animを管理対象から外した方が良い

 

結果

導入前:リポジトリ9GB

導入後:リポジトリ1.2GB(!!!!) LFS 6GB

 

なんか差分の1GBくらいどっかいったけど、多分履歴をfilterしたりしたから?

バイナリ直で持たなくなったから減るとかあるのかな

 

うまく使ってBitBucket無料プランで乗り切っていきたい

 

あとSSH認証じゃないとファイル100件ごとにパスワード要求されるのでKeyは作っておこう