本ページには広告・プロモーションが含まれています。
「ゲーム開発の言語はどれが良いのでしょう？」この質問はゲームプログラミングの FAQ のひとつです。掲示板などで1週間のあいだに何度も聞かれます。この質問はよい質問に分類されますが残念ながら簡単にひとつの答えを与えられるものではありません。
この記事ではゲームプログラマーに人気のある言語をいくつか取り上げ、ゲーム開発で用いられる主なプログラミング言語の概要とプロジェクトにとって長所または短所になる状況を提供します。
紹介する言語のリストは完全でも詳細でもありません。初心者にはなじみのない用語が多く含まれていますが、不明な用語についてはウィキペディアなど外部の情報を参照することをお勧めします。
この記事があなたの迷いを助けてくれることを願います。
目次
オペレーティングシステムやソフトウェア オフィススイート、コンピューター自体と同様に多種多様なプログラミング言語が存在します。多様性の理由は すべての問題を解決する単一の解決策は存在しない からです。
速度が優れている言語もあれば、クラッシュに強いコードを簡単に作成できる言語もあります。テキスト文字列の解析に非常に優れていたり、サーバー上で効果的に機能する言語もあります。 また、企業投資の観点から書き換え不可能な大量の既存コードがあるため長年使用されている言語も存在します。
言語の選択はプロジェクトに影響します。完全に(または少なくとも非常に広範に)書き換えることなしにプロジェクトの途中で言語を変更することは不可能であるため、言語の選択は慎重に行われます。 あなた自身の個人的な好みや友人のおすすめだからといって選択してはなりません。 プロジェクトに使用する言語の選択は十分に研究され実用的でなければなりません。 最も重要なのは結果の品質であり、開発者にとって使いやすい言語ではありません。
もしも FORTRAN と COBOL が初めのコンパイル型高級言語であるなら C は彼らの孫にあたります。1970年代にデニス リッチーによって ALGOL の後継者として開発されました。ゆえに FORTRAN, COBOL の後継者とも成りました。C は ALGOL よりも小さくて単純なバージョンであるように設計されていて、オペレーティングシステムのようなシステムレベルのプログラムを記述することに適していました。それ以前、オペレーティングシステムはアセンブリでコード化されていて持ち運べるようなものではありませんでした。 C はシステムレベルのコードの携帯性を現実のものにした最初のプログラミング言語でした。
C は構造化プログラミングをサポートする言語です。C のプログラムはモノリシックな大量のコードで GOTO 構文によってプログラムの流れを制御するのではなく、関連性のない関数達を呼び出すコレクションとして書かれます。
システムプログラミングを念頭に開発されたのでアセンブリ言語と C を連携させることも簡単にできます。関数を呼び出すインターフェイスも非常に単純です。また、アセンブリ言語を C のコードに埋め込むことができるのでアセンブリのモジュールを分割してからリンクする必要もありません。
小さくて速いプログラムを書くのに最適です。アセンブリ言語のわかりやすいインターフェースでもあります。 歴史があり標準化が進んでいるのでプラットフォーム間のバージョンの差異も少ない。
オブジェクト指向技術のサポートが容易ではないためオブジェクト指向プログラミングのような大規模な C プログラムは簡単に混乱する可能性があります。
構文も難しいことがあり乱用できない - あっという間にコードが読みにくくなる。
Unix、Windows、Oracle といった非常に大規模なプロジェクトが C で記述されていますが、大規模な C ベースのプロジェクトを管理するには、モジュール性を重視して構築された言語よりも規律が必要になります。
ANSI 関数中心なら移植性は高いが機能が限定されます。
ANSI 以外の機能は開発プラットフォームに依存します。
例えば、Windows と Mac をサポートしようとするならユーザインターフェース部分はシステム特有の機能を呼び出さないといけないため、サードパーティの UI ツールキットで動作するようにコードを記述するか、ユーザーインターフェースをプラットフォームごとに記述することを計画する必要があります。
あまりよくありません。
C のコアはかなりコンパクトで理解しやすいですが、C のライブラリ呼び出しの多くは時代遅れであり、後継言語のいくつかでは簡単に処理できます。
C++ は、C の「子」として最も定着している言語です。
1980年代に「クラス」をサポートする C の拡張バージョンとして設計されました。 クラスはプリミティブデータ型とアルゴリズムを、実際の現実世界(ゲームの場合、シミュレートされた世界)をよりよくモデル化できるものに集約する抽象データ構造です。
C++ は C に取って代わるオブジェクト指向をサポートする言語です。
オブジェクト指向プログラミングは構造化プログラミングを超えるプログラミングで、 GUI やデータベースライブラリなどオブジェクトの集まりとして実装されたライブラリを使えば、理屈の上ではブロックを組み合わせるのと同じくらい簡単にプログラミングできるのがオブジェクト指向プログラミングのすばらしいところです。
書式は C++ と異なるものの C でもオブジェクト指向のプログラミングは可能なことから、ゲーム開発での C++ の利用はコミュニティーでも議論の的となります。 簡単に言うと C よりオーバーヘッドが大きいということでゲームには不向きなんじゃないかと。 C++ を気に入っている人達は C で仮想関数のようなことを実現するのなら C も同じようなオーバーヘッドがあるだろうと言います。
C++ のオーバーヘッドはより良い言語に対する対価だと思ってください。COBOL や FORTRAN のような高級言語がアセンブリ言語に取って代わろうとした時代に同じような議論が起こりました。議論の結果は現代の状況が物語っているでしょう。 プログラムのメンテナンスのコストを考えれば"高速でも複雑な言語"より"ちょっと遅い高級言語"に価値があるということです。
オブジェクト指向の枠組みを完全にサポートしますので、大規模プロジェクトをサポートするために C よりもはるかに優れています。 C とは異なり、一般的なデータ構造とアルゴリズムについて非常によく設計されたライブラリが含まれています。
大きくて複雑。C 同様に構文が乱れやすい。C より遅い時もある。
C++ の移植性は C よりも優れています。 最新の移植性のあるツールキットのほとんどが古いスタイルの C 関数ライブラリではなく C++ オブジェクト ライブラリとして実装されているためです。
さらに、C++ の標準ライブラリと非常に便利な Boost C++ ライブラリ は、標準化されクロス プラットフォームとなっています。
C++ のメモリ管理と I/O 操作は C よりもはるかに理解しやすいのですが、C++ の学習曲線はその大きさだけでかなり高くなっています。 しかしながら、言語についてすべてを学ぶ必要はなく生産性を上げるための要所を押さえれば十分です。
新しい標準である C++11 に対応した プログラミング言語C++ 第4版 が素晴らしい。
「DirectX なのか？ OpenGL なのか？」という質問を除いて、この問いは言語学習の初期段階で最もよく聞かれる質問の1つです。
この問いに対する明確な答えはありません。
C に精通したゲームプログラマーはオブジェクト指向プログラミングの技術を使っていると言います。
あなたが C から始めるとしても、早い段階でクラスとオブジェクト指向プログラミングを学ぶことをお勧めします。 オブジェクト指向はシミュレーションのためのパーフェクトな方法論です。 オブジェクト指向を学ばなければ困難な道に出会う ことは明らかです。
Objective-C は、動的ランタイムを備え厳密に型指定されたオブジェクト指向プログラミング言語です。 基本的な構文規則の大部分を C から継承し、メソッド呼び出し、全体的な定義ルールなどいくつかの大きな変更が含まれています。 その性質上 C 言語のスーパーセット(上位互換)とも言えます。
Objective-C は mac および iOS プログラミングの主要言語であり Apple 独自の言語です。
OpenGLベース の 2D および 3D グラフィックスを処理するための非常に広範な組み込みライブラリをサポートしており、 駆け出しのゲーム開発者は強力でネイティブなソリューションを使用して最初のゲームを構築できるはずです。 グラフィックス以外のライブラリでは、特にモバイル向けのゲーム開発に役立つものがあります。
もう1つの優れた機能は、参照カウント方式のガベージコレクターです。非常に高度なメモリ管理システムと密接に連携して動作します。
Objective-C は C の強力なスーパーセットであり、非常に柔軟なアプリケーションを作成できます。
C や C++ コードを利用できるため、新しいプロジェクトを簡単に移植し既存のプロジェクトを強化できます。
非常に多種多様で有用なライブラリがあり多方面で使用できる強力なオブジェクト指向プログラミング言語です。
Objective-C は Apple 専用です。 したがって、アプリケーションを開発するには最新バージョンの macOS を実行する Apple コンピューターが必要です。
もう1つ注意すべき点は、言語の構文規則の一部が、初心者から中級のプログラマーにとって混乱を招く可能性があることです。 メソッド呼び出しは標準からかけ離れており、クラス定義は C / C++ の経験があっても初めは戸惑うでしょう。
他に注意すべきこととして、iOS 向けアプリの開発においては高いレベルでのメモリ管理の知識が絶対に必要です。
皆無。
Objective-C は最も初心者向けの言語ではありませんが、最も難しい言語でもありません。
Objective-C に習熟することは C++ よりも比較的簡単です。 初心者はメモリ管理などの概念に多くの知識を入れる必要があります。 学習を始めた頃は苦痛を伴うプロセスになる可能性がありますが長い目で見れば報われるでしょう。
Objective-C の基本:
Objective-C メモリ管理:
Java は、実用的な目的で使われた最初の「ポストWeb」言語です。 Perl のような一部の言語では、文字列処理機能によって値を取得して表示可能な HTML を ウェブブラウザに送信することが自然であることに突然気付きましたが、Java は自身の基盤をブラウザ自体に見つけました。 最初は非常に興味深いが途方もなく風変わりな HotJava ブラウザ(Java自体で書かれています)で、後に既存のブラウザの拡張機能となりました。
Java は、C や C++ と同様に構造化されていますが「バックエンド」では動作が大きく異なります。 Java コンパイラは、Java ソースコードをネイティブ マシン コードにコンパイルするのではなく、仮想マシン(Virtual Machine/VM) によって実行される「バイトコード」にコンパイルします。 Java バイトコードはある種のアセンブリ言語ですが特定のプロセッサと結ばれているアセンブリ言語ではありません。
Java VM (Java Virtual Machine) は、実際にはバイトコードのランタイム インタープリターであり、マシンのターゲット プロセッサのバイトコードを解釈します。 このアプローチの利点は、Java バイトコードをマシンからマシンに移動し、そしてターゲットマシンに互換性のある Java VM があれば、Java が約束したように「一度書けば、どこでも実行」できることです。
いっぽうでこのアプローチの欠点は、Java バイトコードがネイティブ マシン コードではないことです。 「ジャスト イン タイム」コンパイラーなどのテクノロジーが VM のパフォーマンスを改善できますが、実際には実行時にある程度の解釈を行っているため余分に負荷がかかります。
もうひとつの欠点は、Java が初期の約束を守っていないことです。 ウェブページ内でゲームを実行するというアイデアは人々の心を捉えましたが、現実には、Java VM が互いに本来の互換性を持っていません。 そのため特定のマシンを使用して作成されたJavaアプリケーションまたはアプレット VM は、別の VM バージョンの別のマシンで適切に実行される場合とされない場合があります。 「一度だけ書いて、どこでも実行」は「一度書いて、どこにでも移植」と改名されました。つまり、Java コードの記述が一旦終了してひとつのプラットフォームで問題なく実行されたら、アプリケーションは他のシステムでもうまく動作します。
Java の三つ目の欠点は GUI にありました。 Java GUI となる最初の通過点では、ネイティブ OS コントロール（ボタン、スクロールバーなど）を使用し、適度に小さく高速でしたが、それほど深くはありませんでした。 次の通過点である Swing は、見た目は良くなりましたがパフォーマンスは悪くオリジナルのコントロールとはまったく異なりました。 そして最悪なことに、Sun（Java の親）は、ClearType フォントレンダリングのサポートなど、基盤となる OS に長年存在していた機能の追加が遅かったことがあげられます。 そのため、Java アプリケーションは常に最先端のバージョンとは少し異なるバージョンのように見えました。
ただし、Java が十分に活用され、Java の利点が欠点を上回った場所が1つあります。それはサーバーサイドのプログラミングです。 VM の大きな利点の1つは、実際の物理的なプロセッサではなく単なる演算処理装置であるため、VM のクラッシュがそれほど問題にならないことです。 Java VM が狂ったとしてもオペレーティング システムに直接的には影響せず、マシン全体をリブートすることなくセッションを閉じて再起動できます。
それに、Java のメモリ管理スキームは C++ および C から進化した世代であり、メモリを解放せずに新たなメモリを割り当てるような突然の問題はそれほど問題になりませんでした。 このようなシステムはサーバー環境に最適です。 サーバーは、基盤となる OS に影響を与えることなく、必要に応じて VM を起動および強制終了できます。 また、サーバー管理者にとってはサーバーソフトウェアが見栄えのするものでなくても良いので GUI の問題は無視できるのです。 サーバー側で Java を使用する多くの商用の大規模マルチプレイヤーゲームがあります。
Java が非常に強く浸透している場所は携帯電話市場です。 J2ME（Java 2 Micro Edition）は、Java VM の「ミニチュア」バージョンであり、携帯電話やその他の小型デバイスで実行するように設計されたクラス ライブラリを備えています。 実際、携帯電話の人口統計を含めると Java は現存する最も人気のあるプラットフォームのひとつです。
Java の仮想マシンとそのメモリ管理および不要になったメモリの自動収集(ガベージ コレクション)を組み合わせることにより、非常に堅牢でクラッシュに強いソフトウェアを作成できます。
クラスライブラリも標準化が成されていてとても強力で、広範なドキュメントを持つ優れた伝統があります。
Java の「一度書くだけで、どこでも実行できる」という約束は実現していません。
Java クラスライブラリは古い呼び出しを削除せずに何度も書き直されているため、ライブラリは古いコードと下位互換性がありますが、非推奨となっている API も多くあります。反対に下位互換が問題になるなど新しい機能の追加に時間がかかることもあります。
バーチャルマシンが使用されるので低レベル(ハードウェアに近いところ)を操作するのは難しくなっています。
かなり良いが本来あるべきほど良くない。
移植性があり、基盤となる OS の最新機能を使用する Java アプリケーションを作成することは難しいです。
かなり良い。
言語自体の中核はうまく設計されており理解しやすいです。 また、Java は多くの大学コースの標準言語になっています。
.NET（読み方は「ドット ネット」）は、基本的にマイクロソフトの Java VM に対する打開案で、包括的なテクノロジーの名前です。
実際の VM の名前は CLR（Common Language Runtime の略で日本語の呼び名は「共通言語ランタイム」）であり、Java VM について前述したことはすべて CLR にも適用されます。 重要な例外としては、CLR は Java のように単一言語と結びつかないように設計されていることです。
COBOL や FORTRAN のような古代のレガシー言語から Python のような現代の言語まで、すべてが CLR をターゲットにできます。 ただし、CLR プロジェクトの中には単独で何でもこなすプロジェクトがほとんどありません。 コンパイラの一部は成熟していないこともあり CLR バージョンのお気に入りの言語を見つけたとしても飛びつかないでください。
C# と Visual Basic はどちらもマイクロソフトが開発した最も一般的な CLR を基盤にした言語です。
C# は C または C++ から派生したもののように聞こえますが、明らかに Java から派生した言語であり Java の構文の約90％を共有しています。 C# には Java では追加が遅かったいくつかの素晴らしい言語拡張機能と完全に書き直されたクラスライブラリがあります。
Visual Basic (VB.NET と略されて呼ばれる) は CLR の実装です。確立された人気のあるマイクロソフトの Visual Basic 環境の代替品となっています。 「Basic」と名付けられていますが、1980年代に販売されたほぼすべてのコンピューターの ROM に焼き付けられていた古い BASIC インタープリターとはほとんど似ていません。
構文は、本書で紹介している他の言語と同様に構成されていますがステートメントをグループ化するために中括弧を使用しません。 また、CLR より前の .NET に対応していない旧来のバージョンのように関数ライブラリではなく、オブジェクト指向の「ドット表記」を使用して関数を呼び出します。
Java には Java VM に言語をコンパイルするためのいくつかの小さな取り組みがありますが、CLR はこれをサポートするためにゼロから設計されています。 そのため、CLR ベースの言語がいくつかあり、それらを相互に通信させるのは比較的簡単です。
.NET テクノロジーは、非常に成熟した機能豊富な開発環境であるマイクロソフトの Visual Studio 環境によって非常によくサポートされています。
C# はマイクロソフトの XNA テクノロジ の主要なプログラミング言語です。 XNA は、Windows と XBox 360 ゲームコンソール間で移植可能なゲームを作成する方法です。
Java とは異なり、CLR アプリケーションはウェブページ内でアプレットとして実行できません。
「Silverlight」テクノロジーはこれを可能にしますが、ゲーム環境としてはかなり遅れており、Java や Flash のようにブラウザに定着していません。 また、Silverlight はリリース5以降廃止されました。
CLR ベースのアプリケーションの移植性は、本来あるべきものよりもはるかに低くなっています。
CLR を Windows 以外のオペレーティングシステムに移植するサードパーティの取り組みがありますが、その方向の努力は Windows で行われている作業よりも大幅に小さくなっています。 したがって、Windows 用の非常に安定した .NET アプリケーションを作成できる場合もありますが、 Mac と Linux の作業はそれほどスムーズではありません。
C#、Visual Basic ともに適しています。どちらの言語も簡単で理解しやすい言語です。 さらに、Visual Studio 環境との緊密な統合によりセットアップがかなり簡単になります。
Microsoft Docs の .NET ドキュメント から始めてみましょう。
Python は前述の言語とは異なり大企業や大学のプロジェクトとして開発された言語ではありません。 従来の言語の欠点について不満を持つ人々の間での民主主義的な努力の結果、人気を博すようになりました。
言語自体はかなりコンパクトで使いやすいです。 Python 言語インタープリターを既存のプロジェクトに簡単に組み込むこともできるので、多くのゲームで Python が組み込みスクリプト言語として使われています。
Python は、Java のサーバーフレンドリーな属性の多くを備えているためサーバー言語としても機能します。 実際、Python コードを Java VM とマイクロソフトの CLR の両方にコンパイルできる Python コンパイラが存在します。 ご存知の多くのサービス（YouTube、Google、Yahoo）は、バックエンド処理に Python を広範囲に使用しています。
Python は pygame ライブラリを使用して、ゲームコミュニティでも非常に人気が高まっています。 pygame は定評のある SDL(Simple DirectMedia Layer) ライブラリを、Python から使いやすいものに抽象化するオブジェクトライブラリです。
Python のメンテナンスは実質的にユーザーコミュニティによって処理されるため、Python ベースのプロジェクトに契約するよう企業に依頼するのは難しいかもしれません。 しかしながら、一部の組織は Python に多額の投資をしている事実もあり、以前ほど「趣味の言語」とは言えなくなっています。
かなり良い。
Python 用に作成されたサードパーティ ライブラリのほとんどは、SDL や OpenGL などのポータブルテクノロジーを中心に構築されているため、複数のプラットフォームに対応することはそれほど難しくありません。
Python 言語にはわかりやすい構文があり簡単に習得できます。 有志が作成した優れたチュートリアルがいくつもあります。
python.org はPython のすべてのことを整理したホームです。 また、多くの活発なコミュニティフォーラムのホームでもあり、そこで質問に答えることができます。
まず、アセンブリ言語について知っておく必要があることが2つあります。
1. 言語の名前は「アセンブリ」です。 アセンブリ言語を低レベルのマシンコードに変換するツールの名前が「アセンブラ」と呼ばれます。 言語を「アセンブラ」と呼ぶことは、経験豊富なプログラマーの間でもよくある間違いです。
2. この記事で紹介している言語のなかでアセンブリ言語は最小かつ最速の言語です。 アセンブリは CPU の命令セットのニーモニック表現であるため、アセンブリで高速に処理できないことが高級言語で実装されることはありません。
上記の2番目の事実を考えると検索は終わったと思うかもしれません。 最小で最速の言語であるなら、それを使用してみたいと思うのが当然でしょう。 しかし、なぜ人々が C や C++ など言語の選択に悩むのでしょうか？ これは「最良のコード」という言葉がプログラムの実際の速度とサイズを指すだけではないためです。
「最良のコード」には、主に4つの性質があります。
これらすべての性質においてアセンブリは最下位の言語です。 アセンブリ言語を読んで維持することは非常に困難です。 細心の注意を払ってコメントしない限り、コードを継承する人にとってはほとんど役に立ちません。 バグの修正と既存のコードの拡張も難しいです。
同じメーカーの異なるプロセッサモデルでも実行されないコードを作成しないように、移植性も常に注意する必要があります。
ゲーム開発でアセンブリ言語が単独で使用されることはありません。 数百万回と呼ばれる多くの計算を行うプログラムの一部でいくつかの機械命令を削る場面でメリットが得られることがあります。 しかし、こうした計画はプロジェクトの最初のプロセスにはありません。 プログラミングのボトルネックが実際にどこにあるかを判断した後、初期のテストで行われます。
言語の性質上、他の言語で出来ることは何でもできます。しかしそれは「車で行けるところに徒歩でも行ける」と言っているのと同じです。(遅いという意味ではなく道のりが長いという意味です。)
定義上は最速、最小の言語。
優れたアセンブリ プログラマは他の言語で実現されるいかなるプログラムよりも速いプログラムを書くことができる。 この言語はプロセッサに直接命令できるので、プロセッサの最新の機能をいちはやく利用することができる。
学ぶのが難しい。謎めいた構文なので効率的なコーディングは難しく、何かをさせるためには非常に多くのコードが必要。
皆無。
特定のプロセッサのために設計された言語なので普通は移植不可能です。
「互換性のある」プロセッサ上でも実行されない場合があります。 たとえば、AMD プロセッサに関する一部の特別な指示は、Intel では利用できません。
退散する。
アセンブリ言語の文書を探すということは通常チップの文書を探すことになります。
Intel ベースのコンピューターのアセンブリ言語は、Intel プロセッサー向けに作成する場合に推奨されます。
Intel® 64 and IA-32 Architectures Software Developer Manuals
Intel でない場合は、技術リソースについてターゲットCPUのメーカーを確認してください。
書籍は amazon.co.jp で「アセンブリ」「アセンブラ」といった語で探してみてください
JavaScript は当初にウェブページのスクリプティング用言語として人気を博しましたが、今日ではウェブコンテンツを希望どおりに表示するために使用する言語として広く普及しており、ゲーム開発にも十分堅牢なものとなっています。
ここではサーバーサイドの開発言語としてではなく、クライアントサイド(ブラウザ用)の言語として紹介します。
JavaScript を開発言語として採択を妨げる主な問題が2つあります。
ひとつは、JavaScript のインタープリターはブラウザのメーカーに依存していることです。 言語は ECMA-262 と規格化されているものの、ブラウザの JavaScript 実装によって言語機能とパフォーマンスの両方が異なることがあるのです。 したがって、すべてのブラウザで動作する真に大きく堅牢な JavaScript アプリケーションを作成することが難しくなっています。
ふたつ目の問題は知的財産を保護することです。 JavaScript はコンパイルされず、ソースコードとしてブラウザに配信されブラウザ自体によって解釈されます。 コードを難読化してユーザーから隠すツールもありますが、ゲームのソースコードはブラウザの「ソースの表示」コマンドで得られます。 ゲームの借用/改善/盗難を望まない場合は、利用可能なセキュリティソリューションを厳しく検討する必要があります。
無料で利用できクロスプラットフォームの開発が容易。
JavaScript のインタープリターがブラウザのメーカーに依存することと、知的財産の保護が難しいこと。
優れている。
学習しやすい。
手元のコンピューターでメモ帳とブラウザがあれば開発環境をすぐに準備でき、すぐに学習を始めることができる。 JavaScript 以外に HTML5, CSS の知識も学ぶ必要があるもののインターネット上に豊富な情報があり探しやすいです。
ゲームは今やオンラインによるインターネットを利用したゲームが主流とも言えます。 したがって開発者はサーバーサイドの言語も学ぶ必要があります。
これまで紹介した言語の多くはサーバー上でうまく機能しますが、それらを構築した技術の一部はかなり古く、よりスムーズで使いやすいソリューションが利用可能になっています。
ウェブページのカスタム バックエンドを記述するための標準は CGI (Common Gateway Interface) と呼ばれ、サーバー側で実行可能ファイルを呼び出して処理した結果をユーザーに返します。
CGI プログラムの実装は簡単でしたが、処理速度やセキュリティの観点から今日では httpd サーバーのモジュールであったり、アプリケーションサーバが使われます。
PHP はウェブ用の最初の真の「組み込み」スクリプト言語の1つであり、多くの点でウェブページのスクリプト方法に革命をもたらしました。
PHP は、ウェブフォームから入力を受け取り、処理し、出力を返すスクリプト言語として動作できますが、その本当の強みはハイパー テキスト プリプロセッサとしての使用です。
サーバーのプリプロセッサとして動作するように構成された PHP はページ自体に埋め込まれたコードを処理できます。 したがって、たとえばページ内の現在の日付を出力したいときは、日付を出力するウェブページに PHP コードを直接埋め込むだけでブラウザに送信される結果のテキストとしてコードが置き換えられます。
PHP は無料で強力な MySQL データベースと通信するためのネイティブ コマンドのライブラリも追加し、永続データの保存と取得を容易にしました。
PHP をすぐに人気にしたもう1つの要因は価格です。 無料であったため、LAMP（Linux、Apache、MySQL、PHP）として知られるサーバー構成が定着しました。 これら4つのテクノロジーを組み合わせることで、初心者または低予算のウェブデザイナーに、使いやすく、スケーラブルで、非常に強力なウェブサイト一式の環境を安価で提供することができます。
今日では、単純なユーザーデータベースから完全な「ウェブサイト一式」のセットアップまで、ほぼすべてのタスクを実行するための多数の無料または低価格の PHP スクリプトがあります。
マイクロソフトは LAMP に負けじとばかり、Windows、IIS(マイクロソフトのウェブサーバー)、CLR、および SQL サーバーを基礎にした独自の PHP 風の構成をすばやくまとめました。
PHP の仲間ではなく無料でありませんが、ASP.NET にはお金を出せば技術サポートを受けられる利点があります。 プログラミング言語は C# と VB.NET が規定の言語ですが .NET が基盤となっているので .NET に対応した言語を使うことができます。
Ruby on Rails (単に「Rails」と呼ばれることが多い) は、それ自体がプログラミング言語ではなく、 Ruby プログラミング言語 で構築されたクラスライブラリです。
Rails ライブラリは、MVC（Model View Controller）パラダイムを完全に統合し、可能な限り技術の繰り返しを防ぐように設計されています。 最小限のコードでかなりリッチなサーバーベースのシステムを構築できます。
PHP と同様、Ruby on Rails は無料です。
プログラミング言語を使う という視点からは、全てのアプリケーションに最適な言語は無いと言えます。
「どの言語から始めれば良いのか？」という疑問がわいてくるのは当然ですが、「どんなゲームを作りたいか？」という視点から選択するべきです。
できれば自分が作ってみたいゲームについて現役の開発者にどのプログラミング言語を使っているか聞いてみるのが手っ取り早いです。
個人的には 3D ゲームまで手掛けるのであれば C/C++、 そしてアセンブリが必須だと思います。
くれぐれもプログラミング言語はゲーム開発における手段のひとつであることを肝に銘じておきましょう。
最終更新日: 2019年12月08日(日) / カテゴリー: プログラミング・ソフトウェア開発