鳥小屋.txt

主に自作ゲームをつくったりしているよ。制作に関することやそうじゃないことのごった煮ブログ

トップ > 制作

自分用のブラウザゲーム置き場を作った話

制作

『プレポタ』

僕が今までつくったブラウザゲームを公開するサイトを作りました。

それが、↑この『プレポタ』です。『プレイ！鳥小屋ポータRu』の略で『プレポタ』。
このブログを書いている現時点で、過去10年くらいに作った16作品を置いています。思ったより増えたね。

PCやスマホのブラウザでゲームが遊べることはもちろんのこと、

  • ブラウザ内全画面やフルスクリーン表示対応
  • GoogleDrive連携でクラウドセーブができる
  • SNSシェア用のスクリーンショット撮影機能
  • ハイスコアランキング機能

みたいなところを用意しています。イメージは僕専用のアツマールのパチモン。

パチモンにも程があるだろ！

作るに至るモチベーション

ポエムパートです。ポエムに興味ない方は次の章まで読み飛ばしてください。

そもそもブラウザゲームの利点とは

ブラウザゲームの最大の利点は『自由』である ことだと思っています。

例えば iPhone のアプリは Apple に許可されたものしか公開することができませんが、ブラウザゲームはたとえ世界が認めなかったとしても、自分でサーバーを用意すれば自分の責任の元にインターネットで公開することができます。

※そういった意味では PC用のソフトは基本的に自由に公開できて素晴らしいですね

理想と現実

……と言いつつ、現実問題としては他の方が運営するプラットフォームで公開する場合がほとんどかと思います。

アツマールや PLiCy 、 ふりーむ！ など、既存のプラットフォームを使う利点としては、

  1. 集客が見込める
    • 既存のプラットフォームには既に人が存在しているため、その層にリーチできる
  2. 各プラットフォームが提供する機能が利用できる
    • 例：アツマールのAPI機能、PLiCy のミニ実況機能など
  3. 運用コストが比較的安い
    • 自分で公開場所を用意するのはそれなりに大変

などがあります。

このあたりがうまく自分にハマっているプラットフォームがある場合、そういったプラットフォームを活用するほうがメリットは大きいと思います。

実際、僕はこのあたりの観点で、アツマール と PLiCy を中心にゲームを公開していました。
（ふりーむ！も試してたけど、あんまり向いてなさそうだったのでやめました）

アツマールが忘れられない

その中でもアツマールは、本当に僕にハマる最高のプラットフォームでした。

僕のゲームの代表的な作風は『実績蓄積によるシナリオ進行のパズルゲーム』です。
パズルを繰り返しプレイすることで、実績がアンロックされていってシナリオが進む……というやつ。

まず、『パズルゲーム』はスマートフォンとの相性がとても良いです。そのため、スマートフォンからのゲームの遊びやすさというのは非常に重要でした。
特にスマホのブラウザはストレージ制限が厳しく、普通にブラウザゲームを公開すると、勝手にセーブデータが消されることがよくあります。この部分において、アツマールにはサーバーセーブ機能があったため非常にスマホにマッチしていました。

そして、パズルを繰り返し遊ぶ以上、簡単に『スコアランキング』のような機能を作れるのも魅力的でした。
ゲーム側で何もしなくてもモードを1つ増やすことができるため、これは非常に助かりました。

こういったところから、僕の作風と非常にマッチしていて良いサービスだったのですが、残念ながら2023年にサービス終了してしまいました。かなしすぎる(◞‸◟)

もうサービス終了から1年近く経ちますが、僕の中では今でもアツマールで開いた穴がぽっかりと残っていました。

僕のゲームをもう一度『あの形』で遊べるようにしたい

僕の作ったブラウザゲームたち。
これをもう一度『アツマールでできた体験』で遊べるようにしたい！

この気持ちがどうしても止まらず、様々な手段を考えました。

とはいえ、あまりコストがかかる手段は維持が難しいです。
サーバー代が毎月何万円もかかったりしたら困りますし、僕がスキマ時間で面倒を見れない規模になったら破綻します。

いろいろ考えた結果、自分専用のブラウザ公開スペースを作り、そこに最低限必要な機能を追加するというのが一番低コストにやりたいことを実現できそうだと考え、2024年2月ごろから準備を始めることになりました。

おまけ：考えたけどやめたこと

以下は考えたけどやめたことです

  • PLiCy で外部APIを頑張る
    • PLiCy は外部通信が許可されているため、外のサーバと通信していろいろできます
    • これを使って、外部のサーバと通信してサーバーセーブやランキングなどを作ることを考えました
    • が、ログインの仕組みとか作ろうとすると様々な制約から実現が厳しいことがわかり、諦めました
  • ブラウザゲーム投稿サイトを作る
    • いっそアツマールみたいな機能を持つ投稿サイトを作っちゃえばいいのでは！？（バカ）
    • 雑に試算してみたら、笑っちゃうくらいお金かかることがわかったのでやめました
      • 一般的には『大量のファイルの書き込みや配信』は高コストです
      • でもブラウザゲームってファイル数1000とか余裕であるよね、ウケる
    • そもそも僕ひとりだと監視とかできないから運営ができないですね

続けられない方法を選んじゃうと意味がないので、このあたりのことは考えるだけ考えてやめました。

どう実現するか？

要求を定義する

優先順位順に並べると以下のようになります

  1. 長期的に運用ができること
    • 僕が個人でやる以上、続けられなくなってしまうと困ります
    • お金がかかり過ぎたりしないか？
    • 面倒を見るのが大変すぎたりしないか？
    • 使うサービスが終了とかしたときに引っ越しができるか？
  2. セーブデータをサーバ保存できること
    • スマホのことを考えると必須
  3. ランキングなどの追加機能が用意できること
    • これがあって、あの体験が帰ってくるため

ここに書いてないこと、具体的には『集客』と『収益』は無視します。
そこを狙うなら既存のプラットフォームを使ったほうが確実に良いからです。

あくまで僕の実現したいことは、アツマールでできた『あのプレイ体験』の再現 です。
『アツマールの再現』ではない ため、サービスと良くするとか重視しません。

要求をもとに手段を選定

低コストかつ、引っ越し可能な構成にするため、以下のような構成としました。

デプロイ先は Cloudflare Pages

Cloudflare の提供するホスティングサービスです。
無料でかなり制限ゆるく使うことができるため、最近は個人サイトは全部ここに置いています。

単にHTMLなどを置くだけではなく、Workersの機能を利用してサーバサイドの処理を動かすことができるのも魅力的です。

その中で、特に決め手となったのは、D1データベースの存在です。

D1データベースを使うと、Cloudflare Pages（Workers）上でSQLiteが利用できます。スコアランキングなどの各種機能を実現する上では、馴染み深いリレーショナルDBが利用できるのは大きなメリットです。

また SQLite のインタフェースであることから、将来D1データベースが使えなくなるようなことが起きたとしても、自分のサーバーに引っ越せば同等のコードをそのまま動かすことができる可能性が高そう、というところも良い部分です。

なお、無料で使えるのですが、僕は Workers の $5/月 は払うことにしました。いろいろ制限も少なくなるし、お世話になってるしね。

SSG（Static Site Generator） + 小さなAPI という構成

サイト全体をでかいアプリケーションとして作ると保守が難しくなります。
特にWebフロントはブラウザのアップデートなど様々な外的要因によって大きな変化が発生する可能性は高いです。どこかでのタイミングで作り直しに近いことが発生する可能性は考慮する必要があります。

そう考えると『静的なHTML/JS/CSSのページ』と『小さなAPIサーバー』という2つのアプリケーション構成になるのが良いのではないかと考えました。

ページ部分とAPI部分を分けることで、それぞれ独立した技術を利用してサイト全体を構築することができます。また、静的なHTMLはデプロイ手段も無数にあることから、引っ越しの面でも良さそうです。

今回は SSG 用に Sveltekit 、 API用に Hono を使うことにしました。

Sveltekit はSSG専用のフレームワークではないですが、SSGの機能を持っています。
僕自身、結構 Svelte の記法が好きであることや、別のサイトを作る際にも Sveltekit を使っていたことから今回も採用しました。

Hono については、Cloudflare Pages を使うと決めた時点で、やはり Hono が良いだろうなと考えました。
非常に軽量ですし、書き味も良いです。 Hono をちゃんと使ったのは今回が初めてでしたが、人気が出るのも頷ける『良さみ』を感じました。

なお、ちょうど2月上旬に Honox が公開されていたため、途中までフロントは Honox で作っていました。が、ちょっと機能要求的に Single Page Application にしたほうがいろいろ都合が良いな……という点が出てきたことから、途中で Sveltekit にしました。Honoxはまたの機会に。

ゲームファイルの配信はCloudflare R2で

ゲームファイル自体は別途 Cloudflare R2 にアップロードして配信することにしました。

もともと個人サイトで公開していたゲームは Cloudfront + S3 構成だったのですが、R2のほうが用途的に無料になる部分が大きかったことから今回は R2 を使ってみています。

ちなみに、今回は R2 のバケット自体をパブリックアクセス可能にして使っているのですが、なんかたまーに 503 を返す場合があり気になる。Worker 通したほうが良いのかしら？

サーバーセーブはGoogle Driveに任せる

サーバーセーブをどうするかは悩みのタネでした。

D1データベースに突っ込むにはセーブデータはちょっとでかい。が、R2に保存するには細かい。
そもそもいろんな人のセーブデータが大量にサーバに溜まっていくのも、それはそれで保守の観点では困るところです。

そんな中、Google Drive に appdata という連携アプリケーションが固有のデータを保存できる仕組みがあることを知りました。

これを使うと、僕がみんなのセーブデータを管理する必要もないですし、ユーザーもアプリケーションの連携を切ればゲームのサーバーセーブを自分の意志で消せるし良さそうです。

そのため、セーブデータのマスターはあくまでブラウザのストレージとして、『クラウドバックアップ機能』として Google Drive を利用したサーバーセーブ機能を提供することにしました。

頑張る

頑張る話は楽しくないので割愛します。

ところで、Google Drive の API の叩き方とかは全然知らなかったのでうーん……と思っていたのですが、 GitHub Copilot がほとんど書いてくれました。天才かよ。

そんなこんなでできた『プレポタ』

思ったよりいい感じにできて嬉しかったので、PVみたいな動画作っちゃいました。

まだできたばかりで、もしかしたら細かいところおかしいかもしれませんが、温かい目で見守ってね。

https://play.toripota.com/

よーし、そろそろ次のゲーム作るぞ！

各作品の舞台と時間軸まとめ（2024年3月時点）

制作 憎悪の獣の地下ドール 貴方が狼カードデス！ 天翔と剣のウィッチクラフト ホシトリの夜 パズルネクリア ウヌムマキナ

どういうわけか？

こういうマシュマロをいただきました。

こんにちは、貴方が狼カードデスから色々ゲームをやらせてもらっています！素晴らしいゲームをありがとうございます！
ゲームをしている中で、ハインの時系列がどのように進んでいるか興味を持ったので教えていただけたら幸いです。

プレイありがとうございます！

時系列については、以前『ウヌムマキナ』を公開したときにブログに少し書いていました。

↑の記事のURLをペタリしようかと思ったのですが、少しアップデートしたほうがいいかもしれないなと思ったので2024年3月版をまとめてみることにしました。

各舞台の世界と時間軸の関係図

2024年3月最新版がこちら。

現在は、主に3つの世界のいずれかを舞台としています。
※各世界の名前は僕が区別するために付けているもので、各世界の住民がこの名前で呼んでるわけではないです

特に物語のメインとなっていてゲームの数が多いのは中央の『三月の世界』です。いわゆる魔法のファンタジー世界。3つの世界の中では一番時系列が長く表現されており、前半の方は魔法が中心のお話、後半の方は機術が中心のお話になっています。

その世界とは別に、現代日本をモチーフとした舞台となる『現の世界』があります。『ホシトリの夜』や『貴方が狼カードデス！』はこの世界でのお話で、時系列的には近い関係にあります。

そして、死霊の世界はオバケたちが住む世界です。現状は『パズルネクリア』のみです。本当はもう一作作ってたんだけどエターなっちゃった。

本来、これら3つの世界は別の世界なので相互に干渉することはないはずのものです。が、ハインのように世界の壁を越えて活動をしている者たちの影響で、これらの世界の要素が微妙に影響を及ぼし合っています。

ハインの時系列

※『憎悪の獣の地下ドール』『貴方が狼カードデス！』を始めとした複数の作品のネタバレを含みます

【クリックして文章を表示】

各作品の中でハイン『達』は何人か登場しています。

  • マザーハイン
  • 長女：メイカーハイン
  • 五女：ハイダー（ハイダーハイン）
  • 六女：オーナーハイン
  • その他のモブハイン（ハインドール）

このうち、複数の作品に出ているハインは『オーナーハイン』と『ハイダー』の2人です。この2人にとっての時系列で並べると

『ウヌムマキナ』（オーナーハイン）
→ 『貴方が狼カードデス！』（ハイダー）
→『憎悪の獣の地下ドール』（オーナーハイン / ハイダー）

の順番になります。

6人いる初期型（プロト）ハインドールのうち、現時点ではメイカー / ハイダー / オーナーの3人しか出ていないので、どこかで他の3人も出てくるかもしれませんね。

おわり

そんなわけで徐々に広がりつつあるRuたんワールドをよろしくお願いします（？）

なお、あくまで設定上の繋がりがあるというだけで、ゲームとしては基本的にはそれぞれ単体で完結したい気持ちではあります。が、たまにどうしようもないこともあるので、それは許して欲しい。

Ruたん2023年の世界へ

雑談 制作 貴方が狼カードデス！ 憎悪の獣の地下ドール ウヌムマキナ

今年も年末ですね。

去年の振り返り記事

2023年について雑多に振り返る

去年の振り返り記事では以下のようなことを書いていました。

ここ数年、僕がメインの活動場所としていたゲームアツマールが2023年6月でサービス終了と発表されました。悲しすぎる…(◞‸◟)

もちろんアツマール以前も僕はゲームを作っていましたが、鳴かず飛ばずというか本当にひっそりとやっていました。そんな中でアツマールという活動の場ができて色んな方に僕のゲームを遊んでもらえたり、同じようにゲームを作っている方々と知り合えたりしたのはとても良いことだったなぁと思っています。

アツマールがなくなってしまう以上、僕も活動のベースを変えないといけないため、2023年のRuたんの目標は「僕にあった次の活動スタイルを見つける」みたいな感じでしょうか。

今までもコミケに出てみたり、Steamにゲーム出してみたり、スマホアプリ出してみたりしたものの、どれも「これだ～～～」というほどしっくりは来ていないので、もうちょっと色々なことに挑戦してみたりしないとですね。

※去年の振り返り記事から引用

僕がメインの活動場所としていたゲームアツマールが無くなってしまったことは、非常に大きな変化です(◞‸◟)

もちろん「ブラウザゲームは場所を選ばない」というのが武器であり、アツマールが無くなってしまったからといってゲーム自体が無くなってしまうものではありません。ただ、ゲームの周囲の環境や体験といったものはコンテンツではなく場に強く依存するものであり、その場が無くなってしまうことは決して無視できない変化です。

僕がアツマールで最初に投稿したのは『魔導箱のグリモワール』でしたが、とても多くの方に遊んでいただき、アツマール上ではたくさんのコメントを頂いたりしました。あの反応があったからこそ 『ホシトリの夜』 や 『ウヌムマキナ』 へと続いていく「実績でシナリオが進んでく、いつものRuたんパズル」の流れが確立できたと思っています。

また、春のパズルゲームあつまーる企画が無ければ『双星ペアマール』は生まれるはずがないですし、課金ゲームのお誘いが無ければ『パズルネクリア』を作ることも絶対になかったでしょう。

そして何よりアツマールAPIが無ければ『憎悪の獣の地下ドール』が生まれない！
地下ドールの存在は僕の活動に対して人生最大級に影響を与えており、まさにそれはアツマールから貰った最高の宝だったと思います。ありがとう、ゲームアツマール……！頼むからうっかり生き返ってくれ。

そしてアツマールが無い世界で生きていくことになってしまった2023年、僕は色々ともがいていました。

個別の話

『貴方が狼カードデス！』

2022年秋に開催されたアツマール上のユーザーイベントである『ゲームジャム30』に参加するために作ったゲームです。30日では結末まで作れなくて、つゆちゃんが狼になる1ゲーム分だけ実装して公開していたものを、最後まで完結させて2023年2月に公開しました。

実は本作は結末とそこまでの流れが当初予定していたものとだいぶ変わっています。もともとアツマールに投稿することを前提としていたため、アツマール上で僕のゲームを遊んでいる人に向けたゲームという側面がありました。しかし、アツマール以外での活動を考える上で、その前提なくても成立する形に流れを変更することになり、そこがかなり難産でした。最初は『最後のゲーム』も作るつもりなかったですしね。

本作は2月にアツマール、PLiCy、App Store、Google Playで公開をしました。スマホアプリについては去年『ウヌムマキナ』をやっていたので、同じやり方で割と低コストにできそうというところでチャレンジしています。スマホアプリは普段の僕の活動の場とはだいぶ違うため、届けられる層もかなり違いますしね。

その中でいろいろと感想を頂いたり、ゲーム実況していただいたこともあって、ダウンロード版（Windows版）も作ってみようかなと思いました。過去に地下ドールのダウンロード版を作った際は、ふりーむ！ で配布していましたが、あんまり良い感触が無かったなぁ……というところで今回は Steam でやってみることにしました。「Steam でフリーゲームを配布する」っていうのやってみたかったというのも大きいです。

無料ということもあり、ライブラリ追加数は1万を軽く超えててSteamすげぇ～……となりました。もちろん、実際のプレイヤー数はそのうちの10%切るので、多くの方は積みゲーコレクションの中に加えて頂いている感じですね。みんな積みゲーしてるんだと思うと、罪悪感が無くなって良いですね。（買ったのにまだやってないSteamゲーの山を見ながら）

そんなわけで『貴方が狼カードデス』はいろいろやってみてところどころ手応えはあったりしました。一方で、本作は制作期間が意図せず長期化したこともあって、僕のメンタルにものすごい量のダメージも入ってしまった、というバッドな一面もあります＞＜；

一旦は本作については落ち着いた、というところで少し休んでから次のことを考えようかな……と思います。

『憎悪の獣の地下ドール』

そんなわけで『貴方が狼カードデス！』の連中も参戦しました。
まぁ地下ドールを先にやってた人にとっては、お前はデスゲームの進行してないでこっちに出てろって感じですしね……

もともとドール50体で終わりのつもりでしたが、54体になっちゃったぜHAHAHAHA!
各色のドールがちゃんと同じ数ずつになるようにしてたのに、4体増やしたせいで赤ドールが1体多くなっちゃったのでどうしましょうねコレ？（）

アツマールは無くなっちゃいましたが、PLiCy版で引き続き非同期オンラインバトルはできるので、これからもチャンプを目指して！

『ウヌムマキナ』

実はこっそり英語対応してました。

ただ、英語としてちゃんとしてるかはわかりません。何故なら ChatGPT に翻訳してもらってるからです！（）
まぁなんか僕の目線だとそこまでボロボロという感じもしないし、僕よりは翻訳うまそうだから大丈夫でしょう…！

突然英語対応したのは itch.io に置くためです。一応、itch.io に置くときはなんちゃって英語対応をすることにしてます。英語圏のプレイヤーに届くかは別として一応……。

ブログを書く！

活動の多様化の一環として、『月に1本はブログを書く』という目標を立てていました。

とりあえず目標自体は達成してるかな……！

ブログを書くこと自体は結構自分の中の思考を整理するという意味でもよいと思っているので、来年もできる限り続けていきたいですね。最近はしずかなインターネットにもポエム書いてたりするのでアレですが。

2024年は……？

むずい…！
1年いろいろ試行錯誤してみましたが、安寧の地は見つからない！

そんなわけで、もうちょっともがいてみようかな……という感じになりそうですね。一方で、慣れないこと無理してやると滅茶苦茶キツイということもわかったので、もう少しゆったりペースで生きていこうかな……。

作りたいモノはいくつかあったりするので、しばらくはその辺りをこねこねしたり、下地を作ったりして、来るべきタイミングに備えていこうかな～と思います。

そんなわけで、2024年もよろしくなのじゃ！

ツクールと最大公約数と鳥小屋プラグイン

雑談 制作

ツクールは最大公約数

RPGツクールは『最大公約数』の取り方が非常にすごいなと思っています。
ここで言う『最大公約数』とは「多くのゲームで共通となる部分」の意味です。

正直、ゲームの中身は多くの場合ゲームごとに全く異なっていて、その中の共通点を見つけ出した上で 限界まで削ぎ落とす というのは非常に難しいです。特に『削ぎ落とす』というのはツールの作り手にとっては怖い行為です。なぜならば、機能をそぎ落とせば「◯◯機能がない」という不満を投げつけられる可能性があるためです。

しかし、機能はあればあるだけあらゆるケースにおいて良いというようなものではありません。

主たる思想はどこにあるのか

例えば、僕らの身近な例だとRPGツクール2000とWOLF RPGエディター（ウディタ）を比べるといいかもしれません。ウディタはRPGツクール2000と比べると非常に多くの機能をほぼ無制限に利用することができます。一方で「初めてゲームを作るよ！」という人にとっては、ウディタは結構難しいツールでもあると思います。

これは当然の話で、主たる思想が違うためです。ウディタは公式サイトにも書かれている通り ツールで想定されている範囲を越えた自由度が欲しい という想いから作られているもので、思想の主は「自由」であることだからです。一方でRPGツクール2000は 操作は簡単！手軽にクリエイト！ を謳っており、思想の主は「手軽」であることがわかります。

どちらが優れてるとかそういう話ではないですし、そもそもとして 0 か 1 かなんて話でもありません。実際、ウディタにも初心者向けの部分はありますし、RPGツクール2000にも上級者のための機能もあります。
重要なのは「ツールが目指している場所がどこなのか」という部分です。

RPGツクールの目指している場所と最大公約数

ちょっと Unite がどこ目指してんのかは僕もよくわかんないので置いときますが、
RPGツクールは一貫して「手軽」であることを目指していると思われます。そう考えると、他のプロユースに近いツール達（ウディタやUnityなど）とは異なり、ゲームの最大公約数を見つけ、機能と情報を制限することで、初心者にも全体がわかりやすくする……といったことを目指しているのだと思います。

多くの場合にとって必要なものというツールや機能が厳選されているということは、裏を返すと個々人が開発しているゲームの中だと「微妙にコレできたらいいのにな～」ということはあるかもしれません。しかし、その要望をすべて受け入れるとRPGツクールが目指している場所とはズレてしまうことでしょう。

ここのバランス感覚は非常に難しいと思うのですが、RPGツクールはとても良い場所にいるなと感じており、僕が今でもRPGツクールに惹かれ続けている理由の1つです。

プラグイン

ところで、RPGツクールにはプラグイン機能（XP～VXAceだとスクリプト）があります。

おそらく本来コレはRPGツクールの中における上級者のための機能だったんじゃないかなと思いますが、ユーザーコミュニティの中で発展していく中でプラグイン素材（スクリプト素材）が多く生まれ、自分でスクリプトを書かない初心者でも割と気軽に使いがちな機能になっていますね。

僕とプラグイン素材

僕自身も、RPGツクールVX（RGSS2）のときに自分のゲーム用に書いたスクリプトをブログで少し公開したりしており、RPGツクールVXAce（RGSS3）以降はスクリプト素材屋さんみたいなことをして活動しています。

正直、RGSS3の頃やMVプラグインの初期とかは僕もテキトーなことやってたのであんまり思想もクソも無かったのですが、いろいろと振り返ったりした中でRPGツクールが実現している「最大公約数」を見習いたいなと思い、現在鳥小屋プラグイン置き場で公開しているプラグインの多くはちょっと意識をしています。

鳥小屋プラグインの最大公約数

現在の鳥小屋プラグインでは以下の2つのルールを意識するようにしています。

  1. UIの変更を主としたプラグインは作成しない
  2. UIの豊富なカスタマイズ機能を提供しない

共にUIにまつわる部分です。

(1) UIの変更を主としたプラグインは作成しない

例えば「鳥小屋カッコいいバトル画面プラグイン」みたいなもので、既存のRPGツクールが提供している画面を大きく作り変えるようなプラグインという意味です。

これは「RPGツクールが提供している画面は最大公約数である」ということを考えると、ここから狭めていった先にあるべきなのは「そのゲームのためにオーダーメイドされた画面」であるべきだと考えたためです。そこまで行くとプラグイン「素材」じゃない……！

例えば、地下ドールの戦闘画面は地下ドールのゲームシステム上（2vs2 / 自動戦闘）でしか成立しない。

そのため、鳥小屋プラグインでは既存UIを変更することを目的としたプラグインは作っていません。

ただし「何かを追加する」という形のものはいくつか作っています。例えば『通知メッセージプラグイン』は、マップ画面に通知UIを追加するプラグインです。

(2) UIの豊富なカスタマイズ機能を提供しない

一方で『通知メッセージプラグイン』のような何かのUIを追加するプラグインにおいては、『豊富なカスタマイズ機能を提供しない』というルールを作っています。もちろん最低限のフォントサイズの設定とかはプラグイン設定で提供していますが、この見た目を大きく変えるような機能をプラグインの機能としては提供していません。

これも先ほどと同じで、鳥小屋プラグインにおいて追加するUIにおいても最大公約数を目指す、という思想からです。

あらゆる要望に応えられるようなプラグイン設定を作ることは非常に難しいですし、使う側の人にとってもわかりにくいものになるでしょう。そのため、プラグインとしては多くのゲームでそのまま使える状態を目指すというルールでやっています。

なお、この思想はプラグイン作成上の思想であり、「利用者の人も最大公約数のまま使うべきである」というものではありません。

鳥小屋プラグインでは、画面UIに関わる処理はすべて window.Torigoya.プラグイン名 以下からいじることができるようになっており、「鳥小屋プラグインの処理/見た目を変更するプラグイン」が作れるようになっています。実際、僕が自分のゲームで使う場合は、ゲームにあわせていじっています。

『貴方が狼カードデス！』の実績画面は 実績プラグイン を使っていますが、見た目の部分はこのゲーム専用のプラグインで処理を上書きしています。

そのルール守ってどうすんの？

最大公約数を意識することで、以下の2つを実現できたらなと思っています。

  1. 様々な人が気軽に使いやすいプラグインにしたい
  2. 僕が今後も保守していきやすくしたい

(1) 様々な人が気軽に使いやすいプラグインにしたい

RPGツクールのように、誰もが気軽に使いやすいプラグインにしたいです。

それこそ可能であれば、プラグイン設定などは一切しなくても動くことが理想です。もちろん実績プラグインなどは実績自体を作ってもらう必要はありますが、それ以外の設定というのはしなくても使えるようなわかりやすいプラグインにできたらいいなと思っています。

多くのゲームでそのまま使えるものを考える、ということ自体はとても難しいことで失敗することも多々ありますが、今後も意識してやっていきたいです。

(2) 僕が今後も保守していきやすくしたい

大前提として、僕は自分のプラグインを自分のゲームで使いたいと思っています。
逆に言えば、僕が使わないプラグインは作るつもりはないです。

これは簡単な理由で、僕が使わないプラグインは僕が保守しなくなっちゃうからですね。僕はプラグイン作者ですが、そのプラグインの一番の利用者でもありたいと思っており、そうすることでプラグインの不具合修正などを継続して行っていけるようにしたいと思っています。

これを実現するためには、鳥小屋プラグインはなるべく多くのゲームで使えるようなものであることが望ましいです。最大公約数を意識することで、僕が過去に作ったゲームはもちろんのこと今後作るゲームでも使っていきたいと思えるようなプラグインにしていきたいです。

まとめ

  • RPGツクールの『最大公約数』はすごい
  • 僕はRPGツクールを見習いたい！
  • 鳥小屋プラグインでも『最大公約数』を意識してやってます

くっそ長いブログ書いたけど3行で済む話だった！！！！！！！！！！１１１１１１１１１
ブログの最大公約数も意識したほうがいいかもしれないね（？）

Steam版『貴方が狼カードデス！』2023年10月10日に出ます！

制作 貴方が狼カードデス！ Steam

Steam版『貴方が狼カードデス！』

6月に公開予定だったのに延期になってた、Steam版『貴方が狼カードデス！』がついに2023年10月10日に公開になります！やったぜ！

公開のタイミングは僕が手動でポチポチやったりするのでピッタリ0時ちょうどではないと思いますが、だいたいそんな感じの時間に公開することになるんじゃないかなと思っています、たぶん。Steamでゲーム公開するのだいぶ久しぶりなので、もしかしたら色々ミスるかもしれません＞＜；

ちなみに Steam 版もブラウザ版やアプリ版と同様に無料のフリーゲームとして公開されます。お気軽にダウンロードして遊んでもらえると嬉しいです！

Q&A

Q. そもそも『貴方が狼カードデス！』って？

動画を超がんばって作ったので見て！

『貴方が狼カードデス！』 は人狼をモチーフにしたデスゲームADVです。

キャラクター達の議論を聞いて、誰が狼なのかを当てるというシンプルなアドベンチャーゲームです。1プレイあたり5分程度の狼ゲームを繰り返すことで、徐々にデスゲームの真実が明らかになっていく……！いつものRuたんじゃねぇか！

既にブラウザ版やスマホアプリ版は公開していましたが、今回パワーアップしてSteamに登場します！

Q. ブラウザ版やスマホアプリ版からの変更点は？

主に以下のような変更をしました！

  • ゲームの画面解像度が大きくなりました（800x450 → 1280x720）
    • それにあわせて全体的なUIのブラッシュアップをしました
  • 背景やカードイラストが変更になりました
    • AIくんが作ってくれた画像がなくなった
  • ゲーム内のイベントシーンを一部変更しました
    • 画像を追加したり、セリフを調整したり
  • Steamの実績機能に対応しました
    • 多分クラウドセーブも動くと思いますが、うまく動かなかったらごめん！

Q. ブラウザ版やスマホアプリ版はどうなるの？

Steam版公開のあと、ブラウザ版やスマホアプリ版もv.2.0にアップデート予定です！
アプリは審査とかもあるから、アップデートされるタイミングはバラバラになると思います。少なくとも10月中にはアップデートされるんじゃないかな！

Q. でもお高いんでしょう？

無料のフリーゲームだよ！

Steamくんでゲームを1つ公開するためには1万円くらいの場所代を払う必要があるためド直球に赤字ではあるのですが、新しいことにいろいろ挑戦してみるということで試しにやってみる感じです！

そんなわけで

今度こそ予定通り出るはずなので、よろしくおねがいします！

ウィッシュリストに登録してもらえると、僕のモチベがバク上げします。

Electron + RPGツクールMZ なゲームで Steam の実績に対応する

制作 RPGツクールMZ Steam
【注意】こんなタイトルですが、真面目にツクールを使ってる多くの人にとっては参考になりません

Steam には実績機能があります。正確にはこの辺りの機能には、

  • ゲームのスコア的な内部数値を格納できる Stats
  • PS系で言うところのトロフィー的な Achievements

の2つがありますが、今回の話は Achievements のほうです。

せっかく Steam でリリースするからには実績機能に対応したいため、いろいろやった記事です。

前提

Electron

RPGツクールMZのゲームは内部的にはHTML5なブラウザゲームとして動作します。そのため Steam でリリースをするためには、まず何らかの方法で Windows 等向けのアプリケーションにする必要があります。

RPGツクール側の標準では NW.js が使われています。RPGツクール上でテストプレイを押したときに開くのも、この NW.js です。

しかし一般的にはこういったWebアプリケーションのアプリ化には Electron が使われることが多く、インターネットで得られる記事やツールも Electron を対象としたものが多いと思われます。そのため、僕も NW.js ではなく Electron を使うことにしました。

なお、RPGツクールMZのゲームを Electron を使ってアプリ化する方法は、トリアコンタンさんが詳しい記事を書いているためそちらを見ると良いです。

Steamworks.js

Steamの機能を使うためには、Steamworks SDK の機能を呼び出す必要があります。しかし Steamworks SDK は C++ のコードのため、JavaScript の世界……というか node.js の世界からそのまま呼び出すことはできません。

以前は node.js から Steamworks SDK を呼び出す方法として Greenworks というライブラリが有名でした。ただ結構使うのが難しかった印象が強いです……前の僕は挫折した＞＜；
また、現在は Greenworks は開発が停止状態になっており、他のライブラリの利用が推奨されています。

Steamworks.js は Greenworks のページから移行先の1つとして紹介されているライブラリです。 Rust で書かれたブリッジのライブラリになっており、とてもシンプルでわかりやすい印象があったため使うことにしました。

Steamworks APIを呼び出す

プロジェクトのフォルダ構成

過去の記事 でも触れましたが、僕のゲームのプロジェクトのフォルダ構成はざっくり以下のようになっています。

├── app/     …… RPGツクールのプロジェクトフォルダ
│   ├── audio/
│   （略）
│   └── game.rmmzproject
├── android/ …… Capacitor Android の作成するフォルダ
├── ios/     …… Capacitor iOS の作成するフォルダ
├── windows/ …… Electron 用のフォルダ
│   ├── main/     …… Electron用のJavaScriptが入るフォルダ
│   ├── public/   …… ゲームが入るフォルダ（後述） 
│   └── package.json 
└── package.json

※説明に不要な部分は割愛

Capacitor

僕はスマホアプリも作りたいので Capacitor を使っています。 Capacitor はプロジェクトフォルダの直下にプラットフォーム名（android / ios）のフォルダを作るため、それに習って Electron 用のフォルダに windows という名前をつけています。

Capacitor では cap sync というコマンドを実行すると、 android / ios のそれぞれのフォルダの中にゲームのデータがコピーされるようになっています。そのため、同じように windows/public のフォルダの中にもゲームのデータが自動的にコピーされるようにしています。

Steamworks.js を組み込む

Steamworks.js の README では BrowserWindow を nodeIntegration: true にする方法が記載されていますが、あまり nodeIntegration を有効にはしたくないため、以下のようにして組み込みます。

// main.js

const { app, BrowserWindow, ipcMain } = require('electron');
const steamworks = require('steamworks.js');

// Steamで発行される App ID
const STEAM_APP_ID = xxxxxxx;

let browserWindow = null;

const createWindow = async () => {
  if (browserWindow) return;

  const win = new BrowserWindow({
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      nodeIntegration: false,  // 強い意志で false にする！
      contextIsolation: true,   // 代わりに contextIsolation は使います
    },
    show: false,
  });

  // ウィンドウサイズをいい感じに
  win.removeMenu();
  win.setContentSize(1280, 720);
  win.setMinimumSize(...win.getSize());

  // ページを読み込む
  await win.loadFile(path.join(__dirname, '..', 'public', 'index.html'));
  win.show();

  browserWindow = win;
};

app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') app.quit();
});

(async () => {
  // Steam経由起動でない場合はゲームを終了する
  if (steamworks.restartAppIfNecessary(STEAM_APP_ID)) {
    app.exit();
    return;
  }

  // Steamworksの初期化＆オーバーレイメニューの有効化
  const steamClient = steamworks.init(STEAM_APP_ID);
  steamworks.electronEnableSteamOverlay();

  await app.whenReady();

  // ゲーム内から実績獲得の呼び出し用の口を作る
  ipcMain.handle('activate-steam-achievement', (_event, name) => {
    steamClient.achievement.activate(name);
  });

  // ウィンドウを作る
  await createWindow();
})();

ポイントは steamworks.restartAppIfNecessary と steamworks.electronEnableSteamOverlay() を呼ぶタイミングです。

この2つはアプリケーションが立ち上がってすぐに呼び出さないとうまく動かない場合があります。そのため BrowserWindow の作成よりも先に呼び出すようにします。

また、 ゲーム内から呼び出すためのコードを preload.js に追加します。以下は window.steam.activateAchievement(実績名) で先程用意したSteam実績を追加するための口を呼び出すようにしています。

// preload.js

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('steam', {
  activateAchievement(name) {
    return ipcRenderer.invoke('activate-steam-achievement', name);
  },
});

あとはゲーム内から良きタイミングで window.steam.activateAchievement(実績名) を呼ぶだけです！

その他

パッケージ化するときの注意

Electronのアプリをパッケージ化する際に、ASAR アーカイブ を使用する場合は1点注意が必要です。

Steamworks.js の中には DLL などのバイナリを含むため、それらがASARアーカイブの中に含まれてしまうと正常に動作しなくなってしまいます。そのため node_modules/steamworks.js/dist/ 以下のファイルは ASAR アーカイブに含まないようにします。

僕はパッケージ化に electron-forge を使っているので、 unpackDir の設定に steamworks.js のディレクトリを指定しました。もしくは Auto Unpack Native Modules Plugin でもできるのかも？　試してないけど。

おまけ：実績プラグインと連携する

Torigoya_Achievement2 というRPGツクールに実績機能を追加するプラグインがありますね（ダイマ）。

Torigoya_Achievement2 には「実績獲得時に実行される処理を追加する」機能があるため、以下のようなアドオンプラグインを用意すると、実績獲得時に自動的に Steam 上の実績も獲得状態にできます。

(() => {
  Torigoya.Achievement2.Manager.on(({achievement}) => {
    if (!window.steam) return;
    window.steam.activateAchievement(achievement.key);
  });
})();

なんて便利なプラグインなんだ！！！！！！１１１１（自画自賛）

できた！

左上と右下から実績が出てくるゲーム。

僕は他に少し色々とやりたいことがあるので実際はもうちょっとややこしいコードを書いていますが、大筋はこんな感じになっています。

Steamworks.js はとてもシンプルで扱いやすいので、Steamの機能をElectron + HTML5ゲームから呼び出すときには手軽で便利です。特に Steamworks SDK のビルド環境なども用意しなくて良いため、今後もお世話になりたいですね。

昔、Steamで公開した『天翔と剣のウィッチクラフト』というゲームはこの辺りがうまく解決できず、Steam実績に未対応だったりしました。少しずつ世界は便利になっていく。

Steam版『貴方が狼カードデス！』公開延期します＞＜；

お知らせ 制作 貴方が狼カードデス！

2023年9月26日追記：続報が出たよ！






前回の記事 で「6月26日公開です！」と言っていたのですが、諸般の事情により公開を延期することになりました。Steam上でも公開日を一旦2023年内に変更させていただいています。

延期後の公開日はまだ未定ですが、おそらく数ヶ月単位でお待たせすることになりそうです。期待いただいてる方には大変ご迷惑おかけしますが、よろしくおねがいいします。

なお、Steam版として公開予定だった『貴方が狼カードデス！』ver.1.1の内容自体は完成しているため、PLiCy版（Webブラウザ版） / iOS版 / Android版 については6月下旬ごろにアップデートを行う予定です。会話シーンや演出のブラッシュアップを中心としたアップデートです。アップデートまでもうしばらくお待ち下さい。

処刑シーンはノコギリとか出るようになったり。

急にどした？

アツマール版の舞台裏コーナーにも書いていましたが、『貴方が狼カードデス！』では一部のアートワークに生成AIを使用しています。主に背景画像＆狼とか村人とかのカードイラストの部分ですね。ちょうど作り始めてた去年の秋ごろ話題としてホットだったため、活用の方法を模索して採用していました。

この部分について、Steamでの公開審査時にポリシー的に条件を満たす必要があると指摘を受けました。

貴方が狼カードデス！ appears to contain art and/or text assets generated by artificial intelligence that may be relying on copyrighted material owned by third parties. As the legal ownership of such AI-generated assets are unclear, we cannot ship your game while it contains these AI-generated assets, unless you can affirmatively confirm that you own the rights to all of the IP in the data set that trained the AI used to create the assets in your game.

この辺り、まだ議論が盛んなところなので、プラットフォームとしては難しいところなのは理解できます……
サポートさんとも何度もやり取りさせていただいていましたが、当然ながら学習データの中身を僕が保証したり証明することは難しいので、現状のままSteamで公開することは難しいと判断し、公開を延期することを決めました。

Steamのサポートさん、僕の意味不明な英文に付き合っていただき本当にありがとうございます…… :bow:

今後について

『貴方が狼カードデス』ver.1.1

冒頭にも書いた通り、Steam版公開に向けて制作していた ver.1.1 については完成しています。そのため、予定通り6月末ごろに Web版 / iOS版 / Android版はアップデートの形で公開します。

Steam版『貴方が狼カードデス！』

サポートさんからストアページ消して返金することもできるよ、とご提案いただきましたが、せっかくSteam対応のためのアレコレとかもやってたし、PC版もちゃんと公開したいなぁという気持ちがあるため、公開できるように頑張りたいと思っています。

Steamのポリシーを遵守するため、生成AI由来の画像を差し替える必要があるため、背景画像やカードの画像の差し替えを行うことになるかなと考えています。
……が、単純に画像差し替えるだけだと、ただ雰囲気とかイメージとかが変わってしまうだけで、プレイヤー的には「で？」という感じになりそうですし、僕個人としてもちょっと面白くない…！

そんなわけで Steam版公開に向けて ver.2.0 を制作することにしました。
ただ「背景画像が変わりました」のようなアップデートではなく、ゲーム全体としてよりクオリティを上げるために様々な点をアップデートしようかなということを考えています。

まだ具体的なことを決めるのはこれからですが、1つのアイデアとしては『ゲームの解像度の変更』を考えています。もともとブラウザゲーム向けということもありゲーム解像度を 800x450 で作成していましたが、PCでプレイすることを考えると少し小さめです。1280x720 くらいは欲しい。

もちろん解像度を変更するためにはゲーム内のあらゆる画像の作り直しなどが発生するのですが、どうせやるなら徹底的にやるぞという気持ちで取り組むのもありかなと考えています。

まだ方針についてはこれから考えていくため何もかもが未確定ですが、引き続き応援よろしくおねがいします！

というわけで

ウィッシュリスト登録おねがいします！（チャンネル登録よろしく的なノリで）

Steam版『貴方が狼カードデス！』制作中です

制作 貴方が狼カードデス！

＜2023年9月26日追記＞

公開日が2023年10月10日になりました！

＜2023年6月17日追記＞

諸般の事情によりSteam版の公開は延期となりました。
今後のスケジュールは後日お知らせさせていただきます。皆さんにはご心配おかけし申し訳ありません＞＜；

Steamストアページを公開しました

人狼系デスゲーム『貴方が狼カードデス！』 のSteam版（Windows用）を制作しています。先日、 Steam のストアページも公開されました。

人狼系デスゲーム『貴方が狼カードデス！』

『貴方が狼カードデス！』 は人狼をモチーフにしたデスゲームです。

キャラクター達の議論を聞いて、誰が狼なのかを当てるというシンプルなルールです。1プレイあたり5分程度の狼ゲームを繰り返すことで、徐々にデスゲームの真実が明らかになっていきます。

本作はゲームジャム30の参加作品でブラウザ向けのゲームとして2022年10月にお試し版を作成・公開、2023年2月に完成版として公開しました。その後、iOS / Android 向けのスマホアプリ版も公開しています。

Steam 版の特徴

本作は既に公開済みのブラウザ版やスマホアプリ版とほぼ同内容ですが、一部テキストや画像などのアップデートや、細かいシステム的な調整を含んでいます。例えばバックログを Shiftキー で呼び出せるようになったりとか。

このあたりの調整は Steam 版公開後にブラウザ版などにも反映予定なので、パソコン持ってない人もご安心ください。

Steam 版固有の機能としては、 Steam の実績機能に対応しています。ゲーム内で獲得できる『仕様書』を集めると、連動して Steam の実績もアンロックされる感じです。
（※ルール説明のやつなどの一部仕様書は非対応です）

今はクラウドセーブ周りも対応したいなと思って調整中で、これがうまくいけばクラウドセーブも対応できそうです。別にそんな長いゲームではないですが使えるなら使いたいよね！

頑張って作ります！

現在鋭意制作中の Steam 版は2023年6月26日ごろに公開予定 です。
諸般の事情により延期になりました。詳細な予定は後日告知します……＞＜；

ブラウザ版やスマホアプリ版と同様に 無料 なので、 今すぐウィッシュリストに登録しよう！
登録してくれると僕の幸福度とやる気が増えます（？）

鳥小屋プラグインの裏技（？）の話

制作 RPGツクールMZ

鳥小屋プラグイン置き場 というサイトがあります。
あります、というか僕のサイトですが……。

鳥小屋プラグイン置き場ではRPGツクールMV/MZ向けのプラグインを公開しています。いわゆるプラグイン素材屋さんですね。

プラグイン素材屋さんではありますが、プラグイン素材を日々作っているというわけではなく、僕が自分のゲームを作る中で作ったものの中から素材化できそうな部分を抽出＆整理して公開しているみたいな感じです。そのため、他のプラグイン素材屋さんと比べると置かれているプラグインの偏りがすごかったり、あんまり要望とか受け入れてくれなかったりと、ちょっと我が道行くタイプになってるかもしれません。僕のゲームが普通じゃないからね……

で、素材として公開していますが、いくつか説明に書いてない機能を持っているプラグインがあります。裏技みたいな機能。
これらは主にプラグインをいじる人（＝僕）向けの機能なので、わざわざ説明書いても多くの人には特に役に立たないため書いていません。

そんな秘密の機能・仕様をここではいくつかご紹介します！

実績プラグイン：Torigoya_Achievement2

鳥小屋プラグイン置き場の目玉プラグイン！（自称）

いわゆるトロフィーとか実績とかを実現できるプラグイン。もともとは魔導箱のグリモワール用のシステムだったやつをプラグイン化したもので、実績の仕組みの基礎＋簡易的なUIを提供するものになっています。ちなみにこのプラグインは 2 なので当然 1 があります。

実績の仕組みの基礎、の部分にいろいろと仕掛けがあるのですが、その中でも便利そう（？）な部分を紹介します。

実績獲得したら通知

このプラグインでは実績を獲得すると画面端からピョコっと表示が出たりしますが、そのタイミングで他の処理を走らせたくなることがあります。例えば Steam の実績をアンロックするとか。

Torigoya_Achievement2 には実績獲得のタイミングで走る処理を登録する仕組みがあります。

Torigoya.Achievement2.Manager.on(({achievement, unlockInfo}) => {
  // ここに処理を書こう！
});

獲得した実績が achievement に、獲得日時などの情報が unlockInfo に入ってきます。
オリジナルの通知機構が欲しくなったときとかにも使えるかも。

ちなみに僕はこの仕組みを使って「実績数が一定以上になった時に獲得できる実績」を作っています。

お手軽スタッフロールプラグイン：Torigoya_EasyStaffRoll

鳥小屋プラグイン置き場随一の便利プラグイン！（自称）

スタッフロール、様々なゲームで作ることになるものの、実際つくるの結構たいへん！一応ツクールには「文章のスクロール表示」がありますが、細かい調整しづらいのでスタッフロール用途だと結構難しいですね＞＜
時間指定で表示できるので表示項目増えたり減ったりしても困らないやつ！

そんなスタッフロールプラグインにも裏口、というか隠し仕様があります。

スタッフロール情報の定義

普通にこのプラグインを使う場合は、プラグイン設定でスタッフロールの情報を定義します。

ですが、ゲームによっては動的にスタッフロールの情報を定義したくなる場合があります。例えば、外部ファイルから読み込みたいとか、ゲームの進行状況に応じてスタッフロールの中身を変えたい（？）とか。

そんなときは Torigoya.EasyStaffRoll.Manager.loadStaffRollContent を再定義だ！

Torigoya.EasyStaffRoll.Manager.loadStaffRollContent = () => {
  return Promise.resolve([
    {
      title: 'つくったひと',
      items: [ { title: 'Ruたん', description: '', icon: '' } ],
    },
    ...
  ]);
};

loadStaffRollContent はスタッフロールの定義を Promise で返すメソッドです。デフォルトではプラグイン設定で設定した内容を Promise で返すメソッドとして実装されています。

Promise なので外部ファイルの読み込みのような非同期処理が挟まっても問題ありません。というよりは外部ファイル読み込めるようにするために Promise にしてあります。僕のゲームのためにね。

おわり

今回はこの2つをご紹介しました。

僕のプラグインは他にもいろいろ仕掛けが眠ってるやつがあったりします。特に見た目系はゲームごとに変わってくる可能性が高いので、あくまでプラグインとしては汎用的な見た目を1つだけ提供し、全然違う見た目にしたい場合はプラグインの各所を再定義して見た目を差し替えられるような仕組みになっています。僕のゲームのためにね。

鳥小屋プラグイン置き場のプラグインは僕の思想がとても強いプラグインですが、いろいろ上から捻じ曲げられるような作りにはなっていたりするので、ご利用の方は今後も末永くご利用いただければと思います（？）

エターなってたRPG『百人村の死霊使い』を公開した話

制作

戦闘RPG『百人村の死霊使い』

https://game.nicovideo.jp/atsumaru/games/gm29741

『百人村の死霊使い（ネクロマンサー）』をゲームアツマールで公開しました。
アツマールは4月19日で新規投稿＆ゲーム更新が終了になったため、僕がアツマールに投稿する最後のゲームになります。

命を繋ぐ戦闘RPG

いわゆるノンフィールド系のRPGです。たぶん。
各層にいるモンスターを倒しながら1層ずつ進んでいって、最深部（20層）を踏破するとクリアです。
敵を倒すと様々な装備がドロップするので、それらをうまく組み合わせよう！

特徴としては死ぬとキャラクターがロストします。
ロストしますが、ロストしたキャラクターは1人だけ生きる屍としてパーティに加えることができます。生きる屍は装備は変えられなくなりますが、自動HP回復などの力を持つため強力な味方になります。

1人でクリアすることは不可能なため、強力なキャラクターを作って屍にしてパーティに加えよう！（言い方）

なお、この村の人口は100人なため、100人死んでしまうとゲームオーバーです。
理論上ゲームオーバーになるはずですが、動作確認してないのでバグるかもしれません……

見覚えがあるぞ…！

という人がいたら、ちょっと怖い（？）

このゲームは僕が2016年ごろに作っていたゲームです。
RPGツクールMVの発売が2015年末なので、僕がMV買って最初にまじめに作ってたゲームになりますね。

2016年に書いた以下の記事にもちょろっと出てきたりします。

途中まで作ってたのですが、ある程度作ったところで燃え尽きてしまってそのまま放置コース行きになりました＞＜；
たしか後半のバランスが結構むずかしい感じになってきて、全体的に色々調整しないと～～みたいな感じだったかな……

それ以来ずっと眠りについていた本作でしたが、アツマールの最後ということもあり何かを公開したいなと考え、このゲームを引っ張り出してきました。タイトル画面・エンディング・ゲームオーバーは作りかけ＆未実装だったのでそこは追加実装しましたが、それ以外の部分はだいたい当時のままです。

大きく変えた部分としては、フロアを全30層から全20層に減らしたのと、バランス周りかな。

30層から20層にした理由は単純に20層以降が作りかけ＆25層以降は完全に未実装だったためです。そのため作りかけ以降の部分はまるっと消してしまっています。その結果としておそらく装備図鑑の空白が埋められないという問題があるのですが、許してください＞＜

あとは、敵のHPと攻撃力がバカみたいに高かったのとドロップ率が激渋だった部分を直しました。当時のRuたん、どういうバランス感覚だったんだ………

ところで世界観

ここしばらくの僕のゲームとは世界観的には特に関係ないです。
パズルネクリアのネクリアちゃんは死霊使いだけど特にこんな重い設定もないしね。

一部モンスターのネーミングが、僕が大昔につくったRPGを踏襲してたりしますが、ただのネタなのであんまり関係ないです！

おわり

そんなわけで生き返って公開された『百人村の死霊使い』でした。

なお、本ゲームはゲームアツマールのサービス終了までの期間限定公開となります。
そのためアツマールの終了後は再公開の予定はありません。ご了承下さい。

ﾙﾀﾝとｱﾂﾏｰﾙは…ｽﾞｯ友だょ…!!

『貴方が狼カードデス！』のイベント増殖術

制作 RPGツクールMZ 貴方が狼カードデス！

以前書いた記事 でも少し触れたやつ。

どういうわけか？

ランダムっぽくするために

先日公開した 貴方が狼カードデス！ というゲームがあります。このゲームは人狼モチーフのゲームになっており、プレイするたびに登場人物たちの配役が変わるようになっています。

……と言っても グノーシア みたいに本当にランダムに配役が決まって様々な分岐をしているわけではありません。単にいろんなパターンの組み合わせで物語が書いてあって、その中からランダムに1つ選ばれてスタートするみたいな仕組みです。
（※ちなみにこの記事を書いたv.1.0.3時点では20パターンあります）

クリアしたお話は再度選ばれなくなる仕組みが入っていたりするので、感覚としてはプレイするたびに毎回別のお話が始まるように十分感じられるはずです。全パターンやりきる前にエンディング見れるはずだし（たぶん）

とは言うものの、いっぱい作るのは大変！

もちろん、いろいろな配役パターンのお話を書くこと自体も大変ですが、そこに加えて「書いたお話をゲームに組み込む」部分も大変だったりします。

本作は RPGツクールMZ で作成しているので、ゲームに組み込むためにはイベントコマンドとして入力していくことになります。

こういう感じ。

単純にセリフや地の文を打ち込むだけではなく、キャラの立ち絵を出したり、BGMや効果音を再生したり、演出を入れたりなど、様々なイベントコマンドをいろいろ入力してあげる必要があります。

この作業がかなり時間がかかるため、お話をたくさん作ろうとするとかなりここがネックになることが制作開始の時点で予想されました。

なのでパターン化

今回つくるゲームは人狼モチーフのゲームのため、ゲームの流れをある程度固定化できます。

  1. キャラクター同士の話し合い
  2. 誰を処刑するかの投票
  3. 結果発表
  4. 感想タイム

基本的にこの流れになります。
このうち (2) と (3) 自体はお話の流れに関わらず共通です。お話ごとに変わるのは (1) と (4) だけです。

つまり、この (1) と (4) だけを抜き出して、もっと簡単に作成できるフォーマットで組み込むことができれば、お話をゲームに組み込む労力を減らすことができそうです。

……というお話。

Markdown を使ったお話スクリプト

『貴方が狼カードデス』では、 Markdown を使ったイベントコマンド変換システムを構築しました。

なんで Markdown ？

以下の3つの要件を満たすものが良いと考えました。

  1. 誰でも使えるテキストエディタなどで人間が簡単に編集できるもの
  2. テキストエディタ上で、シンタックスハイライト（色分け表示）が有効になるもの
  3. 既存のライブラリなどで読み込みができるもの

(2) と (3) については JSON や XML とかでも良いのですが、人間が手で編集するのはちょっと面倒くさいです。あくまでお話を考えながら書くときに邪魔にならない程度に人間に優しい（＝特殊な記法が少ない）ほうが良いと思いました。

Markdown は（方言はいろいろありますが）基本的にルールがあまり多くないため、今回は Markdown をベースに作ってみることにしました。

ただし使い方は邪道

僕は Markdown の『記法』を使うだけで、 Markdown 上での意味を厳守する気は1mmもありません。そもそも書くの文章じゃないですからね！

あくまで Markdown と同じ記法を持つ別の何か、です。

こんな感じのルールにしました

<!-- HTMLコメントはコメントとして扱われます。つまり何も起きません -->

> Ruたん,normal
> キャラクターのセリフは Markdown の引用で表現します。
> 1行目がキャラクター名,表情名で、2～3行目がセリフです。

<!--
ツクールの各種コマンドは画像埋め込みの記法で表現します。
alt の部分にコマンド名、pathの部分にコマンドにわたすパラメータを挿入します。
bgm : 音楽変更
se : 効果音
wait : ウェイト（待ち時間）
addState : キャラクターの頭の上に「自称占い師」みたいな状態を表示する
-->

![se](se_damage)
![wait](60)
![addState](rutan,self_villager)

<!--
リスト＋リンクの形で選択肢を表現します。
なお、この仕組みは作ったけど結局使いませんでした(◞‸◟)
-->

> Ruたん,angry
> 僕は狼じゃないです！

- [信じる](flag1)
- [信るわけねーじゃん](flag2)

## flag1

> Ruたん,smile
> 騙されたな馬鹿め！

![goto](end)

## flag2

> Ruたん,sad
> ひどい～～

## end

<!-- おわり -->

画像でコマンドを表現するあたりが本当に""""邪道"""""って感じですが許してもらおう（？）

この形式で書かれた Markdown を読み込んで、ツクールのイベントコマンド形式のJSONファイルに変換するスクリプトを用意しました。

ゲーム内からは動的にJSONファイルを読み込んで、ツクールにイベントとして認識させて再生する形です。

実際にやってみて

よかったところ

  • かなりスピーディに作業ができた
    • イベント組み込みの時間が大幅に削減できたため、シナリオ量産が比較的容易
    • 動かしてみて確認→修正もツクール上でやるより早い（カンタンに検索できるし）
  • 記法にあまり悩まない
    • テキストエディタのシンタックスハイライトが効くし、記法も少ないので間違えにくい

微妙だった部分

  • ツクールの書式コマンドはキレイに色ついたりしないので見づらい
  • 僕のルビプラグイン、 Markdown のリンクとフォーマット被ってるので変換スクリプト書くときに面倒くさいことになった（自業自得）

以前 YAML を使って同じようなことをしていたのですが、それよりはだいぶましかな……？
とはいえ、もうちょっと課題はありそうですね。

おわり

というわけで、『貴方が狼カードデス！』におけるイベント増殖術でした。

なお、 Markdown を使ったのはメインのランダムゲーム部分だけで、オープニングやTIPSなどのイベントシーンは普通にツクール上で作っています。

というのもピクチャの表示や様々なプラグインの操作などを Markdown の記法で表現するには難しいため、無理なことはせずに決まったパターンで量産が必要な部分だけに絞って使っています。

個人制作において物量は敵なので、いろいろな悪知恵を絞ってショートカットをしていくぞ！！！！！！

『貴方が狼カードデス！』を公開しました

制作 貴方が狼カードデス！

出たな、公開しました記事！

人狼系デスゲーム『貴方が狼カードデス！』

デスゲーム！！！！！！１１１１１１１

人狼モチーフのデスゲームです。
何気に僕が公開する作品としては初めてのADVゲームかもしれません。
……いや、本当にADVかコレ……？

ゲーム内容としては、ゲーム内の4人のキャラクターの会話を聞いて、誰が狼カードの持ち主なのかをプレイヤーが当てるゲームです。プレイの感覚としては、ワンナイト人狼 の実況動画を見ているような感じをイメージしています。

1プレイは短く、何度かプレイすることで仕様書（実績）が集まり、物語が進行していく流れです。いつもの。

一応物語としての終わりもありますが、がっつり構えて物語を読み進めるゲームというよりは、すごく気軽に入っていくタイプのゲームになっているので、ぜひプレイいただけると！
PCまたはスマホのブラウザで遊ぶことができます。

プレイはこちらから

スマホ版も出た！（2023/02/24追記）

Appleちゃん、審査20分で終わって怖くて泣いちゃった（？）

めっちゃ大変だった！！！！！！！！

今作は ゲームジャム30 というイベント合わせて作ったゲームです。
いや、まぁ、締切は去年の10月14日だったんですけど……4ヶ月くらい遅刻してますけど……
（一応、途中まで版ですべりこんだのでセーフってことでひとつ…！）

そんなわけで正直なところ、だいぶ難産でした＞＜；
なかなか表現したいことがうまく表現できず、すごく悶々とした日々を過ごすことに……

セルフちゃぶ台返しもかなり繰り返すことになったりはしましたが、なんだかんだ最終的には良いところに落ち着いたのではないかなと思っています。
たぶんガチで追い詰められたときの僕からしか抽出できないエキスとかが入ってる（？？？）

そして次回は

新作はちょっとおやすみです。
やってみたいことはいくつかあるのですが、ちょっと技術的に色々やってみないとわからんなぁというところがあったりするため、少しお勉強モードというか充電タイムみたいな感じになりそうです。

それと並行して過去作のアップデートを予定しています。
3月中を目処に『パズルネクリア』のちょっとした更新と、『憎悪の獣の地下ドール』の新要素追加のアップデートを検討中。

まだ中身全然準備できてないので、もうちょっと時間はかかりそうですが、こちらもお待ちいただければと思います！

個人ゲーム制作における『まずは短編』で『ニガテ』を知る話

雑談 制作

去年はゲームを公開しました報告記事しか書かなかったので、今年は毎月1つはちゃんとブログ記事を書くことを目標にします！

ループ議論：最初は短編

あらゆる創作分野において「最初は短編から作ったほうが良いよ」という話があります。小説でも漫画でもゲームでもみんな同じですね。 マラソンもいきなり42.195kmから始める人いないですし、創作に限った話ではないかもしれません。

この辺りの話は昔からされてますし、いろいろな本とかにも死ぬほど書いてあるでしょうし、インターネットにも記事とか議論とかいろいろあると思います。

Twitterとかでもちょくちょく流れてきて、僕もちょっと触れることがあったりしたので、今回はその話をまとめてブログに書いてみます。

当然ですが、あくまで僕、Ruたんにとっての主観であることにご注意ください。 「あらゆる人間はポジショントークをしている」という前提を忘れて、人の意見を読んではいけません（思想過激派）

短編を作るメリットは「ニガテを知ること」説

ゲーム制作において短編を作ると良い理由として、経験値が～みたいな話もありますが、僕的には一番のメリットは「自分がニガテな作業を知ることができる」だと考えています。

ゲーム制作、と一言で言ってもいろいろな作業があります。

  • お絵描きとか
  • 素材探しとか
  • データベース設定とか
  • お話書くとか
  • イベント演出設定とか
  • 公開用の作業（サムネとか説明文）とか
  • 宣伝とか
  • 他のクリエイターさん＆プレイヤーさんとの交流とか
  • などなど

で、フツーはこれらが全部完璧にできるなんてことは無さそう……全部できたら完璧超人すぎて逆に怖い！

短編を1個作って公開するところまでやると、これらの作業に一通り触れることができるので「自分が何をやってるときは楽しくて、逆に何をやってるとき厳しいのか」がわかります。

特に「楽しい部分」より、「厳しい部分」のほうを知れるのが僕は良いと感じています。

ここで言う「厳しい」というのは、単純にやるのがしんどいとか、めちゃくちゃ時間がかかるとか、そういったものを包括して「厳しい」と表現しています。

ゲーム制作はすごく時間もかかりますし、作ってる最中は「これ本当に面白いのかな…」と不安になることも多いです。特に「厳しい」作業をしているときこそ心がやられてゲーム制作が続けられなくなってしまったりする可能性が高いです。

なので、短編を作ることで自分のニガテを知って、自分のニガテをなるべく避けられるゲーム制作スタイルで活動できるようにしよう！というのが僕のスタンスです。

せっかくゲーム作りたい！と思ったんだし、ゲーム作りが嫌いになっちゃうような活動はしないほうがいいと思いますしね。楽しく作るためにも、楽しくないことを知ろう！

ニガテを知りつつ「時間感覚」も知る

似たようなところで「その作業にどれくらい時間がかかるのかわかる」というのがあります。要は一通りの作業をしたわけで、それぞれにどのくらい時間がかかったかも振り返ることができるということですね。

大体ニガテなことは時間がかかりがちです。作業自体にも時間がかかるし、作業したあとに自分のMPを回復するために休憩時間が必要だったり……。

この辺の時間間隔を認識できるようになると、「こういうゲームを作ろう！」のようなことを思いついたときに、作るのにどれくらい時間がかかるのかというものの目安がつけられるようになります。

投稿イベントとかコンテストみたいなやつは締め切りがあるので、この辺の感覚がある程度身についていると、そういったものに参加したいなと思ったときにも便利なのでおすすめです。

いや、まぁ、ゲームジャム30に全然間に合ってない僕が言うと説得力が皆無なんですが……理想とそれを実現するのはまた別の話なんですよマジコレ！

おまけ

おまけ1：そもそも「短編」ってなんだよ！

短編の定義は非常に難しいですね……

僕の感覚としては練習としての短編であれば「プレイ時間の長さはどうでもよく、制作期間が1ヶ月くらい」にするのが良いかなと思います。

「1ヶ月」は結構いい期間だと感じていて、

  • ゲーム的なメリット
    • 期間が短いので「こだわりポイント」を1つに絞りやすい
  • 経験的なメリット
    • 「1ヶ月本当に本気で作るとどのくらいできるのか」を測れる
  • メンタル的なメリット
    • 最悪、ゲームが微妙だったり完成できなかったりしても、1ヶ月だからダメージが小さい

……みたいなところで、僕は「1ヶ月」というのを1つの指標にしています。

おまけ2：そういうお前はどうなんだよ

僕のニガテはこの辺りです。

  • 制作期間が長いのがニガテ
    • 2ヶ月以上かかってくると、だんだんメンタルが終わってくる
  • 「絵」をたくさん描くのがニガテ
    • お絵かき系の作業がめちゃくちゃ時間がかかる
    • たくさん描かないといけないとなると、だいぶツライ
  • お話を書くのがニガテ
    • 大まかに決めてから書き始めるのだけど、書いてると話が変わってしまう
    • 収拾付かなくなりがち＞＜；

全般的に「物量が多い」のがニガテです。モノをいっぱい作るのがニガテ。

なので、短めのゲームを中心に作って、1つのゲームで1つのお話を書かずに複数のゲームで1つのお話を書いてみたり、各ゲームで使う絵の雰囲気やサイズをあわせて、使い回しできるようにしたりなどすることで、なるべくニガテを回避するゲーム制作をしています。

ニガテを克服するのではなく、回避するのが僕のゲーム制作スタイル！！！！１１１１
ゲームはやっぱり楽しまないとね！（結論）

Webエンジニア的なツクールプロジェクト構成

制作 RPGツクールMV RPGツクールMZ

注意：フツーにツクールを使う人の参考にはなりません

前提

RPGツクール

RPGツクールMV / RPGツクールMZ はHTML5ゲームを作成できるツールです。
RPGの基本システムが実装された「コアスクリプト」と呼ばれるものと、エディタで生成したマップやキャラクター情報などのJSONファイルをWebで公開することで、PC・スマートフォンなどでHTML5なRPGを動かすことができます。

ツクールのJS面はシンプル

RPGツクールは初心者でも扱える＆買い切りのツールということもあってか、内部には特にトランスパイルやバンドルをするための仕組みは持たず、ツクールMVでは完全なES5、ツクールMZでもベースはES5で一部ES6(ES2015)の記法を含む程度になっています。

買い切りの製品の中に、変にbabelなどを含んでしまうと古いバージョンをいつまでも使い続けないといけなくなったりと長期的には不都合のほうが多そうなため、個人的にはこの仕組みは好印象です。
ゲームは年単位で作る人もいますからね。ツールのマイグレーションとか個人クリエイターの仕事ではないのです。

いや、まぁ強いて言うならちょっと window 直下に色々生やし過ぎだよ～とかはありますが……せめてjQuery達みたいに window.RPGMaker とかに閉じ込めてくれると嬉しかった。

また、プラグインという仕組みがあります。
プラグインと言っても何か大げさな仕組みがあるわけではなく、追加のJSファイルを読み込ませることでエディタ内にパラメータ項目を追加したり、ゲーム起動時に追加のJSファイルを読み込ませることができるような単純なものです。
個人的には「プラグイン」というよりは「MOD」みたいな感じかなぁという印象があります。

本題

シンプルだからってシンプルに使わないといけないわけじゃねぇよな！！（？）

一応、僕はWebエンジニアでもあるので、各種制作の管理をする上では「いつものツール達」を使うことができるほうが便利です。

ツクール本体がシンプルであってくれるおかげで、その外側に環境を構築することは容易です。
ディレクトリ構成や各種ツールなど、自分用にいろいろ試行錯誤しながら構築してきたものについて、ある程度結論がまとまりつつあるため、自分の中のノウハウの整理を兼ねて、今回ブログ記事にまとめてみることにしました。

なお、あくまでこの記事のやり方は「僕のやり方」でしかありません。
そもそも本来のツクールの使い方・使われ方からは逸脱してるでしょう。

環境は使う人やチームによって適切なものを準備するべきです。
この記事はあくまで「僕のケース」という前提でお願いします。

なお、今回は僕が作っている中で一番新しいゲームである「貴方が狼カードデス！」の構成を紹介します。

利用ツール

主に以下のようなものを使います。

  • git
    • バージョン管理のため
  • TypeScript
    • ゲーム用のプラグインの記述のため
  • Webpack
    • ゲーム用のプラグインのバンドルをするため
    • TSのトランスパイルは、最近は esbuild-loader を使って試しています

なお、あくまで「ツクール用のプラグイン」のため、 webpack-dev-server などは利用しません。
ファイルとして出力されていないとツクールのエディタから読み込めないため、ベタに webpack watchしています。

また、エディタには IntelliJ IDEA を利用しています。
もうﾃﾘｼﾞｪｰ無しにコードが書けない体になってしまった……

プロジェクトのディレクトリ構成

プロジェクトのディレクトリ構成について、tree コマンドの結果を加工したものを以下に掲載します。

.
├── .browserslistrc
├── .deployment-zip.js
├── .editorconfig
├── .eslintrc.js
├── .gitignore
├── .ncurc.json
├── .prettierignore
├── .prettierrc
├── app/
├── extensions/
├── node_modules/
├── resources/
├── scripts/
├── src/
├── index.html
├── package.json
├── tsconfig.json
├── webpack.config.js
└── yarn.lock

単一のJSプロジェクトが含まれる構成のようにしています。

app/ ディレクトリ

├── app/
│   ├── audio/
│   ├── css/
│   ├── data/
│   ├── effects/
│   ├── fonts/
│   ├── game.rmmzproject
│   ├── icon/
│   ├── img/
│   ├── index.html
│   ├── js/
│   ├── movies/
│   └── package.json

これはRPGツクールが扱うプロジェクトディレクトリです。
RPGツクールで新規プロジェクトを作成した際に作成するディレクトリに app という名前をつけて、ここに設置しています。
ここに含まれる package.json もRPGツクールが生成するもので、僕が直接編集することはありません。

そのため、基本的には app ディレクトリの中身はRPGツクールのエディタを通じて編集されます。
最終的にはこの app ディレクトリの中身をWebで公開する形となります。
一般的なWebフロントのリポジトリにおける public とか static みたいなディレクトリと同様の扱いです。

extensions/ ディレクトリ

├── extensions/
│   ├── bannerPlugin.js
│   └── eslint/

開発ツール用の拡張機能などを入れる場所です。
現在は eslint の独自ルール設定や、ミニマムな webpack のプラグインを置く場所として使っています。

resources/ ディレクトリ

├── resources/
│   ├── json/
│   └── scripts/

ゲーム中で利用するリソースファイルの一部が入っています。

さすがにPhotoshopのPSDファイルなどを git 管轄に含めたくないため、そういった画像や動画などのリソースは別の場所で管理していますが、シナリオ用のテキストファイルだったり、ちょっとした設定値の含まれているJSON/YAMLファイルが git で管理したいためこのディレクトリに含めています。

例えば、上記の構成では scripts/ ディレクトリの中にシナリオデータのMarkdownファイルが入っており、変換スクリプトを通じてRPGツクール向けのJSON化して、 app/ ディレクトリに出力する……のような使い方をしています。

以下のようなmarkdownファイルでシナリオを書くと……

![se](se_damage)

> ひより,surprise
> ええ？！　ちょっと待ってよ\c[2]ユーシ君\c[0]！
> それはおかしいよ！

![addState](hiyori,self_teller)

> ひより,angry2
> だって、\c[2]ヒヨちゃん\c[0]が\c[2]占い師\c[0]だもん！
> \c[2]ユーシ君\c[0]が\c[2]占い師\c[0]なわけないもん！

以下のようなRPGツクールのイベントコマンド仕様のJSONファイルが生成されます。

{
    "code": 250,
    "indent": 0,
    "parameters": [
    {
        "name": "se_damage",
        "volume": 45,
        "pitch": 100,
        "pan": 0
    }
    ]
},
{
    "code": 101,
    "indent": 0,
    "parameters": [
    "",
    0,
    0,
    2,
    "ひより,surprise"
    ]
},
{
    "code": 401,
    "indent": 0,
    "parameters": [
    "ええ？！　ちょっと待ってよ\\c[2]ユーシ君\\c[0]！"
    ]
},
{
    "code": 401,
    "indent": 0,
    "parameters": [
    "それはおかしいよ！"
    ]
},
{
    "code": 356,
    "indent": 0,
    "parameters": [
    "addState hiyori self_teller"
    ]
},
{
    "code": 101,
    "indent": 0,
    "parameters": [
    "",
    0,
    0,
    2,
    "ひより,angry2"
    ]
},
{
    "code": 401,
    "indent": 0,
    "parameters": [
    "だって、\\c[2]ヒヨちゃん\\c[0]が\\c[2]占い師\\c[0]だもん！"
    ]
},
{
    "code": 401,
    "indent": 0,
    "parameters": [
    "\\c[2]ユーシ君\\c[0]が\\c[2]占い師\\c[0]なわけないもん！"
    ]
}

この辺りはまた別途記事に書いてみてもいいかもですね。

scripts/ ディレクトリ

├── scripts/
│   ├── convert-character.js
│   ├── convert-yaml.mjs
│   ├── generate-scripts.mjs
│   ├── scaffold-scripts.js
│   └── update-scriptList.js

主にちょっとした処理をするためのスクリプトコードを置く場所です。
前述の Markdown のシナリオをツクール用の JSON に変換するコードなども、ここに置いています。

基本的に面倒くさいことを手でやりたくないので、単純処理は手でやらずにササッとスクリプトを書いてここに置くようにしています。

よくやるのはキャラクターの立ち絵画像とかですかね。
表情ごとにレイヤー分けて出力した画像をゲーム用のサイズに縮小して、ゲームに読み込む際の位置指定ファイルを準備する……みたいな作業は絶対に手でやりたくないため、 node-canvas や TexturePacker などを使って画像の加工をするスクリプトを書いています。

src/ ディレクトリ

├── src/
│   ├── @types/
│   ├── data/
│   ├── libs/
│   └── modules/
│   │  ├── _share/
│   │  ├── Achievement/
│   │  ├── BattleTalk/
│   │  ├── Choice/
│   │  ├── Config/
│   │  ├── Core/
│   │  ├── CutIn/
│   │  ├── Effect/
│   │  ├── LoadScript/
│   │  ├── Message/
│   │  ├── Result/
│   │  └── Title/
│   ├── boot.ts
│   ├── header.js
│   └── index.ts

このゲーム専用のプラグインのコードを入れるディレクトリです。
コードは TypeScript で記述しています。

index.ts がエントリーポイントになっており、最終的に1つのプラグインが出力されます。
現実にはゲーム用の機能は複数あるのですが、最終的に出力するプラグインを分ける意味があまりないため、 src/modules/ 以下に各機能ごとにディレクトリを作成し、index.ts からすべて読み込む形にしています。

なお、今作は画面数が少ないためやっていませんが、ゲームによっては起動時に読み込ませる必要がない画面などは dynamic import を使用することでゲーム中に必要になるまで読み込みを行わないようにしたりする場合もあります。

※注：ツクールの既存の挙動を変更するようなものはゲーム起動時に読み込む必要があるため、分けられるものはそれほど多くないです

header.js は webpack でビルド時にファイルの先頭に差し込むコメントが書かれたファイルです。
RPGツクールではプラグイン内にコメントとしてアノテーションを記載することで、エディタ内で専用のパラメータやコマンドを定義する仕組みを持っており、それを利用しています。

本当はこのヘッダのアノテーションも手で書かずに自動化したいなと思っているのですが、ぶっちゃけそんなに書く機会がないためやりかけで放置しています……＞＜；

/index.html

プロジェクトルートに index.html を置いています。
が、これは公開用のHTMLではなく、僕がローカルで動作確認をするためのものです。

上記は別のゲームのものですが、ゲームによってはデバッグ用にパラメータを渡すことで開始シーンを変える……みたいな仕組みを入れており、そのパラメータを指定するためのUIなどを含むデバッグ用のHTMLになっています。
毎回タイトル画面から始まると面倒くさい～～みたいなことはよくありますからね……

おまけ：デプロイメント

RPGツクールにはデプロイメント機能がついており、ゲームディレクトリの中からパッケージに不要なファイル（例えば desktop.ini とかセーブデータとか）を削除してまとめて出力してくれる機能があります。

が、めんどくさいので僕は @rutan/deployment-zip というオレオレツールを使っています。
gitignore 的な指定方法で省くファイルを指定できるため、デバッグマップみたいな製品には含めたくないテストデータも自分で指定して含めないようにできるほか、zipファイルとして出力されるため ゲームアツマール や PLiCy などへの投稿がカンタン！

……え、ツクールにはゲームアツマールにワンボタンでアップロードできる機能もあるから、そっちのほうがカンタンじゃないかって？　HAHAHA！（）

おわり

以上、僕のツクールプロジェクトの構成でした。

今回は全体の構成についてサラッと紹介しました。
ちょっとだけ触れたスクリプト類の話や、自分のゲーム用のプラグインをどう書いているの？という話はそれ単体で記事になってしまいそうなので、また別の機会に書けたらいいなと思います。

去年は「○○を公開しました！」みたいなブログしか書けなかったため、今年は制作の様子だったりといったものも記事にできるといいなーと思っています。

……が、Ruたん飽きっぽいからな！ ぜんぜん書かなかったらごめんね！

プライバシーポリシー
Copyright © Ruたん - 鳥小屋.txt