投稿記事

A-Nest 2021/11/10 22:40

タイトルロゴが出来ましたぁ

どうもグラフィック担当ガフです。

キャラのモデルに関しては、一式揃い…後はディテールを詰めるだけ。
そして今は、モーション作業を進めています。

ただ、blenderでのモーションが不慣れなので少し滞り気味・・・。
皆さんにお見せできる段階になったらまた改めて報告させていだきます。


そして、すでに告知したか分からないのですが。
新作のタイトルも決まりロゴを作成しました。

まぁ悪くないのではないでしょうか?

前作は3dで動かせるけどあくまで動画作品だったので
今回はゲーム性に加え
おさわりパートの追加やシチュエーションも
脅迫してレ〇プ、や屈服セックス、そして睡姦と
いろいろと楽しめるように奮闘中です。

個人的には衣装を強化したいと考えており
着衣ックス好きとしては外せない要素。
「こんな衣装があったらいな」みたいなのをいただければ
製作の参考にさせていたこうと思っています!

それでは、予定しているリリース日も迫ってきているので
気合入れて作業を進めていきます!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

A-Nest 2021/11/03 12:41

開発者向け - インターフェイスの使い方1

どうも、最近あまり一般受けしない感じの記事ばっかり書いてるプログラマのゆっくりみかんです。
僕の趣味もあってどうもこういう話ばかりになっちゃっていますが、いずれは作品の進捗も載せられると思うので、しばしお待ちを。

さて、今回はC#におけるインターフェイスや抽象クラス等々の使い方についてです。
何というか、理解出来ると素晴らしく便利で綺麗にコードが書ける様になる概念なのですが、どうも理解が難しい。
かく言う僕も、最初文章を読んだ時点では、理解は出来るもののどこで使うのがいいのやら? という感じでした。

しかし、こういうものは斜め読みでも参考書や仕様書を何度も何度も読んでいれば、ある日突然
「あれ、こう使えばいいんじゃね?」
と天啓の元になるものです。諦めずに頑張ってみましょう。
というか、インターフェイスとか抽象クラスの解説って、大体抽象的な物言いになってて実際の利用シーンをイメージしたサンプルになってない事が多いのも原因な気がします。
そこら辺を分かりやすく書けたらなぁ、と。

ちなみに、僕の解説は完全に正しいかというとそうでもない気がします。
おかしいと思った所があれば、コメントなりでツッコミを頂ければ幸いです。
ただ、オブジェクト指向の説明で自動販売機や動物などを使う時、ああいう例えに
「正確ではない」
と言う方がいたりしますが、そういうタイプのツッコミは不要です。
正しさよりも、まず使える様にならないと話にならないと思っている人間なので・・・
あと、記事に書くコードは実行を確認しておりません。
説明としては正しい物を書く様気を付けてはいるので、ご容赦を。

本解説は、既にC#をある程度扱えている人向けです。

インターフェイス

インターフェイスとは、一言で言うと「クラスの機能を明示的に宣言して、共通の形で扱える様にするもの」です。
インターフェイスそれ自体に実装はなく、単に
「こういうメソッドあるよ」
「こういうプロパティあるよ」
と宣言するのみで、実装は継承した先のクラスで行います。
(最新のC#だとインターフェイスのデフォルト実装という概念がありますが、それについては割愛します)

C#では基本的に最初に大文字の「I」を付けるルールになっており、Visual Studio等々の入力候補で「I」を打ってみると標準のインターフェイスが色々ぞろぞろ出てくる事でしょう。
標準的な物としては、

  • IDisposable(破棄可能である事を示すインターフェイス)
  • IEnumerable(列挙可能である事を示すインターフェイス)

等がありますね。
特にこの二つを挙げたのは、C#の言語仕様に食い込んでいるインターフェイスであり、分かりやすいからです。

IDisposable

例えば、IDisposableを例に挙げてみましょう。

//一時的なインスタンスマテリアルを保持するテストクラス
public class DisposableMaterialTest : IDisposable {
    private Material _material;	//保持するインスタンスマテリアル
    public Material Material => _material;	//保持するインスタンスマテリアルを公開するプロパティ

	//レンダラを引数に取るコンストラクタ
	void DisposableTest(Renderer re){
    	_material = re.material;	//レンダラに割り当てられたマテリアルを一時的なインスタンスマテリアルとして取得する
    }
    
    //IDisposableインターフェイスを継承した場合、このメソッドを実装しなければならない。
    //実装していないと、エラーになり、コンパイル出来なくなる。
    //また、Disposeは何度呼んでもエラーにならない様に実装しなければならない。
    //つまり、一度解放が済んだら次に呼び出した時は何もしない様にする。
    public void Dispose(){
    	if(_material != null) {
    		UnityEngine.Object.Destroy(_material);
        }
    }
}

実装はこんな感じですね。概ね、コメントに内容は記述しています。
さて、これをどう使えば良いのかと言うと・・・

//説明用の適当クラス
public class Hoge : MonoBehaviour {
	[SerializeField]
    private Renderer _renderer;	//何らかのレンダラが割り当てられているものとする

	public void Fuga(){
    	using(var testMaterial = new DisposableMaterialTest(_renderer)){
        	//マテリアルを使う何らかの処理
        }
    }
}

こんな風に使います。
using構文は、括弧内で変数の宣言を行い、そのブロック内から外に出た時に宣言した変数のDisposeメソッドを勝手に呼び出してくれる構文です。
つまり、先ほどのusingは次の例と等価です。

public void Fuga(){
	var testMaterial = new DisposableMaterialTest(_renderer);

	//マテリアルを使う何らかの処理
    
	testMaterial.Dispose();
}

Unityではあまり見かけないですが、使いこなすと色々便利な局面があるかも知れません。
Unity以外では、アプリ開発とかでファイル等のStream関連を扱う時に特によく使う構文ですね。
Disposeの呼び忘れを確実に防いでくれる、素晴らしい構文です。

さて、この様にIDisposableを実装するとusing構文で自作のクラスを活用出来る様になります。
IDisposableを実装していないと、当然using構文で使う事は出来ません。
つまり、IDisposableは「破棄可能である」という機能を示すインターフェイスで、そのインターフェイスを実装する事によって自分のクラスが「破棄可能である」事をC#のコンパイラに対して明示的に示しているわけです。
その様に示した事によって、using構文を使う事が出来るわけです。

IEnumerable

さて、お次はIEnumerableについてです。
このクラスもIDisposableの様に実装するとC#の特定の構文で使える様になります。
その構文は超便利な「foreach」です。
IEnumerable<T>というジェネリック版のインターフェイスもありますが、通常版の使い方がわかったら少し追加で調べるだけでジェネリック版の使い方もわかると思います。

public class TestEnumerator : IEnumerable {
	//IEnumerableインターフェイスを継承する場合、これを実装しなければならない。
	//このクラスがforeachされた時に、どういうデータを返すかを実装する。
	IEnumerator GetEnumerator() {
		//yield returnはイテレータと呼ばれる特別な構文。
		//通常のreturnはその時点で実行を終了するのに対し、yield returnは値を返した後も処理をそのまま続行する様なイメージ。
		yield return "Ringo";
		yield return "Gorira";
		yield return "Rappa";
	}
}

はい、これで実装は終わりです。
これをforeachするとどうなるでしょうか?

public class Hoge() {
	public void Fuga() {
    	var test = new TestEnumerator();
    
    	foreach(var str in test) {
        	Debug.Log(str);
        }
    }
}

こんな感じで使う事になりますが出力としては

Ringo
Gorira
Rappa

になります。自作メソッドが見事にforeachに対応しました。
説明の為に簡単な例にしましたが、実際に使う際はこの様に使う事が多いと思われます。

public class TestEnumerator : IEnumerable {
	private List<string> _testList;	//テスト用リスト
    public List<string> TestList => _testList;	//テスト用リストを公開するプロパティ
    
    //コンストラクタでインスタンス化しつつ文字列追加
    public TestEnumerator() {
    	_testList = new List<string>() {"Ringo", "Gorira", "Rappa"};
    }

	//IEnumerableインターフェイスを継承する場合、これを実装しなければならない。
	//このクラスがforeachされた時に、どういうデータを返すかを実装する。
	IEnumerator GetEnumerator() {
    	//面倒な場合はforeachで済ませるが、頻繁に呼び出す場合は
        //for(int i = 0; i < _testList.Count; i++){}
        //の形にした方が、わずかに軽くなる。
		foreach(var str in _testList) {
			yield return str;
        }
	}
}

こちらでも先ほどのクラスと同じような結果が得られます。
何が違うかというと、文字列をリストで管理している事ですね。
ListはIEnumerableを実装しているので当然foreachが使えます。
なので、このクラスの場合はこういう形でforeachする事も可能です。

public class Hoge() {
	public void Fuga() {
    	var test = new TestEnumerator();
    
    	foreach(var str in test.TestList) {
        	Debug.Log(str);
        }
    }
}

ただ、一々公開用のプロパティを作らないとこういう形には出来ませんし(変数をpublicにすればって? HAHA! ナイスジョーク!)、見た目にもきちんとIEnumerableを実装してそれ自体をforeachで回す方がスマートな見た目になりますよね。

IEnumerableおまけ

余談ですが、今回解説したIEnumerableの実装は簡易化されたもので、ちょっと書くのが面倒な実装のやり方が他にもあります。
ただ、これは余程の拘りが無い限り使う事はないと思われるので、割愛します。
逆に、クラス内のリスト等を単純に出したいだけであれば、もっと簡単な書き方もあったりします。

//テスト用クラス
public class Hoge : IEnumerable {
	//テスト用のリスト
	private List<string> _testList = new ();
    
    //インターフェイスの実装
	public IEnumerator GetEnumerator() => _testList.GetEnumerator();
}

これだけで終わりです。簡単!
これは何をしているかというと、ListクラスはIEnumerableを実装している為、そのListクラスの実装をそのまま使っているだけです。
これで事足りる場合も多いでしょう。

一段落

さて、こんな感じでインターフェイスのサンプルを色々書いてみました。
ただ、これは参考書にもよくある程度のもので、理屈はわかったけどゲームでどうやって使うんだってばよ!? って感じになる方も多いでしょう。
思ったより分量が多くなってしまったので、続きはまた次回とさせて頂きます。

それでは、引き続き作品作り頑張ります!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

A-Nest 2021/10/26 21:31

新作グラフィックまわりアレコレ

メイド服はかわいい(・ω・)b

ご無沙汰しております。
アーネストグラフィック担当のガフです。

作業がひっ迫していたという事もあり
こちらでの進捗報告が疎かになっております。
ですが・・・・っ
グラフィックまわりは、納得出来る物として仕上がってきていますよ!

プログラム担当のゆっくりみかんさんと日々ぶつかってはいますが
奴が頑張っているなら俺も頑張らねばなるまいと気を引き締め
今回は、前作で納得できなかったグラフィック部分を大幅に強化。

そのうちの一つ、着せ替えパートにおける着せ替えパーツの多さです。
前回は、着せ替えシステムを搭載してたのにキャラごとにおける
衣装の少なさが非常に心残りでした。
着衣にフェチズムを感じる身としては、ここに関しては非常にこだわりたい。
そこでアイコンを一部チラ見せ!

このアイコンの数の衣装に加えて色違いの物を。
今後VUにて追加で衣装を増やせたら良いですね
クリスマスにサンタコス、正月に和物衣装、ハロウィンなどなど・・・
そこに関しては、ゆっくりみかんさんや売り上げと相談ということで

ヒロインの女の子もより可愛く手を加えていく予定です。
そちらは、いずれ公開いたしますのでこうご期待!


さて、今回の作品のタイトルが「用務淫」に決定して
キャラクターのイメージも固まり早速モデリング・・・・

・・・・・悪くないじゃない(^ω^)

























ゆっくりみかん「ざっけんなてめぇ」
がふ「ぎゃぁぁぁぁ」


なんかどこかで見たようなおじいちゃん風味になってしまています。
しかも怒られました・・・はい

まぁ角度によっては元ネタをより想起させてしまうので
もう少しイメージを変えるとは思います。
不本意ですが!

一応、ニャンニャンチョメチョメする場面では
ビジュアルをぼかす(かまいたちの夜風)にする機能を搭載するつもりなので
こ奴の人相が気になる人はご安心ください。


さて、別のイベント用に主人公とは別の男キャラをもう一体ほど用意しますか

他人の空似?どこかで見た事ある気がする























ゆっくりみかん「ざっけんなてめぇ」
がふ「ぎゃぁぁぁぁ」

これも同様に、ちょっと似すぎない程度に工夫しますんで!
許してつかーさい!


男ばかり紹介しても何のゲームを作ってるか
エロゲ製作を見に来たのに!と困惑している人のために
一応、ヒロインアバターのこだわりポイントを・・・

以前ツイッターで呟いたネタなのですが。
かなりオッパイの挙動、形にはこだわりがあります。
俯いた時の垂れッパイや仰向けの時の離れッパイ

激しい挙動をした時にバルンバルン弾む感じとか

ここだけで結構時間を費やしましたよ・・・・
それだけに満足した動きになっています。

そんなこんなで、作業もかなり大詰め・・・
と言ってもまだまだ作業が膨大にありますが
今年中リリース目指して頑張っていきたいと思います!

まだフォローしてない方がいれば
今は無料で情報発信しているので
是非ともA-Nestをフォローしていってくださいね!

いずれ有料プランでもなんかしらみんなが
幸せになれるような物を発信していきたいと思っています!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

A-Nest 2021/10/23 17:57

開発者向け - Naninovelの活用

どうも、ご無沙汰しております。
プログラマのゆっくりみかんです。

前回「書けて無くて申し訳ない」と言いながら、また結局書けてませんでした・・・
なので、今後はきっちりルール化して、定期的に書いていこうと思います。

さて、またえらく時間がかかってしまったのですが、開発はもちろん毎日続いています。
ただ、目に見える変化が中々出せなくて
「うーん、Ci-enの記事書くにも何を書くか・・・」
と悩んだままズルズル行ってしまいました。
しかしまあ、いい加減悩むぐらいなら何でもいいから書かなきゃ、となってサークル全体で引き締めていこうぜ、ってなった感じです。

さて、今回は前回の続きの話でも。

前回、テキスト表示アセットについて色々書いてましたが、特に変わりは無くNaninovelを採用して今に至ります。
こちらのアセットですね。

Naninovel

糞高いですが、値下げをちょくちょくしている様なので、タイミングを見計らうと負担が少なく済みます。
そして、値段に見合うアセットです。

そして、Naninovelを使うにあたって得たノウハウを色々書いていこうかな、と。
正直、細かすぎて分かりやすく書こうとするとすごく大変なので、内容がかなりわかりにくくなっちゃってる気がします。
なので、不明点等あれば、コメントを頂ければ答えれる限りは答えます。
そして、あまり幅広い話じゃなくて申し訳ないです。

細かな設定の癖

NaninovelはUnity上でキャラクタ等々の設定を行っていくアセットです。

こんな感じの設定ですね。
英単語を読めば大まかな意味はわかるのですが、いくつか癖のある項目がありました。
Posesの中に「Visible」という項目があります。
まあ、普通に解釈したら
「そのポーズを表示するか、しないか」
という理解になると思うのですが、Visibleにチェックを入れるとキャラクタの表示がどうも妙な挙動になるようです。
バグなのか仕様なのか判別が付かないですが、とにかく直感には反する設定です。
時間があれば原因を追及してバグだったらバグレポートを出してもいいのですが、そこまで見ている時間はありません。
まあとにかく、そういう
「あれ?」
となる部分がいくつもあって結構時間を浪費してしまいました。
まあ、新しく使うアセットにこういうのは付き物なので、しょうがないですね。

カスタム変数

Naninovelで完結したゲーム、つまりノベルゲームを作るだけなら話は早いのですが、うちのゲームは色々内部で連携をする必要がありました。
その際に一番悩んだのが、こちらで用意した変数との連携です。

Naninovelは自分で独自のコマンドを作る事が出来るので、最初はそれを使って対処していました。
例えば、会話の中でアイテムを持っているか確認する時は
「@checkItem」
みたいなコマンドを作ったり。
最初はこれで行けると思ったんですが、想定よりも作らなきゃいけない独自コマンドが増えて、キリが無かったです。
なので、Naninovelの変数マネージャ自体を置き換える形で、自分のゲームの様々な情報にアクセス出来るカスタムクラスを作りました。

	/// <summary>
	/// ゲームのフラグデータを一緒に読み込み/設定するCustomVariableManager
	/// </summary>
	[InitializeAtRuntime(@override: typeof(CustomVariableManager))]
	public class ShinhokenVariableManager : IStatefulService<GameStateMap>, IStatefulService<GlobalStateMap>, ICustomVariableManager {
		[Serializable]
		public class GlobalState {
			public SerializableLiteralStringMap GlobalVariableMap;
		}
        
        ~~~

こんな感じですね。
わざわざ全部一から書く必要は無く、既存の変数マネージャクラスを持ってきて、必要な部分を改造する感じです。

VariableExistsメソッドやGetVariableValue等々、メソッド名は分かりやすいので置き換えるべきクラスを置き換えて行く感じですね。

こういうマネージャレベルのクラスが割と気軽にカスタマイズ出来るのは、Naninovelの良いところですねぇ。
構造が分かりやすい。

こういうクラスを作ると、Naninovelの構文の中で

@if Money > 1000	;お金が1000以上あるかどうか

みたいな形で、自分が用意したカスタム変数やカスタムな状況を存分に利用出来る様になります。
これで、一々細々としたカスタムコマンドを作らなくても良くなりました。

マスタの取り込みについて

ゲームを作る上で、多くの場合マスタデータというものを作る必要が出てきます。

こういう感じのものですね。
イベントデータだったり、アイテムデータだったり、そういったものをまとめて管理する為にデータを集約します。
多くの場合はExcelで管理をしていると思いますが、うちの場合はNotionという無料サービスを利用しています。
これが非常に便利で使い勝手の良いツールなので、いつかこれに関する記事も書いてみたいですねぇ。

まあ、それはさておき。

最初、会話データをNaninovelに取り込む際、Naninovelの変数に会話自体を突っ込んで固定スクリプトを再生する感じの実装でした。
こんな感じですね。

MobFemale: {Kaiwa}	;Kaiwa変数には会話データが含まれている

このやり方だと1人の会話を差し替えるだけの形なので、複数人で会話させるとか、会話の途中に演出を入れるとか、そういった事が一切出来ません。
僕はそれでもまあいいと思っていたのですが、がふさんから「それは拙い」と突っ込みが入って、考え直す事になりました。
次に考えたのが、会話データで誰が喋っているかをプログラムで認識してカウントし、会話スクリプトの中で発言人数分ループで回す、というやり方でした。
今考えるとかなり酷いやり方です・・・。

@checkPerson		;会話データを解析してPerson変数に発話する人、Kaiwa変数に会話データを入れ、人数のカウントをPersonCount変数に入れるカスタムコマンド
#START				;会話スタートのラベル
@if PersonCount > 0	;会話人数が0以上の場合
{Person}: {Kaiwa}
@nextPerson			;次の人間をPerson変数へ、会話データをKaiwa変数に突っ込み、人数カウントを減らす
@goto .START
@endif

こんなんですね。いやぁ、酷い。
複数人の会話という部分はクリアしましたが、細かい演出を入れたいという要求がクリア出来てませんし、何よりNaninovelは文字列変数の中にNaninovelのコマンドを入れても、それを解釈してくれない実装でした。
会話の中で、特定の文字だけ大きくしたい、とかそういう場合にはコマンドを使うのですが、そういったコマンドが使えなかったのです。
Naninovelの良さを超絶スポイルしてしまっている。

そしてある日、マスタデータにNaninovelのスクリプトそのものを突っ込んで、取り込み時にスクリプトそのものを生成すればいい、とようやく気付きます。
というわけで、こういう感じにマスタデータを取り込む際にNaniScriptのファイル生成をするコードを書きました。

			#region Naninovel関連初期化
			if (configuration is null)
				configuration = ProjectConfigurationProvider.LoadOrDefault<ScriptsConfiguration>();	//Naninovelのプロジェクト設定の初期化
			if (editorResources is null)
				editorResources = EditorResources.LoadOrDefault();	//Naninovelのエディタ設定の初期化
			#endregion

			var naniScriptPath = $"Assets/_ShinHoken/Naninovel/{type}/";	//Naninovelの会話を突っ込むパス
			var assetFilePath = naniScriptPath + id + ".nani";			//Naninovelのスクリプトのフルパス
			var existFile = File.Exists(assetFilePath);					//既にファイルが存在しているか?

			//ディレクトリが無ければ生成
			if (!Directory.Exists(naniScriptPath)) {
				Directory.CreateDirectory(naniScriptPath);
				AssetDatabase.Refresh();
			}

			//スクリプトがサブルーチンなら最後にreturnと、念のためにstopを追加
			if (isSubRoutine) {
				naniScriptText += Environment.NewLine + "@return" + Environment.NewLine + "@stop";
			}

			//ファイル書き込み
			File.WriteAllText(assetFilePath, naniScriptText);

			//ファイルを新規作成した場合
			if (!existFile) {
				//アセットデータベースに追加
				AssetDatabase.ImportAsset(assetFilePath);
				AssetDatabase.Refresh();
			} else {
				//既存のNaniscriptを登録解除
				editorResources.RemoveAllRecordsWithPath(configuration.Loader.PathPrefix, id, configuration.Loader.PathPrefix);
			}
	
			//アセットのGUIDを取得
			var guid = AssetDatabase.AssetPathToGUID(assetFilePath);
			//Naniscriptの一覧に作成したNaniscriptを追加
			editorResources.AddRecord(configuration.Loader.PathPrefix, configuration.Loader.PathPrefix, id, guid);

			//データを保存
			EditorUtility.SetDirty(editorResources);
			AssetDatabase.SaveAssets();

こうする事で、マスタデータにNaninovelのスクリプトそのものを書けば取り込んでスクリプトを生成してくれる様になったわけです。
そして、生成されたスクリプトを呼び出せばそれでいいわけです。
Naninovelへのスクリプト追加周りは僕が勝手に解析してこれで行けるだろう、という推測で組んだ処理なので、もしかしたら危うい所があるかも知れません。
何にせよ、これでどんな演出でもマスタデータに書くだけで可能になりました。

発想って本当に大切ですね。
最初、このやり方が何故か全然思いつかなかったんですよ。
でも、ある日風呂に入ってちんこを洗ってる時に唐突に
「あ、こうすりゃいいじゃん」
って思いつきました。
そして、そういう思いつきの集合体が「ゲーム作りの経験」になるわけですね。

とりあえず

今回はまあこのくらいで。
かなり苦労しましたが、今回のテキスト周りでのノウハウはとても強い今後の糧になりそうです。
会話シーンがないゲームなんてないですしね。
次回作以降は、会話周りについては一切迷う必要がなくなる事でしょう。
こういった感じで今後より良い作品を出来るだけ素早く作る為の様々な工夫をしているので、寛大な心でお待ち頂ければ幸いです。

それでは、また!
作業に戻ります・・・!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

A-Nest 2021/04/15 19:00

開発者向け - Unityのテキスト表示について

どうも、プログラマのゆっくりみかんです。
最近またあまり投稿出来て無くて申し訳ないです。

さて、今回は作品の事ではないですが、開発の上での情報共有などをしたいと思います。
同じく制作を行っている方の参考になれば幸いです。

Unityで開発するにあたって、多分色々な人が非常にめんどくさい思いをするのがテキスト表示周りだと思います。
単にテキストを表示するだけなら簡単に終わる話なのですが、

・文字送りをアニメーションさせたい
・文字に効果を付けたい
・選択肢を表示したい
・後から多言語対応するかも
・ルビ使いたい
・スキップさせたい
・後から編集を容易にしたい
・管理を容易にしたい

etc、etc・・・
やるべき事を考えるとキリが無い分野でもあります。

そういうめんどくさい事はアセットストアのアセットに任せてしまおう、と出来るのがUnityの良い所。ですが・・・
何を使えばいいのやら? となりがちです。アセットはお金払って買うものなので、
「とりあえず買っちゃえ!」
とは中々行かない、というのもあります。しかしながら、買わないとどういうアセットなのかわからない、というのもまた事実。
そこで、Unityのアセットを
「とりあえず買っちゃえ!」
しがちな僕がざっとテキスト表示アセット(実質ノベル作成アセットの事が多いですが)について比較をしたいと思います。
最近、とりあえず買っちゃえし過ぎ! ってがふさんに怒られがちですw
あくまで私見なので「買ったけど全然使えないじゃないか!」となっても責任は負えませんし、僕の言う事が正しいとも限りません。
あくまで「参考程度」にして頂ければ、と思います。

多分一番有名なアセットだと思います。

・ノベルゲーを作るのに不足がない、本当にない
・非プログラマの人でも使っていけそうなくらい行き届いている
・ルビ表示にも対応
・作者が日本人なので、日本語ドキュメントが完璧に用意されている

のが良い点でしょうか。
ノベルゲーを作るにあたっては、不満はあまり出ないと思われます。

しかし・・・ テキスト表示に使おうと思って買うと中々痛い目を見ると思っています。

宴は非常に行き届いた素晴らしいアセットです。ただ、本来はノベルゲーの為のアセットであって、テキスト表示という単体の目的に使う為のツールではないので、その行き届いた作りが邪魔をするのです。テキスト表示はあくまで「そういう事も出来なくも無い」という感じです。
正直、僕は使い始めて割とすぐに
「自分で作った方が早いな・・・」
ってなって挫折しました。
Excelを使うというのも僕としてはマイナスでした。Excelって、ファイルの排他制御がやたらと厳しくて、ぱっと編集してぱっとUnityに戻る、みたいなのが非常にめんどくさいんですね。
編集が終わったら一々Excelを閉じないと、異常な結果になりやすい。
これもやはり目的に関わってくる所があると思います。
ノベルゲーなら、まとまった量の文章を一気にガーッと書いて一気にインポート、みたいな感じになるんだと思いますが、ちょっとしたテキスト表示だと、それが細切れになるのです。

そして、最初に書いた行き届いている、という部分が関わるのですが、構造が複雑過ぎて理解し辛い、というのもあります。
細かい所をカスタマイズするのにあまり向いてないなぁ、と。
何というか、プログラマじゃない人が快適にノベルゲーを作るツール、というのが今の所の僕の認識です。

ただ、結果として僕は宴を使い込めてはいないので
「んなこたぁない」
というご意見もあるかも知れません。まあ、そういう時は
「所詮人類ですらない、柑橘類の戯言よ・・・!」
と思って頂ければ・・・w

Fungus

こちらは無料のテキスト表示アセットです。
無料なのでGitHubからも落とせます・・・ というか、アセットストアよりもGitHubで先に最新バージョンが公開されます。
しかし、無料と言っても中々侮れません。

Fungusの一番の特徴は

・覚えやすい
・使いやすい
・カスタマイズしやすい

という部分でしょうか。
かなりすんなりと理解していけました。カスタマイズもかなり容易です。
しかし、やはり無料ツールという事もあり・・・

・時々不安定
・足りない機能がちょくちょく出る
・特に3D表示周りが弱い
・フローチャートの共有に少し不安がある

という事がありました。

不安定なのは非常に困った事の1つで、何故かアセットの機能で会話シーンを自動でスタートしようとするとスタートしたりしなかったりしたので、自分で開始の為のコードを書いたり、初期化が終わっているはずのタイミングで初期化が何故か終わっていないので、最初にダミーの命令を突っ込んだり、変な現象がちょくちょくありました。
まあ、対策できなくもないので致命的ではないのですが。

そして、何より3D表示が弱い。
これのために、3Dを表示する拡張コードをものすごい勢いでガリガリ書く羽目になりました。
3D表示というのは、シーンが3Dであるとかそういうものではなく、3Dキャラのバストアップを会話シーンに表示したい、とかそういう事が出来ない、という事ですね。
基本的に2D表示が想定されているようです。
どうしても3Dキャラを表示したい場合、HDRPを使っていなければレンダーテクスチャを使うのが一番の近道になるでしょう。
スプライトじゃなくてテクスチャなので、結局これも拡張が必要にはなってきますが、まだ楽な方だと思います。

フローチャートの共有というのは、仕組みとしてフローチャート風にテキストを組み立てていくのですが、そのフローチャートがスクリプタブルオブジェクト(データファイル)として出力されるわけではなく、あくまでゲームオブジェクトとしてしか配置されないので、使い回そうとするとプレハブ化する事になります。
そのプレハブ化が何か悪さをしているのか、何というか処理が怪しく感じる所がありました。

総評としては、3D表示を使わない分にはテキスト表示アセットとしては使いやすい部類だと思います。
今作も、途中まではこれで行こうとしてました。

Naninovel

Fungusで行こうと思っていたので存在に気付いていませんでしたが、A-Nestのディスコードサーバの仲間に教えてもらいました。感謝!
価格が非常に高いですが、セール時を狙えば何とか買える範疇に収まるのではないでしょうか。

今の所、まだ使い始めたばかりではありますが・・・
多分、テキスト表示という目的においてはこれが最強のアセットになるのでは、と感じています。

・3D表示も想定されている
・各種要素の汎用性が高い
・ルビにも対応
・テキスト表示部分も最初から吹き出し等、特殊な表示に対応している
・拡張のしやすさにも配慮されている
・ドキュメントに日本語翻訳がある(一部翻訳がない項目、内容が古い項目有り)
・テキストの編集がしやすく、配慮されている

機能面については、値段が高いだけあって、今の所不足が全く見えません。
そして何よりすごいのは、VSCodeに対応している点です。わざわざこのアセットのテキストを書く用の拡張機能が用意されており、命令の候補表示や色づけまで、強力にサポートしてくれます。
良くない点は

・Fungusよりはわかりにくい
・ノベルゲーを想定し過ぎていてデフォルトの構造が少しイレギュラー

という事でしょうか。
デフォルトの構造がイレギュラーというのは特に今悩んでる所で、Naninovelに関するオブジェクトの全てが破棄されないオブジェクトとして全シーンに残り続ける作りになっています。
というか、デモプロジェクトを見ればわかりますが、プレハブ主体でシーンに何一つ配置しないでも作っていける様になっています。
まあそれはいいのですが、カメラまでそちらに持って行かれるのは中々厳しい。
拡張性が高いのでまあ何とかなるんだろうとは思いますが。
ただ今絶賛使いこなしの為に奮闘中です。

結局お勧めはどれよ?

ノベルゲーを作るなら宴かNaninovel、費用をかけたくないならFungus、ノベルゲーにとどまらない作品を作りたいならFungusかNaninovel、って感じでしょうか。
Naninovelは特に、今の所不足が無く極めて優秀です。
そこにさらに、3Dキャラをバストアップで表示したいならFungusは選択肢から外した方が良いでしょう。出来ないわけじゃ無いですが、自分でコードを組める自信のある人、それだけの手間をかけてもいい人に限定される感じです。
最初に言った通り、あくまで僕の私見ですのでそこはご留意下さい。

というわけで、開発者向けの情報回でした。
作品もただ今絶賛開発中で、さらに情報を出して行こうとは思っています。
メンバー一同頑張っていますので、お待ち頂ければ幸いです。

それでは、また!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

2 3 4 5 6 7 8

月別アーカイブ

記事を検索