FFの２５周年記念資料集が出ているので買ったところ子供大百科みたいなすごいのが届いてビックリした。
ドラクエのやつは普通の冊子なのに
というわけでこの本にはプロの企画書が載っていて、すごく勉強になります
俺の書いてるメモと大差ねえじゃんっていうのから、没アイデア集を後のシリーズで拾ってたりする運用のうまさを感じるものまでまあいろいろというわけで創作意欲が湧いてきたわけですが数日で飽きましたね。
しかも２０周年でもなんか冊子出してたらしくていくら潰れそうだからって五年おきにあなた
http://www.nicovideo.jp/watch/sm9773605
ところでこれ見ておれもピコピコ音を自作してえ！と思って調べたんだけど
この人シンセは公開してくれてるけどソースは見せてくれない
うーんそのままつかってしまっては勉強にならん
http://www.hakkaku.net/series/java%E3%81%A7%E3%83%94%E3%82%B3%E3%83%94%E3%82%B3%E3%82%B7%E3%83%B3%E3%82%BB%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86%EF%BC%81
ここの通り進めていくとプーパー音は鳴らせるようになった。
が、midにあわせて鳴らすことは出来ない。
どうやらReceiverがmidimessageの発生タイミングで呼ばれるようなので、
そこで別の何かのスイッチを切り替えて、一定周期で更新を行うさらに別の何かが現在の状況に応じた音を上のサンプルのようにバッファに書き込んでやればよさそうなんだかさっぱりわからん
そこでGrevilというライブラリがソースを公開しているので見ていたところ、よく考えたらこれ使えばいいじゃんということになり
https://sites.google.com/site/niusounds/top/javadesaundofontowonarasu
こちらの通りにやってみたところなんとサウンドフォントが使えるようになったのだ
（ここのサイトは後日追記もあるのでそちらも参照）
ピコピコ音を鳴らそうとしていたはずが、SFCばり（スペック的にはそれ以上）の独自音源が実装されてしまったというわけである
ヒャダインも愛用のファミシンセとかから適当にピコピコ音サンプルってサウンドフォントを作る予定だ
そして今後スーファミ並みのゲームを作りたい時にもこの仕組みをそのまま使えるのだ
サウンドフォント作成という余計な仕事も増えたし、そもそも作るかどうか知らんが
あとこのライブラリのせいなのかどうかは不明だが、マスターボリュームをいじるとすごいノイジーな音になってしまう
レトロ音源ということでそう言う味として受け止めるべきか
そしてツクールでいうイベントの仕組みを作っていたのだが、
ツクールやウディタでブリブリやってる皆さんはご存じの通り、コモンイベント的なもの、ようするにイベントの命令部分だけで独立動作できるようにすれば、全ての画面で使えてしまうことを発見しました！
具体的にどういうことかというと、タイトル画面で今まではRGSSをパクってコマンドウィンドウを表示して、モードを管理して云々やっていたのだが、
タイトル画面にイベントを置いてやることで選択肢の処理と場所移動をするだけでタイトルが出来てしまったのである
まさにコロンブスの卵
ゲーム（特にRPG）って主に表示と選択肢と変数操作で出来ているから、そのへんがほとんどイベントで済んでしまうことになり、イベント命令さえ作ればどこでも応用できるというわけだ、イベント命令を作るのがたいへんだね。
そんな感じで気が向いた時だけ作り続けて早数年（全開のこのカテゴリの日記でワーイとか言って以降停止していた）ですが、今のところ何かが完成する予定はありませんのでご期待ください。
だいたいシステムができたところで素材を用意するのがしんどいよね
と真面目ぶることで各所より寄せられるネタ目線を頑強に跳ね返す作戦
ドラクエのやつは普通の冊子なのに
というわけでこの本にはプロの企画書が載っていて、すごく勉強になります
俺の書いてるメモと大差ねえじゃんっていうのから、没アイデア集を後のシリーズで拾ってたりする運用のうまさを感じるものまでまあいろいろというわけで創作意欲が湧いてきたわけですが数日で飽きましたね。
しかも２０周年でもなんか冊子出してたらしくていくら潰れそうだからって五年おきにあなた
http://www.nicovideo.jp/watch/sm9773605
ところでこれ見ておれもピコピコ音を自作してえ！と思って調べたんだけど
この人シンセは公開してくれてるけどソースは見せてくれない
うーんそのままつかってしまっては勉強にならん
http://www.hakkaku.net/series/java%E3%81%A7%E3%83%94%E3%82%B3%E3%83%94%E3%82%B3%E3%82%B7%E3%83%B3%E3%82%BB%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86%EF%BC%81
ここの通り進めていくとプーパー音は鳴らせるようになった。
が、midにあわせて鳴らすことは出来ない。
どうやらReceiverがmidimessageの発生タイミングで呼ばれるようなので、
そこで別の何かのスイッチを切り替えて、一定周期で更新を行うさらに別の何かが現在の状況に応じた音を上のサンプルのようにバッファに書き込んでやればよさそうなんだかさっぱりわからん
そこでGrevilというライブラリがソースを公開しているので見ていたところ、よく考えたらこれ使えばいいじゃんということになり
https://sites.google.com/site/niusounds/top/javadesaundofontowonarasu
こちらの通りにやってみたところなんとサウンドフォントが使えるようになったのだ
（ここのサイトは後日追記もあるのでそちらも参照）
ピコピコ音を鳴らそうとしていたはずが、SFCばり（スペック的にはそれ以上）の独自音源が実装されてしまったというわけである
ヒャダインも愛用のファミシンセとかから適当にピコピコ音サンプルってサウンドフォントを作る予定だ
そして今後スーファミ並みのゲームを作りたい時にもこの仕組みをそのまま使えるのだ
サウンドフォント作成という余計な仕事も増えたし、そもそも作るかどうか知らんが
あとこのライブラリのせいなのかどうかは不明だが、マスターボリュームをいじるとすごいノイジーな音になってしまう
レトロ音源ということでそう言う味として受け止めるべきか
そしてツクールでいうイベントの仕組みを作っていたのだが、
ツクールやウディタでブリブリやってる皆さんはご存じの通り、コモンイベント的なもの、ようするにイベントの命令部分だけで独立動作できるようにすれば、全ての画面で使えてしまうことを発見しました！
具体的にどういうことかというと、タイトル画面で今まではRGSSをパクってコマンドウィンドウを表示して、モードを管理して云々やっていたのだが、
タイトル画面にイベントを置いてやることで選択肢の処理と場所移動をするだけでタイトルが出来てしまったのである
まさにコロンブスの卵
ゲーム（特にRPG）って主に表示と選択肢と変数操作で出来ているから、そのへんがほとんどイベントで済んでしまうことになり、イベント命令さえ作ればどこでも応用できるというわけだ、イベント命令を作るのがたいへんだね。
そんな感じで気が向いた時だけ作り続けて早数年（全開のこのカテゴリの日記でワーイとか言って以降停止していた）ですが、今のところ何かが完成する予定はありませんのでご期待ください。
だいたいシステムができたところで素材を用意するのがしんどいよね
と真面目ぶることで各所より寄せられるネタ目線を頑強に跳ね返す作戦
とりあえずツクールVXAceに関してはスゲーと思う
「特徴」の汎用性が高すぎてヤバイ
これは面白ステート作りまくりだろ
体験版に付いてくるサンプル遊んだだけで特技の幅広さにワロタ
ボス用の消滅エフェクトとかもあるし
なにがAceだバカｗｗｗｗｗとか思ってたけどこれはすごいツクールだ
なお、皆さんお分かりの通りぼくはツクール大好きですが
これだけ完成できないことを考えると、どうもツクール形式の割と地道な開発は向いていないんじゃないかと思いまして
もっと革新的な（楽な）ツール作れねえかなあとか思いつつjavaでシコシコ作ってるわけです
（出来ることはどんどん凄くなっているが、UIはずっと一緒だし）
そんなわけでAceの購入はどうしようかなーと思ってるんですが
そういう好き嫌いはともかく、良し悪しでいえば間違いなく良いツクールになるんじゃないでしょうか
さすがに十年経ってるだけあって2000のメリットってもう低解像度が使えるぐらいしかないんじゃないか
というわけでRGSS3の話ですが
サンプルゲームの人がこれぞオブジェクト指向！芸術品のようなコード！オーパーツ！現代人に流れ続けるネアンデルタールの血統！とか言ってたのですげえ期待してたんですが
なんのことはないクソコードが丁寧なコードになっただけでした
まあクソと言ってしまうのは失礼で、読みやすさを重視してたようなんだが、素材を作る際に、なんでこの処理分割してねえんだよクソがみたいなことが結構あった
そんな関数は処理単位で作ろう！みたいな割と基本の話に基づいてちょっとコードを整えましたよっていう感じ。
その分メソッド量が増えて処理が追いづらくなってるので、次回作のVXAceReturnsではメソッドだけでなくクラスを小分けするとか、さらなるリファクタリングが期待される
好意的に捕らえるなら、素材を作るときに融通が利きやすいようにやってくれてるようだ
それにしても既に処理が追えないのでこれ以上RGSSが進化した暁にはEclipseとかと連携できるようにしないととても触る気にならない
あと気に入らない箇所としては、相変わらず天候エフェクトがsetPixelで線を引いてるところとか（線とか円とか用意せいや）
敵消滅エフェクトは鼻血が出るほどびっくりしたけど三種類固定かよとか（せめてスクリプト指定できるようにすれば万能なのに）
サンプルマップは素材としてインポートできるとマップ素材屋みたいなことができて楽しそうなのにとか（マップチップ素材にサンプルマップ付けられるとか夢がゲアガリング）
微妙なところで惜しいのが切ない
このへんはデフォルトで何でも出来る、とスクリプト改変をどこまでサポートするか、の境界で作成側としても塩梅に苦労してるのかもしれない
そういうわけでVXからAceへのRGSS変遷でたまげたのは結局Sceneをスタックに積むという発想ぐらいだった
他はむしろデフォルト機能のすごさに驚きを隠せない
そんなおれは複数キャラを同時に移動させるイベントが作れるようになってワーイとかこういうRPGにすらなってない部分で満足感を感じているからゲームが完成しないんだとようやく気付いている
が、楽しいのでそれでいいやあ
「特徴」の汎用性が高すぎてヤバイ
これは面白ステート作りまくりだろ
体験版に付いてくるサンプル遊んだだけで特技の幅広さにワロタ
ボス用の消滅エフェクトとかもあるし
なにがAceだバカｗｗｗｗｗとか思ってたけどこれはすごいツクールだ
なお、皆さんお分かりの通りぼくはツクール大好きですが
これだけ完成できないことを考えると、どうもツクール形式の割と地道な開発は向いていないんじゃないかと思いまして
もっと革新的な（楽な）ツール作れねえかなあとか思いつつjavaでシコシコ作ってるわけです
（出来ることはどんどん凄くなっているが、UIはずっと一緒だし）
そんなわけでAceの購入はどうしようかなーと思ってるんですが
そういう好き嫌いはともかく、良し悪しでいえば間違いなく良いツクールになるんじゃないでしょうか
さすがに十年経ってるだけあって2000のメリットってもう低解像度が使えるぐらいしかないんじゃないか
というわけでRGSS3の話ですが
サンプルゲームの人がこれぞオブジェクト指向！芸術品のようなコード！オーパーツ！現代人に流れ続けるネアンデルタールの血統！とか言ってたのですげえ期待してたんですが
なんのことはないクソコードが丁寧なコードになっただけでした
まあクソと言ってしまうのは失礼で、読みやすさを重視してたようなんだが、素材を作る際に、なんでこの処理分割してねえんだよクソがみたいなことが結構あった
そんな関数は処理単位で作ろう！みたいな割と基本の話に基づいてちょっとコードを整えましたよっていう感じ。
その分メソッド量が増えて処理が追いづらくなってるので、次回作のVXAceReturnsではメソッドだけでなくクラスを小分けするとか、さらなるリファクタリングが期待される
好意的に捕らえるなら、素材を作るときに融通が利きやすいようにやってくれてるようだ
それにしても既に処理が追えないのでこれ以上RGSSが進化した暁にはEclipseとかと連携できるようにしないととても触る気にならない
あと気に入らない箇所としては、相変わらず天候エフェクトがsetPixelで線を引いてるところとか（線とか円とか用意せいや）
敵消滅エフェクトは鼻血が出るほどびっくりしたけど三種類固定かよとか（せめてスクリプト指定できるようにすれば万能なのに）
サンプルマップは素材としてインポートできるとマップ素材屋みたいなことができて楽しそうなのにとか（マップチップ素材にサンプルマップ付けられるとか夢がゲアガリング）
微妙なところで惜しいのが切ない
このへんはデフォルトで何でも出来る、とスクリプト改変をどこまでサポートするか、の境界で作成側としても塩梅に苦労してるのかもしれない
そういうわけでVXからAceへのRGSS変遷でたまげたのは結局Sceneをスタックに積むという発想ぐらいだった
他はむしろデフォルト機能のすごさに驚きを隠せない
そんなおれは複数キャラを同時に移動させるイベントが作れるようになってワーイとかこういうRPGにすらなってない部分で満足感を感じているからゲームが完成しないんだとようやく気付いている
が、楽しいのでそれでいいやあ
いちうまさんのリクエストに応えてプログラミングカテゴリを作りました
RGSSアレルギーのhiroさんがケツ丸出しで逃げ出すぐらいのレベルを目指したいと想います。
なお進行中のプロジェクトは
・UTAUプラグインOverFlags(C#)(公開中)
・お絵かきツールEede(C#)
・RPGツクリプス(Java)
あたりで、このへんの名前がちょくちょく出てくることになると思います。
クソみたいな名称についてはおいおい語ることがあるかもしれませんし、無いかもしれません。
また後ろ二つはあんまり完成させる気が無いので公開しないからって怒らないで下さい。
さてRGSS3ではファイバーを駆使してるとかでツクールの世界も光の時代のようですが、このコルーチンというのの有用性がいまいち理解できていない
よくある例だと
一方おれの組んでるRPG用のプログラムだと、
色々はしょってアドリブで書いてるので、エラー処理とかそのへんは無視して欲しい。
実際にイベントを作る段階ではcommand1云々の箇所を書くことになるわけだが、俺の例２ではイベント命令に応じて次フレームに移動するかどうか決めているが、例１では次フレームに行くかどうかの判断が、イベントを作る人に任されてしまう事になる。
その判断はイベント命令の種類で決まってくるので、おかしいんじゃないかと想っているのだ。
できるならそれはそれでいいんだけど。
そこでyieldを使いつつそのタイミングをライブラリ側で制御しようと想うと、例２のindexが無くなってreturnがyieldになったようなものになり、確かにライブラリ作成の手間は減るが、イベント実装側の手間は変わらんので有用性がわからんということになる。
もちろんコルーチンという技術自体はジェネレータとか色々使えてあれば嬉しい機能なんだが、よく見るゲームのAIに最適！みたいな説明（しかも例１みたいなサンプルが書かれる）には疑問を抱いている。
なお、調べたところluaは上記のような書き方ができそう？（スクリプト処理自体を中断して呼び出し側に処理を戻せる気がする）なんだけど、別言語使うのは結局その言語をパースしてlistを作るって意味で例２のsetup部分と同じなんじゃないかと。
また方向性として出来るだけソース上で解決するようにしているので、別言語を使うというのはちょっと考えていない。
俺のlist形式もこの先条件分岐とか実装することを考えるとすげえ複雑で冗長な記述になるのでキモいのは確かなんだが、これをうまくやる手は無いのだろうか？
というような事を思っているので、RGSS3は一体どんな処理をしているのか、そのうち体験版で確かめてみようとおもっています。
また例３のような書き方をJavaで実現する手があれば是非教えて頂きたい（イベント実装側が簡潔に書ければ、ライブラリ側は複雑になっても構わない）
あとムンホイの人の日記の記述だけ見てSceneManagerはいいアイデアなのでパクろうとおもった。
ちなみにRPGツクリプスとはRGSSをパクいや参考にした上で、俺の使いやすいように作っているRPG用フレームワークおよび関連ツール群です。
名前通り最終的にはエクリプスプラグイン化を目指していますが、今のところ内部のフレームワークを整えて、ツールがなくても気合いでデータを手動記述すればゲームが作れるようにしようと色々やってる状態。
先に書いた通り作っては壊しで完成予定はありませんので、詳しくはつっこまないでね！
では次回からはRGSS3関連になることを願いましょう。
//
追記。例３の書き方は可能らしい。ファイバー外でyieldが来ても無視するのかな。これはかなりcoolだ。
しかしRGSS3では結局事前にリストに命令を格納している形式だったのであまりメリットのない記述になってるようだ。
メソッドをまたいだyieldが有効と言う事で、クラスをまたいでも有効なら色々と誤解が解けて非常に有用という結論に。
つかえねえとか言ってごめんなさいチンコルー先生
さてそうなるとjavaではつかえねえのが問題だな
RGSSアレルギーのhiroさんがケツ丸出しで逃げ出すぐらいのレベルを目指したいと想います。
なお進行中のプロジェクトは
・UTAUプラグインOverFlags(C#)(公開中)
・お絵かきツールEede(C#)
・RPGツクリプス(Java)
あたりで、このへんの名前がちょくちょく出てくることになると思います。
クソみたいな名称についてはおいおい語ることがあるかもしれませんし、無いかもしれません。
また後ろ二つはあんまり完成させる気が無いので公開しないからって怒らないで下さい。
さてRGSS3ではファイバーを駆使してるとかでツクールの世界も光の時代のようですが、このコルーチンというのの有用性がいまいち理解できていない
よくある例だと
例１という感じだと解釈してる。
function update(){
command1();
yield;
command2();
yield;
}
コマンドを実行する度に処理を戻すことができるぞ！
一方おれの組んでるRPG用のプログラムだと、
例２こんな感じになっている。
function setup(){
list.add(new command1());
list.add(new command2());
}
function update()
{
while(true){
end = list[index].do();
index++;
if(end) return;
}
}
色々はしょってアドリブで書いてるので、エラー処理とかそのへんは無視して欲しい。
実際にイベントを作る段階ではcommand1云々の箇所を書くことになるわけだが、俺の例２ではイベント命令に応じて次フレームに移動するかどうか決めているが、例１では次フレームに行くかどうかの判断が、イベントを作る人に任されてしまう事になる。
その判断はイベント命令の種類で決まってくるので、おかしいんじゃないかと想っているのだ。
例３こんな風に書けるならいいのだが、実際にはcommand1()にあたるメソッドは別クラスにあるので、そのクラス自体が単体で利用できることを考えるとこの書き方は破綻しているようにおもえる。
function update(){
command1();
command2();
}
function command1()
{
command1の処理;
yield;
}
できるならそれはそれでいいんだけど。
そこでyieldを使いつつそのタイミングをライブラリ側で制御しようと想うと、例２のindexが無くなってreturnがyieldになったようなものになり、確かにライブラリ作成の手間は減るが、イベント実装側の手間は変わらんので有用性がわからんということになる。
もちろんコルーチンという技術自体はジェネレータとか色々使えてあれば嬉しい機能なんだが、よく見るゲームのAIに最適！みたいな説明（しかも例１みたいなサンプルが書かれる）には疑問を抱いている。
なお、調べたところluaは上記のような書き方ができそう？（スクリプト処理自体を中断して呼び出し側に処理を戻せる気がする）なんだけど、別言語使うのは結局その言語をパースしてlistを作るって意味で例２のsetup部分と同じなんじゃないかと。
また方向性として出来るだけソース上で解決するようにしているので、別言語を使うというのはちょっと考えていない。
俺のlist形式もこの先条件分岐とか実装することを考えるとすげえ複雑で冗長な記述になるのでキモいのは確かなんだが、これをうまくやる手は無いのだろうか？
というような事を思っているので、RGSS3は一体どんな処理をしているのか、そのうち体験版で確かめてみようとおもっています。
また例３のような書き方をJavaで実現する手があれば是非教えて頂きたい（イベント実装側が簡潔に書ければ、ライブラリ側は複雑になっても構わない）
あとムンホイの人の日記の記述だけ見てSceneManagerはいいアイデアなのでパクろうとおもった。
ちなみにRPGツクリプスとはRGSSをパクいや参考にした上で、俺の使いやすいように作っているRPG用フレームワークおよび関連ツール群です。
名前通り最終的にはエクリプスプラグイン化を目指していますが、今のところ内部のフレームワークを整えて、ツールがなくても気合いでデータを手動記述すればゲームが作れるようにしようと色々やってる状態。
先に書いた通り作っては壊しで完成予定はありませんので、詳しくはつっこまないでね！
では次回からはRGSS3関連になることを願いましょう。
//
追記。例３の書き方は可能らしい。ファイバー外でyieldが来ても無視するのかな。これはかなりcoolだ。
しかしRGSS3では結局事前にリストに命令を格納している形式だったのであまりメリットのない記述になってるようだ。
メソッドをまたいだyieldが有効と言う事で、クラスをまたいでも有効なら色々と誤解が解けて非常に有用という結論に。
つかえねえとか言ってごめんなさいチンコルー先生
さてそうなるとjavaではつかえねえのが問題だな
