ユウゴローグ：一部カードの上方修正を計画中です→実施しました

ユウゴローグをリリースして一週間が経ちましたが、個人製作の趣味のゲームにかかわらず、今も一定数のアクセスをいただいております。ありがとうございます。

本ゲームはミニマムな構成のため、公開した時点の仕様で一応の完成と考えておりますが、プレイ環境の改善のために以下の変更を行う予定です。

カードの効果の上方修正

1. 渾身の一撃: トラッシュの武器の枚数×10のダメージ。
   →トラッシュの武器の枚数×15のダメージ。
2. よみがえる一手: トラッシュから武器1枚を選んで手札に加える。
   →(対象制限の緩和を検討中)
3. 三角のお守り: 3ターン目なら敵から受けるダメージが0になる。
   →このターン中に武器を使わないなら、敵の攻撃を回避する。

1. 渾身の一撃のダメージを5増加

渾身の一撃は使いやすい効果を持ちますが、ダメージを伸ばすことが意外と難しいため、対策としてシンプルにダメージを増やすことにしました。

プレイヤーが渾身の一撃のダメージを伸ばすには、デッキ内の武器カードを増やす必要がありますが、これは初期手札の多くが武器になるリスクが上昇し、展開の幅が狭まります。手札に渾身の一撃が2枚あるとダメージが大幅に伸びますが、残りの3枚にドローカードが含まれていないと、結局ダメージは伸びません。また、トラッシュを再利用するカードとは相性が悪いです。これらの背景から、ダメージの増加が必要と判断しました。

2. よみがえる一手の対象制限を緩和(検討中)

よみがえる一手はドローカードと組み合わせた時に、簡単にデッキの大半のカードを引き切ってしまい、難易度を大幅に変える恐れがあるため、リリース前に対象を武器カードに制限していました。

現在の効果でも、武器のバフ効果を持つカードを後からドローした時に、トラッシュから武器を拾って再利用する、という使い方はありますが、他のレジェンドカードよりも明らかに優先度が下がっていました。

対策として、このカードの対象を「剣/槍/斧と書かれたカード」に変える案を検討しています。限定的とはいえドローカードと組み合わせることが可能になるので、引き続き動作を検証中です。

3. 三角のお守りの条件と役割を変更

三角のお守りは敵から受けるダメージを0にする強力な効果を持つため、リリース当初から厳しい条件を付けていました。その結果、確実に勝ちたい1周目に回復を捨てて入れるほどでもなく、運要素の多い2周目にわざわざ入れる余裕もなく、ノーマルカードの中でも優先度が低くなりがちでした。

対策として、このカードの役割を変更し、単なる回避カードではなくターンを消費して初期手札を引き直すカードと位置付けることにしました。

このカードがプレイヤーに回避状態を付与しようとするのは同じですが、ターン中に武器を使っていた場合は付与されません。また、回避状態が付与された後に武器を使った場合、回避状態が解除されます。

想定している使い方としては、初期手札が悪かった時に引き直す目的で使用します。武器カードさえ使わなければ良いので、ドローカードを使って手札を増やしたり、回復カードを使ってHPを増やしても問題ありません。ただし、本ゲームは10ターン以内に敵を倒さないと、敗北になります。

一部の画面にゲームのバージョン番号を表記

今回の更新でカードの効果が変わるため、以下の画面にバージョンを表記します。

• 設定画面: 現在のバージョンを表記
• 挑戦の跡のデッキ画面: 当時のバージョンを表記(ただしリリース直後のデータは空欄)

今回の更新のバージョンは「1.0.1」で、挑戦の跡のデッキ画面にも表記されます。
一方、リリース直後のバージョン(内部的には1.0.0)は、以前からの表示内容を維持するため、挑戦の跡のデッキ画面に表示しません。

つまり、今回の更新が実施されると、古い挑戦のデッキ画面は今まで通りバージョンの表記なし、新しい挑戦のデッキ画面は1.0.1が表記されます。

追記：本日15時にアップデートします

動作テストの結果が良好だったので、本日の15:00からアップデートを実施します。ゲームのファイルサイズが小さいので、アップデート自体は一瞬で終わります。

追記：予定通りアップデートを実施しました

バージョン1.0.1になりました。

ゲーム制作時のテキストの折り返し位置が悩ましい

今回はカードを使うゲームを作ったので、折り返しの必要なテキストが沢山ありました。

加え/る、トラッシ/ュ

Godotの技術的な話に絞ると、Labelクラスで使える折り返しモードは一長一短あります。
基本的にはARBITRARYから使い始めますが、日本語のテキストをそのまま表示するので2ケタの数字の真ん中で折り返す恐れがあり、WORD_SMARTは割といい感じですが、句読点が右端に掛かりそうな時に中途半端な位置で折り返されます。WORDは日本語だとそこまで恩恵を感じませんでした。

幸い、ゲーム内のカードの種類は21枚だけなので、カードを1枚1枚チェックして手作業で改行コードを入れて対応しました。とはいえ「改行しすぎて縦に長くなったり、右側がスカスカになるのも不自然」「単語の位置が微妙で改行を入れるべきか判断が難しいケースがある」「手作業が基本になると、テキストに変更が入った時に改行がやり直しになる」といった問題があり、もっと大きなゲームでも同じように対応するか？ というと悩ましいところです。

Godotでダイアログを毎回作成する代わりに表示切替にしたら、スクロールバーの位置が戻らない

最近作ったローグライトは、表示専用のダイアログがいくつかあります。デッキをクリックしたらデッキのカード一覧を表示するダイアログが表示され、トラッシュも同様です。もしカードの効果でトラッシュから1枚選ぶことになったら、トラッシュを参照する選択ダイアログが表示されます。

デッキの内容を表示するダイアログ

このようなシンプルなダイアログは、インスタンスを毎回作成するよりも、必要な時に表示だけ切り替えた方が無駄が少ないように思えました。

そこで、Godotのエディターに表示されているノードツリーの最後にダイアログを追加して、初期状態は非表示にしました。一見すると上手く動いているように見えましたが、スクロールの位置が一番上に戻っていないことに気づきました。

スクロールバーを一番上や一番下に移動する方法は、検索すれば過去のフォーラムのやりとりなどから見つかります。

How to get scrollbar to automatically scroll to bottom? - Help - Godot Forum
https://forum.godotengine.org/t/how-to-get-scrollbar-to-automatically-scroll-to-bottom/74013

要点だけ抜き出すと、以下のようなスクリプトでScrollContainerのスクロールバーの位置を一番上に戻します。(deferredが付くメソッドやawaitを使ってタイミングの調整が必要かもしれません)

scroll_container.scroll_vertical = int(scroll_container.get_v_scroll_bar().min_value)

今回は、どのダイアログもスクロールバーが1個だけなので、上記の処理を組み込むことで解決しました。

仮にスクロールバーが沢山あるダイアログがあった場合、上記の処理をstaticメソッドとして共通化したり、ScrollContainerを継承するクラスに実装して自動的に呼ばれるようにするなどの対処法が考えられます。しかし、そこまでの手間を掛けるよりも、自分の中で基準を決めて、複雑なダイアログは無理にノードツリーに保持しない方がよさそうです。

Godot でデバッグ中に This control can't grab focus という警告ログが出る

一般的な原因と対処法

警告ログの例

Godotで特定のコントロールにフォーカスを設定したい時はgrab_focusメソッドを使いますが、コントロールの無効化と併用している場合に"This control can't grab focus"という警告ログが出ることがあります。

対処法としては、grab_focusメソッドを使用しているスクリプトを探して、対象のコントロールがフォーカスできる状態かチェックしてからgrab_focusメソッドを呼び出すようにします。

自分に起きたこと

カードを使うゲームをGodotで作ってデバッグしていると、手札やデッキや捨て札をクリックするわけですが、たまにGodotのエディターに"This control can't grab focus"という警告ログが出ることがありました。

全てが解決した今なら、警告の内容が「Controlがフォーカスできない状態なのでgrab_focusが失敗しました。set_focus_modeを使ってフォーカスの取得を可能にしてください」と言われていることが分かるのですが、当時は「カードの操作には何の問題もないのに、なぜset_focus_modeの話が？」と疑問が深まるだけでした。

警告に「grab focus」とあるので、プロジェクトフォルダを検索してみると、カードUIのスクリプトがヒットしました。カードにマウスカーソルを近づけるとカードを手前に表示する処理で、カードゲームとしては良くある挙動です。

func _on_mouse_entered() -> void:
    ...
    if focus_mode != Control.FOCUS_NONE:
        grab_focus()

問題のスクリプトは、mouse_enteredイベントでgrab_focusを呼び出してフォーカスを取得するように実装されていました。事前に「if focus_mode != Control.FOCUS_NONE」でフォーカス可能かチェックしているので、通常はこの対応で問題ないように見えます。

しかし、カードUIの実装を調べてみるとfocus_behavior_recursiveというプロパティも使ってフォーカスの可否を制御していたため、チェックの際はget_focus_mode_with_override というメソッドを使う必要がありました。公式ドキュメントにも、focus_behavior_recursive が影響することもあるのでget_focus_mode_with_override を使うように書いてあります。

Control.focus_mode  — Godot Engine (stable) documentation in English
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-focus-mode

以上の調査結果から、以下のようにチェック処理を変更することで解決しました。

func _on_mouse_entered() -> void:
    ...
    if get_focus_mode_with_override() != Control.FOCUS_NONE:
        grab_focus()

Godotのオーディオバスの設定が便利。手っ取り早くミュートと音量調整の関数を実現できる

BGMとSEのオーディオバスを追加したところ

オーディオバス — Godot Engine (4.x)の日本語のドキュメント
https://docs.godotengine.org/ja/4.x/tutorials/audio/audio_buses.html

公式ドキュメントにもちゃんと書いてある設定なのですが、Godotのエディターの一番下に表示されている「オーディオ」タブを選択すると、ゲーム内の音声の出力方法を制御できます。

といってもカジュアルなゲームでやりたいことは「ミュートを切り替える」「BGMとSEでボリュームを分ける」の2点です。

「バスを追加」ボタンを押すとMasterバスの隣に新しいバスが追加されるので、1番目の名前を「BGM」、2番目の名前を「SE」にします。他の設定はいじりません。

GDScriptからオーディオバスを使って音声を調整する際は、まず、オーディオバスのインデックスを取得しておく必要があります。

var master_bus_index := AudioServer.get_bus_index("Master")
var bgm_bus_index := AudioServer.get_bus_index("BGM")
var se_bus_index := AudioServer.get_bus_index("SE")

ミュートの切り替えやボリュームの調整は、以下のような関数を作って他のスクリプトから利用できるようにすると便利です。

func is_audio_enabled() -> bool:
    return not AudioServer.is_bus_mute(master_bus_index)


func set_audio_enabled(enabled: bool) -> void:
    AudioServer.set_bus_mute(master_bus_index, not enabled)


func set_bgm_volume(volume: float) -> void:
    AudioServer.set_bus_volume_db(bgm_bus_index, linear_to_db(volume / 100.0))


func set_se_volume(volume: float) -> void:
    AudioServer.set_bus_volume_db(se_bus_index, linear_to_db(volume / 100.0))

今回のローグライト開発はどのように進んだか

1. まずはプロトタイプから

RPGツクール本来の動作から外れた開発を試みて断念した後、しばらくは他のジャンルのゲームを作ることを考えたり、制作ツールを変えることを考えたりしていました。

最終的に残ったアイデアは、「『ドラゴンボール 大魔王復活』(1980年代のファミコンのソフト)みたいにカードの数字で戦ったりマップを移動できるゲーム」というものでした。ただし、開発規模を抑えるために以下のように要素を絞り込みました。

• マップは1本道で20マスくらい
• カードは数字とスキルが書いてある(敵に2ダメージ、自分のHPを3回復、など)
• 手札は5枚、デッキは最大20枚(たとえ1歩ずつでも20マスに届くように)

そして一番重要な点として「開発はテキスト中心のプロトタイプから始める」ということを事前に決めていました。開発の初期段階から色々な要素を盛り込んで大変なことになったので、今回は小さく始めることを意識しました。

プロトタイプのUIはテキストボックスとリストボックスとボタンだけなので、統合開発環境としては起動が速いGodot Engineのエディターで実装しました。

2. さらに要素を絞り込む

プロトタイプのカードの効果を検討しているうちに、当初のアイデアのコア要素ともいえる「カードの数字で移動」をやめて、バトルに絞った方が良いのではないかと考えるようになりました。

カジュアルに遊べるように一本道のマップとしたのですが、ゴールまでの進み方にバリエーションが無いなら1枚のカードを移動とバトルで取り合うことにあまり意味を感じられず、結局は移動もマップも無くしてバトルに集中することにしました。

最終的なプロトタイプ。
起動直後にバトルが始まる

プロトタイプの時点ではハイスコア機能も入っていたのですが、カジュアルに遊べる代わりに運要素も大きいゲームには馴染まないので、外しました。

3. カードもナーフする

プロトタイプの主な目的は、ゲームの全体の流れをテキストで確認することでしたが、最も重要な目的の1つが、カードの効果の検証でした。カードを使ってHPを増やしたり減らしたりするのは、テキストベースのプログラムでも確認できるからです。本格的に画像や効果音を付ける前に、このままカードを実装しても問題ないか確認することが重要でした。

今回制作したゲームはドロー効果のカードが多いので、常に大量ドローが発生した場合のことを考える必要がありました。その結果として、例えば以下のようなナーフが発生しました。

• トラッシュからカードを1枚選んで手札に加える →トラッシュから「武器」1枚を選んで手札に加える。
• HPを40回復(レア：枚数制限なし)→HPを「20」回復(レジェンド：デッキに1枚まで)

ナーフされたカードの例

4. ついに正式なUIの開発を開始

プロトタイプを何度も遊んでみて、繰り返し遊んで面白いと感じたので、ようやくビジュアル面を含めた正式な開発を始めました。

GodotでUIを作成する基本的な手順は、過去に3マッチパズルを開発した時に経験済みなので、あとは問題に衝突する度に公式ドキュメントやフォーラムのやりとりを見て学んで、修正する日々の連続でした。(GodotのAPIやコンポーネントの話は、また別の機会に書きます)

画面に配置するパーツを作成

5. カードUIをどう実現するか

カードが画面内を移動したりプレイヤーに操作させる機能は、さすがに自作するのは大変なので、Godotプラグインを使うことにしました。以下のプラグインが候補に挙がりました。

Card Framework
https://github.com/chun92/card-framework

APIとドキュメントが整備されているカードUIフレームワークです。サンプル実装のフリーセルがあります。カードの情報をJSONに記述するので、他のソフトでカード情報を編集しやすいです。

Simple Cards
https://github.com/twdoor/simple-cards-v-2

カードゲームにありそうな要素を抑えつつ最低限の機能が実装されているライブラリです。
サンプル実装のソリティアがあります。全体的にドキュメントがやや不足しています。

Simple CardPileUI
https://github.com/insideout-andrew/simple-card-pile-ui

手札/デッキ/捨て札などのカードパイルの基本的な機能を提供するライブラリです。JSONに記述されたカード情報を読み込みます。手札のカードで敵と戦うサンプルがあります。

今回制作するゲームに対し、Card Frameworkは明らかにオーバースペックで、Simple CardPileUIはカードパイル以外の機能が不足していたため、Simple Cardsを採用しました。

6. 画像と音声

ゲーム内の画像はゲームの雰囲気に合わせて、 opengameart.org で公開されているドット絵を置く予定でした。しかし、ゲームの内容のシンプルさを考えると線画の方が合っていると思うようになり、ベクター画像エディタのInkscapeで自作することにしました。
ここでInkscapeを選択したおかげで、異なる媒体ごとに異なるサイズの画像が必要になった時に、過去に作った画像素材をパーツとして組み込むのが前より楽になりました。

Inkscapeで全てのカードの画像を作って管理

音声は有名な素材サイトをいくつか調べて回り、BGMやサウンドを組み合わせて使っていました。しかし、動作テストで何度も聞いているうちに、素材サイトによって音声のボリュームの基準に微妙な違いがあることが気になってきました。

当初は音声エディタのocenaudioを使ってゲインを調整したこともあったのですが、全ての音声ファイルをこのやり方で対応していくのは現実的ではないと判断し、今回は OtoLogic の素材で統一しました。

7. ひたすら動作テストと修正

一番地味で長く大変な工程です。いろんな問題がありましたが、特に心が動かされたものを上げます。

・手札のカードにマウスカーソルを近付けると手前に表示されるが、その状態でカードの右半分の領域を操作すると、右隣のカードの方が反応してしまう。(z-indexで見かけ上の表示順だけを変更した場合に起こる問題。Godotのビジュアルツリー内の順序も調整して解決した)

・カードをグリッド状に並べた画面をスマホでスクロールしようとすると、たまたま指で触ったカードが選択状態になってしまう。(Godotのスマホ対応でよくある問題らしい。スクロールした場合は選択しないように座標をチェックすることで解決した)

・画面の外側が半透明に暗くなるタイプのダイアログがあり、スマホで暗い部分をタッチしてみたら貫通して操作できた。(入力デバイスを「押した」タイミングに反応する仕組みだったのが原因。マウスボタンを離したりスマホから指を離したタイミングで反応するように修正した)

・Godot Playerでゲームを表示すると画面右上に「ゲームを閉じるボタン」が表示されるが、ゲーム本体の「画面を閉じるボタン」と位置が近いことが判明した。(事前確認が足りていなかった。今回は画面を閉じるボタンを下に伸ばして対応した)

8. 初めての公開は1度きりなので、その前に

普段のミニゲームの制作であれば、ある程度作ったところで公開して、暇な時にSNSでも報告して、となるところですが、今回は趣味とはいえそれなりの経緯があるので、以下の対応を行いました。

・Godot Playerに掲載する紹介文をよく考えて書く(初見で読まれなくても、何かあった時に一番最初に読まれる文章なので)

・SNS向けの紹介文と紹介動画を作成する(投稿してすぐに誰かが見るというよりも、誰かに紹介する時に見せる短い紹介ページとして便利)

・Google Sitesにマニュアルを非公開モードで用意する(人間が読むというよりは、ゲーム内の名称や用語をゲーム外からテキスト検索できるようにするための対応)

9. ついに公開

公開先は以前に3マッチパズルを投稿した Godot Player と決めていました。

いつの間にか機能が増えて、新着リストに載る前の状態で下書きアップロードが可能になったので(実は前からあった？)、正式に公開する前に色々な動作テストができて助かりました。

最後にGodot Playerでゲームを公開して、マニュアルを公開し、SNSに紹介文と紹介動画を投稿して、改めて自分でもゲームを遊んでみて、ようやく完了です。

趣味のゲームの公開が上手くいくか心配になりすぎて胸が痛くなったのは、今回が初めてでした。無事に公開できてホッとしました。

ユウゴローグ：勇者が５回戦うローグライト

https://godotplayer.com/games/yuu_go_rogue 

シンプルなローグライトを制作した経緯

今回のローグライトを開発した経緯について、大まかですが触れておきたいと思います。

1. 最初は単なる願望

いつからか無料ゲームサイトやSteamを開くと、どこかのスペースで対戦カードゲームやローグライトのようなカードを使うゲームが表示されるようになり、何度も目にするうちに自分でも作ってみたいと思うようになりました。とはいえ、簡単ではないことも理解していたので、当時は機会があれば出来たらいいな、ぐらいの願望でした。

2. 良いゲームに出会って触発される

2025年7月にフリーゲームを探して遊んでいたら、以下のゲームに出会って夢中になり、改めてカードゲームかカードを使うローグライトを作りたい気持ちが強くなりました。

【ジャストリーサル】
https://freegame-mugen.jp/puzzle/game_11048.html
(作者サイトがHTTPS非対応のため、上記はゲーム投稿サイト『フリーゲーム夢現』のページ)

最初に選択したキャラクターや難易度によって初期デッキが決まるカードバトルゲームです。敵もプレイヤーと同様にデッキからカードを引いて攻撃してきますが、こちらに手札が見えているので、ある程度の対策は取れます。

カードゲームの経験が少ない自分でも、チュートリアルや難易度設定、魔力解放や特殊アイテムなどのゲームシステムに助けられて、十分に遊ぶことができました。

【NIJICA(サービス終了)】
https://store.steampowered.com/app/3603080/NIJICA/
(Boothのダウンロードページはアクセスできなくなったので、上記はSteam版のページ)

『にじさんじ』をテーマにした同人カードゲームです。カードごとの能力がだいたい1～2種類(例外あり)なので覚えやすく、分からないうちはコストの小さいカードを並べるアグロ戦略でもCPU戦は楽しめます。ソロモードのバリエーションも結構多く、1人用のカードゲームとしても楽しめました。

3. 転機はツクール

RPGツクールMZ

2025年10月にSteamでセール中のRPGツクールMZとMVを購入しました。フリーゲーム紹介サイトにアクセスしていれば必ず目にするソフトなので気になってはいたものの、触る機会が無いまま長い歳月が経っていましたが、今回これなら買ってもいいかな、と思う価格だったので買うことにしました。

早速自分なりにRPGを作り始めてみましたが、そこで気づいたのは、RPGツクールが基本機能で提供するゲームシステムは微妙に既存のRPGと異なっており、もし自分が知っているRPGの要素を入れたいならプラグイン(JavaScript)を組み込む必要があるということでした。
それ以来、プラグインを利用しつつ書き方も勉強した結果、自分のゲーム専用の小さなプラグインを書いてみることも出来るようになりました。

ツクールの素材画像を使ったオープニング画面の例。
この後の未来を暗示しているようにも

 最大の転機はTorigoyaMZ_QuickSkill.jsで、使い方の説明を読んで試しているうちに「MPをマナポイント扱いにしてカードの代わりにスキルを使うようにすれば、カードを使うローグライトのような動きが実現できるのでは？」というアイデアが頭に浮かび、そのアイデアが非常に気に入ったので本腰を入れて制作していくことにしました。

Torigoya ターン消費なしスキル - TorigoyaMZ_QuickSkill.js - #ツクプラMZ
https://plugin-mz.fungamemake.com/archives/938

さて、既存のローグライトと似たようなものを実現しようと思うと、コスト制限のあるスキルだけでは不十分で、沢山のバフやデバフのアイコンを表示できた方が、それらしくなります。当時の自分は既存のプラグインのJavaScriptにも手を加えられるようになっていたので、ステート横並びプラグインと累積ステートプラグインを改変して組み合わせることで、カウンターを併記したバフやデバフのアイコンを表示できるようにしました。

NUUN ステート横並び表示 - NUUN_StateIconSideBySide.js - #ツクプラMZ
https://plugin-mz.fungamemake.com/archives/3728

累積ステートプラグイン (v1.0.9) - KEN_StackState.js - #ツクプラMZ
https://plugin-mz.fungamemake.com/archives/8014

カウンター付きステートを表示する例

ビジュアルやサウンドを充実させるため、各種素材を購入しました。例えばキャラ画像は以下の素材を購入して、asepriteで一部改変して使用しました。

【オールインワン】８bitレトログラフィック素材集 - K.BOOTH - BOOTH

https://booth.pm/ja/items/4458458

ここで想定していたローグライトは、プレイヤーがゲームを開始するとキャラ選択画面が表示されて、キャラごとの特徴が説明されます。

制作中だったローグライトの開始直後の画面(タイトルは仮)

次にマップ画面が表示されて、ランダム配置された敵キャラや宝箱、イベントやショップなどを通って最後にボスを倒すとクリアです。マップは常に3択になるように、過去に選択しなかった通路は使えなくなります。このようなマップを繰り返し攻略します。

制作していたローグライトのマップ画面

4. そして泥沼へ

制作作業としては、この時点で既に悪い流れにハマっていました。

例えばクイックスキルはわざわざ注意書きに「複雑なことをするとおかしくなる可能性があります」とあるように、RPGツクールの処理の中では例外的な動作をしているのですが、自分は既存のローグライトで見かけた色々な機能を実現するためにクイックスキルを拡張しようとしてツクール本体の動作と不整合を起こし、断念するのを繰り返していました。

ある時は奇妙な興奮状態のまま、メモ帳に数日前と似たような実現性の怪しいゲームのメカニズムを最初から書き直していました。

またある時は、ツクールを起動して武器リストや魔法リストを思いつくままに埋めた後で「こんな大量の数値の妥当性をどうやって確認するんだ？」と途方に暮れたりしました。

特にツクールとは関係ない部分で頭を悩ませたのが、ゲーム内の攻撃力やHPの数値の範囲をどうするか、という点でした。読みやすさと分かりやすさを優先してパラメーターを1～9の範囲に収めると海外のカードゲームっぽくなりますが、そうすると1ポイントの違いが大きな差を生むことになるので、これはこれで全体の調整が難しくなりました。

そろそろRPGツクールのイベントエディタとプラグインのJavaScriptの間を行ったり来たりすることに限界が来ていました。

5. 興奮の終わり

ここから撤退が始まり、せめて短時間で終わるタイプのツクールゲーに出来ないかと、開発規模を縮小する目的でクイックスキルを外そうと思ったこともありましたが、もはやそんなことを実行する余裕もなく、最後は製作の継続そのものを断念しました。

断念の一番の理由は「やろうとしていることが自分には大きすぎて管理できない、妥当性の検証も出来ない」という点でした。

とにかく色々なものを放り込むことはできたものの、自分の手には負えなかった、というのが振り返ってみた印象です。

※ちなみに、クイックスキルの名誉のために付記しておくと、クイックスキル自体はちょっと変なケースでも動くように高度な対策が実装されており、一方でRPGツクール本体の処理の流れのような簡単には変えられない部分と衝突するような改変を試みると、さすがに上手くいかない、というのが実態でした。これは自分の事前確認の不足が招いたことです。

6. 堅実さを取り戻す

2026年上旬に、一本道を歩くシンプルなローグライトを作ることを考えました。

前回の反省を踏まえ、手札のカードに書いてある数値が歩数とパワーを兼ねるシンプルな仕組みで、四角いマス目が直線状に並んでいるマップをまっすぐ進んでゴールを目指す想定でした。

結局、開発には至らなかったものの、ゲームシステム全体をシンプルにするアイデアは、後の開発に引き継がれました。

2026年の夏が始まった頃、今回のローグライトの開発を始めました。

ただし、ビジュアルや音声をいきなり放り込んで始めるのではなく、まずは構想の中のカードが実際に遊べるのか検証するため、テキスト中心のプロトタイプを作ることにしました。

プロトタイプ

画面のほとんどの領域は1個の大きなテキストボックスで占められ、現在の状況を表すメッセージが次々と表示されます。分岐があれば画面の一番下にあるリストボックスで選び、ボタンを押して決定します。

2026年8月にプロトタイプの開発と調査が完了し、テキスト中心で遊んでも面白かったので、正式に開発を進めることにしました。この時点のカードの種類は17枚で、現在とラインナップが若干違っていました。(ゲーム公開時は21枚)

それから、やっぱり大変なことは大変で色々ありましたが、ようやく目的のローグライトが完成し、2026年10月4日に無料ゲーム投稿サイトのGodot Playerで公開することができました。

今回のローグライト開発の方で起きた色々な問題と奮闘については、また別の記事で触れたいと思います。