ブログ｜okajimania BROG

[PR]

2024年11月06日

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

[短期連載] Unite に参加して思う、ゲーム開発の敷居が低下したことの功罪 (第2回)

動画が公開されるまで待ってました。
ということにしてください。一気に終わらせるので。

注意

別に Unity をディスりたいわけでも、Unity で開発している人をディスりたいわけでもないです。
そこらへんをご理解ください。

ゲーム開発の敷居が下がって起きた事

とにもかくにも、とりあえず動くところまでが凄く簡単になりました。
main() から実装するサンプルゲームは地獄のように面倒くさいんだぜ？

これはつまり、プログラマの仕事がぐーんと減ったということなんです。

複雑なゲームを作ろうとしたら、やっぱり大変なんだけど…

旗違いだけどプログラマ以外の職種について

企画？何それ、食えるの？
- 専業で企画を考える人を見たことがないので知りません。多分、自分でプロトタイピング出来るようになったので楽になったはずです。
デザイナーは、ツールなどが便利になっていくのでちょっと楽になってます。
- ドット絵、ローポリ、減色などの職人芸の必要性が以前よりも薄くなっているのは良いことです。
- ただしハイエンドでは要求される映像品質が高くなってく一方なので、作業量が加速度的に増えて大変になってます。
サウンドの仕事は…
- FM 音源や矩形波を駆使していた頃から、PCM 音源を流せるようになったあたりですごく楽になって、以降はそれほど変わっていないみたいです。
  - 最近は立体音響などの複雑なことをせにゃなりませんが、ミドルウェアの充実でデザイナーほどコストが高くはなっていません。

とりあえず動いちゃう問題

これが大問題。
以前は優秀な人材が修行を経て「頑張って動くようにするところから始めていた」から必然的に水準が高くなりがちだったのですが、Unity を使ってるとトーシロがそれなりにゲームを作れちゃうんですよ。

こんなに簡単！
- ググれば大抵のことは解決する
  - 自力で悩んで解決する機会が減る (で調べても解決しない高難易度な問題にぶち当たる)
  - ちょっとした内製ツールは”多少問題があっても許される”
  - C/C++ より圧倒的に生産性の高い言語でスクリプトを書くので、生産するのは早い。
    ※ メンテナンスなどのコストは実はあんまり変わらない。(体感)

でも、”プログラムは難しい” というステレオタイプにより、非プログラマから見るとプログラマは 凄い人 です。
ちょっとした要求に応じると、割とすぐに褒められちゃいますよね。
だから ”書いたコードが動いたから OK” になりがちで、そこから先に進まないんです。だから、動作チェックとかテストとかをしません。

だからこうなります→ Unite2016: Unity上級者を目指すなら知っておくべきデバッグテクニック集
 Movie はこちら(YouTube)

多分、オッサンプログラマは「いまだにこんなレベルの話をしないといけないのか」と思うでしょう。
「バグを定義しよう」とかはゲーム業界特有の問題で、そこは凄く重要だと思いますが、それ以外は初歩の初歩…以前です。

なんでこんなに低いのか?

多分、ゲーム開発とか Web 開発とかの浅い経験がない方がプログラムを書いているケースが多いため、
ゲーム以外のプログラミング業界では成熟されていったソフトウェアテストの技術を活用していないんでしょう。

ソフトウェアテストって、

(最初は) コード量が多くなるので面倒くさい
難しく畑違い（と思う）のことだと思われがち
そもそも、ゲーム業界では伝統的に実装以外の作業が軽視されてきた、だから他の人も勧めない
(これが、ゲームプログラマ最底辺説の根拠のひとつだったりします)

という事情でゲーム業界での導入が遅れてたんです。
結果、問題が発生してから場当たり的に不具合修正を行うことを繰り返して、無駄に時間を消費して開発コストを増やし、アプリの品質を低下させてるんです。

バカだろ、お前ら！ (けなし言葉)

※ 最近の AAA タイトル開発ではめっちゃ重要視されています。

ではどうすれば良いのか？

ソフトウェアテストの本を数冊読んでみましょう。図書館には大抵ありますし、それを斜め読みするだけでも十分です。
実践する前に、たまには座学をして見るのも良いものですよ。

僕だって世間一般から ”激務” と呼ばれる状況でも、

きちんとランタイムチェックを行うようにして、(状況によってエラーと Assert を使い分ける)
その内容に応じた単体テスト書いて、
その上下のレイヤーとの結合テストを書いて、
システム全体を通しての動作確認プログラムを書いて、

それでも報告される不具合を解析、修正したものです。
これは面倒なことではなく、不具合が起きることがプロジェクト全体に与える悪影響を知っているから「やっといた方が楽」なんです。
でも小規模の開発チームで少数のプログラマしかいない環境では「その時の作業が増えるから」という理由でスルーしちゃうでしょう。だいたい新人はそうする傾向がありますし…

それを改めて啓蒙しないといけない状況というのが Unity を取り巻く現状の課題といえるでしょう。

ということで、続く。