Glare 3 やった

Glare 1 やったのけっこう前のことなんだけど続編が出てること最近知ってプレイ。

Glare 1 はフリーで18禁、2はフリーで全年齢、3は有料で18禁。グレアさんとイチャイチャするのがゲームの根幹にあるのでエッチシーンあったほうがいいのはいいんだけど、抜きにしても SF 短編として面白かった。1と2はフリーゲームなので気になったらやってみてほしい。

Glare シリーズというのは、キーワード入力式のアドベンチャーゲームで、会話の中で明示的にあるいは暗黙的に提示されるキーワードを入力することでゲームが進行する、きょうびめずらしいスタイルのゲームだ。きょうび、というのは、こんにちのアドベンチャーゲームは、究極、選択肢すらない。それがもはやゲームと呼べるかどうかはさておき、平均的なアドベンチャーゲームは、基本的には提示される選択肢を都度選択するのであって、自分から任意のタイミングで行動を起こすゲームというのはめずらしくなっている。そういうタイプのゲームはポイント・アンド・クリック形式で発展していったこともあり、こういうクラシックなゲームがあたらしく作られることはほとんどない。しかしながら、PC版のポートピア殺人事件のように、そのようなスタイルのゲームが流行した時代というのがあった。この形式はやがて入力可能なキーワードがコマンドリストとして表示されるように簡略化され、オホーツクに消ゆのようにコマンド選択式にかわり、更には会話の中での選択肢という方式に置き換わっていき、いまのような選択肢方式のアドベンチャーゲームが主流になっていく。
そうしてキーワード入力式が選択肢方式になってアドベンチャーゲームが失ったものはなにかというと、明示されない選択肢の存在であり、手がかりを得て真相を解き明かす探求要素だった。そういう意味で、Glare はアドベンチャーゲームの探求要素の復権であり、ルネッサンスだとぼくは思っている。

キーワード入力がグレアさんに検索をお願いする、という体裁になっているところも含め、いまあえてキーワード入力方式であることの意味づけはうまくいっており、作品の雰囲気作りにおおいに貢献しているし、1 ではこのシステム自体が最終的な解決に深く関わっているので、Glare シリーズはこの形式だからこそだと強く思う。きょうびめんどくさいと思うかもしれないが、ポイント・アンド・クリック式の脱出ゲームをたまに無性にプレイしたくなるように、人間には隠されているものを解き明かしたい欲求がある。

アンドロイドものが好きな人にはぜひやってほしい。3 のほかに 1 のリメイク版とかもあるのでどうぞ。

Glare1more

Glare3

続・戦闘がないRPG

aoitaku.hatenablog.com

ゲームボーイカエルの為に鐘は鳴るというゲームがありまして、ジャンルはアクションRPGなんですが、アクション要素はシンボル遭遇システムの敵避け程度のアクション性で、かといってRPG部分については戦闘は自動、しかも乱数なしなので、絶対に勝てない敵には絶対に勝てないし、ダメージを受けずに倒せる敵は必ずノーダメージで倒せます。でもお金を貯めて武器防具を買ったり、ステータスアップアイテムを取って成長したりという要素があり、RPG同様のリソースマネジメントと探索の要素があります。

前回の記事で「戦闘を抽象化してもRPGとして成立する」ということを書きました。このゲームをやってもらえればおおよそ伝わると思っています。

さて、もう一作品紹介するのですが、ノーラと刻の工房の開発に携わった岡澤Dが手がけたゲームにオアシスロードというものがあります。
このゲーム、別に戦闘要素を抽象化しているわけではないのですが、ゲームバランスの調整不足によって、戦闘がリスクとしてはほとんど機能していません。
このゲームでよりリスクとして効いてくるのはどちらかといえば食料と燃料で、とはいえこれもふつうにプレイしていればそんなに問題になるものではないですが、回復アイテムの所持数がダンジョン探索限界に影響することを考えると、食料と燃料がおおむね似たような仕組みとして機能しています。
それから、プレイヤーキャラクターのステータスが交渉や探索に影響していて、このステータスの成長が戦闘以外のところでゲームの進行条件として効いています。このゲームにおける進行の障害となる要素は、戦闘よりもむしろ交渉や探索のほうであり、レベルアップシステムは戦闘以外の要素に対してもゲームの進行をコントロールするのに使えるということがよくわかります。

前回の記事で触れたロロナのアトリエをはじめ、アトリエシリーズには錬金術レベルが存在していて、このレベルによって上位アイテムの作成難度がコントロールされています。上位アイテムを作るにはレベルを上げる必要があり、レベルを上げるためにリソースマネジメントをする……という点について、実は戦闘パートがなくても RPG の動きをする要素が整っているわけです。

ここまでをまとめます。

  • RPGは探索とリスクコントロール、リソースマネジメント、成長の要素で構成される。
  • 探索は抽象化してよい。探索によって何らかのリソースを得られるかわりに、何らかのリスクを負う。
  • プレイヤーはリスクとリターンを天秤にかけながら、どれくらい探索を続けられるか、探索にどの程度リソースを投じるか判断する。
  • リソースを投じることでプレイヤーキャラクターが成長し、成長によって直接的に、あるいは探索限界が拡大されることによって間接的に、行動範囲が広がる。
  • リソースの投入先は戦闘でなくてもよい。探索でもよいし、直接プレイヤーキャラクターの成長要素に投入することもある。

このあたりを踏まえて、戦闘要素を除外しても RPGRPG の味わいを保ったままで成立するかどうか試してみたいと考えています。

戦闘がないRPG

いまさらロロナのアトリエをプレイしていまして、正確にはPS3の頃に買ってちょっと遊んだんですがPS3が置物になっててプレイしてなかったのを、第四作が出る前におさらいしておきたかったので、Switch版の3部作全部入りのやつを買ってプレイしているんですが、PS3版やってた当時に途中でプレイしなくなった理由、それからノーラと刻の工房は周回プレイするくらいには遊んだ理由と考えたりしていました。

こないだ買ってちょこちょこ遊んでる状態なのでまだクリアはしてなくて、でも期間的にはあと一年半というところに来ています。

Switch版ロロナは新ロロナなのでもとのロロナよりも遊びやすくなっています。まあ遊びやすくなってるから遊べた、ということはあまり感じていなくて、Switchで気軽にスリープして気軽にレジュームして遊べるのがたぶんよかったんじゃないかなと思います。ノーラを繰り返し遊べたのもそこはたぶん関係あるんですが、ただなんていうかロロナ、ガワのよさにかかった工数に見合う面白さのゲームになっているかっていうとぜんぜんそんなことない気がしてしまう。
ノーラと刻の工房はダンジョン探索を排除して画面に表示される採集ポイントをタッチして採取っていうすごい割り切ったデザインにしてるんですが、正直これでいいと思います。ロロナのダンジョン、別に3Dのキャラクターを歩き回らせるほどのものではない。新ロロナになって街の中でファストトラベルできるので余計にそう思ってしまう。

で、ここからが本題なんですが、RPGって本当に戦闘要素必要ですか?

アトリエシリーズの核の面白さって、素材を集めて合成するの繰り返しで拡大再生産するゲームで、ゲーム内に設けられた数々の期限は制約として機能していると思っています。採取のリスクとして戦闘要素を取り入れていて、リスクを許容範囲内に抑えるためにキャラクターの強化のために時間とコストをかけなければいけないっていうスケジュール管理が肝っていう感じです。もっとRPGパートに特化したシリーズもありますけど、基本的にはこれが核になっています。

戦闘パートは報酬獲得のリスクとして存在するので、リスクになる要素なら戦闘パートでなくても構わないわけです。

たとえば戦闘を排除して探索メインにしてもよく「歩き回ってダンジョンを踏破すると探索効率が上がるけど、素材採取にかけられる時間はその分減る」みたいなシステムにして、探索には食糧と水を消費して、探索時に乱数で食糧と水が減るようにすると、リスクとリターンを天秤にかけてどう探索するかプレイヤーが考えられるようになります。

RPGから探索パートを除外して戦闘とリソースマネジメントだけに特化してもRPGとして成立することは、探索パートを抽象化したゲームがちゃんとRPGの楽しみを持っていることからわかります。 逆に戦闘を抽象化して探索とリソースマネジメントに特化してもRPGの楽しみを損なわずにちゃんとRPGになるんじゃないのか?ということをずっと考えています。

書こうと思ったけど書いてない記事がたくさんあるけど年内に書かないと意味がなくなってしまうので総ざらいします2018

2018年の出来事については2018年のうちに書いておきましょう。

続きを読む

年の瀬なのでアドベントカレンダーについて思っていることを書く

アドベントカレンダーに気合の入った記事を書くのをやめて普段から書いてください!!!!!!!!!!!

とはいえ自分自身普段のブログの更新も覚束なくなっているので大きな声で言いにくいんだけど、記事の優先度として、まず普段から書きましょうというのが一つ。アドベントカレンダーで実はこうでしたみたいな話はやめて、そういう大事なことはもっと日常的に公開していきましょう。知見の共有大事。

その年になんも知見を記事に起こせてなかったのでアドベントカレンダーの時期くらいはちゃんと書くかみたいなのは気持ちはめちゃくちゃわかるし自分自身そうだったからそうなんだけど、できるかぎりやめたほうがいい。この時期に書いた記事ってだいたい読まれないので、大事な話はもっとなんでもないときにしましょう。とはいえ年内にしといたほうがいい話だから書くとかは実際あるので書きましょう。

アドベントカレンダーですべき話っていうのは実際あんまりなくて、たとえばその年の総括とかは12月に書くものなので仕方ないんですけど、別にアドベントカレンダーっていう体でしないといけないものでもない。ふつうに12月に日記書いてもいいんですよ。

アドベントカレンダー、ぼくが知ったのは10年くらい前で、Perlアドベントカレンダーだったんですけど、「きょう覚えるワンライナー」みたいな内容3行くらいの話だったんですよ。こういうのでいいのでこういうのに回帰しましょう。

あとぼくがアドベントカレンダーを主催しはじめた頃はまだ一応「昨日は〜さんの〜っていう記事でした」っていう感じで一言くらいコメントを書きつつ、「明日は〜さんの記事です。お楽しみに」で締める、っていうのをやってたんですけど、これもちゃんとやったほうがいいというか、これやらないならアドベントカレンダーの体にする意味ある?って思ってます。やるの大変なのはわかるんだけど、やらないんだったら普段の記事と一緒なので。

個人的な好みでいうと、アドベントカレンダーにはむしろ時事性がなくていつ読んでもいい内容でしかも重くない、軽いやつ、「この関数のこのオプションはこういうときに使います」くらいの小ネタでよくて、そういう普段から目にしておきたいけど見落としがちなやつをもう一度拾い上げるための総集編みたいなものでもだいぶ存在意義あるよねっていう気持ちがあります。これくらいみんな知ってるよね?みたいな考えはいますぐ捨てましょう。

こちらからは以上です。

ブラウザ版 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階層とかある。どっちかだけにしないと厳しいように思います。
バージョンアップで階層数が減ってそのあたりは緩和されたんですが、個人的には階層数はそのままでもよく、フロアの広さを制限したほうがよかったんじゃないかなあという感じ。階層数が多い方がモンスターハウスや宝箱フロアの抽選回数増えるので。

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

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

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

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

まとめ

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