百合フリーゲームとボカロ曲のL-Drive - フリーゲーム・ボカロ曲・Webアプリなどを作っています。

Blog ブログ

ブログ

  • ブログTOP
  • 『エンジニアが考えるウディタで良いシステムを作るための3つのルール』

エンジニアが考えるウディタで良いシステムを作るための3つのルール

投稿日時:[2017/10/31 20:33]

コメント:[0]

最近、UnityやPhina.jsに転向したので、ウディタの使い方を忘れてしまう前に、自分なりのコツ的なものを書こうと思う。

狙ったタイトルを付けてみたものの、そんな大層な内容ではないので、身構えず読んで頂ければ。

背景

プログラミングだと、成果物がコードとなって転載しやすいので、Qiitaのような場で盛んにナレッジ共有ができる。
ウディタはそれが難しいため、各自が独自に試行錯誤する必要があり、界隈全体としての技術力を上げるのが簡単ではない。

自分も昔、講座動画を作ったりしたが、正直今見返せばイマイチな内容を紹介しているはずなのでおすすめできない。
こういう古いものが未だに参考に使われるのは、嬉しい判明、良い状態ではないと思う。

で、その後エンジニアになったりなんだりしてウディタでの組み方も変わってきたので、
今回は自分が最終的に大事だと思ったポイントを紹介したい。

紹介するものが「正解」ではないので、真に受けずに「そういうやり方もあるんだな」程度に流し読んでほしい。

特に、自分が作ったシステムにバグが出やすい人に読んでもらいたい。
たった3つです。

その1. 「並列実行」なコモンイベントは2個あれば十分!

ウディタでシステム自作している人の中で、「並列実行」のコモンイベントがたくさんある人は、
「並列実行」を2個、その他全てを「呼び出しのみ」で縛って作ってみよう。

この縛りで組み替えても、全く同じ処理が実装できるはず。

並列実行が沢山あると、「いつどこで何の処理が動いているのか」を把握したり制御するのが困難になる。

並列実行のうち一つは、「変数操作+」で取れる「マウス座標」みたいな何度も使う値をグローバル変数にぶっこむだけの処理。

これは常に動き続ける。

もう一つはゲームの始まりから終わりまでの全ての処理が入る「メインスレッド」的なコモンイベント。

こっちは例えば、タイトル画面から始まり、ステージ選択画面でユーザー入力を待つ間止まったり、ステージをクリアするまでループしたりする。

このとき、メインスレッドに全ての処理を長々と書いてほしいという意味ではない。
むしろその逆で、沢山の「呼び出しのみ」イベントとして分割してほしい。

詳細は次の項目で。

その2. コモンイベントは「機能ごと」に細かく分割!

もし「100行を超えるコモンが何個かある」な状態の人は「少ない処理数のコモンが大量にある」状態を目指すといいと思う。

分割は「機能ごと」に行うこと。
「そのコモンは何を渡すと何が返ってくる(何が起こる)のか」を明確にする。

試しに自分が実装したコモンを一つ言葉で説明してみて欲しい。

例えばだけど、「このコモンは文字列を渡すと、その文字数がカウントされた結果が数値型で返って来る」みたいに役割を簡潔に説明できるような状態が理想。

また、コモンイベントの分割は単なるグルーピングだけが目的ではない。

「そのコモンイベントは、与えられた役割に責任を持つこと」、
「役割と関係ない処理を請け負わないこと」が大事。

つまり、そのコモンイベントが呼び出し前後のケアが前提で機能していたり、
そのコモンイベントを呼び出すことで別の目的まで一緒に達成できるようになっているのはよろしくない。

その1、その2までを意識するだけで不具合そのものも減ると思うし、
「いつどこでどんな処理が動いているのか」が自分で把握しやすくなるので、不具合の原因の特定も容易になる。

余談だけど、「呼び出しのみ」イベントを呼び出すとき、「イベント名で呼び出す」を使うと、コモンイベント一覧の並びを変えても大丈夫になる。
「イベント名で呼び出す」がウディタの内部処理的に重くなるのかどうかは不明。

その3. データはDBに!

コモンイベントには「処理」のみ入れること。「データ」は含めてはいけない。

例えば「敵に攻撃が当たったらHPが15減る」ってのを実装するとき、
「敵に攻撃が当たったかどうか」の処理は当然コモンイベントに書く。
次に、「HPが」「減る」も処理なのでコモンイベントに書いてオーケイ。

「15」。これはダメ。この数字はデータなのでDBに入れよう。
コモンイベントではそれを呼び出して使うこと。

ただ、これは完璧にやり過ぎると逆に不便になったりするかもしれないので注意。

DBの設計は話しだすとキリがないので、綺麗にいかないならデフォルトシステムを参考に。
新しいデータを増やすとき、DB自体を増やすのか、項目を増やすのか、行を増やすのか、よく考えよう。

「DBをもっとかっこよく設計したい」という意欲が有り余っている人は「第三正規化」などで検索してみるとよいかも。

ウディタのDB設計でも参考になると思う。

おまけ. マップイベントは不要!

おまけとしたのは、これは全ての場合には当てはまらないため。

ウディタには、移動やマップイベントに関する処理が本体に組み込まれている。
しかし、これを必ず使う必要はない。

自分の場合

自分の場合、キャラクターの描画から移動処理まで一通りコモンイベントで実装している。
そうしないと、RPGはともかく、アクション要素のあるゲームを作るなら、ウディタ側の制約の中で実装することになり、逆に難しいと思う。

マップへの敵キャラの配置もマップチップを用いて行い、コモンイベント内で置き換えている。(画像参考)

もしマップイベントにマップ固有の処理を書く場合でも、実際にそのイベントの発火・実行を行うのはコモンイベントとしている。

おわり

色々書いたものの、最終目標は皆「ゲームを作る」だろうし、基本的には「動けばいい」でいいと思っている。

もし、バグが出やすくて困っている人や、中身に対する改善意欲のある人は「その1」〜「その3」を意識してみてもよいかもしれない。

「バグが多いのはデバッグ不足だ!100回テストプレイしろ!」のような体育会的精神を唱える人もいるが、自分は同意しかねる。

どうしても苦手な人の手段としてそれはアリだけど、最初からバグが出にくい組み方を模索する方が効率がいいはず。

なんなら、相手が「お客様」じゃない以上、その辺のケアに身を削るより次の作品に時間を使うほうが健全だと思う。

話は逸れましたが、そんな感じで以上です。
ありがとうございました。

    コメント(0)

  • まだコメントがありません (お気軽に書き込んで下さい)

ツイートする

Game

スピネルの魔法工房

NEW

Game

Dirty Darkness

Game

The Dragon Throne

Web

オンライン 絵しりとり

Game

マイムの見た夢

Vocaloid

マッドパンプキン

おすすめ

Vocaloid

ドクターリブラ

Game

リブラの見た夢

おすすめ