ブロック崩し(未)晒し with ソースコード
まだまだ未知の世界
青白いボヤッとしたものが電子です。緑の棒で電子を跳ね返して黄色いブロックを崩します。今当たり判定のテスト中なので緑棒が中心にあります。
キャラクターをBuilderパターンで生成
動機
今までは図形を描く関数(OpenGLを使って描画しています。参考:Drawing 2D stuff (SFML / Resources / 2.0 tutorials))を使って図形を描いてました。しかし、自分の作ったキャラクターを使いたい。だから自前の画像を管理するクラスを書きました。
自分でキャラクターを管理するためには、初期位置、初期速度、画像ハンドル・・・、色々なパラメータを予め設定しておく必要があります。しかし、これらをコンストラクタで一気に設定しようとすると引数が冗長になり可読性が著しく低下します。
だから中間に専門業者を挟むBuilderパターンを実装してみました。
Builderパターンは以前にも実装したことがあります。(参考:【新歓展示に向けて】Merritt et al. 4-coil~イチヨウは作れる~No.2 - 幸福の物理)ただ、だいぶ前のことなのでまた一から書き直しました。*1
ソースコード
恥ずかしながらソースコードをGistにて晒しました。プログラムというものは自分で悩むよりも人からツッコまれたほうが早く的確に書けると実体験で学びました。つまり、「参考にしてくれ!」というより「ツッコんでくれ!」が目的です。
The Game which I make now.This is still incomplete ...
ちなみにこれらはgistコマンドでターミナルからGistに投稿しました。ターミナルに一行書くだけで投稿できるなんて便利ですね!
std::shared_ptrかstd::unique_ptrか
私は忘れっぽい人間です。newなんてしたらdeleteし忘れるのがオチです。だからスマートポインタの力を借りることにしました。
今回悩んだのは158行目のvoid createObject()です。newを回避するためにはstd::shared_ptrを使うべきか、それともstd::unique_ptrを使うべきか。
結局、std::unique_ptrを使うことに落ち着きました。多分この方が簡潔で軽くて良い?
296行のstd::shared_ptrは保留状態です。これからどうすべきか考えます。
目標
当たり判定の修正とキャラクターの管理ですかね。
当たり判定がおかしいです。電子が棒の下から当たるとすり抜けます。早く直さねば。
キャラクターの管理は難しい。キャラクターがたくさんいたらそれだけたくさんのクラスを書かないといけないってことですよね。以前キャラクターを.csvファイルで管理した経験を活かすか?(参考:【STG開発入門】Excelでスクリプティング~敵キャラ管理~&動画作成・投稿”初”体験 - 幸福の物理)
でもBuilderパターンでのキャラクター管理は経験ありません。さあどうしよう。
それからそろそろ物理エンジンも実装したいです。具体的にはクーロン力です。オイラー法でいいのかな?
└(՞ةڼ◔)」<恥ずかしィ~!///