『Ｌｉｇｈｔ　Ｗｏｒｋｓ』

仕事とは関係無いのですけど、悪友に薦められてマイクラ時々やってます。
で、彼が大量に火薬が欲しいと言うことで作りました。
このくらいならネットで調べれば簡単に作れるはずなんですけど……
たいしたMODでも無いので、ガラクタ置き場においておきます。
こちらからどうぞ。

《火薬６４個》
炭炭炭
赤金赤
炭炭炭

炭……木炭・石炭
赤……レッドストーン鉱石
金……金ブロック

金ブロックは、作ってくれる見えない妖精さんへの手数料と言う事で。
金塊９個で１ブロックなのでコスト的に少し高めです。
とはいえ、レアではあってもあまり使い道の無い金の消費には丁度良いかも知れません。
また注意はレッドストーン鉱石です。
鉱石の方なので、シルクタッチのつるはしが必要です。
一応救済として

《レッドストーン鉱石１個》
赤赤赤
赤赤赤
赤赤赤

赤……レッドストーン

で、鉱石に戻す事が出来るようにしてます。
しかし当然ですが鉱石を割れば２～３個程度しかRSを入手出来ませんので、作成するよりつるはしで掘った方がコストパフォーマンスは高いです。

《粘土８個》
土土土
土水土
土土土

土……土（※芝ブロックは不可）
水……水バケツ（作成後バケツはインベントリへ）

こちらはコストこそタダ同然ですが、地味ーーにスタック不可な水が面倒臭いレシピです。

火薬も粘度も一応バランスクラッシャーにならないようには調整したつもりなのですが、火薬６４個は流石に大過ぎるかなとも思ってます。

今回はちょっと脱線して、某所に少し書き込みがありましたのでperlの正規表現のお話です。
perlなんか関係ないだろと思われる方もいらっしゃると思いますが、正規表現はPOSIXに準拠しておりperlもTJSもほぼ一緒です。
これを覚えてると、ライター兼スクリプターとしては検索や置換が劇的に効率良くなります。

前置きはこのくらいにして、今回問題はこれです。

$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

html側からformで送られて来たデータをデコードする部分です。
これはcgiを作ろうとするとまず最初に躓くところですね。
私もこれを完全に理解するのに２日かかりました。　理解するとどうと言う事も無い事なのですが。

例えばこんな文字列

これは テストだよ

これをformで受け渡しすると・・・・・

%82%B1%82%EA%82%CD+%83e%83X%83g%82%BE%82%E6

こう言う文字列になります。この法則は以下の通りです。
●ルール１　半角英数文字『*-.@_』はそのまま表記。
●ルール２　半角スペースは『+』に変換される。
●ル＾ル３　半角表示のその他の記号は『%+2桁の16進1バイト』で表現される。
●ルール４　全角文字は『%+2桁の16進の2バイト』で表現される。

あと全角カタカナひらがなの一部に、２バイト目にアルファベットを使うと言う特殊なルールがあります。（今回の例では『テスト』）
これに関しては、なぜそうなのかは”2バイト文字”等を検索してください。
またJISの場合にはまた少し違ったルールがあったりしますが、日本の場合SHIFT-JISかUTF-8が多いのであまり気にしなくても良いと思います。

まず$value =~ tr/+/ /;は問題無く理解出来るかと思います。
文字+をまず半角スペースにデコードしています。
問題は次の行かと思いますが、これは動きを順番に追って行くと理解しやすいかと思います。
まずは以下の式を観てください。

$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/$1/g;

これを実行すると、

82B182EA82CD 83e83X83g82BE82E6

となります。

これは単純に結果だけを見ると%を取り除いた処理……と見えますが、実はここを理解出来ればほぼ８割理解したも同然です。
この書式は%の文字の後にアルファベットの大文字か小文字のA～F・もしくは数字一桁が2回連続して現れたらその３桁のうち先頭の%を取り除いて、その条件にあてはまらなかったものはそのままで文字列を組み直せと言う命令です。
なので処理されたのは赤い部分です。

%82%B1%82%EA%82%CD %83e%83X%83g%82%BE%82%E6

単純に%を取りのぞくだけなら$value =~ s/%//g;で済みます。
最後のgは、マッチしても（条件を満たした部分を見つけても）文字列の最後まで何度でも繰り返し処理を行えと言う命令です。
$1と言うのは、s/～/に挟まれた部分にマッチした部分の文字列（ただしこの場合は%は()の外にあるので()の中のマッチしたアルファベット・数字の部分だけの文字列）を指し示す変数（代名詞）です。
なのでマッチしなかった部分は$1には代入されません。この表現式では処理外として、そのままただ文字列の並び通りにくっつけられます。（←こことても重要）
eとかXとかgとかがそのまま何事もなかったかのようにくっついてるのが見て取れます。
ここまで理解出来れば、もうほぼ分かったも同然です。

次に第二段階の数式です。

$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/hex($1)/eg;

hex()と言うのは、中の数字を10進数にする関数です。
出力された結果は以下のものに変化します。

130177130234130205 131e131X131g130190130230

先頭の%82%B1を見ると130177と変換されてるのがわかると思います。
/eは、変換側を数式と解釈すると言う意味です。　意味が分からなければeを外して見ると一目瞭然です。

最後に、

$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;

ここまで来れば簡単と思います。
$1の２桁の16進数表記の文字列としてマッチした部分を次々と1バイトコードに書き換えてます。（マッチしなかった部分は何もせずそのままくっつける）
あとはそれをHTMLでSHIFT-JIS形式で読めば、『これは テストだよ』と表示されます。

さてこの二段階目・三段階目で重要なのは、%82%B1....と言う文字列を見つけたら、まず82B1....と言う処理をしてから次に130177....に変換してるのでは無いと言う事です。
%82を見つけたら、%82＞82＞130＞130に対応する1バイトコードに変換して次に%B1を……と１回のマッチ毎にデコード処理をして次に進んでると言う事です。
一見当たり前の事を言ってるようですが、ここを理解してないと初心者はハマります。
「正規表現はパズルを組むようなもの」と言う人もいますがまさにその通りで、時にこれ以外には表現式はあり得ないと言うものが存在します。
この文字のデコード用の式もそうで、これをわかりやすくしようといくつかの式に分解しようとするとする恐ろしくハマります。と言うかハマりました。
だからどのサイトでもこの表現式しか書かれてないのですが、perlにとっては正規表現に関する部分が最も奥が深く難解で、それを最も端的に表す美しい式がこの式で、同時に初心者に最初に鉄壁の壁として立ち塞がるのがこの式だったりします。
私もそれ程正規表現は詳しい方ではありませんが、経験則ではこれを理解したおかげで一気にperlを理解出来たような気がします。
なので、この表現式を目当てに来られた方は、頑張って読み解いてください。

今回はゲーム中の演出のお話です。

ここ最近で一番自分にプラスになった出来事は、某社様に朝でも夜中でも自由に出入りさせて頂いた事でした。
週に何度も、仕事が終わるととりあえず打ち合わせ等も兼ねてお伺いして、そこの社長様とご迷惑とわかりつつ数時間色々なお話をさせて頂いておりました。

そこで良く演出のお話もさせて頂いてのですが、「意味の無い演出はダメだよね」と言うお話をよくさせて頂いてました。
これはどう言う事かと言いますと、これは私の個人的な見解なのですが。
最近はマシンスペックが上がり映画的な演出が出来るようになった事に加え、ゲームのネタとしては出尽くしてしまっているので、残るは演出で差別化していくくらいしか差別化は難しいだろうと言うのは確かにそうなんだろうと思います。
確かに同じソフトを作るなら、演出が入ってないより入ってる方が見栄えは良いと思います。
ただそれを自社の技術力を見せるためだけの力業で無意味な演出をしても、それはただのオナニーでしか無い。
はっきり言えば、エロシーンで変なゴテゴテした演出入れても萎えるだけ。いっそただ紙芝居にした方がユーザーは喜ぶ……と言う事です。

私から見て、「これどうやって動かしてんだろ。すごいな」と思うものは最近結構あります。
でもそれが＝ゲームのおもしろさに直結してるのか？と考えるとかなり疑問符なものも結構あります。
掴みとして演出を入れる。時間経過をユーザーに知覚させるために演出を入れる。このイベントで大きく物語りが動くからその予兆として演出を入れる。”話として”クライマックスだから演出を入れる。
……このくらいで良いような気がします。
演出と言うのは、知覚的にどうしても動的なものになりまうので頻繁にそう言うものが入ってるとウザくてしょうがありません。
別の会社の社長様でしたが「立ち絵が動くと視点が変わるのがウザイから、表情だけでポーズを変える事はしたくない」とおっしゃられる方もいらっしゃいました。
これは極端な例かも知れませんが、確かにチャカチャカキャラが動くとシナリオに集中出来ないと言うのも事実です。
シナリオが避ければ演出はいらない。絵もいらないとはエロゲ屋としては言ってはならない事かも知れませんが、そうおっしゃられる方すら結構この業界いらっしゃいます。

演出家としては、自戒として出来るだけ『演出を入れない演出』を心がけないといけませんね。

なかなか更新出来ない間に、エンジンを二つ覚えたり、シナリオやったり、ぶっ倒れたりと去年は波瀾万丈な一年でした。
うまく行ったお仕事もあれば、ご迷惑をおかけした仕事もあったりと、結局年間通したらプラマイゼロだったかなと言う感じですが、スキルだけはもりもりレベルアップしてます。

ブログの方は、ちょっとまだ体調も良くないのですが仕事も一段落したのでまた次の次のお仕事を模索しつつのんびり更新して行こうかと思ってます。

外注でライター＆スクリプターをやってて一番大変なのは、色々なエンジンのコマンドタグややれる事やれない事がごちゃごちゃになってしまって、いざその時になって初めて「あっ、このエンジンじゃこれ出来ないんだっけ」と思う事が結構あります。
特にエフェクトやレイヤー周りはそう言う事が多く、そのあたりが特にエンジンそれぞれにクセが強く表れやすいところで、結構致命的になったりしやすい部分です。

なので私は一度覚えたエンジンも、次のエンジンを覚えたらとりあえず忘れるようにしてます。
忘れると言っても、数ヶ月苦労して覚えたエンジンはそうそう簡単には忘れませんので、記憶の奥底に地層みたいに圧縮されて残しておいて、いざ必要になったらまたエンジンのリファレンスを数日掛けて読み直して思い出す……と言う感じで作業してます。
そうしないと、似たようなコマンドだと結構気をつけてても間違った名前を書いたりします。
たとえばメッセージ枠の文字列をクリアする命令で、/clsとか/clearとか/cとか先頭文字（呼び方があったと思うけど思い出せない）も\cとか^cとか$cとか、吉里吉里みたいに複数の言語を同時に使うタイプのエンジンだとそう言うミスが結構多くなってしまいます。

基本のタグだと思ってもエンジンによって微妙に違ったり、ほんの些細な事ですけどそれがバグの元なので結構気を遣ってしまいます。
ゲームのバグのほとんどはスクリプトを組む人間の責任になるので、時間が無い中でこう言う勘違いが起きると致命的だったりもします。

最近バタバタ忙しくて更新出来ずに申し訳ありません。
お仕事があるのは良い事なのですが、気がついたら一月以上更新してなかったですね。

一応ネタはいくつかあるのですが、動画作ってるヒマが無くてうーむと唸ってます。
勉強させて頂いてる中で、結構良い演出とかあるんですよね。
それをなんとか木里木里で再現してみようとか考えたりはしてます。
あと三角関数の話とかも補足しておかないと、知り合いになんであんな動きになるんだと突っ込まれましたのでそれも後ほど。

映画も書きたいネタがたくさんあります。
そういえば金曜ロードショーでジブリ特集やってましたね。
今観ても「海がきこえる」の物語の完成度の高さには唸ります。
海がきこえるは日テレ開局４０周年記念作品で、ＣＭのたびに同じジブリ制作の「そらいろのたね」が放映されてとても雰囲気が良く今でもはっきりと覚えてます。

ところでこの夏は節電とか。
九州は今年は暑いっぽいのですけど、なんとかして欲しいなと思う今日この頃。
私は消極的原子力推進派（低コストで安全な代替エネルギーないからしょうがないじゃん派）なので、とっとと原子力稼働させてくださいと思うばかり。
そういえばどこかで面白い記事を見かけました。
なんでも原子力反対してる人と民主党に投票した人・支持した企業団体が日本が原子力に依存してた分節電すれば残りの人たちは少なくともこの夏は従来通り過ごせるとか。
ゲーム屋は電力なかったら仕事になりませんので、是非そうしてほしいものです。

２つ前のモーフィングで少しお話しをしましたが、そもそもperspective.dllの使い方がわからん！と知り合いに突っ込まれましたので、最低限の書式についてです。
ちなみにパースペクティブって何？って人はググって下さい。
ぶっちゃけこれ単体ではほとんど使い道ありません。むしろこう言う使い方ありそうって言うのがありましたらお教え下さい。試してみたいです。
何かと組み合わせて始めて劇的な効果を現すタイプのものなので、無くてもそんなに困る事は無いでしょう。

では準備です。

１．吉里吉里以外では”perspective.dll”が必要です。
　　吉里吉里関連サイトのどっかにあります。あまり不用意にURLを貼れませんので探してください。たぶんすぐ見つかります。

２．startup.tjsの上の方に　Plugins.link("perspective.dll");　と書く。
　　サブフォルダに置いた場合、プロジェクトフォルダの下からのパスを通す事。

これで準備完了です。

このdllがいったいどう言うdllかと言うと、特定のレイヤーの画像を特定のレイヤーにパースペクティブ”的”変形をさせて表示すると言う物です。
パースペクティブを日本語に訳すのはかなり意味合いにブレがあるので難しいのですがまぁそう言う事です。

でこのdllの使い方をいくつかの解説サイトで覗くと

@macro name=perspectivecopy
@eval exp="kag.getLayerFromElm(mp,'dest').perspectiveCopy(kag.getLayerFromElm(mp,'src'),+mp.left,+mp.top,+mp.width,+mp.height,+mp.x1,+mp.y1,+mp.x2,+mp.y2,+mp.x3,+mp.y3,+mp.x4,+mp.y4)"
@endmacro

……みたいに書かれてます。
今回の参照はOUTFOCUSさんのperspective.dllに関する記述からです。いつも大変お世話になっております。

これをTJSで使用するように解読すると……

kag.getLayerFromElm(%['layer'=>'layer_dest', 'page'=>'page_dest','prefix'=>'dest']).perspectiveCopy(kag.getLayerFromElm(%['layer'=>'layer_src', 'page'=>'page_src','prefix'=>'src']),left,top,width,height,x1,y1,x2,y2,x3,y3,x4,y4)

layer_dest = コピー先レイヤーno
page_dest = コピー先ページ　fore/back
layer_src = コピー元レイヤーno
page_src = コピー元ページ　fore/back
left = ソースの基点座標Ｘ(通常0）
top = ソースの基点座標Ｙ(通常0)
width = ソースの基点座標から数えた幅
height = ソースの基点座標から数えた高さ
x1 = コピー先の基点座標Ｘ
y1 = コピー先の基点座標Ｙ
x2 = コピー先の右上座標Ｘ
y2 = コピー先の右上座標Ｙ
x3 = コピー先の左下座標Ｘ
y3 = コピー先の左下座標Ｙ
x4 = コピー先の右下座標Ｘ
y4 = コピー先の右下座標Ｙ

こんな感じです。あとはそれぞれの数値を入れ込むと遠近法のように画像が変形します。

最初にお詫びです。　上のニコ動の動画はどうレートを下げてもビットレートオーバーになってしまいましたので、極端に画質を落としてようやくアップ成功したもので非常に見づらいです。
こう言う単純な不連続なノイズ画面が一番エンコに負担が掛かるのは理解してましたが、案の定でした。Orz

アナログＴＶの砂嵐です。
無いと微妙に困ったりするのでちょっと作ってみたのですが、よく考えると地デジになるとこれもなくなっちゃうのでしょうか。
子供の頃、この砂嵐から必死に宇宙人のメッセージを読み取ろうとしたのは、きっと私だけでは無いはず。
ちなみにこれはVHF域の砂嵐です。
個人的にはUHF域の砂嵐が品があるように思うのですが……物語は関東圏で進行する事が多いのでVHFじゃないとダメと言う理由からVHF域の砂嵐です。
VHF域は帯域が狭い上に、最近のテレビは高性能で、”意味のある波形に修正しようとする”機能があるのでこんな感じの黒っぽい何かの模様のような感じになってしまいます。
そのあたりの事は、昔ＮＨＫ教育で数学の秋山先生がその基礎理論をわかりやすく解説してくれてたのですが、ちょっと忘れてしまいました。

この砂嵐、ＡＥで作ったものです。
こう言うノイズや水の流れのようなカオス理論に基づいた連続体を嘘臭く無く作るのは、ＡＥに限らず非常に難しいですね。（テレビのノイズもある意味複雑な因子が色々絡み合ってると見なせます）
なのでそれっぽく作る一番良い方法は、ＰＣ（ソフト）に任せて出来るだけ人間は触らないと言う事が究極的な感じじゃないかと思います。

吉里吉里の動画用に最適化した物はコチラです。
10秒ループ素材ですが、画像それぞれには連続性が無いので適当にぶった切って短くして使われても特に問題無いと思います。
ほとんど需要無いと思いますが、良かったら使ってやってください。

某所で話題を振られましたので、お返事です。
モーフィングは実は以前に考えてかなりネットで調べたのですが、良くわかりませんでした。
実現したいとは考えてますが、具体的にはメッシュワープかペジェワープあたりのわかりやすい解説サイトでも見つけないと難しいかなと思ってます。
ご存じの方がいらっしゃいましたら、そのあたりの解説サイトをお教え下さい。　お願いします。
サイドインマクロに組み込むのであれば、単純にperspectivecopy.dllを組み込めば良いかと思ってはいるのですが静止画ならともかく動的な物には流石に重たいようです。　これに関しては具体的な検証が済んだらご報告します。
吉里吉里では無いのですが、パースペクティブを組み込んだフェードを取り入れてらっしゃる会社もあり、すごいなと眺めること頻り。　事実、見栄えが良いんですよね……
ほんのちょっとした部分なのですけど、そこを適当にこれで良しとするかある程度こだわるかの差がクオリティの差だよなぁっと最近つとに感じます。

一枚画へのモーフィングに関してはたぶんパーツをＡＥ出力のパラパラアニメで持って、それを総合的に管理するオブジェクトを組む方がうちのレベル的に現実的かなと考えてます。
Ｍ２さんのモーフィングはそれを演算で行ってらっしゃるようで高い技術力は流石と言うところですね。
ところで昔からあるツールですが、ynwさんのXX-CAKE!も上手く使えばかなり良い感じなので上手く使えないかと思案中です。
ぷるんぷるん動かす事に関しては、ＡＥで作るより使いやすくまた微調整が容易で非常に便利です。　使いどころが激しく限定されそうですが。

　　／⌒ヽ
　く/･〝　⌒ヽ
　 |　3　(∪￣]
　く､･〟 (∩￣]

ちょっとかわいいAAだったのでコピってみました。

以前のエントリーでスクリプトによる擬似的な奥行きを持たせる動画をアップしましたので、今回はそれと対になる動画による奥行き表現のテストです。
ここまでいくと演出と言うよりは手品とか大道芸に近い物で、「そこまでこだわってアホちゃうか」と言われれば素直にアホですと答えますOrz

たぶん勘の良い方はすでにピンと来られてると思いますが、立ちキャラの前後を★のパーティクルの動画で挟んだだけです。
なので、吉里吉里と言うよりはAEの領分の作業が大部分を占めます。　と言うより、ハッキリ言ってしまえばparticularのみで作成してます。
★のパーティクルは本当はポリゴンにしたくて、過去に使っていたShadeと3ds maxの体験版をDLして使ってみたのですが……かんっぺきに忘却の彼方でしたOrz
近いうちにヒマを見て覚え直します。
ここでは公開してないのですが、前々から羽根が降ってくるループ素材とかせっせと作ってまして、それが落下時の質量的な部分や羽根自体の柔らかさとか今現在2Dからの表現に限界を感じてまして、やはりポリゴンで作るしか無いかと考えているところです。
まぁこんなアホな事に力を入れてるシナリオライターとか日本中探してもうちだけだと思いますので、ご覧頂けてる方は気長におつきあいください。

《星空０４》
とりあえずの完成形です。
一見バージョン０３と大して変わらないように見えますが、根本から全て新しく作り直しています。
星のレイヤーは７枚重ね、さらにそれをレイヤーモードを変えて二重に重ねています。（実際にはループ素材にするために１つの星レイヤーを３枚重ねしてますので星レイヤーだけで４２枚重なってます）
また大気の揺らぎを入れたり、チリの表現を入れたり、球面収差を強めに加えたりしてみました。
その上で、そのままだと見栄えが悪いので少しアニメ的な星の動きを入れてあります。
結果、バージョン０３同様フル動画になってしまいましたOrz
複雑にレイヤーモードを重ねてますので、星の部分と背景部分に分解して別々に再生するとこの動画とは違う印象の動画になってしまいます。

今回はAEの機能のみでの作成で、PS等の外部アプリは使用していません。
Particularも今回は使用していません。
理由はチリの表現のように明滅させるのは、明滅の為にキーを打つか動画としてパーティクルを設定するしか無いので面倒だったのと、高性能なだけにそれなりに重いプラグインなので大量に使うには向かないからです。
試してませんが、４２枚も重ねたらたぶんうちのマシンでもフリーズするかも知れません。それこそ専門でAEに特化したマシンじゃないときつい処理です。
AEは、昔ほどではありませんがちょっと重い処理や複雑な処理をすると今でも結構普通に落ちます。
そりゃもう、これオープンβじゃないよね？と言いたくなる程落ちます。
あまりにも落ちるので、不正落ちの直前にデータを「一度だけ保存するチャンス」を与えると言うトンデモ回避策が組み込まれた程です。
なので、出来るだけ軽く作る事も重要になってきます。
それでもおそらく一昔前なら、これはレンダに半日掛かる程重たい処理で、それをわずか数分で出来てしまうマシンの性能の向上には目を見張ります。

《追記　110508》
ちょっと言葉足らずと勘違いがあったので追記。
明滅のキーをOver Lifeに打つと、出力が最初の0フレーム1回限りのために同じレイヤー上での出力された粒子の明滅のパターンが一緒になってしまいます。
これを回避するためには、粒子の明滅を動画で持ち、Particle TypeをSpriteでやれば回避出来るのですが、粒子を動画で持つとかなり重くなります。　粒子の動画を作るのも面倒でした。

勘違いは、1つのフッテージに設定したエフェクトを複数のコンポで使っても、フッテージの出力は一度だけ行われそれを使い回すようです。
当然ですよね。一々呼ばれる度に演算してたら、マシンパワーいくらあっても足りないOrz

ちょっと最近いくつか星空を作成してました。
子供の頃に観た宇宙戦艦ヤマトの劇場版の圧倒的な宇宙描写が頭の中にあるせいでしょうか。
どう作っても納得行かないですね。
やはり手描きは偉大です。逆立ちしても敵いません。

星空動画の自分ルールは、ゲームに使う為ですのでメモリをあまり喰わないループ素材として作る事としてます。
そこを気にしなければもっと綺麗に作れるのですが、ループにすると色々と弊害が出て厳しいです。



《星空０１》
これは雪の表現の時に作った物です。中央に天の川的な表現も入れてみました。
星は４枚に分けて移動率を奧のレイヤーほど緩やかにしてあります。
ニコ動だと画面が小さく潰れてしまって逆に良い感じなのですが、実際の画像では奧の光点がモロにドットっぽくてのっぺりと見えてしまいます。
ベースの、夜空の色ムラが平坦で一枚絵に見えてしまってます。


《星空０２》
これはアニメ的な感じにしようと色々と変えてみました。
一番大きなのは星にクロスラインを入れた事ですが、そのせいで夜のネオン街のような安っぽい雰囲気になってしまってます。
星自体も真っ白ではなく、どれも色を若干つけてあります。
背景の夜空の色ムラはp_lessを使ってじみーに動かしています。もちろんこれも上下をちゃんと繋いでループ素材になってます。
星のループが少し不味くて、時々二重に見えてしまってます。また星の動きは拡散方法へと変更して試してみましたが、やはり良い結果は得られないようです。


《星空０３》
０１と０２の問題点を踏まえて作ったのが、このバージョン０３です。
ベースの夜空に奥行きを持たせる事で全体的に立体感を表現しています。
また星自身をパーティクラーに変更してみましたが、これ自体はあまり効果に変化はありませんでした。
クロスラインを調整して短く設定して、星を４枚のレイヤーにわけてそれぞれ違う色を設定。
全体的には良い感じが出たのですが、やはり嘘臭さが抜けません。
一番手前の星のレイヤーが馴染んでませんね。
改良の余地大有りです。


星空のプラグインとか考えたりもしたのですが、ただランダム描写するだけならともかくそれをメモリに優しく綺麗に明滅させる方法が思いつかず断念。
画面に馴染むかどうかの問題もありますし、結局これは動画演出の真骨頂部分かなと思います。

side_in_outマクロです。
過去記事のシネスコ演出等で画面外からスライドするみたいにキャラがイン・アウトする演出をマクロ化しました。
難しい事は特別にありませんが、『TJSに挑戦！』様のeximage2・exmove2が必須です。
パッケージにはこの２つのksファイルは含んでいませんので、TJSに挑戦！様よりDLしてscenarioフォルダにでも入れてください。
と言うかこの２つは演出上必須なのでデフォで突っ込んどくと便利です。
うちなんかコレなかったら、演出の７割が使い物にならなくなります。

某所で、冒頭のメニューはどこのだ？と言う質問があったのですが、スミマセン、オリジナルです。
公開したくても、オブジェクトに変数では無く直接画像を組み込んでるので汎用性を持たせる為の手直しはちょっと途方に暮れそうな感じなので無理です。ゴメンなさい。