【ウディタ】WOLF RPGエディター 其の66
■ このスレッドは過去ログ倉庫に格納されています
RPGツクール系よりは手がかかる分、比較的細かい所まで作り込む事ができます。
RPGツクールでは物足りないけど、プログラミングはちょっと……という方にお勧めです。
次スレは >>980 が立てて下さい。
■WOLF RPGエディター公式サイト
ttp://www.silversecond.com/WolfRPGEditor/
■開発者サイト SilverSecond
ttp://www.silversecond.net/
■エディター説明書
ttp://www.silversecond.com/WolfRPGEditor/Help/
■WOLF RPG エディター パーフェクトガイド
ttp://www.silversecond.com/WolfRPGEditor/Guide/
質問スレ
WOLF RPGエディター 質問スレ 其の10
http://echo.2ch.net/test/read.cgi/gamedev/1463812471/
前スレ
【ウディタ】WOLF RPGエディター 其の64
http://mevius.2ch.net/test/read.cgi/gamedev/1490548845/
以下、公式サイトから抜粋。
○高度なRPG開発が可能な、完全無料のゲーム制作ツールです。
○作成したゲームは自由に配布・販売・コンテスト投稿などが可能。
○コモンイベントを導入することで、ゲームシステムを無限に強化できます!
※Ver2.02a以下のウディタで暗号化したファイルは、Ver2.10以降のウディタでは読み込めません
旧Verの入手も公式HPの【本体のダウンロード】のページから可能です >>180
確かにタグ検索や作者別検索、ブックマーク、いいねほしいかも。
(狼煙さんお忙しいだろうから無理かもだけど)
でも、最近、コモンクリックすると別タブになるように更新されたみたい。
>>179
kwsk ブクマとか高機能なのは必要ないが、単純に作者別のリストや機能やタグを
細分化して、それがリスト化して見れるようになれば嬉しい。俺は自分でリスト化した
あと、同じような機能を別々の人が違う方法で各々実装していたりとか結構ある
汎用的な機能はライブラリ化してコモンの依存関係がわかるようにする
現状はみんなが不効率な車輪の再発明をし続けているように見える 🤔 
外部でデータベース作ってタグ付けとか考えてたけど
これ機能毎に細分化するの無理っしょ
クオリティの高いコモンをまとめた方がよっぽど為になりそう >>183
多分>>182とは言っていることが違うと思うけど、これが一番良さそう
これで使用頻度の高いコモンが一番有用だってことだし >>181
あんたはデータの断片化を気にした事はないのか? >>186
データの断片化って用語初めて知った
複数の場所に分散して保存されている状態のことを言うんだね
デフラグのフラグって、データの断片化の別名のフラグメンテーションから来てたんだね ちなみに、オイラのパソコンはあのウィンドウズ10だから、
バックグラウンドで勝手にデフラグされているらしい。 パソコンは一日2時間しか使ってないから自動的にデフラグなんてするわけがない 漏れのPC は、Windows10, SSD だから、書き込み回数を平均化するために、
OS が勝手に、データを移動させる(ウェアレベリング)
書き込みの限界回数を超えた所は、もう使えなくなるから Windows10だとSSDを検出すると
そのドライブには自動デフラグはSSD用で実際には並び替えないよ
7はSSDでは手動で停止させる必要あるけど 例えばだけどエネミーデータをNo50までいれてたセーブデータがあって、バージョンアップでNo60までエネミーデータが追加された場合、セーブデータをそのまま移すとNo51以降が呼び出せなくなるのは仕様ですか?
解決策などがアレば教えてもらえるとありがたいです UDBだといけるんですか?
知らなかった…ありがとうございます うちのパソコンのHDDの中身が物凄い勢いで断片化するんだが >>197
マシンが持ち主にケツまくってるんじゃないかw
「アホくさ、やってらんねーよ!ようし!食い散らかしてやれ!」みたいな感じでw マップチップで家の三角屋根を描いているんだが色変えやバリエーション持たすとあっというまにスペースが無くなる
縦が4000ピクセル超えてしまった そこは、容量や読み込み速度を取ってできるだけ同じチップで済ませるか、
グラフィックの多様性(飽きなさ)を取るか、今こそジレンマの時じゃない?
Y4000ピクセルってことは、16で250×8、32で125×8、40で100×8かー。 でも、ピクチャを使うかデフォルトのマップを使うかは、
開発初期の段階で決めない? 自分ではピクチャ使うものの相手の立場に立って考えたつもりで、
マップの方主張したらピクチャ勢の多さに押しつぶされたでござる←
まぁピクチャはピクチャでも、
・基本はマップで組みつつもピクチャスクロールとリンク多用
・Taigaの様な一枚絵マップ
・コモンイベント集の3Dダンジョン
とかいろいろあるからな… 限られた容量の中でやりくりするのが好きな俺はマップチップを勧めるおまえさんの行き方嫌いやないで マップチップをウディタとは別のマップ生成ソフトに入れて、
画像マップを作って、ウディタで遠景として表示するという方法もあったりする。
あまり同じチップを使いまわさない場合は、その方が容量削減できたりする。 ウディタでマップを作って、スクショを撮って遠景に使ったら駄目なん? 1画面で済むならそれでいいと思うけど広けりゃ面倒じゃねっていうのと、そのまま管理出来るなら遠景にする必要なくねっていう
レイヤー3枚駆使してチップ最大限に活用しても難しいって場合じゃなけりゃ修正やら面倒なだけだと思う
ウディタゲーじゃないけど、フェアルーンとかはマップにグラデかけててチップセットにする意味がないから、ああいう感じなら利点になりえると思う
>>207の言う同じチップを使い回さないならって多分そういうことだと思う 扱いやすさがマップチップの利点だと思う
タグ取得とか当たり判定とか表示のあれこれ(回り込みとか)を全部一括で管理出来るから素直に使うのが便利だよね
修正も圧倒的にしやすい
>>199は外観と内装、もしくは町ごと、マップごとでチップセットを分けるとかすると、十分足りると思う
まあどこを面倒と思うかって話になるけど 自分は1イベントごとにしつこくテストプレイ、修正を繰り返す効率が悪い作り方をしている
ゆえに一枚絵だときつい 初歩的な質問なんだけどセーブデータを
削除したらCDBの保存された箇所も初期状態に戻るよね? >>212
そっちの方が全体の制作期間考えたら効率よくない?
まだノウハウが少ないときにチェックもろくにせずに作り続けて、根本的な不具合が出たときに1から作り直した方が早いって経験してからは動作チェックは慎重になったわ 初歩的な質問で悪いんだけど
標準の機能では主人公ってピクセル単位の移動は出来ないよね?
もしピクセル単位で移動できるゲームを作りたければ
コモンイベントのピクチャで自機を表示して
当たり判定等も自作していくっていう方法で良いのかな? いや自機だけピクチャならマップとイベントの当たり判定は楽だからそうでもない
角でのズレ判定とかやり出すとちょっとアレだけど せやで
ウディタはフィールドキャラの当たり判定バグ(基本コモンで作る分には関係ない)があるから、
1ピクセルで動かす前提のゲーム作るつもりならどっちにしろ判定コモン書いてたと思うで
当たり判定だけなら数行でいける >>218>>219
回答ありがとう
標準ではピクセル単位の移動は無理で
コモンイベントを組むならこの方向性で大丈夫って事で良いんだよね?
あと質問ばっかで悪いんだけど
もしかしてウディタって標準では平方根の計算をする機能は無いのかな?
加減乗除+αの算数的な処理は出来るけど
三角関数なり平方根なりの数学的な処理は標準ではついて無い感じ? sin, cos, atanは変数操作にある
平方根は見つからない 平方根や累乗根はループと条件分岐で簡単に作れるし、解説サイトもあったはず。
コモンイベント集にもいくつかある。
ループでの処理時間ロスが気になるなら、
空いたタイミングで予め自動計算したのをDBに保存しておけばよし。 平方根算出からさらに計算を重ねるわけでないなら、平方根求めずにやってもええよ
平方根求めるのって、よっぽどの場合だけだし >>221>222
>空いたタイミングで予め自動計算したのをDBに保存しておけばよし
成る程、イベント集からの導入と自作で数値計算コモンを書くのは考えてたが
テーブルを作ってしまうっていうのは頭に無かったわ
参考になった、ありがとう
しかしふとゲームを作りたいと思ってウディタを触ってみたんだけど
非常に取っつきやすい分、便利な道具はやや少ない感じなのかな
プログラミングなら数学関数はばっちりそろってるだろうけど勉強する時間がね…
一長一短でどっちにするか迷うなあ 実際作ってみるとわかるけど
俯瞰視点マップでのピクセル単位での移動って現実的じゃないよ
精々マスを1/4にする程度 作ったことあるけどどう現実的じゃないと思ったのかが分からない 単純に速度が1px/Fだと遅すぎるから現実的じゃない
移動というのが主人公の移動ではなくて、RTSでの駒の移動とか言うなら分かるけど 1px/Fにするという前提が間違ってる
好きな速度にすればいい
>移動というのが主人公の移動ではなくて
"主人公というウディタの機能"は使わない前提だよ
>>215からの流れだからピクチャ使用 いや別に俺熟練者じゃないし100%正しいこと言ってるつもりもないしさ
全然違うこと言ってるのかも知れんし
単純にどういうこと?って思うから普通に解説欲しい
トップビューって限定してるってことはそこに理由があるのかなって思ったけど やったことあるけど解像度640x480のキャラサイズ32x32で3.5px/Fぐらいがちょうどいい速さ >>230
いやそんだけだよ
1px/Fだと遅すぎるからデフォ速度の4px/F辺りを採用するだろうけど、結局デフォのマス単位での移動とほぼ変わらない出来になるだけだということ
俺が作ったときは解像度等倍で32*32の最低2px/Fだったけど、それでも1/8マス単位での移動で十分だったし
トップビューに限定したのは、加速減速が入ると1px単位での移動が入ると考えたから
横スクなんかで重力加速度とか慣性力が働いたりしたらマス単位での移動にはならんなと 速度自体は同じでも入力によって進み具合が変わるからマス移動とは操作感全然違うと思うけどなぁ
まあその辺は感覚の好みの範囲かね
現実的じゃないっていうのを実装しても使えないって意味として受け取ってしまったから不思議だったけど、
する必要が無いって感じの意味かな
どうもありがとう 加速減速がないピクセル移動って点でSTGとか考えてみると、
弾や敵との当たり判定を細かくする必要があるかどうかっていう所が観点になるのかな ん?
マス移動ってことは半歩か1歩かだから速度は変えられても進むピクセル数は変えられないんじゃないの?
1/8マス移動って出来なくね?
システムとしての主人公をマス移動で動かすのか、ピクチャをピクセル単位で動かすかって話だよな?
1pxずつ動かすかどうかとピクセル移動かどうかって関係ないと思うんだが
言葉の受け取り方が双方ずれてる気がする ウディタにおけるピクセル移動っていうのは自分で(主にピクチャ)位置計算なりして動かすことで、もちろん1フレで1pxずつ進もうが1マス分進もうが勝手
反対にマス移動は1回の入力で必ず1マス分の移動をするRPGっぽいあれ(主に主人公イベント)
というのが俺の認識 そういや今って16*16でも等倍表示できるから、キャラを32*32にして、8px単位での移動ってできるんだよな どういう根拠で物理的に無理とまでいうのか分からない
娘の過去絵見たら普通に絵描ける人だし、アイテム1個で下絵無しなんか珍しいことじゃないし、30分は確かに早いけど普物理的に無理というほど有り得んクオリティと早さではない
ただこれは全部を1ドットずつは打ってないなと思うし、ツイート見るとグラデや図形機能使ってるって書いてた
そこで時間短縮とアンチ多用によるぱっと見のクオリティの高さに繋がってる
剣の方も見たけど、グラデはともかく、ドットもアンチも整頓されてなくて汚いからドット絵としてだけの評価なら酷いと思う
でもドット絵かどうかってこだわりないみたいだし、アイテム絵としては普通にクオリティ高い ある程度イラスト描ける人にドット無視して30ピクセルくらいでペイントツール使って描いてって頼めば描けるものをドット絵とは思ってなかったわ
剣もあの下絵から途中段階でのグラデ処理されてるのか意味不明だし
3枚目の人なんてデザインはともかく縮小しただけですやんw 俺は「物理的に30分じゃ無理」を否定しただけであの瓶も剣も人もドット絵とは思ってないよ
あれでプロ(のドッター)になれるじゃん!って意見出てるのはめちゃくちゃ複雑
でも呼び方がおかしいだけで発注通りだし素材としては有用だろ
勘違いなんかよくあることだし、イラスト縮小素材自体は別に悪いものじゃない
つーかついレスしちゃったけどスレ違いもいいとこ ユーザー側のゲーム内操作でcsvの出力や読込できるようにって実装できたりしない?
なにかいい案持ってる人がいたら教えておくれ 詳しく知らんけどcsvの中身もテキストじゃないの?
フォーマットに沿って書き出し読み込みすれば、
ウディタのテキスト操作で実装できるんじゃないかな >>248
なるほどその手があったか
試してみるわ。サンクス 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 過去どれだけいい資料があったのか調べてたけど、かなりの資料が、リンク切れとか起こしてるな
ここが10の時に載ってた、猫とゲームもなくなっているしな つまらんやる気で金払ってサーバー借りるとそうなる
かえってfc2とか忍者のような無料で借りたホームページは残りやすい
広告邪魔だけど 4年位前の方が資料は多かった気がする
今になって知りたくなったりする初歩で分からない事結構ある ちょうど最近ニュースにあった
後継者がいなくて倒産する会社みたいになったウディタ
そこらへんツクールはしっかりしている >>254
でもさ、わざわざ新しくソフト作るの大変なんだぜー
今のを、流行り風に大きく改良しようにも、ウディタはdxlib使ってたはずだから、マルチプラットフォームやVRは無理だし ツクールMVはPC用に出力させるとHTML5(javascript含む)ゲーム+専用ブラウザのパッケージだけど
ダウンロードゲームだけ作るならそれいる???だし (リックさんの基本システムインターフェース改造系シリーズカッコイイ) DXライブラリはAndroidやPS4、PSVita、Switchにも対応してるから
ウディタも互換性に注意して組めばウディタ製ゲームがそれらのハードで動くこともあるかもよ これアレだな、タイルは16幅だからってキャラチップも16幅じゃなきゃダメってわけでは無いのな コモン変数でコモンイベントを呼び出す場合は変数を渡すことはできないのでしょうか?
渡そうとしても非活性化されていて選択できない状態になってしまいます
https://i.imgur.com/g3nlSm4.png >>260
変数呼び出し値の『コモンEv Y のコモンセルフ変数X』と変数操作の代入先の『X番の変数呼び出し』の合わせ技 改造したイベントコードを貼り付ければいける
ブログの受け売りだけどできるのは確認した
ウディタ コモン 呼び出し 引数 でググれば元ネタ見つかるはず
WoditorEvCOMMAND_START
[210][a,0]<0>(b,c,d,e,f,g)()
WoditorEvCOMMAND_END
a = 引数の数 + 2
b = CSelf11で呼ぶなら1600011
c = 引数の数
d, e, f, g = 引数1, 2, 3, 4 3人ともありがとうございます
おかげさまで無事解決できました いつも思うんだけど、
イベントコードに一見無駄な記述が必要そうに見えるのは、
チェックディジットってやつなのかな。 SDBのタイプ6、データ21に文字の影が〜があるのは分かってて、項目加えて変数の値0にしてるんだが、何も変わらない ウディタのデフォUI(基本システム2やデフォルトのウィンドウ)って、
そのままでも充分カッコイイなって。
狼煙様やデフォ素材の作者様たちやっぱ流石っすわぁ。 シンプルでいいと思う
旧バージョンのメニューが横に並ぶのも好きだ ファイル選択コモン作ってみた。
創作性が充分じゃないと著作権発生しないから、著作権は放棄。
コモン素材のみ
https://silversecond.com/WolfRPGEditor/CommonList/html/tdv252.html?#15420132073301
オリジナルBGM付きのサンプルゲーム
https://www.freem.ne.jp/win/game/18881
基本システムのUI私は好きだけど、デフォルトに近いの嫌という人も結構多いよね。
ツクールMVとかでウディタの基本システム完コピくらいまでしたら、
努力の無駄遣いでデフォルト嫌勢もびっくりかもだけど。 フォントとHPSPバーの色のクソダサさがやばいんだよね >>272
ワザとダサくする事で自分で自作せよと促しているような感じもする
あのサンプルの中身もそうだし 別に基本システムの中身まで変えなくともウインドウとかフォントとか見た目変えるだけで大分デフォルトっぽさは薄れるよね
メニュー画面の配置とかは数値いじれば変化がわかりやすいの多いし、改造不慣れだけどデフォルトっぽさなんとかしたい場合はメニュー描画とかいじるのがいいと思ってる HPSPゲージカラーのデータベース指定と
敵SPゲージの表示は
元々デフォルトから実装しようとされていた形跡が基本システム2に遺っている。
HPSPゲージカラーのデータベース指定コモンについては、
著作権を放棄して公式CEv集に投稿したけど。 エフェクトのピクチャ明滅にディレイつけたいのですが不可能でしょうか?
ピクチャのカラー補正とディレイをあわせてやるしかないようでしたら諦めますが、もしよい方法などありましたらお教えいただけると幸いです 並列処理のコモンを作る。
以下コモン
・ウェイト1フレーム
可変データベースで適当な名前のフラグを作って、
そのフラグをコモンセルフに代入
そのコモンセルフを使った条件分岐入れる。
条件分岐の中に
・入れたいディレイ-1のウェイト
・明滅のエフェクト
・可変DBのフラグに条件分岐の条件に合わない数値を代入
をいれる。
以上コモン
後は、呼び出したい時に可変データベースの数値に、
条件分岐の条件となる数値を代入すれば、おk。 >>277
おかげさまでやりたいことができました!ありがとうございます
今まで並列処理使ったことがなかったのですが便利ですね
https://i.imgur.com/R8nh7Od.png >>278
画像見たけど、並列処理を使ったことないにもかかわらず、
割と手慣れた賢い組み方していて、改めて考えれば、
ピクチャ明滅にディレイをいれようとする時点で、只者じゃないな。 ■ このスレッドは過去ログ倉庫に格納されています