プロジェクト演習 III,V＜インタラクティブ・ゲーム制作＞

プログラミングコース

第 1回ガイダンス

みなさんに、聞いておきたいことがあります。

どんなプログラムを書きたいですか？

そもそもプログラム、書きたいですか？

どういう風に、書きたいですか？

この授業の方針として…

• ゲームエンジンを作れる人を育てたい。• 何でも出来る最強エンジンではなくても、今作ろうとしているものに対して「一番いいプログラム」を書ける人になってほしい。

• そのために、アクセル全開で行くことにしました。

具体的には

• 基礎的なところは自学自習してくるものと信じて、丁寧に解説しません。

• 高度な理論や概念を惜しみなく使います。–今までは「理解しやすさ」を考慮してセーブしていましたが、それはもうやめます。

• 表面的なところだけマネしようとすると痛い目を見るかもしれません。–本質に降りようとする姿勢がないときつい。–でもその手助けやサポートはします。

今日のお話

• 2年生向けガイダンス• 3年生向けガイダンス• 今後のスケジュール• コードレビューの進め方

2年生が今期やるべきこと

• 前年度後期で作品を作ったり、作りかけたり、挫折したりした

• 今期はより効率的に、大規模なプログラムを構築する手法を学ぶ

昨年度の授業は「出来ること重視」

• こう書けばこんなことが起きるよ～というエサで釣った授業でした。

• しかし、それだけでは苦しくなってきたのを皆さん感じたことと思います。

• 今期からは「先を見越して地力を付ける」ことを重視します。– OOPと数学の話をみっちりやります。

簡易コードレビュー

• すごい書き方しているコードを紹介• 「もっと効率いい書き方あるなら先に教えろよ！」と思ったかもしれません–敢えて教えませんでした–初めて学ぶことに対して最初から効率を追求するのはナンセンスです

–教えたところで身につきません• まずは非効率的でも動くものを作り、その上で効率化の手法を学ぶ

覚えて欲しい内容

• C++の基礎– 配列

• teki1, teki2, teki3…とかやめましょう– 関数

• main()が 7600行とか拷問です– クラス化

• 使い回し、開発の分担、あらゆる面で大活躍– ファイル分割

• クラス化とあわせて覚えたい– 動的メモリ管理

• その場でデータを読み込んで動作させるための方法

覚えたいであろう内容

• 位置関係や向きに関する判定–ベクトルと行列の基礎

• より高度な当たり判定–提供ライブラリも拡張していきたいですね

• FKUTの解説と基本設計– C++の基礎を固めた上で触れます

• エフェクト–最後の方で扱います

前期の進め方

• 配付資料による講義と課題による学習• 学期末時点での制作物および仕様書による評価– 前年度の作品を改良するもよし– 自分で小規模の実験作品を作るもよし

• オブジェクト指向プログラミングの内容と重なる部分が多々あります– 履修者はしっかりと、それ以外の人でもできるだけ選択科目としての履修を推奨

開発環境について

• 言語： C++• ライブラリ： FK ToolKit System• 基盤 API ： OpenGL, OpenAL• IDE(開発環境 ) ： Visual Studio 2010

その他の選択肢

• 実績あり＆ノートで動かなくもない– DXライブラリ– XNA– Unity

• 実績なし＆ノートじゃ無理(でもどうやらチャレンジャーなチームが？ )– Unreal Engine(UDK)

• チームを組んだら、まずターゲットを明確に絞ろう

3年生が今期やるべきこと

• 作ること

• 他になんかある？

そのためには

• 仕様の確定– GW 明けに確定してないと死亡フラグ

• 技術的課題の列挙、整理、クリア• 開発スケジュールの管理–無理はともかく、無茶はするな

外部仕様 ( 機能仕様書 etc)

• いわゆるマニュアルに相当するもの–プログラムの知識が無い人にもわかる内容

• UI( ユーザーインターフェース ) 主体–どのような画面モードがあるのか–画面上の項目の説明、操作方法–画像とか載せておくと良いかも

• プロデューシングの発表がベースになる–…はずだよな？

内部仕様 ( 詳細仕様書、設計書 etc)

• プログラムの詳細設計書–開発者向けの内容–開発環境 ( 条件 )、クラス仕様、構成、アルゴリズム等の説明

• プログラムの内部動作についてまとめる–これとソースコードがあればプログラムの

中身が全部わかる、というくらいに–必要に応じてコンポーネント図やフローチャート等も書く

敵はどこだ！？

• 内部仕様をまとめたら、解決するべき問題点を列挙する– やればすぐ解決する問題

• すぐやっちゃいましょう– 時間をかければ解決する問題

• 早めに手を付けましょう– 時間をかけても解決しない

(でも判明すれば瞬殺できる )問題• 早めに相談しましょう

– 本気でどうしようもない問題• どうしましょう

スケジューリング

• 使える作業時間と、解決するべき課題の所要時間を算出–くれぐれも学業に支障の無いように！–解決所要時間も甘く見積もりすぎないこと

• 半月単位でやるべきことをリストアップ–遅れが生じたり、問題が起きたら即相談–前倒しで予定を立てて、トラブルが起きたらリスケできる余裕を作る

前期の進め方

• 毎週の講座と設定した課題による評価• 学期末時点での制作物および仕様書による評価

• 3年生チームは 1回コードレビューを受けることを強く推奨します– XNAや DXライブラリでもいいですよ

コードレビューの進め方

• 事前に現時点でのプロジェクトと内部仕様書を提出

• 3 週に 1回程度コードレビューの週を作り、そこで私がずんばらりと斬ります

• なるべく早い方が幸せだと思います

次回までの課題

• 2年生– プログラミング演習の内容を総復習• 配列• メソッド

– 先日発表した作品のコードを読み返す• 問題点や納得いかない

点を洗い出す• リストアップしたものを提出

• 3年生– タスクリストの整理

• 内部仕様が綺麗にまとまってなくてもいい

– 次回の授業時に提出• 書式はテキストでも

Wordでも Excelでも可