スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告|
  3. トラックバック(-)|
  4. コメント(-)

たまには進捗

文章のルビ表示に対応してみた。
原寸

今回、和風題材なので読めない系漢字が多くて、ルビ欲しいなぁと前々から思ってたのでした。
農業用語でも読みづらいやつ多いですからね。 「唐箕 (とうみ)」とか。
ちなみにサクナ様は正式には「佐久名比命 (サクナヒメ)」といいます。

160925_02.png

セリフ、というか表示テキストはExcelで管理してます。
ローカライズももう4作目になるのでなるべく楽にできる様に…。

ルビは、「^本文^ルビ^」みたいな書式で対応しました。
技術的に難しいことはなかったけど、レイアウト崩れを潰していくのが案の定めんどかった。
元データが読みづらいのが難点ですけど、Excelだから仕方ないね。
Excelには既に管理上の限界を予感してますが、といってツール自作できるわけもなく。
なんか適したツールがネットのどこかにあるんじゃないかなぁと思ったりもするのですが。

ついでに機能解説すると、
なるべく連番は消し去りたい派なので、通し番号は文字列をハッシュ化したものを使ってます。

Ownerのとこは名前入れておけば吹き出しに自動的に名前表示が付くのと、
どのオブジェクトが喋ってるのか探してくれるみたいな構造。

あとCodeの最後を数字連番にしておくと自動的にグループ化されて、
グループを指定して会話を流せるみたいな感じ。

RPGっぽいものは社畜時代も含めて作ったことがないのでこの辺手探りなんですが、
夏コミ版を通して、やっと量産にいけそうかもな手応えは出てきました。
物量多いゲームは大変ですね。


そんな感じでたまには進捗報告してみた。
夏コミ版を経て大枠は発表済みとなったので、
これからはちょっとした進捗など見せていければなぁと思います。
次回更新予定は冬コミ当落報告!
スポンサーサイト
  1. 2016/09/25(日) 13:46:31|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

あけました

あけまして冬コミお疲れ様でした!

なんとか新作「天穂のサクナ」の初体験版を頒布して帰ってきました。
めっちゃギリギリでスクショだけ公開したのがこちら。
拡大拡大
拡大拡大

公開がギリギリすぎて反省したけど、なにせここ3日くらいの怒涛の追い込みで
全く見た目が変わってるので仕方なかったとしか言い様がございませんぬ。 ごめんねごめんね。
いやぁ初回リリースは大変だよね。 一応体裁だけは整えられた気がするので一安心してます。
当たり抜け……? 知らない子ですね……。

ご覧の通りの横スクロールアクションがメインですが、
冬コミ版には全く入らなかった拠点パートというものがあったりします。
アクションパートでも、このゲームの特徴になる要素はあまり入れられてませんので、
今回はとりあえず基礎的なアクション部分が体験できる内容だったということで、これからにご期待ください。


ところで今回CD頒布をやめて、初のDLカードオンリー頒布をやってみました。
拡大
名刺サイズにダウンロードURLが書いてあるカード。
対面電書さんなど利用すればシリアルコード発行もできます。
今回ギリギリすぎて対応できなかったのでDropboxに入れちゃいました。

さて、開発側から見た結論から言うと、非常に楽ですね。

テュプリケーター導入してないうちとしては、CD焼きの時間コストはハンパないわけです。
1枚1分で焼けたとしても、500枚焼いたら500分 = 8時間もの間
ディスクの入れ替えなど地味な作業が待ってます。
(アスタ最終体験版を500枚焼いた時は途中寝たのも含めて27時間かかりました)

また、CDの場合、焼き始めたらもうデータ内容の変更は効きませんが、
DLの場合はデータを再アップロードするだけで可能です。 会場でだって更新可能!(あかん)

重量、容積ともに優秀です。
CDといえど3ケタ枚になってくると重いんです。 搬入までに袋が大破しないか心配になります。
DLカードならかさばらない! 軽い! 最高!

またCDは完売できなかった場合の精神ダメージが大きいです。 持って帰りたくない。
DLカードなら最悪閉会後に捨ててしまうというのもアリでしょう。


人に渡しての反応は、
・DLカード頒布増えましたねー。
・あ、ありがとうございますー?? (なんのカードなのか理解されてない)
・こんなもんもらって嬉しいと思ってんのかちゃんとディスク焼けディスク! (ねこみみのかけら 神楽さん)

といったものがありました。
最後のは案外重要な話で、いまいち手に入れたっていう嬉しさに欠けるみたいなんですよね。
電猫さんくらいちゃんと作ってあれば僕的には十分嬉しいですけど、どうなんだろ。
拡大

定着していくにつれてユーザー側の反応も変わってくるのかもしれない。

CD頒布にはなんせ大きな問題が2つあって、
・CD系ドライブが最近のPCには付いてない
・太陽誘電をはじめCDメーカーが生産を辞め始めてる
ので、完成品に関してもディスクメディアで大丈夫か怪しい状況になりつつあります。

サクナ完成時には……うーんどうだろう。 読めない。
パッケージ自体は作りたいので作るでしょうけど。
中身の完成がまだまだ見えないのでこんな話しててもしょうがないですが。

そんなこんなでDL頒布してみた感触でした。
体験版頒布時は特に最後余力がなくなるので、DL頒布は有利ですね。 今後もやっていきたい。
  1. 2016/01/01(金) 18:18:45|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

しんちょく

月一の進捗報告です。 ご確認下さい。

150709_00.jpg

次回作向けの制作準備を着々と進めてますが、
とりあえずフリージアさんでテストしてます。 懐かしいですね!

今回エンジンごと変えたので何もないまっさらな状態からのスタートでしたが、
段々準備が整ってきて、色んな機能が結構さくっと動く様になってきて楽しくなってきました。
スタートダッシュ遅かったけどここからゲーム作っていくのは早そう。 早いといいな。
  1. 2015/07/18(土) 16:26:43|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

進捗です。 ご確認下さい

とりあえずエフェクトエディタが使えそうなとこまできたっぽい。
150530_00s.jpg

色々足りないというか、やろうと思えばいくらでもやれてキリがないといった方が正しい。

今までこのエディタは自分しか使わないこと前提に作られていたのですが、
何箇所かから他所でも使いたいかもって言われてたりして、
依存部分をある程度外に出したりとかしてたんですが、それがもうほんと大変で。
自分が使えればいいやー\(^o^)/方式よりコスト3倍くらいかかってると思う。
その割に他所で使うのは結構大変そう。 汎用環境作るのはわいには難しい…。

ただ、おかげさまでJsonによる中間形式に対応できまして、念願の拡張性が確保されました。
今までなんとバイナリ一本だったので、
ゲームの量産に入ったらデータフォーマットは変更しない! という男らしい仕様でした。
それはそれでゲーム完成へ向けては良いのかもしれませんが…w

追加したい機能も色々あるんですが、こちらもキリがないので一旦とめて
ゲーム本体の開発に移ろうかななどと言ってたらコミケ当落が出ちゃいますよプロデューサーさん!!

\(^o^)/
  1. 2015/05/31(日) 14:43:15|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

近頃のえーでるわいす

気が付いたら1ヶ月経っちゃってるてへ。

最近はまだアスタの海外版など作業していたりしますが、
概ね新作の制作へとシフトしてます。 わぁい。

実は去年の前半、まだうちでPS4移植やるかどうかまごまごしていた頃にも
新作へ向けての環境整備など進めてました。
140610_0001.jpg
アスタの時点では最古の使いづらいシステムになってしまってたエフェクトシステムを一から作り直した
新エフェクトシステムとエディタなど。 あまり見た目にはわからない。 /(^o^)\

そして今は環境をもっと根っこから整備してます。
またエンジン作り直すの? バカなの? という感じですが、
色々とご縁やタイミングが合って、これまでとは少し違った形の開発環境になりそうでウキウキしてます。
早く成果が見せられる様に頑張りたい。 かしこ。
  1. 2015/04/22(水) 11:47:45|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

マスタブリード

アスタブリード PS4版 完成!完成にございます! 3/19発売です!

大体動画にまとまってるのでとりあえずこちらを御覧ください。





  1. 2015/03/04(水) 23:49:35|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

花咲か妖精UE PV正式版

花咲か妖精 Ultra Encore 正式版PVを公開しました!

(ニコニコはこちら)

まとめ動画からは結構雰囲気変わったんじゃないかと思います。

ていうか10日前はこの有り様でした。
拡大


拡大

拡大

締め切り前の追い込みたるや。

UE4の検証用ということで1ヶ月と決めて作った今作ですが、
一応形にはなったので成果としてはまぁまぁ上々かなと思います。

というわけで明日の夏コミではよろしくお願いします!
  1. 2014/08/16(土) 13:02:48|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

うにこーど

英語版対応の時に文字コード関連でちょっと引っかかったのでメモっときます。


■ OSを英語環境に設定してチェックする
コントロールパネルの「地域と言語」で、
「システムロケール」を英語かなんかに。「場所」を米国かなんかに。

140612_00.jpg
これでマルチバイトで普通に日本語とか出してたとこは化けると思います。
ゲームの対応としてはユーザーから見える文字について対応できてれば良いので、
プログラム自体はマルチバイトのままいって、
ユーザーに見せる表示処理だけどうにかするという方向でいきます。



■ マルチバイトプログラム(SJIS)の海外対応の選択肢
1.SJISから一切の変換なくそのまま使う
2.UTF-8にする
3.UTF-16にする

まず1のSJISをそのまま使う方法。うちだとフリージアさんがこの方式です。
「一切の変換なく」の点が重要で、先の英語OS設定を行うとWindowsAPIでSJISが使えません。
具体的には WideCharToMultiByte で CP_ACP を指定しても動かない。(参考)
内部変換ができないため、SJISで受け取りSJISのまま処理するしかありません。

ビットマップフォントみたいな自前でフォントテーブルを参照する方式で使えます。
OSのシステムを使ったフォント表示だと無理です。


2と3は共にUnicode対応ということになります。
フォント表示に限って言えば3のUTF16対応が最も有効なのですが、
全ての文字を2バイトにされてしまうので色々困ったりします。
UTF8であれば半角英数は1バイトのままでSJISとの互換も保つので、
途中から対応する場合は基本UTF8で処理するのが個人的にはオススメ。
アスタはUTF8にしました。



■ 落とし穴いろいろ

ビットマップフォント系は文字列を1文字ずつ解釈していかないといけないので、
文字単位のバイト長の判定が必要になります。
UTF16は2バイト固定ですが、UTF8は可変長で最大6バイトまでいっちゃいます。

UTF8でバイト長取る例
u8 Font::getByteSizeUtf8( u8 uCode )
{
	u8	uRet = 1;
	if( 0x80 & uCode ){	//!< 1バイト文字以外
		for( u8 i=2 ; i<=8 ; i++ ){
			uCode <<= 1;
			if( !(0x80 & uCode) )	break;
			uRet++;
		}
	}
	return uRet;
}
ちなみに漢字は3バイト


漢字判定。
厳密にやるとかなりめんどいっぽいですが、簡易的に取るならこれで問題ありませんでした。
	uWord >= 0xE4B880 && uWord <= 0xe9bea0
参考:UTF-8コード表


表示時に UTF8 から UTF16 への変換。
日英対応くらいならおそらく必要ないんですが、
>ポルトガル語をUTF8のままシステムフォント表示に流し込んだら文字化けした。
って肉の人が言ってました。
直前にUTF16へ変換してから送ったら直ったそうな。

UTF8とUTF16の相互変換はOS設定とかに関係なく可能です。
やり方はググったらいっぱいでてきます。



もうSJISなんて使うなよって話ではありますが、やっぱり中々難しい。

というか英語OSでも内部変換さえできれば問題なかったんですけど、
それさえ出来なくしたWindows様に怒りが有頂天なのでありんす。

あと英語ならなんとなくは分かるわけですけど、
世界にはもはや記号にしか見えない文字がたくさんあるわけでして、
多言語対応は茨の道だと思いました。まる。
  1. 2014/06/12(木) 15:48:33|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

Opusに対応してみた

Opusというサウンドフォーマットに対応してみました。
例によってサウンド系は情報が少ないんで、実装メモなど書いておきます。


■ Opusとは
「OggOpus」といっても間違いではなくて、「OggVorbis」の後継フォーマットにあたります。

Vorbisと比較した時のメリット
・圧縮効率がやや高い
・低ビットレートでも高い音質を保つ (サイズ比ではこれが大きい)
・低レイテンシ (発音までの遅延が短い)

デメリット
・デコードがどうやら重い(後述)

詳細はググると色々出てきます。
・wikipedia
・modest - Firefox Beta 15 でサポートされる Opus オーディオ形式


■ 実装
OggVorbisの後継だけあって、ほぼ同じ流れで対応できます。
Vorbisの実装は調べると色々詳しいページが出てきますので、
ここではVorbisに対応済みのとこから拡張する想定で違いなどを書いていきます。


──── ライブラリ準備 ────
Ogg
「libogg_static.lib」 が要ります。

Opus
「opus-tools」 「opusfile」 「libopus」 が必要。
opus-tools … エンコーダなど付いてくるので、Opusデータを作るのに必要。
libopus … 「celt.lib」 「opus.lib」 「silk_common.lib」 は少なくとも必要。
opusfile … 「opusfile.lib」 が必要。


──── 実装 ────
・まずファイルコールバックを登録してオープン。
	s32	err=0;
    OpusFileCallbacks	opusCB = { readCB, seekCB, tellCB, closeCB };
	OggOpusFile*	pOpusfile = op_open_callbacks( this, &opusCB, NULL, 0, &err );
なぜか tell と close の順番が逆になってる。
// ---------------------------------------------
//! @brief  Opusfileコールバック(ファイル読み込み)
//! @param  pSource	[in]	ファイルハンドル
//! @param  pPtr	[i/o]	読み取ったデータのコピー先
//! @param  nBytes	[in]	読み取るサイズ	[byte]
//! @return 実際に読み取った回数
// ---------------------------------------------
s32 SoundDecoderOpus::readCB( void *pSource, u8 *pPtr, s32 nBytes )
{
	DWORD	uRet = 0;
	ReadFile( (HANDLE)pSource, pPtr, (DWORD)nBytes, &uRet, NULL );
	return uRet;
}

// ---------------------------------------------
//! @brief  Opusfileコールバック(ファイルシーク)
//! @param  pSource	[in]	ファイルハンドル
//! @param  offset	[in]	オフセット移動量	[byte]
//! @param  whence	[in]	移動前の位置
//! @return オフセット移動後のポインタ
// ---------------------------------------------
s32 SoundDecoderOpus::seekCB( void* pSource, opus_int64 uOfs, s32 nWhence )
{
	DWORD	result;
	switch( nWhence ) {
		case SEEK_CUR:	result = SetFilePointer( (HANDLE)pSource, (long)uOfs, NULL, FILE_CURRENT );	break;
		case SEEK_END:	result = SetFilePointer( (HANDLE)pSource, (long)uOfs, NULL, FILE_END );		break;
		case SEEK_SET:	result = SetFilePointer( (HANDLE)pSource, (long)uOfs, NULL, FILE_BEGIN );	break;
		default:	return -1;
	}
	return (result == 0xffffffff) ? -1 : 0;
}

// ---------------------------------------------
//! @brief  Opusfileコールバック(ファイルクローズ)
//! @param  pSource	[in]	ファイルハンドル
//! @return 正常なら0, 不正ならEOF
// ---------------------------------------------
s32 SoundDecoderOpus::closeCB( void* pSource )
{
	BOOL result = CloseHandle( (HANDLE)pSource );
	return result ? 0 : EOF;
}

// ---------------------------------------------
//! @brief  Opusfileコールバック(現在位置取得)
//! @param  pSource	[in]	ファイルハンドル
//! @return 正常なら現在位置, 不正なら-1
// ---------------------------------------------
long long SoundDecoderOpus::tellCB( void* pSource )
{
	u32	offset = SetFilePointer( (HANDLE)pSource, 0, NULL, FILE_CURRENT );
	return offset;
}
独自部分を掲載用にちょっと書き換えたのでもしかしたら怪しいかも。

コールバックの中身は大体Vorbisと同じですが、
read で読み取りサイズと読み取り回数が分かれてたのが、読み取りサイズのみに統合されてます。


・波形フォーマットの取得
	//! Opus情報
	const OpusHead*	pOH = op_head( pOpusfile, -1 );
	if( !pOH )
		return false;

	//!	WAVEフォーマット初期化		
	ZeroMemory( &mWfx, sizeof(WAVEFORMATEX) );
	mWfx.wFormatTag      = WAVE_FORMAT_PCM;
	mWfx.nChannels       = pOH->channel_count;	//!< チャンネル数
	mWfx.nSamplesPerSec  = 48000;				//!< サンプリングレート(Opusの出力は常に48khz)
	mWfx.wBitsPerSample  = 16;					//!< 量子化ビット数
	mWfx.nBlockAlign     = mWfx.nChannels * (mWfx.wBitsPerSample/8);
	mWfx.nAvgBytesPerSec = mWfx.nChannels * mWfx.nSamplesPerSec * mWfx.nBlockAlign;
	mInSamplingRate		 = pOH->input_sample_rate;
出力のサンプリングレートは常に48khzになる。
入力と同一にならないので注意。


・デコード
// ---------------------------------------------
//! @brief  デコード
//! @param  pDst		[i/o]	転送先
//! @param  uSize		[in]	読み込むサイズ [byte]
//! @return READ_????
// ---------------------------------------------
u8 SoundDecoder::decode( u8* pDst, SIZE_T uSize )
{
	u8*		pDstPtr	= pDst;

	//!	byte → sample
	SIZE_T	uRemain = uSize / (mWfx.wBitsPerSample/8) / mWfx.nChannels;
	uRemain = (uRemain >> 1) << 1;	//!< 偶数変換

	while( uRemain > 0 ){
		//!	読み込み
		long	nActualRead = op_read( mpOpusfile, (opus_int16*)pDstPtr, uRemain, NULL );

		//!	終端チェック
		if( nActualRead <= 0 ){
			ZeroMemory( pDstPtr, uRemain );	//!< 無音データで埋める
			return READ_END;
		}

		uRemain -= nActualRead * mWfx.nChannels;
		pDstPtr += nActualRead * sizeof(opus_int16);
	}
	return READ_OK;
}
ここが少々面倒なのですが、Vorbisのデコードはバイト単位なんですが、
Opusはサンプル単位なので変換なりなんなりが要ります。
あとPCMのサイズがVorbisは多分1バイトだと思うんですが、Opusは標準2バイトです(opus_int16の部分)。
float版もあるので、そちらを使うと4バイト。
この辺り動作見ながら適当にやってしまったのでちゃんと理解してません! いい感じにしてください!


・終了処理
op_free() を呼んでおしまい。


長々書きましたが、吉里吉里ZにOpus対応されてます。
ソースも公開されてるので、そちらを見るとよろしいかと…。


■ 使用感
まず音質の話から。
この形式は楽曲とボイスに最適化されて作られているそうで、
低ビットレートでもかなり聞ける音質に仕上がります。

64kbpsで割と妥当な状態で、96kbpsあれば違いが分からないレベル。
32kbpsだと流石に…とは思ったのですが、
色々鳴ってるゲーム中なら案外気にならないかもしれんという感じで
ものによっては正直いけるかもしれんと思いました。

アスタブリードのラスボスBGM(3分27秒)での容量比較。
同BitRateでは圧縮効率にはあまり差がないんですが、
妥当なBitRateのラインが落ちてると思われるのでその差があるかなと。
FormatBitrateSize
Ogg(Vorbis)160kbps4.00MB
Opus96kbps2.26MB

次にデコード負荷の話。
ストリーム再生時のデコード負荷はXAudio2のプロファイラによると
Opusの方がOggの約4倍かかってるんですけど、
ゲームの処理負荷から考えるとそんなの大したことないというオチはあり得ます。

うちのライブラリだとオンメモリサウンドはロード時にデコードという仕様になっているのですが、
3秒のボイスを128個ロード + デコードさせてみた比較が以下です。
FormatBitRateロードデコード
Ogg(Vorbis)128kbps0.23秒2.77秒
Opus64kbps0.06秒2.12秒
意外にもOpusの方が早くなりました。なんで?
ロードめっちゃかかりそうだから採用はないかな…って思ってたけど、検証してみるもんですね。


■ 結論
ゲームサウンドならADXが最強。/(^o^)\
  1. 2014/03/31(月) 14:55:28|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

えーでるわいすえへくと2

エフェクトシステム作り直しております。

またかよ!みたいな印象あるかもしれませんが、
エフェクトシステムは何気にフリージアさんの最初期に作ったもので、
えーでるわいすエンジンの中でも最古参のプログラムの一つです。

ほぼ全編にわたってC言語で書かれており、
色々と不便で色々と不便なのでうぎーってなってたんですが、
ここに手を入れるとさすがに大掛かりすぎるということで、
アスタではあえて見て見ぬフリをして過ごしました。

まぁもう限界!なので、やるなら今このタイミングしかあるまいということで
重い腰を上げて作り直しております。

動作自体は割と揃ってきたんですけど、実行画面だと違いが分からない
(というより基本的に同じになるべき)のでもにょってますが。
内部結構変わってるんですよ!
結構細かい単位で並列スレッド更新になってたり、
固定パイプライン廃止してシェーダー描画統一されてたり、
ドローコールが減る様な修正入ってたりします。

普段プログラム嫌い嫌い言ってる割には
こういうとこいじって気持ちよくなってる辺り、
実はちょっと好きなのかもしれない。でもネットワークだけは勘弁な!

あとホントに初期に作ったとことかは3D計算よく分かってなかったので
なんか出し方によって座標ズレたり回転軸おかしくなったりしてたんですけど、
全体的に見直して、ちゃんと動く様になってると思う。多分。

びりびり
こいつは大幅に作り直したら見た目結構変わったので、
こりゃいいやとブログ更新ネタに利用するのであった。


枝分かれは前々からやりたかったんですけど、
スーパーめんどくさいので毎回断念してましたが今回やっと実装できました。

代わりに“うねり”を廃止。むっさ重くなる割に期待した効果が出なかった。
“うねり”はレイクライシスのWR-02の雷を目指してたんですが、
あんなにカッコ良くなんないですね。どういうことや!説明せえ!


うちのエフェクトシステムのコンセプトは新旧変わらず、
「簡単なものを簡単に出す」です。
正直びっくりするくらい簡単なことしかできません。

自由度を上げすぎると簡単なものを出すのにもやたら手間がかかったりするので、
どうせ量産するのも僕なんで、僕が必要なものに特化して用意しています。
↑の放電なんかは正にそれで、放電!とか火花!とか
用途に応じたプリミティブタイプをいくつか用意してるという形。
選べばそれっぽいものがとりあえず出ます。
テクスチャ描くの嫌いなんで、なるべく頂点カラーだけでも頑張れる様に。
モデルは一切使えない!(作れないし)

本職のデザイナーさんには使い物にならないだろうけど、
そこそこの品質で良ければ生産性も鑑みると悪くないんじゃないかなーとか。

気持ち的には公開もしてもいいと思ってるんですけど、
例によってエンジンとの依存が強すぎてお手上げ。
今はEffekseerもあるしなーと。色んな人が使う分には確実にあちらの方が優れてるし。

オープンソース化ってちょっと憧れるんですけど、
何からしていいのかさっぱり分からんし、
おそらくその作業そのものは僕が嫌いな種類のものな気がするw
  1. 2014/03/18(火) 17:09:45|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:5

かいはつにっきに戻る時だ

一度途切れると中々ちょっとしたネタ程度だと書きづらくなるもんですね…。
そろそろいい加減平常運転に戻すべきだろうということで、
ぐだぐだ開発日記でも書いてまいります。

アスタブリード関連はまだちょこちょこ作業してますが、
それと平行して新作も進めています。
まだシステムの根っこの根っこを整理している段階ですが。

フリージアの初期から使い続けてきたライブラリというのが残ってて
C言語で書かれてるとことかあるんで、根絶しなくてはならない。
と思い立ってはや6年くらい。立派な老害同人おじさん。

算術とか色とかクラスに置き換えるのは中々の地獄的作業でした…はい…。

ついでにコアモジュールという単位まで切り分けられると
下のモジュールが独立するんで、
やりたいと思いつつやれてないサウンドエンジン公開とかできるんですけど
めんどくさい。めんどくさい。はや4年くらい。

しばらくは見て面白い様な内容の日記にならなそうですけど、
更新無いよりはマシだろうの精神で適当につぶやいて参りますです。
  1. 2014/02/20(木) 16:40:03|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:0

アスタブリードDL版はじまりました

■ PlayismさんでアスタブリードのDL販売が始まったみたいです。
Playism_Banner.png


DL版とパッケージ版はゲーム内容に違いはありません。
価格が¥2000とパッケ版よりお得ですが、サントラが含まれません。

ちなみにサントラについて、ゲーム中のBGMと何か違うの?って聞かれたんですけど、
サントラはサントラ用にマスタリングしてあります。

ゲーム中のBGMはSEやボイスなどが同時に鳴ることを想定して
音量とか細かいところを落としてあったりするのですが、
サントラはBGM単体でベストに聴ける様に調整されているということです。
あとはゲーム中は圧縮音源での再生ですが、サントラは非圧縮です。
(ここは常人には違いが分からないレベルだと思いますが)

在庫に苦しむ同人屋さんとしては、パッケ版を推していきたい


さておき、今回はDL販売をほとんど発売と同時に始めてみました。
展開については色々考えてる様で実は何も考えてないんですけど、
「パッケージ版を豪華仕様にして生産数絞るかわりにすぐDL版始めるということは、
 もうDLをメインに考えているということですよね?」
と人からツッコまれて、ああなるほど、そうだったのか!って思いました。

なんか、こう、なんとなくやってるんですよね。なんでも。
ツッコまれて、なるほど!って思うことが最近多いです。
いや、昔からなのかもしれない。前まではツッコまれもしなかっただけで。

理論固まってる方が人と会話したり説明する時有利なのでそうしたいんですが…。
「わかんないっす」「なんとなくっす」って返すしかなくて困るます。

どうでもいい話になってしまった。
アスタについてはバグ修正もやりつつやっと落ち着いてきたところなので、
次回作の企画も進めております。
今度は、そうですね。半年で完成予定ですかね!!
  1. 2014/01/17(金) 18:20:54|
  2. 自作自演|
  3. トラックバック:0|
  4. コメント:3
次のページ Map
TweetsWind
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。