↓ メインコンテンツへスキップ
プログラミング演習B
  1. 第14講 最終課題、期末試験、まとめ/

最終課題

講義資料 課題 最終課題
目次

概要
#

PyGame を用いてゲームを作成してください。

提出方法
#

  • 提出先　Moodle
  • 〆切　　2026-02-02 (Mon) 09:00

作成したプログラムのソースコードを提出してください． また、どのようなゲームであるのか、どのように操作するのかのマニュアルや 工夫した点、苦労した点などを README.md に記載して提出してください。 必要なファイル（画像ファイルなど）も全て含めて提出してください。

エントリポイントとなるファイルは main.py としてください。 つまり、python3 main.py でゲームが起動するようにしてください。 コマンドライン引数は特に指定せず、実行するだけでゲームが起動するようにしてください。

発展課題
#

GitHubやGitLabなどのGitリポジトリにソースコードを公開し、そのURLを提出する形でも構いません。 利用するGitリポジトリサービスはGitHub、GitLab、Bitbucket、Giteaなど、一般に公開されているものであればどれでも構いません。 その場合、リポジトリのURLが書かれたテキストファイル（例えば repository_url.txt という名前のファイル）を提出してください。 README.md や Python のファイル、画像などはリポジトリに含めておき、提出するファイルには含めないでください。 クローンしたものが実行できるようにしておいてください。 なお、private リポジトリの場合は、他の人が閲覧できませんので、public リポジトリにしてください。

評価のポイント
#

  • python3 main.py で起動し、ゲームとして遊べるか。
    • 必要なファイルが揃っているか。
  • コードが適切に構成されているか。
    • クラス、関数に分割されているか。
  • README.md に必要な項目が記載されているか。
    • ゲームの概要（どんなゲーム）
    • 操作方法を始めとしたマニュアル。
    • 工夫した点
    • 苦労した点

コードが適切に構成されているか
#

コードが適切に構成されているかは、以下の点を参考にしてください。

  • 関数やクラスに分割されているか。
  • 変数名、関数名、クラス名が適切に命名
    • 例えば、a、b、c といった名前は避ける。
  • 関数やクラスが適切に設計されているか。
    • 例えば、1つの関数が長すぎないか。
    • 1つの関数が1つの役割を持っているか。

この項目については、コードの品質測定を行うツールを利用します。

コード品質測定ツール
#

  • pylint
    • Pythonコードの品質を測定するツールの一つです。
  • lizard
    • コードメトリクス（コードの評価尺度）を測定するツールの一つです。

両ツールともにインストールするには、pip3 コマンドを用います。

pip3 install pylint
pip3 install lizard

インストール後、測定したいファイルを含むディレクトリをコマンドの引数に指定して実行すると結果が出力されます。 command not found というエラーが出る場合は、hash -r コマンドを実行して、シェルのコマンドキャッシュをクリアしてから再度実行してください。

pylint の実行結果の読み方
#

pylint の実行結果は、以下のようなものが大量に出力されると思います。

maze4/stages.py:32:0: C0301: Line too long (108/100) (line-too-long)

表示されている内容は、ファイル名、行番号、メッセージID、メッセージ内容です。 この中で、メッセージID（以下のC0301）に注目してください。 このメッセージIDの先頭の文字は、メッセージの種類を表しています。

  • F: 致命的なエラー（Fatal）
  • W: 警告（Warning）
  • E: エラー（Error）
  • C: コーディング規約違反（Convention）
  • R: リファクタリング推奨（Refactor）
  • I: 情報（Information）

上記のうち、C、R、I はコードの品質に関する情報であり、コードの動作には影響しません。 F、W、E はコードの動作に影響する可能性があるため、注意が必要です。 具体的なメッセージ内容については、こちらのドキュメントを参照してください。 pylint の実行結果を全て修正する必要はありませんが、F、W、E のメッセージが出力されないようにすることを目指してください。 どうしても修正できない場合は、その理由を README.md に記載してください。

lizard の出力結果の読み方
#

lizard の出力結果には、以下の2つのソフトウェアメトリクス（コードの評価尺度）が含まれています。 この値を用いて、コードの良し悪しを判定します。

  • LOC (Lines Of Code, SLOCなどとも呼ばれる)
    • コード行数のことです。
  • 循環的複雑度（Cyclomatic Complexity、サイクロマチック数）
    • コードの複雑さを表す指標の一つです。

コード行数の目安について、具体的な値が一般的に存在するわけではありません。 ただ、1つの関数が\(n\)行を超えないようにすることが望ましいとされています。 \(n\)の値は様々ですが、pylint ではデフォルトで、関数の長さが50行を超えると警告が出るようになっています。

循環的複雑度は、基本的にループや条件分岐が増えると増加します。 循環的複雑度は、理想的には10以下であることが望ましく、20以上で、複雑であるため、設計見直しが推奨されます。 50を超えると、非常に複雑であり、リファクタリングが強く推奨されます（参考）。 この値を減らすためには、ループの中身を別の関数に移したり、 StageやWalkerで用いたような手法 で条件分岐を減らすなどの工夫が必要です。

README.md
#

README.md とは、マークダウン形式で書かれたテキストファイルです。 マークダウンは、GitHub、Qiita、Zenn などで広く使われている軽量マークアップ言語です。 ターミナル上で表示した場合でも、それなりに見やすく表示されてるように設計されており、テキストエディタで簡単に閲覧、編集できます。 ソフトウェア技術者であれば、マークダウン形式でドキュメントを書けるようになっておきましょう。

マークダウンの書き方
#

マークダウンの書き方は以下のページなどを参考にしてください。

マークダウンは実は様々なバリエーション（方言）が存在しますが、基本的な書き方は共通しています。

マークダウンエディタ
#

マークダウンは、どのようなエディタを使っても編集できますが、専用エディタを使うと便利です。 いくつか紹介します。 もちろん、VSCode にもマークダウン編集機能が備わっており、 プレビュー機能もありますので、VSCode を使うのも良いでしょう。