ゆめにっきっぽいゲームを作るスレ 13部屋目

1 ：胃の結 ◆DacPbHTgw2 ：2014/10/06(月) 01:16:19.13 ID:mPZgAROl.net

ききやま氏作のフリーPCゲーム「ゆめにっき」っぽいゲームを
みんなで作ってみようと目論むスレです。
意見の押し付け合いは無しの方向で、ききやま氏に敬意を払いつつ行きましょう。
　
絵師・音師・ツクラー募集中！詳しくは下記のまとめWikiにて。
　
ゆめにっきっぽいゲームを作るスレまとめ
ttp://wikiwiki.jp/yumenikki-g3/
　
◆専用うｐロダ（専ロダなので基本パス無しでおｋ、外部ロダ共通パス yume
http://ux.getuploader.com/yume2kki05/（素材用）
http://ux.getuploader.com/yume2kki_A/（本体用　臨時）

　
◆RPGツクール2000体験版
ttp://www.famitsu.com/freegame/trial/2000_trial.html
　
◆本家スレ
ゆめにっき65ページ目
http://maguro.2ch.net/test/read.cgi/gameama/1377902094/
　
◆前スレ
ゆめにっきっぽいゲームを作るスレ 12部屋目
http://peace.2ch.net/test/read.cgi/gamedev/1351597862/

221 ：Ca ◆Qz/yBncGCA ：2014/11/12(水) 01:08:14.64 ID:cv+xA3i0.net

曲一覧→RPGツクールの仕様的にほぼ不可能かと思います。無理やり作っても利便性は今以下になるかと。
4行しか表示出来ませんし。やるとすればピクチャー…作る側の管理が余計に面倒となります。

曲情報のピクチャ→今は不要になってる筈です。主人公名とかで管理している…と思います。
画像は残ってますけど…

＞必要な編集箇所を1イベントに
私はむしろ一つのイベントにつき一箇所にして、イベントを増やしてはどうかと。
４ページ目とか、途中に編集箇所がある事こそややこしさの原因ではないかと私は考えています。
１０個程度ならまとめた方が分かりやすいと思いますが、数百単位となればちょっと。

具体例(EV.Noは適当です、実際は処理順の関係以下略...)
EV0001(000,000) 説明書(or説明のある場所、ファイル)
EV0002(000,001) 開放率
EV0003(001,001) 総曲数
EV0004(002,001) コンプ判定
EV0005(003,001) 曲格納庫

p.s.新参の癖に五月蝿くて申し訳ないです。
間違ってたり気に食わなければ無視してやってください…。

222 ：Ca ◆Qz/yBncGCA ：2014/11/12(水) 01:11:45.84 ID:cv+xA3i0.net

あ、画像の件は嘘でした。訂正します。…やっぱり黙っておくべきかもしれない。

223 ：名前は開発中のものです。：2014/11/12(水) 01:21:08.74 ID:mcYLAgK9.net

ふと思ったのですが、710氏の映像イベントのBGMって、SRに追加しない方向ですか？

224 ：名前は開発中のものです。：2014/11/12(水) 07:25:47.24 ID:U7FYadsI.net

> 曲一覧→RPGツクールの仕様的にほぼ不可能かと思います。無理やり作っても利便性は今以下になるかと。
> 4行しか表示出来ませんし。やるとすればピクチャー…作る側の管理が余計に面倒となります。
→ピクチャでやる。文字は表示しない。
　開放されてるかどうかが視覚的にすぐ分かって、その曲をパッと選べるのが理想形。

> 曲情報のピクチャ→今は不要になってる筈です。主人公名とかで管理している…と思います。
> 画像は残ってますけど…
→K氏がピクチャ処理に戻した。見栄えは確かに良いが、あれを毎度用意しろとなると骨が折れすぎる。
　曲情報は見たい人が見たい時に見れればいいんだから、曲演奏中に何かキー押したら
　文章で表示させる程度で事足りると思う。

> ＞必要な編集箇所を1イベントに
> 私はむしろ一つのイベントにつき一箇所にして、イベントを増やしてはどうかと。
> ４ページ目とか、途中に編集箇所がある事こそややこしさの原因ではないかと私は考えています。
→これは納得。イベント名に「何を登録するイベントか」を明記し、マップ上部に編集する順番に並べとけば、
　どこ弄ればいいのか分かりやすそうだな


上に書いた案については、
こんな感じにしたら良くなるんでね?って絵が浮かんでるんだが、
口だけで伝えるのは難しいな

最初の30曲くらい使って
新SR仮製作して見せた方が、良い悪いもはっきりするかな
てなわけで少し時間をくれ
意見・提案は引き続き求む

225 ：名前は開発中のものです。：2014/11/12(水) 09:54:01.95 ID:X6GgLMgC.net

デブラグ画面みたいなもの用意して、解放されるたび変化させるとかどうかな
壁紙の解放みたいに一画面である程度の進捗がつかめれば便利かもしれない
今の操作方法に加えて、その画面上でカーソルを移動させてクリックで再生ていうような

ざっくり表現すれば

■■■■■
■回■□□　回←カーソルオン
□□■■■　■←ロック
■■■■■　□←解放

みたいな

226 ：Ca ◆Qz/yBncGCA ：2014/11/12(水) 12:38:38.36 ID:cv+xA3i0.net

ああ、エアライドのチェッカー…とこれでは一部の人にしか伝わりませんね。
http://www.nintendo.co.jp/ngc/gkyj/sarani/g_01.jpg
これを連想しました。

イベントの編集箇所削減に関するアイデアです
https://www.dropbox.com/s/4ss0j568x95za8w/srtest0.txt?dl=0

227 ：幻想 ◆89nd/MMxy. ：2014/11/12(水) 17:22:08.56 ID:mcYLAgK9.net

>>219

追記忘れました
走る際に、MAP0631〜0640の割り当てを使用します

関係ない話ですみません…

228 ：kuraud ◆psB7u4PVzw ：2014/11/12(水) 19:29:36.43 ID:Z7kgUDF/.net

>>クリアチェッカー方式
もし今までのSRのEDと演出すべてを消してもいいのなら、床にイベントを敷き詰めるという手もありそう
ツクラーへの分かりやすさは多分これが一番だと思います


>>必要な編集箇所
現時点でイベントが複数あり、例えて言えば「複数人に台本を渡している」状態です
できることならこれを「１人に台本を渡すだけ」にしたいなと。これなら曲番の入れ替え・整頓もしやすいし
（※ピンからキリまでの処理を１イベントに収める気はまったく無いです）

今は「開放率を調べる」「再生する」と別々に分かれていますが
これを「最初に曲番号で分岐した上で、スイッチで開放率の確認処理・再生処理などに分岐させる」形にすれば
編集箇所がほぼ一箇所に収まるんじゃないかと考えてます。もちろん20曲ぐらいごとにページ分ける形で
たぶん言ってることは>>226でCa氏が言っているのと同じかも


>>曲一覧
壁紙のような形か、縦に番号と開放されているか確認するための何か(番号の色とか)が並ぶ形式かが気になる
私の想像の中では後者


>>曲情報
曲名のとこが事実上まったく機能してないので、作曲者名だけ出すのもアリかも
でも編集しやすさ重視で考えると、壁紙と同様に主人公名のとこにぶちこんで\N[1]\N[2]が安定ですね

229 ：名前は開発中のものです。：2014/11/12(水) 21:23:59.64 ID:U7FYadsI.net

先に言っとくと、正直ゆきひつじ氏が作ったような
見ごたえのあるSRにする気はない

必要な曲が全部聞けて、
どの曲が完全開放されてないのか分かりやすくなってれば
とりあえずはOKだと思う

演出とかのカスタムは
全体の構成がしあがってから、実装したい人がやればいいわけで

230 ：名前は開発中のものです。：2014/11/13(木) 08:16:24.09 ID:YKr8tBVw.net

曲判定について一つ聞きたい

現在の形式はSR入室時と演奏時にそれぞれ条件を満たしているか確認しているわけだが、
これを壁紙やパズルのように、判定は最初の1回のみにして開放状況を変数に記憶させるのはアリだろうか？
その曲の使用箇所が2ヶ所あるなら、0が未開放、1・2が片方開放、3が完全開放みたいな感じで

変数に入れるメリットとしては、
毎度条件判定をする必要がなく、特定の変数の値のみ監視するだけでよくなるということ
曲一覧を表示させるなら、SR用に変数を確保した方が編集しやすいし分かりやすい

逆にデメリットとしては、
ただでさえカツカツの変数領域を、
200以上ある（これからもさらに増え続ける）曲のために確保しておかなければならないということ
現状空きは確かにあるが、この先のことを考えるとキツイやもしれん