ブラウザ版 To Hole of Hell 開発後記

To Hole of Hell - RPGアツマール

先日ブラウザ版 To Hole of Hell (以下 THH )をリリースした。ブラウザで遊べるので試しに遊んでみてほしい。

THH は2012年4月に、ゆえっちこと結城えいしくんと二人で作って公開したゲームだ。ツイッターにスコアを投稿する機能があったのでみんな遊んでツイッターに投稿してくれていたのが、2015年くらいまで続いていた。

それから RPGツクールMV が発表になって、ブラウザ向けに気軽にゲームを作れるようになったのを見ながら、THH もブラウザで遊べたらいいな~ということを思っていた。*1

THH は当時すでに完成されたゲームで、試しに組んだ機能が遊んでみたらカッチリとハマって触るところがあまりないという状態でリリースできた。これは幸運なことだったけれど、感覚的にはこれでちゃんと面白いゲームになっているということは言えても、どうして面白いのか自分で説明するのが難しい状態だった。

今回ブラウザ版を作るにあたってロジックの移植をしてテストプレイして挙動をオリジナルに合うよう調整するということをやってみて、そのあたりが言語化できそうだなと思ったので、書いておく。ゲームの仕様みたいなことも包み隠さず書いていくので、攻略の参考にもなるかもしれない。
あとたぶん RPGツクールMV でアクションゲームを作る話とかはそれなりに技術的なバリューがあると思うのでそのあたりも触れておく。

ゲームデザインの話

ゲームプレイにメリハリをつける

移植作業の初期はスクロール速度が遅くなったり早くなったりせず一定のままだったが、これがとにかく退屈だった。
で、開発初期にゆえっちから「ゲームプレイに変化がないからスクロールスピード早くしたり遅くしたりできないか」という提案があってそれを組み込んだが、実装にあたっては、特に深く考えずになんとなく1000フレーム周期で早くなったり遅くなったりするようにした。
900フレームごとに100フレームかけて早くなるのを二回、次の900フレーム後に100フレームかけて元の速度に戻すということをやっている。動かしてみてしっくりきたからこうという感じでこの数字になっていて、明確な根拠はないのだが、これがちょうどいい具合になっていると思う。
実際に遊ぶと24~5階で遅くなって、次に32階付近でまた早くなる、というふうになっていると思う。ゲームのサイクルが16階層周期なので、ちょうどマッチする。

ゲームのサイクルが16階層周期なのは、一回のステージ生成で16階層分作って、以降16階毎にステージを再生成している都合からだ。16の倍数階には敵が出現しない。ループ境界をまたいだときに敵がワープすることがあったのでそれを抑止するための苦肉の策だったのだが、敵がいないことがわかっている階層が周期的にやってくるのは、緊張し続けなくてよくなるので、結果的にはよかったと思う。

なお、16の倍数階層ごとに敵出現率が上がるようになっている。計算上は144階以降はすべての足場に敵か回復アイテムのいずれかが配置される状態になる。ふつうにプレイするとまずそこまで到達できないだろうとは思う。

ゲームプレイと BGM の協調

ブラウザ版では46~7階層で曲が一周して、50階層でゆっくりになるところでイントロが終わるくらいの感じになっている。ここはゲーム体験とシンクロしていてかなりいいんだけど、これは本当に偶然で、まったく意図していなかった。曲が展開して盛り上がりに入っていくところでスクロール速度がゆっくりから加速に切り替わっていくところも、これも本当に偶然だが、プレイしていてかなりしっくりくる。BGMとゲーム体験についてはオリジナルの THH を作った当時にはあんまりよく考えてなかったのだけど、今は自信を持ってこの状態はよくできていると言える。
さすがに次の一周はゲームのサイクルとはシンクロしていないのだが、曲の二周目が展開して盛り上がるあたりから敵の密度が高まってくる。スクロール速度はゆっくりだが、むしろ敵が多くなるタイミングからいきなりスクロール速度が速いよりは適当で、ゆっくりだからかえって「あれ気付いたら敵たくさん湧くようになってない?」という気付きを生むタイミングになっているし、敵が増えて緊張感が増すタイミングで曲が展開して盛り上がるのでグッとくるのではないかと思う。

もちろんブラウザで動作する関係上、曲の読み込みタイミングによっては意図通りにはならないのだが……。

このあたりのことを言語化したかったので、できてよかった。

ランダムだけど完全ランダムでない地形生成

生成といってもあらかじめ組んでおいたパターンを並べているだけである。
だけなのだが、完全にランダムにしようと思うと、

  • 一画面まるごと足場がない
  • 足場の隙間が少なすぎる状態が連続する

こういうことを抑制しないといけない。これをロジックで組むこともできなくはないが、それよりはあらかじめ組んでおいたパターンを並べるほうが制御しやすい。
足場のパターンは14種類で、これが適切かどうかはまだちょっと悩ましい。今は厳しい足場が連続するとかなり厳しく、乱数が効きすぎているなと感じている。足場のパターンごとに出現率に重み付けしたほうがいいんじゃないかと思うが、ちょっと緩めると緩くなりすぎてしまう。

パターンはあらかじめ決まっているので、プレイしているうちになんとなく「この位置に足場が来たら次はここに来やすい」みたいな肌感覚が身についたりするかもしれない。
「目指せ100階」というのはそれも込みの目標階層数で、ちょっと厳しめに設定してある。でも不可能ではないかなというくらい。もちろん祈る場面も少なくはないけど……。

ジャンプの廃止

スクロール速度が変わったりするところはこのゲームのメカニズムの中では複雑な方だと思っているが、基本的にはシンプルにまとめる方向で調整している。
前に公開していたバージョンには回復アイテムもなく、ダメージを受けたら受けっぱなしで、どれだけダメージ受けずに降りられるかみたいなデザインだったが、そのかわりにジャンプできるようになっていた。
で、今作はジャンプできなくするかわりに回復アイテムを配置することにした。
やってるとわかると思うんだけど高速スクロール中はジャンプしてる余裕なんてなく、低速スクロール中はあえて敵をジャンプで乗り越えてまで逆の端から降りたい場面がそんなになかった。もちろん下に足場がないけど敵が前にいて邪魔、みたいなことはたまにあるが、その場面でとっさにジャンプを思いつけるほど、ふだんからジャンプするゲームではないので、下に足場があることを祈ってダイブするほうを選んで、落ちてからそういやジャンプできたなあ、とか思う。だったらいっそジャンプなくていいよね、ってことで、ジャンプを廃止した。

回復アイテムは、一画面あたり最大一つだけ、1/10の確率で足場に配置される。割と出たり出なかったりの確率だ。やむをえず敵に当たっても、わりと回復できる。回復できるが、ダメージを受けると「回復しなきゃ」ってなって焦る。このあたりの緊張感が個人的にはうまく効いてるんじゃないかと思っているけど、人によっては好みがあるかもしれない。
このゲームのコンセプトには合っていると個人的には思っている。

敵に当たらないにこしたことないので、祈りながらダイブするプレイング。
敵に当たっても後で回復すればいいので、安全に足場を選ぶプレイング。

どっちもありだと思う。ジャンプを廃止して左右の移動だけに絞ったことで、どっちも選べるようになった。操作ボタンが少ないほうが、プレイヤーの選択の幅が広がることもある。

といいつつ、今後ジャンプにかわるアクションを追加する予定でいる。ジャンプは気軽に使えないからよくなかったので、今作のゲームデザインにあう形のアクションなら組み込んでもいいだろうという。もちろんそれでゲームバランスは変わってしまうだろうが、今のゲームバランスもそれなりに気に入っているので、クラシックモードとして残すか、何かしら考えている。
どういう形になるにせよ、今後もアップデートを続けてもっと遊べるようにしていくので、楽しみにしていてほしい。

実装の話

RPGツクールMV のプラグインを書いて実装した。TypeScript で書いて JS にトランスパイルして RPGツクールMV に取り込んでいる。
TypeScript でプラグインを書く方法については

www.f-sp.com

など参考になる記事が Web にあるので見てもらえればと思う。
型定義ファイルは以下のものを使うとよいだろう。

github.com

横スクロールアクションの挙動の実装

肝心の実装のポイントは、

  • クラスを継承して独自クラスを作らない
  • クラスにインスタンス変数を追加しすぎない

この二点で、じゃあどうやったかというと、横スクロールアクションの挙動を司るクラスを作って、そのインスタンスGame_Character クラスに保持させるという方針にした。Twitter でかねてより口にしている「無闇に継承せずに委譲とコンポジションを適切に使え」である。

  • SideViewActionCharacter というベタなクラスを作り、Game_Character に持たせる
  • Game_Characterupdate 内で SideViewActionCharacter を更新
  • Game_Character の座標と `SideViewActionCharacter の座標を同期する

ということをやっている。「Game_Characterupdate 内で SideViewActionCharacter を更新」して「Game_Character の座標と SideViewActionCharacter の座標を同期する」ことができれば別に Game_Characterインスタンス変数に SideViewActionCharacter インスタンスを格納する必要はなくて、どっかにテーブルを作って Game_CharacterSideViewActionCharacter を紐づけてもいいのかもしれない。

Game_Character はプリセットの状態でかなり複雑な上、Game_EventGame_Player がそれぞれに機能を拡張している。この状態で横スクロール用の挙動を拡張して実装するのはかなりコストが高いのでやりたくない。既存の動作と競合して意図したとおりに動かなかったりするし、デバッグも困難だからだ。
一から専用のクラスを作って完全にコントロール下に置きたいが、そうなってくると Scene_MapGame_Map 上にその独自クラスを追加することになり、これもまたかなり困難があるし、何よりイベント監視まわりなどの既存の資産をすべて捨てることになる。
既存の動きに乗った上で挙動だけこちらでコントロール可能なクラスに管理させるのはバランスがよいやり方で、実装自体もかなりシンプルになっている。

当たり判定も一から書いているが、実装自体はオリジナルの THH から移植するだけなので難しくないし、元の実装もごくシンプルな AABB ボリュームの交差判定になっている。これくらいならベタで一から書いても大したことはない。*2

このあたりはゆくゆくは汎用的な実装に組み替えてプラグイン化も考えているので、興味のある人は期待せずに待っていてほしい。

ダメージ処理・アイテム取得処理

Game_Character を拡張して横スクロールアクション用のオブジェクトを作った、というわけで、敵やアイテムもイベントとして配置されるようにしてある。
「プレイヤーから触れたとき」をトリガーとしてイベントを記述して、ダメージ処理やアイテム取得処理を組んである。ツクールのイベントコマンドでどうしようもない処理はスクリプトを呼び出してなんとかしている。イベントコマンドのスクリプトGame_Interpreter インスタンスのスコープで解決されるので、ふつうに $gameMap.event(this._eventId) とかやれば実行中の Game_Event インスタンスが取得できるし、ここから SideViewActionCharacter インスタンスにアクセスして任意の処理を行わせればよい。API を整備しておくと便利だろう。
たとえばダメージを受けたら一定時間無敵にする処理は被ダメージイベントをコールする API を用意して Game_Player インスタンスの初期化時にイベントハンドラをセットするというやり方にしてある。

敵の移動ルーチン

Game_Event の移動ルーチンまわりの処理をフックして SideViewActionCharacter を操作しているだけで、難しいことはしていない。座標に関わることはすべて SideViewActionCharacter でやって、ゲーム処理のサイクルはツクール側に任せる、というふうにしてある。これでエディタ上で移動ルートの設定から敵の移動の挙動を記述できる。といっても THH は壁か足場の端にぶつかるまで前進して、ぶつかったら反転する、ということをしているだけなので、凝った挙動はもともと書かなくてよかったりはする。

壁や足場の有無を判定してなにかする部分だけは、移動ルートからスクリプトで呼び出している。
イベントのカスタム移動ルートのスクリプトGame_Interpreter インスタンスのスコープで解決されるので、センサー処理だけスクリプトから呼び出せるように API を整備しておけば、視界にプレイヤーが入ったらどうこうみたいなことも一応制御できるようになる。

動的なマップ生成

ステージ生成用のクラスを作って Scene_Map から呼び出して、Game_MapData_Map にデータを反映する。これだけ。
Game_MapData_Map の構造を把握できてればそんなに難しくないと思う。そのうちに詳細を解説する記事を書きたい気がする。ローグライクゲームなどに応用が効くと思うが、ローグライクはすでにプラグインがあると思うので、それを使ったらいいだろう。

今作のマップ生成はマップパターンをランダムに抽出して縦に連結するだけというシンプルな作りになっていて、マップパターンはエディタ上でそれぞれ一枚のマップとして登録してある。

敵やアイテムの配置パターンはそれぞれのマップ上でイベントとして設定しておいて、マップ生成時には配置情報だけを使うようにしている。
実際の敵やアイテムのイベントはテンプレートイベントを用意して、生成時にクローンしている。テンプレートイベントはマップから読み込んだらどこかのテーブルに格納しておいてマップからは消す。今回みたいな動的にマップを生成するゲーム以外でも、敵や宝箱をランダムに配置したいときには有効な方法だと思う。もちろん既にそういうプラグインはあるので、それを使えばいいだろう。

アンチエイリアスのかからないピクセルフォント

PIXI.extras.BitmapText を使っている。文字とそのグリフの画像ファイル上の位置を記した fnt という形式の xml と グリフを並べた pngPIXI.extras.BitmapText.registerFont に渡してフォントを登録すると、PIXI.extras.BitmapText インスタンスを使ってピクセルフォントを使った文字描画ができるようになる。PIXI.extras.BitmapTextPIXI.Container 派生クラスなので、普通に PIXI.ContaineraddChild すれば画面に乗る。ツクールだと Scene が spriteset というものを持っているのでここに addChild すればピクチャみたいな感じで使える。直接 Scene に addChild すると画面のフェードイン・フェードアウトや色調変更の影響を受けなくなるので注意が必要。

スコア画面はピクチャみたいに使えるプラグインコマンドを生やしてイベントから呼び出して描画している。専用のシーンクラスを作るよりこのほうがイベントの機能を使えて便利なので最近はこういうふうにやってしまうことが多い。

他にも細かいところはいくつかあるものの、実装の話はだいたいこんなところでいいだろう。気になることがあったら気軽に聞いてくれればと思う。

おわりに

もう6年も前に作ったゲームだが、今あらためて遊んでみても「もう一回」となる魅力があって、これが長らく遊べない状況が続いていたのはもったいなかったなと思う。これからは RPGアツマールのサービス終了まではずっと遊べるので、いつでも気が向いたときに遊んでもらえればなと思う。

前述したとおり、今後のアップデートも予定している。アクション追加の他には、たとえば RPGアツマールにはスコアボード機能があるので、各プレイヤーを横断したスコアランキングを作ってみてもいいかなと思っている。あとはよくある実績機能とか。実績向きのゲームシステムだと思うので、たぶん組み込んだら楽しいだろうと思う。他にも思いついたら何かやってみる。もちろん、今すでにシンプルでよく整っているので、あまり足し算しすぎて壊さない範囲で。

*1:実のところ、それより前から Unity に移植する計画などもあったのだが、Unity でオリジナルの挙動を再現するのがむずかしかったので断念した

*2:実はオリジナルの実装には地形の角の接触判定にバグがあって異常な挙動を起こすのだが、面白い動きをするのでそのままに移植した。実際に遊んで体験してみてほしい

ロールディアの翼やった

これやりました。

フリーシナリオの自動生成ダンジョンハクスラ RPG で、主人公は女の子、モンスターに襲われるとヌコヌコされてしまうタイプのゲームです。

よかったところ

主人公の女の子は RPG の主人公だからというのもあってか口数が少ないんですが、それが個性につながっててかわいかったです。無口クールな女の子がモンスターにヌコヌコされてトロトロになっていくの最高だった。

ゲームバランスはよくはないですが悪いというほどでもない。戦闘はキツめですが金策の手段はいろいろあり、「お仕事」をすれば稼げます。レベルよりも武器が重要な感じなので、金稼いで武器を強化してやっていくのがスムーズ。そのあたりの手探り感はよかったです。

シナリオはあっさり目ですが、雰囲気もよく、ほどよくつらさや苦さがあって好みでした。

よくなかったところ

戦闘はかなりジリジリします。囲まれると終わるので一匹ずつ釣るのはいいんですが、この戦い方は基本的に長引きます。初期のほうのバージョンだと敵の数が多いので一フロア突破する間にかなり疲れてしまう。

攻撃してもノックバックしないので、引きつけて殴って下がり、引きつけて殴って下がる、という感じなのですが、ダンジョンは基本的に細長い通路なので、無限に後退しながら殴ることになります。敵を倒しきってから先に進む。これのせいで探索時間が伸びてしまっている。爽快感はゼロです。倒し終わったときの疲れたという気持ちだけが残る。
ノックバックするようにしてほしかったですね。敵が硬くても、ノックバックがあるだけでだいぶ爽快になったと思います。

ダンジョンも、バージョンアップ前は長かった。特に高難度ダンジョンはフロア自体が広い上に7階層とかある。どっちかだけにしないと厳しいように思います。
バージョンアップで階層数が減ってそのあたりは緩和されたんですが、個人的には階層数はそのままでもよく、フロアの広さを制限したほうがよかったんじゃないかなあという感じ。階層数が多い方がモンスターハウスや宝箱フロアの抽選回数増えるので。

ランダムダンジョンはちょっと難がありましたが、固定ダンジョンはちょうどよかったです。

街マップはねくら氏のマップチップのおかげで美麗なんですが、ダンジョンは自動生成の都合上破綻している箇所がたくさんあって、そこはやや残念でした。まあでも実装が難しいとは思います。

サブキャラクターたくさん出てくるんですが、自由に連れ歩けるのは二人(と傭兵のおじさん)くらいです。ちょっともったいないですね。サブキャラクターとの絡みも、イベント外ではほとんどなかったも寂しいです。リタもいっしょにヌコヌコされてほしかった。

女の子モンスターがスキュラくらいしかいなかったのも個人的には惜しかった。せっかくサキュバスのイベントあるのにサキュバスが女の子モンスターとしては出てこないのなんで~ってなった。触手は充実しているので触手スキーは満足度高いかもしれない。

まとめ

よくなかったところのほうが多くなってしまったんだけど、今のバージョンは戦闘が長引く件については敵の数だったりダンジョンのフロア数だったりを抑えることで改善されてはいますし、そもそも初期のバージョンから充分遊べるゲームバランスではあります。 不満点はありましたが遊んでいて楽しかったですし、落ち着いたら頭から再プレイしたい気持ちでいます。

レベルデザイン考

発端のリンクをはっておくけど、この記事を書いた時点では、このまとめを読んでもレベルデザインとはなにかに対する明確な答えはない。

togetter.com

そしてこの記事もぼくなりの見解であって、現職のレベルデザイナーの見解にそぐうかどうかはわからない。

まとめを読むとわかると思うけど、たぶん「難易度」の話が解決しないと先に進めないので、レベルデザインと難易度の話をする。

レベルデザインに難易度の設計は含まれるか

「含まれる」と考えている人は、だいたいこんな考え方だろうと思う。

  • 単に難しくしたいとか簡単にしたいとかっていうつもりで使っているわけではない
  • 体験の一部として手応えのある要素を用意したり、慣れを実感させたり爽快感を味わわせるためにハードルを下げたりっていうことをレベルデザインの要素だと考えており、これを指して「難易度の設計」と呼んでいる
  • 難易度の調整はレベルデザインの先にある作業だということは理解している

レベルデザインに調整が含まれないのはわかっているけど、個々の要素について難しさを意識してステージの配置を行うんじゃないですか」っていうことを、この人たちは言っているのだけど、現場のレベルデザイナーからは「いや難易度調整はレベルデザインに含まれないです」という回答がかえってくるばかりで、答えがない状態のままだった。

違う、調整じゃなくて、難易度設計の話をしているんだ。

でも、そもそも難易度設計っていう言葉がよくないんじゃないかと気付いた。

レベルデザインに難易度の設計は含まれない

レベルデザインは単純に『難しいステージ』『簡単なステージ』を作る行為ではない」ということを、現職のレベルデザイナーの方々が伝えようとしているのではないかと思う。
そう考えてみると、確かに一貫してずっとそう言っている。

レベルデザインは体験ありきであり、難易度はその結果として現れる。

次のようなアウトラインに沿って考えてみる。

ゲームデザイナーが考えたゲームのメカニクスがあり、そのメカニクスを体験するフィールドとしてレベルがある。メカニクスの理解を促すために、プレイヤーが遊びやすい環境からはじめ、メカニクスが有効に使える場面、逆に有効でない場面を体験させる。メカニクスに対する理解ができた頃に、手応えのある障害を用意する――このようにしてレベルデザイナーがレベルを作成し、その後、レベルデザイナーの要請に沿って、難易度が調整される。

実際に遊んでみると、先に出したレベルよりもその後のレベルのほうからプレイしたほうがメカニクスを理解しやすい、ということがあったとする。レベルの順序を入れ替えることもあるのかもしれない。レベルデザインを行うより先に難易度は決まっておらず、レベルデザインの後で適切な難易度が見えてくる――のかもしれない。

ぼくは開発現場でゲームを作っているわけではなく、野良で個人製作のゲームを作っているだけだから、ゲームデザインからレベルデザイン、難易度調整まで自分で一人でやることになる。
そうすると境界線なんてあってなきがごとしだから、最初にふわっと難易度曲線のことを考えて、序盤だから遊びやすく、終盤だから手応えを……みたいなことを考える。個人製作者の中にはそう考えて作る人もそれなりにいるんじゃないかと思う。

「レベルデザイナーは難易度を FIX しない」「レベルデザインは難易度を決定する作業ではない」ということだとすれば、そもそも「難易度の設計」という言葉がまずくて、そのような作業は存在しない。

これは現場を知らないので想像なんだけど、たとえばゲームデザイナーから「ここは序盤でプレイヤーに遊び方を理解させるレベルにしたいです」とか「ここは中盤でプレイヤーが遊び慣れてきているのでそれを実感できる手応えのあるレベル or 爽快さを味わえるようなレベルにしたいです」みたいな指示があって、それに沿ってレベルを作成する。
この要件からはふわっと難易度のことが頭をよぎるんだけど、難易度は本質ではなくて「遊び方を理解させる」「慣れを実感できる手応えを」「爽快感を味わわせる」みたいなことが根っこにあり、その結果として難しさが表出してくるのであり、最初から難しくしようとか簡単にしようって考えて作ってはいけない。
もっとも、レベルデザインに難易度設計が含まれると考えている人、みんながみんな、単に難しくしたり簡単にしたりしようって言っているわけではないだろう。
彼らにとっての難易度設計っていうのは、たとえば「遊び方を理解させるためにどうするか。ギミックの配置の複雑性をエスカレーションして、徐々にプレイヤーが複雑なギミックに対応できるようにして……」ということであり、ここでいうギミックの複雑性のコントロールを難易度設計と呼んでいる人も、少なからずいるように思う。そういう人たちは、敵の配置の密度なり、通路や部屋の戦いやすさなりっていうのも、ひっくるめて難易度設計と呼んでいるように思う。
中身を分解してみれば、それはちゃんとレベルデザイナーの作業になってると思うのだけど。

繰り返しになるけれど、単純に難しくしようとか簡単にしようって思っているわけではない、と思う。ただ、どうやら現職のレベルデザイナーの方からは、難易度設計という言葉は単に難しくしたり簡単にしたりしようっていうふうに見えているかもしれない。実際にそう考えている人もいると思うので、そう見えても仕方ないかもしれない。

通じていない言葉よりも、通じていると思っている言葉の認識の齟齬をなくすほうがむずかしい

今回だと難易度というおおむね意味が通じているだろうという言葉のほうが、認識を合わせるのが大変だった。
現場の人のいう「難しいとか簡単とかいうことはゲームの本質ではない」というのは理解できるし、一方で「プレイヤーの習熟にあわせて障害の困難さをスケールさせる行為は、難易度をコントロールしていると言えるのでは?」という意見も、やはりよくわかるから、一見して「レベルデザインに難易度に関わる作業は含まれない」という言葉だけでは、ちょっとピンとこない。

難易度設計

それはそれとして、難易度の設計はレベルデザインとは別の工程としてある。
レベルデザイナーは敵の強さを決定しないし、敵の攻撃方法を設計したりはしない。強い敵や弱い敵について、あるいは強い攻撃方法や弱い攻撃方法を設計するのはレベルデザイナーの仕事ではない。
現場の感覚では、難易度設計という言葉を使われると、こういう仕事のことを考える。
レベル内の障害の困難さをコントロールすることは難易度設計とは呼ばない。

そしてレベル内の障害の困難さは難しくしたり簡単にしたりするためにコントロールするわけではないから、レベルデザインが難しさにかかわる作業だというのは誤りである。

だいたいこういう理解に落ち着いた。

余談

ところで、英語圏での level design について難易度にかかわる作業が含まれないという話の根拠は特に見当たらなかったし、英語の記事で level design について難易度を絡めた話をしている記事はちらほら見かけた。たぶん英語圏においても、スタジオによってまちまちなんじゃないかと思う。

敵の出現頻度や AI の思考を動的にコントロールして難しさを変化させる仕組みとかもあるし、難易度と個々のレベルとは切り離して、レベルデザインにおいては遊び方の設計をするにとどめて、その遊び方が難しかったり簡単だったりっていうのは、その先でやることだよ、レベルデザインでは考えないことだよ、っていうのは、まあわかる。
一方で、地形それ自体の構成が直接的に難しさにかかわるようなケースは実際にあってそのような記事*1 を書いている人もいるし、プロシージャルにコンテンツや難易度を決定してレベルデザインする手法っていう論文*2 もある。

個人の見解です

「どうして難しくしたり簡単にしたりしたいのかを考えるのがレベルデザインです」っていう話からは、やっぱり難しさのことを考えるんじゃないのかな……って気はする。考えた結果として「いや別にここ難しい必要ないですね」っていう答えが出るにせよ。むしろゲームのメカニクスを理解させるのに不必要に難しかったりしないか?ということは考えないといけないんじゃないのかなあ。別に難しくしたいわけではないんです。難しいのが面白いとも思ってないんです。

とはいえ難しさは本質ではないというのは本当によくわかるしそのとおりだと思うので、目先のわかりやすい難易度よりもっと根底にあることを考えた上でのレベルデザインっていう言葉だっていうことは、ちゃんと理解しておきたい。*3

*1:参考: http://simonlundlarsen.com/scaling-geometry-difficulty-in-level-design/

*2:参考: https://ieeexplore.ieee.org/document/6633640/ ※読んではいない

*3:でも今回の話、たとえばニカイドウ氏はそのへんのことはよくわかってらっしゃる方だと思うんだけど、なんか不必要に攻撃されてたような気がしてつらい

なんでも書ける場所にした結果

Twitterに書きにくいことを書くだけの場所になってしまった。チラ裏。

チラ裏があることは便利なんだけど、よく考えるとこのブログじゃなくてよかったなと思う。なんか逆にチラ裏的な記事の存在によって、このブログにまっとうなことを書いても表で記事書いたって言いにくくなってしまった気がする。

まあそれはそれでいいかと思っているのだけど、オールタイムで読めるような記事は選別してアーカイブ版として静的サイトに載せたい。せっかく書いたので。

まあそういうのも体力使う。いろんなことが中途半端になってしまっている。

coinhive の話

これ「他人のコンピュータのリソースを勝手に使って利益を得る行為だから悪いことだろう」っていう理屈はわかるんだけど、その理屈と「ウイルス作成罪」での逮捕ってのはやっぱ無理筋なんじゃないですか。

争点の一つに「同意していればOK」というものがあって、たとえば「他人の土地を勝手に使ったら違法」とかっていうたとえがある。そのたとえもわかるんだけど、ウイルス作成罪と何か関係ありますか。

ここ論点が錯綜してるところだと思うんですけどウイルス作成罪の範囲を拡大することの危険性っていうのも論点にあって、拡大解釈がいきすぎれば、なんでもかんでも恣意的にウイルス扱いすることで家宅捜索し放題、なんなら個人所有のコンピュータ内のデータを検閲することに利用することだって可能じゃないですか。もちろん可能性の話であって蓋然性がどうかっていうのはぼくは正直よくわからないんですけど、ただ、今回の件をウイルス作成罪として立件したことは、すでに濫用が始まってしまっている、と感じています。

かといって法的に真っ白かというとそれもけっこう難しいんじゃないかなというところもあるので、納得のできるプロセスで、納得のできる理由で立件すべきですよね、と思います。
たとえば、電気窃盗に近いと思うんですけど、どうですかね。もちろんこれで立件するのは難しいと思いますけど。

箱庭えくすぷろーらもあ攻略メモ

  • 潔癖バッジがないとたべものが腐る。潔癖バッジはクフ遺跡の超あにきの裏の隠し部屋にある。
  • マーグ火山の隠し部屋で手に入る鍛冶バッジ。使い方がわからなかったが、作者のツイッターによるとエンディングでドロップする石と鍛冶バッジを持って状態異常による武器変化を行うと石を消費して上位武器を作れるらしい。石を売って買ったほうが早い。武器持ち込みできないランダムダンジョンに上位武器を持ち込むための手段と考えるべきで、通常攻略に役に立つようなものではなさそう。
  • 凍結の剣の悪いお兄さんはサームイの武器屋レベル3から出現。店レベルを上げるために剣素材を売る必要があるんだけど、必要数揃えるのに時間がかかる。吉松先生の武器を破壊してなまくら剣をドロップさせてそれを壊すと上剣素材になるのでこれを調達すると短縮できる。
  • ナワオキ武器屋レベル5でおまもりが買える。おまもりは他に嫌われ状態のサームイ草原のかまくらで買える。たぶんかまくらのほうが早いので、無理してふぇち素材集めなくてもいい。ふぇち素材を集めるならトトリの幼女に負けるときにけしからん液体か水をぶちまけてドロップさせる。5、6個手に入るのでここだけでレベル4くらいにはできると思う。吉松先生からもドロップするので吉松先生からも回収しておくといい。
  • 低難度と高難度とでダンジョンの構成違う? 熟練者でしかやってないからわからないんだけど、フリーゲーム版からダンジョンの構成がすっかり変わっている。マーブイ灯台は葉っぱの足場がなくなっているし、アンコルワトは敵を倒さないと部屋が開かなくなっている。
  • けしからん液体や水で敵やボスの装備の耐久を削ると換金アイテムをドロップする。けっこういい金策になるので、けしからん液体や水は一個くらい持ち歩いておくと便利な気がする。
  • 本気らいおんを低レベルで倒すには、けしからん液体なりで防具を壊して、それから炎上か凍結させる。どっちも防御力が下がるので。器用特化でクリティカル狙いも考えたけど安定しない。
  • 強力な強化素材は効果を1.5倍に、究極の強化素材は効果を2倍にする。必中の剣や硝子の剣みたいな基礎値が高い装備に使うと強い。
  • 強化された装備は壊すとその名前の強化素材が手に入る。強化ツール拾ったら適当な壊れやすそうな装備に使って、ほしい強化がついたらその装備を壊して強化素材を取り出して、強化したい装備にあらためてつければいい。

ダンジョンメーカー

よいゲームだとは思うのだけど、手放しでは褒めがたい。15~20時間くらいはプレイしたと思う。 プレイ体験はおおむねよかった。値段分の価値はある。

よいところ

  • グラフィックが良好
    美麗なドット絵。しかもよく動く。が、日数を重ねるとエフェクトで隠れて何が起きてるのかわからない。それでもユニット一覧や配置を眺めているだけでも楽しい。
  • 戦術・戦略の幅が広い
    使えないスキルというのも実際にはあるものの、スキルの組み合わせ、部屋の配置を考えるのは楽しい。
  • 選択の繰り返しの楽しさ
    このような選択の繰り返しは他のローグライクゲームにもあるけれど、ランダム三枚から一枚選ぶというのは完全なランダムよりも優れたアイデアだと思う。考える余地があるのは楽しい。自分の考えを反映できることが楽しい。

よくないところ

  • 時間がかかりすぎるのでリプレイ性が低い
    一プレイの時間が長いが、そのわりに得られるリターンは少ない。
    たとえば100日目指してプレイして90日そこらで死ぬことが続くとかなりつらいが、これはまだ転生経験値による魔石がもらいやすい頃なのでそれほどつらくない。
    200日到達で100日越えて死ぬのを繰り返すのはけっこうしんどい。100日到達までにけっこう時間かかる。でも死ぬと無。200日目指す頃だと、転生経験値で魔石がぜんぜんもらえなくなってきてるので。
    モンスター引き継ぎが早い段階で手に入っていれば、スキルを厳選したりとかの楽しみもあるんだけど。
    死からフィードバックを得て次のプレイに反映させるにせよ、フィードバックループに時間がかかりすぎる。
    戦闘4倍速とか8倍速とかできるようにしてほしい。

  • 魔石ガチャによってレベルデザインが無になっている
    魔石ガチャの結果は悪いときは悪いし悪い結果が続くと悪い。
    実績によって得られるリターンを固定化するほうがレベルデザインとして優れている。
    たとえば100日目到達で新魔王追加とか。新しい魔王が使えるようになるなら100日目指そう、ってなるが、今だと最初にもらえる転生経験値報酬の魔石で一発で魔王を引くこともあれば、そうでないこともある。
    プレイヤーに選ばせるべきでもない。プレイヤーはその有用性を正しく判断できないので。
    もちろん最初の10回くらいでモンスター引き継ぎがまったく出ないとかもあるし、ぼくは最初にプレイしたとき15回の魔石ガチャで一度もモンスター引き継ぎも部屋引き継ぎも出なかった。そういうこともある。
    ここは課金要素でどうにかなるところではあるのだが、課金要素を開放したところで、やはりレベルデザインはそこにない。プレイヤーの習熟に合わせてあたらしい要素がアンロックされていくという難易度と自由度の曲線はそこに存在していない。

  • 実績解除後のエンドコンテンツがない
    このゲームひととおりの実績を解除しても魔石ガチャ70回分にはならない。魔石ガチャで得られる140個の要素のうち70個を開放すればゲームに必要な要素はひととおり揃うようにできているらしいが、転生経験値の報酬とあわせて70回分の魔石貯まるんだろうか。たぶん貯まるんだと思うが、最後のひとつがあこや貝だったりするとつらそうだなという気がする。おそらくハボリムのペトロクラウドみたいなものなので、なしで難易度10の340日到達するほうが楽しそうな気もする。
    ひととおりの要素が揃ったところで新戦術を開拓する楽しみとかはあるんだけど、それが本来は難易度10の340日到達とかであるべきなんじゃないのか、と思っている。クリア後の裏ダンジョンで最強武器が手に入ったときの、この武器何に使うねん感というか……。
    もっともぼくはまだ100日そこそこしか行けてないので、まだやることはたくさんあるのだが。

  • プレイが単調
    同じBGMを聞いているのはわりと厳しい。これで飽きのこないBGMならよかったんだけど、個人的には気にいるほどでもなかった。悪くはないけど、ふつうのBGMだと思う。
    日数重ねたらBGMが変わったりしたほうが体験がよい。100日越えた時点でBGMが変わるとか。
    同じ画面を見ることに対してはそんなに抵抗はない。同じBGMを聞き続けるのはくるしい。

  • UI が悪い
    権能誤タップしすぎる。権能に限らないが全体的にタップ領域について改善の余地がある。
    戦闘中にスクロールするときにスライドでスクロールするんだけどタップで権能1が発動する。やめろ。魔王の部屋が見たいだけだ。
    あとこれは iOS 固有の問題の気もするが、バックグラウンドに移行するときにタップ判定が残っているのか何なのか、バックグラウンドからの復帰時にその日のカードが勝手に選ばれることがある。

この値段でこれだけ遊べたら充分だとは思うのだが、10時間そこらで実績100%にしてお腹いっぱいになるまで遊べる箱庭えくすぷろーらもあのほうが時間のない社会人にはやさしいな、ということを箱庭えくすぷろーらもあをやりながら思った。モンスターのドット絵がぬるぬる動くところも見られるし。