投稿記事

饗庭淵/喘葉の森 2021/11/08 16:11

次回作『乳愛奴○調教計画』の進捗②


精液風呂! 精液風呂ができたから見て!

さて、本作は「洗脳」「調教」といったジャンルのゲームになるわけですが……
どういうプレイがあるといいのかなあ、というのを悩んでおります。


今のところ予定してるのは上の「精液風呂」とか、バイザーつけて「仮想現実」を見せつけるやつですね。これも定番。


というのも、こういう研究ツリーみたいなのを用意しようかと思ってるんですが、「ツリーとしてあまり面白くないな……」と。

「睡眠薬」ってあるけど睡眠○プレイはもっとこう、日常とか……そういう場面で活きるものではないのか?! 
拉致監禁して調教みたいなシチュではあまり映えなくない?!
とかも悩んでます。


そんなわけで、なにかアイデアがあればいただけないかと思ってます。
ただ、本作はいうまでもなくパイズリオンリーですので、その範囲にそぐうもので。つまり女性器になにかするようなのはNGです。
範囲がグッと狭まったわね!!
パイズリのシチュエーションでもいいですが、できれば研究ツリーが面白い形になるようなのがよいです。

たとえば……なんだろう……(それが浮かばないから募集している……)
設定上、技術レベルはなんらかのなんかで逸脱してるのでやたらファンタジーだったりSFだったりするようなのもたぶん大丈夫です。
「思考盗聴」くらいは平気でできます。
調教対象がなにを考えているかは丸わかりです。
(思考盗聴をツリーに組み込めばいいのでは?)
(確かにそれは正しい、正しいのだが……! 必然的に台詞の分岐が発生してめんどくさい……!)

そうですね、「思考盗聴」みたいなのはかなりアリではないかと思います。
ゲームが有利になるわけではなくなんか楽しいみたいなのもいいですね。


あるいは、オススメの洗脳・調教シチュの作品とかでもOKです。よろしくお願いします。



あ、ちなみに調教済みの助手の子ともパイズリできます。
本題とは関係ありませんがこれだけはお伝えしたかった。
  • アイコン
    ユーモア ID00244819
    次回作楽しみにお待ちしております。

1件のチップが贈られています

チップを贈るにはユーザー登録が必要です。チップについてはこちら

饗庭淵/喘葉の森 2021/10/28 20:43

『温泉旅館のパイズリ怪異』を振り返る

さて、例によって制作の経緯などを振り返っていきましょう。
本作は『乳愛奴○調教計画』の作業を他人に投げている間、暇だなあと思ってつくった作品です。
どっかで聞いたような話ですね。

で、前々からどこでもパイズリシステムっぽいゲームはつくりたいなと思ってました。
ヒロインが後ろからついてきて話しかけるといつでもえっちなことができる!
きっと楽しいはずです。
以前に似たようなシステムは組んだので簡単にできるでしょう。
きっとちょうどよい暇つぶしになるはずです。

※以下、ネタバレし放題です。
気になる方は本編をプレイの上お読みください。

・なにが面白い?

ゲームを新しくつくりはじめる際にはまずこの点を考えます。

この点についてはさほど不安はありませんでした。
なんたって過去に黒先輩という似たようなゲームをすでに作ってますからね。
面白さについてはすでに保証されているといえます。

・ホラーっぽい雰囲気のなか適当な謎解きをしつつ、
・謎に詰まれば後輩がヒントをくれ、
・精液が溜まりればどこでもパイズリ

これで間違いはないでしょう。
『黒先輩』と異なる点は「精液ゲージ」の存在です。
「精液ゲージ」の及ぼす影響だけが未知数でしたので、そのへんは精査する必要がありました。

さて、本作にかぎらず私がなにかゲームを作る際にはだいたい既存作を参考に作り始めます。
言い換えると、既存作で「面白い」と感じたことの再現です。

『黒先輩』も元はといえば「オープンワールドゲームでメインクエストを無視する楽しさ」がもとになっています。
『黒先輩』自体はオープンワールドでもなんでもないですが、「謎解き」というメインクエストに対しまったく無関係の「セクハラ」要素は、ゲーム上まったく必要性はなく、プレイヤーがただ楽しいから行うものです。

つまりは「必要だからやる」のではなく、「自分でやりたいから選択する」という体験のゲームデザインというわけです。
「どこでもパイズリシステム」もそれと同じコンセプトです。

仲間が後ろからついてきてどこでも話しかけられるようなゲームはあるのに、なぜその仲間がえっちな爆乳ヒロインではなく、いつでもどこでもパイズリできるようなゲームはないのか?
その思いが本作に表れています。

『魔機人形』についても過去に似たようなことを書いてます。
メイドさんMODとか仲間をぞろぞろ引き連れるの楽しいよね、という体験の再現がコンセプトです。
もともとは一要素に過ぎないものを抜き出しそれに特化するわけですから、再現でありつつ単なる焼き直しやパクリではなくゲームとしては独自の味になるかと思います。

誰も見たことのない完全なオリジナルを目指すよりは、「知ってるけど少し違う」くらいがちょうどいいと思ってます。


・UIを設計しよう

なにからつくりはじめたのかあまり覚えてませんが、一つ覚えてることがあります。


この画面はかなり初期につくりました。
エロゲーといえばやはりこれですよ。エロステータス画面。これは必須です。

これもまた過去に体験した「面白かった」の再現です。
正確には面白いというより「えっちだ……」の再現でしょうか。

ちなみにこれを初めて感じたのは『Natural Another One 2nd -Belladonna-』という作品です。なつかしすぎる。
パラメータがあるだけでなんか臨場感増すなあ! と感動したのを今でも覚えてます。


メニュー画面のUIもどうしようかなあと思いましたがさっぱりした感じに。
『百合籠』くらいすっきりさせたかったですが。
メニューに後輩の爆乳立ち絵を出すことも考えましたが、話しかければいつでも拝めるんだからメニュー画面に出すのは余計かなと思って却下しました。

・温泉旅館っぽいマップをつくろう

と、その前になぜ温泉旅館?


元ネタはこちらです。
えっと……2015年の絵ですね。そんなに前?!

題材はわりとなんでもよかったというか、規模はそこまで大きくならない(黒先輩みたいに一つの屋敷が舞台)とか、せいぜい条件はそれくらいで、なにかないかなあと目についたのがこちらのイラストです。

で、旅館はちょうどいいなと思って実際の旅館の見取り図を調べながらマップを組みました。
カラオケルームといいつつ特に歌えるわけでもないパイズリ専用部屋がありますが、それは見取り図をいろいろ調べていたときに「へえ、旅館にカラオケとかあるんだ」と思ったからです。

実際にどの旅館を参考にしたよ、とか貼れるわけではありませんし、いうほどモデルになっている旅館はありませんが、要はマップを組むときにはググりますという話です。

マップデザインとして意識した点は、序盤に渡り廊下を歩かせる点です。
なんかいい感じに綺麗なマップを見せたかったのです。


・謎解きをでっち上げよう

パイズリがメインのゲームではありますが……

本作の制作順としてはパイズリはひとまず後回しにして、探索・謎解きゲームの部分から作り始めました。
パイズリはひたすら絵を描くだけでゴールの見えている作業ですが、謎解きなどは作る方も思いつかなければ延々と詰むことになります。

そういうわけで、本作のパイズリ絵を描きながら作業用BGVとしてそれっぽいゲームの実況動画を延々と流していました。

あれ? さっきと言ってること違くない?
違いません。謎解きをつくるには多くの参考資料が必要なのです。
謎解きゲーをつくるのに私自身は実のところ素養があまりないのでそれを補うために実況プレイ動画をいっぱい見ました。

なんだかんだふつうに楽しんでただけでどれだけ参考になったかは定かではないですが……
意識した点としては、「一つのアイテムを手に入れいたら二つ以上の使い道が欲しい」とかそんなんです。といいつつ、一つしか使い道のないアイテムも多いですが。

また、謎解きと呼べるようなものではありませんが、カウンターを飛び越えたり台の上に飛び乗ったり見たいな動きは「あ、こういうことできるんだ」と気づいてもらってちょっとだけ気持ちよくなってもらえるかなあ、みたいな意図です。

本作の謎解きはぶっちゃけてしまうと時間稼ぎです。
プレ時間の水増しというと聞こえは悪いかもしれませんが、「体験」の提供には時間が必要です。
「旅館をうろうろ歩き回る」という体験の設計のために謎解きを用意します。
あとは「謎を解いた先になにがあるのか?」というワクワク感を意図しています。

ところで、謎解きの難易度設計って難しいですよね。
私は謎を解くまでの工数でだいたい測れるのではないかと思ってます。

「○○の鍵を手に入れた。これで○○の部屋が開く」

謎解きとすら呼べないほど非常にシンプルです。

「手がかりが三つ各地に散らばっていて、それを合わせると謎が解ける」

まず三つの手がかりを集めるという工数が生じます。
そして各地に散らばっているという要素が合わされるとプレイヤーの思考は枝分かれを強いられます。
「手がかりは三つだけなのか?」「他にも手がかりはあるのか?」「なぜあの場所にあったのか?」
結果、難易度が上昇します。

本作で一番難しいのはロッカーの番号ではないでしょうか。
ここで難しい謎解きを挿入したのは時間を稼ぎたかったからです。
「あーでもないこーでもない」と頭を悩ませる時間が没入感を与えます。
まあ、本作はエロがメインなので詰まった場合はぶっちゃけ答えを教えてもらえます。
このへんは『黒先輩』と同じですね。

でもせっかくだからそれなりに難しい謎解きも欲しいな……隠し要素としてちょっと難しい謎解きを用意しよう……その難しい謎解きを達成した後の報酬は?


ヒロインが増えました。

・ストーリーをでっち上げよう

パイズリがメインのゲームではあるけれども……
それなりの臨場感、ホラー感を出すためにそれっぽいストーリーを用意します。

この作業はだいぶ楽でした。
悪く言えば手癖です。

もとよりなんかホラーっぽいのを書きたいなあと思っていたので実話怪談系の本を読み漁っていました。
そうして得た知識をもとにホラーっぽい話を書いていきます。

実際にホラー体験をした人はどんな反応を示すのか?
そうしたホラー現象が科学的に検証不能であるのはなぜなのか?
実話怪談ってそういう体なだけでフィクションなんじゃないの?
でもわりと「勘違い」で済まさせそうな実害のない話ばかりだな……

とかあれこれ考えながら話をまとめます。


また、マップのそこら中に断片的な文書が落ちていて、それらを読み進めることでストーリーの全体像が見えてくるという構成はカリスあたりからずっと続けている手法です。
『黒先輩』にもその片鱗はなくはないですね。

これは自作でも何度もやっていたり、『Fanastasis』をプレイしていても面白さを感じた要素です。
まあ、外れはないでしょう。もちろんテキストの質にもよりますが。

CG集にせよ漫画にせよ、ストーリーラインが一本しかない作品はエロ以外のことをしていると「余計なことしてないでさっさとやって?」となりかねない問題がありますが、ゲームの場合は「寄り道」がしやすくていいですね。

また、真相とかそういうのは特に考えずに書きはじめていますので、一通り書き終わって思いついたら帳尻を合わせる修正を入れます。


・パイズリ実装と精液ゲージの仕様を考える

どこでもパイズリシステムである以上、場所によって変化する多様なパイズリを描きたい……!

とか言ってたらキリがないので、そこまでバリエーションはありません。
せいぜい「縦パイズリ」「寝パイズリ」「座りパイズリ」「馬乗りパイズリ」「搾りパイズリ」くらいです。


どこでどのようなパイズリができるのか、はこのように話しかけるたびに左上に表示されます。
ただ、これは初期の初期にはありませんでした。
やっぱいるよなあとは思いつつ、「背後霊テストプレイ」によって「いるに決まってんだろ」と思い実装したものです。

第一のテストプレイヤーは作者自身ですが、何度も何度もプレイしているうちに仕様を完全に把握しているだけでなくいろいろ慣れてしまうものです。
他人にテストプレイをさせるのは必ずやってください。

「このゲーム、テストプレイしてないのでは?」と揶揄されるゲームがありますが、おそらくはテストプレイを「させていない」が実情なのではないかと思っています。

閑話休題。
本作において特に新しい試みは「精液ゲージ」の存在です。
ロリ巨乳の里にて』にもそれらしいゲージはありましたが、本作では同じ仕様のままではいられません。
『里』における仕様は「眠れば回復」「レベルアップで最大値上昇」「精液回復薬でも回復」「たまに演出でも回復」といったものでした。

本作では眠ることもなければレベルの概念もありません。
ただ、「精液回復薬」「演出による回復」は使えそうです。

回復の仕様で考えたのは「リアルタイムで少しずつ回復」「行動ごとに回復」ですが、結局どちらも採用されることになりました。
前者の場合、ただ待つ時間が生じてしまわないか?
後者の場合、回復に限界が生じてしまわないか? あるいは同じ行動を連打することにならないか?

それぞれ問題点はありましたが、リアルタイムで回復することで限界問題は解決でき、行動によって回復することでただ待つしかない問題を解決できると考えました。

また、精液が回復する行動として「後輩に話しかける」を採用しましたが、話しかけるたびに回復していたのではただ連打するだけのゲームになり没入感が削がれてしまいます。
よって、「新規会話」のときだけ精液回復が発生する仕様としました。
新しい会話はゲームを進めるごとに増えていきます。
つまりはゲームを進めるモチベーションにもなるわけです。やったね。

さて、まだ大きな問題が残っています。
回復速度をどの程度に調整すべきか。これが難しい。

パイズリの種類がそこまで多くないので何度も頻繁に精液が溜まってもやることがなくなってしまう。
せっかくなので焦らされるような体験を味わってほしい。
「やった! 溜まった」感のためにはそこそこ時間がかかってほしい。
でもプレイヤーとしてはさっさと何度もパイズリしたいはず……。

というわけで、とりあえず暫定的に決めてテストプレイをしてもらい、そのフィードバックから回復速度を調整しました。
結果として初期verから比べるとかなり速くなりました。


・エロは手段ではなく目的

本作のゲームデザインとしてはこの点を意識しました。

エロとゲームを合わせるとき、たとえばですが……
「錬金術の材料に精液が必要」「だからエッチをして精液を搾り出す」
という構造にしたとします。
この場合、エロは「手段」となるわけですが……

ゲームに没入すればするほど「早く新しいアイテム錬成したいからエロシーン飛ばせねえかな……」になりかねない問題が生じてしまいます。
錬金系ゲームはそれだけでも面白いものです。
その「手段」の部分にエロを足すと、「テンポを削ぐ余計なもの」になってしまうかもしれません。

そういうわけで、私はエロは「目的」にした方がよいのではないかと考えています。
あるいは「報酬」とも言い換えられます。
たとえば「めちゃくちゃ強いボスを倒した報酬としてのエロシーン」
強いボスを倒すためにあらゆる準備と工夫をし、やっとのことで倒せた。
一息つき、達成感に浸っているうえでさらにエロシーン。
むしろこれが見たくてボスを倒したんだよ!
となると、ゲームとエロがうまく噛み合うのではないでしょうか。

本作においても、パイズリはゲームを進めるうえでほぼ必要のないものです(一つだけ例外あり)。
むしろゲームを進めた報酬として、「100円玉を見つけると栄養ドリンクが買える」「栄養ドリンクが飲めると精液が回復する」「精液が回復するとパイズリできる」という構造になっています。

つまり最終到達点がパイズリなのです。
本作では100円玉をいくら集めたからといって、たとえば強い武器のようなゲームで有利になるようなものはなにも得られません。ただパイズリできるだけです。

それでよいのか?
いいんです。
前にも似たような記事を書きましたが、ゲームを進めるうえでなにか有利になるようなものではない「報酬」としてのストーリーという発想に近いものです。

そもそも、スーパーマリオワールドのドラゴンコインだって集めたからってなにもいいことはありません。ただ集めるのが楽しいだけです。
そのうえパイズリもできる!
ならよいではないですか。

別にパイズリはしなくてもゲームはクリアできる。
でもしたいからする。

もとよりゲームとはそういうものです。
「しなければならない」からゲームをプレイするのではありません。
「したい」からゲームをするのです。


・その他細かい点

・最大量
「実は精液ゲージの最大量増えてるんだけど気づいてた?」
「え、全然気づいてなかった。アハ体験かよ」

テストプレイの段階からこの問題はありましたが、製品版をプレイした方にも同じ経験をされた方はいるのではないかと思います。
一応、対策としてなんかそれっぽいエフェクトが出るようにしましたが、まだわかりにくい!
「精液量をHPとかみたいに数値として可視化すればええんちゃう?」とは思いましたが、なんの説明もない謎のゲージの方が面白いかなって……
このへんは作家のエゴが出てしまった部分でしょうか。


・脱出ゲーム“ではない”
このゲーム実は「脱出ゲーム」ではありません
「温泉に入ったらクリア」なのですが、これもわからないですよね。
ただ、ハーレムエンドが存在する仕様上、「あれ? これで終わった?」「回想モードが開放された」「まだありそうだな……」となると思いますので、噛み合っているようないないような。


・扉の演出
細かいこだわりポイントは鍵のかかった開かない扉を調べるとガタガタ震えるやつですね。ホント細かいですが。
鍵を開ける場合はどの鍵で開けたのかわかるように「○○の鍵を使った!」とメッセージを出します。これも大事です。


・パイズリ誤爆防止
後輩に話しかけたときの選択肢は上から順に「話す」「パイズリ」「どいて」になっています。
実はこれ、もともとは「話す」がなくて「パイズリ」「どいて」だけでした。
するとしたくもないのにパイズリを誤爆してしまうリスクがありました。
もっと精液を溜めてからしたかったのに! しかも長い!

そんなわけで、誤爆防止に「話す」が一番上にあります。
初期で無選択状態にするUI(カーソルキーを押すと選択状態になる)もよくありますが、あれ嫌いなんですよね……めんどくさくて……。


・端書の合体
足し算すればいいだけなんですが、電卓とかを取り出して計算するのはめんどくさいだけでなく、「本気でこんなことさせるつもりか?」とプレイヤーにメタ読みさせるようなことになりかねません。
という感じの指摘がありました。
せっかくそれっぽいUIがあるので合体できるようにしました。


・文書コレクション
回想モードのためエロシーン回収はエロゲーなら定番ですが、本作には文書も収集要素としてありますので、ゲームクリアフラグが立った場合には最大数と取得数を表示するようにしました。
最初から表示させないのは没入感を削ぐことを懸念してです。


・タイトル画面
ロゴがぷにってするやつ好き。

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

饗庭淵/喘葉の森 2021/10/28 16:56

次回作『乳愛奴○調教計画』の進捗

Ci-enといえば進捗報告!
というわけで次回作の情報です。


次回作として制作中なのはこちら『乳愛奴○調教計画』です。
前々からちょいちょいツイッターには上げてましたが、タイトル発表は初かもしれません。

ちなみに上の画像はゲーム中のものではなくクリップペイントでつくった設計図のようなものです。
UIデザインをする際にはこのようにレイアウトを考えることが多いです。


それぞれの機能についてもこんな感じ。
開発中のものなので実際の画面は変更される可能性があります。というかたぶんされます。


あとはこんなリザルト画面とか。


ヘルプ画面とか作りたいなあって思ってます。
(まだできてない)

さて、ツイッターを見ていた方はわかるかもしれませんが、本作についての情報が出たのは実のところ温泉旅館より前です。

妙だな……つまりそれだけ制作に時間がかかっている……
まさか、温泉旅館を遥かに凌ぐ規模の大作ということか……?!

と、思ったかもしれませんが、本作はそこまでの大作ではありません。
(もちろん温泉旅館よりは大きいですが)

本作の制作に時間がかかっているのには別の要因があります。
いくつかの作業を部下(のようなもの)に投げているからです。

いっぱいゲームつくりたいなあ、めんどくさい作業が多いなあ、と前々から思っていまして。
そんなわけで開発環境の規模を拡大するため人員を増やすことにしました。
ツクールにもプログラミングにも初心者だったりしたので要は研修期間中です。
ので、どうしても時間はかかる。仕方ない。

で、暇だなあと思って作ったのが温泉旅館です。
2か月ほど暇を潰しましたが、こちらの進捗はあまり進んでません。
いえ少しは進みました。少しは。

温泉旅館では描き文字演出や動きっぽい演出などパイズリシーンの演出をいろいろ試してみましたが、カメラワークも欲しいな……欲しくない? と思い、本作(調教ゲー)では導入してみることにしました。


そうしてつくられたオープニングがこちらです。
本作はおっぱいが大きくなるゲームなので初期状態ではかなり小さいです。
後半はチュートリアルっぽいものをやりたいと思いつつ仮置きです。


ちなみに金髪ツインテールの子は調教済みの助手キャラです。
こういう進行に便利なキャラがいないとやっぱ不便だなあと思って生えました。

完成はいつごろになりますでしょうか。少なくとも来年ですね。
2022年の前半くらいに……そして来年は2作くらい出したい……
だが……なにもわからない……

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

饗庭淵/喘葉の森 2021/10/27 20:01

どこでもパイズリシステムを実装しよう

どこでも……? パイズリ……? システム……?


これのことです。

要は常にヒロインが後ろからついてきて話しかけるとどこでもパイズリができるというそのままのシステムなのですが、意外とそれっぽいシステムのゲームを見ません。
それこそ私の過去作『黒先輩』くらいなものでしょうか。

わりと汎用性の高いシステムな気がするので実装方法について共有しておきます。

※以下の記事は中~上級者向けです。
プラグイン? オーバーライド? と聞いてわからない方にはあまりオススメできません。


・フォロワーに独立してもらおう

似たようなことは過去作『魔機人形』でやったものです。
本作はそのマイナーチェンジ版といえます。

後輩にせよ魔機人形にせよ、ついてくるこいつらはなにものなのか?


こいつらです。

こいつらのことを「フォロワー」と呼びます。
デフォルトではただプレイヤーの後ろをついてくるだけの存在ですが、本作ではこのフォロワーを独立させ、当たり判定をつけて機能させています。

まずは独立させる方法です。
プレイヤーに追従して動く処理がありますので、これを消しましょう。
この処理はGame_FollowersのupdateMoveで各フォロワーごとにchaseCharacterが実行されることで動いてます。
(Game_FollowersとはGame_Follower=個々のフォロワーを格納しているクラスのことです)
ので、以下のようにオーバーライドするとよいでしょう。

Game_Followers.prototype.updateMove = function() {
};

Game_Follower.prototype.chaseCharacter = function(character) {
};

要らない処理なので空白にしてしまうわけです。


Game_Followers.prototype.update = function() {
    /*if (this.areGathering()) {
        if (!this.areMoving()) {
            this.updateMove();
        }
        if (this.areGathered()) {
            this._gathering = false;
        }
    }*/
    for (const follower of this._data) {
        follower.update();
    }
};

あるいはこうでもよいです。
プレイヤーの後ろをついてくる処理をコメントアウトしています。


さて、以上を適用してゲームを実行するとどうなるでしょう?


見事フォロワーを置き去りにできました。

・フォロワーに動いてもらおう

さて、動かなくなったので今度は代わりに別の動きをしてもらう処理を書きます。
ツクールにおいてリアルタイムの処理はupdateという関数でなされています。
この関数は毎フレーム、つまり1秒に60回呼び出されるものです。

では、Game_Followerのupdateにはなにが書かれているでしょう。

Game_Follower.prototype.update = function() {
    Game_Character.prototype.update.call(this);
    this.setMoveSpeed($gamePlayer.realMoveSpeed());
    this.setOpacity($gamePlayer.opacity());
    this.setBlendMode($gamePlayer.blendMode());
    this.setWalkAnime($gamePlayer.hasWalkAnime());
    this.setStepAnime($gamePlayer.hasStepAnime());
    this.setDirectionFix($gamePlayer.isDirectionFixed());
    this.setTransparent($gamePlayer.isTransparent());
};

いろいろ書かれていますが……
要するにこれは全部「プレイヤーに従え」という処理です。
いけません。まだプレイヤーから独立できていないようです。消しましょう。

Game_Follower.prototype.update = function() {
    Game_Character.prototype.update.call(this);
    this.setTransparent($gamePlayer.isTransparent());
    this.updateDashing();
    this.updateAction();
};

こうなります。

ちなみにsetTransparentは透明設定で、これだけは残しておきます。
プレイヤーが透明の場合はフォロワーが透明でだいたい問題ないからです。
(もし問題がある場合はこの行も消す)

さて、唐突に表れたupdateDashingupdateActionですが、これは今から書きます。
updateDashingは本来Game_Playerのみが持つ関数で、文字通り「ダッシュしているかどうか」を判定する関数です。
updateActionはまったくの独自定義関数です。重要なのはこちらです。

まずは簡単に「プレイヤーの方を向く」という処理を書いてみます。

Game_Follower.prototype.updateDashing = function() {
};

Game_Follower.prototype.updateAction = function() {
    this.turnTowardCharacter($gamePlayer);
};

updateDashingの方はひとまず仮に空のものを置いておきます。


これでプレイヤーの方を向く動きができました。
あとはこの応用です。
そうですね、次はランダムに動かしてみましょう。

Game_Follower.prototype.updateAction = function() {
    this.moveRandom();
};

これでフォロワーは好き勝手に動き回るはずです。


いくらなんでも好き勝手すぎる。

どうしてこんなことに?
updateは毎フレーム、つまり1秒間に60回呼び出される関数です。
1秒に60回もランダムに動けばこうなってしまうのは当然の結果です。

よって、行動回数を抑制する処理を書かねばなりません。
そうですね、動くのは1秒に1回くらいで十分でしょう。
つまり60フレームに一回動けばいいわけです。

Game_Follower.prototype.updateAction = function() {
    if(this._waitCount > 0){
        this._waitCount--;
        return;
    }
    this.moveRandom();
    this._waitCount = 60;
};

つまりこうです。


今度はまともな動きになりました。
障害物は平気で無視してますが、これはまだフォロワーに当たり判定を実装していないからです。
動くようになると気になりますので、次は当たり判定を実装してみます。


・フォロワーを実体化させよう

フォロワーには当たり判定がありません。
壁も平気ですり抜けるし、プレイヤーとも触れ合えません。なぜでしょう?

①すり抜けフラグがtrueになっているから
②衝突判定がそもそも実装されていないから

答えは両方です。
まずは①から見てみます。

Game_Follower.prototype.initialize = function(memberIndex) {
    Game_Character.prototype.initialize.call(this);
    this._memberIndex = memberIndex;
    this.setTransparent($dataSystem.optTransparent);
    this.setThrough(true);
};

Game_Followerのinitialize(初期化)関数です。
ここにあまりにもそれっぽい記述があります。
this.setThrough(true)です。これを消しましょう。


プレイヤーやお互いのことは無視しますが、マップ上の障害物にはちゃんとぶつかってるのがわかると思います。
つまり、キャラクター同士の衝突判定とマップの衝突判定は別物だということです。

次は②のキャラクター同士の衝突判定を実装します。

Game_CharacterBase.prototype.isCollidedWithCharacters = function(x, y) {
    return this.isCollidedWithEvents(x, y) || this.isCollidedWithVehicles(x, y) || this.isCollidedWithFollowers(x,y);
};

Game_CharacterBase.prototype.isCollidedWithFollowers = function(x, y) {
    const followers = $gamePlayer.followersXyNt(x, y);
    return followers.some(function(follower) {
        return follower.isVisible();
    });
};

Game_Player.prototype.followersXyNt = function(x, y) {
    var followers = this.followers().visibleFollowers();
    return followers.filter(function(follower) {
        return follower.posNt(x, y);
    });
};

もとからある衝突判定をもとにフォロワーにも適用させたものです。

この処理を書くとどうなるか?
プレイヤーがフォロワーを通り抜けできなくなります。
ですが、フォロワーの方はプレイヤーを通り抜けます
衝突判定はそれぞれのキャラクターごとに設定しなければならないのです。
これはGame_Eventを参考にしましょう。

Game_Follower.prototype.isCollidedWithCharacters = function(x, y) {
    return (Game_Character.prototype.isCollidedWithCharacters.call(this, x, y) ||
            this.isCollidedWithPlayerCharacters(x, y));
};

Game_Follower.prototype.isCollidedWithPlayerCharacters = function(x, y) {
    return this.isVisible() && $gamePlayer.isCollided(x, y);
};

つまりこうです。


これでフォロワーが実体を得ることができました。


・フォロワーに話しかけられるようにしよう

せっかく実体化したので話しかける処理を入れましょう。
これもGame_Eventが参考になります。
どちらかというとプレイヤーが主体となる処理なのでGame_Playerの方に書きます。

Game_Player.prototype.triggerButtonAction = function() {
    if (Input.isTriggered("ok")) {
        if (this.getOnOffVehicle()) {
            return true;
        }
        this.checkEventTriggerHere([0]);
        if ($gameMap.setupStartingEvent()) {
            return true;
        }
        this.checkEventTriggerThere([0, 1, 2]);
        if ($gameMap.setupStartingEvent()) {
            return true;
        }
    }
    return false;
};

プレイヤーがイベントを調べるときの関数はこのへんです。
近い処理はcheckEventTriggerThereです。
これを参考にcheckFollowersTriggerThereという関数を書いて挿入してみます。

Game_Player.prototype.triggerButtonAction = function() {
    if (Input.isTriggered("ok")) {
        if (this.getOnOffVehicle()) {
            return true;
        }
        if(this.checkFollowersTriggerThere()){
            return true;
        }
        this.checkEventTriggerHere([0]);
        if ($gameMap.setupStartingEvent()) {
            return true;
        }
        this.checkEventTriggerThere([0, 1, 2]);
        if ($gameMap.setupStartingEvent()) {
            return true;
        }
    }
    return false;
};

Game_Player.prototype.checkFollowersTriggerThere = function() {
    const direction = this.direction();
    const x1 = this.x;
    const y1 = this.y;
    const x2 = $gameMap.roundXWithDirection(x1, direction);
    const y2 = $gameMap.roundYWithDirection(y1, direction);
    this.followers().forEach(function(follower) {
        if(follower.isVisible() && follower.posNt(x2,y2)) {
            follower.talkPlayer();
            return true;
        }
    }, this);
};

Game_Followers.prototype.forEach = function(callback, thisObject) {
    this._data.forEach(callback, thisObject);
};

Game_Follower.prototype.talkPlayer = function() {
    this.turnTowardPlayer();
};

待ってくれたまえ。コードの洪水をワッといっきにあびせかけるのは!


なにはともあれ、これで話しかけるとこっちを向く処理まではできました。

先にも書いた通りcheckFollowersTriggerThereという関数の中身はcheckEventTriggerThereを参考にしたものです。
プレイヤーの現在位置と向きをもとに、その先にフォロワーがいるかどうかを判定しています。
決定キーを押したときフォロワーがいたのなら話しかけたという処理が成立し、talkPlayerという関数が呼び出されます。

talkPlayerの中身は現在は「プレイヤーの方を向く」だけです。
this.followers().forEach~のあたりは、フォロワーは複数いるのでfor文で回してすべてのフォロワーについて確認しているということです。

さて、ここまでできたらtalkPlayerの中身を書き換えるだけで話しかけるという処理は完成します。
コモンイベントでも呼び出しましょう。

Game_Follower.prototype.talkPlayer = function() {
    this.turnTowardPlayer();
    this._waitCount = 60;
    $gameTemp.reserveCommonEvent(1);
};

ただ、これではすべてのフォロワーで同じコモンイベントが呼び出されることになります。

キャラによって別のコモンイベントを呼び出したい場合はたとえば以下のように書きます。

Game_Follower.prototype.talkPlayer = function() {
    this.turnTowardPlayer();
    this._waitCount = 60;
    const actorId = this.actor().actorId();
    $gameTemp.reserveCommonEvent(actorId);
};

これでアクターIDと同じ番号のコモンイベントが呼び出されます。


こんな感じにコモンイベントを組んでおきます。
さて、実行してみましょう。


おお……これはもう、完成なのでは……??


・フォロワーが邪魔!!

ただ、このシステムには問題があります。
フォロワーが実体をもって動き回るせいで邪魔なのです。

ふつうのRPGでも町の人が邪魔をして通れなくて困る経験はあると思います。
フォロワーはそれが常について回るのです。どうすればいいでしょう?

解決手法はほかにもあるかもしれませんが、一定時間以上ぶつかり続けると場所を交換する処理を組みました。

これもプレイヤーが主体となる処理です。Game_Playerに記述します。
checkEventTriggerTouch関数のなかに入れ込んでしまいましょう。

const _Game_Player_checkEventTriggerTouch = Game_Player.prototype.checkEventTriggerTouch;
Game_Player.prototype.checkEventTriggerTouch = function(x, y) {
    _Game_Player_checkEventTriggerTouch.apply(this, arguments);
	this.checkFollowersTouching(x, y);
};

Game_Player.prototype.checkFollowersTouching = function(x, y) {
    this.followers().forEach(function(follower) {
        if(follower.posNt(x,y)){
            follower.turnTowardPlayer();
            follower.countObstacle();
            if(this.isDashing()) follower.countObstacle();
        }else{
            follower.resetObstacle();
        }
        if(follower.obstacle() > 20) {
            this.swapFollower(follower);
        }
    }, this);
};

まずこれは20フレームぶつかり続けるとswapFollowerが起こるという処理です。
countObstacleはフレームをカウントする関数です。
resetObstacleはカウントをリセットする関数です。
以下のように書きます

Game_Follower.prototype.countObstacle = function() {
    this._obstacle++;
};

Game_Follower.prototype.resetObstacle = function() {
    this._obstacle = 0;
};

Game_Follower.prototype.obstacle = function() {
    return this._obstacle;
};

swapFollowerはjumpでプレイヤーとフォロワーの位置を交換する処理です。

Game_Player.prototype.swapFollower = function(follower) {
    this.jumpStraight();
    follower.turnTowardPlayer();
    follower.jumpStraight();
    follower.resetObstacle();
};

Game_CharacterBase.prototype.jumpStraight = function() {
    var x = 0;
    var y = 0;
    const d = this.direction();
    if(d == 8){
        y = -1;
    }else if(d == 6){
        x = 1;
    }else if(d == 4){
        x = -1;
    }else if(d == 2){
        y = 1;
    }
    this.jump(x,y);
};

ここで注意ですが、ツクールはデフォだとプレイヤーがジャンプするとフォロワーも一緒にジャンプする仕様になってます。フォロワーに自我はないのか。
ので、その処理を無効にする必要があります。

Game_Player.prototype.jump = function(xPlus, yPlus) {
    Game_Character.prototype.jump.call(this, xPlus, yPlus);
    //this._followers.jumpAll();
};

this._followers.jumpAll();をコメントアウトしましょう。


これで邪魔なフォロワーと立ち位置を交換する処理が書けました。やったね。


・フォロワーについてきてもらおう

肝心なことを忘れていました。
今のままではフォロワーとは名ばかりのただランダムに動き回るだけの存在です。
よって、とりあえずランダムに動くだけの処理を書いていたupdateActionを改良します。

また、主人公を追いかける処理ですがツクールにはデフォで経路探索の関数が用意されています。
クリック操作によるプレイヤー移動でクリック先に向かう動きに使われています。
これを利用させてもらいましょう。
というより、ツクールMVのプラグインであるSmartPathをちょっと改造させてもらって使います。

Game_CharacterBase.prototype.setTarget = function(target, targetX, targetY) {
    this._target = target;
    if (this._target) {
      this.setTargetXy();
    } else {
      this._targetX = targetX;
      this._targetY = targetY;
    }
};

これは向かう先、つまり文字通りターゲットをセットする関数です。
第一引数のtargetにはcharacter、第二・第三引数は座標をセットします。
フォロワーの向かう先はプレイヤーですので$gamePlayerを入れればよい、はずですが……

実は、これには問題があります。
フォロワーは$gamePlayerの中に含まれているクラスなのです。
つまり無限ループ構造が発生します。
MVのころはこれで問題なかったのですが、JSON変換かなんかの仕様が変わった影響で、MZだとセーブができなくなるのです。

よって、苦肉の策ですが以下のようにします。

Game_CharacterBase.prototype.setTargetXy = function() {
    if(this._target === 'player'){
      this._targetX = $gamePlayer.x;
      this._targetY = $gamePlayer.y;
    }else{
      this._targetX = this._target.x;
      this._targetY = this._target.y;
    }
};

プレイヤーを追いかけたい場合は$gamePlayerではなく"player"と文字列を入れることにします。

Game_CharacterBase.prototype.clearTarget = function() {
    this._target = null;
    this._targetX = null;
    this._targetY = null;
};

さらにターゲット関連の変数を初期化する関数もつくり……

const _Game_CharacterBase_updateStop = Game_CharacterBase.prototype.updateStop;
Game_CharacterBase.prototype.updateStop = function() {
    _Game_CharacterBase_updateStop.call(this);
    if (this._target) {
        this.setTargetXy();
    }
    if (this._targetX != null) {
        direction = this.findDirectionTo(this._targetX, this._targetY);
        if (direction > 0){
            this.moveStraight(direction);
        }
    }
};

updateStopという関数にエイリアスで書き加えることで経路探索で追いかける処理をつくります。
findDirectionToという関数がそれです。
それなりに精度の高い経路探索ですので、殺人ピエロが追いかけてくるみたいな動作にも使えます。

さて、準備ができましたのでフォロワーに動きを組み込みましょう。
そうですね、3タイル以上離れたら追いかけフラグが立つ仕様にしましょう。
新たにchasePlayerという関数を用意します。

Game_Follower.prototype.updateAction = function() {
    if(this._waitCount > 0){
        this._waitCount--;
        return;
    }
    this.chasePlayer();
};

Game_Follower.prototype.chasePlayer = function() {
    // ついていく
    if(this._follow && this._waitCount <= 0){  
        this.setTarget('player');
    }
    // 一定以上離れた
    if(!this._follow && this.distance($gamePlayer) > 3){
        this._follow = true;
        this._waitCount = 60;
    }
};

距離を測るためのdistanceという関数も独自定義のものです。
以下のように書きます。

Game_CharacterBase.prototype.distance = function(target) {
    const sx = this.deltaXFrom(target.x);
    const sy = this.deltaYFrom(target.y);
    const ax = Math.abs(sx);
    const ay = Math.abs(sy);
    return Math.sqrt(ax**2 + ay**2);;
};


ついてくるようになりました。モテモテですね。

さて、これをもう少し改良して離れすぎるとダッシュで近づいてきたり、暇なときはブラブラしたりする動きを加えてみましょう。

Game_Follower.prototype.chasePlayer = function() {
    // ついていく
    if(this._follow && this._waitCount <= 0){  
        this.setTarget('player');
    }
    // 暇
    if(!this._follow && this.distance($gamePlayer) > 1){
        this.moveRandom();
        this._dashing = false;
        this._waitCount = 60;
    }
    // 一定以上離れた
    if(!this._follow && this.distance($gamePlayer) > 3){
        this._follow = true;
        this._waitCount = 60;
    }
    if(this.distance($gamePlayer) > 6){
        this._follow = true;
        this._dashing = true;
        this._waitCount = 0;
    }
    // 隣接
    if(this.distance($gamePlayer) <= 1){
        this._follow = false;
        this._dashing = false;
        this._waitCount = 60;
        this.clearTarget();
    }
};

ちょっと長い関数になってしまいました。
また、ダッシュしてるかどうかを示す関数の定義も行います。

Game_Follower.prototype.isDashing = function() {
    return this._dashing && !$gameMap.isEventRunning() && !$gameMap.isDashDisabled();
};

this._dashingはそのままダッシュさせたいときにtureにする変数です。
あとはイベント中はダッシュしないダッシュ禁止マップではダッシュしないと書いてあります。
どういう動きになるでしょうか。


わんこみたいで可愛いですね。


・一応用意しておきたい、緊急ワープ

馬鹿な!? さすがにもう完成なのでは……

ほとんど問題ないといえばないのですが、経路探索も完璧ではありません。
あまりに入り組んでいると、どうしてもプレイヤーの場所まで辿り着けない場合も出てきます。


このように極端に複雑なマップだと経路探索も振り切れてしまいます。
こうなってしまうと、話しかけたい仲間がそばにいなくて面倒ですよね。
よって、緊急ワープを実装します。

と、コードを引用しようと思ったら長い長い……。
urgencyWarpという関数がそうなのですが、えっと、最後にプラグインを配布しますのでそこで確認ください。

簡単に紹介しますと、プレイヤーの周囲8座標を調べて通行可能かどうかを判定し、可能ならその場所に飛ぶ、というものです。
通行可能かどうかの判定というのは、たとえば「壁の中にいる」を防止するための措置です。

考え方としましては、あまりに長い間プレイヤーのもとに辿り着けないとurgencyWarpが発動する、というものです。


これでいつまでもいっしょだね。

・そしてどこでもパイズリへ――


以上の処理が完成すれば、あとはコモンイベントの内容をあれこれするだけでこうなります。
改めて一から紹介してみると結構めんどくさいことしてますね。

さらには、このシステムからどこでもパイズリに至るには――
現在位置の情報からふさわしいパイズリを判定したり、会話内容を状況に応じて変えたりと、他にもいろいろあります。

IndependentFollower.js (15.61kB)

ダウンロード

というわけで、今回の内容をまとめてプラグイン化したものがこちらです。
これを配布してくれるならこれまでの講義はいったい?! という感はありますが、実際に使おうとした場合はいくらか手直ししたくなる部分が出てくるかと思います。
そのためのリファレンス代わりとしてこの記事はご利用ください。
本プラグインを導入される場合にはツクールMZの公式プラグインPluginCommonBasePluginBaseFunctionが必要です。

また、記事内容と異なる点としてはトークイベントの指定法をより汎用性の高いものにしています。


このようにメモ欄に記述します。

さて、これで技術的な準備は整いました。
どこでもパイズリシステムはもう目前です。さあ、歩み出しましょう。

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

饗庭淵/喘葉の森 2021/10/26 19:49

RPGツクールでエロゲーをつくろう


RPGツクールではエロゲーもつくーるできます。そして販売もできます。
基本はふつうのRPGをつくるのと同じなのですが、なかにはエロゲーならではの表現、ちょっとめんどくさいことなどもあります。
今回の記事ではそのへんを触れていきます。

ちなみに使用ツールは最新の「RPGツクールMZ」とします。
また、わりとツクールに慣れてる人向けの記事になります。

・テキストを取り込もう

エロゲーにはかぎらないですが、エロゲーではエロシーンにおいて大量のテキストを処理する必要が出てくると思います。
通常RPGツクールではイベントコマンドの「文章の表示」を使ってゲーム内にテキストを表示させます。
ただ、2000字とか3000字とか、それなりに分量のあるテキストはメモ帳などの外部テキストエディタを使ってあらかじめ執筆しておくのが普通かと思います。

さて、それをツクールに取り込むとき……
一つのメッセージで最大4行、空の文章表示を無限にコピペして、スペースキーで編集を開いて、テキストエディタから一つずつコピペして……
少量であればなんとかなりますが、大量になると次第に吐き気を催してきます。

その作業を格段に楽にしてくれるのが「メッセージ組み込み開発支援プラグイン」Text2Frameです。
メモ帳に一定の規則で記述しておけば一気にツクール内に取り込んでくれる便利なプラグインです。
詳しい使い方は……リンク先を見ましょう!



・効果音を探そう

エロゲーといえば……重要なのは効果音! たとえば射精音です。
え? 射精の……音……??
演出です。演出として射精音はなければ締まりません。
デフォ素材のWaterあたりでごまかそうとしてはいけません。
たとえ絵がエッチでも音がそんなのでは興醒めしてしまいます。

さて、そのようなえっちな音素材はどこにあるのでしょう。
えっちなものは……だいたいDLsiteにあります

著作権フリー効果音・BGM集 vol.25 射精音・ピストン・手コキ・ぶっかけ効果音108個+BGM10曲パック

私が愛用しているのはこちらです。
射精音はもちろん、ピストン音手コキっぽい音まで揃っています。

著作権フリー効果音・BGM集 vol.7Hシーン用効果音117個+BGM10曲パック

あるいは同じサークルですがこちらですね。

え? お高い?
音にお金を惜しむべきではありません。
ましてやエロ同人ゲームとして販売するつもりならすぐ回収はできます……それだけの価値はあります……。

もちろん、こちらのサークル以外にも様々なエッチ効果音がDLsiteには販売されています。サンプルなどを聴き比べあなた好みの音を見つけましょう。



・台詞にハートマークをつけてみよう

エロ作品なら……語尾にハートマークはつけてみたいですよね❤
と、「❤」を使ってもよいのですが、これは環境依存文字です。
それに、せっかくなら赤いハートマークを使ってみたくありませんか?
文字色変更で赤くしようとするとこうなります。


毎回この表記はめんどくさいですよね。
文章の長さ(ウインドウ内に収まるかどうか)がパッと見わかりづらくなる問題もあります。

そういうわけで、私が提案する手法はアイコン表示です。


アイコン表示なら記述も短く済み、環境依存でもありません。
上の場合ではアイコンセットの1番にハートマークを置いて、以下のように表示されます。


これであらゆる台詞にハートマークを撒き放題です。

・差分を管理しよう

エロシーンをつくる際には、基本的に「ピクチャの表示」を利用することになると思います。
それ自体はむずかしくありません。
えっちな絵を表示させて、えっちな文章を表示させて、えっちな効果音を鳴らして、それでえっちなシーンが完成です。

ただ、一つのゲームにつき少なくとも10シーン、えっちな絵が10枚ほどあるとします。
それぞれえっちな絵には表情差分があり、射精差分などもあるでしょう。
どんどん枚数が膨れ上がってわけのわからないことになっていく恐れがあります。
めんどくさいのもそうですが、めんどくささはミスを誘発しかねません。

そういうわけで、ツクールMZでは待望の「サブフォルダ」対応がなされました。つまりフォルダの下にフォルダを置けます。


「pictures」フォルダの下に「expressions(表情)」フォルダや「diffs(差分)」フォルダを用意しておけば混乱は大幅に回避できるはずです。


(私の場合はちょっと小細工を弄して「img」フォルダ直下に両フォルダを置いてたりしますが)

ここからさらに突っ込んで、処理を自動化できる部分は自動化してしまうともっと楽になります。
表情については、「ここではいたずらっぽい笑み」「ここでは困ってる顔」……と状況に応じて手動で指定するほかありませんが、たとえば射精差分は「射精した後の画像になる」ことは決まり切っています。

つまり、命名規則を定めていれば、わざわざ手動で射精後の画像を選ばずとも、自動的に射精後の画像を表示させることができるはずです。

Game_Screen.prototype.showSemen = function(noWait) {
	const max = 5;
	const count = Math.min($gamePaizuri.ejaculate(), max);
	const name = this.namePicture(p_base, true) + '_s' + count;
	const pictureId = p_base + count + 1;
	const opacity = noWait ? 255 : 0;
	this.showPicture(pictureId, name, 0, 0, 0, 100, 100, opacity, 0);
	this.movePicture(pictureId, 0, 0, 0, 100, 100, 255, 0, 30, 2);
};

これを私はこのように書いています。
「p_base」や「p_inside」は即時関数内で提示しているconstです。ピクチャーIDを指定しています。
あと「namePictre」という関数もデフォにはありませんので書いてます。
「$gamePaizuri」というのも独自に定義したクラスです。射精回数などを管理してます。

さて、これだけ見てもなんのこっちゃと思うかもですが……


命名規則としては、たとえば「P_Tate_s2」という画像を例に挙げますと

P_(パイズリ画像であることを示す。ソート用の命名規則)
Tate(縦パイズリの画像であることを示す)
_s(射精後差分であることを示す)
2(射精回数を示す)

となっています。


ちなみに基本となる画像は「P_Tate」と装飾のないファイル名になっており、この画像の名前をもとに差分画像を表示させます。

私の例をもとに処理の流れを書き出します。
・P_Tate(基本画像)をp_base(20番)に表示

・p_expression(30番)に表情差分を表示(手動)

・射精処理が行われた場合、射精回数に応じて射精差分をp_baseより上(21番)に表示(p_baseのファイル名を取得し、その文字列に「_s」と射精回数の数字を加算し、射精差分のファイル名を指定する)

なんかそんな感じです。
ちなみに、同じように命名規則を工夫することで挿乳差分を扱うことも可能です。なにそれ?


つまりこんな画像です。
「基本名」「#」をつけることで表現しています。
_s0というのは射精回数が0回だからです。つまり扱いとしては射精差分と同じです。


そして挿乳差分にもそれぞれ射精差分があります。ややこしいですね。
ただ、処理を自動化してしまえばめんどうなのは画像を用意する作業だけになります。


こうした作業で具体的にどのような仕上がりになっているかは上の動画などをご覧ください。
体験版でもいいですし、いっそのこと本作を購入なさっても構いません



・回想モードをつくろう

エロゲーといえば……回想モードは必須

そしてツクールゲーの回想モードといえば……


なんかこんなん(概念)です。
まあ、UIとしては使えなくはないのでこの形式でひとまず問題はありません。

問題となるのはフラグ管理です。
いっそ開き直って最初から全開放、という形式なら問題ありませんが、基本的には一度でも見たら次からは何度でも見られる、という形式が一般的です。
しかし、たとえば敗北エロであればゲームオーバーになってしまいます。セーブデータには残りません。どうすればよいでしょう?

こういったプラグインを利用するとたとえゲームオーバーになったとしても「そのエロシーンを見た」というフラグは共有セーブデータに残すことができます。

あとは、本編からでも回想モードからでも再生しやすいようエロシーンはコモンイベントで組んでおくとよいでしょう。


ちなみに私の作品ではこういうUIを組んでいます。
これと同じものを実装するにはSceneクラスのあれこれの知識が必要になるわけですが……これを書こうとしたらかなり長くなりますのでまた機会がありましたら……(あるのかな……)

ちなみに、RPGツクールにおいてSceneクラスに手を出し始めると「これもうツクールじゃなくてよくね?」みたいな領域に足を踏み入れることになります。
いや、なんだかんだツクールの機能にはお世話になってるんや……!

この記事が良かったらチップを贈って支援しましょう!

チップを贈るにはユーザー登録が必要です。チップについてはこちら

1 2 3 4 5 6

記事のタグから探す

月別アーカイブ

限定特典から探す

記事を検索