/**
 * ジョイスティックの入力状態
 */
struct ST_JOY_STATE
{
    unsigned char    ucJoyUp;            ///< 上キー
    unsigned char    ucJoyDown;          ///< 下キー
    unsigned char    ucJoyLeft;          ///< 左キー
    unsigned char    ucJoyRight;         ///< 右キー
    unsigned char    aryucJoyBtn[6];     ///< 数字キー
};
ST_JOY_STATE _stJoyState;    ///< ジョイスティックの入力状態

こんな列挙型と配列使ったほうが、

/**
 * ジョイスティック用キーコード
 */
enum E_JOY_CODE
{
    JOY_UP,        ///< ボタン上
    JOY_DOWN,      ///< ボタン下
    JOY_LEFT,      ///< ボタン左
    JOY_RIGHT,     ///< ボタン右
    JOY_BTN1,      ///< ボタン1
    JOY_BTN2,      ///< ボタン2
    JOY_BTN3,      ///< ボタン3
    JOY_BTN4,      ///< ボタン4
    JOY_BTN5,      ///< ボタン5
    JOY_BTN6,      ///< ボタン6
    JOY_CODE_END,  ///< 最終メンバ（メンバ数取得用）
};

unsigned char _aryucJoyState[JOY_CODE_END];    ///< ジョイスティックの入力状態

管理しやすいような気がした。

上のE_JOY_CODE列挙型があれば、ボタンの情報を関連付けやすいし、そんで構造体より配列の方がコードがシンプルになる。

※「///<」はDoxygen用のコメント

ゲーム処理クラスはDirectXなんて知らない。だから、描画クラスだけいじれば、ゲームプログラムを一切変更せずに描画エンジンが切り替えられる。

というのも、DirectX処理クラスは、完全にゲームとは別に独立したものっていう考えで、本来はDLLとして存在するべきものにしてある（DLLにすると逆にめんどいことがあるんで、今は敢えてDLLにしてない）。だから、今作ってるゲームに限らず、このDirectX処理クラスは汎用的に使えるようにしてある。

本来独立して存在するものが、ゲーム処理クラスと同じ共通処理クラスを使用してるのは変。だから、DirectX処理クラスは、共通処理クラスを使わない方がいいな。

そもそも共通処理クラスっていうのが抽象的すぎた。ゲーム処理用の共通クラスとでもしておくか。

[デバッグトレース]

• ファイル読み込みや、シーンの切り替えなど、重要処理や全体の処理フローがわかるようにトレースする
• エラー発生時に、そのときの関数の名前や行数などをトレースする

[ログ出力]

• エラー発生時に、そのときの関数の名前や行数などを、エラーログとして出力する

[エラーメッセージ表示]

• エラー発生時に、そのことがプレイヤーにわかるよう、メッセージダイアログにて、エラーメッセージを出力する
• 基本的には、ゲーム起動時に出力する
  例）「DirectXの初期化に失敗しました」
  　　「画像ファイルの読み込みに失敗しました」

重要度でいくと、

エラーメッセージ表示　＞　ログ出力　＞　デバッグトレース

っていう順番かな。

1バイトだけのデータとか文字列は別にエンディアンを考慮する必要なし。1バイトずつ見る分にはひっくりかえりようがないから。2バイト以上の整数値は変換しないといけない。

memcpy(&shNum, pFileData, sizeof(short));
memcpy(&lNum, pFileData, sizeof(long));

とかやったら、shNum、lNumは変換必要。そもそも、memcpy関数使わないで、エンディアン変換込みのメモリコピー関数を独自で作ればいいけど。

嫌だったのは、バイナリデータが構造体を表してて、それを取得するところ。構造体は、long型（4バイト）とかのメンバをめちゃくちゃ持ってた。

struct ST_TEST
{
    long    lDataA;
    long    lDataB;
    long    lDataC;
    …
    …果てなく続く（嘘）…
}

この構造体をそのまま

memcpy(&stTestData, pFileData, sizeof(ST_TEST));

ってしたら、↓こんなバイナリデータが、

00 00 00 01  00 00 00 0A  00 00 00 02 …

それぞれ4バイト区切りでひっくり返った値になって解釈されちゃう。↓こんな風に。

lDataA：0x01000000　※本当は0x00000001というデータで欲しい
lDataB：0x0A000000
lDataC：0x02000000
…

というわけで、せっかく構造体として存在してるのに、わざわざメンバ一個ずつ見てエンディアン変換かけることに。めんどい。

リトルエンディアンって、よくいう「バッドノウハウ」ってやつになるのかな。

メリットは、

• if文の多用や、それによるインデントの数を防げる
• 終了時の処理が分散しない（途中returnを無くせる）

ってとこだと思う。

実際↓こんな感じになる。

/**
 * なんかの初期化関数
 *
 * @param[in]    a_nIn    入力値
 *
 * @return    処理結果
 * @retval    true    成功
 * @retval    false   失敗
 */
bool Init(int a_nIn)
{
    bool    bRet = true;        // 戻り値
    char*   pszError = NULL;    // エラーメッセージ

    do
    {
        // パラメータチェック
        if (a_nIn < 0)
        {
            pszError = "パラメータエラー";
            bRet = false;
            break;
        }

        // オブジェクトの生成
        if (! CreateObject())
        {
            pszError = "オブジェクト生成エラー";
            bRet = false;
            break;
        }

        // オブジェクト2の生成
        if (! CreateObject2())
        {
            pszError = "オブジェクト2生成エラー";
            bRet = false;
            break;
        }
    }
    while (false);

    // エラーメッセージ表示
    if (! bRet)
    {
        OutputErrorMessage(pszError);
    }

    // ログ出力とか？必要なら
    OutputLog(__FUNCTION__);

    return bRet;
}

途中returnあると、終了時の処理が分散しちゃって見にくいし、管理しにくい。終了処理は一箇所にまとまってる方がいいかなと。

ちなみに、while文使って、

    while (true)
    {
        // パラメータチェック
        if (a_nIn < 0)
        {
            pszError = "パラメータエラー";
            bRet = false;
            break;
        }

        …（略）…

        break;
    }

でもいいかと思ったけど、会社の人と話したときに、

「breakは忘れるから怖い」

って言ってた。while(true)でbreak忘れて無限ループになるのが怖いと。
do～while文だったら、最後のwhile忘れたらコンパイルがそもそもできないし、その最後のwhileにfalseじゃなくて敢えてtrueを指定するって間違いは無いと思う。
でも、while文のときは、while(true)の中で最後にbreak忘れても、コンパイル通っちゃう。そのbreakだけ忘れるとかだったらやっちゃいそう。

あ、goto文は存在しないことにしときます。

/**
 * CSampleクラス
 * 
 * @date 2008/04/30
 */
class CSample
{
    int    _nTest;
    int*   _pnTest;
    …
} 

こんなメンバ変数持ったクラスだったら、初期化リスト使った初期化はこうなる。

/**
 * コンストラクタ
 */
CSample::CSample():
    _nTest(0),
    _pnTest(NULL)
{
}

で、メンバ変数が配列とか構造体のときは、どうすんのかと思って調べたけど、見つからなかった。試しに次のメンバ変数を初期化リストに入れてデバッグしてみた。

/**
 * CSampleクラス
 *
 * @date 2008/04/30
 */
class CSample
{
    int        _arynTest[100];    ←配列
    ST_TEST    _stTest;           ←構造体
    …
}

初期値を引数に入れようとするとエラーになったから、空にしてビルドした。

/**
 * コンストラクタ
 */
CSample::CSample():
    _arynTest(),
    _stTest()
{
}

で、このとき構造体"_stTest"は0埋めされてたから、とりあえず構造体は0で初期化されるっぽい。ただ配列"_arynTest"は0埋めとかされてなかった。この方法だと配列は初期化できないみたい。

配列のメンバ変数の初期化は、普通に{}内で、memsetとか使うしかないか。