当サイトでは、四聖龍神録2をベースに、部分的にソースコードをオープンにしながら四聖龍神録2のようなゲームを作ることを目的とします。
また、以下のような方を対象としています。
・Ｃ++の基本は理解したが、それを本格的な設計に活かす方法がまだ良く分からない。
・ＤＸライブラリの基本は理解した。
ＤＸライブラリについて特に難しい手法は利用しませんが、基本は理解している必要があるため、
ＤＸライブラリについて良く知らない人はまずこちらをご覧ください。
ゲームとオープンソースとはかなり相性の悪い物です。自分がせっかく作ったゲームがオープンソースだとチートされ放題で、不正し放題になってしまいます。
また、海賊版が配布されるリスクもあるため、皆したがらず、なかなか中規模以上のゲームプログラムのオープンソースはありません。
私はそこにある需要に応えたくこのホームページを作りました。
ただし、龍神録プログラミングの館公開時には
「企業の採用試験の提出物としてそのまま提出されている」
「専門学校の卒業制作としてそのまま提出されている」という報告を多数受けました。
このようなことの無いよう利用規約を守った利用をお願いいたします。
Ｃ++を学ぶ者にとって、Ｃ++の入門書を読破しても、そこからなかなか「良い設計」にたどり着くには時間がかかります。
そもそもオブジェクト指向というものをぼんやりしたイメージから完全に理解するレベルまで到達するにはかなり時間のかかることでしょう。
私はそこから一歩ステップアップするためのお手伝いをさせてもらえたらなと思っています。
Ｃ++中級者が読む読み物としてお勧めしたいのが以下の本です。
よければこのような本も読んでみて下さい。
「Effective C++」「Effective Modern C++」「オブジェクト指向でなぜつくるのか」「現場で役立つシステム設計の原則」「デザインパターン」
本館はゲーム制作に特別特化するつもりはありません。
それよりもC++等のオブジェクト指向言語でオブジェクト指向による適切な設計・コーディングをするための一つの教材として位置づけるつもりです。
ここでは初めに、この館でのコーディングポリシーを紹介します。
この書き方はどうしてこうなっているのだろう？という疑問を解消します。
(この節は本館が完成するまで思いつきで増やしていきます)
・constを使う
とにかくしつこいほどconstを付けて下さい。
int a;
はaが可変なのに対し、
const int a;
にすると不可変になるのはご存知の通りです。さて
const int* const p;
の場合は最初のconstはポインタの参照先を不可変にすることを意味しており、
後ろのconstはポインタそのものの書き換えを不可変にしています。
更に
const int A::function() const;
の場合、最初のconstは返り値を不可変にしており、
後ろのconstはそのメンバ関数内でメンバ変数の書き換えが起こらないことを保証しています。
このようにconstは書く位置によって意味が異なるのでconstの仕様をしっかり理解して読んでください。
constは書き換えできないことを保証するもので、コーディング時にそのコードの安全性を高める上で非常に重要なものです。
・const *とconst &
関数の引数に実体のコピーを受けるようにしてしまうと、クラスの中身が大きい時に処理が非効率になるのでやらないというのは極基本的なことですが、
それであればconst *で受け取ってもいいし、const &で受け取ってもいいような気がします。
この場合なるべくconst &で受け取るようにしてください。何故かは上の書籍に書いてあります。(C++のSTLの中身などはconst
*ではなく積極的にconst &が使われています)
それにもかかわらずポインタで受け取っている部分が出てきます。
それは主にインターフェイスポインタの受け取りです。親クラスのインターフェイスをコールバックしたいような場合はimplementsしたポインタを受け取ってコールバックする設計になっています。
・実体ではなくshared_ptrを使う個所
本館では基本的にnewは使いません。JavaやSwiftやC#等の言語はガベージコレクションと言ってメモリをnewしてもdeleteしなくて良い言語仕様になっていますが、
C++は自分でdeleteしなければメモリリークが起きてしまいます。
それをモダンな言語のようにdeleteしないで良くしてくれるのがshared_ptrであり、本館では積極的にこれを利用します。
また、個所によってはポインタ使わなくても実体をそのまま定義すればよいように思う個所があるかもしれませんが、
インスタンスの生成タイミングを変更したり、コンストラクタの引数に持たせたい情報が決定するタイミングを見計らいたい場合もあるため、
メンバ変数に実体を用意するのではなくshared_ptrにしている箇所があります。
・関数ヘッダやコメントはDoxygen形式
本館でのコメントは以下のように記載します。
/*!
@brief 座標を引数の回転角度分回転して返す
*/
この書き方は「Doxygen」というツールを使えるようにする書き方です。
Doxygenとはコードの設計書を自動生成してくれるツールのことで、このツールの記載規則に従って書くと自動で綺麗な設計書が出来上がるのです。
・音楽系の実装は最後
これは経験上こうした方がいいという考えの元ですが、音楽・サウンド系、特にバックミュージックの実装は最後にした方が良いです。
それは聞き飽きるから。
ゲームを作っていく時、何百回、何千回とコンパイルすることになると思いますが、そのたびに同じ音楽が流れるのは正直飽きます。
これを避けるために音楽関連の設計は最後にします。
音楽関連のモジュールは楽に後付け出来るように設計するのが望ましいでしょう。
・後日追記
基本的には前の章からの変更点を説明しながら章が進みますが、一字一句変更点を列挙していない場合があります。
そんな時にはどこに変更点があるのか確認するにはWinMergeを使うと便利です。
まずWinMergeをインストールしてください。
その上で、比較したい章のフォルダを２つ選択します。
右クリックします。
「WinMerge」を選択します。
色の付いているファイルが前の章から変更されたものです。
Looper.cppをダブルクリックしてみましょう。
色の付いている部分が変更のあった行です。
コンストラクタやloop()メソッドに変更はありませんが、onSceneChanged()メソッド内に変更が、
及びinclude文が一行追加になっていることが分かります。
このようにすることで前後の章での差分が全て確認可能です。
万が一言語仕様的に間違った解説をしている箇所や、不適切な記述がもしあれば御報告頂けると幸いです。
また誤記や誤字脱字等の御報告も見つけた方は御報告頂ければ幸いに存じます。
連絡先：dixqhp@gmail.com (または掲示板) まで