地球と惑星日本、過去と未来、虚構と現実。そして無数の平行世界。
複雑に絡み合いながらも超えることの叶わなかった数多の世界が、
人の想いの力によって繋がってゆく。
高位存在〝てとら〟の力が全てを変える2年ぶりの最新刊。

8～10巻あたりの頃は「さっさと本筋進めて終わらせてくれ」と
思ってたんだけど今回はすげえ面白かったわこれ。
というのも新キャラの〝てとら〟や平行世界の惑星緑日という
「成恵と和人」以外のものが中心になって話が動いていたから。
正直成恵と和人の関係っていうのは5巻あたりでほぼ完成しちゃってるから
話の膨らませようが余り無い気がするんだよね。
実際9～10巻あたりは「丸尾と八木さん」とか「新田くんと工藤さん」とかの
脇キャラの話のほうが面白く感じたし。

これまでの「何か事件が起こったけど真相は謎のまま」な消化不良な部分も
今回の11巻でかなり伏線解消されてるしこのまま突っ走って貰いたいところ。

つまり何を言いたいかというと
四季ちゃんの出番をもっと増やせってことだってばよ！

　

これから週数回くらいのペースで
ツクールDSについてちまちまと取り留めのないことを書いていこうと思うけど
その際の約束事というか自分内でのルールのようなもの。

①比較対象はPCツクール
本来ならGBやGBAといったかつての携帯コンシューマ機ツクールと
比較するべきなんだろうけれど、実は据え置き機/携帯機含めて
コンシューマツクールというのをツクールDS以前には触ったことがなかったりする。
というわけで比較対象はPC、特に自分が慣れてる200Xが中心になるかと。
ただ、変数の有無などの「何が出来るか」については語り尽くされてる感があるので
操作性やインターフェイスを主に見ていくつもり。

②基本は自作品「機神少女」制作記。
自分が実際にツクールDSいじってる時に感じたことが中心なのでまあこれは当然。
時間があれば低画質だけど写真も貼っていきたいな、と。

③容量についての話は極力しない
これも①の変数とかと同じ理由。
ツクールDS＝容量問題はGoogle先生が予測変換してくれるくらいの代名詞なわけで
他で言われまくってることを改めて言う意味なんて無いし自分でもつまらない。
発売後数ヶ月が経って素材一つ一つの消費容量なんかをまとめてるサイトもある中で
「容量少ねえよ」的なことを今更書いてもなあ、というのが正直なところ。

また「酷いのはDPだ」「Fullならそれなりのものが出来る」
などと特にDPモード※での容量不足が言われているけど、
「機神少女」においてはFull→残り36、DP→残り1024という逆転現象が起きているので
少なくとも自分は「DPだからどうのこうの」とは全く思えなかったりするのが現状だったり。

--------------------—-
※DPモード
要はPCツクールにおける「ゲームディスクにランタイムのデータを含める」のこと。
全データを送るためソフト未所持でも遊べる形式だが、
その反面制作時には画像や音楽の使用に多くの容量を必要とする。

新作はこっそり作る(モチベ的な意味で)のが俺のジャスティス。

GW祭りに過去作を引っ張り出してきたり
ちょっと前に廃スペックデジカメでのDS撮影に挑戦していたのは
こっちのほうをちょっと作ってたからだったりする。

現在開催中のツクールDSコンテスト投稿作品……のはず。
「はず」というのは4/24投稿にも関わらず5/24更新時でも音沙汰が無いから。
さすがにスパンが1ヶ月を超えると不安になる。

しかしまあ開催期間は6月までだしそれまでに無事掲載されればおｋ。
発表されなかったら……どうしようか。
ここでSS貼りつつ審査の基準とかについてちょっと考察してみてもいいかもしれんね。

これまでは半ば意図的にツクールDSについては触れてなかったわけだけど、
こうして発表してしまったからには少しDSの話でもしようかな、と。

----------–
※追記
5/31のコンテスト会場更新にて無事公開されました。
簡単な作品情報は以下の通りです。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
【タイトル】機神少女 －Inheritor－
【作者】下駄
【ジャンル】継ぐ者との絆を知るRPG
【最終更新日】2010/04/24
【プレイ時間】45分前後
【コンテストID】000101901
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

2010/09/01追記
作品公開期間終了に伴い、本作品も8/31をもって公開終了となりました。
プレイして下さった皆様、評価して下さった皆様、ありがとうございました。

前回の続きです。

-----—
③自作システムによるシンボルエンカウント
・メリット:
A戦闘の前後にイベントを挿入したりすることが簡単に可能
B勝利した時/逃走した時などの分岐を作ることが出来る
C並列処理ではないため②よりはバグが出る可能が少ない
Dシンボルを上手く使えば敵の種類や強さなどを戦闘前に知らせることが出来る
・デメリット:
a全ての敵を個別にコピーする必要がある
b個別に設定しない限り先制攻撃/不意打ちが絶対に行われない
c敵の移動パターンなど考えるべき部分が多くなる
d全コピー後に何らかの不具合等が見つかった場合の修正が大変
-----—

「何が出来るのか」のみに着目すると、③は②とほとんど変わらない。
しかしそれは製作側の理屈であって
プレイヤー側にしてみれば「敵が見える」というのは大きな違いであり、
結果として
・敵とのエンカウントがある程度調節できる
・敵が見えることでアクション的要素が加わる
・不意のエンカウントが減り、事前の回復や準備が可能になる
などの要素が加わり、プレイヤー側の選択肢は広がる。

じゃあどうして自分のゲームでは③ではなく②にしていたかというと
これは完全に好みの問題。
実はシンボルエンカウントというのはあんまり好きじゃない。
それは「避けるのが苦手＋敵が見えていると戦わなくちゃいけないような気がする」から。
記憶に新しいのがDSリメイク版saga2。視界に入ってきた敵のほとんどと戦っていたせいで
第3世界でHPが4桁頭打ちになってしまった。
「シンボルを避けられないプレイヤー」にとっては、
ランダムエンカウント以上の連続戦闘を強要される局面が異様に多い。
これがシンボルエンカウントの問題だと思う。

長々と書いてきたけど結論。
・シンボルエンカウントのほうが選択の幅が広がる。
・並列処理が単純に1個減るのもありがたい。
・しかし自分含め避けるのが苦手なプレイヤーにはランダム以上にうざったい存在になる。
そして辿り着いた答えがこれ。

　

　

　

シンボルエンカウント＋シンボル数の変更可。
とりあえず試験的にやってみたけど問題は無さそうだ。

自分のゲームも含めて一番オーソドックスなRPGというのは
雑魚戦→ボス戦の繰り返しで成り立っているわけだけど、
ゲームクリアまでに数十～数百回と繰り返すことになる
雑魚戦のエンカウント形式について少し考えてみようかな、という話。

RPGツクールにおけるエンカウント形式には様々な方法があるが、
本項ではこれを大きく3つに分けて考察していきたいと思う。

-----—
①ツクールデフォで設定できるランダムエンカウント
・メリット:
Aデフォルトの機能を使うため、他のイベントと競合しない
Bエンカウント歩数の変更もイベントコマンドで簡単に行える
・デメリット:
a戦闘の前後にイベントを挟むことが難しい
b勝利した時/逃走した時などの分岐を作ることが出来ない
c実際のエンカウント歩数は揺れ幅が非常に大きい
-----—
最も簡単に導入できるのがこの①。
メリットAのおかげでバグが発生することもほとんど無く軽量だが、
デメリットa/bなどの理由でスイッチ技の後処理などを導入するのは逆に難しい。
そして最も問題なのがデメリットc。
推察※が正しければ極端な話、出現歩数を999に設定したとしても
1歩でエンカウントする危険性があり、状況によっては非常にストレスフルになる。
短編処女作「輝石少女」ではあんまり考えずにこれを採用したが、
時間が許すならあんまりやりたくない。

-----—
②自作システムによるランダムエンカウント
・メリット:
A戦闘の前後にイベントを挿入したりすることが簡単に可能
B勝利した時/逃走した時などの分岐を作ることが出来る
Cエンカウント歩数を一歩単位で自由に決めることが出来る
・デメリット:
aマップごとの設定に手間がかかる
b個別に設定しない限り先制攻撃/不意打ちが絶対に行われない
c並列処理を使うため、他イベントとの競合が起きやすい
-----—
「弾丸少女」「夢幻少女」で採用しているのがこの②。
導入の理由はひとえにメリットA/Bのため。
戦闘の前後にイベントを挟むことで称号による能力上昇や以前触れたスイッチ技の処理、
また「戦闘勝利時のみ図鑑に登録される」ことを再現している。
一方、エンカウントについてはアイテムで有無を選択できるようにしているように
あんまりこだわりはなかったりする。
しかしながら自作ゲームにはフェイスチャットやダッシュといった他の並列処理が
存在しているため、製作中にはイベントの割り込み等のバグが起こってしまっている
など、デメリットcによる問題点などもある。
単純に並列処理が増えて動作が重くなるのも困りもの。

-----—
③自作システムによるシンボルエンカウント
については明日。
というのも見た目には大きく違うけど自作ゲームで採用するには②とそう変わりはなく
個人の好みの問題が非常に大きいから。
-----—

※推察
ツクール2000/2003のエンカウント計算式は不明だが、
スクリプトの閲覧/編集が可能なXP/VXでは以下のようになっており、
エンカウント歩数計算式は1～設定歩数×2であることが分かる。
本項では体感的/経験則より200Xも同様の計算式であるという推論の上で考察を行う。

　def make_encounter_count
　　if $game_map.map_id != 0
　　　n = $game_map.encounter_step
　　　@encounter_count = rand(n) + rand(n) + 1
　　end
　end

（VXスクリプトエディタからの引用です。）