ゲームプログラマーのポートフォリオには、自分が何を作り、どの部分を担当し、どんな技術で実現したのかが分かる作品を載せます。ゲーム画面の動画だけでなく、担当範囲や工夫した点、使用言語・ゲームエンジンまで示すことが重要です。
ゲームプログラマーのポートフォリオに載せる基本内容
まずは、次の情報を作品ごとに整理しましょう。作品数を増やすよりも、技術力や考え方が伝わる作品を選ぶことが大切です。
- 作品名と作品の概要
- 制作期間と制作人数
- 自分の担当箇所
- 使用したプログラミング言語やゲームエンジン
- 実際に動いているゲーム画面
- 実装した機能と工夫した点
- 苦労した点と、その解決方法
- プレイ動画や実行ファイルへのリンク
- ソースコードや技術資料へのリンク
作品の概要
作品を見ていない人にも内容が伝わるように、ジャンル、対応機種、プレイ人数、ゲームの目的などを短く説明します。
たとえば「Unityで制作した2Dアクションゲーム。プレイヤーが敵を避けながらゴールを目指す作品」のように、最初の数行で概要が分かるようにします。
自分の担当箇所
チーム制作では、作品全体を自分一人で作ったように見せないことが重要です。プログラム、ゲームシステム、UI、敵の行動、セーブ機能など、担当した範囲を具体的に書きます。
「プログラムを担当」とだけ書くよりも、「プレイヤーの移動、敵の追跡AI、ステージクリア判定、画面遷移を担当」のように機能単位で示すと、担当範囲が伝わりやすくなります。
使用した技術
使用したゲームエンジン、プログラミング言語、開発環境、外部ツールなどを記載します。
- ゲームエンジン：Unity、Unreal Engineなど
- 言語：C#、C++、JavaScriptなど
- 使用した機能：物理演算、アニメーション、AI、通信、セーブ・ロードなど
- 開発ツール：バージョン管理ツール、3D制作ツール、画像編集ツールなど
ただし、触ったことがある技術をすべて並べる必要はありません。作品の中で実際に使った技術を中心に書き、説明できない技術名は載せないほうが安全です。
技術力が伝わるゲーム作品の見せ方
作品紹介では、完成したゲームの見た目だけでなく、どのような課題をどのように解決したかを説明します。ゲームプログラマーの場合、実装の考え方が分かる情報が評価材料になります。
実装した機能
作品の中で自分が実装した機能を、具体的に列挙します。単に「いろいろな機能を実装」と書くのではなく、プレイヤーやゲームの動きに結び付けて説明します。
- プレイヤーの移動とジャンプ
- 敵キャラクターの追跡や攻撃
- アイテム取得とインベントリ管理
- ステージクリアやゲームオーバーの判定
- セーブ・ロード機能
- メニュー画面や設定画面
- オンライン対戦や通信処理
- 大量のオブジェクトを扱うための処理改善
すべての機能を詳しく説明する必要はありません。自分が特に工夫した機能や、応募先で生かせる機能を優先します。
工夫した点と解決した課題
ポートフォリオでは、結果だけでなく制作中の課題と対応方法を示すと、問題解決の進め方が伝わります。
たとえば、敵キャラクターが多い場面で処理が重くなった場合は、原因を調査し、更新頻度の調整や不要な処理の削減など、どのような対策を行ったかを書きます。改善前後のフレームレートなど、実際に測定した数値がある場合は、測定条件と一緒に掲載します。
数値を載せる場合は、実機やパソコンの環境、比較方法を明記してください。条件が分からない数値だけでは、性能の比較ができません。
設計やコードの説明
コードをすべて掲載する必要はありません。重要な部分を抜粋し、クラスの役割、処理の流れ、設計上の判断を説明します。
たとえば、ゲーム状態の管理、敵の行動切り替え、入力処理とキャラクター処理の分離などについて、なぜその構成にしたのかを書きます。コードを載せる場合は、読み手が動作を確認できるよう、前提条件や関連する処理も補足します。
動画・実行ファイル・ソースコードは何を載せるか
作品を確認できる手段は、できるだけ複数用意します。ただし、リンク先が開けない、実行方法が分からないといった状態では作品を確認してもらえないため、各リンクの説明も必要です。
| 掲載物 | 伝わる内容 | 掲載時の注意 |
|---|---|---|
| プレイ動画 | ゲームの動き、操作感、機能の流れ | 担当した機能が映る場面を含める |
| 実行ファイルや公開ページ | 実際にプレイできるか | 対応OS、操作方法、必要な手順を記載する |
| ソースコード | コードの書き方や設計 | 公開できる範囲だけを載せ、READMEで概要を説明する |
| 画面写真 | 作品の見た目やUI | 画像だけで分からない機能は文章や動画で補う |
| 技術資料 | 課題、設計、改善の考え方 | 専門用語を使いすぎず、結論から説明する |
プレイ動画
動画の冒頭で作品名と概要を示し、その後に自分が担当した機能を見せます。長いオープニングやプレイ場面を続けるより、移動、戦闘、AI、UIなどの要点が短時間で分かる構成にします。
動画だけでは担当範囲が分からないため、動画の下に「何分何秒にどの機能が映っているか」を書くと確認しやすくなります。
実行ファイルやプレイ可能な作品
実際に遊べる作品を公開する場合は、ダウンロード方法、対応するOS、操作方法、既知の不具合を記載します。起動に特別な設定が必要なら、その手順も書きます。
応募先へ提出する場合は、企業が指定するファイル形式や容量、公開範囲を優先してください。公開できない作品や、他人の素材・業務上の機密情報を含む作品は、そのまま掲載しないでください。
ソースコード
ソースコードを公開できる作品では、リポジトリへのリンクを載せると、実装を確認してもらえます。READMEには、作品概要、起動方法、使用技術、担当範囲、操作方法をまとめます。
コードを公開できない場合でも、画面や処理の流れを説明する技術資料を掲載できます。公開できない理由を簡潔に書き、未公開のコードを無理に掲載しないようにします。
学生・未経験者が載せるとよい内容
実務経験がない場合は、学校や個人で制作した作品を載せて問題ありません。重要なのは、作品の規模よりも、完成まで取り組んだことと、自分の実装内容を説明できることです。
小規模な作品でも、次のような情報を加えると内容が具体的になります。
- 制作を始めた理由
- 最初に立てた目標
- 自分で実装した機能
- 途中で発生した問題
- 問題を解決するために調べたこと
- 完成後に分かった改善点
- 次に追加したい機能
未完成の作品を載せる場合は、完成品のように見せず、開発中であること、現在できること、残っている課題を明記します。完成した作品があるなら、未完成作品だけでなく、動作を確認できる完成作品も優先して載せます。
応募先に合わせてポートフォリオの内容を変える
ポートフォリオは、応募する職種や担当分野に合わせて見せる内容を変えます。ゲームプレイに関わる職種なら操作やゲームシステム、技術寄りの職種なら設計、最適化、ツール制作などを詳しく示します。
| 応募先・関心分野 | 強調しやすい内容 |
|---|---|
| ゲームプレイプログラマー | 操作、戦闘、ゲームルール、カメラ、ゲームの手触り |
| グラフィックス系プログラマー | 描画、シェーダー、エフェクト、ライティング、最適化 |
| AI系プログラマー | 敵の行動、経路探索、状態遷移、群れの制御 |
| ネットワーク系プログラマー | 通信、同期、ルーム管理、切断時の処理 |
| ツール・エンジン系プログラマー | エディター拡張、制作支援ツール、データ管理、処理速度 |
一つの作品で複数の分野を扱っている場合は、応募先に関係する機能を先に説明します。すべてを同じ分量で紹介する必要はありません。
載せないほうがよい情報と注意点
ポートフォリオには、確認してもらいたい情報だけを載せます。次のような内容は、作品の評価を分かりにくくしたり、公開上の問題につながったりすることがあります。
- 担当していない機能を自分の実績として書く
- 使用していない技術名を一覧に加える
- 動作しないリンクや説明のないファイルを掲載する
- 他人のコードや素材を自作として掲載する
- 学校や会社で公開が禁止されている情報を載せる
- 長い文章だけで、作品を確認できる画面や動画がない
- 作品数を増やすために、未完成の小作品を大量に並べる
チーム制作や既存素材を使った作品では、制作メンバー、素材の出典、ライセンス、担当範囲を明記します。権利関係や公開条件が不明な素材は、利用規約を確認してから掲載してください。
作品紹介ページの書き方の例
作品ごとに、次の順番でまとめると、読み手が必要な情報を確認しやすくなります。
- 作品名とゲームの概要を書く
- プレイ動画または画面を最初に見せる
- 制作期間、人数、自分の担当範囲を示す
- 使用した言語、ゲームエンジン、主な機能を書く
- 工夫した点や解決した課題を説明する
- 実行ファイル、公開ページ、ソースコードを案内する
- 制作後の改善点や今後の課題を短く書く
説明文は、技術名の羅列ではなく、「何を実現するために、どの技術を使い、どのような結果になったか」という順番にすると伝わりやすくなります。
ゲームプログラマーのポートフォリオに必要なのは、作品数の多さだけではありません。作品が動くこと、自分の担当範囲が分かること、実装の工夫を説明できることを優先して、応募先に関係する作品から整理しましょう。
