実際はもっと処理を抽象化して分散できる。Gameというシングルトンの枠に全て詰め込むのであれば、Cで書くのと何も変わらない。ついて、自分でも考えてみましたが、GameFlagの設定をセッターとして関数化するくらいしか思いつきませんでした。どのような個所が抽象化できるでしょうか。勉強熱心で素晴らしいですね。これはすいません、追加追加でそのままになっていて、分割するのを見過ごしていました。気持ちはわかりますが、このコードの再利用性は0です。メンテナンスも大変になります。この程度のプロジェクトでも、分ける癖をつけましょう。どちらもゲーム内で必ずただ一つ存在するものという意図でしましたが...ゲームはシングルトンでない方がいいでしょうか?確かに、シングルトンと言えなくもないように感じます。実際はシングルトンは基本使ってはいけない。いえば、再利用性も拡張性も無だから。シングルトンを適用すべきは、OSレベル等自分のプログラムの更に下の階層にあるシステムが「ひとつでなければならない」「いちどだけしかしてはならない」などとしている場合だけだと思うべきです。むずかしい話になりますが、キーボードそのものが本当にひとつだけである必要はありますか?例えばGameの中で1つ作成して使えばよいのではないですか?もし複数のキーボード入力を受け付けるゲームに変えたらどうなりますか?キーボードという概念自体は世界で唯一ではありません。あなたがキーボードを1つに固定するのなら、キーボードのインスタンスをゲームで1つ作り、それにアクセスすればいい話です。1つしか創れないという制約を設ける必要はないはずです。一度ゲームを終了して再起動する処理を実装しようとしたら、あなたはどうしますか?また、ゲームに少し機能を追加しただけのものを作る時、シングルトンでは継承もできません。シングルトンは設計として例外中の例外です。どちらもタイプの手間を減らし、インデントされることで定数である意図をはっきりさせたつもりですが、たしかに逆に意図が不明瞭になってしまったかもしれません。256;タイプの手間が減りますか?そうとは思えませんが。列挙子を使うのは、複数の定数に同じ型を与えるためです。KEYMAXなどの定数に使う必要はありません。いうか、enumは使うべきではありません。数値と比較するためと言いましたね。キャストが手間だとも。その考えは直ちに捨てて下さい。それでいいと想っているなら一生Cを使う事をおすすめします。何の為に型があり、何のために数値と比較できないようになっているのか。それはバグを生みそれを治す手間を省くためです。列挙子を使うなとは言いません。ボードの状態を列挙子で扱うのは自然な考えです。問題なのはそれと「数値を比較する状況が生まれること」なのです。列挙子は定数の列挙として使うのではありません。複数の定数に同じ型を与えるために使うのです。そもそも、同じ型同士でしか比較する状況が生まれないのが正しい使い方をした場合です。してもスコープは同じクラスなので。統一しようと思います)いいえ、スコープは同じではありません。無名の名前空間も列挙子も、内部では一意な名前を持っています。列挙子は型も違います。enumは、enum名を省略して書けてしまうため、まるで同じ空間に属しているかのように扱えます。汚染だと言っているのです。別のところにあるのに、同じ名前でアクセスできる識別子が存在する可能性が生まれます。それは深刻なバグになるでしょうね。class、定数を宣言するだけならconst、これがいずれ大きなバグを防ぐでしょう。this->は関数は使用して変数は使用しないことで統一しました。ブロック文は、基本的には1行の時のみ省略し、for文の中のif文は書くようにしていましたが...ルールが複雑ですね。書くようにしたいと思います。thisとメンバ変数の命名規則については、私は言及しません。それで良いと思います。ブロック文は一行の時に省略する慣習はあります。それは「一行の場合は大抵処理が短く、1つであるから」なのです。短く1つの処理ならば、スコープは関係ないからです。実際はブロックをつける場合はスコープが生成され、そうでなければ生成されません。これは意味が違うんです。生成されないことで生まれるメリットはたった二文字を省略できることだけです。私は必ず書くことを勧めます。私などは、switchですらブロックを必ず書きます。}}この2つのマクロは、ゲーム関連の大規模なプロジェクトで見かけて便利だと思ったので使ってみましたが...そうですね、少なくともundefはするようにしたいと思います。例外とassertの混在は、例外の方はデバッグ時もリリース時も原因を通知してプログラムを終了させ、assertはデバッグ中は終了させるがリリース時は無視するという風にしたかったからです。画像が見つからないときにabortの画面でfileやlineが表示されてもユーザーは困るだろうと思ったので...。そのゲームプロジェクトはよほど非効率に運用されたでしょうね。それはそれで良いと思います。私は実行時アサートは一切仕込まないのですが、それも1つの手段です。さんが書きました:ただし。実際はもっと処理を抽象化して分散できる。Gameというシングルトンの枠に全て詰め込むのであれば、Cで書くのと何も変わらない。ついて、自分でも考えてみましたが、GameFlagの設定をセッターとして関数化するくらいしか思いつきませんでした。どのような個所が抽象化できるでしょうか逆に、なぜどこも分散しなかったのか謎です。全てゲームに詰め込んでいますね。これでは1つ修正する度にゲーム全てを作り直すことになります。描画処理このクラスは何のためのクラスですか?「画像を読み込んで、キーボード確認して、ブロックを操作して、描画したりしてゲームを実行する」でしょうか。実に具体的すぎるとおもいませんか?このクラスだけで全てが完結しています。これならCで書いたコードと変わらないというものです。Cで書いたコードをクラスに全部ブチ込んだだけですね。描画処理をちゃんと関数にわけたのはいい考えではあります。それならCでもできますね?私はぷよぷよをプレイしたことがないのでその辺の関係性はなにかおかしいかもしれませんが、一例としてコードをあげます。PuyoPuyoを変更しなくても描画だけ変えることもできるようになる。ファイル分割していれば再コンパイルする量が減る。}};いちから作るのは面倒なので、とりあえず描画処理を別に切り分ける案です。コンパイル部分が長いゲーム本体を再コンパイルする必要もなく、描画ができます。情報からぷよを表示するクラスすら用意すべきです。複数タイプの描画スタイルを用意しても、ポリモーフィズムをすることで継承したクラスをそのまま扱えばいいのです。単純な例を上げましたが、例えばボードのサイズを変更できるようにしたりするときに、部品化を進めておけば拡張が用意になります。HighPuyo)を作ったとします。}にすればよいだけなのです。}とすれば実行時に切り替えることもできます。部品化すればこれを発展させたもっと面白いゲームが簡単に作れるかもしれませんよ。新ゝ月さんがコードの指摘を行ってますので私は実行してみた感想を。・キーの配置についてAとDが左右なのはいいが、なんでSが下?と思いました。個人的にはZかXかなーと。Kが左回転かと思ったら自由落下なのもちょっと驚きました。カスタマイズできるようにするとベストかもしれない。・起動していきなり始まるのはどうか。通常のゲームって、まず「トップ」画面があって、ユーザーが開始するものです。起動していきなり始まってるのはよくないと思います。・ESCキーを押すと、ゲームの途中でも抜けてしまう。終了するときは必ず、「終了しますか?」と必ずユーザーに確認するものです。あとは、スコアをつけることですかね。スコアを表示できるようになったら、今度は順位を表示するとか。以上がどんなゲームでも必ずあると思われる点です。私の述べる改善をしていってはどうでしょうか?がんばってください。5年前>新ゝ月さんありがとうございます。どの点も納得しました。最後のコード例のような書き方を実はほとんどしたことがなく、クラスの機能やSTLを勉強してC++を勉強した気になっていましたが、オブジェクト指向の考え方が身についていませんでした。Cの考え方が染みついていたようです。消化不良気味なのでもう少し概念を調べてコードを書き直したいと思います。>へにっくすさんご意見ありがとうございます。キーの配置は、一般的な、WSADが上下左右に対応する形にしました。Xが下というのは慣れない人が多いのでは...。逆回転、タイトル画面と終了確認については、入れてみたいと思います。一通り疑問が解けたので解決としますが、後にコードをアップデートすると思うので、その時はよろしくお願いします。ミクプラは自由にリンクできます。