ページ 1 / 2
ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 14:58
by Rittai_3D
どうも、C++を挫折しそうな3Dです。またお世話になります。
最近C++ばっかりやっていますが、わからないところが多すぎて諦め気味です。
という訳で、久しぶりにC言語を使って簡単な弾幕シューティングゲームを作ろうと思いました。
そこで、C++っぽくオブジェクト指向を意識してやってみようと思いましたが、シューティングゲームにおけるオブジェクトとは一体なんだ?と思い、行き詰まっています。
ここで質問です。シューティングゲームにおけるオブジェクトとは何でしょうか?
また、シューティングゲームだけでなく、他の種類のゲーム(RPGなど)のオブジェクトも教えていただけるとありがたいです。
【開発環境】
Dxライブラリ
Visual C++2008 Express Edition
WindowsXP
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 15:08
by h2so5
オブジェクトというのは要するに「名詞」です。
シューティングゲームに出てくる名詞を列挙してみましょう。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 15:27
by Rittai_3D
>>h2so5様
返信ありがとうございます。
h2so5 さんが書きました:オブジェクトというのは要するに「名詞」です。
シューティングゲームに出てくる名詞を列挙してみましょう。
当方あまりゲームをしないので不足している部分もあるかもしれませんが、
自機
雑魚
ボス
弾幕
自機ショット
くらいしか思いつきません。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 15:33
by softya(ソフト屋)
背景や点数表示も名詞ですね。
この作業は、一種のオブジェクト指向分析です。
「オブジェクト指向分析設計 - Wikipedia」
http://ja.wikipedia.org/wiki/%E3%82%AA% ... D%E8%A8%88
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 15:45
by Rittai_3D
>>softya様
返信ありがとうございます。
背景と点数表示を忘れていました。言われていればそうですね。
リンク先を読ませていただきます。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 15:48
by softya(ソフト屋)
あと画像の形として見えない処理もあります。考えてみて下さい。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 15:56
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:あと画像の形として見えない処理もあります。考えてみて下さい。
自機画像
ボム画像/計算(忘れてました)
弾画像
(ボード?画像)
(被弾処理?)
これ以上は全く思いつきません。他にあれば是非教えて頂きたいです
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 16:21
by softya(ソフト屋)
そこを考えるのが一番重要なので安易にはお答えしませんよ。答えを早く求め過ぎでは無いかと思います。
じっくり図や紙に色々書いて考えてみてください(人により方法が違う)。
それが分析や設計の方法です。
あとSTGにボムは必須ではありませんし、弾幕と弾画像は別のオブジェクトなのでしょうか。
安易に機能を増やしすぎるのはMusicRoomで懲りたのでは?
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 16:30
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:そこを考えるのが一番重要なので安易にはお答えしませんよ。答えを早く求め過ぎでは無いかと思います。
じっくり図や紙に色々書いて考えてみてください(人により方法が違う)。
それが分析や設計の方法です。
おっしゃる通りです。自分の悪い癖で、知りたいことはすぐに他人に聞いてしいます。自分でじっくり考えて見ます。
紙は無くしやすいので、テキストファイルにでも書いてみます。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 16:38
by softya(ソフト屋)
紙は無くしても良いんですよ。思考をまとめるツールにすぎません。
まとめたら、テキストに起こせば良いんです。
あるいは、Draw系のツール使っても良いでしょう。
↓ この間ISLeさんが紹介していたWEBツール。
「Gliffy Editor - Online」
https://www.gliffy.com/go/html5/launch? ... 00200c9a66
OpenOfficeにも似たのはあります。
紙などでオブジェクト間の相互作用を書きだしてみると足らない物が見えてきますので良かったら試してみて下さい。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 17:03
by ISLe
何もないところからオブジェクトを想像するのは難しいと思うので、ネットに転がってるゲームのスクリーンショットから映っているものをひとつ残らずピックアップしてみるとかしてみたらどうでしょう。
あるいは思い付いたものを紙に描いて(丸や四角の中に名前を書く程度でよし)スクリーンショットに仕立ててみれば足りないものが見えてくると思います。
振る舞いに関してはそのあとにしたほうが良いのではないでしょうかね。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 17:57
by Rittai_3D
>>softya様
返信ありがとうございます
生憎、OpenOfficeは持ってないです...
WEBツールを教えていただきありがとうございます。自分の部屋のPCはネットに繋がってないので紙に書きたいと思います。
softya(ソフト屋) さんが書きました:紙などでオブジェクト間の相互作用を書きだしてみると足らない物が見えてきますので良かったら試してみて下さい。
この図は「敵が弾を出したら弾を描写する」という解釈でよろしいですか?
この方法でやってみたいと思います。参考になります。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 18:01
by Rittai_3D
>>ISLe様
返信ありがとうございます。
ISLe さんが書きました:何もないところからオブジェクトを想像するのは難しいと思うので、ネットに転がってるゲームのスクリーンショットから映っているものをひとつ残らずピックアップしてみるとかしてみたらどうでしょう。
あるいは思い付いたものを紙に描いて(丸や四角の中に名前を書く程度でよし)スクリーンショットに仕立ててみれば足りないものが見えてくると思います。
振る舞いに関してはそのあとにしたほうが良いのではないでしょうかね。
了解しました。やってみます。
丸や三角に意味はありますでしょうか?丸は更新(?)処理で三角は描写、みたいな...
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 18:04
by softya(ソフト屋)
> この図は「敵が弾を出したら弾を描写する」という解釈でよろしいですか?
違いますよ。敵オブジェクトが弾オブジェクトに対して、弾の生成を依頼している所です。
これがISLeさんが振る舞いと表現した部分です。
ただ、その前にISLeさんの言われる作業を徹底した方が良いと思いますね。
やってみてなさそうですし。
>丸や三角に意味はありますでしょうか?丸は更新(?)処理で三角は描写、みたいな...
丸は自機、三角は敵機では?
オブジェクトの振る舞いではなく仮想ゲーム画面を作れって話ですから。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 18:11
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:> この図は「敵が弾を出したら弾を描写する」という解釈でよろしいですか?
違いますよ。敵オブジェクトが弾オブジェクトに対して、弾の生成を依頼している所です。
これがISLeさんが振る舞いと表現した部分です。
ただ、その前にISLeさんの言われる作業を徹底した方が良いと思いますね。
やってみてなさそうですし。
そういう意味だったんですか。失礼しました。
今まで龍神録のプログラムをマネしていただけなのでやります。
softya(ソフト屋) さんが書きました:>丸や三角に意味はありますでしょうか?丸は更新(?)処理で三角は描写、みたいな...
丸は自機、三角は敵機では?
オブジェクトの振る舞いではなく仮想ゲーム画面を作れって話ですから。
オブジェクトの振る舞いだと解釈していました。すいません。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 18:41
by softya(ソフト屋)
そういえばオブジェクトなどまとめていけばわかりますが、MusicRoomよりも遥かに複雑なものになるんですが覚悟されていますよね?
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 18:49
by ISLe
オブジェクトのピックアップを徹底したあとの話ですが。
描画というのは実装ですから、振る舞いとは別に考えないといけません。
むしろ設計段階では実装をなるべく除外してください。
オブジェクトとしての本質的な振る舞いを考えてください。
実装に依存しない仕様です。
当たり前のことを書かなくて済めば仕様がシンプルになります。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 19:09
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:そういえばオブジェクトなどまとめていけばわかりますが、MusicRoomよりも遥かに複雑なものになるんですが覚悟されていますよね?
はい。MusicRoomはC/C++の勉強がてら作り始めただけですので。また、C++verはC++が完全に理解できていなかったのでと考えています。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 19:13
by Rittai_3D
>>ISLe様
返信ありがとうございます。
ISLe さんが書きました:オブジェクトのピックアップを徹底したあとの話ですが。
描画というのは実装ですから、振る舞いとは別に考えないといけません。
むしろ設計段階では実装をなるべく除外してください。
オブジェクトとしての本質的な振る舞いを考えてください。
実装に依存しない仕様です。
当たり前のことを書かなくて済めば仕様がシンプルになります。
わかりました。描画って実装なんですね。勉強になります。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 19:18
by softya(ソフト屋)
実のところ「二兎を追う者は一兎をも得ず」を心配しています。
この場合は、「オブジェクト指向的な設計」と「始めての規模で組むSTG」です。
3D_3Dさんにある程度経験があれば止めないのですが、MusicRoomを見ている限りは混乱すると思います。
つまり、規模を落としたほうが良いんじゃない?って事ですね。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 19:26
by Rittai_3D
>>softya様
返事ありがとうございます。
softya(ソフト屋) さんが書きました:実のところ「二兎を追う者は一兎をも得ず」を心配しています。
この場合は、「オブジェクト指向的な設計」と「始めての規模で組むSTG」です。
3D_3Dさんにある程度経験があれば止めないのですが、MusicRoomを見ている限りは混乱すると思います。
つまり、規模を落としたほうが良いんじゃない?って事ですね。
規模を落とす、とはSTGではなく、もっと簡単なものから始めた方がいいということですか?
確かに、まともに作ったものがブロック崩し程度なので、他のものから始めた方がいいかもしれません。ただ、STGくらいしか作りたいものが見つからないので…
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 19:29
by softya(ソフト屋)
では、シューティングの規模を下げましょう。龍神録並じゃなく仕様をそげ落として下さい。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月30日(火) 19:52
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:では、シューティングの規模を下げましょう。龍神録並じゃなく仕様をそげ落として下さい。
わかりました。夏休みの課題が終わらなそうなので、明日考えてみます。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 10:08
by Rittai_3D
一応自分なりに書いてみました。
おかしいところ、足りないところなどを教えてください。
また、画像からピックアップしたものを書きだしてみました。こちらもおかしいところなどがありましたら教えてください。
コード:
SS( スクリーンショット )からピックアップ
・弾幕( ボスショット )
・ボス
・自機
・背景
・ボム
・ボム数
・体力ゲージ
・残機
・自機ショット
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 10:52
by softya(ソフト屋)
作れる範囲に仕様を削っていないと思われるので、削った想定画面を作りましょう。
・ボム必要ですか?
・豪華な弾幕必要ですか?
・ボスは必要ですか?
最初のが上手く行ったら次に機能追加して作れば良いだけなので、最初は思っきり減らして下さい。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 11:16
by usao
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 11:35
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:作れる範囲に仕様を削っていないと思われるので、削った想定画面を作りましょう。
・ボム必要ですか?
・豪華な弾幕必要ですか?
・ボスは必要ですか?
最初のが上手く行ったら次に機能追加して作れば良いだけなので、最初は思っきり減らして下さい。
もっと削って良いんですか?わかりました。どんどん減らして行きます。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 11:37
by Rittai_3D
usao さんが書きました:私なら最初はこれだけかなぁ
そんな少なくて良いんですか?分かりました。参考にさせていただきます
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 12:07
by usao
>そんな少なくて良いんですか?
私なら,です.
ご自身がやれる範囲で最初から用意するものを決めればいいと思います.
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 12:20
by Rittai_3D
>>usao様
返信ありがとうございます。
usao さんが書きました:私なら,です.
ご自身がやれる範囲で最初から用意するものを決めればいいと思います.
わかりました。とりあえず、自分でできる範囲のものでやってみます。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 12:29
by Rittai_3D
usao様とsoftya様のアドバイスを元に作り直してみました。
これも、何かおかしいとかありましたら指摘お願いします。
#Fieldの文字を削除しました
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 12:50
by softya(ソフト屋)
自分の弾が無いですが狙い通りですか?
あとフィールドとbackgroundって何が違うんでしょうか?
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 12:55
by Rittai_3D
>>softya様
返信ありがとうございます
softya(ソフト屋) さんが書きました:自分の弾が無いですが狙い通りですか?
あとフィールドとbackgroundって何が違うんでしょうか?
自機ショットはとりあえずはずしました。たぶん混乱してしまうような気がして。
フィールドは間違いです。本当はそこはボードでした。(
http://dixq.net/rp/7.html のボードのことです。)
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 13:05
by softya(ソフト屋)
ボードって必要でしょうか?
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 13:11
by Rittai_3D
>>softya様
返信ありがとうございます
要らないですね。よく考えていませんでした。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 15:25
by Rittai_3D
では、取り敢えずv0002.pngの画像を元に作って行きたいと思います。
また詰まったら質問に来ます。その時もよろしくお願いします。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 16:33
by ISLe
作る作らないは別として、観察力とか解析能力を鍛えるために既存ゲームのスクショからオブジェクトをピックアップするのは続けてはいかがでしょう。
ヒットコンボ関連とかまるっと抜けてますし。
参考にしたスクショのゲームは道中とボスのシーンではレイアウトが違うので、先にやるのは道中のほうが良いと思います。
ボスシーンに移行するとき画面のパーツが移動するので、実際にどの部分がどういうふうに動いているか見るともっと分かりやすいですが。
いまできる範囲で『設計』すると実際にできる範囲よりずっと規模の小さいものになってしまうと思います。
特に初心者にとって『実装』できるかどうかでふるいにかけるべき問題を『設計』に持ち込むと成長を止めてしまうことになると思います。
突拍子もない仕様を思い付いても困りますが、そうならないためにもスクショを参考にしての訓練は有効だと思います。
言葉にできれば実装できるとわたしは思います。
Re: ゲームのオブジェクト指向について
Posted: 2013年7月31日(水) 17:11
by Rittai_3D
>>ISLe様
返信ありがとうございます。
ISLe さんが書きました:作る作らないは別として、観察力とか解析能力を鍛えるために既存ゲームのスクショからオブジェクトをピックアップするのは続けてはいかがでしょう。
ヒットコンボ関連とかまるっと抜けてますし。
ゲームだけだったのでボス戦を選んでしまいました。道中でもやってみます。
ヒットコンボ関連は後回しにしていました。
ISLe さんが書きました:参考にしたスクショのゲームは道中とボスのシーンではレイアウトが違うので、先にやるのは道中のほうが良いと思います。
ボスシーンに移行するとき画面のパーツが移動するので、実際にどの部分がどういうふうに動いているか見るともっと分かりやすいですが。
いまできる範囲で『設計』すると実際にできる範囲よりずっと規模の小さいものになってしまうと思います。
特に初心者にとって『実装』できるかどうかでふるいにかけるべき問題を『設計』に持ち込むと成長を止めてしまうことになると思います。
突拍子もない仕様を思い付いても困りますが、そうならないためにもスクショを参考にしての訓練は有効だと思います。
言葉にできれば実装できるとわたしは思います。
ありがとうございます。これから道中のスクショを調べてやって見ます。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:13
by Rittai_3D
現在、道中のスクショから想定画面を作成していますが、ボス戦とあまり変わらないです。v0002.pngの画像に雑魚を付け加えただけの物になりました。( 現場報告 )
また、ISLe様から指摘がありましたヒットコンボ関連はシューティングの基礎が出来てからの方がいいでしょうか?
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:24
by メリモ
C++使えたら全ての言語余裕でしょうってくらいC++はむずいですね。
JavaがC++の下位互換って聞いてびっくりしました。Javaも相当難しいんですけどね。クラスの大半は意味不明です。
Javaはハードとかにも詳しくないとやってられないと思いますね。頑張って下さい。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:41
by Dixq (管理人)
> Javaはハードとかにも詳しくないとやってられないと思いますね。
真逆だと思います。
CはともかくJavaのような高級言語はハードに依存することなくかけることが利点であり、
世界で一番良く使われている言語であるだけあって非常に使いやすく作りこまれていると思います。
Androidアプリを作る時にいつもJavaを使いますが非常に使いやすい言語だと私は思いますよ。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:46
by softya(ソフト屋)
ISLeさんの言うスクショからものはあくまで訓練ですので、やるやらないは別にしてオブジェクト対象物を全部上げることに意義があります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:47
by メリモ
すいません。このままだと荒れると判断して削除させて頂きました。wwwwを使うことじたい荒れる原因です。 by softya(ソフト屋) 22:52ごろ。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:51
by softya(ソフト屋)
もう言っていることがめちゃくちゃです。
C言語の方も理解度が怪しいと納得しました。
元を削除いたしました。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:52
by Dixq (管理人)
メリモさんは言っていることがおかし過ぎます・・。
ちょっと話が横道にそれましたね、これ以上ここで、CやJavaの話はしない方が良いようです。ごめんなさい。
(softyaさんの対応に沿って私も前言撤回します。ここではこれ以上話さないようにします)
さて、
オブジェクト指向での設計についてですが、
http://dixq.net/rp/
の下に「龍神録C++版オープンソース化計画は第三回あたりで中断中・・。」ってリンクがあるんで、
参考になるか分かりませんが、参考になればどうぞ。
第二回にクラス図があります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 22:57
by メリモ
↑上なんだ?
僕は自分で削除してないですが、あなた誰ですか?勝手に人の名前騙らないで下さい。 softya(ソフト屋)が削除しました。
管理人さん
ハードっていうからおかしいんですね。Javaはシステマチックで難しいってことです。
それとロックとかスレッドとか言いたかっただけです
管理人さんプログラマーで僕素人なんだから手加減してくださいよ
「添削」 荒れる原因になる口調を修正させて頂きます。 by softya(ソフト屋) 23:09ごろ。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 23:01
by softya(ソフト屋)
申し訳ありませんが荒れる原因と判断し管理人権限で添削しております。3D_3Dさんの迷惑になるので、3D_3Dさんの質問と関係の無い書き込みはご遠慮ください。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月01日(木) 23:03
by メリモ
そういえば人のスレでしたね。自重します。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:18
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:ISLeさんの言うスクショからものはあくまで訓練ですので、やるやらないは別にしてオブジェクト対象物を全部上げることに意義があります。
訓練をしないとプログラミングは上達しないような気がするのでやります。
質問ですが、オブジェクト指向は対象物ごとにcppファイルやclassなどを分けることですよね?
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:22
by softya(ソフト屋)
対象物の定義が微妙ですが、眼に見えない物も含めてクラスに分けることです。ファイルを分けるのは別の単位の話なのでオブジェクト指向とは完全には関係ないですね。
【補足】
実装上は、管理クラスや制御クラスが必要になる場合もあります。これが設計上と実装上で違うって事ですね。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:27
by Rittai_3D
>>Dixq様
返信ありがとうございます。
Dixq (管理人) さんが書きました:
さて、
オブジェクト指向での設計についてですが、
http://dixq.net/rp/
の下に「龍神録C++版オープンソース化計画は第三回あたりで中断中・・。」ってリンクがあるんで、
参考になるか分かりませんが、参考になればどうぞ。
第二回にクラス図があります。
拝見させていただきました。オブジェクトの分け方の参考にさせていただきます。
いままでオブジェクト指向を全く意識しないでプログラミングしてきたので、とても参考になります。
クラス図もあまり書いたことがないのでオブジェクト指向の理解を深めるとともに設計するように頑張ります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:32
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:対象物の定義が微妙ですが、眼に見えない物も含めてクラスに分けることです。ファイルを分けるのは別の単位の話なのでオブジェクト指向とは完全には関係ないですね。
【補足】
実装上は、管理クラスや制御クラスが必要になる場合もあります。これが設計上と実装上で違うって事ですね。
ファイルを分けるのは完全には関係無いのですか。
では、C言語でオブジェクト指向プログラミングする場合はどのようにすればいいと思いますか?C++のようにC言語はclassが無いので気になっています。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:35
by softya(ソフト屋)
C言語はファイルで分けるのが良いと思います。
いや、もっと面倒なC言語によるオブジェクト指向はありますけどね。
これはC++よりもある意味面倒なので。
「C 言語によるオブジェクト記述法 COOL」 ← 参考
http://www.sage-p.com/process/cool.htm
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:46
by Rittai_3D
>>softya様
返事ありがとうございます。
C言語はファイルで分けるのですか…てっきり構造体みたいなやつでクラスもどきつくって〜とかすると思いまして質問させていただきました。
リンク先をざっと見させていただきましたが、確かに面倒なことになってますね。取り敢えず、C言語でファイルで分けてやります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:50
by KORYUOH
クラス図が書けるようになってきたら
ゲームの取説からクラス図を作ってみるといい訓練になるかもしれません
実際、私の学校の授業で一回やったので
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:56
by Rittai_3D
>>KORYUOH様
返信ありがとうございます。
KORYUOH さんが書きました:クラス図が書けるようになってきたら
ゲームの取説からクラス図を作ってみるといい訓練になるかもしれません
実際、私の学校の授業で一回やったので
クラス図自体書いたことが無いので(1〜2回程度です。)まずはクラス図を書けるように訓練します。
あと、自分はゲームをほとんど持っていませんので、適当なフリーゲームをダウンロードしてみます。
(本当にゲームを持っていません。10年くらい前のポケモンなら持ってるはずですが)
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 00:58
by softya(ソフト屋)
KORYUOH さんが書きました:クラス図が書けるようになってきたら
ゲームの取説からクラス図を作ってみるといい訓練になるかもしれません
実際、私の学校の授業で一回やったので
それは中々良さそうですね。選ぶゲーム次第で大変なことにはなりそうですが。
で、分け方ですが。
とりあえずファイルを分けただけだと継承とか出来ないので、オブジェクト化・カプセル化を徹底してください。
構造体とか形から入るより、そちらを徹底した方が良いと思います。
なお、クラスポインタの代わりに構造を見せない構造体ポインタを返すと言う実装はC言語でも比較的楽なのでやってみても良いと思います。
※ 前方宣言した構造体のポインタを使います。私のRPG講座でも使っています。
【補足】
出来ることは言うなればカプセル化とインスタンスの生成です。
「マイ 日記 • C言語交流フォーラム ~ mixC++ ~」 ← RPG講座の日記です。
http://dixq.net/forum/blog.php?u=114&sd=a&c=2&start=10
「ちょー簡単RPG講座7-1 ゲーム本編画面遷移」で解説しているのが、それです。他にも使ってますけどね。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 01:07
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:KORYUOH さんが書きました:クラス図が書けるようになってきたら
ゲームの取説からクラス図を作ってみるといい訓練になるかもしれません
実際、私の学校の授業で一回やったので
それは中々良さそうですね。選ぶゲーム次第で大変なことにはなりそうですが。
で、分け方ですが。
とりあえずファイルを分けただけだと継承とか出来ないので、オブジェクト化・カプセル化を徹底してください。
構造体とか形から入るより、そちらを徹底した方が良いと思います。
なお、クラスポインタの代わりに構造を見せない構造体ポインタを返すと言う実装はC言語でも比較的楽なのでやってみても良いと思います。
※ 前方宣言した構造体のポインタを使います。私のRPG講座でも使っています。
当方、あまりゲームをやらないので(3回め)
オブジェクト化やカプセル化…ですか?聞いたことはあるけどしたことは無いので試行錯誤しながらやってみます。
RPG講座を見させていただきます。頑張ってオブジェクト指向プログラミングをマスターしたいと思います。
明日以降に自分なりにカプセル化やオブジェクト化したコードを貼るので採点していたたまければ幸いです
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 17:10
by Rittai_3D
とりあえず、自分なりに書いてみました。カプセル化やオブジェクト化を調べながらやってみました。
main.cpp
コード:
#include "DxLib.h"
#include "key.h"
#include "player.h"
#include "BackGrd.h"
bool ProcessLoop()
{
if( ProcessMessage() != 0 ) return false;
if( ClearDrawScreen() != 0 ) return false;
if( GetHitKeyStateAll_2() != 0 ) return false;
return true;
}
int WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR, int )
{
ChangeWindowMode( TRUE ), DxLib_Init(), SetDrawScreen( DX_SCREEN_BACK );
ch_t plry;
Player_Init( &plry );
Player_Load();
BG_Init();
BG_Load();
while( ProcessLoop() ){
BG_Calc();
Player_Calc( &plry );
BG_Draw();
Player_Draw( plry );
ScreenFlip();
}
Player_Fina();
BG_Fina();
DxLib_End(); // DXライブラリ使用の終了処理
return 0; // ソフトの終了
}
player.cpp
コード:
#include "DxLib.h"
#include "key.h"
#include "player.h"
#include <math.h>
static double Speed = 4.5; // 移動スピード
static int m_img_ch;
static int m_img_ysize[ 3 ] = { 0, 48, 96};
static int m_img_xsize[ 8 ] = { 0, 32, 64, 96, 128, 160, 192, 224};
void Player_Init( ch_t* player )
{
memset( player, 0, sizeof( ch_t )); // 初期化
player->x = 384/2;
player->y = 448*3/4;
}
void Player_Load()
{
m_img_ch = LoadGraph( "dat/pl00.png" );
}
void Player_Draw( ch_t player )
{
DrawRectRotaGraphF( (float)player.x, (float)player.y,
m_img_xsize[0], m_img_ysize[0],
30, 46, 1.0f, 0.0f, m_img_ch,
TRUE, FALSE );
}
void Player_Calc( ch_t* player )
{
bool joge_flag = false, sayu_flag = false; // 上下左右移動フラグ
double naname = 1.0; // 斜めのときの速度
if( CheckStateKey( KEY_INPUT_DOWN ) != 0 ){ player->y += Speed/naname; joge_flag = true; }
if( CheckStateKey( KEY_INPUT_UP ) != 0 ){ player->y -= Speed/naname; joge_flag = true; }
if( CheckStateKey( KEY_INPUT_LEFT ) != 0 ){ player->x -= Speed/naname; sayu_flag = true; }
if( CheckStateKey( KEY_INPUT_RIGHT) != 0 ){ player->x += Speed/naname; sayu_flag = true; }
if( CheckStateKey( KEY_INPUT_LSHIFT ) != 0 ) Speed = 2.5;
else Speed = 4.5;
if( joge_flag && sayu_flag ) naname = sqrt( 2.0 );
if( player->x < 48 ) player->x = 48;
if( player->x > 400 ) player->x = 400;
if( player->y < 38 ) player->y = 38;
if( player->y > 440 ) player->y = 440;
}
void Player_Fina()
{
DeleteGraph( m_img_ch );
}
BackGrd.cpp
コード:
#include "DxLib.h"
#include "BackGrd.h"
static int m_cnt;
static int m_img_back;
void BG_Init()
{
m_cnt = 0;
}
void BG_Load()
{
m_img_back = LoadGraph( "dat/Back.png" );
}
void BG_Draw()
{
SetDrawArea( 32 , 16 , 416 , 464 ) ;//描画可能エリアを設定
DrawGraph( -32, m_cnt%480+16-480, m_img_back, FALSE);
DrawGraph( -32, m_cnt%480+16 , m_img_back, FALSE);
SetDrawArea( 0, 0, 640, 480);//エリアを戻す
}
void BG_Calc()
{
m_cnt++;
}
void BG_Fina()
{
DeleteGraph( m_img_back );
}
key.cpp
コード:
#include "DxLib.h"
#include "key.h"
static unsigned int stateKey[ 256 ];
int GetHitKeyStateAll_2()
{
char GetHitKeyStateAll_Key[ 256 ];
GetHitKeyStateAll( GetHitKeyStateAll_Key );
for(int i=0;i<256;i++){
if( GetHitKeyStateAll_Key[i]==1 ) stateKey[i] ++;
else stateKey[i] = 0;
}
return 0;
}
int CheckStateKey( unsigned char Handle )
{
return stateKey[ Handle ];
}
player.h
コード:
#pragma once
typedef struct
{
int flag;
double x,y;
} ch_t;
void Player_Init( ch_t* player );
void Player_Load();
void Player_Draw( ch_t player );
void Player_Calc( ch_t* player );
void Player_Fina();
key.h
コード:
int GetHitKeyStateAll_2();
int CheckStateKey( unsigned char );
BackGrd.h
コード:
#pragma once
void BG_Init();
void BG_Load();
void BG_Draw();
void BG_Calc();
void BG_Fina();
v0002.pngを元に自分なりに作ってみました。また、ゲームの設計と分割コンパイル (3)(
http://dixq.net/g/d_05.html )を参考にさせていただきました。オブジェクト化やカプセル化などで間違っているところがありましたら、ご指摘お願いします。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 17:23
by softya(ソフト屋)
とりあえず、気になったこと
・名前は素直に! FinaじゃなくFinal。一文字節約して読みづらなくなっても意味ないです。
・Playerの構造体の実構造を外部に公開する必要などありません。構造体の前方宣言でカプセル化できます。
つまり、今はカプセル化出来てないよって事です。 mallocしなくても良いので、実体定義はplayer.cppで行いましょう。
・ch_tはプレーヤー専用でしょうか? であれば名前に気をつけるべきです。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 17:32
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:とりあえず、気になったこと
・名前は素直に! FinaじゃなくFinal。一文字節約して読みづらなくなっても意味ないです。
・Playerの構造体の実構造を外部に公開する必要などありません。構造体の前方宣言でカプセル化できます。
つまり、今はカプセル化出来てないよって事です。 mallocしなくても良いので、実体定義はplayer.cppで行いましょう。
・ch_tはプレーヤー専用でしょうか? であれば名前に気をつけるべきです。
詳しくありがとうございます。
・名前はPlayer_~の部分がみんな4文字ですごく気になったのでFinaにしました。修正します。
・構造体の前方宣言はやったことがないのでこちらも調べながらやってみます。
・ch_tはプレイヤー専用の構造体です。player_tにします。
これらを踏まえてもう一度やってみます。
#そういえば、上のコードはVisual C++ 2010でコンパイルしています。自分のPCは訳ありで使用できませんでした。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 17:37
by softya(ソフト屋)
忘れてました!
・どうにもマジックナンバーが散見されます。出来るだけ減らしましょう。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 17:41
by usao
コード:
typedef struct
{
int flag;
double x,y;
} ch_t;
これだと,flagやx,yを外部からいじれる→カプセル化 にはなっていない.
それと,無名構造体は避けた方がよいです(前方宣言できなくなる).
で,ch_t型インスタンスがもし自機1つ分しか作られないのであれば,
背景と同じようにch_t変数の存在を隠ぺいしてしまえば良いのかな.
ch_t型を他のもの(例えば敵とか)でも使いまわす予定なら,
「新しいch_t型インスタンスを作成し,そのハンドルを返す」ような関数をPlayer.hにて公開し,
その他の,現在ch_t*を引数としている関数の引数を,ch_t*ではなくそのハンドルの型 に変更する.
(あとは,当然ながら,インスタンスを削除する関数も追加)
Player_Calc()がキーの状態を見に行くのは微妙.
キーが押されたかどうか(というよりも上下あるいは左右に動くべきかどうか)という情報を引数に受ける方がいいと思う.
#あと,Player_Calc()内のnanameって効いてなくないですか?
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 17:45
by softya(ソフト屋)
そういえばそうですね。
player_tは1つしか無いなら外部公開の必然が無いですね。
全部、隠して良いでしょう。
敵の時には公開を考慮する必要有りですけどね。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 18:07
by usao
うーん,あと,私だったらなるべく各オブジェクトには自身の描画処理を行わせない方針でやるかも.
仮に各オブジェクトに自身の描画を行わせるという方式を取るのだとしても
画像のロードと始末とか まではやらせたくないかなぁ…
各コードがDXLibへ依存することは妥協するとしても
画像ロード(と破棄)はmain等の外側で行って,例えば
コード:
//hImgにはpCHが示すインスタンスが描画の際に用いる画像のハンドル値を指定する.
//この関数は,成功時には0でない値を,エラー時は0を返す.
int Player_Init( ch_t *pCH, int hImg )
{
//hImgが,ch_tの表示用に見合うものかどうかを判定し,ダメならエラーとする
if( 画像サイズとか調べたらダメっぽい )
{ return 0; }
...
return 1;
}
みたくしてインスタンスに画像を指定する形を取るとかすると思う.
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 18:17
by softya(ソフト屋)
それも方針ですが、Dixqさんと私の方式だとクラス内でハンドルを得てますね。
リソース管理をどうするかの設計の問題なので、どちらが良いとは言えませんが、自身のリソース確保を外部に委ねる気がするので私は外部から受け取るのはちょっと避けたいです。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 18:39
by Rittai_3D
>>usao様
返信ありがとうございます。
usao さんが書きました:コード:
typedef struct
{
int flag;
double x,y;
} ch_t;
これだと,flagやx,yを外部からいじれる→カプセル化 にはなっていない.
それと,無名構造体は避けた方がよいです(前方宣言できなくなる).
で,ch_t型インスタンスがもし自機1つ分しか作られないのであれば,
背景と同じようにch_t変数の存在を隠ぺいしてしまえば良いのかな.
ch_t型を他のもの(例えば敵とか)でも使いまわす予定なら,
「新しいch_t型インスタンスを作成し,そのハンドルを返す」ような関数をPlayer.hにて公開し,
その他の,現在ch_t*を引数としている関数の引数を,ch_t*ではなくそのハンドルの型 に変更する.
(あとは,当然ながら,インスタンスを削除する関数も追加)
Player_Calc()がキーの状態を見に行くのは微妙.
キーが押されたかどうか(というよりも上下あるいは左右に動くべきかどうか)という情報を引数に受ける方がいいと思う.
#あと,Player_Calc()内のnanameって効いてなくないですか?
今まで無名構造体を使ってきたので慣れてませんが前方宣言に慣れて行きたいです。
Player_Move関数を作ってやってみます。
質問ですが、引数に受けるとはどういう意味でしょうか?
# 確かに効きませんね。修正します。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 18:46
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:そういえばそうですね。
player_tは1つしか無いなら外部公開の必然が無いですね。
全部、隠して良いでしょう。
敵の時には公開を考慮する必要有りですけどね。
とりあえず全部隠してみます。
また、まだ敵に関する事は何一つやっておりませんが、敵の方が大変そうですね。STGは完成させておきたいので、頑張ります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 18:51
by Rittai_3D
>>usao様
返信ありがとうございます。
usao さんが書きました:うーん,あと,私だったらなるべく各オブジェクトには自身の描画処理を行わせない方針でやるかも.
仮に各オブジェクトに自身の描画を行わせるという方式を取るのだとしても
画像のロードと始末とか まではやらせたくないかなぁ…
各コードがDXLibへ依存することは妥協するとしても
画像ロード(と破棄)はmain等の外側で行って,例えば
コード:
//hImgにはpCHが示すインスタンスが描画の際に用いる画像のハンドル値を指定する.
//この関数は,成功時には0でない値を,エラー時は0を返す.
int Player_Init( ch_t *pCH, int hImg )
{
//hImgが,ch_tの表示用に見合うものかどうかを判定し,ダメならエラーとする
if( 画像サイズとか調べたらダメっぽい )
{ return 0; }
...
return 1;
}
みたくしてインスタンスに画像を指定する形を取るとかすると思う.
自分としては、引数が長くなるのが嫌なので今迄はそのような方法をとっていませんでした。本当にそれだけの理由です。
質問ですが、インスタンスに画像を指定する形のメリットとデメリットを教えて頂きたいです。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 18:55
by Rittai_3D
>>sofrya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:それも方針ですが、Dixqさんと私の方式だとクラス内でハンドルを得てますね。
リソース管理をどうするかの設計の問題なので、どちらが良いとは言えませんが、自身のリソース確保を外部に委ねる気がするので私は外部から受け取るのはちょっと避けたいです。
なぜリソース確保を外部に委ねることを避けたいのですか?初心者のちょっとした質問です。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 19:01
by usao
無名構造体がどうの の話は
コード:
typedef struct ch_t //←ここに構造体の名前を書くようにしようね
{
int flag;
double x,y;
} ch_t;
//そうすれば,別のファイルにて前方宣言が使える.
//ch_tが定義されているヘッダをincludeしなくても
struct ch_t; //このように「ch_tというstructがあるらしいよ」という宣言を書けば…(名前が無いとこれが書けない)
ch_t CH; //これは無理だけど
ch_t *pCH; //こっちが可能になる.
ということです.(ch_tがどんな変数を抱えているかとかを知らなくていい場所にはそういう情報を公開せずに済む.)
>質問ですが、引数に受けるとはどういう意味でしょうか?
例えばこんな感じ.
コード:
const unsigned char DIRECTION_LEFT = 0x01;
const unsigned char DIRECTION_RIGHT = 0x02;
const unsigned char DIRECTION_UP = 0x04;
const unsigned char DIRECTION_DOWN = 0x08;
//dirには今回移動すべき方向を示す値を指定する.
//これは,↑の4つの値をORでまとめたも値にする.左上なら DEIRECTION_LEFT | DIRECTION_UP とか.
void Player_Calc( ch_t *pCH, unsigned char dir )
{
if( dir & DIRECTION_LEFT ){ ←方向移動処理... }
...
}
キー入力の判定はPlayer_Calc()呼び出し側でやり,その結果を引数に渡す.
自機オブジェクトに「キー押下で動く」という仕様を含めなくてよいと思う.
こうしておけばキー押されてなくても強制的に動かしたりもできる.(イベント的なシーンとか,リプレイとか?)
>画像をどこで読んだり捨てたりするか の話
これはまぁ好きな方法でやればいいのかな.
各オブジェクトが内部で自分が使うのをロードする方式だと
・同じリソースを複数個所で共有するとかしたくなった場合(わかりやすいとこだと,同じ種類の敵が複数出てくるとか)
をどういう風に扱うのか
・いろんなタイミングで「画像がロードできない」のようなエラーが発生し得るのがうざい
といった点に適切な対応さえすれば,わかりやすい方式だとは思います.
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 19:08
by softya(ソフト屋)
リソースを自分で管理するのは、利用する全部のリソースを見渡しやすいから(可読性・メンテナンス性)です。
重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。と言うか大抵そうします。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 19:18
by softya(ソフト屋)
あと移動方向をusaoさんの言うように外部から受け渡すにはメリットとデメリットがあります。
メリットは、usaoさんの言うとおりですが、デメリットとしてキー操作に対する処理がプレーヤーのオブジェクトに無いのは直感を裏切る可能性が高いと思います。
どこのオブジェクトにあるべきかと言うのは重要問題で、上位のマネージャ・オブジェクトが細かい処理まで受け持つのはオブジェクトの特性を無視することになりかねません。
と言うことで私はplayerオブジェクト内部派です。
違う意見が2つの話が出てきて混乱すると思いますが、まぁ現場でもよく有ることです。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 19:21
by usao
>重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。と言うか大抵そうします。
こんな感じでしょうか.
コード:
ImgManager *GetImgManagerInstance(); //画像リソースを一元管理するオブジェクトへのポインタを返す
int ObjectInitialize( Object *pObjInstance, const char *ImgFileName ) //←これはさすがに受け取るのだと思う
{
pObjInstance->ImgHandle = GetImgManagerInstance()->GetImgHandle( ImgFIleName );
if( pObjInstance->ImgHandle == INVALID_IMG_HANDLE_VALUE ) //※INVALID_IMG_HANDLE_VALUE:無効なハンドルを指す何らかの値
{ エラー }
...
}
キーの処理も内部ですか……オブジェクトにどこまでの責任を持たせるか?という思想の違いなんでしょうね.
とにかく質問者様はご自身がやりやすい(わかりやすい&コーディングしやすい?)方法を選択されればよいと思います.
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 20:41
by Rittai_3D
>>usao様
返信ありがとうございます。
usao さんが書きました:無名構造体がどうの の話は
コード:
typedef struct ch_t //←ここに構造体の名前を書くようにしようね
{
int flag;
double x,y;
} ch_t;
//そうすれば,別のファイルにて前方宣言が使える.
//ch_tが定義されているヘッダをincludeしなくても
struct ch_t; //このように「ch_tというstructがあるらしいよ」という宣言を書けば…(名前が無いとこれが書けない)
ch_t CH; //これは無理だけど
ch_t *pCH; //こっちが可能になる.
ということです.(ch_tがどんな変数を抱えているかとかを知らなくていい場所にはそういう情報を公開せずに済む.)
おお!こんなことが出来るなんて!感動しました。
今まで知らずにやってきたのが恥ずかしくなりました。
今すぐにでもソースを修正したいですが、今日の分の課題が終わらないので明日修正します。
usao さんが書きました:>質問ですが、引数に受けるとはどういう意味でしょうか?
例えばこんな感じ.
コード:
const unsigned char DIRECTION_LEFT = 0x01;
const unsigned char DIRECTION_RIGHT = 0x02;
const unsigned char DIRECTION_UP = 0x04;
const unsigned char DIRECTION_DOWN = 0x08;
//dirには今回移動すべき方向を示す値を指定する.
//これは,↑の4つの値をORでまとめたも値にする.左上なら DEIRECTION_LEFT | DIRECTION_UP とか.
void Player_Calc( ch_t *pCH, unsigned char dir )
{
if( dir & DIRECTION_LEFT ){ ←方向移動処理... }
...
}
キー入力の判定はPlayer_Calc()呼び出し側でやり,その結果を引数に渡す.
自機オブジェクトに「キー押下で動く」という仕様を含めなくてよいと思う.
こうしておけばキー押されてなくても強制的に動かしたりもできる.(イベント的なシーンとか,リプレイとか?)
これはビット演算ですか?ビット演算やシフト演算は苦手なのであまりしたく無いです…
usao さんが書きました:>画像をどこで読んだり捨てたりするか の話
これはまぁ好きな方法でやればいいのかな.
各オブジェクトが内部で自分が使うのをロードする方式だと
・同じリソースを複数個所で共有するとかしたくなった場合(わかりやすいとこだと,同じ種類の敵が複数出てくるとか)
をどういう風に扱うのか
・いろんなタイミングで「画像がロードできない」のようなエラーが発生し得るのがうざい
といった点に適切な対応さえすれば,わかりやすい方式だとは思います.
なるほど。自分はこのやり方では一度もやってなかったので、参考になります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 20:44
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:リソースを自分で管理するのは、利用する全部のリソースを見渡しやすいから(可読性・メンテナンス性)です。
重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。と言うか大抵そうします。
うーん、難しそうです…
自分の力で出来そうならそのようにやりますが、今の実力で出来るとは思いません…
しかし、出来るようにプログラムの勉強をします。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月02日(金) 20:49
by Rittai_3D
>>usao様
返信ありがとうございます。
usao さんが書きました:>重複する画像リソースなど問題は、画像管理マネージャに管理を一存して画像ファイル名を引数に画像管理マネージャから画像ハンドルを貰う方法があります。と言うか大抵そうします。
こんな感じでしょうか.
コード:
ImgManager *GetImgManagerInstance(); //画像リソースを一元管理するオブジェクトへのポインタを返す
int ObjectInitialize( Object *pObjInstance, const char *ImgFileName ) //←これはさすがに受け取るのだと思う
{
pObjInstance->ImgHandle = GetImgManagerInstance()->GetImgHandle( ImgFIleName );
if( pObjInstance->ImgHandle == INVALID_IMG_HANDLE_VALUE ) //※INVALID_IMG_HANDLE_VALUE:無効なハンドルを指す何らかの値
{ エラー }
...
}
キーの処理も内部ですか……オブジェクトにどこまでの責任を持たせるか?という思想の違いなんでしょうね.
とにかく質問者様はご自身がやりやすい(わかりやすい&コーディングしやすい?)方法を選択されればよいと思います.
自分は、多少長くなってもわかりやすいように書きたいと思います。後で自分で書いたコードを見たときに混乱しそうな気がするので…
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:03
by Rittai_3D
今日、プログラムを書いていて思ったのですが、player.hに構造体を書いてありますよね。で、player.hをmain.cppでincludeしているので隠蔽できてないのではないでしょうか?
あと、それ以外はちゃんと隠蔽できていますか?
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:07
by softya(ソフト屋)
3D_3D さんが書きました:今日、プログラムを書いていて思ったのですが、player.hに構造体を書いてありますよね。で、player.hをmain.cppでincludeしているので隠蔽できてないのではないでしょうか?
あと、それ以外はちゃんと隠蔽できていますか?
はい。出来ていないです。
なので私とusaoさんが前方宣言の話をしていました。
前方宣言を上手く使うことで構造体の構造を隠蔽できます。
※ 私のRPG講座が例になります。
他は相互作用がないので、今のところ問題ないです。
ただ、今後相互作用を追加していく時にカプセル化を守れるかが課題です。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:15
by Rittai_3D
softya(ソフト屋) さんが書きました:はい。出来ていないです。
なので私とusaoさんが前方宣言の話をしていました。
前方宣言を上手く使うことで構造体の構造を隠蔽できます。
※ 私のRPG講座が例になります。
他は相互作用がないので、今のところ問題ないです。
ただ、今後相互作用を追加していく時にカプセル化を守れるかが課題です。
では、struct.hのようなファイルを作ってそこに書いたほうがいいでしょうか?
カプセル化、オブジェクト化などはやったことがないので四苦八苦しています。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:19
by softya(ソフト屋)
3D_3D さんが書きました:softya(ソフト屋) さんが書きました:はい。出来ていないです。
なので私とusaoさんが前方宣言の話をしていました。
前方宣言を上手く使うことで構造体の構造を隠蔽できます。
※ 私のRPG講座が例になります。
他は相互作用がないので、今のところ問題ないです。
ただ、今後相互作用を追加していく時にカプセル化を守れるかが課題です。
では、struct.hのようなファイルを作ってそこに書いたほうがいいでしょうか?
カプセル化、オブジェクト化などはやったことがないので四苦八苦しています。
C言語のカプセル化の場合は、構造体の実構造は構造体のメンバを使う関数群があるcppファイルの先頭に記述します。
そうしておいて、前方宣言だけをヘッダファイルに記述します。
struct.hは使いません。私のRPG講座の例もそうなっているはずです。
私のRPG講座の例で分からないことがあれば聞いてくださいね。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:32
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:C言語のカプセル化の場合は、構造体の実構造は構造体のメンバを使う関数群があるcppファイルの先頭に記述します。
そうしておいて、前方宣言だけをヘッダファイルに記述します。
struct.hは使いません。私のRPG講座の例もそうなっているはずです。
私のRPG講座の例で分からないことがあれば聞いてくださいね。
つまり、関数のプロトタイプ宣言みたいなものだと解釈してもよろしいですか?
>私のRPG講座の例で分からないことがあれば聞いてくださいね
優しいお言葉ありがとうございます。理解できるように頑張ります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:35
by softya(ソフト屋)
> つまり、関数のプロトタイプ宣言みたいなものだと解釈してもよろしいですか?
そういう事です。前方宣言はサイズな不明な構造体となるのでポインタでしか扱えないものとなります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 16:58
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:> つまり、関数のプロトタイプ宣言みたいなものだと解釈してもよろしいですか?
そういう事です。前方宣言はサイズな不明な構造体となるのでポインタでしか扱えないものとなります。
だからポインタを使用するのですか!
引数に渡さなないほうがいいですよね?
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 17:06
by softya(ソフト屋)
ポインタであれば引数にできます。ここが多分初心者には難しいと思います。
逆に実体はPlayer.cpp以外で作れないためmainなどで実体宣言は出来なくなります。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 17:15
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:ポインタであれば引数にできます。ここが多分初心者には難しいと思います。
逆に実体はPlayer.cpp以外で作れないためmainなどで実体宣言は出来なくなります。
では、staticをつけてグローバルに player_t *player; とかしたほうがいいですか?
#ch_tはplayer_tに変更しました
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 17:17
by softya(ソフト屋)
staticが必要かどうかはそれだけの情報だと分かりませんが、ポインタ変数であれば不要の可能性が高いです。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 17:30
by usao
カプセル化の話が既存のものから読み取りにくいのかもしれない(?)ので,簡単な例.
コード:
//[Player.h]
struct Player_t; //前方宣言
Player_t *CreatePlayerInstance(); //新しいPlayer_tインスタンスを生成し,そのインスタンスへのポインタを返す
void ReleasePlayerInstance( Player_t *pReleaseTargetInstance ); //指定インスタンスを破棄する
void SetPlayerStatusValue( Player_t *pSetTargetInstance, int status ); //「ステータス」として何らかの値を設定しておける機能がある
int GetPlayerStatusValue( const Player_t *pPrintTargetInstance ); //設定してあるステータス値を得る
たとえばこんなのをmain側でincludeした場合を考えるとわかりやすい.
Player_t型の定義や関数群の実装はたとえばPlayer.cppとかにあり,main側からは見えない.
main側はPlayer_tがどんな型なのかわからないので,構造体メンバ変数をいじったりできない.
ただ,必要な仕事は関数に任せればよいということを知っているだけ.
[追記]
一応main側の雰囲気も書いときますね.
コード:
#include "Player.h"
int main()
{
//Player_tインスタンスを作成
Player_t *pPlayerInstance = CreatePlayerInstance();
//Player_t周りの処理は,処理関数にpPlayerInstanceを渡すことで行う
...
int CurrPlayerStatus = GetPlayerStatusValue( pPlayerInstance );
//不要になったらインスタンス破棄する
ReleasePlayerInstance( pPlayerInstance );
//※これ以降,pPlayerInstanceの指す先は無効となるので注意する.
pPlayerInstance = NULL; //念のためNULLにしておいたり.
...
}
#なんか最近すぐに勝手にログアウトされてしまうな…
オフトピック
No.74のコード…
全部Cで書かなきゃと思ってたのにC++が半端に混じった変な書き方になってしまっていますね……
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 17:50
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:staticが必要かどうかはそれだけの情報だと分かりませんが、ポインタ変数であれば不要の可能性が高いです。
分かりました。ポインタにはstaticは不要ですね。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 18:10
by Rittai_3D
>>usao様
返信ありがとうございます。
usao さんが書きました:カプセル化の話が既存のものから読み取りにくいのかもしれない(?)ので,簡単な例.
コード:
//[Player.h]
struct Player_t; //前方宣言
Player_t *CreatePlayerInstance(); //新しいPlayer_tインスタンスを生成し,そのインスタンスへのポインタを返す
void ReleasePlayerInstance( Player_t *pReleaseTargetInstance ); //指定インスタンスを破棄する
void SetPlayerStatusValue( Player_t *pSetTargetInstance, int status ); //「ステータス」として何らかの値を設定しておける機能がある
int GetPlayerStatusValue( const Player_t *pPrintTargetInstance ); //設定してあるステータス値を得る
たとえばこんなのをmain側でincludeした場合を考えるとわかりやすい.
Player_t型の定義や関数群の実装はたとえばPlayer.cppとかにあり,main側からは見えない.
main側はPlayer_tがどんな型なのかわからないので,構造体メンバ変数をいじったりできない.
ただ,必要な仕事は関数に任せればよいということを知っているだけ.
オフトピック
No.74のコード…
全部Cで書かなきゃと思ってたのにC++が半端に混じった変な書き方になってしまっていますね……
サンプルありがとうございます。質問ですがmainではどのように書くのですか?
コード:
int WINAPI WinMain( HINSTANCE, HINSTANCE, LPSTR, int )
{
ChangeWindowMode( TRUE ), DxLib_Init(), SetDrawScreen( DX_SCREEN_BACK );
struct player_t* player;
Player_Init( player );
Player_Load();
BG_Init();
BG_Load();
while( ProcessLoop() ){
BG_Calc();
Player_Calc( player );
BG_Draw();
Player_Draw( player );
ScreenFlip();
}
Player_Final();
BG_Final();
DxLib_End(); // DXライブラリ使用の終了処理
return 0; // ソフトの終了
}
と書いてしまっていいのでしょうか?
また、描写関数にはポインタを渡してもいいのでしょうか?
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 18:15
by softya(ソフト屋)
> と書いてしまっていいのでしょうか?
Player_Init( player );
これだとポインタの更新ができないので、失敗します。
経験のため一度失敗してみたほうが良いと思います。
【補足】失敗して苦労したことは中々忘れないからです。
> また、描写関数にはポインタを渡してもいいのでしょうか?
それしか無いですね。
あとplayer構造体に、後々のため画像ハンドルも含めたほうが良いですね。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 18:35
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:> と書いてしまっていいのでしょうか?
Player_Init( player );
これだとポインタの更新ができないので、失敗します。
経験のため一度失敗してみたほうが良いと思います。
【補足】失敗して苦労したことは中々忘れないからです。
> また、描写関数にはポインタを渡してもいいのでしょうか?
それしか無いですね。
あとplayer構造体に、後々のため画像ハンドルも含めたほうが良いですね。
ポインタの更新ですか?調べながらやってみます。
分かりました。描写関数にポインタを渡します。
また、player_t にimg_hdlという変数を追加します。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 18:38
by softya(ソフト屋)
私としては、このままで失敗してダメな理由を考えて欲しいです。
調べるのは失敗して考えたあとでお願いします。出来れば調べない方が良いかもしれません。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 19:32
by ISLe
オブジェクト個別にカプセル化を追求するのは勉強としては良いのかもしれないけれど、最終的にゲームプログラムとしてインターフェースを統一することを考慮しておかなくても良いのでしょうかね。
『ゲームの~』というスレタイとの乖離を感じます。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 19:43
by Rittai_3D
>>softya様
返信ありがとうございます。
softya(ソフト屋) さんが書きました:私としては、このままで失敗してダメな理由を考えて欲しいです。
調べるのは失敗して考えたあとでお願いします。出来れば調べない方が良いかもしれません。
わかりました。プログラミング力をつけるために考えて見ます。
オフトピック
思いついたのは
・どのアドレスに割り振られるかわからないうちに初期化されるから、かなと思いました。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 19:54
by Rittai_3D
>>ISLe様
返信ありがとうございます。
ISLe さんが書きました:オブジェクト個別にカプセル化を追求するのは勉強としては良いのかもしれないけれど、最終的にゲームプログラムとしてインターフェースを統一することを考慮しておかなくても良いのでしょうかね。
オブジェクト指向になれるためにSTGを作り始めたので全く考慮はして無いです。本格的に作るわけではないので意識するつもりはないと考えました。
ISLe さんが書きました:『ゲームの~』というスレタイとの乖離を感じます。
そうですね。シューティングゲームのオブジェクトは何?から始まってシューティングを作り始めてしまったので今更別トピックにしようと思いました。player部の隠蔽が終われば"オブジェクト指向でのシューティングゲームの作り方"みたいなトピックを立てます。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月03日(土) 20:34
by へにっくす
3D_3D さんが書きました:・どのアドレスに割り振られるかわからないうちに初期化されるから、かなと思いました。
違います。
ヒントは、関数の受け渡し方です。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月04日(日) 07:41
by Rittai_3D
>>へにっくす様
返信ありがとうございます。
へにっくす さんが書きました:3D_3D さんが書きました:・どのアドレスに割り振られるかわからないうちに初期化されるから、かなと思いました。
違います。
ヒントは、関数の受け渡し方です。
ヒントありがとうございます。ポインタではなく関数なんですね。また考えて見ます。
オフトピック
そういえば、player_t player;にしてPlayer_Init( &player );としたときはうまく行きましたが、
player_t *player;のときのPlayer_Init( player );は失敗します。
では、
コード:
player_t *player;
int test;
&test = player;
とかしたらどうなるでしょう。デバッガを駆使して値の変化を見て見ます。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月04日(日) 10:15
by へにっくす
3D_3D さんが書きました:そういえば、player_t player;にしてPlayer_Init( &player );としたときはうまく行きましたが、
player_t *player;のときのPlayer_Init( player );は失敗します。
C言語は
すべて値渡し※なので、その値を変更しても戻ることはありません。ではなぜ&をつけるとうまくいくのか考えてみてください。
Re: ゲームのオブジェクト指向について
Posted: 2013年8月04日(日) 10:23
by Rittai_3D
>>へにっくす様
返信ありがとうございます。
へにっくす さんが書きました:C言語は
すべて値渡し※なので、その値を変更しても戻ることはありません。ではなぜ&をつけるとうまくいくのか考えてみてください。
&はたしか先頭アドレスを示しますよね。
アドレス値ではなく、先頭アドレスを返すからですか?