ゲーム開発環境がunityに移った理由

もともとはツクールmvでゲーム作成していたが、この一年でpygame、unityを触ってみた。

結果からいうと下記のとおり。これには個人的な偏見も含まれていますので注意。

そして結局、今のところ最適なのはツクールｍｖだなと思って、ブーメランのように戻ってきました。プログラム開発ツールは全てvscodeを使用してます。

※なんてこともあったけど、現在はunityを使ってます。理由は追記しました。

pygameはなにがイマイチだったのか？

本当はpythonが好きなのでpygameでゲームが作りたかったのだが、クロスプラットフォームではないので、作れてもwebですぐにプレイできない。ダウンロードしてプレイしてもらうという形式しか取れず、プレイヤー側としてはイマイチ。

そして、tiledMapEditorでマップ作成をするのだが、イベント作成は困難でわかりにくくなることがわかった。困難でわかりやすいならいいけど、わかりにくいのは致命的。

さらにlinux上で作ってましたが、この環境がどうにも慣れなかった。よく誤動作を起こすし、使いものになってないというのが正直なところ。極端に使えるソフトが少ないという点もかなりのマイナス。そこで、windows＋unitiyにしてみました。

unityはプログラミング言語が好きじゃない

hddからssdへわざわざ買い替えて挑みましたが撃沈。C#というプログラムの書き方もまったく好きじゃない。

なんでわざわざVBみたいに型を指定しなければいけないのか？なんで末尾に;（セミコロン）がいるのか？pythonはそういう煩わしいのは一切ないんだから、実現してくれよと言いたい。

型なんて変数名で明示すればどうとでもなるではないか。配列ならlistとか、辞書型ならdistとか付ければいいじゃないか？なのになんでわざわざ型指定してセミコロン。voidなんかいらないだろ。空なんだからいちいち明示させるなっての。面倒くさすぎるという感じ。

しかし！それだけが原因というわけではなかった。その不満はあったが、unityには将来性がある！と踏んでいた。ツクールは悪い言い方をすれば作られたＲＰＧという枠から外に出られないツールだ。同じようなものが量産され、ツクラーは元のツクールをどうやって崩していくかが求められる。

それに対してunityは変幻自在というか、可能性が高い。機能が多すぎるぐらいだ。さらにクロスプラットフォームに対応しているからスマホアプリとして世に出せる。これからはunityだぜ！…などと思っていたのだが致命的な問題が発覚。それが再生までの時間だ。

unityはゲームの再生まで時間がかかる

unityのデバッグの流れを見ていくと、こうなる。vscodeデバッグの開始→unityウィンドウに移動→コードがunity側に反映するまで待つ→unity再生。

さて、なにが問題なのか。入門サイトを見ながら、順調にコードを打ちこんで学んでいくぶんには問題はあまり感じられなかった。しかし、入門サイトに頼らない段階となると話は変わってくる。その段階になると、少しコード変更してデバッグ、少しコード変更してデバッグを繰り返す。

そこで気になってくるのが再生の遅さだ。移動する手間やコード反映するまで時間もかかるが、さらにこいつ、あろうことか頻繁にフリーズまで起こす。そのとき自分はこう思った。「あ、これ、ダメなやつだ」と。

デバッグがスムーズにできないのは致命的である。さらにさらに、unityはアツマールに投稿してもコメントがいっぺんに流れたり、音量を操作できなかったりする。それをどうにかするAPIもあるらしいが、情報が極端に少ない。つまり…そういうことだ。察しと諦めの悪い自分は一生懸命、他の道を模索したが無理だった。

いや、お前バカだろ？unityroomでいいじゃん。そう思うかもしれない。が、unityroomはコメントが極端に少ない。スマホプレイヤーがほとんどなのでフィードバッグが少ないことは数値から見て取れる。自分はフィードバッグを受け取りたい派で、それによってゲームをよりよくしていきたいのだ。だからアツマールが最良だと思った。