自己紹介
以前作ったパッケージのコードが汚すぎて作り直した大学生。
ConversationGraphとは
ノードベースのスクリプトエンジン（会話を構築できるヤツ）のUnityパッケージです。
OSSとして公開しています。
なお、本記事はv2.0.0-pre.1がリリースされた際の記念記事です。
正式リリースまでにサンプルプロジェクトとドキュメントの整備を行う予定です。
がんばる…
コンセプト
実用に耐えうる自由度とパフォーマンス
本題
この記事では、READMEには書けないこだわりや苦労した点、v1との比較を記します。
ConversationGraph-v1（旧バージョン）の問題点
１．ランタイムでリフレクションを使用していること。
ランタイムで速度的に問題となるリフレクションを使用していることは問題視していました。
２．拡張性のなさ
v1も拡張性を意識して開発したつもりでしたが、最終的にはあまり拡張性を持たせることが出来ませんでした。
３．UIの限界
v1ではノードツールのUIは全てGraphViewの上に乗っかっていました。
これによってUI構築の自由度が低下し、UXの向上が難しい状態でした。
４．ConversationGraphAssetの無駄
v1ではRuntime上でもNodeの座標などをもつConversationGraphAssetを読み込み使用していました。
これでは無駄なメモリが確保されることになります。
５．無駄なプロパティシステム
v1では全ての型に対応した属性ベースのプロパティを採用していました。
しかし、これでは大規模なゲームになってくるとプロパティだけでメモリの消費が無視できない量になることが想定されました。
６．UniRxの依存
当時、UniRxに入門したばかりだったため、使いたい・練習したいだけでUniRxに依存しているパッケージでした。
これは単になくしています。
ConversationGraph-v2の改善点
１．拡張性
これはスクリプトノードの導入によって、改善しました。
スクリプトノードは、独自のインタフェースを継承したクラスをパッケージ使用者が制作することで独自の処理を会話中に挟むことができます。
これによって、高い拡張性を担保しています。
２．UIの大幅な変更
UIの中心をAppUIベースのConversationGraohInspectorという独自のEditorWindowに移行しました。
これによって、高いUXを実現できるだけでなく、GraphViewからの依存も軽減しています。
また、ノードエディターがよりすっきりした見た目になりました。
３．RuntimeとEditorのScriptableObjectの切り分け
Editorで使うノードの情報を取り除いたScriptableObjectを生成することで、無駄なメモリ確保をなくしています。
４．Dictionaryを使用した一般的なプロパティシステム
ConversationGraphではstring型のみに対応すればよいという観点から、内部的にはDictionaryを使った一般的なプロパティシステムに移行しました。また、動的にプロパティをいじることが少ないと考え、プロパティ用のScriptableObjectを用意してこれを参考にプロパティが反映されることにしました。
メモリ管理もv1のstaticなフィールドを使用したものより容易だと考えられます。
また、bool型のプロパティは廃止され、スクリプトノードに移行する予定です。（ScriptableBranch）
今後の課題
Runtime側のコードが満足いってないので、その修正を行いたいと思っています。
特にユーザー側が独自のFacilitatorを作る必要のないぐらい洗練したいですねぇ（もともと独自にFacilitatorを作れるようにしようという設計だったが、それが不要なぐらいScriptableNodeが仕事してくれそうなので、色々変更したい。）
ほかにもやりたいこといっぱいあります！！
さいごに
少しの間、自主開発のUnityを触れないかもしれないため少しやり残し感はありますが、previewとしてリリースしました。
また更新して、いい感じにREADMEまで書きたいですね。