議論/過去ログ01

Last-modified: 2025-10-20 (月) 00:10:17

エフェクト展示室(MAP0179)を共有部屋として扱う提案

窯良 (2025-08-10 (日) 10:11:02)

ゆめ2っきフォーラム/12
題名の通りで、システム的な要素の強い場所であり円滑な開発のために共有部屋として宣言しておくことを提案します。
いかがでしょうか。

しばらく議論ページで確認して、さしたる反対意見がなければ共有部屋として将来宣言しようと思います。


  • エフェクト展示室が共有部屋でないことで円滑な開発を妨げられた経験が無いので、この提案はあまりピンときていません。システム的な要素の強い場所…といってもエンディングのいくつかに関わってるだけで、エンディングというのも個人が作ったイベントに過ぎないものだと感じてます。反対したいわけではないですが、もう少し理由や必要性を説明して、MAP0179のケースが特別だと分かると良いんじゃないかなと思いました。 -- qxy 2025-08-10 (日) 11:37:25
  • 下記のような理由を考えています。
    ・MAP0179はぴぬ氏のマップだが、ぴぬ氏は取得したエフェクトのフィギュアが置かれる場所として初期にマップデータを作成しているのみであり、編集の実態として、エフェクトを捨てたり再取得したりできる現在の仕様はその他のツクラー10人程度で追加されていった経緯があった。加筆の体制としてはデバッグルームやうろつき邸のような共有部屋にそもそも近く、2010~2013年ごろの合意状況は不明瞭ながら、共有部屋という認識でツクラーたちが編集していた可能性がある。扉部屋⇔エフェクト展示室のアクセス追加についても、同様の論理でオブジェが置かれた可能性がある。
    ・作中で唯一エフェクトを捨てられるマップで、エフェクトアイテムの管理に直接関係している。エフェクトを捨てるという動作は、ゆめにっき派生のゲームシステムとして基本的な機能の一つだと認識していた。基本的な機能を扱う場所として、現実部屋や夢部屋が共有部屋扱いであるなら、エフェクト展示室が共有部屋扱いになっても違和感がないし、強く反対する理由はないはずだと考えていた。
     個人の割り当てのままでも半年ルール適用下に編集可能なので将来的に支障をきたすおそれはとても低いが、システム保全の観点と、編集の歴史を鑑みても、エフェクト展示室が明確に共有部屋割り当てになったほうが無難と考えている。 -- 窯良 2025-08-10 (日) 14:23:08
  • ありがとうございました。MAP0179のケースが特別だと分かりました。 -- qxy 2025-08-10 (日) 14:32:30
  • 21部屋目 >>668, >>681で確認して、同MAPを共有部屋に追加しました。 -- 窯良 2025-09-12 (金) 18:51:32

夢の世界で使用可能なRTP素材の範囲を定める提案

窯良 (2025-05-14 (水) 10:40:40)

忙しなくいろいろ話題を持ち込んですみません。
ゆめ2っきフォーラム/30を受けて、夢の世界で使用可能なRTP素材の範囲を定める提案をします。

提案としては、夢の世界に使用できるRTP素材のカテゴリを以下の4種類に絞ることを考えています。
ゲーム内で過去によく使われているカテゴリに絞って提案しています。

  • Battle(戦闘アニメ)
  • Panorama(遠景)
  • Sound(効果音)
  • System(システムグラフィック)

RPGツクールシリーズのうち、2000以外のRTP素材を持ち込む場合も、上記4種類に相当するものに絞るのがいいんじゃないかなと思います。

RTP素材の用法を定めるなら、ルールに基づいて遡及的に過去のマップデータも修正が必要とすることを考慮してます。

いかがでしょうか。


  • 良いと思います!個人的には、RTPに限らず、フリー素材についても同様の制限をかけた方がよいかと思います。理由としては、「RTPではないから」としてフリーゲーム向けのチップ素材を使われる可能性が0とは言えないからです(↑v↑に使われているような素材サイト由来のもの等)。BGMに関しても、RTPは雨や波の音といった環境音に留めてほしい気持ちもありますが、区分けが難しくなりそうなので今は置いておきます。 -- spelude 2025-05-14 (水) 11:17:57
    • うーん、フリー素材を使う場合はたいてい自分のアセットに取り込んで再配置する段階で多少改変が入ると思いますし、チップセットに関してはわかりませんが、背景や大きめの画像テクスチャにフリー素材が使われた例は過去多くあるので、それを制限すべきとはあまり思っていません。自分もFaraway Landsマップで、16x16マップチップ素材を購入して使いましたが、ある程度改変して使っています。
      ツクラー本人の意図や意匠が乗らない、RTPそのままのチップセットやキャラセットの使用は夢の世界の中ではちぐはぐになってしまうのかなと思って、今日はそこに絞って提案をしてみました。 -- 窯良 2025-05-14 (水) 12:01:59
    • 今回の議論でもしFaraway Landsのような外部チップセット素材を利用した例も良くないという結論になるのであれば、自分は本マップのチップ・キャラセットは全部描き直すつもりです(それは可能です) -- 窯良 2025-05-14 (水) 12:17:38
    • なるほど。部分使用されているケースがあるのは知らなかったので、やや極端すぎましたね。私としては丸々使われる事を危惧していたので、部分使用でもぱっと見て分からないレベルなら大丈夫じゃないかな、と思います。上の発言はなかったことにしてください。 -- spelude 2025-05-14 (水) 12:28:15
  • もしも以下の議論のルールが実際に適用されることになった場合、自マップ「混沌の坩堝」(MAPID2047)のEV0050に関して、イベントの一環としてデフォルトのBGMを使っているため修正の対象となる可能性があります。もしも修正が必要な場合はイベントを変更したいと思います。ここからは個人的な意見になります。自分のマップの解説みたいになってしまい申し訳ないのですが、混沌の坩堝にのコンセプトの一つに関して、ツクールの仕組みを2っきのプレイヤーに知って少しでも制作に興味を持ってほしいという思いと、自マップ(^□^) (MAPID1988)の要素を追加した空間を作りたいと思い作成しました。また、今まで使われていないような音楽を流すことで、奇怪な演出の一つになるのではないかと思いデフォルトの音楽を使いました。そのような経緯から個人的には、自身・2っきの素材提供者のデザインや音楽といった制作物を主としてRTP素材が従になるような使い方(制作物99.9%、RTP素材0.1%位)でなおかつ自マップの制作物を引き立てるために素材を利用したと判断した場合は他のツクラーとの相談を必須として使ってもいいのではないかと思います。 -- 21keb 2025-05-14 (水) 18:48:40
    • ご返信ありがとうございます、もちろんツクラー間で相談して柔軟に例外を作るということは可能だと思います。制作の基本的方針として、チップ・キャラ・音楽のRTP素材を夢の世界の体験根幹を左右するような形で使ってしまうことを避けたほうがよいと思って今回の提案をしました。本当にチョイ役として程度の登場なら問題ないと思います。
      ただ、混沌の坩堝はBGMのほか、特殊なランダムイベントやメッセージ表示など含め、夢派生で一般的ではないこうした演出・素材が似合ってマップの魅力として生きている非常に稀有な例だと思います。相談のうえで使うことができるかもという立ち位置にRTP素材のチップ・キャラ・音楽が入ることとなっても、活用するための難易度はけっこう高そうです(なので結局使用頻度はごく低いままで推移したら良いと思います)。 -- 窯良 2025-05-14 (水) 19:17:57
    • ご連絡ありがとうございます。柔軟な例外対応があるということで安心しました。粗製乱造に近いマップが増えることの防止策としてRTPの制限を設けることに関して、これ以上の意見はありません。 -- 21keb 2025-05-14 (水) 21:11:27
  • 言わんとしている所が分からないわけではないのですが、どこか賛同しづらい気持ちがあります。
    もちろん、創意性の薄い……極端な例で言えばRPGツクールMVのサンプルマップデータそのまま、というものが大量に実装されることを恐れる気持ちが分からないわけではありません。(方向性はあれどヒトの"味"が注目されるものではあるでしょうし)ただ、ここで否門松氏ほったらかしで進めていいのかな?ここで挙げられている内容が"効果的なガードレール"になるのかな?……という疑問があります。
    何より、"この件でみなさんが伝えたいことを伝える方法"は"使用可能なものを絞るという方法"しかないの?というのが傍目に見ていて浮かんだ疑問でした。 - kuraud -- 2025-05-14 (水) 21:02:57
    • kuraudさんはどうすれば「効果的なガードレール」にできると考えていますか?
      ガードレールは車が道から外れないように止める働きもありますが、歩行者に安心感を与えるものでもあると思いますよ。
      ルールの逸脱がなくても、制作者やプレイヤーが安心した制作環境を得られるのであれば、ルールの役割を立派に果たすものだと思います。

      "使用可能なものを絞るという方法"は皆さんが伝えたいことを伝える方法では無いと思います。
      フォーラムや議論ページなど、問題点の指摘やルール生成の過程での話し合いこそが、伝えたいことを伝える一番の方法ではないでしょうか。 -- qxy 2025-05-14 (水) 22:20:22

    • ……言いづらいんですが、あったら書いてます……。RTP素材そのものに焦点を当てても、結局は(例えばFSMのサンプルマップなどをそのまま使う例が出れば)アセットフリップだなんだとまた似たようなことになるんじゃないんでしょうか?かといってあちこちの素材利用を制限していくのは何か話が違いませんか?……辺りのことを思っているのですが、それだけでは私の考えが足らず建設的な形にまでは達してないんですよね……。
      かなりふわっとした所にはなりますが、アセットフリップが疑われるものをどう対処するか(そう見えるか差し戻すか違う対応をするかを毎回議論するのかもしくは何らかのボーダーを設けるのかetc)というルールを考えた方が良いんじゃないかと思っています。 - kuraud -- 2025-05-14 (水) 23:04:12
    • kuraudさんの不安に感じているポイントは理解できました。この草案は完璧ではないかもしれませんが、このまま何もしないのもどうなのかと考えてしまいます。そういう観点から私にはこの草案に反対する理由がありません。何かもっと良い方法が無いか私も引き続き考えていきたいなと思います。 -- qxy 2025-05-14 (水) 23:23:52
    • あーっ……色々紛らわしくて申し訳ないです…。賛同しづらい(から反対です)というわけではなくて、(反対ではないけど…でも)賛同しづらい、辺りのニュアンスでした。意見ふわふわすぎてすみません。 - kuraud -- 2025-05-15 (木) 01:09:24
  • 簡潔なルールにできないかもしれませんが、RTPのMusic素材のうち下記の5点(環境音のwavファイル)は利用可能としても良さそうかなと思いました。
    ・SE雨
    ・SE海
    ・SE時計
    ・SE大雨
    ・SE地震 -- qxy 2025-05-14 (水) 22:22:58
  • 上記kuraud氏の悩みは私も感じています。自分の提案は素材利用を絞ることが直接の動機ではないのだと思います。
    ゆめ2っきフォーラム/30でも何度か触れられたように、つくり手の作風やこだわりよりも(有名な)素材利用がマップに及ぼす影響が今回はるかに巨大であって、マップを訪れたときにオリジナリティやゆめ2っきらしさが感じづらくなってしまったことがおそらく今回の問題提起(と元フォーラム)の懸念事項だったと思います。
    RTP素材の利用を制限するほかに、「マップの大部分が自作でない素材で構成されるときは、ツクラー個人が表現に工夫やこだわりを持ち、マップがオリジナルの魅力を持つよう努めること」という指針をルールのどこかに含めてもいいのかなと思いました。
    全部のマップ投稿を事前に審査したり、具体的なボーダーを設定したりするのは現実的でないと思っています。上記文に精神性がひっかかりそうなマップが追加されたときに、対応を逐一協議する形になってしまうのかなとは感じます。 -- 窯良 2025-05-15 (木) 00:20:32
    • あいまいな投稿が来たときに対応を逐一協議することについては、たしかに労力がかかりますが、その時にアクティブな開発者間で議論や着地点の模索を行うことで制作の大意を再確認することができる効果もあると思います。制作者たちが積極的に話し合いをもちながら、制作が柔軟に進んでいけたらいいなと思っています。 -- 窯良 2025-05-15 (木) 00:31:00
  • フォーラムを見ていると(書き込むみなさんの労力はともかく)以前よりそういった協議がしやすくなっているような印象があります。
    私自身今回のような件はレアケースではないかと思っているのと、件の世界をこのまま置いておくのは好ましくないという認識はゆめ2っきフォーラム/30]でもたびたび言われているので、指標を置いてみるだけでも違うのかもしれないと思います。(その場合に件の世界どうなるの?という疑問が残るのはなんとも言えない所ですが…) - kuraud -- 2025-05-20 (火) 21:04:22
    • お疲れ様です。先の文のような感じで、指針(指標)を置くのは良いと今日でも思っています。
      RTP素材を制限する提案をしましたが、RTPに類似した素材やモチーフはspeludeさんkuraudさんが指摘する通り、ほかにもありますので、RTPだけ絞ったところで実際に目指したいルール/指針の効果からはすこしぼやけた対策になってしまうのかなとは心配してました。
      とりあえず、指針「マップの大部分が自作でない素材で構成されるときは、ツクラー個人が表現に工夫やこだわりを持ち、マップがオリジナルの魅力を持つよう努めること」というような内容は共有方針として考えていったほうがいいんじゃないかなと私は考えています。そして、くだんのマップについてですが、否門松さんが2っきの話題に触れない姿勢をとっているようなので、半年の間に氏が戻ってくるなら方針を直接相談することとして、もし半年ルールの対象となったら申し訳ないんですけどそのときに再編集の方針をアクティブな開発者の間で協議して決めるのがいいのかなと思います。
      根っこの問題を先送りにしている感はありますが、まずは作者が戻ってくる・こないが分からないと動きづらいのが正直なところかなと思ってます。 -- 窯良 2025-05-20 (火) 21:49:43

提案の仕切り直し、「お約束素材の用法の指針」をツクール編集ルールに追加する提案

窯良 (2025-06-21 (土) 11:35:01)

お疲れ様です。上記の提案が1ヶ月ほど寝てしまったので提案内容を整理して仕切り直しをします。
ツクール編集ルールの ◆詳細 の末尾に、「お約束素材の用法の指針」を追加することを提案します。
方針が整ったら、R4Rで確認しようかなと思います。

[ここから]

  • お約束素材の用法の指針
    • 編集内容の大半が自作でないフリー素材や定番の素材(RTP素材など)で構成されるときは、
      ツクラー個人が工夫やこだわりを持ち、内容がオリジナルの魅力を持つよう努めましょう。
    • 夢の世界でのRTP素材の利用は以下の範囲内にします。
      • Battle(戦闘アニメ)
      • Panorama(遠景)
      • Sound(効果音)
      • System(システムグラフィック)
      • Music(音楽)は環境音5種類のみ SE雨, SE海, SE時計, SE大雨, SE地震

[ここまで]

  • 補足:
    初期の提案であった2文について
    「RPGツクールシリーズのうち、2000以外のRTP素材を持ち込む場合も、上記4種類に相当するものに絞るのがいいんじゃないかなと思います。」
    →指針1行目があるので、これを明示するほどでもないなと思って記載をやめました。
    「RTP素材の用法を定めるなら、ルールに基づいて遡及的に過去のマップデータも修正が必要とすることを考慮してます。」
    →既存のマップを修正・編集するための道具としてルールを使ってほしいわけじゃなくて、これからの2っきの開発がオリジナリティを目指す姿勢を維持することへの安心感として作用してほしいので、遡及について第一に書くすることはやめました。 -- 窯良 2025-06-21 (土) 11:43:49
  • 特にコメントなければ7月上旬にR4Rにのせます。 -- 窯良 2025-06-27 (金) 13:55:16
  • RTPのチップ素材だけど色変えたからオリジナル!っていうのはこのルールで対応できるのかな? -- 2025-07-06 (日) 12:40:41
    • 元の素材(著作物)の色や形状をいくつか変えただけのものをオリジナルと主張はできないよというのは一般常識の範疇かなと思っていたのですが、そこまで明文化してカバーしないといけないでしょうか…?一応、1文目の内容でそれも包含できているんじゃないかなと私は思ってます。 -- 窯良 2025-07-08 (火) 13:53:22
    • "夢の世界でのRTP素材の利用は以下の範囲内に"の部分があるので、少なくともその点はカバーできるものだと私は思いました。
      ("努めましょう"の指針なわけだし、"このルールで対応"というのとはちょっと違いそう…という気もしてます) - kuraud -- 2025-07-08 (火) 18:04:18
  • RTPのBGMをアレンジしたものを更に低速加工したり切り貼りして別の曲っぽくして使うというのはアウトでしょうか?元曲からあまり変わってないようなの(ローテンポにしただけとか)はやめたほうがいいですかね…? -- †Nightmare† 2025-07-08 (火) 22:57:16
  • ゲームのバグやデバッグルームをテーマにした世界だとか、ツクールゲーやRPGのお決まりに対するメタ的な演出としてはアリだと思います。ただ、この議論のきっかけになったRTPの世界のように、「RTP素材を活かしながらオリジナリティを出す」というのは感覚的なところがありなかなか難しい問題ですよね…
    はじめて聞いたときは気づかなかったけど、よく聞いたらあの曲がベースになってる?くらいに改変されていたら使ってもいいんじゃないかなーと思ったり -- 2025-07-12 (土) 18:50:49
  • ちゃんとオリジナリティが担保されていれば大丈夫だと思うな、傍から提案を見てる感じだと、抵触した瞬間にOUT~~~!!とか言うためのルールってわけじゃないと思うし。ルールの発端になった件の時みたいに「これはさすがに...オリジナリティがあるか...?」みたいな空気が漂った時に、誰かのお気持ちで対処させるとかじゃなく、ルールとしてダメだよね?って言えるようにするためのルールだと思うな。でも、フリー素材に関してもルールの範囲内とはいえ、どんな改変もOKでRTPっぽい、RPGっぽい雰囲気のフリー素材・BGM素材も探せばあると思う。結局改変するならフリー素材じゃなくてわざわざRTP素材を使うのは、どんな人にもウケるようなよっぽど上手いメタ演出でもない限りはルールに触れてしまうリスクが高くなるだけかなとは思うよ。 -- 2025-07-13 (日) 10:09:01
  • RTPのBGMでできる表現は、ほかのロダ素材やRPG風の既製素材を使いながらでも同じような味は出せるのではないかなと思います。RTP素材がプレイヤーから常に見える・聞こえる位置で使われていると、ゆめ2っきを遊んでいるというより、この素材は別のゲームでも見たなあという感想のほうが前面に出てくるおそれがあって、それが没入感を損なったり、2っきの開発体制の舞台裏が見えてしまったような不安感を助長してしまったりすることがあると思います。
    安直にRTPに頼ったと思われないような、RTPでなければならない確固たる理由があるならRTPのBGM素材を使うことにも私は納得できるかもしれませんが… 夢として現れる景色に使うものがRTPでなければならない理由って何というのは私はちょっと思いつかないです。
    それってRTP素材じゃなくてもいいよねという部分を、ちゃんと個人的に準備した素材で構築していくことが、このゲームの景色に多様性と魅力を生む大事な要素なんじゃないかなと思います。 -- 窯良 2025-07-13 (日) 11:10:37
  • ご意見ありがとうございます。私の考えとしては、ツクールそのもののパロディを含むマップのBGMとして、RTP曲のアレンジを更にvaporwaveのように何度も加工して別の曲のようにしたものを使いイースターエッグとして楽しんでもらう…というようなケースを想定していました。しかしそのような仕掛けは必須ではありませんし、RTPの利用にはリスクが何かと多いのでやめておこうと思います。 -- †Nightmare† 2025-07-13 (日) 19:55:08
  • R4R承認を経たため、過去ログに下げておきます。 -- 窯良 2025-08-10 (日) 08:35:37

予約ルール 第2版 の提案

窯良 (2025-05-11 (日) 11:33:27)

新しい割り当てを、予約中のまま放棄された未使用領域から捻出するためのルールが存在しなかったため、予約ルールの改訂を提案しました。
現在、スイッチの捻出可能領域が無くなったため、捻出に関しては方針の確定が必要です。

改訂は議論ページで内容を整えてから、R4Rに持ち込みます。


2025/05/11 17:47 改訂

◆概要
(予約の方法)
1-a.
マップ、チップセット通行設定、スイッチ、変数の割り当ては、本スレあるいは避難所で宣言して予約する。
予約の際は、予約者名、領域の種類、割り当て範囲を明記する。
1-b.
マップ、チップセット通行設定、スイッチ、変数の割り当ては、10個ずつの区切りで予約する。

(予約の取り消し)
2-a.
過去に予約された割り当てが、完全に未使用であり、予約から1年以内に使用・更新・報告がない場合、予約者に使用状況を確認する。
確認から1週間以内に使用あるいは予約継続の希望がない場合、予約領域を取り消す。
予約が取り消された領域は、誰でも予約できる状態に戻る。
2-b.
予約の継続は、同じ割り当て領域のまま予約日を継続の希望があった日に更新する形で行う。
2-c.
過去のスイッチ・変数の割り当ては、10個ずつの区切りに分けて予約状況を管理する。
予約の取り消しは、10個ずつの区切りで行う。

(代理実装の予約)
3-a.
代理実装のための割り当て予約が必要な場合、代理実装担当者が予約を行う。
3-b.
代理実装の担当が別のツクラーに移る場合、そのツクラーが割り当て予約を引き継ぐ。

(その他の領域の予約)
4-a.
戦闘アニメID、地形ID、コモンイベントID、変身No.、自販機商品IDの予約が必要な場合、
実際の利用より先に、ゲームの更新内容にダミーデータを含めることで疑似的に予約する。
4-b.
予約に使うダミーデータは、名前に予約者名と予約日時を含める。
予約を行った場合、changelogに記載する。
4-c.
予約の取り消しは、2-a.と同様とする。

◆詳細
新しい割り当てを、予約中のまま放棄された未使用領域から捻出するためのルールが存在しなかったため、予約ルールの改訂を提案しました。
また、割り当て予約について明文化したルールがなかったため、追記しました。

予約ルールの第1版と異なる点:
1. 割り当て予約の方法を明記し、本スレだけでなく避難所でも予約可能とした
2. スイッチ、変数の割り当てを10個区切りとした(持続可能性のため)
3. 予約の取り消しまでの期間を、予約から確認まで半年、確認から取り消しまで半年と、のべ半年分延長した 改訂で、確認まで1年、確認から取り消しまで1週間とした
4. 代理実装の予約、その他の領域の予約について明記した


#ルールの草案に含めなかった内容
・10個中1,2個だけ使用あるいは記名のみして、残り未使用のままの隙いた予約領域をどうするか。整理をするか。
・スイッチや変数がこの方式で5000個使い切った場合、9999まで外部ツールで拡張するか。実施の手続をどうするか。
・赤い工事中看板への接続を予約したが、半年以上放置している場合、予約を解消するか。ルールが/誰が取り消すのか。
・到達判定記録に昔使われていて現行処理に移行さえすれば開けられる領域や、一部MAPで初期化処理の対象に入っているが実際には活用されず何も格納されていない領域など、そのあたりのスイッチ・変数からの捻出はどうするか。

#申し訳ないですが自分が少しキャパシティオーバー気味なので、修整・改善案をいただけるなら修正後のルールの文案もセットでいただけるととても助かります


  • 提出してから気づきましたが、到達判定記録に昔使われていて現行処理に移行さえすれば開けられるスイッチ・変数だったり、初期化処理の対象にだけなっているけど実際には使われていないスイッチ・変数だったり、そのあたりの領域から捻出することについてこの改訂案だとまだカバーできてないですね。どうにかしたいです。 -- 窯良 2025-05-11 (日) 11:37:19
  • 良い感じだと思います。ルール草案に含めなかった内容や現行処理に移行さえすれば開けられるスイッチ・変数に関しては、時間のある時や将来他の開発者にお任せしても大丈夫だと思います。個人的な好みを言うと、予約から半年って結構短いのかなという気がするので2年くらい待ってもいいんじゃないかなと思いました。あと、フォーラム29で話題になっていた約10年間更新がないツクラーさんの割り当ては、予約領域として扱い捻出可能とする方針なのかお聞きしたいです。 -- qxy 2025-05-11 (日) 13:42:54
    • ご確認いただきいつもありがとうございます。
      予約解消までの期間についてはけっこう悩んでて、確認→本解消まで半年&半年にするか、2年&1年にするか迷ってました。もとの予約ルールが半年基準だったのでとりあえず半年&半年で提案しましたが、他の人の意見も聞いて2年&1年も提案してみたいです(みなさんどうですか?教えて下さい!)。
      約10年間更新がないツクラーさんの割り当ては、2-a.案に従って解消とするのがよいかなと思いましたが、半年あるいは1年待機するのは難しいですよね。もう枠がないですし…。
      待機期間を設けずいきなり解消しちゃうか、データベースを6000番(適当な数字)まで拡張して姑息的に耐えるか、どちらかかなと思いますが、あんまり軽率に一人で提案するのもこわくて、困ってます。 -- 窯良 2025-05-11 (日) 13:47:36
    • 空き領域が足りないかどうかを見てある程度計画的にルール運用しないといけなくなるのはちょっと大変そうですね。
      予約継続の希望の確認期間を一週間に縮めてしまうのはどうでしょう。
      予約者に使用状況を確認するまでの期間はとりあえず半年と考えましたが、もうちょっと余裕をもって長くできれば確認期間を短くしても大丈夫そうな気はします。

      2-a.
      過去に予約された割り当てが、完全に未使用であり、予約から半年以内に使用・更新・報告がない場合、予約者に使用状況を確認する。
      確認から一週間以内に使用あるいは予約継続の希望がない場合、予約領域を取り消す。
      予約が取り消された領域は、誰でも予約できる状態に戻る。 -- qxy 2025-05-11 (日) 14:03:02

  • 予約を継続するなら、使用状況確認までの期間と同じ期間がまた予約に足されるという風になりますね。半年後に確認してまた半年足すでもいいのですが、確認しないといけない領域が結構多くて連絡だけで煩雑になりそうという心配があるので、1年で確認にしてもよさそうだと思います。
    さっき2年を提案してしまいましたが、2年後に継続されて軽率に4年間更新なしでホールドされうるのは厳しい気がしました。(なので1年+1週間以内確認がベストチョイスか?) -- 窯良 2025-05-11 (日) 14:12:59
    • 個人的にはそのくらいでちょうど良さそうだと思います。ゆめ2っきをこれからも開発可能なものにしていくためには、新規開発者と既存の開発者の利益のバランスをとっていく必要がありますから、改定案は良い案配にまとまったと思います。私が聞きたかったことは以上で(多分)終わりです。草案の作成お疲れさまでした。引き続きルール制定までフォローしていきたいなと思います。 -- qxy 2025-05-11 (日) 15:14:21
  • 上の議論をふまえて内容を改訂しました。
    2-cがあるからこのルールで過去の割り当て予約を管理してもよいということにしてしまっても大丈夫でしょうか。「このルールは過去すべての割り当て予約領域に対して効力を持つ」ということを明文化して含める必要があるかどうか気になりました(徹底しすぎ?) -- 窯良 2025-05-11 (日) 17:51:58
  • 改めて空きの調査や草案の作成等お疲れ様です。今までちょっと扱いに困ってた部分が2-bなどでカバーされてて良いなぁって思います。
    体感や想像がいくらか混ざるのですが、2-a内の「予約から1年以内に使用・更新・報告がない場合」の部分、"報告"だとあまり有効に機能していない(伝わりきっていない)感じがあるので、「予約から1年以内に使用・更新・予約継続の報告がない場合」とした方が結果的に呼びかけを行う回数が減りそうな予感がしてます。
    過去の割り当ても10個区切りで管理するとありますが、こうなると「~人目」という表記はいたずらにややこしいだけかも……。
    今はIDの範囲を直接言っている場面がかなり多いのでこの機に「~人目」という表記を表向き使わないようにするのも一つの手だと思います。(ばっさり消してしまうとか、&null{{}}で隠してしまうとか)
    2-cはハッキリ「過去の予約領域を管理」と言及しているので、これだけで過去の範囲に波及することは十分伝わると思います。 - kuraud -- 2025-05-11 (日) 20:30:01
    • そうですね、自発的に予約継続の報告をしてもらうのが自然ですね。更新する気がある人は基本的にスレに書き込んで進捗報告できると想像できますし…。
      「予約から1年以内に使用・更新・予約継続の報告がない場合」として、過去1年より前の予約領域に関してこの予約解消の話をルール発効後に持ち込む時は、ルール発効から2週間以内に予約継続の報告を行うこととするのはどうでしょうか。2週間というのは適当な期間で、1週間でもいいかも……
      「○人目」の呼び方を廃止してもいいかもしれませんが、現行の予約ルールまでで予約された領域と○人目の対応は、wikiのどこかにログとして残しておいたほうがよさそうですね。 -- 窯良 2025-05-12 (月) 00:40:24
  • 本スレ 21部屋目 >>496-499 でR4R発議しました。案の整備をお手伝いいただいたお二方、ありがとうございました。ここでの議論は終了とします。 -- 窯良 2025-05-13 (火) 19:51:50

AIを使った素材に関する個人的意見

黒九 (2025-05-01 (木) 20:29:51)

他所ではAIを使用せずに作った作品がAIで作ったと勘違いする事がときどきあるみたいです
その勘違いの対策としてAIを使った素材を出来るだけ取っておけたら良いのではないかと考えてます
個人的には流れが変わってAIで作った素材が使いやすくなる時があるかもしれないとも考えてます
その素材を取っておく為にろだを一応準備してます(上手く行くか不安)


  • 素材ろだ管理人としてなのですが、「消したいけど削除パスワード忘れたんでお願いします」はあったけど、私自身が「AIが生成したものは消す」という判断をしたことは無いです。なので現状ろだを用意してもそこまで活用されないかも……(素材作者さん自ら取り下げてーってしたのを保管することは素材の扱いとして反するものだろうし)。……リスキーな素材の一覧の表を、AI関係のもので絞りやすいように整えておくと勘違いだと分かった時に便利かも?とは思いました。 - kuraud -- 2025-05-01 (木) 21:17:03
  • 本人自身の…意思だったのか…とりあえずろだの準備は必要ではないかぁ… -- 黒九 2025-05-01 (木) 22:26:26
  • これ以上特に何も意見が無ければしばらくした後過去ログへ移動させようと思います -- 黒九 2025-05-03 (土) 18:09:37

扉部屋に設置するルールについて

710? (2024-10-11 (金) 20:59:41)

扉部屋に設置するルールを新たに定義したいと思っています。

まず協議することとして、今後扉部屋の設置は今まで通り許可なく無造作に増やして良いのか、
もしくは扉部屋への追加に対してルールや基準を設けて乱立を防ぐのかということについて議論したいです。

2024/10/17 以前の案

前者の場合は現状通りだとして、もし後者の場合は例えば以下の尺度を提案したいです。

・実装製作者様の引退や音信不通等により、該当世界及び関連世界の更新が見込めない世界。
・エフェクトが設置されておらず、エフェクトが設置されている世界との繋がりが現状無い世界。

これら二つの尺度を満たしている場合に扉部屋への設置を一製作者につき一つのみ認可するものとしたいです。
理由としては、扉部屋直下というゆめ2っきの玄関的立ち位置の世界において、一定の質を担保するためです。

そのため、これらが認可された場合は扉部屋の以下の世界を移動させることを検討しています。
・赤街灯の通路
(元々扉部屋ではなく繋ぎ部屋なため、及び釈迦世界と製作者が一緒なため)
・盾梟世界
(紫地世界と製作者が一緒なため)
・エフェクト展示室
(赤い世界と製作者が一緒なため)
・腐った世界
(エフェクトが無いため。21keb氏とは事前に連絡済み)
・クロック世界
(エフェクトが無いため。Myme氏とは事前に連絡済み)
・廃キャンプ場
(エフェクトが無いため)

また、これらの世界へのポータルをkappa氏製作のMAP0784に移動して準扉部屋のように取り扱いたいと考えています。
ちなみに、扉部屋に設置される場合は、必然的に繋ぎ部屋のように他製作者が更新できるような状態とすることが望ましいと考えます。


  • 読んだ限りでは「扉部屋から行ける世界群が風化しすぎない状態」「何らかのエフェクトが近くにある構成」を望ましく思ったことは伝わってきたのですが、710氏にとってのやりたいこと・こうなると嬉しい…という着地点がうまく汲みきれないことと、後者の仮定から伸ばしすぎていてなんだか後者で確定しているかのように感じてちょっと意見を挟みにくく感じます…。

    読んだ感想としては今のところ提案に乗れないです。
    赤街灯の通路は当初仮設置だった記憶なので移動させるのはアリだと思いますが、
    腐った世界、クロック世界、廃キャンプ場については「他の世界も最初からエフェクトへの道だっただろうか?」「強引にエフェクトを設置/追加することに繋がらないだろうか?」と思ってしまいます。
    (悪い考え方すれば"既にあるエフェクトの2つ目の取得場所になれば基準を満たす"という話になってしまう)

    確実に言えるのは、"エフェクト展示室"についてはエフェクトを捨てるという"本家の扉部屋の機能"を担っているので、ただただルール・基準だからという理由で遠ざけても誰も喜ばないのではないでしょうか…(ぴぬ氏割り当て・ぴぬ氏制作ですが、この件でぴぬ氏の世界としてカウントしても仕方がないと思います) - kuraud -- 2024-10-11 (金) 22:10:46

  • 正直な話、現状の扉部屋の設置に関して許可なく増やして良い状況を私は危険視しており、
    後者の仮定で進めるにはどうしたらいいか...という内容で書いてしまっています。
    そもそものこの件に関してもどうしたら良いかありましたら指摘くださると幸いです。

    エフェクトに関して、
    "扉部屋直下というゆめ2っきの玄関的立ち位置の世界において、一定の質を担保するため"...という目的のためある程度の基準を設けたいところで、一定の質を設けるために一つのたたき台としての基準でした。他にはDiscordでColby氏が扉部屋ルールとして仮定義してくださったものがあるので、DeepLで翻訳したものですが引用してみます。
    ルール1:ネクサス・マップはそれなりのコネクションを持つべきである。
    1. 自分のルートをつなぐ
    2. 既存のワールドとの接続
    3. 開発者のために赤い看板を残す。
    ネクサス・ワールドを作るには、3つのカテゴリーのうち少なくとも2つをクリアしなければならない。
    ルール2:明確なアイデアやコンセプトを持つこと。ゲーム内の他のマップに似たワールドを作ることは許されていますが、既存のネクサス接続から直接似たようなコンセプトを取ることは許されていません。
    ルール3:ネクサス・ワールドを作るにはそれなりの経験が必要です。ネクサスワールドを作成するためには、少なくとも5つのマップ(lmuマップファイル)を作成した経験が必要です。

    原文:https://discordapp.com/channels/450664875891490837/910910139660378182/1191698763497091122

    "エフェクト展示室"について、
    扉部屋への設置を一製作者につき一つのみ基準に基づいて安易に列挙してしまいました。
    エフェクトを捨てる"本家の扉部屋の機能"を担っているというのは勿論ですが、個人的にはうろつき邸の一部屋と同じ機能を持っている世界が同じデザインで扉部屋からも行けてしまう現状にはちょっと疑問が出てしまいます。
    とはいえ、この内容は今回の話とは脱線してしまいそうなので、こちらは一旦外して考えていただいて構いません。 -- 710? 2024-10-12 (土) 17:08:00
  • 個人的には…ですが、扉部屋の設置に制限を設ける必要性はそこまで感じていません。
    他の人が作ったマップに行きにくくなるような編集だったり、複雑な処理を扉部屋で実行させる編集は控えてほしいんですが、どんな世界を繋げるかは個々人の判断にお任せしても問題ないかなと今のところ感じています。
    エフェクトの有無やコンセプトの類似性などのマップの中身で制約を課すことは、その人の感じるゆめにっきっぽさの追求の妨げになってしまうと思います。
    マップの内容に踏み込んだルールは客観的な判断が難しいので、ルールを実際に運用するのが難しくなるし、偏った判断に陥ってしまう可能性もあると思います。
    どうしても制約が必要なら、明確な判断が簡単な形にしておいたほうが、ルールとして機能しやすいと思います。 -- qxy 2024-10-12 (土) 19:55:13
  • 2つの尺度が提案されていますが、この尺度の両方にマップが該当した場合、そのマップへの入口を扉部屋に設置してはいけないようにしたいという提案でしょうか?(正しく文意を汲み取れているか不安です)
    扉部屋に新規のmapを追加するうえで何かの条件を設けることには一定の価値があるかもしれませんが、ご提案いただいた尺度についてはちょっとしっくりこず、提案に賛成しがたいです。

    特に、2つ目の尺度についてですが、エフェクトに対してマップ数の増加スピードがあまりに速すぎるため、「エフェクト取得場所へのつながりに乏しい世界を扉部屋に置くことを認めない」というふうにエフェクト関連の条件で扉部屋の基準を決めてしまうことには無理があると思います。
    kuraud氏が指摘されておりますが、"既にあるエフェクトの2つ目の取得場所になれば基準を満たす"というふうに基準が乱用されるようなことになってしまうリスクもあると思います。

    夢世界の探索においてエフェクトの収集がそもそも必要なのかというところについては、今年9月ごろにCheo氏が2っき内の接続の個数や条件の数について調査されていたことがありました。そこでは、世界のつながり全2500個くらいに対して、エフェクトの有無が移動に関係するのは5%程度にすぎないという結果になっており、プレイヤーにとってエフェクトが率先して集めないといけない重要なものかというと、現状の2kkiではあんまりそうでもないのかな、というのが私の見解です。

    扉部屋に接続するマップに一定の質を保ちたいという言葉は少し理解できますが、ここでいう質とは体験の質であって、収集要素や更新頻度を質として評価してしまうのは焦点がずれていると思います。
    これは私の考えですが、プレイヤーがマップを探索したときに一番がっかりするのは、おそらく何かあるかもしれないと思って時間をかけて一通り探索して、代わり映えのない景色が続いて何もなかったときだと思います。
    これに対して条件を作るとすると、扉部屋直結の新世界から5つ以上の新世界をさらに用意するというのはどうでしょうか?

    具体的には
    ・扉部屋から行ける新しいNexus worldを追加するときは、その先に繋がる新しい世界を5つ以上用意する。
    ・奥に追加する新しい世界はなるべく早く実装し(可能ならNexus worldと同時)、遅くともNexus worldの追加から半年以内にゲームに実装する。
    ・奥に追加する新しい世界は自分自身で制作したものに限らず、他のツクラーと準備を協力してよいものとする。
    というのはどうでしょうか。(Nexus world: 扉部屋直結の世界のこと)

    もちろん、繋ぎ部屋のように他のツクラーにとって編集しやすいマップであるとより素敵ですが、勧奨程度におさめるべきかと。
    エフェクトの有無やそのツクラーの更新頻度、すでにNexus worldをもっているかどうかは別にマップの質に関連してないので、条件にからめるべきではないと考えます。
    なお、MAP0784に6つの世界を移すのは個数として少しやりすぎだと思いますので、他のマップにも配分するなど接続の密度を再考いただく余地があるかと思います。 - 窯良 -- 2024-10-13 (日) 01:01:50
  • ルールで制作の内容をそこまで踏み込んで制限するのはどうしても抵抗があります。
    提案されたルールを当てはめれば、710さんや窯良さんにとって良いゲームに一歩近づくのかもしれませんが、ある意味で他の人の考え方や可能性を潰していることに気づきませんか。
    例えば、窯良さんがプレイヤーをがっかりさせないようにという視点を重視されている一方で、他の制作者にとっては全く関心が無いこともあるかもしれませんね。窯良さんのマップに無い魅力を新しく創造できるのは、そういう別の視点を持った制作者だと思いますよ。

    今までの扉部屋の接続で、どうしても我慢できないようなものがありましたか?
    それはルールを作って無理やり解決するのではなく、制作者同士の個別の協議で解決できる範囲だと思います。
    共有部屋が明確に悪意を持って荒らされたりするような事態は一度も無いはずですし、これまで通り制作者の良識を信用しても問題無いと思います。
    もし現状に何か大きな問題点があるなら、ルールの議論の前にまずそれを共有して頂きたいです。

    私もどちらかと言えばゆめ2っきには良いゲームであってほしいと思いますし、710さんや窯良さんの提案したルールに納得できる部分もあります。
    ですが、710さんの仰る通り「ゆめ2っきの玄関的立ち位置の世界」ですから、そこに制作した内容に物申すようなルールを持ち込むのは、個人的にはあまり賛成できません。 -- qxy 2024-10-13 (日) 02:45:28
    • 本当に、どうしても扉部屋への設置に制限が必要なら、「扉部屋への設置を一製作者につき一つのみ」だけのルールはどうでしょうか。
      これならマップの内容に直接触れるものでもなく、明確だし、効果も見込めそうなので、まだ良いと思います。 -- qxy 2024-10-13 (日) 02:45:28
  • qxy氏のおっしゃるとおりで、私も無理に新しくルールを立てる必要はないという考えです。上記のコメントで提案した内容はルール(条件)を立てるならばという仮定の話で記載したつもりになっていましたが、文章を読み直してみると私の記述のしかたが悪く、申し訳ありませんでした。
    扉部屋にマップを作りたい/作ったけれど、内容をどうしよう?と個人的に聞かれたら個人間でアドバイスに答える程度にしておくのがいいのではないかなと思います。これを変にルールとして決めてしまうと、今後の制作を尻込みさせる原因になったり、ルールを作った意図がうまく伝わらなかったりして、結果的に個々人の理想をかなえることが困難だと思います。
    ここは共同制作ですから、さまざまな性質や魅力の入り混じったものがゆめ2っきの扉部屋として存在しているこれまでの形が維持されて良いのではないかと思います。- 窯良 -- 2024-10-13 (日) 03:04:21
    • 私も勢いですぐにコメントを書いていたので、窯良さんの記述の仕方に問題は無かったと思います。補足のコメントありがとうございます。
      正直に言うと、おそらく710さんの感じている危機感もとても共感できるのですが、それで本当に良いのか考えるととても難しいです。
      ルールを作るのは難しいなと感じますが、プレイヤーやゲームにとって扉部屋を良いものに改善していくことは大切なことだとも思います。 - qxy -- 2024-10-13 (日) 04:15:51
  • 私の意見としては、そもそもゆめ2っきは「ゆめにっきっぽいものを作る」といういわば「みんなのお砂場」でありそこには「自由な意思による創作活動」があると認識しています。しかしこのルールでは、それらとは打って変わり「質を第一にする」という一つのルールを全員に強制する形になっています。そこに果たしてこれまでのような自由はあるのか?みんなのお砂場が、何か別のものに変貌していないか?今一度考える必要があるのではないでしょうか。 -- †Nightmare† 2024-10-13 (日) 03:52:46
    • 加えて申し上げますと、上で言及されている「質(クオリティ)」という概念はあくまで710氏ご自身の基準であるように見え、それにそぐわないものを左遷するようなルール制定には少々疑問符が浮かびます -- †Nightmare†
      • 更に追記しますと、私は実際に胡蝶雨月へのエフェクトの設置を検討したり直通の繋ぎに対してエフェクト入手に近づくようなルート設置を行いましたが、表現の幅を狭めているだけのように感じました。その上、プレイヤーからは「なぜここに繋いだの?」と首を傾げられる結果となりましたので正直あまり良いものでもないと思います(これ自体は無茶をした私の責任でもありますが)。そうしたものを設置しなければならないというプレッシャーも強く感じたので、これをルール化することには否定的です。-- †Nightmare†
  • 提案内容に反対します。710氏のやりたいことは、コミュニティの総意・大義名分という形ではなく、よりシンプルに、コミュニティの2者間での相談により原作者の意向が変わった、という経緯での個人的な調整として扱われるべきだと考えています。個人的にそのような努力をすることは(原作者やコミュニティ全体の意向を遮ってまで行動を推し進めたり、その他無理を通すようなことが起こらなければ)自分は問題とまではいかないのかなと思いますが、それがルールの制定という形で発露されることに、私は強い問題意識を持っています。 -- 2i9? 2024-10-15 (火) 16:31:21
    • 扉部屋周辺の接続構造についてこの場で相談したい、こういう接続構造を考えてみたけれどいろいろな視点からの意見がほしい、みたいな意図だったら こちらの議論スレッドを使って進めてみてもそこまで問題ないかなと思います。(ただ、終始穏当な議論ができるよう710氏が議論の中でファシリテーター的な役割を担い、話題を逐次誘導するような努力が必要そうです) -- 2i9? 2024-10-15 (火) 16:35:43

  • 一旦最初の文言を折りたたみました。
    ここまで多くの反対意見が集まるとは思っていなかったので、まずは最初の案件について改めて議論したいと思っています。
    扉部屋への接続にてルールや基準を設けることについて、もう一度皆さんの意見をお聞かせください。 -- 710 2024-10-17 (木) 00:44:18
  • ルールや基準を設けること自体に反対意見はありません。
    扉部屋の広さは有限ですし、最近は制作者の人数も昔よりもずっと多いので、710さんがこのタイミングで発議された理由もよく分かります。
    どういったルールや基準が適切なのか…というのがとても難しいことだと思います。 -- qxy 2024-10-17 (木) 22:44:17
  • 適正な条件が何かないかどうかしばらく考えていたのですが、制作内容について画一的なルールや方針を定めるのはやはり難しいと思いました。自分にとっての扉部屋直結の世界としての「らしさ」のようなものを、数や言葉で表すのは困難でした。ただ、様々なマップを歩くとき、この世界は扉部屋直結として良いものだな、あるいはどこか違和感があるかもしれないな、というような感想が自分のなかにもあるのもたしかに事実です。クオリティコントロール的なものはこれまでゆめ2っきに公式にはありませんでしたが、扉部屋は夢世界の入口となる重要な場所ですし、なにかしらのコントロールを設けるべきというのも自然な考え方だと思います。
    以下、もし提案をするなら…という案 本筋から逸れるので折りたたみです

    ひとつ提案するならば、扉部屋直結世界の追加にあたっては、ツクラーから一定数の承認を得る必要があるということにするのはどうでしょうか。意図としては、ルールとして画一的に制作内容に基準を設けるのが困難なので、各人の裁量や考え方それぞれにコントロールをいっそ委任してしまおうという発想です。実際、世界追加の承認にあたっての基準や考え方は、各人に任せる形で良いと思っています。
    必要数については、「★…半年以内にゆめ2っきを更新していて、かつ引退表明をしていない日本のツクラー(日本語圏のコアデベロッパー)」の人数を数え、その四分の一以上の承認を、日本のツクラー(更新時期問わず)から得るというのはどうでしょうか。
    現在ですと★の人数は20人となるので、5人以上の日本ツクラーが承認すれば扉部屋に世界を追加してよいということになります。意見を求められたツクラーが承認しがたいと感じたときは、マップ制作者に何かしらの改善点を提案し、制作のためのひとつの意見として活用してもらうことができます。これなら、仮に今後2っきの更新が過疎化しても運用可能かもしれないとも思っています。

    なお、これはあくまで「何かルールを設けるならば」という議論に対しての案であって、扉部屋にルールや基準をどうしても設けなければならないという強い希望は私のなかにはありません -- 窯良 -- 2024-10-18 (金) 13:44:12
  • ルールを設ける目的は、クオリティコントロールというよりも、割り当てルールのように資源を分配するため…と私は考えていました。
    制作者が公平に扉部屋への接続の機会を持つためには、早い者勝ちのような現状のルールよりも、何か良いものがあるだろうなと。
    扉部屋はもちろん最大500×500マスで有限なんですが、制作者やプレイヤーにとって許容できる広さ(複雑さ)の限界はそれよりずっと狭いでしょうから、接続が増えすぎないように何か制限を設けましょう、という方向性です。
    各々の制作者の接続機会が絞られるなら、少ない機会でより良いものを作ろう試行錯誤してくれた結果、その制作者にとってマップの内容も良いものになっていくのではないかなと、楽観しているところもあります。
    710さんや皆さんが求めているのがクオリティコントロールなのだとしたら的外れな意見になってしまいますが、私が「反対意見はありません」と言った理由はこういう考えがあったからです。 -- qxy 2024-10-19 (土) 02:33:34
  • 改めて提案に賛成します -- 2i9 2025-03-19 (水) 16:17:38
  • 赤街灯が下げられないことでルールとして破綻しているので撤回します。710が求めているのはクオリティコントロールのためでもありました。 -- 710 2025-04-19 (土) 20:30:24

ゲーム内素材のライセンス確認と注意喚起ページ設置の提案

窯良 (2025-03-18 (火) 10:29:14)

お疲れ様です。
以下、やさこてん氏と雑談していて思い至った内容の相談です。

ゆめ2っき用の素材として提供されている音・画像などのコンテンツについて、
ライセンスや権利の問題があると考えられる素材が混ざっていることが最近みられます。
そのようなファイルはゲーム中に使わないよう、ツクラーに注意情報をまとめて情報共有する場(ページ)があったほうがよいのではないかと提案します。

従来はファイルの出典に誰かが気づいた段階でスタッフ名簿以下の個別の提供素材表に出典を掲載していましたが、
近年、提供素材数が主に音楽で著しく増えており、見逃しが発生しうることがありえます。
そのため、一つのページに注意情報をまとめたほうがよいのではないかと考えています。

少なくとも以下のような事項は、判明した時点で共有したほうが良さそうだと思っています。

  • ライセンス違反の素材
  • 明瞭に判別できうる、違法なサンプリング(ゆめにっき原作のサンプリングを含む)
  • 素材作者起因の問題(名義の騙り、盗作など)

また、すでにゲームに収録されている素材のなかで、素材の出典に問題があるのではないかという指摘が今後出た場合も、
同じページに情報を集約し、ファイルの差し替えの検討やツクラー向けの注意喚起として建設的に情報共有ができたらいいなと思っています。

こういったページを作って運用することには潜在的な問題点があるかもしれないと思いましたので、
事前に是非をここで相談させていただきたく思います。
どうでしょうか。

ついでに:
上記の内容は、ゆめ2っきについて権利関係をクリーンに保つための努力なので、ここからの話は性格が違うのですが…。

代理実装経由のマップ提供者についても、提供者起因の問題が生じたために今後の代理実装の運用が難しそう、
あるいは、新規の引き受けにあたってこの提供者には予想される警戒事項がありそう(モラルのずれや強すぎるこだわり等)と判明したとき、
代理実装担当者のだれかがトラブルを察知した時点で、ほかの代理実装担当者にも情報共有し、
トラブルを未然に回避し、代理実装者の負担を全体として軽減するような情報共有の場があったほうがいいのではないかと思っています。

これは、素材ファイルの問題ではなくて、より個人的でセンシティブな領域の話になってしまうので、
wikiなどに公に記載するのではなく、必要な方だけ確認できるどこかクローズドな場所で相談したほうがよさそうですよね。
これもどうしましょうか…。


  • 提供から実装まで時間が開くことも珍しくないゆめ2っきではこういった共有は重要だと思います。使っちゃダメな素材が一覧で分かると助かります。
    あまりにも問題なマップ提供者ならスレなどに報告していいと思うんですが、そこまででもない場合は扱いに迷ってしまいますね。私が代理実装しているときも問題のあるマップ提供者の情報が共有されることがありましたが、そのときはdiscordで共有されていたと思います。 -- qxy -- 2025-03-18 (火) 21:28:03
  • 賛成します。使ってはいけない素材 / 使ってもいい素材の判断に困る場合がけっこうあり、そこの線引きや網羅が大変だなとは思いつつも、そもそも「使ってはいけない素材がある」ことすら知らないような方も散見されるので、注意喚起として必要だと思います。 -- 2i9 2025-03-19 (水) 16:16:58
  • 賛成 (散らばっているより1ページ見て問題がないことを確認できたほうが手間が減って良いと思います。頑張っても100%安全な状態には保てないけど、既知の危険物は避けられたほうがよいですからね…) -- やさこてん 2025-03-21 (金) 01:59:20
  • みなさんありがとうございます、前半の内容に関しては後日ページ用意しようと思います。 - 窯良 -- 2025-03-23 (日) 16:05:55
  • とりあえずページを作成しましたが、まだ情報を集められていません。リスキーな素材の一覧
    最終的にはメニューの「情報共有/依頼」にページを追加するのが良さそうだと思っています。 - 窯良 -- 2025-03-27 (木) 14:24:18
  • とりあえず思い当たるものを書いてみました。しかし音楽とかの基準がよくわかっていないので、これは無罪では?ってのもあるかもしれない。 -- やさこてん 2025-03-28 (金) 23:10:33
  • 実際に書かれたものを見てみると将来、何らかの対応があった際などにスタッフ名簿の個別ページ側に記載漏れが出そうな予感がしたので、表にリンク置けそうな列を追加してみました。
    (URLでWiki内検索かければ一応出るし、他編集者さんのスタンスによってはいらないかも…) - kuraud -- 2025-03-28 (金) 23:55:19
  • 後半の内容について、Discordになりますが代理実装者間で情報を共有するためのグループチャットのようなものを作成しようかと思います。作成したら各人に招待URLをお送りしますが、利用するかどうかは各人の裁量におまかせします。 -- 窯良 2025-04-19 (土) 14:25:15
    • 海外のツクラーさんの代理実装をアクティブに担っている方に参加をお声がけします(2i9さん、ほらつきさん、やさこてんさん、ナビサエさん、中津さん)。それ以外のツクラーさんでも、内容を確認しておきたいよという方がいらっしゃいましたらご連絡ください。 -- 窯良 2025-04-19 (土) 14:29:02
  • 特に何もなければ1週間以内に過去ログに下げます -- 窯良 2025-04-19 (土) 17:02:36

ゆめ2っきの任意の小部分について、難易度調整、表現の調整、接続・深度管理、編集意向の確認・すり合わせ、不具合未満のささいな微調整の提案・相談を行うための場所がwikiに欲しい

窯良 (2025-04-02 (水) 19:26:04)

題名がすごく長くなっちゃいましたが、題名の通りです。
なんとなく、ツクラー向けの気軽なフォーラムのような場所があったほうがいいんじゃないかと思って提案しました。

本スレ・避難所のほかに、議論ツクラー質問掲示板(これはRPGツクールの技術相談的) がすでにありますが…
本スレ・避難所はどちらかというと更新や予約のための定型連絡、
議論は見解がわかれそうな問題やゆめ2っき全体にかかわるような問題を扱う場所というふうになっていて、
題名のような小規模な相談や見解の募集・すり合わせなどはここ数年はwikiやスレ外のSNSやSkype/Discordなどで行われることが多くなってきています。

ただ、クローズドな場所でこういう相談を続けると、連絡先が分かりやすくて声をかけやすい人・逆にかけにくい人の差ができてしまったり、
そもそも何かにログインしないと見られないような場所に制作の情報が溜まってしまったり、
本スレ・避難所、議論で相談するには敷居が高すぎてなんだかなという気持ちのうちにどこにも表明しないまま流れてしまうささいな意見が生まれて消えてしまったり、
そういう思いがツクラーの間に漂うことが時々あることを肌感覚で感じて、この提案をしました。

ツクラー希望素材ツクラー質問掲示板のような形式でページを立てて、小さなトピックや相談・提案はそちらに集めて、
ツクラー間でオープンな場所として使うほうがすっきりするのかなと想像していました。

掲示板ページを作るなら、説明の文章はもうちょっと整理したほうが良さそうですが…
ツクラー向けにこういうページを持つことについて、ツクラーの皆さんはどう思いますか?

(ページを作るとして、取り扱う話題の例)

  • 新規の編集内容について
    • マップを作ったんだけど、◎◎さんのMAPxxxxのここに接続してもいいですか
      • つなぐと深度が浅くなっちゃったり、もともとのルートとは別のやり方でこの世界に来れちゃうけど、大丈夫かな
    • ◎◎さんのこの素材を使わせてもらってもよいですか(素材の利用規約で、作者への確認が求められていた場合)
    • 半年ルールで過去のマップを編集したいけど、けっこう編集量が多くて、こんなに変えちゃって大丈夫かな
    • Edit Infoを読んで編集したけど、これで大丈夫ですかね
  • 難易度調整について
    • メニュータイプNo.XXの取得に要求するプレイ難易度があまりに高すぎて、◎◎の部分を簡単にしたほうがよいのでは
    • 壁紙No.XXの条件がシビアすぎて、取るのが難しい気がするよ
    • ◎◎のマップが貯金箱の金額に影響してるけど、ここに行くのは大変すぎやしないかい
    • 探索をじゃまするトラップや追いかけNPCが多すぎて、やりすぎかもと思ったよ
    • エフェクトをここに置きたい/ここに置いてあるけど、発見難易度的にこれっていいんですかね
  • 体験調整について
    • BGMやSEが大きすぎてまずい気がするよ
    • マップ移動の前後でうろつきの向きが変わるのが見えてしまうよ
    • ◎◎のマップの前後で、マップ移動のための演出時間が長すぎる気がするよ
    • 文字イベントとして、この世界の◎◎の部分を管理対象にしたほうがいいんじゃないか
    • すごい額の夢通貨をあげる/奪うイベントがあるけど、大丈夫ですか
    • マップの色や点滅が激しすぎて、もうちょっとなだめてもいいかもしれない
    • マップが暗すぎて、カンテラを使えるようにしたほうがいいかも
    • このキャラセットは、あと1ドット下に画像を動かしたほうがキャラクターが自然に見えるかもしれないよ
  • その他
    • 自分の編集のうちの小さな部分について、単に他の人の意見を聞いてみたい
    • ◎◎の内容って、決定事項や何かのライセンスに違反してるかもしれないけど、大丈夫ですか

  • 個人的にはzawazawaトピックにしておくとメンション機能を他ツクラーさんへの呼びかけに活かせたり画像添付しやすかったり良い感じかも、と思いました (ガイドライン編集相談所みたいにページ内に置いておく形でもよさそう) - kuraud -- 2025-04-02 (水) 21:07:08
  • 良いと思います。個人的には完全にツクラー向けに絞るよりもプレイヤーも含めてオープンな場として意見を募っていっても良いのかなと思いました。体験や難易度の調整を目的にするなら広く意見を募っていく方がより有意義なものになるかもしれません。名無しの人が議論に参加すると意見をまとめるのが難しくなったり良し悪しはあると思いますが、一考の価値はあると思います。 - qxy -- 2025-04-02 (水) 21:36:32
  • 名無し投稿を許容するかどうかですが、IDや送信サーバー情報である程度個人を識別できるとはいえ、完全に名無しの人を招くことで無責任・ずさんな投稿が入り、誰かを無用に傷つけることを心配しています。
    zawazawaトピックは、トピック群=グループ=wikiごとに書き込める人の範囲を3つのなかから選択できて、無制限、zawazawaログイン者のみ、グループメンバーのみのいずれかから選択できるようです。
    少々設定やログインは面倒ですが、このようなページをzawazawaトピックで準備するなら、プレイヤーからも広く意見を受け付けるものとしつつも、発言にある程度責任を持ってもらうという意味でログイン者のみ投稿を受け付けるようにしたほうがいいのかもしれません。 -- 窯良 2025-04-02 (水) 21:54:03
    • よりツクラーの意見を集約しやすい環境づくりのためにツクラーに絞ったページとする意義は分かりました。広く意見を集めるならそれこそ制作スレを使えば良いとも言えますね。 - qxy -- 2025-04-02 (水) 22:22:40
    • 自分の気持ちとしては、自分の発言に責任を持てない名無しじゃないと書けないようなことを建設的な場に持ち込むのはありえないという普通のことが、こういうような気軽でちょっとした相談ができる空間を守る前提となると思っているんです。
      必ずしもツクラーに発言者を絞る必要はなくて、プレイヤーでも名を名乗って協調的に議論していただけるなら問題ないだろうと思います。 -- 窯良 2025-04-02 (水) 22:33:26
    • 役割が結構被ってそうなツクラー質問掲示板がそこまで利用頻度高くないように思えたので、ツクラーもプレイヤーの延長線上と考えればあえてツクラーに絞る必要性もないように思っていました。しかし、どのような運用にするとしてもそれぞれ良いところがありそうですね。 - qxy -- 2025-04-02 (水) 22:56:10
  • 地味~な補足なのですが、ログイン必須などの制限はいつでも切り替えられるので「一旦これで行きましょう」という形もできます。
    あと思ったのは、場合によっては素材提供者さんから「以前提供したアレを差し替えてほしい」みたいな相談もありえそうですね。(ツクラー質問掲示板辺りだとそういうの話しにくいのかも) - kuraud -- 2025-04-03 (木) 00:29:37
    • ログイン必須制限をつけるかもしれないという前提で考えると、https://z.wikiwiki.jp/cj57thz9al2p3mln/ とは別のトピックを立てたほうがいいんでしょうか?たしかに、素材提供者やその他スタッフも参加できるような場になることが理想的です -- 窯良 2025-04-03 (木) 20:56:12
    • ログイン必須の設定はグループ(掲示板)全体ではなくトピック(スレ)ごと*1なので https://z.wikiwiki.jp/cj57thz9al2p3mln/ 内でよいと思います。 - kuraud -- 2025-04-03 (木) 22:09:29
    • 混乱してました、ありがとうございます -- 窯良 2025-04-03 (木) 22:21:29
  • もしかしたら他の人と同じことを違う言葉で言ってるだけになってるかもしれないけど一応私も表明
    日によってはスレが劇物になっているので(指摘された欠点を曲解・誇張して中傷に使われかねない場面がある)答えが出にくい議論の場に適さないときがある
    出た意見を一旦保留して共に考える場は、意見の共有が出来、極端な結論や、些細な不満の蓄積の爆発を避けることができる(些細な不満の爆発によるアンチ化は実際スレで発生している)
    閉じた場での意見交換は時に偏った結論を導きかねず、製作wikiという完全に全員が見れる場でやることで第三者にストッパーの役目を期待できる
    上記の理由から比較的管理しやすい状態であるwikiでしか、はっきりとした結論が期待できない不満を建設的な形に昇華できないと私は思います。実際に荒らしを規制できる一点でスレより優れているので…
    私が5ch下手なだけかもしれませんが感想の域を超えた大規模な誹謗中傷を防げなかったのを考えるとあまりに…(相変わらずひどい文章で失礼) -- やさこてん 2025-04-03 (木) 01:19:05
    • 避難所はともかく、本スレは近年でも誹謗中傷が入ったためしがありますし、スタッフにとっても些細な相談を書くには書き込みづらいなと感じがちだと思います 私の個人的な感想ですが、まじめな意見をやりとりするには不向きな場所になってしまってきたのかなと思っています(投稿規制もしばしば激しいですし) 避難所とすみわけをする形で、今回の場を準備できれば良いのかなと考えています -- 窯良 2025-04-03 (木) 20:59:39
  • ホントは話題ごとに小さいスレッドを立てられるのが良いのかなと思ってましたが、zawazawaトピック1つを用意してそのなかでツリー形式で返事をするような形のほうが2っきには合ってるんでしょうか(避難所のような) -- 窯良 2025-04-05 (土) 23:13:25
    • そこに関してはかなり未知数ですね……。「話題ごとにトピック(スレ)立ててね」と言われた時に各々がどう感じるかがポイントなのかなぁとは思います。……仕様として可能か否かで言えば可能です。 - kuraud -- 2025-04-06 (日) 21:17:46
  • しばらく考えてみました。アクティブな人があまり多くない現状をふまえると、話題ごとにzawazawaトピックを立てると話題を読むのに1クリック階層が増えてしまうことと、トピックを立てる作業も少し煩雑ですので、通常のzawazawaトピック1つに(避難所のように)フォーラム空間をまとめるのが気軽かつ話題に触れやすくていいかなと思いました。
    避難所を更新・予約報告、周知事項用に今まで通り使い、意見交流やささいな相談・提案を取り扱うものとして今回の新規のzawazawaトピックを用意できたら、すみわけもわかりやすいかなと考えています。 -- 窯良 2025-04-07 (月) 22:49:20
    • 10日程度経って特に反対意見なければ、まずはお試しとしてトピックを立ててみて、実際に使ってもらって追加でほしい機能や配慮について考えていけたらと思っています。 -- 窯良 2025-04-07 (月) 22:53:53
  • 月曜に上記のように1トピックでやってみる提案をしたのですが、全部の話題を一つの板でやる状態は、現行の避難所とかわりばえせず、結果として新しい話題を出しづらくなってしまいそうだなと後から懸念が生まれました。
    すこし野暮ったい形になりますが、いくつか話題のカテゴリを分けて、カテゴリごとにトピックを用意する案を下記に提案したいです。
    あわせて、制作に関する話題の現状の相談場所も、理解のために一度まとめてみました。 -- 窯良 2025-04-09 (水) 18:11:32
古い案の折りたたみ

●用意してみたいトピック 10個

[端書きとして]
*問題点の指摘をするときは、改善案と必ずセットで話しましょう。
*ツクラーもプレイヤーも投稿できます。
*投稿はZawazawaへのログインが必要です。アカウント作成はこちらから > https://zawazawa.jp/s/signup

1)一般
:総合的なディスカッション、どこに該当するか分からない話題、制作で生じたささいな質問、疑問

2)【相談】他作者のコンテンツの編集・素材の利用について
:マップの接続・編集の相談、ルート調整、素材利用

3)【相談】自分の領域の制作・編集について
:自分の編集方針を他の人に仰ぐ、自分のコンテンツの追加編集を他のツクラーに依頼する

4)【提案】ゲームの難易度や複雑さ、収集要素の条件に関する調整
:到達判定加算対象、SR分室、壁紙、パズル絵柄、メニュータイプ・システム効果音、夢通貨、エフェクト、追いかけNPC・閉じ込め・強制起床、アクションゲーム・パズルゲーム的難易度、主人公の最大HP等

5)【提案】視覚的・聴覚的ストレスに関する調整
:BGMやSEの大きすぎる音量、光の点滅や画面揺れなどの激しい演出、暗すぎて判別が困難な画像、精神的ショックが強すぎる可能性のある演出等

6)【提案】文字イベント関連
:既存のマップ・イベントを文字イベント管理対象とする提案、対象となっているマップ・イベントの扱い、文字イベントOFF版の演出の作成等

7)【提案】細やかな表現の調整
:マップ移動時の演出、カンテラ時の明るさ、ふみきりやチェーンソーをはじめとしたエフェクト反応の追加、画像・音楽素材の微調整の提案等

8)素材に関係する相談・報告
:提供素材の更新・差し替え希望、ライセンスや著作権にまつわる報告事項なにかあればこちらで、問題のあるコンテンツの差し替えの提案など

9)ゲームファイルの管理
:マップツリーやデータベースの管理、容量削減可能なファイルの探索、RPG_RT特有の問題の対応(場合によってはEasyRPGも)

10)YNO関連の管理・相談
:YNO管理者チームと協議したことや新しい共有事項の更新があれば記載する

*8、10については避難所でもカバーできそうだが、話題を一箇所で追えるようにしたほうが将来的に楽だと考える

●準備する優先度は低そう:

@)更新・予約報告、代理実装報告、R4R用の場
いまは避難所や本スレでよいだろう。

@)ゲームシステムや制作ルール・慣習、その他ゲーム全体に関係する、大々的な議論が必要となる提案
いまは議論ページでよいのでは。

@)他の作者のコンテンツに関するその他の提案
上記でカバーしきれないような、各人の制作物やゲーム全体の根本や大規模編集にかかわる相談が該当。論争を呼ぶ原因となるので、トピック設置は慎重に考える必要がある

@)ロダ素材関連
素材を使用した報告、素材をアップロードした報告
いままで慣習的にこういった報告はされておらず、報告をしなくても無問題だと思うが、使用素材の重複を避ける(主に画像素材)という意味ではトピックを用意する価値は小さくながらもある

既)Wiki編集報告
WIKI編集相談所がすでにある

既)必要素材の提供依頼
希望素材掲示板がすでにある

既)RPGツクール2000の技術的相談
ツクラー質問掲示板がすでにある

既)リスキーな素材の検討
zawazawaのロダ素材関連トピックに内容をあわせてもいいのかもしれないが、今はwikiの1ページに表として知見を集約しておくのがわかりやすいはずである

脱線してしまった:Discord系の場のまとめ

●Discord系の場のまとめ:

既)Discord「ゆめ2っき・オン2っきを楽しむサーバー」のツクラー向けチャンネル
些細な話題や制作中のスクリーンショットがここにあげられており、その運用は継続してもよさそう。
ただ、ツクラー全体に周知するような内容や、公に行ったほうがよいことはすべて本スレ・避難所・wiki・上記トピック類で行ったほうがいいだろう。そこもこれまで通り。
(Discordは参加していない人には見えないし、参加しないと見えないような場所に大事な情報を書くべきではない、大事な情報はそこにはないという前提でプロジェクトが回るようにするべき。)
小さな話題の集積として機能しており、英語圏の人も参加しやすいのがいい。

既)Discord「Yume 2kki <ゆめ2っき>」の#warehouseチャンネル
海外ツクラー向けの雑談・制作共有・相談チャンネルとして運用されている。海外ツクラー同士で制作情報やゲーム情報を共有・理解するための場として活用されている。
ゆめ2っきバグ報告所が同サーバーに#laboratoryチャンネルとしてあり、かなり活発に報告がある。
日本ツクラーはおそらくほとんどこのサーバーを読めていない。

既)Discord「ゆめラボ(未満)」
日本。2っき含むゆめ派生作者向けの知見共有の場。ゆめにっき関連の資料やツクールの技術相談がされている。
雑談、議論を呼ぶ話題などを取り扱える場所としても有用であるが、利用頻度は低めで、人数もそんなに多くない(ツクールやウディタを扱える人中心)。

既)Discord「Yume Nikki Online」
ゆめ2っき開発自体の話はここにはない。
ただ、YNO特有のバグ報告や、YNOサービスの不具合、EasyRPG特有の不具合はこちらで処理されている。
ゆめ2っきの新バージョンにセーブデータやデータベースを破壊する重篤なバグがある場合は、すみやかにこちらの#technical-feedbackに報告をいれるか、YNOの管理者たちのどなたかに連絡をとったほうがよい*2

廃)Discord その他のサーバー
把握している限りでは、過去のサーバーはすでに廃れたか、人数が非常に少ないかどちらかで、開発の話は行われていないとしてよい。
Collective Unconsciousの開発サーバーや、Uneven Dreamのサーバー、Dream Diary Development(夢派生全体)サーバーにおいても、2っきの開発の話はまったくない。

  • すごく主観的にいろいろ提案しちゃってるので、良くないところやそれはどうなのという部分があったら気軽にご指摘いただけると助かります。 -- 窯良
    • 迷走していたら諌めてくださると助かります、当初の提案の目的に合わせてもっと絞った方が良さそう -- 窯良 2025-04-09 (水) 22:24:04
  • ぶっちゃけた話、どれも"制作スレ/避難所で可能"なものです。なので私的に方向性としてはかつてあった雑談板と制作スレの中間くらいのものかなと思っていました。(話半分で言う…くらいの感じ)
    私的にはここまで細かくする理由がちょっと思い当たらないです……。後からもトピックは立てられるので、(話題ごとにトピックを立てる形じゃない感じなら)まずは整理統合・網羅的な感じで立てておき必要に応じて細分化させていくことも一案だと思います。 - kuraud -- 2025-04-09 (水) 22:25:13
    思ったところ

    2)【相談】他作者のコンテンツの編集・素材の利用について
    3)【相談】自分の領域の制作・編集について
     読む限りだと(私が)上手く使い分けられるかな……と思いました。
     それぞれ話の主役が違うので、書き込みが多くどちらかが埋もれてしまうなら分ける価値は確かにありそう、とも思います。
    5)【提案】視覚的・聴覚的ストレスに関する調整
    6)【提案】文字イベント関連
    7)【提案】細やかな表現の調整
     文字イベントに関しては実装される頻度を思うと上下どちらかにまとめてもよいと思います。
    表現に関するものとしてまとめてしまうのも悪くなさそうと思いました。
     ただ、もし今後なにか類似機能(蜘蛛恐怖症対策モード的なアクセシビティ項目)が増えていったら独立してた方が便利かも?
    9)ゲームファイルの管理
     聞く限りは他トピックの色が強くなったり、レアケースゆえに制作スレ/避難所や1)一般でカバーできたりしそうな気がします。
    8)素材に関係する相談・報告
    10)YNO関連の管理・相談
     これはこれとして今回の話題とは別で存在してたら便利だと思います。
     前者については差し替え希望をデータ/パソコンの壁紙データ/パズルゲームの絵柄で受け付けてる現状なので、それらのコメント欄を置き換えて共有させてしまってもよいかも。
    @)ゲームシステムや制作ルール・慣習、その他ゲーム全体に関係する、大々的な議論が必要となる提案
    @)他の作者のコンテンツに関するその他の提案
     大規模なものであればであればそれこそ制作スレ/避難所があるのでは……。
     後者も、2)7)辺りでやるものかなと思って読んでました。
    @)ロダ素材関連
     性質としてはこれは8)素材に関係する相談・報告に内包されている気もします。 - kuraud -- 2025-04-09 (水) 22:25:13

  • 1つ提案なんですが、ログインしなくても書き込めるようにしませんか。わざわざアカウント作って管理するのが煩わしく感じます。ここまできちんとした場所を作ろうとするならツクラーに障壁なく参加してもらったほうがいいなと思いました。 - qxy -- 2025-04-09 (水) 22:54:58
  • 私はてっきりバグ報告のような話題毎に新しいページを作ってくようなものを最初想像してました。kuraudさんの言うどれも"制作スレ/避難所で可能"なものと言うのはその通りで、避難所と変わり映えしなさそうだなとちょっと感じてしまいました。 - qxy -- 2025-04-09 (水) 23:01:32
  • 当初の目的から迷走して混乱を招いてしまいごめんなさい。今日のさきほどの提案(トピック作成の形式)は撤回します。
    この議論当初の目的は、気軽なフォーラムのような場所を用意することでした。それはkuraudさんがおっしゃるとおり、本スレ・避難所未満、古い雑談コメント欄以上くらいのやや緩い性格のものが良いのだと思います。今日の私の提案だと、見るところが増えてむやみに複雑になり、結果として気軽に書き込みにくい場所になってしまうなと反省していました。

    ①気軽に書き込める、②話題ごとに話の流れが追いやすいものが良いツクラー質問掲示板議論バグ一覧のような)、③誰でも見られる、④制作の主軸はあくまで本スレと避難所 の4点が前提となるような空間が良いのだと振り返りました。

    ①→ログインしなくても書き込めるようにしたほうが良さそうですね。ツクラーに限る必要もなく、アカウントを作る障壁がないほうがいろいろな場所・端末から気軽に書き込めて良い気がします。必要に応じてこのコメント欄のように名前を各自がつけられますし、トリップの確認が必要なようなことは本スレ等で話せばよさそうです。
    ②→大まかなカテゴリごとに板を分けるよりは、個別にページを作るスタイルのほうがやはり良さそうです。wikiwikiのtrackerプラグイン(バグ一覧ツクラー希望素材ページで使われている機能)でページを作るのでも良いかもです。
    ③→当wiki上のページとして管理するのが良さそうです。
    ④→さっきの私の提案のような、たくさんのzawazawaトピックが乱立するような形は更新が追いづらいし、本スレ・避難所の性格とかぶってしまいそうです。むやみにトピックを増やさず、1つのページから各話題にクリックしてアクセスできるような形がよさそうです。

    先の提案では話題をいくつかのカテゴリに分けておくことも提案していました。これはバグ一覧ツクラー希望素材ページでtrackerプラグインでやっている感じで、話題を最初に投稿する人が、話題のカテゴリをプルダウンメニューで選べるようにすることで代替できそうです。
    カテゴリごと見るような機能もwikiで実装しやすそうだし、良いのではないかと思います。 -- 窯良 2025-04-09 (水) 23:48:17
    • 私は良いと思いました。制作スレと避難所に話題が横断してしまうことは今もたまにありますが、それが過ぎると話題を追ったり参加するとき大変になってしまいますから、制作上重要な報告や相談は本スレと避難所に任せた方がいいな……と考えていました。興味がある人が摘まんで読めるような感じだと気軽に参加できて良さそうだと思いました。 -- qxy 2025-04-10 (木) 00:51:57
  • ありがとうございます。練習ページ#ed05e67d ここでフォームを試作してみています。何か手を加えたほうがよいところはありますか? -- 窯良 2025-04-14 (月) 23:45:03
  • 試作の作成乙です。見た感じこのまま使っていけそうですね。
    投稿時に添付フォームが設置されますが、添付したファイルは削除が難しいことや画像以外は容量制限の面でも適さないことを思うと、もし置くとしても&attachref;の方が適してそうです。あと感覚的なものなのですが「返信可」の部分、「進行中」もアリかなぁとちょっぴり思います。
    ……今になって言うのもなんだか気が引けますが、実際に形となったものを見てみると、ツクラー質問掲示板からもう一歩範囲を広げてツクラー以外の質問・相談も書けるモノ……という雰囲気を感じました。ツクラー質問掲示板の名前を変えて(もしくは過去の投稿内容を引き継ぐ形で)今回の案に吸収させてしまうのも一案なのかも……?(そことは性質が違うよって感じなら聞き流してください) - kuraud -- 2025-04-15 (火) 00:46:17
  • 練習ページのフォーム試作見ました。
    このまま運用してもとても良さそうだと思いました。
    あえて1つ挙げるとしたら、カテゴリーをまとめてカテゴリー名を簡潔にしてしまってもよさそうかなと思いました。
    ここらへんは個人的な好みに過ぎない問題だと思いますので、スルーしてもらっても全然大丈夫です。
    一案ですが、
    ・未分類 : どのカテゴリーなのか迷ったらとりあえずこれを選んでおくことにして投稿のハードルをちょっと下げる。他の人が後から別のカテゴリーに分けたりしてもいい。
    ・全般 : 雑談、総合的なディスカッション、複数のカテゴリーに深く関連するような話題
    ・マップ制作 : 他ツクラー領域の加筆・変更 + 自分のマップ制作 (これはまとめすぎかもしれない)
    ・難易度 : 難易度や複雑さ、収集要素の条件
    ・表現 : 光・点滅・視覚ストレス + 音量・聴覚ストレス + 細やかな表現 + 壁紙・パズルゲームの素材の表現に関するもの
    ・素材 : 素材の利用・編集・報告 + 壁紙・パズルゲームの絵柄の差し替えとかの相談
    ・YNO : Yume Nikki Online関連の相談 -- qxy 2025-04-15 (火) 00:48:12
  • お二方ありがとうございます、いただいた案をもとにもう少し簡潔にしてみます。名称を変えたうえで(現状仮案はゆめ2っきフォーラム)、ツクラー質問掲示板と内容を統合するのもありかなと思います。ツクール技術相談系だけ別の場所にある必要もないかなと感じています -- 窯良 2025-04-15 (火) 18:20:47
    • いただいた意見をもとに仕様アップデートしてみました。雑談なども該当することを考えると、「返信可」「進行中」というよりは「開放中」のほうがいいかなと思ってそうしています。お試しで「RPGツクール」というカテゴリーを作ってツクラー質問掲示板を包含する受け皿を作ってみました。 -- 窯良 2025-04-15 (火) 18:43:43
  • 私はいい感じだと思いました。カテゴリーも見やすくなったのではないかと思います。試作の作成お疲れさまでした。
    (試作のフォーラムで間違って追加ボタンを押してしまって空っぽの投稿を作ってしまいました) -- qxy 2025-04-15 (火) 21:22:25
  • もしもツクラー質問掲示板の記事を移行する形で統合するなら、ふつうにフォーラムを運用しだしてから後で記事をコピー&形式変更する形でいいのでしょうか?(付番とか気にしたほうがいいものなのでしょうか) -- 窯良 2025-04-16 (水) 23:02:53
  • 付番に深い意味はないので、コピー&形式変更でいいんじゃないかと思います
    強いて言えば付番を変えないようにしておけばリンク張り替えしやすいかもしれません (でも他所からリンクされてはなさそう) - kuraud -- 2025-04-16 (水) 23:40:17
  • 本番ページを試作してみます。適宜、見出しやはしがきを設置する必要がありそうなのでしばらく編集に時間がかかります。ツクラー質問掲示板の記事も、コピー・マージしてみます。 -- 窯良 2025-04-17 (木) 18:35:54
  • 改めて作成お疲れ様でした! ツクラー質問掲示板の方、ひとまず投稿フォームだけはコメントアウトで外しておこうかと思います (誤爆やイタズラに使われても困っちゃうし…) - kuraud -- 2025-04-17 (木) 21:07:01
    • ありがとうございます、つつがなく本ページが運用できるようであれば、一週間程度でここの議論は過去ログに下げようと思います。(フォーラムのページに、沿革を示す意味で議論ログへのリンクはどこかにちっちゃく掲載するかも) -- 窯良 2025-04-17 (木) 21:11:06

特定のマップらを非表示にして二度と表示しない機能の提案

やさこてん (2025-02-08 (土) 08:28:09)

<要約>
目的: ゆめにっきっぽくないからゆめ2っきにいるべきでないという意見からマップを守る
方法: マップの入り口近くに消去用マップへの入り口を設置、消去用マップで消去を選択すると消えるマップの収集要素を全開放する
問題: 不穏なイベントか何かと間違えそう、気が変わった時に戻せない

<本文>
ルール違反ではないがあまりにゆめにっき派生として前衛的な表現や、遠すぎる旅は時に一部のプレイヤーに大きな不満をもたらすため、このような手段を提案します。 踏破率に含まないだけでは収集要素の追加を拒絶してしまうし、「せっかく長く歩いたのに到達率は微塵も上がらないし、SRも増えない…」という落胆の元にもなってしまいます。 そこでマップの入り口を非表示にし、収集要素を回収済みにする選択を可能にすることで

  • 探索欲のある人は今まで通り探索で踏破率や収集レートが上がる楽しみを維持する
  • 前衛的な表現をしたいツクラーが過剰に拒絶されることがなくなる
  • 古典的なゆめ2っきが好きな人は嫌なコンテンツを通らなかったことで発生した不利益を気にせずに済む
    になり、全員がハッピーになれると私は考えます。
    (この選択肢を提示されるということ自体がショッキングなことではあると思いますが。)

方法は各所のマップへの移動オブジェの近くにアプリのアンインストールアイコンのようなデザインのイベントを置き、
1. そのイベントに触れると消去するか選択するマップに移動する。
2. 消去を選択すると該当マップの収集要素に関するフラグを達成状態するイベントを作動させ、マップを退出する。戻るを選択すると何もせずマップを退出する。
3. 以後アンインストールアイコンが非表示になる。
というのを考えています。

考えられる問題は「不穏なイベントか何かだと思って探索好きの人が間違って消去を選んでしまう」「プレイヤーの気が変わっても後戻りができない」があります…
ご意見お待ちしております。


  • 賛成でも反対でもなく単純な質問なのですが、「Aさんのマップに行きたいけど非表示にしているBさんのマップにしか接続がなくて到達できない」という事例は発生しうるのでしょうか。また、発生した場合はどのように対処したらよいのかについても良ければ教えていただけると幸いです -- 2025-02-08 (土) 22:16:04
  • 実装や管理の煩雑さに比して目的を達成できていないように思えてしまうので、賛成できません。ゆめにっきっぽくないからゆめ2っきにいるべきでないという意見は、収集要素などゲームでの不利益と無関係に生じていると思います。
    それに、消去用マップの入り口って私にはゆめにっきっぽいとは思えないし景観が崩れるので、設置を強制されるならとてもハッピーにはなれそうにありません。技術的にもほとんど実現不可能に近いと思います。
    話し合いをして相互理解を深めていくことが問題解決の最善の方法だと思います。
    基本的に皆自分が感じたゆめにっきっぽさを込めてマップなどを作ってるのだと思います。それを言葉で伝えることも、耳を傾けることも、共同制作において大切なプロセスなんだと思います。 -- qxy 2025-02-08 (土) 22:44:31
    • (補足)やさこてんさんの提案は「ゆめにっきっぽくないからゆめ2っきにいるべきでない」という意見に迎合するものだと思います。「ゆめ2っきにいるべきでない」なんて断じたり、「それじゃあマップを見えないようにしよう」なんて応酬することは、どちらもやってることは同じに見えます。相互理解を拒絶する姿勢が共通していますから。同じゲームを遊んでて、同じゲームを作ってるのに、それってすごくバカバカしく思います。
      やさこてんさんの提案の根底に優しさがあることはよく分かります。ですが、技術的なことを抜きしにしても、提案された内容にはこうした理由から疑問を感じています。 -- qxy 2025-02-09 (日) 10:58:49
  • 「特定のマップらを非表示にして二度と表示しない機能」に関しては、qxy氏が述べたように技術的に無理がある、仮に実現したとしても制作者への負担増加になると考える為、反対の立場です。
    ただし、「ルール違反ではないがあまりにゆめにっき派生として前衛的な表現や遠すぎる旅」といった要素については、私自身も少し思うところがあります。これらについて明確な線引きやルールを設けるまではいかなくとも、プレイヤーへの配慮やゲーム全体への影響を意識した制作姿勢が求められてもよい、それによりプレイヤーの不利益を少しでも避けられるのではと考えます。
    ここからは主に「ルール違反ではないがあまりにゆめにっき派生として前衛的な表現」についての私の意見です。
    自分が面白いと感じるものを実装したい、まだ誰もやっていない表現をしたい、実験的なマップを作りたい、という試み自体は構わないと思います。しかし最近頻繁に「ゆめにっきっぽいゲームを作る」という本来のコンセプトからかけ離れているのではと感じる、それこそ「ルール違反ではないがあまりにゆめにっき派生として前衛的な表現」が個人的には見受けられると思います。
    ゆめにっき、ゆめ2っきのどこに魅力を感じたのか?どの部分から影響を受けたのか?本当に「ゆめにっきっぽいゲーム」を作りたいのか、それとも単なる実験の場として扱ってはいないか?という目で見てしまうマップが存在する、が正直な感想です。
    「ゆめにっきっぽい」は人それぞれであり、明確な基準が存在しない概念である事は周知の事実であると考えます。制作者が「これが私の考える『ゆめにっきっぽい』です」と主張するなら、どんな形であれそれは否定されてはならないと思います。
    ゆめ2っきもまた、各制作者が思う「ゆめにっきっぽい」を、できる限り他者から制限される事無く表現してよい場と考えています。
    しかし、やりたい事なら何でもしてよい場だとは考えていません。共同制作であるからこそ限度・節度が求められる部分はあると考えます。長く制作が続いている上で変化が発生するのは当たり前の事ではありますが、何もかも許容してしまう事はこのゲームの本来のコンセプトを見失う事に繋がると考えます。
    表現やグラフィックに関してはまた別の議論になると思うので省きますが、少なくともマップの仕様や収集要素については、例えば以下のような点をできる限り考慮するよう周知する位はしてよいのではないかと考えます。
    ・収集要素やマップのギミック等の過度な難易度設定によって、プレイヤーに不必要な苦痛を与える事がなるべく起きない様に配慮する事
    ・新たなギミック等を実装する際は、複数の制作者から意見を募り、ゲームバランスを適切に調整する事、実装後に何かしら意見が出た場合も、適宜調整していく事
    ・どうしても譲れない仕様がある場合、プレイヤーに不利益の出ない選択肢を用意する事
    長くなりましたが、最終的に言いたい事は、プレイヤーへの配慮やゲーム全体のバランスを意識する姿勢を各制作者が改めて心掛けることが、解決とはいかなくとも制作者の保護やプレイヤーの体験の改善に少しは繋がるのではないかという事です。 -- 宇和 2025-02-09 (日) 05:10:15
  • 返信を一切しないのもアレなのでちょびっと書きます、
    <要約>
    管理について: 条件付きマップと同じ感じで出来そうと考えてた。
    補足: 批難されまくったがどうしても変えられない部分だった場合の避難所として自主的に使うのを想定
    強硬手段な理由: 相手に対話する姿勢がない場合、過剰な批難が収まることはない、自分の許せるもの以外許さない人から守るには断絶するしかない

    思想の違いの場合、対話してどうにかなるのは相手が少しでもこちらに好意的である場合のみだと私は考えます。そもそも対話する姿勢ではない人、対話できる立場でないプレイヤー等が、行き場のなく解消されることのない不満から「この製作者はゆめ2っきを大切にしていないのではないか?こいつはゆめ2っきの敵なのではないか?」という疑念を抱いて攻撃的になるのは止めようがないです。狭い自己中心的な「ゆめにっきっぽさを求める一般的な日本人プレイヤー」像を他人に強要することを止めるためにはルールとシステムによって強制的に保護するほかないと思います。そうでもしなければ創造的な場は守られない。そういう危機感から発案しました。 -- やさこてん 2025-02-09 (日) 21:17:50
  • 管理についてですが、結果的に袋小路なマップぐらいならば他者の接続の自由さと引き換えに、高難易度条件のマップと同じ感じで出来ないかなと軽く考えていました。現在批難されているようなマップが接続の中心になっていることは少ないからです。 -- やさこてん 2025-02-09 (日) 21:24:32
  • もちろんこの機能は他人に強制するものでは決してなく、もともとは私が将来的にさらにマップを追加するときに設置しようと思ったのを、プレイヤーの不満を捌ききれなくなった(心が折れたともいう)人の避難方法としても使えないかと思いここに投稿した次第でございます。 -- やさこてん 2025-02-09 (日) 21:29:13
  • やさこてんさんが掲げた目的に沿った使い方をするとしたら、プレイヤーは「ゆめにっきっぽくないからゆめ2っきにいるべきでない」と思ったマップを非表示にするんですよね。それってそういう意思表示のより手軽な手段を新たに与えているだけで、何の解決にもなっていないどころか、現状を悪化させてしまうのではないかと心配があります。SNSにこのマップ非表示にしましたって投稿したり、このマップを非表示にできるようにしてって要望がきたり、YNOでいっしょに遊んでたところこのマップ非表示にしてるんだって言われたり。それらは「ゆめにっきっぽくないからゆめ2っきにいるべきでない」って言われるのと何も変わらないと思うんですが違いますか。この機能で拒絶されたツクラーには反論する余地も挽回するチャンスも与えられません。やさこてんさんが言うように一度消したら後戻りできないのですから。これで「ゆめにっきっぽくないからゆめ2っきにいるべきでない」って言われる頻度が下がるとしたら、それはゲームが分断されてただプレイされなくなっただけです。真に創造的な場がどうあるべきか、やさこてんさんにはよく考えてから決断してほしいと願います。
    強制される機能でないなら、私から強く反対する理由は見つかりません。懸念点があるとしたら、強制されない機能だからこそ「なんでこのマップに非表示機能はないの?」って疑問をプレイヤーに生じさせてしまいそうなことです。 -- qxy 2025-02-09 (日) 22:17:54
    • (ちょっと上の文を編集しました)私の言いたいことはだいたい全部言えました。宇和さんが書いてくれた内容は建設的で共感できました。やさこてんさんの抱いている危機感を共有してくれたらこの機能の必要性をもっと理解できそうだと思いました。 -- qxy 2025-02-09 (日) 23:30:07
  • この案に欠陥が多くあることは十分理解しました。もちろん2っきに追加することはありません。
    敵意の総量は変わらないし、嫌になった人が2っきから去るのと大して変わらないだろうと思ったけれども、提案の体で言えてしまうのはより陰湿なのは確かにそうですね。
    危機感と表現しましたがずっと性質は変わっていないので…「気に入らないから猛烈に叩いて追い出す」が繰り返される可能性を消したいだけです。…所詮はインターネットとは言え、他人の思う「ゆめにっきっぽさ」という不明瞭なものを絶対的な基準とし、運が悪ければ猛烈に攻撃されるような、とても強い心の人だけを迎え入れる環境で防御方法が特にないのはちょっと異常なんじゃないかなって…
    決して交わることのないジャンルが「棲み分け」をするように、2っき内でも出来たならばと思っただけです。 -- やさこてん 2025-02-10 (月) 01:37:51
    • やさこてんさんが現状に異議を唱え、議論の場を設けてくださったことに感謝します。防御方法が無いのは私にとっても辛いことです。制作者同士でもっと仲良くなって、お互い支え合えたらいいなと思います。味方が居てくれることが敵意から守る一番の方法だと思います。 -- qxy 2025-02-10 (月) 02:09:36
  • (あっ表題の結論は出たので3日以上ご意見・ご質問がなければ過去ログに送ります。) -- やさこてん 2025-02-10 (月) 02:07:58
  • こんな未熟な案にご意見・ご質問をくださった皆様本当にありがとうございました。
    どこまで引き下がればいいのかのラインみたいなのが明確にあったほうがどうすればより良くなるかの議論も安心して行えるのではないかという方向性の話だったのですが、アイデアがあまりにも役に立たなかった為、私がこの界隈は異常だ!って言って引っ掻き回しただけになったのは凄く申し訳ないと思っています。 -- やさこてん 2025-02-11 (火) 00:05:06

代理実装者の負担軽減のため、マップ提供者へのお願いやルールを追加する案

ナビサエ? (2024-07-27 (土) 01:45:31)

更新時 : 2024-10-12 (土) 21:27:05

(マップを作って送る人=マップ提供者:Associated Developer
送って貰ったマップを実装する人=代理実装者:Core Developer:Proxy)
ゆめにっきっぽいゲームを作るスレ まとめ Wiki = まとめWiki
YumeWiki = 海外Wiki)

この議論は、「代理実装者の負担を減らすことを目的とした、マップ提供者向けのガイドライン・ルールを作成をしたい!」という議論です
まず、ゆめ2っきの制作に関してのルールが見れる場所を確認していきます

現状存在する代理実装のガイドライン情報については個人的なイメージで下の表のような感じです

〇:ある
△:あるけど情報が足りていない
×:ない

まとめWiki海外Wiki
制作に関する
ルールハウツー
代理実装に関する
ルール
×
代理実装に関する
ハウツー
××

マップ提供者の方が、恐らく最初に見つけるのがYumeWikiのhttps://yume.wiki/2kki/Content_Contribution_Guidelines このページです
このページには最低限のガイドラインが書かれています

・海外Wikiの編集には権限が必要な場合があるっぽい
・海外Wikiだとガイドラインの存在に気付くのが難しい
・制作に関するものが複数のWikiにあると管理が大変
という感じの問題があるかなと思ったので~、まとめWikiに英語&日本語でNEWガイドラインを作成し、海外Wikiのほうは、既存のガイドラインを削除してまとめWikiのNEWガイドラインに誘導するような感じにすればいいかなと考えています

現状の代理実装ガイドラインの中身

現状の代理実装ガイドラインの中身

  • 一般ルール
    • 1:代理実装してくれた人のことをproxy(代理実装者)と呼ぶ
    • 2:ろだに素材をアップしたらアクティブなツクラーの方が実装してくれるかもしれない
  • RPGツクール2000で開発してください
  • 表現に関するルール
    • 政治的表現
    • ポルノ表現
    • 宗教的表現
    • 過度に暴力的な表現
    • 他人の著作権を侵害する表現
    • 実際の出来事を連想させる表現(歴史的出来事を除く)
      これらの表現をしてはならない
  • 編集に関するルール
    • 他のツクラーさんのマップを編集したい場合は半年ルールに則って編集をする必要がある(該当マップのツクラーさんが許可している場合は自由に編集しても大丈夫)
    • RPGツクールの機能での戦闘イベントは禁止
    • うろつきのレベルやパラメーターの変化するイベントは禁止
  • 半年ルールに関する説明
    • 作者の更新が半年以上なければ、自由に編集することができる(元の作者の意図を尊重する)
    • 以下のマップは半年ルール関係なく編集不可
      ※以下対象の世界が列挙されている
  • 一般ルールの詳細
    • #1代理実装者はコンテンツをそのまま実装する義務を負わないこと、データが破損するなど、ガイドラインに違反した際は更新をキャンセルすることが出来る
    • #2ろだに素材をアップしても、誰も実装する時間がないという理由で、実装されないこともあります
    • #2マップ提供者は更新のファイルに追加で、settings.txtというファイルを提供しなければならない

このページ↓をたたき台として窯良さんが少しずつ編集していただけています!感謝!
現在私がここに書いていること以外の意見などもまとめて貰えてるのでぜひこちらのページを基準に意見の提案等をお願いします
練習ページ/代理実装における制作ガイドライン案?

ガイドラインへの意見はこの議論の下にある挿入からお願いします


↓議論が長大化して読みにくくなったため、コメント含む古い議論をaccordionでまとめています

古い文章①

NEWガイドラインに書いておきたいことをまとめました

更新履歴

  • settings.txtに追加するもの
  • ルールに追加するもの

+マップツリーのツリー構造はマップID順にシンプルに並べる

+マップ名をテンプレートに沿った形にする

  • 便利スイッチ、便利変数の仕様を理解してもらう
     ⇒世界の移動でリセットされるようなスイッチ、変数には便利変数を使用する
  • お願いに追加するもの
    • できる限り最新バージョンで作業を行う(編集したマップが被った場合はそこの対応まで行う)
       ⇒直近の更新で編集したマップが被った場合、最新の更新内容を取り消さないように気を付ける
  • ハウツーに追加するもの
    +便利スイッチ、便利変数、ピクチャーをどのような用途で使用しているか(なるべく)注釈に書き残す
settings.txtに追加するもの

settings.txtに追加するもの

  • 代理実装者に自身の編集内容およびそれに関して得た許可の情報を全てテキストに記載して伝える
    • 既存マップの編集箇所を全て記載する
    • マップの接続がどの座標に存在するかを記載する
    • 追加・編集した素材があればそれらが追加されたファイルか編集したものか記載する
    • 使用したBGMがどこで再生されるかを記載する
    • SRやメニュータイプなど収集要素の追加があればどこで取得できるかを記載する
    • 他者のマップに関わるものは許可を得たか否かを記載する
  • 代理実装者に自身のマップをどのように扱ってほしいかを全て伝える
    • マップ到達判定を行うべきか否か、到達率に含めるか否か
    • SR分室への曲の登録をしてもよいか否か
ルールに追加するもの

ルールに追加するもの

  • マップ制作に関係するもの
    • マップ提供者にどんな意図があろうと、代理実装者はBGMやSEの音量を調整することができる
    • 世界の移動でリセットされるようなスイッチ、変数には便利変数を使用する
    • ピクチャーは1番から使う
    • ゆめにっきを自分のプレイでエンディングまでプレイする
    • マップツリーのツリー構造はマップID順にシンプルに並べる
    • マップ名をテンプレートに沿った形にする
      この折り畳みの一番下に載せてみます
  • それ以外規約や許可などに関係するもの
    • 素材の使用や接続許可に関する規約はマップ提供者が確認する、連絡が必要な場合で日本語に自信が無い場合は代理実装者を通して連絡を行う
    • 他の方のマップの要素を出さない
    • 初めて参加する際は各マップ、素材の利用規約.txt用のテキストを用意する
    • 素材の利用規約.txt用のテキストには自身の連絡先を1つ以上記載する
    • 関係のないマップのバグを修正しない
    • 通常プレイするだけでは見えない範囲であっても、著作権(ルール)的に問題のある画像や地形などの要素を入れない
    • 工事中看板など、システム的な意味を持つものと誤認するようなグラフィックは実装しない
    • 過去削除されたマップの復元をしない
    • 過去削除されたマップを参考にしない

イメージ/テンプレート

  • MAP0001 <フルネーム> 空マップ
    • MAP0002 <省略した名前> <マップ名> <アルファベット16文字or日本語8文字>
    • MAP0003 <名前> <マップ名>
    • MAP0004 <名前> <マップ名>
    • MAP0005 <名前> <マップ名>
    • MAP0006 <名前> <マップ名>
    • MAP0007 <名前> <マップ名>
    • MAP0008 <名前> <マップ名>
    • MAP0009 <名前> <マップ名>
    • MAP0010 <名前> <マップ名>
  • MAP0011
    • MAP0012 <名前> <マップ名>
    • MAP0013 <名前> <マップ名>
    • MAP0014 <名前> <マップ名>
    • MAP0015 <名前> <マップ名>
    • MAP0016 <名前> <マップ名>
    • MAP0017 <名前> <マップ名>
    • MAP0018 <名前> <マップ名>
    • MAP0019 <名前> <マップ名>
    • MAP0020 <名前> <マップ名>
お願い、ハウツーに追加するもの

お願い、ハウツーに追加するもの

  • お願いとして追加するもの
    • 直近の更新で編集したマップが被った場合、最新の更新内容を取り消さないように気を付ける
    • ファイルの削除や名前変更はパッチでは行うことが出来ないことを知ってもらう
    • SRに使用する画像を用意する
    • 分かりやすいようにシステムアイコンを使用する
    • 効果音の音量バランスを他の既存マップと揃える
    • ティッシュイベントを設置する
    • 便利スイッチ、便利変数、ピクチャーをどのような用途で使用しているか(なるべく)注釈に書き残す
    • 移動イベントにはイベント中動作禁止&解除を入れる
  • ハウツーとして追加するもの
    • 同じイベントを複数設置する場合はイベントの呼び出しを活用する
    • ピクチャー20番以降を使用する場合はシステムとの番号被りに気を付ける

ここでは、こういったルールも付けたい、あの仕様の説明もガイドラインを見せるだけ教えられるようにしておきたい!
などマップ提供者に求めることの意見を出していければ、と考えております

※もう一度まとめる際に、見かけた意見も参考にさせて頂きました、ありがとうございます


  • とても正直に言うと、文面を読んで「そこまでして代理実装を続けなくたっていいじゃないか」と思いました。無理して心折れるの哀しいんだぞ…。
    分かってもらえない・難しいようであれば代理実装を断る・止めることも視野に入れた方がよいと思います。 - kuraud -- 2024-07-27 (土) 04:48:02
    長いので折り畳み

    いくつか練習ページに関連する記述があるのでリンク貼るだけ貼っておきます、ちょっと古いし話題違うかもだけど

    • できる限り最新バージョンで作業を行う(編集したマップが被った場合はそこの対応まで行う)
    • 通常プレイするだけでは見えない範囲であっても、著作権(ルール)的に問題のある画像や地形などの要素を入れない
      • なんかそもそもリレールール表現に関する基本ルール素材投稿ルールを分かってもらえてない気がします
        すでにルールとして触れてる部分なので、ちゃんと制作まとめWiki読んでよねって感じがする
        言っちゃなんだけど、もしマップ提供者がyume.wikiだけ見てこちらを見ていないのだとしたら困って当然だと思う…
        …というかyume.wikiにも「Expressions that infringe the copyrights of others」って書いてあるんじゃん、それってもうルールとかの話じゃなくなーい?
    • 関係のないマップのバグを修正しない
    • スイッチや変数を使用した場合分かりやすい名前を付ける
      • (このWikiのどこかに名前付けてねと書いてあった気がしたけど見当たらないや、気のせいだったかも)
    • 便利スイッチ、便利変数の仕様を理解してもらう
    • 移動イベントにイベント中動作禁止&解除を入れる
    • 同じイベントを複数設置する場合はイベントの呼び出しを活用する
      • 決めたいと思うほどの何かがあったんだろうけども、
        割り当て詳細/各種用途ハウツー的な情報を分かってもらえていないことが本質だと思うので、"ルール"としてこのまま書くのはなんか違う気がする
    • メニュータイプなど、収集要素はどんな人でも取得できるような難易度にする
    • 接続先の世界の雰囲気を壊すような世界の接続を行わない
    • 攻略難易度を考慮する
      • この辺りはボーダーラインが人によってまちまちだし、
        「代理実装者の判断で適宜 改善や変更を求めたり、場合によってはマップ提供を拒否したりするよ」みたいなのを添えてよいと思う (既に添えてあるならごめんね)
        これに限らないけど、代理実装の関係は「実装を頼まれた側と頼んだ側」だと思っているので、頼まれた側(代理実装者)の考えをある程度優先する方が良いと思う
    • SRの開放条件を記載する
    • 使用したBGMと聞ける場所をセットで記載する
    • SRのNo.を記載する(現時点最新版のものでOK)
    • メニュータイプを実装した場合は取得できるMAPを記載する
    • 追加・編集した素材は追加か編集かも分かるように全て記載する
    • 既存マップの編集箇所は全て記載する
      • これ代理実装者への情報伝達の話でもあるし、setting.txtとやらに書いてほしいことリスト内でよさそう
        書き直して並びを少しまとめてみたもの
        • 代理実装者に自身の編集内容およびそれに関して得た許可の情報を全てテキストに記載して伝える
          • 既存マップの編集箇所を全て記載する
          • マップの接続がどの座標に存在するかを記載する
          • 追加・編集した素材があればそれらが追加されたファイルか編集したものか記載する
          • 使用したBGMがどこで再生されるかを記載する
          • SRやメニュータイプなど収集要素の追加があればどこで取得できるかを記載する
          • 他者のマップに関わるものは許可を得たか否かを記載する
        • 代理実装者に自身のマップをどのように扱ってほしいかを全て伝える
          • マップ到達判定を行うべきか否か、到達率に含めるか否か
          • SR分室への曲の登録をしてもよいか否か
    • ありがとうございます!まとめていただきとても助かりました!
      ...代理実装もこれからは無理しない程度に続けられるように気を付けていきます! - ナビサエ
  • このマップは是非2っきに居てもらいたい!って方ですらちょっと2っきのルール把握が怪しかったり、音量が異常にバカでかかったりするので私としては是非進めていただきたいところ。ほぼ手探りで同じような英文を送り続けるのは無駄な負荷ですし…と私は考えます。それはそれとして無理はしないでほしい(代理実装者として全然ちゃんとしてないので言えた立場じゃないが。) -- やさこてん? 2024-07-27 (土) 05:13:31
    • ありがとうございます!実装量を調節しつつ頑張っていきます! - ナビサエ
  • 代理実装の負担軽減というよりも、編集時の負担軽減のための方針なんですが、せっかくの機会なので、こういうルールがあると作業が捗りそうです。代理実装によってマップがたくさん追加されていくと、それだけゲーム全体の把握が難しくなっていくので、これからの管理のコストを下げる意味でも一歩踏み込んでルール化してもらえると嬉しいです。ご検討よろしくお願いします。
    • マップツリーのツリー構造はマップID順にシンプルに並べてもらえると嬉しい。マップの接続関係をツリーで表現しようとしてるのがたまにあるけど目的のマップを探すのが大変
    • 可能ならマップの名前に提供者の名前(略称でも良い)を含めてもらえると助かる -- 2024-07-28 (日) 09:59:29
    • 返事が遅れてしまってすみません!意見ありがとうございます!参考にさせていただきました!どちらも代理実装のルールというか、制作のルールとして提案するのもアリだと思いますね!
  • 提案でもなんでもなく読んだ感想でしかないのですが、・便利スイッチ、便利変数の仕様を理解してもらう、がルールとしての追加欄にあるのなんでだろう……と思ってしまいます (言い出したら便利~系に限らず仕様を理解してほしいものがゴロゴロあるだろうし、そのまま書いていくと極論ブライト博士の禁止リストになっちゃいそう…)
    これ、「便利スイッチ、便利変数、ピクチャーをどのような用途で使用しているか(なるべく)注釈に書き残す」があった方が良さそうかもとふと思いました。 -- kuraud -- 2024-08-16 (金) 21:48:57
    • 再び読んでいただきありがとうございます。仕様を理解してもらうというのはふわっとしすぎていたのでもう少し意図を絞った形にルールを変更させていただきました!新しい意見も追加させていただきました!バグ修正も私が行うことに多かったのでとても助かりますね! - ナビサエ
  • さまざま提案された情報をまとめて、ガイドライン?管理要項?なんと呼べばいいのかわかりませんが、勧奨事項を私がまとめてみたドキュメントを8月中にこちらに載せられればと思っております もう少し時間をください - 窯良 -- 2024-08-16 (金) 22:50:37
    • まとめお疲れ様です!今のところはガイドラインと呼んでいます、こちらも出来るだけまとめられるよう頑張ります! - ナビサエ
  • 別件ですが、Yume wikiサイドのContent Contribution Guidelinesに書いてあった Rules > General > 2番の、「2っきロダにマップデータを上げて、誰かが善意で実装してくれるのを待つ」という内容はこれは廃止したほうがいいと思いますという意見表明をしておきます。丸投げすぎるし、誰も責任が取れません。 - 窯良 -- 2024-09-01 (日) 23:19:54

古い文章②

  • 練習ページ/代理実装における制作ガイドライン案?を作成しました。どうでしょうか?ご意見をいただければと思います… - 窯良 -- 2024-08-30 (金) 20:39:23
    • 初版読んで気になったところ
      1.「デベロッパーに求められる規範意識」と書かれているけど、誰に向けた見出しかが分からない/分かりにくいように感じます (内容的にはAssociated Developer向けの趣を感じる)
      2.「規範意識」の中に「遵守しなければならないルール」が存在していることになんか違和感がある (言わんとする所は分かるので"規範意識"という見出し名が私の中で引っかかっているだけかも)
      3.個人的な感覚としてはナビサエ氏が使っている「ガイドライン」という表現がしっくりくる
      4.「本家をエンディングまで自力でプレイ」って書いてあるけど人によっては攻略見ないことだと思いそう(たぶんない) -- kuraud -- 2024-08-30 (金) 21:15:50
      • 4に対しては「自力で」を「自分に」に修正しておきました - 窯良
  • 練習ページのガイドライン初版を読みました。良くまとまってると思います。1つ疑問があったので、もし良ければ答えてもらえると幸いです。「デバッグについて」に「S[0017]:てるてる天候変更禁止 がONになっているとき、てるてるぼうず長押し動作後メニューが開けなくなるバグがある」というのは具体的にはどういうバグだったんでしょうか。どこに注意すべきバグなのかもう少し分かりやすい文章だとなお良いかなと思いました。 -- 2024-08-30 (金) 21:41:09
    • 追って記載しました→ver0.124h p3で修正されたためなかったことになりました、お騒がせしました。 - 窯良
  • 「SR分室における演出は単一のパノラマ画像以外、原則として認めない」これは 「仕組みが分からないうちは単一パノラマを推奨、希望がある場合は実装者と要相談」ぐらいにとどめたほうが良いかと…というかSR登録代行という仕組みがあるのだから…
    いやしかしマップ提供者→代理実装者→SR登録代行者 でなが~くなる気がするが仲介ぐらいなら無くすべきでもないか… -- やさこてん? 2024-08-31 (土) 00:10:14
  • ここまでいただいた内容をうけて案を修正しました。てるてるぼうずバグについての記載が誤っていたので修正しました。 - 窯良 -- 2024-08-31 (土) 12:55:30
  • お疲れ様です。"デバッグについて"は代理実装に限らずこれから参加するツクラー(違う表現で言えばCore Developer)にとっても助かる記述な気がするので、将来的には「よくある失敗」的な形で独立させ整えてもよいかも、と思いました (今話すことでもない)
    細かいですが、「ティッシュイベントの設置忘れ」「マップ内にティッシュ用のイベントを設置する」は別にやらなくても古い仕様で動くだけなのでバグ・確実に遵守というほどなのかな…?と思いました。…やった方が見栄え良いのは実際そう。
    あと、もし目次を付けるなら「導入部の説明(用語について等)」「代理実装における制作の流れ」「気を付けるべきポイント」のようなグループでまとめてあると良さそうに思います。ただ現状レベル1~3見出し全て使用済みなので難しいかも。 -- kuraud -- 2024-08-31 (土) 21:01:14
    • ありがとうございます~! ティッシュイベントは確かにそうだなと思って細字の奨励程度に下げました。 目次や読みやすさの問題はじっくり調整したいと思います(時々並び替えながら様子を見ています) - 窯良 -- 2024-09-01 (日) 10:01:19
  • ティッシュイベントの話ですが、大きめの迷いやすいマップでティッシュが消えることへの不満を見ることがまれにあったので、広いマップやワープ系の迷う可能性のあるマップは特にマップイベントのティッシュを設置を頑張ってもらいたいかもです。それとたたき台の作成もとても感謝です!いつか作らねばと思っていたのでとてもとてもありがとうございます! -- ナビサエ? 2024-09-01 (日) 18:18:04
    • こちらこそ議論提起ありがとうございます!気になることあったら断りなくとりあえず加筆しちゃってください🤝 ティッシュの件は追記してみました - 窯良 -- 2024-09-01 (日) 21:58:57
  • 延々と編集を続けてて申し訳ありませんでした。全体に推敲して、第2案としてページを更新しました。 - 窯良 -- 2024-09-01 (日) 23:05:16
  • 代理実装に関連して、以下の4種のIDを事前に予約できるようにルールを追加するのはどうかなと思ったのですが、どうでしょうか… いずれも実装時のID変更に合わせて編集するのは少し大変なもののような気がするので、事前にIDを決めておけると日本ツクラーも海外ツクラーも楽かなと思いました - 窯良
  • このルールを追加するとなると、他のツクラーやwiki編集者にも影響を与えると思いますので、もっとしっかりした場所で話し合いをすると良いと思います。地形IDの予約に関して意見を言うと、地形IDで足音を鳴らすCEV0033はゲーム全体への影響が大きいので、あまり更新頻度を高くしないでほしいです。地形IDを増やして足音を増やすのは、その足音を他のツクラーにも使ってほしかったり、多くのマップで利用する場合だけに留めてもらえると良いです。ハウツー/足音#v05da44d にそのマップで好きな足音を鳴らす方法が載っているので、代理実装時にもこの方法を広めてもらえると、ゆめ2っきをずっと長く更新していくのに役立ちます。この方法なら、地形IDの事前予約は不要なので、代理実装の労力軽減にも役立つと思います。 -- 2024-09-02 (月) 22:23:59
    • ご意見ありがとうございます!おっしゃる通り、地形がむやみに増大することで足音CEV(並列実行)の負荷が将来的に問題になることも想像され、頻繁に更新されるべきではないというのもうなづけます。
      4項目をあげましたが、このなかでIDが変わった場合に特に修正編集が大変なのは、戦闘アニメIDとお面IDのように個人的には思います。今度2項目に絞って、別の議論として立ち上げることを考えてみます。(急ぐものではないような気がしました。) - 窯良 -- 2024-09-02 (月) 22:33:46
  • 2000 - VIPRPG@総合制作技術 Wiki* これを見ると、VALUE!+版と英語版でツクール2000の機能が若干違うので、そのことに触れたほうがいいのかもしれません(主にピクチャー番号の制限と注釈の行数制限) -- 2024-09-03 (火) 12:59:30
  • 前者はピクチャー番号51以降は日本語RPG_RTではエラー落ち・EasyRPGでは動く(昔試した)ので51番以降を使わないよう記載した方が良さそう、後者はそれ自体よりもエディターのウィンドウ幅が異なることを書いた方が的確かもしれません。軽く確認した限り日本語版では「1行につき最大56bite程度の横幅、条件分岐の内側であれば各ネストごとに-2biteほど幅が減る」が表示できる範囲の目安になると思います (ツクール豆知識/日英対応表) -- 2024-09-03 (火) 16:36:05
    • 記載追加しておきます、調査ありがとうございました - 窯良 -- 2024-09-03 (火) 20:11:43
  • データをどうやって送ればいいですか?という質問が多い ■ ファイルの命名に関して”author type title or No.” ◇ Urotsuki_chip_01などのようにツクラー名、ファイルの種類(ChipSetかPanoramaかなど)、そのあとにタイトルやファイルの番号を書く形だと判別、利用などがしやすい ■ 動画ファイルを(Movie)を使用しない容量が大きくなりやすいため?現状制作のルールにもなさそう? ■ 音楽ファイルの名前が長すぎるとSR分室での曲名に入りきらない ■ エフェクトの2つ目や、扉部屋の世界などゲーム全体のバランスや印象に直結しやすい要素の提案が多い...一人は確認をしてOKを出したという認識のためCore Developer責任を取ることになりやすい ■ Associated Developerはマップの日本語名を決めることは出来ない ◇ マップの日本語名を書いてくれる方もいるが、翻訳の関係で不自然になマップ名を提案されることが多いため ■ Associated Developerは1度は全てのイベントが問題無く動作するかテストプレイをしてからCore Developerにデータを送る ◇ 環境の違いがあるかもしれませんが、1度試せば絶対に分かるようなバグ(進行不能、暗転したままなど)が残っていることがあるため ■ このあたりのルールに関してもう少し整えてから書いてみようかなと考えております...遅くなるかもしれないのでほかにまとめてくださる方いましたら、先にまとめて書いてしまっても全然大丈夫です -- ナビサエ 2024-09-19 (木) 17:43:48
  • Movieについては、かつて環境によって再生できるかどうかに差異が発生したために「Movieを再生しないパッチ」が作られているのを見かけたことがあります(今はそういった事例が起きない可能性もわりと考えられますが一応)。
    今まで使われていなかった背景に関しては、そもそもMovie自体がプレイを完全に止めてしまう上に他の演出を付けられないので使い所に乏しく、ムービー作ること自体が昔は色々めんどかった、あとは挙げられている通り容量が大きくなりやすいので避けられていた、というような認識を個人的には持っています。
    (このコメント入力欄では改行が無効化されるけど、入力欄の下にある改行ボタンを押すと改行の命令が挿入されます。ちょっとややこしい…) -- kuraud -- 2024-09-19 (木) 21:12:04

古い文章③

  • ナビサエ氏、kuraud氏のコメントを踏まえて、第3案としてまとめてみました 練習ページ/代理実装における制作ガイドライン案?
    だいぶとっ散らかってきたので、整理すべきポイントがあったら教えていただけるとありがたいです - 窯良 -- 2024-09-22 (日) 17:40:13
    • もし内容にあんまり加えることがないかも…という雰囲気になってきたら、10月中に英語に一度訳してみて、一部の海外ツクラー方に見てもらって補足事項がないか確認してみようと思っています。 - 窯良 -- 2024-09-23 (月) 01:53:50
  • やや別件ではあるのですが一旦ここで…、練習ページ/代理実装/プロキシ担当リスト?ページ内の「プロキシ」のところを「代理実装担当リスト」「現(旧)代理実装者」と書いた方が日本語での通りが良いかな…と思いました。ただこれ私自身が"プロキシ"呼びに馴染みがないだけかも… -- kuraud -- 2024-09-23 (月) 02:28:42
    • 直してみました - 窯良 -- 2024-09-23 (月) 14:52:41
  • ガイドライン第3案を読みました。そろそろ新しい項目の追加も減ってきたと思うので、読みやすさの調整があるともっと良くなりそうに思いました。
    例えば、「RPG_RT.ldbをProxyに渡す」という内容は、「Proxyとの協調性」「Associated Developerの基本的な制作の流れ」「Proxyに対するデータの送り方」の3つの項目に書いてあるのが気になります。ガイドラインということなので、Associated Developerの制作の流れに沿って分類を整理するともっと読みやすいのかなと思いました。Associated Developerがデータを送るときはここだけ読んでおけばよい、マップを作るときはここだけ、みないな感じで実際の制作のときにガイドラインの一項目だけを読んで利用できる形を目指すのはどうでしょうか。実際に取り組んでみると難しいと思いますので、その場合はこのコメントの内容は聞き流してもらって大丈夫です。 - qxy -- 2024-09-28 (土) 01:36:21
    • お疲れ様です。各項目の内容を少し整理してみました(一部、移項したものもあります。) - 窯良 -- 2024-09-30 (月) 14:17:26
  • ガイドライン中の「ゆめにっき (Yume Nikki) をエンディングまで自分でプレイしておく。」現状これはルールではないとしていますが、証明はしなくていいですが、絶対に守るべきルールであってもいいのかなと思いました。制作のルールにはありませんが、そもそもゆめにっきを知っていないとゆめ2っきに辿り付くことはほとんどないでしょうから、ほとんどの人にとっては当たり前ではあるとは思うのですが...個人的には最近のゆめにっき派生界隈の雰囲気としてそういったこと(派生はプレイしたことがあるけど、ゆめにっきはほとんどプレイしたことがない)が起こるのもあり得ない話ではないなと感じています... -- ナビサエ 2024-10-08 (火) 23:55:06
    • 大事なことだと思います、ご意見ありがとうございます すごく悩みながらではあるのですが、重要なルールと規範意識のところに試しで成文してみました。こうしたほうがいいかも、ということがあればどなたかご意見いただけますと幸いです。 - 窯良 -- 2024-10-10 (木) 12:00:18
    • プレイの深さの指標として「エンディングまで」はひとつの目安たりえるかもしれませんが、酷い話、RTA向けのチャートやバグを利用してさっさとエンディングを見てしまっても…となると本末転倒なので、「~~まで」と言うのではなく「しっかりとプレイしてもらう」ことを重視した伝え方が良いのかも…と思いました。もちろん、そういったニュアンスを伝えるのは難しいので参考程度に思ってもらえれば…。 - kuraud -- 2024-10-11 (金) 21:28:51
  • 今日のバージョンで一度英語に訳してみました。練習ページ/代理実装における制作ガイドライン案/English? 一部の海外ツクラーにDiscordを通してプライベートに見てもらいつつ、英語に不自然な点がないか、盛り込むべきことがないか少し聞いてみます。 - 窯良 -- 2024-10-11 (金) 21:13:49
  • kuraud氏に10/11にご指摘いただいた内容を、うまい言及のしかたかどうかわかりませんが重要なルールの部分に説明として書いてみました。
    ...2ヶ月弱かかりましたが、内容はおおむねまとまってきたように感じます。一週間程度置いて特に大きな変更がなければ、ガイドライン案を実際に使う方向に(R4Rなどで?)決めていけたらいいかなと思います。 - 窯良 -- 2024-10-13 (日) 14:37:34
  • 書こう書こうと思って忘れてた、ページの最初の方で「随時記載が追加される」と書かれているけど翻訳の工程が挟まる事もあると思うので、何か文字色などで「ここはまだEnglish側への翻訳がされてないよ」と分かると翻訳漏れを防ぎやすいのかなーと思いました。(楽しむwikiのバッジ攻略ページ見てて思ったやつ) - kuraud -- 2024-10-13 (日) 21:08:24
    • 良いと思います、とりあえず日本語版ページのほうに「新規に追加した未翻訳の内容は文字色を赤くしておいてね」ということを一番上に書いてみました。 - 窯良 -- 2024-10-13 (日) 21:21:41

古い文章④

  • さまざまな方からいただいた意見をもとに案を修正して、第5案を作成しました(日本語・英語ともに更新済み)。練習ページ/代理実装における制作ガイドライン案?
    まとまっている内容について何か意見がありましたら教えて下さい。 -- 窯良 -- 2024-11-04 (月) 17:14:37

【記載内容がこれでいいのか悩んでいるポイント】

  1. Lysenthe氏よりガイドライン案の内容に質問があり、こちらに提起します。
    練習ページ/代理実装における制作ガイドライン案#f06f52cf? 削除されたマップの内容から派生した新しい作品を(半サルベージ的に)作りたいという意思がLysenthe氏にあるようで、オリジナルのツクラーに連絡がとれないときはどうしたらいいのか記載を明確にしてほしいという希望がありました。
    希望をうけて、いくつか項目を追記してみたのですがどうでしょうか。サルベージを実行するときの立ち回りについて統一的な見解を載せるのは少し難しいとも感じており、現状の記載になっています。 - 窯良 -- 2024-10-28 (月) 12:49:46
  2. また、もう一点確認したく…。
    クリエイティブ・コモンズ・ライセンス下で公開されていた素材の利用については、以下のように記載したのですが大丈夫でしょうか?問題点があればどなたかご指摘ください。
    * CC0の素材は無条件で使用可能。
    * CC-BY(表示)およびCC-BY-NC(表示-非営利)の素材は、copyright.txtに出典を記載しなければならない。
    * ND(改変禁止)、あるいはSA(継承)のCCライセンスで公開されている素材は、ゆめ2っきで使用することはできない。 -- 窯良 -- 2024-10-31 (木) 11:23:40
  • 11/21までに特にコメントなければこの2点については現状ままで進めます - 窯良 -- 2024-11-15 (金) 11:41:25
  • 削除されたマップのサルベージ的実装をする時には一度実装したいと言ってるAssociated Developerさんの考えを知りたいと思ってしまいます(消されたマップを復活させてみんなに行ってもらいたい!のような単純な理由であれば断りたい)、実装をしてもらう前にはProxyにサルベージをしたマップを実装する意味や許可などの考えや情報を全て伝える必要があったほうがいいかな?と思いました -- ナビサエ 2024-11-16 (土) 13:02:26
    • ありがとうございます!練習ページ/代理実装における制作ガイドライン案#f06f52cf? ナビサエさんのコメントをもとに記載を追加してみました(赤字部分) 補足があればどなたでもご意見ください -- 窯良 -- 2024-11-16 (土) 20:24:50
  • 以降特にご意見なかったので上記1.2.についてはとりあえず現状ままで行こうと思います。
    本日、案の内容を読み直して、「代理実装を円滑に行うために一定のルールや敷居を用意する」という目的を超えて記述が厳しすぎると感じた内容をいくつか削除(コメントアウト)しました。コアデベロッパーが守る必要があると明文化されていないのに、代理実装経由のデベロッパーが遵守しなければならない内容が厳しすぎると不公平感が強くなってしまうということを懸念しての変更です。 -- 窯良 -- 2024-12-11 (水) 15:31:14

【ガイドライン取り扱いについての提案】

  • 今後このガイドラインを実際に使うことがあれば、R4Rで承認して決定事項にするというよりは、決定事項よりは緩く(R4Rをあえて通さず)、代理実装の実態にあわせて柔軟に内容を変えながら運用するほうがよいなと感じています。案を作るにあたっても様々な意見をいろいろな方からいただき、今後も各人がぽつぽつと気づいたことが現れると思いましたので…。
    また、11月中に大きな反対意見がなく、細かい修正が進んだら実用してみてもいいのかもしれません。
    ガイドラインが運用された際には、ガイドラインのページにコメント欄(Zawazawaのスレッド)を設置して、変更点や改善点の提案をそのコメント欄でツクラーができるようにする形もありなのかな、とも考えています。
    今日時点で考えていたことをこちらに共有いたしました。 -- 窯良 -- 2024-11-05 (火) 22:46:57
    • ガイドライン編集のための約束?を試しに作成してみました。R4Rの仕組みを参考にしつつ、もっと短期にルールをまとめています。また、ルールというほどかたいものでもないような気がして「約束」という言葉を選んでしまいました。
      ガイドライン編集の提案をどこで行うこととするべきか悩んでいます - 新しくZawazawaスレッドを立てるより、他のツクラーも話題を確認しやすい、という意味ではやはり議論ページか、本スレ/避難所のほうがよいのでしょうか? -- 窯良 -- 2024-11-11 (月) 13:54:26
  • 個人的な感覚として、議論ページは「どの議論に新たな書き込みがあったのか把握しづらい」「最新~件表示などの機能がない」のが弱点だなぁと感じているので、これからも使うことを前提にしつつWikiのコメントフォームを選ぶならWIKI編集連絡所のように専用のコメントログを用意する形になると話を追いやすそうだと思います
    一方、ZAWAZAWAトピックとして立てると他者による話のまとめ(古い議論をaccordionでまとめる等)は行いにくくなりますが、本人確認がしやすいのが旨味かなと感じています
    ただ、広く周知させつつ話を進める…という狙いを重視するならやはり制作スレが一番なのかなーとも……
    ……全部プッシュするような意見になってしまった、すみません - kuraud -- 2024-11-11 (月) 21:07:50
    • ありがとうございます!本人確認をしやすいという点ではトリップのつけられる本スレやzawazawaスレッドが有用だなと確かに思いました。
      本スレや避難所に書き込むのはツクラー各位にとって少し心理的にハードルが高い(気軽でない)のかなと思うこともありますが、話題の周知という意味では本スレ等の場所がいいのかもしれませんね… 話題の周知というか、提案に気づいてもらうという点では、zawazawaスレッドであってもwiki側でnewタグを使用して発言に他ツクラ―が気づきやすくする!という工夫もできそうだと思いましたが、そもそもzawazawaスレッドの更新にnewタグのようなものって反応させられるんでしょうか…?(無理かもしれないですね)
      私もまとまっておらずすみません。 -- 窯良 -- 2024-11-12 (火) 09:15:20
    • 特定トピックのみに反応するNew!が出せれば地味に便利なんですが、現状無いっぽいですね…。(サービス運営元に機能リクエストして実装されるのを期待する、という手もなくはないです)
      複数のトピックがある例としては、ゆめ2っきを楽しむWikiのメニュー内"ZAWAZAWA"欄のような形で表示する感じになります。このwikiのメニュー内"避難所"部分も形式としては同じなのですが、特定トピックのみに限定するオプションは無いみたいです。 - kuraud -- 2024-11-12 (火) 21:27:35
    • 貴重な情報をありがとうございます!zrecentの仕様を確認してみましたが、避難所の他にあと1スレッドだけ存在するような状態ではMenuBarにzrecentを載せるにも見た目のバランスや更新頻度的には不格好になってしまいそうですね…。
      でもzrecentではタグを指定できるようで、もしかすると避難所は避難所のみ、ガイドライン編集はそれのみで分けてzrecentの表示を行うこともできるのかもしれない?とも思いました。試してみる価値がありそうです - 窯良 -- 2024-11-13 (水) 11:44:58
    • 本当だ、タグ機能そこでも使えるんですね…。他所で試したところ「指定したタグが付いてるトピックだけ表示」という動作のようなので狙い通り使えそう。今回の件以外でも役立つと思うので避難所にタグを付けておこうと思います。 - kuraud -- 2024-11-13 (水) 22:39:17
    • 練習ページ#MenuProxyで試してみましたが、Zawazawaから新しいスレッドを立てて、避難所とは別のものとしてMenuBarにスレッドの更新履歴を表示することができそうです。5chより海外の方にとって書き込みやすく、wikiコメント欄よりは本人確認がしやすいため、zawazawaスレッドを採用する方向で考えてみたいと思います。
      海外ツクラーさんがコメントを書き込みたいけれど、Zawazawa側のデフォルトの国制限の影響で書き込めないということがもし起こった場合は、別の手段で代理実装担当の日本のツクラーさんにお話していただいて、間接的に意見表明を行っていただくように誘導の文章をあわせて掲載するのも良いかなと考えています。 - 窯良 -- 2024-11-15 (金) 11:40:46
  • 試しに練習ページ/MenuBar?でzawazawaスレッドを使った表示方法を検討してみています どうでしょうか - 窯良 -- 2024-11-15 (金) 23:27:30
    • Zawazawaスレッドを使う方針として、練習ページ/MenuBar?ガイドライン編集のための約束?の内容を作ってみました。
      なにかご意見がございましたらひとまずクリスマス頃までにご連絡ください。 -- 窯良 -- 2024-12-11 (水) 15:46:24
  • 初版を代理実装/代理実装における制作ガイドラインとして公開しました。ガイドライン作成にご協力いただいたみなさま、そしてこの議論でのガイドライン作成を快く受け入れていただいたナビサエ氏、改めてありがとうございました。
    2025年1月1日から運用されるものとして扱おうかなと思うので、運用前に何かあれば年内にご連絡ください。 -- 窯良 -- 2024-12-25 (水) 22:23:00
    • なお、Yume.wiki側のコンテンツ提供ガイドページは、yugamineena氏にページ内容の刷新を依頼しています。こちらも年明けには更新を済ませる予定です。 -- 窯良 -- 2024-12-25 (水) 22:29:10
    • 上記Yumewikiページをアップデートしてもらいました。 - 窯良 -- 2024-12-31 (火) 23:50:37
  • 本日より運用開始してみます。お気づきの点がありましたら避難所ガイドライン編集相談所などでご連絡ください。
    この議論ページでこれ以上何もなさそうであれば今月中に過去ログへ議論を移します - 窯良 -- 2025-01-01 (水) 13:58:24
  • 移動しました。- 窯良 2025-01-30

R4R「新エフェクトの実装について」の発議について(推敲・意見募集)

Ca? (2015-02-20 (金) 23:59:34)

R4R「新エフェクトの実装について」
このルール発議を行おうと考えています。
何か意見ありましたらお気軽にどうぞ。推敲も募集していますー

r4ra.txtの転記 (元文書更新日時 2015/02/19)
(Revすりー)
R4Rによる発議を行います。

タイトル 新エフェクトの実装について

・新エフェクトの正式実装は、正式実装をスレに告知した上で
  告知後一ヶ月の間、参加歴半年以上の制作者二名以上の反対意見、慎重意見が無いことを条件とする。
・二名以下の反対意見、慎重意見に収まった場合も、制作者はその意見に耳を傾けること。

・正式実装を宣言する際は必ずデバッグ用の試験実装を行わなければならない。
・正式実装は、試験実装と全く同じものでなければならない。(バグ修正は例外とする)
・グラフィック/挙動を変更する場合は、試験実装に変更を適用した上で再度正式実装の告知を行い、意見を待つこと。

(期間設定は発議時の制作ペースに合わせたものです。
  過疎、過密が進行した場合はそれに合わせて変更してください。)

エフェクトはEDにも関わるゆめ2っきの主軸なので、
  実装には慎重な判断が必要ではないかと考え発議しました。
決定は一ヶ月後(2015/99/99)になります。

  • 10年近く放置されてしまった議論のため、いったん過去ログに移動しました。 -- 窯良 2024-12-15 (日) 20:43:00

旧バージョンで作ったマップのイベントを最新バージョンに持って行く為の空っぽのマップを置いてみたい

黒九 (2024-10-26 (土) 21:29:58)

旧バージョンのマップのイベントを元のマップを上書きせずにイベントだけを最新バージョンに持って行く為の空のマップを置いてみたいです。
やる事自体は無くても出来る事ですが事故防止と説明を付ける事で出来る事が分かりやすくなれば良いかなという考えです。


  • 各個人のマップ割り当て領域のうち空いているものをこのような移行作業のためには使えばよいのではないかと考えており、全ツクラー共有として空きマップを用意することには積極的には賛成しません。
    一方で、最近の更新ではマップに対する編集内容が以前のものに差し戻されてしまう事故がたしかに散見されます。
    既存マップの編集に関しては、パッチ作成前にchangelogを検索し、最近の編集を見落とすことがないように各人で徹底するように、あらためて周知するのが良いかなと考えていました。 - 窯良 -- 2024-10-28 (月) 12:44:38
  • 分かりました。個人の割り当て内で試作してみてきっかけがあったら更新して個人の割り当て内のまま表に出すか出さないかぐらいでやって見ようと思います。 -- 黒九 2024-10-28 (月) 17:26:11

砂糖道(MAP1184)の公衆電話が便利すぎるために、なんらかの調整をする案

2i9? (2024-05-25 (土) 19:36:42)

今までゲーム内容についての直接的な相談がここでなされていなかったですが、
先日避難所でゲーム内容についての相談が行われた件がありましたので、前々から自分で悩んでいたこちらの相談を投稿します。

私が実装した楽しむwiki名: 砂糖道(MAP1184) が、様々な世界に接続していてあまりにも便利すぎるので、
公衆電話(CEV0296: 【呼】即席ショトカ)の、好きな世界との接続を一つだけ選べる、というコンセプトが成立していないという悩みがあります。
そこで、なんらかの調整を行いたいです。

現在は、以下のような編集を行いたいと考えていますが、これについて、多くのプレイヤーが目にするマップであるため、確認の意を込めて意見を募集したいです。

  • MAP1184に接続したすべてのマップの実装者に直接許可を貰った上で、うろつき邸に砂糖道へ接続するショートカットを作成する。許可が降りなかったマップについては、マップ実装者との相談で別の場所に接続を移動させる。
  • MAP1184から公衆電話を削除する。
  • 高級お面屋は、夢銀行に10万夢以上預金し、かつゆきひつじ氏のお面屋で最大まで割引された状態にて、夢銀行とうろつき邸から接続されるマップへと変更する。砂糖道と高級お面屋間の旧来の接続は削除する。
  • 影絵からお面屋まで移動する際の歩行距離を少なくするよう、マップをわずかに改変する。
2024/05/27 23:20 以前の案
  • MAP1184に接続したすべてのマップの実装者に直接許可を貰った上で、うろつき邸に砂糖道へ接続するショートカットを作成する。許可が降りなかったマップについては、マップ実装者との相談で別の場所に接続を移動させる。
  • 高級お面屋は、マップ接続のコンセプト上お面を引き継げないような場所でもお面を楽しむための手段として再設定し、砂糖道から接続を移動させる。扉部屋でお面の姿に変身したい場合は通常のお面屋を使用していただくようにする。
2024/05/25 23:20 以前の案
  • 現行のMAP1184を2つに分割し、それぞれ接続5つと工事中看板が1つずつのマップとして作成しなおす。(※この編集については、各マップの実装者に直接許可を貰った上で行います。他のツクラーさんの意見によっては、操作を実装できない可能性がある。)
  • 以下のように分割する。
    (砂糖道A:繁栄巣、繋皆大成、グラフィティー街、荒野、ヒラヤマ)
    (砂糖道B:ephemera、石煉瓦遺跡、彫刻庭園、樹海、スタッチュ)
  • 高級お面屋を別のマップへ移動させる。このマップは他と比べて利便性が高いので、別個公衆電話を作成するか、別の公衆電話のあるマップの近くへ移動させる。

また、現状の砂糖道にはマップが曲がりくねっていて歩きづらい、という問題もありますので、こちらは透明な壁部分の通行設定を変更してより広範囲を歩けるようにする、道が極端に細い部分について少し太くして歩きやすくする、マップの広さを変更する、などの方向で調整したいです。


  • 編集への賛否、特に分割の是非についても確認しておきたいです。接続の量を鑑みると多くのプレイヤー・ツクラーさんに影響を及ぼす編集箇所になると思いますので、強く反対する意見が非常に多い場合はこれを撤回します。 -- 2i9? 2024-05-25 (土) 20:10:51
  • プレイヤーとしてこうなったらいいなというものですが、うろつき邸に新しい部屋を作りそこに砂糖道の公衆電話と置き換わるような形で虫羽オブジェを置くとかどうでしょう。これだと公衆電話はフリーになるしよく砂糖道を利用していた人も不便になったと感じることはほぼ無いんじゃないかな?と少なくとも私は思います。曲がりくねっていて歩きずらいというのは人によっては面倒に感じることかもしれませんが、個人的には木なども異常にまがりくねったり、不思議な生物、謎のオブジェも多くあるため逆にその曲がりくねった歩きずらさも、その不思議な世界の雰囲気にあっていてとても良いなと感じております -- 2024-05-25 (土) 20:46:22
  • また、高級お面屋を分離して新たに高級お面屋用の公衆電話を追加したり、別の公衆電話のある世界の近くに移動したりすれば結局砂糖道と同じ事(便利すぎて電話先を変えられない)になりかねないのでは?という感じがします -- 2024-05-25 (土) 20:51:02
  • わかりました。砂糖道は「ある程度扉部屋からの深さのある繋ぎ部屋」というコンセプトで作成し、それを実現するために公衆電話を活用してみたのですが、ここまで肥大化したらそうは言ってられないですよね………上記の私の意見をすべて撤回すべきと思うほどにはかなり良いアイデアだと思いましたが、いくつか調整したい点がありますので、別の施策で考えてみました。提案を更新しましたので、確認お願いします。-- 2i9? 2024-05-25 (土) 23:20:22
  • ただ、一点確認しておきたいこととして、もしかして高級お面屋はほかのすべての公衆電話による移動先と比較しても、明らかに便利なのでしょうか。扉部屋から通常のお面屋までの距離が微妙に遠いなと思い、ある程度慣れているプレイヤーがゆめ2っきオンラインやお面を楽しみたいような場面で活用することを想定して作成したマップなのですが、ここに公衆電話を配置すること自体に異議が出ることは正直想定していなかったです……… -- 2i9? 2024-05-25 (土) 23:38:00
  • 個人的な友人とも相談してみました。もし砂糖道の他の接続に比較して、高級お面屋の存在が有意に便利なら、高級お面屋だけを公衆電話に関係ない場所へと移籍することでなんとかなるかもしれません。そのあたり、どうでしょうか? -- 2i9? 2024-05-26 (日) 10:03:54
  • 少ないとは思いますが、お面でのさんぽをよくする方にとってはとても有用な場所になるかと思われます。それにお面屋に行こう!というときに高級お面屋に行く、という姿をよく見る気がします。(旗が立っていて分かりやすい、実質無料で利用できる、世界が見やすいなどの理由があるかも)(つい最近まで影絵で迷うことが多く、結局通常のお面屋への行き方分からない人だったので高級お面屋にはよくお世話になっていました)それか影絵のほうに案内の旗や看板を設置するという方法もありかも?(影絵側のお面屋を選択しやすくする。砂糖道と違いどこでも歩けるうえ地形の特徴がつかみづらいため迷いやすい、なのでお面屋の入り口に高級お面屋と同じ旗を立てて特徴をつける、赤街灯から来ると右矢印のお面屋への案内看板、右に進むとこの上に進むとお面屋があります!みたいな上矢印の案内看板を設置するなど...) -- 2024-05-26 (日) 15:15:27
  • なるほど、ありがとうございます!では、もし高級お面屋と砂糖道の接続解除だけを行い、砂糖道の公衆電話や周辺の接続は今まで通り変えないままにするような編集を行ったとしても、公衆電話のシステムをより良いものにできるでしょうか。もしこれでも問題ないのなら、既存の接続箇所の編集や必要な許諾が要らなくなりますし、より変更点の少ない更新にできるので、嬉しいです。高級お面屋の扱いについてはこれから考えるとして、一旦これを確認しておきたいです。 -- 2i9? 2024-05-26 (日) 16:55:18
  • もし砂糖道への公衆電話の設置を続けたいのであれば、砂糖道が一強になるのは避けられないものとなると思います。高級お面屋の存在はあくまで砂糖道の価値のひとつであり、高級お面屋のためだけに砂糖道にショトカを置いているという人は少ないでしょう。砂糖道から電話を変えられない、変えたくない理由は接続の多さが1番大きなところでしょう、さらにそこから繋がる世界の魅力が非常に高い、しかもそんな世界がとても多い、さらにはお面で移動することが出来る、しかもその先の世界目的ではなくお面目的だとしてもお面屋より高級お面屋を利用したほうが便利になってしまっていることが原因でしょう。そもそもHUB世界として作った場所にショートカットの公衆電話を設置すれば、公衆電話を占有してしまうことになる可能性が高いことはしょうがないことといえます。 -- 2024-05-27 (月) 13:06:22
  • 公衆電話で砂糖道以外を選んでもらえるようにするための方法であれば・公衆電話ではなくうろつき邸から接続するようにしてしまう・砂糖道の利便性を下げ、電話として設定する価値を他の公衆電話のある世界と同じくらいになるように調整する。という2つの案から選べるはずです。砂糖道自体の利便性を下げてしまえば、不満が出てくることは避けられないでしょうね...私の考える処置をまとめますと・《うろつき邸》の新たな部屋に公衆電話と置き換わる形で移動オブジェを設置する(砂糖道への到達で解放など条件を付ける)・公衆電話での《砂糖道》⇔《うろつき邸》というルートを削除する。という感じです。後は高級お面屋をあくまでお面屋の分店として"高級"と付いているのですから、お面になるときには影絵側のお面屋の2倍くらいの料金がかかるようになってもいいんじゃないかな?というのも提案しておきます(利用回数で割引とかしてもいいかも)(影絵側のお面屋を尊重する的な)(後からマップ名が付いたのかもしれませんが) -- 2024-05-27 (月) 13:55:08
  • わかりました。高級お面屋と砂糖道の接続削除、砂糖道の公衆電話の代替としてうろつき邸接続 を両軸で進めていくような更新を実行しようと思います。ゆきひつじ氏のお面屋の利用頻度を高めるような施策も考えたのですが、自分のマップ自体にはこれ以上手を加えたくなかった(料金倍化などの策はやりたくない)ので、このようになりました。議論部分の案を最終段階のものとして更新しましたので、確認お願いします。 -- 2i9? 2024-05-27 (月) 16:14:40
  • この条件であれば、私は異論ありません。本当に調整お疲れ様です -- 2024-05-27 (月) 20:31:07

ツクラーによる割り当ての予約対象に、戦闘アニメIDとお面用変身No.を追加する案

窯良 (2024-09-03 (火) 20:47:16)

お疲れ様です。

決定事項制作ルールにおける、「割り当て」「予約領域」の用語が指す範囲に、次の2種を新たに含めることを提案します。

  • 戦闘アニメID
  • 変身No. (V[3930]で指定される値, お面用)

戦闘アニメIDに関しては、手元のプロジェクトで制作したものを実際に最新版に移行する際にIDがずれてしまうと、
各MAPやコモンイベントでのID設定を手作業で変更する必要があります。
これがどちらかというと操作が煩雑な作業であることを鑑み、今回の提案を行いました。

  • 戦闘アニメのID予約は、1個ずつ、あるいは数個まとめてなど、
    ツクラーごとの裁量で若めの番号からひとつずつ予約することを許可するのはどうでしょうか。

変身No.についても同様に、走者としてパッチを作成する際にIDを変更するとなると、
編集箇所が複数のコモンイベントやマップイベントに及ぶためやや大変な状態です。

現在は、000xxx番台がお面屋関連、500000付近のものがその他のお面・変身という暗黙の了解で
番号が各ツクラーによって選ばれている状況ですが、50万番台では良くも悪くも番号が飛び飛びになっている事態を招いています。

現状の使用状況を鑑みると、変身No.の予約について以下のようなルールを提案します。

  • 000001番~100000番は、お面屋 あるいは CEV0288:【呼】スッピンお面購入 が初めての実装場所になるお面のために用いるものとする。
    • 000138番以降を、1つずつ若い番号から予約する。
  • 100001番~999999番は、それ以外の用途のために用いるものとする。
    • こちらは、番号の予約範囲を10ずつ指定する。
    • 下2ケタが01から10、51から60という風に10刻みで予約する。(たとえば「500501~500510を予約します」など)
  • いずれも、他のツクラーの迷惑にならない範囲であれば数枠(数個)連続で予約してもかまわないものとする。

ルールとしてこれが受け入れられるのであれば、wikiの割り当てページに新しく両者の表を用意して、
マップ予約やチップセット予約などと同じように、予約状況の情報が共有できる形にできればいいなと思っています。

R4Rに上げる前に、議論ページである程度アイデアが整えられれば嬉しいなと思います。何かご意見があればよろしくお願いします。


  • 提案者が窯良氏ということで、まずは下記の代理実装に関しての話題に集中した方が周囲も話を把握しやすいのではないでしょうか。枝葉のように出てきたことは分かりますが、周りが意見を言うにも1つ1つ背景を把握せねばなりません。
    ……と書いておいてなんですが。戦闘アニメは現状予約が必要なほど頻繁に増えているのだろうか?という疑問があります。
    また、変身No.を10刻みで予約する案は余らせる人が多く出るような予感がします。現状でも1つ2つのお面で済んでいる方がそこそこ居るので、お面屋などの用途ごとに番地を大まかに区切るだけで十分かと思います。(変身No.についてはデータ/お面があるのでそちらで良いと思います、必要ならページ名変更してもよいかと) - kuraud -- 2024-09-03 (火) 21:00:25
    • あちこちに話題が飛んでいて申し訳ありません。
      戦闘アニメに関しては、ver0.121以降から今日までの1年間で11人のツクラーさんが演出を追加している状況でした。
      単純計算で約1ヶ月に1人追加している状況で、アニメが連番になるようにIDを走者が調整するというのが大変とみるかそうでもないとみるかは、人それぞれかもしれません。でも、解決可能な負担であるように少なくとも私には見えました。
      お面に関しては番号に十分余裕があるので、余ることには何の問題もないと思います。番地を大まかに区切るという場合は、そういった目安を何か提案したほうがよいかもしれません。 - 窯良 -- 2024-09-03 (火) 21:20:14
  • (追加の頻度なども鑑みるに)余らせる人が多いだろうし戦闘アニメの話と同じく詰めていいんじゃない?と思うところなのでした。目安自体も言ってしまえば既存の範囲の話そのままなので提案というのはちょっと私の意見からは外れていきますね…。 - kuraud -- 2024-09-03 (火) 21:35:52
  • 予約のルールを増やすことは予約の宣言やwikiでの管理など作業負担が増加する面もあると思います。
    ルールを追加せずになんとかする方法として、使いたいIDを予めダミーデータで埋めておくというのはどうでしょうか。実際に私はお面の499901~499930をダミーデータで埋めています。多くの人がダミーデータで埋めていくとそれはそれで問題が生じるので、個々のツクラーの良識に頼った方法になってしまいますが。IDを固定することが合理的なものだけダミーデータで埋めるようにして、そうでないものは更新時に気軽に追加する感じでも十分事足りるのではないかなと思います。 - qxy -- 2024-09-03 (火) 23:32:11
  • ありがとうございます。ダミーデータによる疑似的な予約は有効そうに見えます、そしてwiki編集や宣言が煩雑にならないのもよいところですね。今回の提案は、下の代理実装関連の負担となっているポイントのひとつを解消できないかというところに一端がありましたので、代理実装者だと日頃の更新で未来更新のためのダミーデータも気軽に挿入できそうですし、良さそうですね。
    ゲームデータへのダミー追加に加えて、changelogにダミーデータのID(No.)程度は記載するようにしていただくと、後続の開発者が編集の意図を理解しやすくなるのでそれは奨励したほうがいいのかもしれません。
    ルール未満の慣習レベルの立ち位置のやり方でツクラ―のみなさんにこのまま許していただけそうであれば、疑似的な予約をしたい方向けにダミーデータを利用して頂く方式がよさそうだと今日思いました。 - 窯良 -- 2024-09-04 (水) 14:44:37
  • 現状のお面のコモンイベント(CEV0274)はお面ID順に並んでいないので、ゲームデータだけ見てもどのIDが空いているのか分かりにくかったです。ダミーデータで埋める場合にこれでは少し困りそうです。次の私の更新までに直ってなさそうだったら、ID順に並べて、ID順に並べてねという旨をコモンイベントの見やすいところに注釈として残しておこうと思います。 - qxy -- 2024-09-05 (木) 22:51:21
    • CEV0274の順番をver0.125で整理しておきました - 窯良 -- 2024-09-08 (日) 22:32:27
  • 戦闘アニメと変身No.に対しては、あくまでルール未満の便宜上ではありますがダミーデータ挿入による疑似的な予約を行う方式をとってもよいこととして、この議論をクローズしたいと思います ありがとうございました!
    何も補足がなければ、9月18日に議論過去ログに移動します。 - 窯良 -- 2024-09-12 (木) 11:41:40

(R4R撤回) Lemniscate氏マップの利用規約について

窯良? (2024-08-18 (日) 21:05:05)

各マップ、素材の利用規約.txtより

・Lemniscate氏
 
【マップの編集可否】
全マップ改変自由ですが、マップ接続の際は必ずLemniscate氏本人に連絡して下さい。
 
【各素材の利用可否】
氏が作成した素材に関しては、自由に使用して頂いて構いません。
 
【その他】
 

上記の記載についてなのですが、
2022年夏にLemniscate氏がゆめ2っきコミュニティを完全に離れており、インターネットを通して氏に連絡を取ることができない状態です。
当時、トラブルを事由に英語圏のコミュニティからBAN処理を受けており、2年経過しておりますが今後も氏の復帰は考えにくいと思われます。

なお、本スレッド20部屋目 229番レスでは、Lemniscate氏の代理実装を引き受けていた2i9氏も今後の氏のマップの実装はしないとお断りされております。

上記の理由を踏まえて、Lemniscate氏のマップの編集可否について、
『マップ接続の際は必ずLemniscate氏本人に連絡して下さい。』という部分を削除し、
通常の半年ルールの適応となるように変更することが望ましいのではないかと考えたのですが、いかがでしょうか。

この議論を持ち上げた意図としては、ネオンシティ(MAP1195)に工事中看板が複数残されたまま行き止まりとして制作が放棄されている状況でして、
編集可否ポリシーが現状のままですとこの先を誰も今後作ることができない状態であり、改善する必要があると感じたためです。


  • この議論の内容には含めない内容として、思ったこと…→
    「編集・追加は受け付けるかもしれないけど事前に一報くださいね」という編集可否ポリシーについては、
    どんな方でも突然失踪するリスクがあることを鑑みると、該当の作者が2年? 3年? 以上誰も連絡がとれない・もしくは連絡手段がないとき、
    「事前に一報いれて返事を待ってね」という趣旨の部分は無視されますよ、あるいは削られますよというようなルールを今後建ててしまってもいいのかなと思いました。 - 窯良 -- 2024-08-18 (日) 21:12:43
  • R4Rで発議したため、タイトル記載を変更しました 質疑は本スレに書いていただけると助かります (R4R: ~2024/09/08) - 窯良 -- 2024-08-18 (日) 21:31:17
  • Lemniscate氏本人と連絡がついたため、本R4Rは中止・撤回となりました。詳細は 21部屋目 >>275 - 窯良 -- 2024-08-27 (火) 01:01:14

二次創作ガイドラインページの改定について

natl◆y5Ts2KZBv.?(2022-5-25(水)18:41:13)

発議した理由は二つあります。

  • 同人活動者・ゆめ2っき製作者から「二次創作・同人関係のガイドラインが欲しい」というご意見を頂いたこと。
  • 現在のガイドラインでは2っきの二次創作・同人活動に関して製作者の意向(同人グッズを制作・頒布してほしくない等)が反映できないこと。

そのため二次創作活動を行うファン・ゆめ2っき製作者の両者が安心できるようにと、二次創作ガイドラインページ改定について発議しました。
ガイドライン草案・第二案(Google Drive)


  • ツクラー側の賛成を四票頂きましたが、制定することへの不安や懸念点などの意見も多く挙がりました。
  • 「公式で(同人活動等)金銭の絡む活動を認めてしまうことでトラブルが発生する可能性がある」「法律の異なる海外ファンにも受け入れられるガイドライン作りが困難」等の理由で、審議期間終了前に発議者が議論の打ち切りを宣言しました。

素材利用ルール 20/07/30改定案

2i9 ◆uXs1clq.gnfS? (2020-07-30 (木) 19:44:17)

規制回避のためにこちらにリンク貼ります
Google Docsに飛びます


  • このR4Rは終了しました。 -- 2i9 ◆uXs1clq.gnfS? 2020-08-22 (土) 09:50:56

製作参加の条件、代理実装のルール草案(推敲・意見募集)

2i9 ◆uXs1clq.gnfS? (2019-05-19 (日) 17:18:01)

本スレ18部屋目>>341のR4Rの内容を踏まえ、当wikiのルールページに記述する為のルール草案を作成しました。
ルール草案は下記のh抜きURLから閲覧できます。
ttps://drive.google.com/open?id=1FECpB2sliw1cEpshb5-_Jvu3NA-0Su9R*3

拙いものですがこれでルリ氏のような英語話者の方々にも、言語の壁を超えて不自由なく制作を続けていただければ、と思います。
ルール自体への反対意見、変更した方がいい文章等あればコメントで指摘してください。


したらば掲示板への移行について

2i9 ◆uXs1clq.gnfS? (2019-03-09 (土) 17:39:00)

ワッチョイ導入のため、したらば掲示板への移行を発議します。
賛成か反対か、賛成の場合は本スレ163の「重要な点」をどうするか、反対の場合は具体的な理由を明示してください。
意見は2019/3/30まで受け付けます。
詳しくは本スレを閲覧してください。


  • スレ18部屋目>>214 (2019/03/30)、反対多数のため導入を取りやめることとなった

タイトル画面の変更提起

◆tAkaDaGOxA? (2018-12-03 (月) 12:41:00)

タイトル画面の変更について製作スレの917レス目で提起しました。
議論自体は本スレで進めていき、こちらでは概要をまとめていきます。
この決議の方法についてですが、R4Rをそのまま適用するには議論の主旨がR4Rの想定とまったく異なりますので、より臨機応変な方法で進めていきたいと思います。

ツクラーさんたちが主体となって進めて頂けるのが理想ですので、具体的には次のようなルールで決めていきます。
ツクラーさんに反対か賛成か立場を表明して頂き、賛成ならどの案に賛成かというのも明記して頂きます。
新しい案を自薦して頂くのも構いませんし、ご自身の立場や支持する案はあとから変えて頂いても構いません。既存の案については各素材ろだを参照してください。
反対の場合でも具体的な理由を示してください。現状の案の問題点や改善点をご指摘いただくことで、議論の進行や案の改善の支えになると思います。疑問に思う点などあれば遠慮なく質問してください。
意見は2018/12/23 23:59(JST)まで受け付けることとします。その後、過半数のツクラーの方からの賛成をもってタイトル画面変更を可決し、最も支持の多い案をタイトル画面とします。
しかし、この決議は今後の同様な変更提起を妨げるものでは一切ありません。少しでも着実に進化できることこそが『ゆめ2っき』の魅力と思います。

決議方法自体についても、議論期間中他のツクラーの方から問題点の指摘等あれば修正を加えていきたいと思います。
ツクラーさんの協力と合意が重要な企画ですので、どうかよろしくお願い致します。


  • スレ18部屋目>>17 (2018/12/04)にて提起した◆tAkaDaGOxA氏は手を引いたものの、タイトル画面が以後変わらないわけではない。今も誰かが新しいタイトル画面案をひっそりと待っていることだろう。

【終了】「文字イベントのアリ/ナシ切り替え機能は今も必要とされているか」

ゆめにっきの文字と言えば「あ」ぐらいの物だったが、
ゆめ2っきでは文字をメインに作りたい人も出てきた。
本家には無い「文字」をどうするか?
様々な議論があったか無かったかは置いといて、現在は
「プレイヤーが見たくない場合は非表示にする」という事になっており、
ゲーム内のパソコンから「文字が出るイベントのON/OFF」を切り替えできる。
 
しかし3年以上もの月日が経った今、
「今でも必要なのか?」という疑問がどこからともなく出てきた。
「アンケートを取ってみないか?」という名無しさんの声に
当Wiki二代目管理人は「面白そうだからやってみよう」と思ったのである。
 
そしてアンケート開始から約4ヶ月…
特に何もなく、このまま続けるのは有意義ではないと判断した
当Wiki二代目管理人はアンケートの結果を集計したのだった。
 

アンケート結果

選択肢投票数投票率
文字のON/OFF切り替えは欲しい78.97%
文字のON/OFF切り替えはいらない2532.05%
あって損はないだろう4658.97%
正直どうでもいいわ00.00%

(投票期間:2013年03月29日~2013年8月5日)
(※投票率の値は小数点以下第三位を切り捨てています)
 
 
 

  • 「(このゲームに文字主体のイベントがある事は)もう十分に知れ渡っているはずだ。必要ないだろう」
    「本家には文字は無いに等しい。そこから流れてきた人の為にも、ON/OFF切り替えは必要だ」
    「最初はONの状態で、嫌な人だけOFFにするのはどうだろう?」 -- 4月7日18時の製作スレまとめ (2013-04-07 18:54:57)
  • バカな質問かもですが、OFFにするとどんなメリットがあるんでしょうか? -- 名無しのうろつき (2013-05-31 10:27:35)
  • ↑現在メリットと言えるのは、図書館のビビッドワーカー本をマージナルで読むと顔腕に直行できることと、一部の壁紙取得条件が緩和されることくらいかね -- 名無しさん (2013-07-06 13:57:13)
  • 返答ありがとうございます。ずっとモヤモヤしていたので -- 名無しのうろつき (2013-07-10 13:31:36)
  • 長らくスレで話題にならなかったのもあって、アンケートを〆切ました。 -- K
  • LSDや他の派生とかでも文章あったりするし、そもそもゆめ2っきは色々な世界観があるわけだから、別にあったって何の問題もないはず -- 2014-11-12 (水) 21:35:55
  • 切り替え機能で楽しみ方が増えるのでは? -- 2015-03-05 (木) 22:38:49

【終了】マップチップ通行設定の割り当ての貰いかたについて

K? (2014-10-31 (金) 03:29:38)

2013年の11月に、割り当ての区切り方と貰い方を変更し、以下のようになりました。
◆これからは変数とスイッチは100ではなく10ごとに区切る
 (マップとマップチップの通行設定は今まで通り10ごとに区切る)
マップだけ貰う、変数とスイッチだけ貰うことができるようにする

…ちょっと待って、今更だけど「マップチップの通行設定」は?
今、通行設定の割り当てをどういう風に貰えばいいのかハッキリしていません。
それならばここで決めちゃいませんか。

現時点で私は「欲しい場合は通行設定だけを10ずつ貰える」のが良いのではと考えています。
同じマップチップでマップを複数作る人もいますし、
逆にマップ一つに対して複数のマップチップを用意する人もいます。
それなら通行設定だけ欲しい時に追加で確保できた方が便利なのではと思います。


  • 11月30日まで反対なければ強行して「通行設定だけを10ずつ貰える」で決めてしまおうか・・・。ご意見お待ちしております。 -- K? 2014-11-12 (水) 19:39:36
  • とても重大な変更点を無反応なだけで決めるのは如何なものか。見てない人も多数居るはず。スレで聞いてから検討すべき -- 2014-11-14 (金) 01:21:11
  • すまん、あんまりにも反応が無いもので気が落ちてたのかもしれん…。スレのSRの話が落ち着いてきたらこの話を持ち出してみるよ。 -- K? 2014-11-14 (金) 21:46:49
  • 2015/08/22にR4Rでもって提案し、2015/09/12に決定となりました。
    ( http://peace.2ch.net/test/read.cgi/gamedev/1423661560/678 ) -- 2015-09-21 (月) 23:21:10

*1 避難所はログインしなくてもOK、ガイドライン編集相談所はログイン必須、みたいにそれぞれで設定可能
*2 なお、YNOのゲーム内容のバージョンアップ・データ置換作業は主にyugamineena氏が担当している
*3 2024年現在、404エラーで閲覧できない