プログラマ専用SNS ミクプラ

おはようございます。

プログラミングのリハビリを兼ねて、VC++, Dxlibでインベーダー（2D)を作ってみました。
どなたでも構いません。こちらプログラムの評価お願いできますでしょうか？

よろしくお願いします。

＜フォルダ内容＞
１．Applicationフォルダ：　アプリケーションが入っています。
２．SpaceInvadersフォルダ：　コードと画像類
３．クラスダイアグラム：　クラス図の画像(png)
４．ソリューションファイル：　vs2008のソリューションファイル

インベーダーとしては完成度は高いと思います。
ただ、本家より弾や砲台の移動速度が低めなのはわざとでしょうか？
なんかBASICで作られた移植版を見ているかのような感じです。

ざっと見ただけですが、
1)SequenceManagerはシングルトンにしたほうが素直では？と思いました。

2)メンバ名の分担がよく分からないです。
Update();
Shot();
Action();
Move();
と別れてますが基準が良く分かりません。

3)クラスの説明がないので、何を担当しているクラスかわからないものが有る。
解析するまでHeroが砲台だとは思いもしませんでした。

4)CharacterとTroopMemberの類似性が気になります。
TroopMemberはCharacterを継承できなかったのでしょうか？

softya（ソフト屋) さんが書きました:インベーダーとしては完成度は高いと思います。
ただ、本家より弾や砲台の移動速度が低めなのはわざとでしょうか？
なんかBASICで作られた移植版を見ているかのような感じです。

フラッシュとyoutubeの動画を何本か見て作ったっていうレベルのインベーダーのパクリものなんで
本家とはたぶんどこかしら違うかと思います。

softya（ソフト屋) さんが書きました: ざっと見ただけですが、
1)SequenceManagerはシングルトンにしたほうが素直では？と思いました。

そうでした。いくつも実態はいらないですね。シングルトンにすべきでした。

softya（ソフト屋) さんが書きました: 2)メンバ名の分担がよく分からないです。
Update();
Shot();
Action();
Move();
と別れてますが基準が良く分かりません。

例えばShot()ならショット系の処理を...みたいな感じでまとめたのですがわかりにくいようですね。
次の改良点にします。

softya（ソフト屋) さんが書きました: 3)クラスの説明がないので、何を担当しているクラスかわからないものが有る。
解析するまでHeroが砲台だとは思いもしませんでした。

コメント少なすぎました。すみませんでした。

主人公の機体じゃなく砲台なんですか？勘違いしてました。てっきり地球を守る主人公の機体（英雄）かと思っていました。

softya（ソフト屋) さんが書きました: 4)CharacterとTroopMemberの類似性が気になります。
TroopMemberはCharacterを継承できなかったのでしょうか？

継承できました。（最初は継承でやっていました。）しかし階層が深くなるのでやめました。
代替案としてキャラの重複部のパラメータを構造体とし、それを持つことにしました。
少しコード量は増えるものの、時間を置いた後見返したときやクラス全体として見たときにわかりやすいのでは？と考えたためです。

ところでこの継承について質問です。
ゲーム造りでは深い継承や実装継承や差分プログラミングというものは　わりと許容されているのでしょうか？
IS-Aなどまったくお構いなしに継承できればかなりコードは減らせるだろうなと組んでいて思いました。
この辺りどうなのでしょうか？

たくさんのクラスに分かれているのに、GameとかEnemyTroopsが各オブジェクトに対して過度に干渉している印象を持ちました。
もっとクラスの独立性を高めたほうが良い気がします。

GameIsOverメソッドなど機能と名前が食い違っている印象がところどころにあります。
コメントがほとんどないのでいっそう感じるのだと思います。

本家のインベーダーゲームは、すべてのインベーダーが一度に動くのではなく、一匹ずつ動きます。
それを実現するには高度な状態遷移の実装が必要になるので挑戦してみてはいかがでしょうか。

dig さんが書きました: ところでこの継承について質問です。
ゲーム造りでは深い継承や実装継承や差分プログラミングというものは　わりと許容されているのでしょうか？
IS-Aなどまったくお構いなしに継承できればかなりコードは減らせるだろうなと組んでいて思いました。
この辺りどうなのでしょうか？

深い継承自体はやっぱり回避したいというのがゲーム作りでもいえると思います。

ただゲームの場合、ゲーム内のオブジェクトを一元管理したい時がままあります。
（当たり判定やら、更新やら描画やら）
そういったときにゲーム内のすべてのオブジェクトが基底であるオブジェクトから派生させるというのは、
よくある手法だと思います。

まあ、そうはいってもせいぜい４階層くらいが個人的には限度かなあと思います。

３Ｄゲームの場合は、
基底⇒２Ｄ、３Ｄの描画方法で派生⇒PlayerやEnemyなど大まかなくくりに派生⇒それぞれのタイプに派生
これぐらいだとまあまあ、あるかなという感じです。
２Ｄのみなら２個目をぬかして設計する感じです。

まあ、これもあくまで個人的な感覚ですが…。

dig さんが書きました:ゲーム造りでは深い継承や実装継承や差分プログラミングというものは　わりと許容されているのでしょうか？

ゲーム制作はマスターアップ直前まで実装を変更する可能性があります。
大きなところは知りませんが、わたしの知る限りではほとんどの現場でフレームワークのインターフェースを継承する程度止まりでした。

dig さんが書きました:IS-Aなどまったくお構いなしに継承できればかなりコードは減らせるだろうなと組んでいて思いました。

本家インベーダーゲームは少ないメモリに収めるために涙ぐましい努力をされていると思います。
そういった点で共通項がたくさん見えると思いますが、それは設計としては決してやっていけないことです。

それに完成したゲームを見ているから言えることであって、これから作ろうというところにそのような設計を持ち込んだら、自ら作った枷に囚われてがんじがらめになること必至です。
さらに、そのようにして書かれたコードは使い回しの効かないものになってしまいます。

ネットにあるゲームプログラミングの入門的な記事でも、クラスを使って作るのに都合の良い部分だけを解説していたり、都合の良いようにゲームデザインを変えていたりするものばかりですし。

【誤字修正】

やはり深くなるとデバッグを困難にするので避けたほうが良いと思いますので、深すぎたら全体的に見直す必要があるかもしれません。
今回の場合はTroopMember_A/TroopMember_B/TroopMember_Cの問題なので継承では無い実装にすれば解決するような気がします。

本家の動きは、こんな感じです。だいぶ違うのが分かって頂けると思います。
[youtube][/youtube]

ISLe さんが書きました:たくさんのクラスに分かれているのに、GameとかEnemyTroopsが各オブジェクトに対して過度に干渉している印象を持ちました。
もっとクラスの独立性を高めたほうが良い気がします。

GameIsOverメソッドなど機能と名前が食い違っている印象がところどころにあります。
コメントがほとんどないのでいっそう感じるのだと思います。

本家のインベーダーゲームは、すべてのインベーダーが一度に動くのではなく、一匹ずつ動きます。
それを実現するには高度な状態遷移の実装が必要になるので挑戦してみてはいかがでしょうか。

独立性がまだ足りないですか...次の改善点にします。
本家のインベーダーゲームの動きを完璧に真似るのは難しそうですね。
あの敵の移動は状態遷移でやっているんですか？なんだかややこしそうですね。まったくイメージが湧きません。
ただ、FPSの試作作成に取り掛かりたいので、これ以上はやらないかもです。

ISLe さんが書きました: 深い継承自体はやっぱり回避したいというのがゲーム作りでもいえると思います。

ただゲームの場合、ゲーム内のオブジェクトを一元管理したい時がままあります。
（当たり判定やら、更新やら描画やら）
そういったときにゲーム内のすべてのオブジェクトが基底であるオブジェクトから派生させるというのは、
よくある手法だと思います。

まあ、そうはいってもせいぜい４階層くらいが個人的には限度かなあと思います。

３Ｄゲームの場合は、
基底⇒２Ｄ、３Ｄの描画方法で派生⇒PlayerやEnemyなど大まかなくくりに派生⇒それぞれのタイプに派生
これぐらいだとまあまあ、あるかなという感じです。
２Ｄのみなら２個目をぬかして設計する感じです。

まあ、これもあくまで個人的な感覚ですが…。

個人的には継承は拡張や修正が楽ですが、後から見るときにコード追うのが大変かなと思います。
4階層ぐらいですか...参考にします。

ISLe さんが書きました: 本家インベーダーゲームは少ないメモリに収めるために涙ぐましい努力をされていると思います。

本家は本当に努力されていると思います。
外側から見ると3日でできるんじゃないか？なんて思ってしまいますが、組んでみると結構難しかったです。

ISLe さんが書きました: そういった点で共通項がたくさん見えると思いますが、それは設計としては決してやっていけないことです。
それに完成したゲームを見ているから言えることであって、これから作ろうというところにそのような設計を持ち込んだら、自ら作った枷に囚われてがんじがらめになること必至です。
さらに、そのようにして書かれたコードは使い回しの効かないものになってしまいます。
ネットにあるゲームプログラミングの入門的な記事でも、クラスを使って作るのに都合の良い部分だけを解説していたり、都合の良いようにゲームデザインを変えていたりするものばかりですし。

設計の決まりごとはやはり極力守るべきということですね。

softya（ソフト屋） さんが書きました: やはり深くなるとデバッグを困難にするので避けたほうが良いと思いますので、深すぎたら全体的に見直す必要があるかもしれません。
今回の場合はTroopMember_A/TroopMember_B/TroopMember_Cの問題なので継承では無い実装にすれば解決するような気がします。

確かに違うのは絵とスコアだけなので継承しなくても良かったかもしれません。switchでも代替可能でした。

softya（ソフト屋） さんが書きました: 本家の動きは、こんな感じです。だいぶ違うのが分かって頂けると思います。

波打つように動いてますね。またショット同士の衝突も判定するみたいですね。
速度もだいぶ違います。
ショット衝突、速度変更は即実装可能ですが、この波打つような描画はどうやっているのか気になります。

波打っているのは描画の書き換えが見えているだけです。ＶＲＡＭが遅いのが原因ですね。
そこは擬似的に真似できな訳では無いですが時間の無駄かなと。
それぞれのインベーダーの移動タイミングが違うのは真似するとより本物っぽくなります。

インベーダーが動くとき波打っているように見えるのは、一匹ずつ動いているからですよ。
#場面転換時に画面が徐々に消えていくのが分かるのは描き換えが見えているせいですけど。
インベーダーが撃たれて爆発パターンが表示されているあいだインベーダーの動きが止まりますが、インベーダー同士の隙間の空く場所が都度違うのが分かるでしょうか。

これは演出じゃなくて一匹ずつ動かすことしかできないくらいハードウェアが非力だったのが理由だと思います。

一匹ずつ表示されたり、一匹ずつ動いたり、消えるときは全体が止まったり、というのはオブジェクト指向的に作ると高度な状態遷移になります。
PCで作る場合は環境に配慮した制約もありますし。

ISLe さんが書きました:インベーダーが動くとき波打っているように見えるのは、一匹ずつ動いているからですよ。
#場面転換時に画面が徐々に消えていくのが分かるのは描き換えが見えているせいですけど。
インベーダーが撃たれて爆発パターンが表示されているあいだインベーダーの動きが止まりますが、インベーダー同士の隙間の空く場所が都度違うのが分かるでしょうか。

これは演出じゃなくて一匹ずつ動かすことしかできないくらいハードウェアが非力だったのが理由だと思います。

一匹ずつ表示されたり、一匹ずつ動いたり、消えるときは全体が止まったり、というのはオブジェクト指向的に作ると高度な状態遷移になります。
PCで作る場合は環境に配慮した制約もありますし。

私は一斉に降りるときの波打ちの話だと思ったけど、そっちの話が正解ですね。

softya（ソフト屋) さんが書きました:私は一斉に降りるときの波打ちの話だと思ったけど、そっちの話が正解ですね。

インベーダーが一段下がるときも一匹ずつですよ。

ISLe さんが書きました:

softya（ソフト屋) さんが書きました:私は一斉に降りるときの波打ちの話だと思ったけど、そっちの話が正解ですね。

インベーダーが一段下がるときも一匹ずつですよ。

正確に言うとティアリングが見えるですね。ごめんなさい。

YouTubeの動画ですが、一時停止してカーソルキーの左右を押すとコマ送りできるのでじっくり確認できますよ。
動画のフレームレートが低いのでインベーダーが何匹か一度に動いているように見えますが、実際は一匹ずつです。

ISLe さんが書きました:YouTubeの動画ですが、一時停止してカーソルキーの左右を押すとコマ送りできるのでじっくり確認できますよ。
動画のフレームレートが低いのでインベーダーが何匹か一度に動いているように見えますが、実際は一匹ずつです。

本物で確認してみました。
[youtube][/youtube]

本物だと分身というかティアリングしている様に見えますね。

本家スペースインベーダーは、スプライト機能のない時代のハードで、モノクロビットマップを描き換えています。
レインボーと呼ばれる消し損なうバグが有名ですが、いわゆる部分描き換えなので、前の位置に描いてあったイメージと一瞬重なるのがテアリングのように見えるのかと思います。
テアリングではなく、描き換えの遅さが原因です。

そもそもスペースインベーダーの筐体はモニタが縦置きで、走査線は縦に走っているので、横に裂けることはないですし。

波打つ移動らしいものを作ってみました。
こんな感じでしょうか？

[フォルダ内容]
Applicationフォルダ：　アプリケーション（移動修正版）と画像ファイル等

ますますBASICゲームっぽくなりましたね。
たぶん原因は横への移動量と全体が動くことに掛かる時間だと思います。
まぁ、インベーダー再現に拘らないのであればここらへんでやめておくことが無難です。

softya（ソフト屋) さんが書きました:ますますBASICゲームっぽくなりましたね。
たぶん原因は横への移動量と全体が動くことに掛かる時間だと思います。
まぁ、インベーダー再現に拘らないのであればここらへんでやめておくことが無難です。

そうですね。この辺りでやめておきます。

softya様
ISle様
katariya様
評価のおかげで改善点が見つかりました。
ありがとうございました。

これにてトピックを解決済みとさせていただきます。

dig さんが書きました:波打つ移動らしいものを作ってみました。
こんな感じでしょうか？

わたしは良いと思います。
チープな感じを受けるのは横の移動量が本家より大きいだけの問題かと。
本家は4回の移動で一キャラ分のはずですけど、倍くらいになってますよね。

あと、細かいことを言えば折り返しの仕方が違います。
本家は真下に下がるのではなく、折り返しとともに一段下がるので斜めに移動します。

本家そっくりになるとそれはそれで問題なので適当なところでやめておいたほうが良いですね。

ISLe さんが書きました: わたしは良いと思います。
チープな感じを受けるのは横の移動量が本家より大きいだけの問題かと。
本家は4回の移動で一キャラ分のはずですけど、倍くらいになってますよね。

あと、細かいことを言えば折り返しの仕方が違います。
本家は真下に下がるのではなく、折り返しとともに一段下がるので斜めに移動します。

本家そっくりになるとそれはそれで問題なので適当なところでやめておいたほうが良いですね。

本家は4回で1キャラ分ですか...知りませんでした。
本家を完全コピーすることが目的ではないのでこの辺りでやめておきます。
敵の移動の考え方については勉強になりました。
ありがとうございました。

はじめまして、ターボと申します。

インベーダーゲームダウンロードしてやってみました。

私はブロック崩しやインベーダーゲームやパックマンやテトリスみたいなレトロなゲームが好き(ファミコン世代なので)これからも頑張ってください。

技術的なレスじゃないのですがこのゲームとても面白かったです。