http://eelglass.g1.xrea.com/game/NScripter_for_other_genre.htmlに移転しました。
Googleはbotくんに検出させてください。
| フレームレート | 描画回数 | １フレームにかけてよい時間 |
| 30fps | 一秒に30回 | 約33.3ミリ秒 |
| 60fps | 一秒に60回 | 約16.7ミリ秒 |
余談：
①「負荷が重い場所で自主的にフレームレートを落とそう(30fps等に適宜切り替え、見た目上のカクつきを抑える)」という考え方もある(狭義の可変フレームレート)
②どんな人間の目にもはっきりと処理落ちが分かるのは60fps→54fpsあたりから。数字を出さなければ案外気付かないものです
③ツクール2000は「60fps・アニメーションのみ20fps」という形式を採用している。NSLuaでは再現できない(毎フレーム画面全体を更新する場合、再現しても効果がない)
素のNScripterにおいては以下の状況で実行される。
| 実行タイミング | 説明 | 欠点 |
| 内部的に効率化されているようで、「前回の描画から見た目が変わったらしい領域(無効領域、dirty pixels)」のみ再描画している | 特殊な条件下で奇妙な描画が起きる | |
| repaint | 何も考えず画面全体を再描画する。 | サウンドノベル用途においてはパフォーマンス上の無駄が多い(重いと書かれている・推奨されていない理由) |
| 暗黙的なprint | ボタン待ち命令やアニメーション実行中など、「当然再描画を伴うであろう処理」は内部的にprint相当の再描画が行われる。 |
ボタン待ち中は入力判定ごとに再描画が掛かり得る(複合ボタンの処理)。判定実行頻度は明かされていないが、
① 「通常の用途で不便しない程度には細かい」
② 「新ボタン命令の方が圧倒的に反応が良い」
の二点については経験的に知られている。
アニメーションは指定したミリ秒ごとに更新「しようと」する。
あまりに無茶な数字、たとえば1ミリ秒ごとにアニメーションしろと命じても描画は間に合わない。
命令としてのprintは当然呼び出したときに実行される。
サウンドノベルにおいては「ムダなくまとめて描画しよう」でパフォーマンス上十分であるため、
「それがいつか？」
「どのくらい時間が掛かるか？」
について通常気にされることはない。
ノベル以外の用途(のうちミリ秒と戦わねばならないジャンル)においては、
どうせNSLuaを用いることになるのでやはり気にされることはない。
フレームレートの概念下においては、画面全体の更新１回をもって「１フレーム」と見なす。
画面を部分部分再描画している場合は適当に考える。
(人類はかつてインターレースのような特殊な描画技法を発明したが、NScripterには関係ないので省略する)
①既存のNScripter製ゲームを見た
実際、「NScripterで作られたノベル以外のジャンル」もフリーあるいはシェアウェアとして完成した状態で世に出ている。
ジャンルは経営シミュレーション、ターン制バトルロワイアル、ノンフィールドRPG、DRPG、音ゲー、クイズ、パズルと幅広い。
完成したゲームとして世に出ている事実はジャンルをカバーする最強最大の保証だ。
それらのうちどれかが刺さった結果、「同じツールで」と考える人がいるかもしれない。
②「気付いちゃった、このジャンルNスクで作れるんじゃね？」
そうなんですよ。
③サウンドノベルエンジンである利点を活かしたい
(ノベル以外のジャンル)を作ろうと思い立つならば、逆説的だが動機としては十分にあり得る。
ノベルエンジンであるがゆえに「ノベル的な演出」を行うための機能が一通り揃っている。
つまり「ちょっとしたイベントシーン」のために追加の処理を書いたり探したりする必要がない。
一方でノベル以外を想定した命令も一通り備わっており、特にLua込みなら2Dゲームの多くをカバーできる。
実際、機能上のバランスは良い。問題になってくるのはパフォーマンスが足りるかどうかである。
④恐らくはあなたが文法をよく知っていること
追加の知識なしで済むなら、それにこしたことはない。
とはいえ、「特化エンジンを選ばないことで生じる余計な手間」の大きさ次第では話が変わってくる。
⑤珍しさ目当て
遊ぶゲームのエンジンを気にする人がどれだけ世にいるかはさておき……
「エンジン知名度に対して、ノベル以外のジャンル内では飽和していないツール」という美味しいポジションではあるかもしれない。
ツクールでいう「デフォ戦が見向きされなくなった」現象、
現代的3Dエンジンでいう「そのアセットサンプルまんまじゃね？」現象とは無縁でいられる。
「ノベルエンジンでノベル以外のジャンルを作る」はゲームで遊ぶ人相手なら頑張りが伝わる。
Q.何でわざわざそんな事するの？
その上で向き不向きの早見表、各ジャンルにおける詳細の順に記載する。異論は受け付けない。
| ジャンル | 総合的な向き不向き | Lua込みの適性 | NScripterの適性 | fpsの概念 | 競合するエンジン |
|---|---|---|---|---|---|
| 育成/経営/戦略シミュレーション、 SRPG、クイズ、パズル | ◎ | ◎ | ◎ | ない | 強力なものはない |
| ノンフィールドRPG・ダンジョンRPG | ○ | ◎ | ○ | ない | 近代ツクール、2000 |
| 音ゲー | ○ | ◎ | △ | ある | 音ゲークローンエンジン |
| フィールド付きRPG | △ | ○ | △ | ある | ツクール |
| 格闘ゲーム、RTS | △ | ○ | △ | ある | mugen、3Dエンジン |
| アクション、2Dシューティング | △ | △ | × | ある | 各種汎用・専用エンジン |
| 3Dゲーム | × | × | × | ある | 3Dエンジン |
競合する特化エンジンはそもそも存在しなかったり、拡張性を欠いたり、別に汎用エンジンでよくねってものだったり。
あえて言えば他のあらゆる汎用エンジンが競合対象になるが、どの道フルスクラッチに近い形で開発せざるを得ないジャンルではある。
一番慣れているツールを使えばよい。
| 他の選択肢 | 制作の手間 | NScripterの長所 | ツクールの長所 |
|---|---|---|---|
| ツクール2000 | 独自描画/戦闘を自分で組む限り、コア部分を作る手間は大して変わらない。 むしろ変数などを楽に扱えるNScripterの方が下手をすると楽かもしれない。 GUIとテキストファイルのたたかい。 (2000にも非公式エディタが複数存在するが、今は考慮しない) |
①解像度。
2000は320×240の倍角表示なので、必然的に一枚絵やフォントはSFCドット絵になる。ゲームの性質次第では気にする人もいる。 ②機能面で上回っている点。変数の扱い、外部ファイルの読み込みなど。 |
その圧倒的資産(そざい)は今日もフリーゲームを支えている。ドット芸万歳。 「2000製の変態的にすごいフリゲ」には固定層が付いているため、良いものを適切に作れば相応に評価される。 (「過去の名作が立ちはだかる」とイコールではあるが) 僕はツクール2000が好きです。 |
| 近代ツクール |
近代ツクールは公開されているスクリプトを組み合わせてコア部分を省力に作れる。 RPG隣接ジャンルに必要なスクリプト素材は概ねカバーされているため、最大限利用すれば手間は圧倒的に削減される。 自分で複雑なシステムを組むなら、近代ツクールはコード書いてね(ruby→javascript)と開き直っており手間はそれほど変わらない。 |
動作の軽さ、というか近代ツクールが異様なまでに重い。 それだけで触る気が薄れる人間もここに一人いる。 あの人たちバッテリー食い過ぎません？ なんで？ |
僕は近代ツクールが苦手です(重さ、デフォ素材の頭身、戦闘の背景うねうねエフェクト、あのうねうねエフェクト！)。 とはいえRPG用途として見た場合、そのスクリプト資産は決して無視できない(NScripterの場合は半ばフルスクラッチになる)。 「本来のVXは妙ちくりんな縦横比だが大抵4:3にカスタマイズされている＝結果的にNScripterとほとんど同じ解像度」 といった事情により、グラフィック素材の差はない。 |
唯一問題になるのは「最も細かい音符・休符の間隔に入力受け付け頻度が間に合うか？」という点。
「入力を正確に拾えなかったり、処理落ちしたりする音ゲー」を想像してほしい。
温情抜きだとクソゲー扱いされかねず、その意味で描画パフォーマンスをある程度気にする必要が出てくる。
結論のみ言うと、(新ボタンやLuaを使うなら)演出が豪華すぎない限りは間に合う。
| 詳細ジャンル | 補足 | 制作上のネック |
| 音ゲー |
音ゲー作らんと思い立つ人ならみんな知っていそうだが、BPM(beats per minute、曲が１分間(60000ミリ秒)にいくつの４分音符を打つペースか)という概念がある(心拍数みたいなものだよ)。 特別な事をしていなければ120前後の曲が多く、ミッキーマウス・マーチやめざせポケモンマスターはbpm120。 下限近くのテンポはお葬式じみており、現行の国歌はbpm70である。 一方で商業音ゲー用の高難度曲はbpm240を超えるものもざら。 さらに曲の途中でテンポが変化することもあり、ゲームとしての難易度上昇に拍車をかける、あのアレ。 bpm240×３２分音符あたりまで考慮するなら、およそ数十ミリ秒に一回判定を行う必要がある。 それ自体は素のNScripterでも恐らく間に合う(Luaなら余裕である)が、より細かく判定グレードを付けるなら秒間60回に迫るペースの判定が必要になるかもしれない。 |
譜面データの作成。楽譜またはmidiファイル、恐らくどちらか一方は必須。 なお、既存の音ゲーフォーマットに曲を乗せたいだけならクローンエンジン使った方が早い。 |
| リズムゲーム | リズム天国系クローン。 入力間隔の最小単位に余裕がある分、いわゆる音ゲーより「プログラム難度は」大幅に低い。 | ちゃんと面白いの作れるか？ |
格ゲーのパフォーマンス事情は他と同じ(刺し合いゲーならオブジェクトも多くならないので、むしろ他ジャンルより楽かもしれない。コンボゲーはさすがに厳しい)。 さすがに格ゲーツクールという時代でもない(当時から微妙だったし)が、このジャンルは明らかにmugenと競合する。 しかもmugenはLuaを使っている。どうするよ？
サイト内のライブラリ(NSLisichka)、素材のうち権利が僕に属するものは必要なら自由に使ってください。 ※そうでない素材・プラグインは配布元参照。 なお、現時点で自機グラフィック用に借りたMMDモデルは配布終了しているようです。
先回りしておくと、目指すところが東方クローンなら東方弾幕風あたりを使った方が早い。
3D演出(背景)を活用するならば3D機能を持ったエンジンが良い。
そうではないSTGを作ろうと思うならば、当然STGに対してそれなりの拘りがあるはず。競合ツールで痒い所に手が届かなければ、一から自作した方が幸せになる事も少なくない。
(「動かすだけなら簡単」と言われるジャンルであり、実際名作凡作を問わずフルスクラッチのSTGは多い。)
素のNScripterにおいては、非弾幕STGならばどうにかなるかもしれない。
弾幕STGとなると、計算・描画パフォーマンスの関係で素のNScripterには厳しくなってくる。
かつてサンプルを作った先人が存在するが、固定背景・極小敵でもフレームレートが危うい。
Luaを使うとどうなのか。60fpsターゲットならLua必須である
NSLuaの直接描画(高機能なblt命令と考えればよい、NScripterが有する中で最速の描画である)を使うことになる。
機能面では(他のエンジンでコードを書けるなら)全く問題ないが、パフォーマンスは許容範囲の下限スレスレとなる。
① 640×480の画面領域をフルに使う
② 60fpsを基本とする(処理落ちを避ける)
③ 最低環境(安いタブレット)まで動作環境に含める
この条件下では、初期スーファミ相当の演出でギリギリだと思った方がよい。
つまり全画面多重スクロール背景(背景や画面手前にかかる霧、網目越しに映る背景など)は諦めた方がよい。
NSDSpは(60fpsを視野に入れるなら)やや遅く、640×480サイズの透過背景を重ねるだけで60fps達成のための余裕はほとんどなくなる。
イベントシーンのみ30fpsにするなど涙ぐましい工夫を行うか、オプションでグラフィック設定を用意するか。
いずれにせよ2Dゲームの華である多重スクロールに弱いのは惜しい点である。
30fpsに絞る、そもそもの画面サイズを落とすなど妥協すればまったく余裕だが、解像度を落とすのもフレームレートを落とすのも相応に覚悟が要る行為。
なお、ここまでの話は640×480をフルに使うSTGを前提にしている。
「画面を更新せずに済む領域」が大きい縦STGの場合、話は全く異なる。
横9:縦16はピクセルに直すと270×480に相当し、この場合常に更新するべき領域は半分未満に抑えられる。
アクションゲームに関しても事情は似ている。 半透明エフェクトや多重スクロールはSTG以上に2Dの華であるため、目指す描画クオリティがどの程度であるか(そして実現する上で性能が足りるか)考える必要がある。 アクションゲームはPCにおいても多少の処理落ちまでなら許容されている節があり、その意味で神経質になる機会は減るかもしれない。