オブジェクト指向を学ぶ〜継承とコンポジションについて〜
ビームについて具体的に実装する前に
ビームオブジェクトと主人公オブジェクトの関係を文章に落とし込みつつ、
オブジェクトの性質を他のオブジェクトに持たせるための方法について
勉強したのでまとめます。
今回は継承とコンポジションについて具体例を交えつつ、
そのメリットを享受できるように解説していきます。
ゲーム画面に配置する”モノ”オブジェクトとして以下を挙げられます。
①主人公
②敵
③画面(背景)
④スコアボード(数字を表示するフレーム？)
⑤ビーム(主人公オブジェクトにおけるコンポジション)
⑥通常ビームと特殊ビーム(元ビームクラスのサブクラス)
※分かりやすくするために何もついていない⑤のビームを
以後は元ビームと呼ぶことにします。
※②③④は設計上出てきますがここでは関係ないです。
⑥ビームクラスにおいてコンポジションとかサブクラスという言葉が出てきました。
サブクラスについては以前、オブジェクト指向について学びましたが、
私自身の向学のために簡単におさらいしておきます。
クラスというのは継承ができるということでした。
あるクラスAをクラスBが継承すると
クラスAはクラスBの親クラスとなり
クラスBはクラスBの子クラスとなります。
この例では元ビームクラスは通常ビームクラスと特殊ビームクラスの親であり、
実際の世界においても子どもは親の遺伝子は持っているので
親の元ビームは通常ビームと特殊ビームが満たすべき性質を両方持たなくてはなりません。
性質を集合に例えると、元ビーム(親クラス)が持つ性質は和集合部分(共通部分)です。
なので、通常ビームと特殊ビームのそれぞれのクラスは
元ビームを継承したサブクラスとします。
次に⑤の元ビームクラスにおいてコンポジションという言葉が出てきました。
これも継承と同じく、オブジェクトの性質を他のオブジェクトに持たせるための一つの方法です。
ただし、継承のように全ての性質を引き継ぐのではなく、
ざっくりしたイメージとしては”変数として持つ”＝所有物という感じです。
実際の世界を考えると分かりやすいですが、
ここで考えているビームオブジェクトは主人公が発射するものなので
主人公の所有物と考えることができます。
なので、主人公オブジェクトの中で保有物(コンポジション)として定義します。
コードロジックの概念的な構成としては以下のような感じです。
【主人公クラス】
@interface MyMachineClass : NSObject{
BeamClass *oBeam;//定義時に通常ビームとしてインスタンス化
BeamClass *sBeam;//定義時に特殊ビームとしてインスタンス化
}
【ビームクラス】
@interface BeamClass : NSObject{
CGPoint *pont;
}
@interface OrdinaryBeamClass : BeamClass{
}
@interface SpecialBeamClass : BeamClass{
}
主人公はコンポジションという形で
ビームクラスを保有します。
ビームクラスは宣言時にはBeamClassであるが、
インスタンス化される時にOrdinaryとSuperとして定義することで
サブクラスとして実体化されます。
なぜ最初からサブクラスとして定義しないかというと
恐らくビームは沢山発生させる必要があり
NSMutableArray等の配列(イメージとして弾倉、マガジン)に格納する必要があるためです。
※上記の例では分かりやすく、個別の弾丸をコンポジションとしていますが。。
そうすることで配列から取り出す時にordinaryなのかspecialなのか意識せずに取り扱えるからです。
継承の特徴として子が親の性質を受け継ぐと言いましたが、
上記の例ではBeamClassにサブクラスで共通して必要な情報、
例えば位置座標(CGPointオブジェクト)、攻撃力等を定義や
動作、例えばダメージを返す等のメソッドを定義しておけば
サブクラスであるOrdinaryとSpecialではそれらを記述しなくても使えます。
あとはそれぞれのサブクラスで差異部分だけ記述すれば良いです。
例えばOrdinaryBeamClassでは物理攻撃エフェクトのみ、
SpecialBeamClassで特殊エフェクトのみを記述します。
今日はオブジェクト指向のコンポジションと継承について学びました。
引き続き、開発を進めながらここらへんをしっかり学んでいきたいです。
とある海外掲示板での雑談〜xcodeのframework設定について〜
今回はちょっと大人の事情で横道にそれますが。
ゲーム開発と並行して、将来的に課金アイテムとか作るためフレームワークの導入について調べていました。
GPS機能を使うならCoreLocation.framework
課金アイテムを使うならStoreKit.framework
広告を使うならAdSupport.framework
SNSログインを使うならSocial.framework
サウンドエフェクト、BGMを出すならAVFoundation.framework, AudioToolBolx.framework
とかいろいろ挙げたらきりがないんですが、これらが必要らしいことが分かりました。
そして、どうやらフレームワークの設定方法には「オプショナル」と「リクイヤード」の２種類があることが分かりました。
その違いについてこちらのサイトが参考になったので軽くまとめてみました。
OSが多少古い情報ですが、議論してる内容は今の状態でも使えることなのでまとめてみました。
※なお翻訳文は正確性よりもニュアンスでざっくり性を重視してます。
カッコの文章は私の想像ですw
【質問】
I set Storekit.framework from 'Required' to 'Optional' since the last update, then I found the IAP sales is zero today.
I want to ask that does this possibly caused by setting storekit.framework to optional?
最近の更新でstorekitフレームワークをリクワイヤードからオプショナルに設定したとたん、今日の課金アイテムの販売がゼロになりました。
確認したいのですが、storekitフレームワークをオプショナルにしたことが原因と考えられますか？
(回答者現る)
Optional means your app could theoretically run on an older ios version before StoreKit was available. But if you aren't checking for it in your code before attempting to use it, then the app would just crash if it didn't exist. Otherwise, you shouldn't see any different behavior.
オプショナルとはアプリが、storekitフレームワーク利用可能なバージョン以前であっても論理的に(正しく)動作することができるということを示している(そういう風に宣言しているようなものだ)。
しかし、もし(プログラムが)フレームワークを使用する前にコード側でそのチェックがされていない場合で、かつその判定がない場合クラッシュします。
(質問者煮え切らない)
So even set it to 'Optional', this should not affect the IAP sales, right?
If I set it to 'Required', does it mean the whole app can't run on iOS 5.1?
それで、オプショナルに設定しても課金アイテムの売上には影響しないということでおk？
もしリクワイヤードに設定したら、iOS5.1では全てのアプリが起動しないということ？
(回答者大人の対応で少し噛み砕く)
Let's say StoreKit was first available in iOS 3.0 (I don't know the actual version). If you have it as Required, then no one with below 3.0 could install the app. But if it's Optional, then others could download it, but you would need to check at runtime whether or not it was available.
まずStorekitがiOS3.0から動作したとします(実際のバージョンは分かりません)。
この場合もしリクワイヤードに設定したら、3.0未満のユーザーはインストールできません。
でももしオプショナルなら誰でもダウンロードできます。でもその場合、実行時に利用可能かどうかチェックする必要があります。
(略：とある他のフレームワークの推奨についての議論が続く。
(真打ち登場！)
My understanding on optional vs required is. If your app absolutely needs a framework in order to work such as Foundation then you mark it as required because without it the app would not function. But if your app uses a non essential framework such as iAd framework then you have it as optional because not having iAds will not effect it's use ability. However if your app really must have the iAd framework you mark it as required. And but set the minimum target iOS to one that supports that framework.
If you try to support and iOS version that is too low for a framework then have it optional but have conditional code to prevent using it unless user is on correct iOS
リクワイヤードとオプショナルの違いについて私の意見です。
もし(導入しようとしているフレームワークが)Foundationのようにそのアプリで絶対に必要である場合、リクワイヤードにすべき。
なぜならそれがなければアプリは動作しないから。
でももしそのフレームワークが(例えばiAdフレームワークのように)アプリにとって絶対必要ではないなら、オプショナルにすべき。
なぜならそれがなくてもアプリは動作できるから。
しかし、iAdがあなたのアプリに絶対に必要であるなら、iAdフレームワークをリクワイヤードにして、その上でアプリの使用可能OSを(フレームワークがサポートできるバージョンに)設定すべき。
もしアプリの(が動作すると)想定されるiOSのバージョンがそのフレームワークよりも低いバージョンなら、
・フレームワークの設定をオプショナルにした上で
・ユーザー端末のOSが正しくない場合にそのフレームワークが動作しないようにコーディングする
必要がある。
結論というか感想。
アプリ上で必要なフレームワークを導入した場合、それはリクワイヤードにすべき。
※その場合、他のフレームワークで絶対に必要でなくてもオプショナルにせずに、リクワイヤードのままにしておくべき。
リクワイヤード(Required):絶対に必要なフレームワークであることを示す。
オプショナル(Optional):アプリ内で使用しているが、なくてもよいことを示す。
例えば、StoreKit.frameworkは課金アイテムの購入に必要なので
Requiredにしておくべきかと。
例え、それが他のライブラリ(例えばレビュー推奨ライブラリAppirator等)で必要であり、「導入したらoptionalに設定して下さい」という指示があっても
optionalに設定せずにRequiredに設定しておくべき。
そうしないと課金アイテムの購入ができなくなってしまうから。
あとはAdSupport.frameworkは広告を使う場合に必要ですが、
ユーザーにとって絶対に必要ではないのでOptionalでよろしいかと。
ゲーム中のプレーヤー表示②：動かす
前回までのあらすじ
・iOS Developer登録(申請篇、アクティベート篇、完結篇)
・主人公決定！
前回、画面の中で主人公の少女が翼を羽ばたくドラゴンに乗っている様子を
animationImagesに配列を格納してアニメーションで表現しました。
今回はその主人公が画面内を縦横無尽に羽ばたけるようにします。
具体的には画面をタッチしたら主人公がその位置に応じて動くようにします。
ソースコード的には主人公 が描画されるUIImageViewに対し
画面タッチで呼び出されるメソッドで位置を変化させます(リアルタイムで)。
ちなみに前回のソースコードで
主人公を表示するためのUIImageView(のuiv変数)をグローバルに宣言しましたが、
その理由が上記の通り他の(画面タッチで呼び出される)メソッドで使用するためです。
前回のソースコード
CGRect rect = CGRectMake(0, 0, 70, 70);//大きさ
uiv = (UIImageView *)[[UIImageView alloc]initWithFrame:rect];
NSArray *imgArray = [[NSArray alloc] initWithObjects:
[UIImage imageNamed:@"player.png"],
[UIImage imageNamed:@"player2.png"],
[UIImage imageNamed:@"player3.png"],
nil];
((UIImageView *)uiv).animationImages = imgArray;//uivオブジェクトに、配列に格納した画像集合をセット
((UIImageView *)uiv).animationRepeatCount = 0;//リピート回数(ゼロなので永遠にリピート)
((UIImageView *)uiv).animationDuration = 1.0f; // アニメーション全体で1秒（＝各間隔は0.33秒）
[((UIImageView *)uiv) startAnimating]; // アニメーション開始
[self.view addSubview:uiv];//viewに主人公のイメージ(uiv)を貼付ける
このコードの最後に
uiv.userInteractionEnabled = YES; UIPanGestureRecognizer *flick_frame = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(onFlickedFrame:)]; [uiv addGestureRecognizer:flick_frame];
を追加するとuiv変数をタッチすると
onFlickedFrameというメソッドが呼ばれます。
onFlickedFrameメソッドの中身は以下のようにしてみました。
- (void)onFlickedFrame:(UIPanGestureRecognizer*)gr {
CGPoint point = [gr translationInView:uiv];//uivの位置を取得する
//フリックによって動いた位置を取得する
CGPoint movedPoint = CGPointMake(uiv.center.x + point.x, uiv.center.y + point.y);
uiv.center = movedPoint;//uivの位置をセット
NSLog(@"uiv.x=%f, uiv.y=%f",//一応コンソールで確認
uiv.center.x,
uiv.center.y);
[gr setTranslation:CGPointZero inView:uiv];//よくわからないおまじない。
}
やっていることは
最初にuivの位置を取得し、
フリックによって動いた後の位置を計算(単なるベクトルの足し算)して
表示位置を実際にセットします。
フリックした時にこれらが実行されます。
最後の
[gr setTranslation:CGPointZero inView:uiv];//よくわからないおまじない。
は多分何かを初期化しているようです。
※すみません、勉強不足でよくわかりません。
実行結果は以下の通りです。
滑らかに動いてますね。よかった。。
次回は生きてたらビームとかを出してみようと思います。
続きます。
ゲーム中のプレーヤーの表示①(翼を羽ばたかせる)
前回までのあらすじ
・iOS Developer登録(申請篇、アクティベート篇、完結篇)
・主人公決定！
今回はゲーム中の画面で主人公をどうやって表示するかです。
今回はコンパクトに以下のように書いてみました。
ちなみに主人公が表現されるuivはグローバルに宣言されています。
その理由は次回説明します。
CGRect rect = CGRectMake(0, 0, 70, 70);//大きさ
uiv = (UIImageView *)[[UIImageView alloc]initWithFrame:rect];
NSArray *imgArray = [[NSArray alloc] initWithObjects:
[UIImage imageNamed:@"player.png"],
[UIImage imageNamed:@"player2.png"],
[UIImage imageNamed:@"player3.png"],
nil];
((UIImageView *)uiv).animationImages = imgArray;//uivオブジェクトに、配列に格納した画像集合をセット
((UIImageView *)uiv).animationRepeatCount = 0;//リピート回数(ゼロなので永遠にリピート)
((UIImageView *)uiv).animationDuration = 1.0f; // アニメーション全体で1秒（＝各間隔は0.33秒）
[((UIImageView *)uiv) startAnimating]; // アニメーション開始
[self.view addSubview:uiv];//viewに主人公のイメージ(uiv)を貼付ける
こうやっても簡単なパラパラマンガ的なアニメーションできるんですね。
コードはオブジェクト指向もなにもあったもんじゃありませんが、
まずは動けばいいという信念です。
ニートなので多目に見てやって下さいwwww
※実際のアニメーションではフレーム数を増やすことで動きを滑らかにしつつ、
画面中央に配置するため位置の調整もしています(ui.center = CGPointMake...っていういつものやつです)
次回はこれをフリックで動かして画面を縦横無尽に走らせますw
続きます。
主人公決定！
今までの流れです。
・iOS Developer登録(申請篇、アクティベート篇、完結篇)
そして前回、ゲームのデザイン面はプロにお願いしようということを書きました。
そしたら一日かからないウチに色々進展がありましたので報告します。
午前中、クラウドワークスとかランサーズとか徘徊してましたが、
ようやく一人のデザイナーさんにお願いできることになりました。
お名前はまだ許可をもらってないので非公開ですが、
後で許可を貰えたら(ステマにならない程度に)公開します。
今の所、アイデアとしてスクロール型のシューティングゲームということで
お互いに意見を出し合える感じで進めていきましょう的なノリになりました。
この軽(ぬる)いノリが社会の脱落者ニートにとっては一番重要なのかもしれません。
ざっくり話した内容をまとめると、
以前は主人公はグラディウス的な機体を想定していましたが、
正直な所私自身、人物プレーヤーか飛行機プレーヤー？か迷っていた部分もあって
人物プレーヤーにするなら可愛い少女の方がいいなーっていう希望を伝えた所
先方もそれなら描けるということでしたので
女の子にすることにしました。
断じて私が変態だからではありません。
でも女の子がシューティングゲームの主人公になる場合、
飛行するのはどうするんだろうって考えたんですが、
・マントみたいなのを使って飛ぶ(スーパーマンみたいなww)
・何かに乗って飛ぶ(動物とか飛行機とか)
変に細かいところが気になってしまって
多分どうでもいい設定なんでしょうけど、
私のこだわりとして普通の少女が冒険する感じにしたかったので
少女自身が飛ぶというよりは動物とかに乗ってほしいと伝えました。
昔エウレカセブンにハマってた影響で髪の長さはショートカットでお願いしますと伝えました。
そんですぐに帰ってきたのが、⬇です。
！！━━━━Σ(ﾟдﾟ；)━━━━
動物は、、、せっかくなら仮想的な動物・・そうですねードラゴンとか？って提案したらすぐに⬇が来ました。
・・・・・・！
破壊力とんでもないです。
さすがです、クオリティ高いのもそうですけど、まず思ったのが
ちょwwwはえーーwww
連絡して一時間くらいで返信とイメージが届きました。
髪の色についてどうしましょう？って相談したらすぐに三色で帰ってきました。
(しつこいようですが昔エウレカセブンにハマってた影響で)やっぱり髪の色は緑でっていうのをお願いしたら⬇が来ました。
目の色は髪と同じ緑か、ピンク、茶色のどれかがいいと思うんですが
イメージ湧きませんねーって伝えたら早速選択肢がww
(もしかして俺って面倒くさい客？という自己嫌悪に陥りつつ妥協はしてはいけないと思って)髪の色と目の色を変えたらどうなりますか？って言ったら
⬇が帰ってきます(とにかく早いですww
・・・
・・・
・・・
うーーん、やっぱり目の色は緑がいいなーってことで
緑色にしました。
あとは髪のつやとか肌の色に生気を出して
全体的に(ドラゴンのも)筋肉とかの影を付けて下さいってお願いしました。
んで、最終形がコチラです⬇
・・・！ ！
アーティストさんってはんぱないっすね。
ちなみに私の絵のレベルは⬇です。
これはこれで・・・！！って感じですが。
最初はこれでどうにかしようと思ってた自分が恥ずかしいです。
次回、ゲーム中に出て来るプレーヤーも作っていく予定です。
ゲーム中のプレーヤーの動きはobjective-cのアニメーション機能で実装します。
続きます。
※ちなみに著作権は先方との契約時に当方に所属するということになっているので、デザイナーさんにも申し訳ないですし無断転載はお控えいただければと思います。
ニートがゲームを作ってみようとしようとしたらwww
機能を作る前からデザインについて考えてます。
技術的なことはあとからでも追加できそうですが、
デザインは残念ながら(とても残念なことですが)私の手には負えません。
ということで、グーグル先生にお伺いを立てたら
凄腕のデザイナーさん(アーティストさんとお呼びすれば良いのかもしれませんが)が沢山いるじゃないですか。。
いろいろ見た私の感覚では
フリー素材で作品を出している人や
有料素材では作品を出し続けている人はとても技術レベルがたかいですw
今ではクラウドソーシングって言うんでしょうか、
クラウドワークスとかランサーズ、ココナラのような有料の仕事依頼のプラットフォームもあるようです。
いろいろ眺めた結果、
前者の素材のみ販売しているwebサービスでは作品を定期的に出品している方の技術レベルはとても高いですが、
作者へのアクセス方法が限定されていたり、個別の依頼とか追加依頼に柔軟に対応して頂けるのか不安です。
クラウドワークスとランサーズは大御所というだけあって
依頼がかなり出されてて活気がブラウザを通して伝わってきます。
ココナラは価格が限定されているだけあってちょこっとした作業を手軽にお願いできる感じでした。
これからいろいろなアーティストさんとお話を進めて、価格交渉とかデザインの方向性について
お話を進めつつゲームのデザイン面を決めていこうと思います。
数人に絞り込みつつ、最終的には当方の経済的事情をご理解頂ける一人のデザイナーさんに決めようと思います。
いつになったらゲーム作り始めるんだって声が聞こえそうなので
並行して開発も進めていきたいです。
続きます。
腹減った
今日もいつものカップラーメン一食しか食べれなかった。
実家に父親はおらず、母は祖母の介護で面倒にはなれず従ってニートでも一人暮らしせざるを得ないので家賃浮かせるために食には金をかけられない。
年金とか保険とか税金は無職でも前年のサラリーマン給料に対応した分だけ持ってかれるのね。。
貯金が驚く程なくなって行く恐怖はマジではんぱなくやばい。
毎日誰かに追いかけられる夢を見るし、
この数日なぜか神経がおかしくなりそうだわ。
早く手に職つけて ないと。。
ちゃんとしたもん食べないといけんし。
てことで、数日ふさぎ込んでましたが、意識が戻ってきたので明日からまたアプリ作りに励みます。
と宣言しておきます。
続きます、と信じたい。
