■サイト[SilverSecond]トップ
■開発日誌トップ
■ 2017/01/14 (土)  ウディタの今後の話など ■
【ウディタの今後の話など】

内々では色んなことが舞い込んできていて大騒ぎしているところですが、
開発日誌ではまだ言えないことばかりなので、今回からしばらく
皆さまからお寄せいただいた質問やネタにお答えしていきます!



今回はWOLF RPGエディター(ウディタ)の話題です。
なおウディタは、現在、最新版Ver2.20のβ版をバグ報告スレッドで公開中です。
そろそろリリースできるかと思いましたが、またバグが山積みになっています。
バグ報告してくださる皆さま、いつも本当にありがとうございます!



>ウディタの有償化するかしないか、今後のサポートの方向性を知りたいです。
>要望の機能を実装するのか、不具合の修正に集中するのか等……。    .


これは答えによっては物議をかもしそうなご質問!
ですが不安な方もいらっしゃるかもしれませんので、
一度明確にしておいたほうがいいかなとも思います。

今の私の率直な心情としては、サポート期間のいくらかの生活費くらいはまかなわないと
餓死する気がしはじめているので、少しはウディタを収益に繋げた方が続けやすいだろうな、
という考えを持ちつつあるのは事実です。

例えば2016年だけでサポートにまるっと2~3ヶ月分くらいボランティアで修正しているので、
年収の16%~25%を失いながらサポートしてると考えるとこれはなかなかです。
世知辛いですが、年を取るほどボランティアに使える時間も短くなっていますしね。

といっても、いくらかの生活費のためだけに
利用者の大多数がガッカリしてしまうようなやり方は私もガッカリなので、
基本的には従来の利用者の皆さまに不便のないようにサポートを続けるつもりです。
となると仮に有料の何かが出ても、無料で使える範囲は以下の通りであり続けたいと考えています。


【ウディタが無料で使える範囲の方向性】

・今後新たに搭載された新機能はこれまで通り使用可能。
・もちろんバグもこれまで通り修正を続ける。
・今後の最新バージョンもずっと使用可能。
・ご要望には元々あまり対応してない気がします。
(ごく低コストで実装できるものと自分が賛同したものなら入れています)



この範囲を維持して何か収益化に繋げるなら、「元からなかった部分を使えるようにする」とか、
「関連する成果物を販売する」とか、あるいは「カンパ」など、そういった感じになると思います。

「関連する成果物」ならばたとえばグッズはどうか……と思っていたんですが、
メタルストラップはまだ黒字になってないのでなかなか難しそうです。

「カンパ」はおそらくやり始めた頃に少し入るだけで、それ以後は低調になり、
割とすぐにカンパ窓口の存在意義がなくなる状態になると予想してます。
→1/14 23:46追記:法律的にややこしそうというのも懸念事項の一つになりました。
カンパは寄付扱いになるんでしょうか。少なくともPayPalさんではアウトらしいです。

カンパに似た方向性として、「Enty」や「ファンティア」といった支援系サービスもあるんですが、
これのリスクとして期待の金額が集まらないまま
コンテンツ提供を続ける必要が出る可能性を見ていて、
精神的・労力的な負担をこれ以上増大させたくないとの考えから今のところは見送っています。
(全年齢ゲーム開発者は月1万円の支援のボーダーに達するのも難しい印象があります)

その他、色々と案を考えているところですが、何にせよ、仮に収益化するにしても
皆さまにご不便をおかけしないやり方でやりたいなと考えていますので、
そういった点でご心配な方はどうかご安心ください。



>ウディタ2.20が正式版になった暁には         .
>【C言語とRubyとウディタの計算速度】(2009/02/13)
>を再度検証して欲しいです。貴台自身で論外と評した
>ウディタの速度が現在どれだけ改善され、また    .
>Rubyの速度にどれだけ迫っているのか気になります。


これ意外と手間がかかるので私はやりたくないです!
興味がある方はぜひやってみてください。
私は前回、変数操作の10万回分くらいを計算したんですっけ。

推測としては、VXAceなどの最新のRGSS3ならば
ツクールXP時代のRGSSよりだいぶ速くなっているらしいので、
1処理の速度比では以前と同じくウディタが最も「遅い」と思います。

ただその割には、「ウディタ製のゲームは軽い」と言われることも少なくありません。
ウディタが軽いと言われるのは、DXライブラリで言うところの
「グラフィックカードの3D機能」を使っているからという部分が一番大きいと思います。
以下は技術的な解説です。

旧来のRPGツクールはプレイヤーの環境によって差異が出ないよう、
CPUを使って描画していると思うのですが、ウディタはその差異が出ることを覚悟で
CPUでなくグラフィックボードを使って描画しており、そこで速度の優位さを獲得していました。
(ウディタで「ソフトウェア描画」にすると、旧来のツクールと似た形式・重さになると思います)

・たとえば毎秒60フレーム、つまり1枚あたり16ミリ秒ごとに更新して動かす前提で、
仮にツクール側がCPUによって8ミリ秒かけて画面を描画していたとすると
コマ落ちさせずにイベント処理に使える時間は16-8=残りの8ミリ秒のみです。

・ですが描画をグラフィックボードに任せた場合はまるっとCPU時間が空くっぽいので、
イベント処理に使える時間が8ミリ秒からほぼ16ミリ秒まで伸びるため、
2倍の量のイベント処理を実行しても処理落ちしなくなります。
これら数値は仮のものですが、仕組み的にはこれがウディタの得ていた優位性です。


なお最新のRPGツクールMVはOpenGLでグラフィックボードによる描画をしているようなので、
従来のツクールみたく、描画で処理時間を喰っていた問題もカバーされていると思います。
イベント部分はJavaScriptで動いているので速度については分かりませんが、
気になる人はJavaScriptの処理時間も比較してみても面白いかもしれませんね。
私はMVのゲームがブラウザで動かないことが多いのであまり試せていません。悲しい。



ということで、今回はウディタに関するご質問にお答えしました!
色んなご意見ご質問をお寄せくださっている皆さま、本当にありがとうございます!

引き続き、開発日誌で話して欲しいネタやご質問など、
拍手コメントから受け付けております。
答えられるものでしたら取り上げていきますので、
無茶振りと感じられそうなものでも何でもどうぞ。
関連記事