これが最初の投稿になるのかな。人生、中年になると色々昔のことを知っていて、どうしても今を昔と比べてしまう。同じゲーム開発においても、昔と違って、今の開発者は幸せだなと思う今日の今頃です。つい最近、若い人たちにこう言われたんだ。なんで昔こんなしょぼいグラフィックでこんなシンプルな内容のゲームの開発でも、ゲーム単価カセットが1万円を超えたんですか?ってね。

今じゃこの内容は300円も価値ないですよ。ってね。本来、ここで少しムッとなるところですが。まあでも、彼の話はよくわかるんだ。

例えば、今更スーパーマリオブラザーズみたいなゲームをスマホで出したら、どれだけの人が数千円のお値段を出して買うのだろう。そりゃそうだよな。一つのゲームをわずか十数分、あるいは数十分でクリアしてしまうからだ。続にいえば、プレイ時間のパフォーマンスは非常に悪いということになる。

でもね。昔はこの程度のゲームの開発でも、ものすごく苦労したんだ

今の若い開発者たちには分からないだろうな。

SFC(スーパーファミコン)の時代のゲーム開発は、現代とは全く異なるものでした。当時は現在のような高機能な「ゲームエンジン」は存在せず、開発者たちは非常にローレベルな環境で、文字通りゼロからゲームを構築していました。

SFC時代のゲーム開発の様子

  • 開発環境:
    • 専用の開発機材: 各ゲーム会社は、SFCのロムカセットにプログラムを書き込んだり、動作を確認したりするための専用の高価な開発機材を使用していました。これは一般の人が手に入れられるものではありませんでした。
    • ホストコンピュータ: プログラムの作成やアセンブル(人間が書いたコードを機械語に変換する作業)、グラフィックデータの作成などは、PC-9800シリーズなどの当時の高性能なパソコンで行われることが多かったようです。
    • ROMライター: 作成したプログラムやデータをSFCの実機でテストするために、ROMカートリッジに書き込む専用の装置が必要でした。
    • ICE (In-Circuit Emulator): ソフトウェアのデバッグ(バグ取り)をハードウェアレベルで行うための非常に重要なツールでした。CPUの動作をリアルタイムに監視・制御し、問題箇所を特定するために使われました。
  • プログラミング:
    • アセンブリ言語: SFCのCPU(65C816)の性能を最大限に引き出すため、プログラミングは主にアセンブリ言語で行われていました。アセンブリ言語はCPUの命令に直接対応するため、非常に高度な知識と技術が必要とされました。
    • C言語 (限定的): 一部の開発では、C言語などの高級言語が部分的に使用されることもありましたが、最終的にはアセンブリ言語に落とし込む必要がありました。
  • グラフィック・サウンド:
    • ドット絵: キャラクターや背景などのグラフィックは、ドット単位で手作業で描かれていました。専用のペイントツールも今ほど洗練されておらず、非常に時間と根気が必要な作業でした。
    • サウンドプログラミング: 音楽や効果音の作成も、SFCのサウンドチップの仕様を深く理解し、レジスタを直接操作する形でプログラミングされていました。現在のゲーム音楽制作とは全く異なるアプローチです。
  • ゲームロジック・物理演算:
    • 自力実装: 衝突判定、キャラクターの移動、AI、アイテムの管理など、ゲームの根幹となるロジックや簡単な物理演算も、プログラマーが全て自分でアルゴリズムを考え、実装する必要がありました。ライブラリやミドルウェアといった便利なものは存在しませんでした。

ゲームエンジンがある現代との省力化の比較

現代のゲーム開発で利用されるゲームエンジン(Unity、Unreal Engine、Godotなど)は、SFC時代と比較して圧倒的な省力化をもたらしています。例を挙げると:

  • 開発環境の統合: プログラミング、グラフィック編集、レベルデザイン、サウンド管理など、ゲーム開発に必要な機能が一つのソフトウェアに統合されています。
  • 豊富な機能とアセット: 物理演算、衝突判定、AI、アニメーション、GUI(ユーザーインターフェース)など、多くの機能が標準で提供されており、すぐに利用できます。また、アセットストアなどを利用すれば、高品質な素材を比較的安価に入手できます。
  • 高級プログラミング言語: C#、C++、GDScriptなどの高級言語で開発できるため、アセンブリ言語のような低レベルな知識は必須ではありません。より抽象的な思考でゲームロジックを記述できます。
  • クロスプラットフォーム対応: 一つのプロジェクトで、PC、スマートフォン、ゲームコンソールなど、複数のプラットフォーム向けに同時に開発を進めることができます。
  • 豊富なドキュメントとコミュニティ: ゲームエンジンの使い方に関するドキュメントやオンラインの情報が豊富であり、世界中の開発者コミュニティからサポートを得られます。
  • ビジュアルな開発: マップエディタやアニメーションエディタなど、視覚的にゲームを構築できるツールが充実しており、プログラミングの知識が少なくてもある程度のゲームを作ることが可能です。

省力化の度合い

具体的な数値を出すのは難しいですが、体感的にはSFC時代の開発に比べて、現代のゲーム開発は数倍から数十倍の効率化が図られていると言えるでしょう。

例えば、SFC時代に数ヶ月かけてアセンブリ言語で実装していたような基本的なキャラクター移動や衝突判定の処理は、現代のゲームエンジンを使えば、わずか数行のコードを書くだけで、あるいはGUI上で設定するだけで実現できます。

グラフィックに関しても、SFC時代は職人がドットを一つ一つ描いていましたが、現代では高解像度のイラストや3Dモデルを制作し、それをエンジンに取り込んで様々な表現を比較的容易に行うことができます。

もちろん、現代のゲームはグラフィックやゲームシステムが複雑化しているため、開発規模自体も大きくなっている傾向はありますが、もしSFCレベルのゲームを現代の技術で開発するとすれば、SFC時代よりもはるかに短い期間で、より少ない人数で完成させることができるでしょう。

まあ、そういう意味ではゲームエンジンの登場は、個人や中小規模のチームでも高品質なゲームを開発できる可能性を大きく広げ、ゲーム開発の民主化に大きく貢献したと言える。スーパーマリオブラザーズレベルのゲームでも、昔は数十人、百人を超えるスタッフで開発していたんだ。それを端的に言えば、今のゲームエンジンを使うことで、おそらくひとりの人間がわずか数日で開発できてしまうだろうね。

さらに遡ると、テトリスというゲームあれ、こんなもの、今や人工知能で「テトリスというゲームをつく」ってという言葉を話しかけると、すぐさま数10秒でコードを書き出してくれ、ゲームになるじゃないかと言われると思う。でも、このテトリスも当時、ものすごく頑張って作られたと言われている。

よく昔のファミ通もそうだし、ゲーム雑誌でこういうこと言われていた。

「最新のグラフィックを実現できる。この新しい新機種で、開発費も膨大に膨れ上がる」

これを見て、もしかしてゲームの販売単価が上がるんじゃないかって皆さん思ったりしませんでしたか?シェンムーの開発費が、ハリウッドの映画並みだとか。そんな話をする時代もありましたね。でも、ふたを開けてみれば、実際、ゲームの販売単価は変わりませんでした。

これは単純に、ファミ通のスタッフがゲーム開発をよく知らなかったのか、あるいはゲーム開発者にそう吹き込まれたのかと思言うと、実はそうではない。

そう。ファミ通の人間は、私と同じ。おっさんだからだ。おっさんの価値観からしたらゼロからゲームを開発してここまでのゲームを作るとなるとコストが凄まじいことになるという、が凄まじいことになるという固定観念からの計算なのだろう。

当然、シェンムーを作るころには、シェンムーを作るころには、かなりのゲーム開発会社がインハウスソフトウェアという、要は非公開の自分らしいしか使わないゲームエンジンを持っていたんだ。これをベースに開発したんですね。

単純な話、ストリートファイターというゲームがあるとしよう、というゲームがあるとしよう、二作目を作るとなると、ほとんどの主要キャラクターは一冊目のコピーと同じです。もし作り変えるとしても、フレームを増やしたり、新しいアクションを増やしたりと、プラスアルファの要素を取り入れるだけです。ベーシックな根幹はできており、アイディアもストーリーも背景もすべてできております。そこから増やすのは、難しいことではない。これを数値化にするのはなかなか難しいことですが。強引に数値化をしたらこうなる。

作品グラフィックアイデアプログラム労力合計
1作目100100100300
2作目10101030
3作目20102050

これはれは格闘ゲームの極端な例ですが、格闘ゲームの極端な例ですが、例えば最初のゲーム開発を300人の人間が一年間をかけたとしよう。それを労力の合計では300にします。二作目だと、わずか30人でことが足りることになります。さすがにダレるので、3作目は少し増やして50人という具合です。

もちろん、RPGのようなゲームに関しましては少し違います。

これからAIがゲームを開発するとなると、もっと話が変わりますが。3Dゲームでもだいぶいろんな3Dオブジェクトの再利用が利いて、金額や開発用の省略ができるんじゃないかと思う

もちろん、昔と一つ異なるのは、ゲームエンジンの開発元に上納金という形で払わなきゃいけないということです。例えば、売上が100万円あったとしよう。売れた金額が多ければ多いほど、上納金は払うように今なっているはずです。最大で半分は持っていかれるはずなので、100万円の中の30万円はUnityあるいはUEに払うことになります。さらに、公開しているプラットフォームに対してもお金を払わなきゃいけないので、単純に売却金額であればたいした金額にはならないが、例えばアイテムを売ったり、あるいは定期的なサブスクという形でのゲーム収入であれば、AppleのプラットフォームあるいはGoogleのプラットフォームに対して3割を払わなきゃいけないのです。

結果的に。

ゲームエンジンの登場によって、開発が大幅になくなりました。でも、開発者の生活が苦しくなりました。

ということが落ちです。それでもあなたはゲーム開発をしますか?

投稿者 nobodycareblog

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です