【ウディタ】WOLF RPGエディター 其の66
レス数が900を超えています。1000を超えると表示できなくなるよ。
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の【本体のダウンロード】のページから可能です 基本システムならターン終了時処理で
味方に戦闘不能者がいるかで条件分岐すれば
割と簡単にできる気がする
任意で入れ替えしたいなら手間は手間だけど
そういうコモンも公式に上がってたと思う 入れ替えができるなら、入れ替え時に技を使うのは割と簡単
パーティ外のキャラを選択するのも、入れ替えを自力で作れる人間なら十分可能かと
一番面倒くさいのは入れ替えそれ自体じゃないかな
最悪のクソみたいな見た目でも良ければ選択肢を使う超簡単な方法もあるけど ＞入れ替えを自力で作れるなら
ぶっちゃけ一番重要なのはこれだと思うわ
これにつまづく可能性が一番高いし、これがクリアできるなら他の部分も実相自体は楽
面倒なら頼むのも手だとは思うけど、金銭のやりとりとそれに関する取り決めも結構面倒だからな
俺だったらある程度高い額じゃないとやりたくない 色々お話ありがとうございます。もう少し詳しい仕様をいうと
・戦闘の前衛人数は4,5人くらい 控え含めた総人数は数十人規模
・控えには回復、復活など処理はできない
・メンバー入れ替えは戦闘時以外でできる
こんな風に考えてます。多人数で戦いに挑める分復活手段がないのでボス戦など接戦になる場面では
ボコボコ死んでいってリソースに限りがある戦いになりますね。
戦闘時に入れ替えできるかどうかはちょっと悩んでるんですが、できない場合も
的の行動パターンと味方の控え順での「駆け引き」がおきていいかな？とも思っています 聞き流してもらっていい話なんだけど、別に有償で外注することを否定はしないけどやはり作って楽しむのが醍醐味なのだと思う
自分で組むのは難しいとしても公式の公開コモンを利用して見るくらいはしてもいいかもよ 俺も自分で作った方が良いとは思うけど人によるからねー
自分のドット絵が動いているところを見たいって理由で作っている人もいるだろうし あと追加でいうと別コモン「基本システムAdvanced ver3」というコモン上で
動くようにしてもらいたいという点もありました。
概要はこんなとこでしょうか。 >>792
【ｳﾃﾞｨﾀ】気紛れ3Dﾀﾞﾝｼﾞｮﾝ
http://nico.ms/sm19309420
【SMILE GAME BUILDER】 ﾄﾞｯﾄｲｰﾄ作ってみた 【ｽﾏｹﾞﾋﾞ】
http://nico.ms/sm29541830
【実況】ﾊﾟｯｸﾏﾝがﾘｱﾙになったら怖すぎた｡【FPS-MAN】
http://nico.ms/sm20340625
【夢のﾊｺ企画】懐かしのGBｿﾌﾄを振り返ろう【第四十三回】
http://nico.ms/sm29749117
あー､気紛れ3Dダンジョンとかスキなんだけど､
最近は他のゲームツールも充実しすぎて､
ウディタでやろうとするひとが､多分､少なくなってんだろうね｡
とりあえず実検で古臭い単純なドットイートゲームや
シンボルエンカウント戦闘などをつくっていたけど｡ >>808
こうやって控えを設定した
・CDB6のデータを１つ増やして控えパーティを設定
・CDB10のデータを25まで増やして20〜25を控え用に設定
主人公DBから戦闘用DBに呼び出すのはコモン203,204に>>809の言うような処理を追加するだけでいいが
今確認したら、戦闘用DBから主人公DBに戻す処理がうまくいってなかった
自分は戦闘用DBと主人公DBを主人公IDで紐づけてデータを戻す処理をコモン206に追加したけど
どっか別の処理で戦闘時の配置＝パーティでの並び順として
処理してるっぽくて別人のHPやMPが反映されてしまう
探すの面倒いからもう寝ますわ よくやるな
俺はもうコモンイベント集にあるシステムで動くようにしてって話を聞いただけでリタイアだわ 全滅時に控えが出て来る設定だけなら割と楽
まず控えの設定は主人公ステータスに項目を一つ加えて
「0なら未加入」「1なら加入済み」ってやるだけ
戦闘メンバーは実際にパーティに加入しているから区別の必要は基本的に無い
（戦闘メンバーから外れた時に備えて加入済みにしておく必要はある）
あとは「倒れてる奴はパーティから外す」
「主人公を次々に調べて、控えメンバー認定されてる奴をパーティに加える」でOK
まあ、これはあくまで大筋の話なので、このまんまやると壮絶にバグる
とはいえ、色々いじる気概があれば修正はそこまで難しくはないはず
ただ任意交代はこんなに簡単ではないんで注意な
あと戦闘DBの10番以降は基本的に敵の領域だからいじるのはやめた方がいい >>819
UDB13で最大7体しか敵を設定できない都合上、CDB10の20番以降を使っても問題ないと判断したけど、そうでもないのか
参考にします
基本システム読むのは時間かかるな 仲間追加削除って戦闘中にも使えた記憶がある、あれターン終了時とかに使えばいいんじゃね？
基本システムで一時データベース書き換える改造はオススメしない、仕様に沿って新たに追加していく方針がいい そもそもコモン作成を依頼して人なるんだから
そんな作り方の話ししてもしょうがないけどな 公式の公開コモンに「お手軽3Dダンジョン」っていう
ワイヤーフレームのダンジョンが作れるコモンがあるけど
これ旧基本システム用なんだよなー
誰か基本システム2用に更改してくれたら嬉しいのに 旧基でも戦闘とかメニューとかに関わっていないなら普通に使えなかったか？ やりたいゲームが無かったから自分で作り始めたけど中々難しいな 言われてみればアレってマップ周りくらいしか変更ないな
もしかして基本システムである必要すらないのかもしれない
試してみよう 3D描画＋基本システム2といえば、
・各種画面サイズに対応
・動く3Dオブジェクトに対応
・各種地形ごとに足音を設定可能に
・地形ごとに異なる天井や床の高さを可能に
・敵にレベルを設定可能に
・敵も装備を可能に
・敵にも戦闘コマンドを設定可能に
・マップごとにテクスチャ用に参照するDBタイプ番号を変えられる
な合作コモン配布してたりするから良ければ見て欲しい。
https://www.freem.ne.jp/win/game/18651 ウディタで3Dとか邪道すぎて、dxlibでやれよと思ってしまう
さらに、dxlibじゃあなくて、UE4とかでやれよとも思い始めてしまう、俺がいる なんで突然3Dの話しだしたのかと思ったら学会やってたのか ウディタ学会らしいよ？
130行のコモン一個で動くレースゲー的表現を見て俺はそっとウインドウを閉じた お手軽3Dダンジョンコモン、色々と修正は必要だったけど
基本システム2でも動かせそうだよ 情報ありがとう
やっぱマップは2Dより3Dが作るの楽だなぁ
マップチップ調達に悩まなくていいし >>834
>>やっぱマップは2Dより3Dが作るの楽だなぁ
>>マップチップ調達に悩まなくていいし
激しく共感、
私もキャラチップの代わりにモンスターグラフィック使うために疑似3Dやってる。 828だけど、本当、君らウディタ民って変態ちっくだなぁ
俺も一時期は色々やろうとワクワクしてた時期があったが、なんというか、
ライブラリとか使おうという気が凄くて、わざわざ車輪の再発明ちっくなことをする気が起きない
もうおじさんな俺にはついていけないぜ >>836
UE4使えるのは純粋に凄いなー！
UE4やUNITYって素材の利用規約が複雑だし、英語で書かれた規約もあるから、
素材の利用規約を読むのに結構時間がかかりそう。
色んな素材使うと権利関係も複雑になるし。
ウディタは割と利用規約が軽い素材が多い印象。 CPUの進化が頭打ちになってきてるから限られた環境で構築できたりソースコードを短くできたりする一昔前のプログラマーのような能力が求められる時代が来ると言われてるね >>837
俺、ゲーム作りたい派ではなく、システム作りたいぜ派なので、素材とかぶっちゃけない
全部デフォかシステムで作った四角や丸ばっかり
ウディタの時も、自作システムしか作らなかったし
>>838
俺、CPUやらの専門家ではないが
Cacheという言語があるだが、そこには"R 変数"で、入力を受け付けるというのがあるだが、こんなソースが早いとは思えないだが(ついでに初心者に対する可読性が悪い)、普通に"READ 変数"も変わらん気が・・・
問題は、コンパイラで高級言語をアセンブラに直した時に、ソースが長くなるのをどうにかすべきというところでは？
そもそも、スパコンで回すプログラムは、全部スパコン専用に設計しているから、元から、838さんが言っているみたいなことになっているぞ このようになにかというと「オレ知識も経験も豊富なんですよアピール」に持っていくマウント取りおじさんがどんな話題でも必ず湧いちゃうのが、このスレが過疎ってる大要因だと思った >>841
この程度の関係資料はググれはいくらでも出てくるし
スパコン関係かそれに類似する記事などをちゃんと読んでれば、誰でも思いついて書けるぞ
841さん、「俺の持ちネタじゃあ攻めきれないから、このおじちゃんきらいー」と言っているのと同じだぞ
ウディタで3D作っちゃう連中みたいに、知識や技術に対してもっと熱くなれよ もっと熱くなれよは同意だけど、ウディタのスレだし、
ここの住民にウディタ以外の知識を過度に求めるのは
何か違うような気もする。
ウディタ以外の知識がなくても楽しめそうな話題といえば、
ゆーいちゲームスのウルファールドというゲームオススメしたい。
https://www.freem.ne.jp/win/game/16343
ウディタ製でウルファールも登場するし、純粋にクオリティ高い。
しかも、ミニマルな設計だから、小規模でハイクオリティな作品作りたい時に、
参考になると思う。 >>841
しかも語句しか知らなくて中身が伴っていないからな
覚えたての言葉を使いたがる子供以下 >>844
勝手な推測だけど、836や840ってマウントとるおじさんを演じるのが好きなだけで
本気でマウントとっているわけじゃなさそうに見える。
後、煽るのもスレが過疎る原因になるし、
マウントとるのは基本的には自己評価が低いからって聞くから、
とりあえず、周囲を褒めまくれば周囲それぞれの自己評価が
上がって周囲がマウントとらなくなってWINWINだと思うし、
逆に煽れば煽るほど相手の自己評価が下がってマウント取るようになると思う。 掲示板で戦ってる暇があったら処理作ってる方が楽しいとは思う 残業や休日出勤したほうが効率いいって考える奴マジでいるんだな わざわざウディタのスレでマウント取りたいがあまりウディタと
関係ないスキル振りかざして「お前らそんなことまでウディタで
やるとか変態だな」とまで言うのは、いくらなんでもスレ潰しすぎる。
プログラミング言語の話がやたら挙がることについてもまぁそういう
理由なのだろうし、自己評価の低さから無意識にやってしまっているの
だとは思うけど、やはりこういう「自分のやっていることの意味すら
分かっていない害悪なだけの愚者」には、いい加減うんざりなわけで。 本人は園児達が三輪車でキコキコ遊んでるところにF1マシンで乗り込んできてるつもりなんだろう
実際は「えふわん」と書かれたステッカーを貼った補助輪付きの自転車だったとしてもな だから事実そうだとしてもわざわざ首突っ込んで言うあたりスレチだってわからないかな
スレ民から煙たがられて当然だよ なかよくしようや
3Dダンジョン作ってんだけど、デフォルトのマップエディタでダンジョン作るいい方法ないかな？ 私の公開している合作コモンもデフォルトのマップエディタで3Dダンジョン作れるし、
そのもととなった公式のコモン集にあるLucifaさんの3Dダンジョンコモンも
デフォルトのマップエディタでダンジョン作れる。
後、話題に挙がった気紛れ3Dダンジョンもデフォルトのマップエディタで3Dダンジョン作れる。
方法としては、ループ処理で順番に各マスのマップチップ番号やイベントIDを
変数の操作＋で読み込んで、予めUDBやCDBで設定しておいた
テスクチャを参照して表示するようにすると実現できる。
https://www.freem.ne.jp/win/game/18651 つい自分の合作コモン見てもらいたくて、合作コモン紹介しちゃったけど、
質問者の立場になって考えるなら、Lucifaさんのコモンを参考にするのが
わかりやすいかも。 現在位置を中心として周囲のマップチップを変数+で調査し
通行不能な場所を「壁」、それ以外を通路として読み込む感じなのかな
あとは読み込んだ「通路の状況」他に合うように画面を表示する、と
やり方を聞いてしまうと、素材があれば意外と楽なようにも思えるな 察するに昨日のＦ1も大筋の論理は一緒なのかな
あとは移動距離をてきとーに計算して
それが一定を超えたら次のチップに移動するとか？
道路自体のアニメをどう表現すりゃいいのかはさっぱりだが
描画して消してを繰り返せば、それっぽく見える気はする >>854
そんな感じ。
この読み込み方は、クォータービューとかでも使えるから、色々応用できる。
ぶっちゃけ3Dコモンよりクォータービューコモンの方が少ないから、
クォータービューのコモン出してみたら使ってくれる人いそうとか企んでる。
>>855
F1はカーブの感じ的にコースはマップを参照せず、
計算式で出しているように思えたけど、よくわかんない。 お手軽3Dダンジョンコモンは元々が旧基本システム用だし
そもそも導入自体がそれなりにウディタへの慣れを要する
入れるのに半日くらいかかったぜ
でもあまり凝った機能はいらなかったしあのシンプルさは
物凄く好みだったから頑張った マップイベントってセルフ変数に名前付けられないし
数も少ないから、イベントは基本的にコモンで作って
マップイベントはそのコモンの呼び出しに使う、
というやり方をしてる 店とかの施設も全部
これは妥当はやり方なんだろうか 店とかは汎用イベント用意するだろうから妥当じゃないか
セルフ変数に関しては、
コモンセルフは複数呼出時に共有されるんで
呼び出し元マップEvSelf使うことも結構あるけどね どこまでマップイベントでやって、どこから
コモンイベントでやるのかって線引きも
よくわからないでやってる
「こんにちは」って言うだけのNPCだったら
わざわざコモンで作って呼出さなくても
マップイベントで済ませればって話になるし
そこらへんの基準はどう思われますかしら ちなみに基本システムの話です
多少は改造もするけど よくわからないでやったものは後々コモンやDB化することが大半だったから、最近はコモン呼び出しで統一してる
会話なら分岐も含めて全体で把握しときたいのと修正のしやすさも考えコモン呼び出し一択です モブの会話が変わるようなイベントを考えていないなら
ＤＢに名前つける手間の方がかかるかもしれないからマップイベントで良いのでは
ストーリー展開で皆が喋る内容を変えるならコモン使ってＤＢから個別に呼ぶ方が楽
あとは乱数操作で会話変える場合なんかもコモンとＤＢ作る方がいい、両方やるなら尚更 あとは仲間キャラが固定じゃない場合に
仲間を混ぜて会話のドッジボールする場合もコモンとＤＢの形を取るべきかなあ
まあこれはそもそも面倒くさいのでやるかどうか自体考え物だけども にゃるほど
店とか会話程度のそのマップで完結するイベントなら
やはりマップイベントで済ませちゃった方がいいのかのぅ
品揃えとか会話内容が変わるにしてもマップイベントなら
ページ分けできるって特徴もあるわけだし
前にゲーム開始時のキャラメイクとかメンバー編成を
「どうせ最初しか使わないイベントだし」と思って
タイトルマップのマップイベントだけで作ったら
セルフ変数は足りないし文字列用もないから
えらい苦労しちゃった事があって
マップで完結する＆それほど大規模じゃなければ
マップイベントで済ませてよい、ということかしら むしろそのページ分けが面倒だからこそコモン化する感じかも
手間を省くために手間をかけるってやつ ページ分けも含めてコモンで一括処理できるようにしてるな
マップイベントの役割はEV番号の引数を渡す程度
DBでテキスト管理するにしてもエクセルで入出力するのがワンクッションある程度だし
それすらも面倒だったら外部テキスト読み込むコモン組めばテキストエディタのみで完結できて楽かも
どの方法を選ぶにせよ選択肢を知っておくのはいいことだ コモンイベントにせよマップイベントにせよ「数値や文字列等の
データはデータベースで管理すべきであって、イベント自体に
持たせるべきではない」ということをどこかで見た記憶がある
それがあるべき姿かもしれないけど「プログラミングスキルが
なくてもゲームが作れるツール」であるウディタを使う分には
そこまでカッチリしなくてもいいのかな、とも思う
基本システム自体にもNPCの会話用DBなんてデフォでないし >>845
840だけど、半年ぐらい、お世話になったウディタ民の知識の助けになればと思って、ここに居たけど
荒らす原因ばかりになっているから、消えるわ
俺の未練を切るために、講座が足りないと思って、載せていたウディタ向け資料も全部消す
ごめんな いい機会だから言うけど、
私は変態だなは褒め言葉や冗談として受け取ってたし、
マウントとるのを演じる人とは思ったけど、マウントとる人とは思ってないから
869に対して自己評価が低いとは思ってないっていうのは伝えておく。
かばい過ぎたらそれはそれで荒れそうだったしで、
あんまり巧い治め方ができなかった。
852の内容が不快な言い回しになってたら御免。 こういうタイプはどうせ消える消える詐欺だから気にせんでよし 割とどうでもいい
縁と周期が合えば一気に出来上がるけど縁が無いならそれまでだ 自分の劣等感を紛らわすために知識ひけらかしてマウント取りとか
自己満足のためにスレ住人見下して不快な思いさせてきたクセに
よく「ウディタ民の知識の助けになればと思って」とか言えるな
自分の行動見てもの言えよ 最後の最後まで不快だわ 昔作った処理を見直したら全回復が種類ごとに別コモンになってて泣けた あるある
DBとかも1つで足りるのに個別で作ってたり
後で気付いて直すのも…って状態になってる事多々ある >>877
分けるわけないと言えば、データを消去したりデータ数を減らしたりして数値を
初期値と同じ値に戻すときに、
DBタイプを敢えて分けておくと、この部分は消去して初期値に戻すけど
この部分はそのままにしておくとかもできるから、
どんな分け方するかは人によって好みが出るよね。
後、並列処理とか絡むときに、同じコモンを複数の並列処理が同時に呼び出すと
同じコモンセルフを複数の処理が共有することになってバグの元になるから、
並列処理用に同じ処理のコモンを二つ作る場合という状況もあったり。 ウディタに限らずだけど最初から綺麗なアルゴリズムやデータ構造を作るのは無理
途中まで作って「正解」が見えてきたらリファクタリング（または1から作り直し）で綺麗にしていくしかない そういう部分に関して参考になるような、
非圧縮のウディタ作品あったら教えてください >>878
あーそういう使い方もあるか！盲点だった
ピクチャの切替の処理でそういう並列の使い方はしたことあるな
あとでそうした事を忘れてる事あるけども 動きゃいいんだよ動きゃ！
そういう改善点は次作るものに活かせばええ
そうしないといつまで経っても完成しねぇし 同じような処理を１つのコモンにまとめるのと別コモンにわけるのはどっちがいいかね
例:文字列処理+としてまとめるかわけるか
文字列からN番目の文字を抜き出す
文字列からN番目以前/以降/より前/より後の文字列を抜き出す
文字列から計算結果を返す
文字列の行別最大文字数を返す
文字列の行数を返す
メリットデメリットなにが考えられる？ 基本的には「動けばいい」だけど、俺なら機能別に細かく分ける
その方が不具合が起きにくいし、起きても対処（特定）しやすいから
コモンイベントの数が増えるのがデメリットと言えるかもだけど
基本的に名前呼び出しだし、数が多くても別に困らないと思う >>883
自分は最初のと次とあと3つで計3コモンにするかも
3つのは入力コモン0/1/2で判定して貰う形にするかなあ
今使ってるものだと文字列/数値を互いに値によって変換するコモンは1つにしてる 精密/標準両者の斜め移動時って何ピクセル位移動してるか分かります？
いつも値分からなくてモヤモヤしてるのですが 斜め移動は横と縦が1マスずつ移動だから、単純にX軸方向にタイルサイズ分、Y軸方向にタイルサイズ分だけ移動。精密の場合はそれぞれの値が半分
タイルサイズはそれぞれの設定によるから知らん
>>883
同じような処理の範囲による
例えば俺だったら 文字を抜き出す処理は纏める(全部同じ引数と返り値で設定できる。更にコモンイベント名を「文字を抜き出す[位置]」とかにしておけば後から見返した時に分かりやすい)。
計算結果、行別最大文字数、文字列の行数は別にするかな。全部処理目的が違うか引数が違うし。配列とか行列で返せるなら行数と行別最大文字数の2つは纏めるかな。セットで使うことが多そうな気がする 私なら
>>883の5つを上から順にA~Eとすると
・全部別々に作る
・DとEは別々に作って、第六のFコモンでDとEを呼び出す形にする
・Bのコモンは、Aを呼び出す処理を使用して省略
・Cのコモンは、A、B、Fを呼び出す処理を使用して省略
で計6コモンにするかも 質問です
斜めからの会話をできなくさせることは可能ですか？ 変数操作＋で主人公のXY座標と呼び出しマップEvのXY座標を
それぞれコモンセルフ代入して
条件分岐で主人公のと呼び出しマップイベントのを比較して
XYのどちらも違ったら1を、XYのどちらか片方でも同じだったら0を
返すコモンを作って置き、
会話イベントで呼び出して、マップセルフに返り値を代入、
そのマップセルフが条件分岐で0だった場合のみ台詞表示にする方法が
考えられる。 繰り返して書く処理は別コモンにして修正しやすくして
似通った目的で設定項目も同じならコモンをまとめて使いやすくする感じ？
これでいいとこ取りになってるかな 「入力値だけ違って構文自体はほとんど変わらない」なら
コモン分けるのも容量の無駄なのでまとめていいと思う
「機能も構文も異なるコモン」なら、下手にまとめちゃうと
不具合起こしやすくなるし調査も大変になっちゃうので
なるべく細分化した方がいいんじゃないかな
つまり、なるべく無駄なく分かりやすく どこまでまとめてどこから分離するかは経験値の世界だから理屈にするの無理だと思う 機能ごとにコモン作ったら呼び出すとき探しづらいじゃん どこで分けるか判断できない
機能を把握できない
要するに知性が足りずないない尽くしのお前が悪いって事だ 把握できないのはエディタの機能不足が原因だからウディタやめてプログラミングやったほうがいいよ というかそもそも他の人にとってやりやすいやり方が自分にとってやりやすいとは
限らないし、好みの問題だからいいとこどりや正解なんてないと思う。
特に気にせずやりたいように作ってたら、やりやすいやり方が見つかると思うし、
それよりもモチベーションが大事だと思う。
モチベーションがあれば、それだけ経験をつんでいけるし、
経験をつんだ分理屈を理解できるようになる。
後、機能を把握できないのは逆にその人にとって機能が多すぎるからだと思うよ。 意見くれた人ありがとう
今まで通り自分なりに作っていきます 変数で主人公とかのキャラクターの向きって変えれましたっけ？
動作指定くらいですかね ウディタってサンプルに使われていないデフォ素材多すぎ
と思ったけど落ち着いて考えたらツクールもそうでした アイテム回りを改造して、キャラ別に管理しようかと思って途中まで進めたんだが
面倒くさい割に得られるものが乏しいな
キャラを選ぶために様々な場面でプレイヤーの手間が増えてしまう
個数制限や種類制限をつけるにしても別の手段を使う方が良い感じだなあ レス数が900を超えています。1000を超えると表示できなくなるよ。
