概要 モバイルゲームを開発する際は、ExcelやGoogleスプレッドシートなどでマスターデータを管理し、csvとしてエクスポートしてgit管理するといった運用をわりと見かけます。 最近、クライアント/サーバー間でやりとりするマスターデータのフォーマットをcsvからtsvに変えたところ、とても使い勝手が良かったため紹介します。 tsvとは タブを区切り文字として使用したデータ形式。 csvはカンマを区切り文字とするが、そのカンマ（,）がタブ（\t）になったもの。 具体的には以下のようなテキストデータとなる。 csv name,hp,atk スライム,10,2 ゴブリン20,4 tsv name\thp\tatk スライム\t10\t2 ゴブリン\t20\t4 tsvのメリット 言語やライブラリへの依存がとても少なく、シンプルにパースすることができる わりと最近のシステムだとcsvファイルとして普通に読み込める コードサンプル C#でtsvを出力 var line = string.Join("\t", fields); C#でtsvをパース var fields = line.Split('\t'); PHPでtsvを出力 $line = implode('\t', $fields); PHPでtsvをパース $fields = explode('\t', $line); tsvのデメリット 文字列中にタブを使用したい時は別の文字列に置換する必要がある マスターデータでタブを文字列として使用したいシチュエーションはあまりないが… 古いシステムだと読み込めないものがある csvのメリット とても一般的に使用されている 以下略 csvのデメリット tsvのようにシンプルにパースすることができない 後述のようにダブルクォーテーションを考慮する必要がある 文字列としてカンマを使用したい時はダブルクォーテーションで囲う必要がある ダブルクォーテーションを使用している箇所と使用していない箇所が混在しがち tsvに比べてロジックが複雑なためパースコストが高い シンプルにカンマ区切りでパースするだけならtsvとコストは変わらないが、マスターデータでキャラクターの説明文にカンマを使用するなど、カンマを文字列として使用したいシチュエーションがわりとあるため ライブラリによっては細部の対応オプションが異なる まとめ tsvからcsvへの変換は容易なため、非エンジニアがマスターデータを参照する時はcsvとして扱いつつ、クライアント/サーバー間のやりとりはtsvとして扱うなど、柔軟に使い分けられると双方のメリットが最大限に活かせるのではないかと思います。

0.0 はじめに 現在アクティブになっている（プレイ中の）シーン（Scene）をもう一度読み込む方法です。 ゲームオーバーになった際のリトライやリプレイの処理を実装する方法です。 備忘録としてまとめます。 1.0 スクリプト 下記のみです。 Test.cs SceneManager.LoadScene (SceneManager.GetActiveScene().name); SceneManager.GetActiveScene().nameで現在アクティブなシーンの名前を取得しています。 その名前のシーンをSceneManager.LoadScene()で呼んでいます。 ?ポイント SceneManagerを使うためには下記が必要になりますのでご注意。 using UnityEngine.SceneManagement;

これは、ソフトウェアアーキテクチャの一つである Clean Architectureを、開発現場での実運用（特にC#, Unityでの開発）に合わせて調整した Simple Clean Architecture の解説記事です。(英語版はこちら) なぜアーキテクチャが必要なの？ ソフトウェアは、どんな実装でもできます。あなたが個人開発をする限り、そしてあなたがコードのすべてを把握できている限り、どんな実装をするのも自由です。ただし、実際にビジネスの現場で、複数人で大規模なコードをみんなで作り上げていくときに、問題が出てきます。あなたの書いた天才的なコードは、他の人から見ると理解に時間がかかり、バグを誘発しやすい難解なものになっているかもしれません。アーキテクチャの使命は、ソフトウェアの構造にルールを課すことで、コードに一貫性をもたせ、これにより開発スピードとクオリティを上げることです。 特に Simple Clean Architectureは実際のビジネス、とくにスタートアップのような不確実性が高い中で最速で結果を出していく必要がある開発現場のため、下記をゴールとして考えて設計しています。 ・複数のメンバーが参加しても、全員が似たような実装になるような規則を用いることで既読性/メンテナンス性を維持する ・複数のメンバーが参加しても、疎結合で相互依存の少ない実装にすることでお互いの変更が干渉しあわないようにする Simple Clean Architecturetとは？ Simple Clean Architecture (SCA) は、Clean Architectureの考え方をベースに、実際の実装方法のレベルまでルールを具体化させたものです。Clean Architecture自体は「設計指針」に近いため、実際の実装の方法は１つではありません。SCAは、Clean Architectureのエッセンスを利用しながら、冗長な部分は省き、また、実装上必要になる「Dependency Injection (依存注入)」と「Reactive Programming」の考え方を足すことで「実装ルールに落とし込んだアーキテクチャ」の形になっています。 とはいえ、Clean Architectureの考え方はコンポーネントを疎結合に保つために非常に重要な基本概念です。下記のようなページを参照することをおすすめします。 https://qiita.com/kz_12/items/bc79102247b86626fc72 https://gist.github.com/mpppk/609d592f25cab9312654b39f1b357c60 また、前述の通り、SCAは Dependency Injection (DI) と Reactive Programming の考え方を取り入れています。これらはソフトウェアアーキテクチャというより、アーキテクチャを実際の実装に落としたときの実現手段(デザインパターン)の１つ、ツールのような立ち位置です。 これらも、SCA特有のものではなく、ソフトウェア構成として一般的なものですので、基礎知識を調べてみることをおすすめします。 ・Dependency Injection https://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f ・Reactive Programming イベント駆動型プログラミングが考え方としては近いです。 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754 https://ninjinkun.hatenablog.com/entry/introrxja おさらいすると、Simple Clean Architecture (SCA) とは ・Clean Architectureで概念として示されているものを、必要最小限のエッセンスを取り出して実装可能なルールに落とし込んだもの ・実装のためのツールとして、Dependency Injection(DI) と、Reactive Programming(RP)を導入している というものになります。 Simple Clean Architectureの構成 下記の図は、Clean Architectureで調べるとまず出てくる図です。Uncle Bobの原典で使われている図です。 Clean Architectureはあくまでコード・コンポーネント間の依存関係を少なくすることでプロジェクトをきれいに保つための行動指針ですので、「この実装じゃなきゃダメ！」というものはありません。だからこそ人によって理解や実装形態が千差万別になっています。 SCAではClean ArchitectureのSOLID原則を元に、特に下記の考え方を重要と考えます。 ・外側のレイヤーから１つ内側のレイヤにのみしか依存してはいけない ・依存関係は必ずインターフェイスを通じて行い、DIによって依存解決する ・内側から外側への情報の伝播はイベント駆動で行うことで、依存関係を無くす また、Clean Architectureではいろいろな登場人物が登場しますが、SCAではその中から下記のみを取り出して使用します。 ・Entity ・Usecase ・Gateway ・Presenter ・View それぞれの特徴を見ていきましょう。 Entity Clean Architectureでは最も中心のレイヤーにある要素です。なので、上位のレイヤーのどれにも依存関係を持ってもいけません。Entityは、「最も基本となるビジネスルールのカプセル化」を担当します。オブジェクトとして扱われる最小単位の要素や、ビジネスルールの特徴上必要になる計算処理などが含まれます。DDD(ドメイン駆動設計)を知っている方には、「EntityはDDDにおける Entity, ValueObject, Domainserviceをまとめたもの」とも言えます。 「基本となる要素のクラスの定義をするレイヤーで、他の上位レイヤーに対して依存してはいけないんだな」と考えてもらえれば十分です。 Usecase Clean Architectureでは中心から二番目のレイヤー、「Application Business Rules」にある要素です。「アプリケーション固有のビジネスルール（いわゆるビジネスロジック）」を記述する役割をもちます。UsecaseはEntityの操作をすることが役割です。ただし、Entityを直接操作するだけでなく、「データベースからEnityとして定義されたデータをGatewayを通じて取得し、処理する」といった処理部分もUsecaseの担当となります。そのため、UsecaseはGatewayのInterfaceに依存することができます。また、UsecaseはInterfaceを通じてPresenterから呼ばれることになります。 Gateway Clean Architectureでは中心から三番目のレイヤー、「Interface Adapters」にある要素です。Interface Adaptersは「ビジネスルールとUIやDBなどのアプリの外の世界とをつなげる」役割をもったコンポーネントが所属するレイヤーです。Gatewayはこのうち、DBや外部ライブラリとのインタラクションを担当するコンポーネントです。 例えばデータベースからEntityで定義したデータを取得する IDBGateway というインターフェイスを定義したとします。 public interface IDBGateway{ int GetValue(string key); void SetValue(string key, int value); } このとき、実際の実装方法としてはDBとしてMySQLを使っても、PostgreSQLを使っても、それは実装者の自由です。これらの実装方法の違いは、例えば IDBGateway を継承した MySqlGateway : IDBGateway や、 PostgreSqlGateway : IDBGateway として実装できます。重要なのは、この実体の修正が他のレイヤーに影響を与えないことです。DIがインスタンスする対象を MySQLGateway から PostgreSqlGateway に変えるだけでこの変更ができることになります。このDIの考え方は他のコンポーネント（UsecaseとPresenter）でも同じです。 Presenter Clean Architectureでは中心から三番目のレイヤーで、「ビジネスルールと外の世界をつなげる」役割をもった「Interface Adapters」にある要素です。Gatewayと同じレイヤーに所属し、UI (View) とのインタラクションを担当します。Presenterはインターフェイスを通じてUsecaseを参照することができます。Viewからの入力をUsecaseに伝えてビジネスロジックを駆動させ、UsecaseからのEntityの更新をViewに伝えます。ここで「Viewに伝える」ための方法として、Reactive Programmingを使用します。PresenterがEntityの更新をPublishするReactive Propertyを備えることで、Viewへの依存なしにUIを更新することができます。 View Clean Architectureでは一番外側の「Frameworks & Drivers」レイヤーに属します。UIの操作、すなわちUIを介したアクションのInputと、更新されたEntityのOutputを担当します。 ViewはPresenterにインターフェイスを介して依存することができます。ViewからPresenterへのアクションはPresenterの関数を呼ぶことで実現します。一方、Viewの更新は、ViewがPresenterが提供するReactive Propertyを購読することで実現します。Presenterの値の更新をイベントとしてコールバックで取得することで、Viewがコールバックを通して表示を更新する。という動作を実現します。これにより、ViewとPresenterが密結合になることを防ぎ、新しいViewの追加を容易にします。Viewはレイヤーの最外にいるため、他の要素に依存することはできません。 以上を図にまとめると、コンポーネント間の関係は下記のようになります。 UnityでのSimple Clean Architectureの実装 SCAは特定の開発言語、プラットフォームに限定されたアーキテクチャではありません。大規模開発でコンポーネント間を疎結合に保ちたい場合、SCAの考え方を適用することはできると考えます。 一方で、最も実践上で相性が良いのがUnityでのプロジェクトに対する使用です。Unity上でのアプリケーション開発は、アーキテクチャ無しの場合、下記のような悪夢を容易に実現できます。 ・とあるMonobehaviourが別のMonobehaviourに依存し、どれかを修正したらすべて動かなくなる ・Monobehaviourへの依存関係 (変数の代入) を public や [serializefield] を使い、Inspectorから代入して行っていて、誰かの変更ですべての参照が吹っ飛んだ ・新しいオブジェクトを追加するためにシーンファイル (.unity) を複数人で編集し、gitでマージする際にコンフリクトした これらは、Unityのエディタからの操作やMonobehaviourに依存しすぎた結果起きるものです。できるだけC#の世界でコードを整理しておき、シーンへのコンポーネントの追加やMonobehaviourの参照を少なくすることで、大規模開発での混乱を少なくすることができます。 具体的には、UnityでのSCAの実装は下記のようになります。 ・SCAに基づき、コンポーネントをレイヤーごとに分ける ・Monobehaviourを継承できるのは「View と Presenter のみ」に限定する ・UniRXを使ってReactive Programmingを実現する ・Extenjectを使って依存注入し、Unityシーンをできるだけ編集せずに機能拡張を実現する 下記はコンポーネント間のデータの流れを示します。 ここでは Gatewayは割愛しています。GatewayはUnityに依存しない純粋なC#の世界のクラスのためです。重要なのは「ViewはPresenterしか参照せず、PresenterはUsecaseしか参照しない」ことです。これを実現するために、 PresenterからViewのような逆方向の情報伝播はReactive Programmingを積極的に使い、外側のレイヤーが情報をイベントドリブンに取る実装になります。 SCA for Unityの各コンポーネントにおけるルールをまとめると、下記のようになります。 ・View 　・Viewはインターフェイスを通じてPresenterに依存できる 　・Viewは他のViewに依存できない 　・ViewはUsecase, Gatewayに依存できない 　・ViewはMonobihaviourを継承できる ・Presenter 　・Presenterはインターフェイスを通じてUsecaseに依存できる 　・PresenterはView, Gatewayに依存できない 　・PresenterはMonobihaviourを継承できる 　・Presenterは他のPresenterにインターフェイスを通じて依存してもよい（が、できるだけ避ける） ・Usecase 　・Usecaseはインターフェイスを通じてGatewayに依存できる 　・UsecaseはView, Presenterに依存できない 　・UsecaseはMonobihaviourを継承できない 　・Usecaseは他Usecaseにインターフェイスを通じて依存してもよい（が、できるだけ避ける） ・Gateway 　・Gatewayはインターフェイスを通じGatewayに依存できる 　・GatewayはView, Presenter, Usecaseに依存できない 　・GatewayはMonobihaviourを継承できない 　・Gatewayは他Gatewayにインターフェイスを通じて依存してもよい（が、できるだけ避ける） SCA for Unityの実装サンプルをgithubで公開しているので、参考にしてみてください。 他のアーキテクチャとの比較 「なんでMVPやMVVMではダメで、SCAを推奨するの？」に対して回答します。それは「MVPやMVVMだとモデルが肥大化するから」です。MVPやMVVMが悪いと言っている訳ではありません。ソフトウェアアーキテクチャは実際のアプリケーションに最適なものを使うべきなので、利点が欠点を上回ればそれで良いと思います。一方で、MVPやMVVMは、前述の通り、役割をきれいに分類していくとビジネスロジック部、つまりモデルのコードサイズが大きくなっていきます。モデルの全体像が把握できているうちは問題ありませんが、プロジェクトが大きくなっていくと「Model間での循環参照、密結合」が顕在化してきます。SCAではモデルに相当する部分はGateway、Usecase、Entityに分かれているので、この「モデルの肥大化」が起きにくなっている点が違いです。言い換えると、「MVPやMVVMのモデルの定義をもう少し細分化したもの」がSCAになります。 「MVPだとコードが整理しきれないけど、Clean Architectureを真面目にやると、RepositoryとかUsecase input portとか、Data Accessとか、細かすぎて逆に複雑になっちゃうよ～」という人達に向けた、「Clean Architectureを簡略化して実装ルールに落とし込んだアーキテクチャ」が Simple Clean Arcitectureになります。

UnityでNuitrackのサンプルを動作させようとしたらエラーしたので解消メモ 下記のコマンドみたいにdllを入れてあげたら解消できました dllをEditorへコピー 管理者で実行が必要でした FORFILES /S /P "C:\Program Files\Unity\Hub\Editor" /M tbb.dll /C "cmd /c copy \"C:\Program Files\Nuitrack\nuitrack\nuitrack\bin\tbb.dll\" @path" エラー内容 nuitrack.TerminateException: NuitrackException (TerminateException): WARNING: Cannot load library module: C:\Program Files\Nuitrack\nuitrack\nuitrack/middleware/NuitrackModule.dll ERROR: TBB version mismatch: runtime library version is 9102, but the application was compiled with the 11102 version! 参考サイト