日本国内ですが、本当に旅に出ます。
１週間ぐらいですが、その間、更新が止まると思います。
ちょっとリフレッシュと言うことで…
2015/06/26
繋がり判定(1)
HexaDropsで繋がりを判定するには、隣接する配列が同じ値かを確認していきます。
言うだけなら簡単ですが、実際には手間がかかります。
配列は２次元配列で画面のサイズと同一ですが、見た目上は半分ずれている状態です。
見た目がずれているだけで、配列上はやはり隣接しています。
下のような感じです。
例えば、(X:0,Y:0)の部分は表示位置としては同じような感じとなりますが、
(X:1,Y:0)の部分は表示上は半分ずれた状態となります。
隣接判定としては、(0,0)と(1,0)は表示上も隣接していることになりますので、
これが同じかどうかで判断できます。
上下に対してはズレがありませんので、こちらはそのまま(0:1)が同じ色なのかで判定できます。
今度は(1,0)の場合で考えてみます。
上下はズレがないので問題ありません。
左右は…ズレていますので、隣接判定は (0,0)、(2,0)、(0,1)、(2,1)の４箇所となります。
(1,0)の部分で考えた場合には合計６箇所ですが、同じ色と判定された箇所があった場合には、
更にその部分から隣接判定を行う必要があります。
同じような隣接判定ですので、隣接判定から隣接判定を呼び出すと上手くいきそうです。
これは再帰呼び出しを行うとできそうだと判断できます。
続きは、次回に…
言うだけなら簡単ですが、実際には手間がかかります。
配列は２次元配列で画面のサイズと同一ですが、見た目上は半分ずれている状態です。
見た目がずれているだけで、配列上はやはり隣接しています。
下のような感じです。
(X:1,Y:0)の部分は表示上は半分ずれた状態となります。
隣接判定としては、(0,0)と(1,0)は表示上も隣接していることになりますので、
これが同じかどうかで判断できます。
上下に対してはズレがありませんので、こちらはそのまま(0:1)が同じ色なのかで判定できます。
今度は(1,0)の場合で考えてみます。
上下はズレがないので問題ありません。
左右は…ズレていますので、隣接判定は (0,0)、(2,0)、(0,1)、(2,1)の４箇所となります。
(1,0)の部分で考えた場合には合計６箇所ですが、同じ色と判定された箇所があった場合には、
更にその部分から隣接判定を行う必要があります。
同じような隣接判定ですので、隣接判定から隣接判定を呼び出すと上手くいきそうです。
これは再帰呼び出しを行うとできそうだと判断できます。
続きは、次回に…
Drops → HexaDrops
Dropsは四角形キャラクタで、縦・横・斜めに３つ以上並ぶと消えるコラムス型パズルゲームでした。
このキャラクタを六角形にしたものがHexaDropsになります。
六角形にした場合、横に３つ以上並ぶと消えるという場合には見難く直感的に並んだというのがわかりません。
ですので、HexaDropsでは、辺で３つ以上繋がった場合には消えるというルールに変更しました。
こうすると、繋がった判定はDropsのままでは使用できません。
繋がる先としては、上下と斜め方向になります。
Dropsと比較した場合には横方向がなくなりますので、一見すると楽になるように感じるかもしれません。
上記の画面では、一番下段の青３つが繋がっているように判定されるべきでしょう。
この時、３つが繋がると消えるでは、簡単に３つ繋げることができるので、
繋がったら消えるときの数も調整する必要があります。
これが、ゲームの難易度に直結します。
また、ゲーム画面では半分ずれて表示されています。
しかし配列で0.5というのはありません。
配列の数を倍にすると整数で扱うこともできますが、半分の配列が未使用状態になります。
考え方が古いので、こんな無駄は勿体無くて許せません。
偶数と奇数で表示位置をずらせば無駄にはなりませんが、今度は繋がる判定が面倒になるでしょう。
どうやって判定するのかは、次回に…
このキャラクタを六角形にしたものがHexaDropsになります。
六角形にした場合、横に３つ以上並ぶと消えるという場合には見難く直感的に並んだというのがわかりません。
ですので、HexaDropsでは、辺で３つ以上繋がった場合には消えるというルールに変更しました。
こうすると、繋がった判定はDropsのままでは使用できません。
繋がる先としては、上下と斜め方向になります。
Dropsと比較した場合には横方向がなくなりますので、一見すると楽になるように感じるかもしれません。
（画面は開発中のもので、Dropsの背景を使用しているのでずれて表示されています）
上記の画面では、一番下段の青３つが繋がっているように判定されるべきでしょう。
この時、３つが繋がると消えるでは、簡単に３つ繋げることができるので、
繋がったら消えるときの数も調整する必要があります。
これが、ゲームの難易度に直結します。
また、ゲーム画面では半分ずれて表示されています。
しかし配列で0.5というのはありません。
配列の数を倍にすると整数で扱うこともできますが、半分の配列が未使用状態になります。
考え方が古いので、こんな無駄は勿体無くて許せません。
偶数と奇数で表示位置をずらせば無駄にはなりませんが、今度は繋がる判定が面倒になるでしょう。
どうやって判定するのかは、次回に…
キャラクタの表示
Dropsのキャラクタは四角ですので、全角文字の四角（■）で終わらせることもできなくはありませんが、
グラデーションを付けたりするには、絵を作って表示させる必要があります。
絵を作るにはWindowsのペイントでもいいのですが、きれいなグラデーションを付けるのは結構苦労します。
GIMPを使うと簡単にグラデーションを付けた四角を作れますので、
これで作ってみましょう。
GIMPを起動して 46x46 サイズの画像を作成し、全範囲を選択して、ブレンドによりグラデーションの四角を作成します。（作ったものは、選択範囲の「角を丸める」により丸めています）
グラデーションを付けたりするには、絵を作って表示させる必要があります。
絵を作るにはWindowsのペイントでもいいのですが、きれいなグラデーションを付けるのは結構苦労します。
GIMPを使うと簡単にグラデーションを付けた四角を作れますので、
これで作ってみましょう。
GIMPを起動して 46x46 サイズの画像を作成し、全範囲を選択して、ブレンドによりグラデーションの四角を作成します。（作ったものは、選択範囲の「角を丸める」により丸めています）
この画像をエクスポートにより、PNGファイルで保存します。
保存場所は プロジェクトの中の、以下のフォルダにすると、後々作業が行いやすくなります。
\app\src\main\res\drawable
プログラムからこの画像を呼び出すために、以下の様な関数を作成しておきます。
public Bitmap read(Context context , String name)
{
int ID = context.getResources().getIdentifier(name , "drawable" , context.getPackageName());
return BitmapFactory.decodeResource(context.getResources(), ID);
}
int ID = context.getResources().getIdentifier(name , "drawable" , context.getPackageName());
return BitmapFactory.decodeResource(context.getResources(), ID);
}
これで、MainActivityから
private Bitmap char_bmp;
char_bmp = read(this , 画像ファイル名);
char_bmpに画像ファイルの内容が読み込まれます。
画像ファイル名で指定している部分は、拡張子を指定しません。
（例：画像ファイルがfile.pngの場合には、 "file" とだけ指定します）
これで、キャラクタの読み込みは終わりましたので、
表示するときには drawBitmap により表示できることとなります。
2015/06/23
miwについて
ランキングサーバ作成で使用した miw というファイラーですが、
結構全角文字を使用している部分が多くて、途中であっさりと挫折してしまいました。
（ソースを見るのが久々で、ソースを追えなくなっているのも大きいですが…）
Ｃ言語って、あんなに面倒だったっけ？
ビット演算、シフト演算、三項式を使いまくる使いまくる。
でも、defineはＣの方がいいなぁとか思ったり…
こんなのとか…
#define StrCpy(__TO , __FROM) \
{\
char *__CP1 , *__CP2;\
__CP1 = (char *)__TO;\
__CP2 = (char *)__FROM;\
while ((*__CP1++ = *__CP2++) != '\0') ;\
}
こんなのとか…
#ifdef Debug
#define DebugPrint fprintf
#else
#define DebugPrint
#endif
結構全角文字を使用している部分が多くて、途中であっさりと挫折してしまいました。
（ソースを見るのが久々で、ソースを追えなくなっているのも大きいですが…）
Ｃ言語って、あんなに面倒だったっけ？
ビット演算、シフト演算、三項式を使いまくる使いまくる。
でも、defineはＣの方がいいなぁとか思ったり…
こんなのとか…
#define StrCpy(__TO , __FROM) \
{\
char *__CP1 , *__CP2;\
__CP1 = (char *)__TO;\
__CP2 = (char *)__FROM;\
while ((*__CP1++ = *__CP2++) != '\0') ;\
}
こんなのとか…
#ifdef Debug
#define DebugPrint fprintf
#else
#define DebugPrint
#endif
2015/06/22
onTouchEvent
onTouchEventの冒頭部分はこんな感じになっています。
@Override public boolean onTouchEvent(MotionEvent e)
{
for (int cnt = 0 ; cnt < e.getPointerCount() ; cnt++)
{
int x = (int) (e.getX(cnt) * gl.SCREEN_X / getWidth());
int y = (int) (e.getY(cnt) * gl.SCREEN_Y / getHeight());
e.getPointerCount では、タッチされた件数を取得します。
２箇所タッチされたら２となります。
cntがイベントのインデックスとなっており、インデックスは0からです。
うまい具合に、forループの条件にタッチ件数とインデックスを使用できます。
e.getX、e.getYにより画面上でタッチされた位置を取得できますが、
ここでは実画面サイズでの位置が取得できます。
setFixedSize された位置ではないので、拡大・縮小分を計算する必要があります。
（最初はこれが解からず、正しく判定できないでいました）
@Override public boolean onTouchEvent(MotionEvent e)
{
for (int cnt = 0 ; cnt < e.getPointerCount() ; cnt++)
{
int x = (int) (e.getX(cnt) * gl.SCREEN_X / getWidth());
int y = (int) (e.getY(cnt) * gl.SCREEN_Y / getHeight());
e.getPointerCount では、タッチされた件数を取得します。
２箇所タッチされたら２となります。
cntがイベントのインデックスとなっており、インデックスは0からです。
うまい具合に、forループの条件にタッチ件数とインデックスを使用できます。
e.getX、e.getYにより画面上でタッチされた位置を取得できますが、
ここでは実画面サイズでの位置が取得できます。
setFixedSize された位置ではないので、拡大・縮小分を計算する必要があります。
（最初はこれが解からず、正しく判定できないでいました）
画面の大きさ
端末の大きさはいろいろあります。
仮想端末として使用したNexus５と実機端末であるF-01Fは 1080×1920 ですが、
他のサイズの端末もいろいろあります。
それぞれごとに合わせることは不可能ですので setFixedSize により画面に対する表示サイズを固定します。
setFixedSize(400,800)とすれば、横400×縦800での表示となります。
端末の実サイズに関係なく400×800 で表示されます。
一応、setAntialias をしておくと、ジャギーが防止できるはずなので setAntialias も設定しておきます。
（アンチエイリアスが不要な場合には、setAntialias(false) でアンチエイリアスを解除します）
アンチエイリアスが不要な状態ってあまり思いつかないのですが…
方眼を画面上に表示する時なんかですかねぇ。
仮想端末として使用したNexus５と実機端末であるF-01Fは 1080×1920 ですが、
他のサイズの端末もいろいろあります。
それぞれごとに合わせることは不可能ですので setFixedSize により画面に対する表示サイズを固定します。
setFixedSize(400,800)とすれば、横400×縦800での表示となります。
端末の実サイズに関係なく400×800 で表示されます。
一応、setAntialias をしておくと、ジャギーが防止できるはずなので setAntialias も設定しておきます。
（アンチエイリアスが不要な場合には、setAntialias(false) でアンチエイリアスを解除します）
アンチエイリアスが不要な状態ってあまり思いつかないのですが…
方眼を画面上に表示する時なんかですかねぇ。
2015/06/21
ランキングサーバ
Androidのプログラムを作るのなら、通信もやりたいなぁということでDropsにインターネットランキング機能が付いています。
ネットに繋がっているサーバは既に家にあるので、それを流用することでサーバ部分は大幅に簡略化できました。
ただ、そのままはもちろん使用できないので、Dropsランキング用にプログラムを修正する必要があります。
サーバのプログラムは、直接サーバで修正したかったので、どうしたものかと思案していましたが…
昔作ったプログラムに miw というものがありました。
miw とはマルチウィンドウのファイラーで大本はSVR4で作られたものでした。
（SVR4なんて、知っている人がどれだけいることやら）
昔、X68000用に mint というファイラーがありました。
X68000でファイル操作をするなら、mint 以外にありえないと思うぐらいに、とても使いやすいファイラーでした。
仕事先ではSVR4を使っていて、ストレスが溜まりまくる状態に…
このままでは、とてもじゃないけどやっていられなくなり、
ファイル操作だけでももっと簡単に行えるように作成しました。
mint にはインタプリタ言語が搭載されており、それが使いやすくしている要因だったのですが、
とてもそこまで創りだす余裕はありません。
幸いにしてSVR4はUNIXベースです。シェルスクリプトは非常に強力です。
自分でインタプリタが作れないなら、シェルスクリプトで実行できるようにしてしまえばいいだろうと考えました。
お陰でかなり操作しやすくなっていたのですが、時代がWindowsへ移行するに従い、
仕事もWindows関連のものが多くなり、miw の存在も忘却の彼方へと…
現在のサーバはCentOSですので、簡単にmiwを動かすことができました。
が、文字コードが変わっています。
SVR4はEUCでしたが、LinuxはUTF-8です。
全角文字のハンドリングが異なるので、画面が崩れます。
今後のためにも、半角文字だけを使用するように修正して、きちんと動作するようにしておく必要がありそうです。
※miw は今のところ公開する予定はありません。
ネットに繋がっているサーバは既に家にあるので、それを流用することでサーバ部分は大幅に簡略化できました。
ただ、そのままはもちろん使用できないので、Dropsランキング用にプログラムを修正する必要があります。
サーバのプログラムは、直接サーバで修正したかったので、どうしたものかと思案していましたが…
昔作ったプログラムに miw というものがありました。
miw とはマルチウィンドウのファイラーで大本はSVR4で作られたものでした。
（SVR4なんて、知っている人がどれだけいることやら）
miwの実行画面
昔、X68000用に mint というファイラーがありました。
X68000でファイル操作をするなら、mint 以外にありえないと思うぐらいに、とても使いやすいファイラーでした。
仕事先ではSVR4を使っていて、ストレスが溜まりまくる状態に…
このままでは、とてもじゃないけどやっていられなくなり、
ファイル操作だけでももっと簡単に行えるように作成しました。
mint にはインタプリタ言語が搭載されており、それが使いやすくしている要因だったのですが、
とてもそこまで創りだす余裕はありません。
幸いにしてSVR4はUNIXベースです。シェルスクリプトは非常に強力です。
自分でインタプリタが作れないなら、シェルスクリプトで実行できるようにしてしまえばいいだろうと考えました。
お陰でかなり操作しやすくなっていたのですが、時代がWindowsへ移行するに従い、
仕事もWindows関連のものが多くなり、miw の存在も忘却の彼方へと…
現在のサーバはCentOSですので、簡単にmiwを動かすことができました。
が、文字コードが変わっています。
SVR4はEUCでしたが、LinuxはUTF-8です。
全角文字のハンドリングが異なるので、画面が崩れます。
こんな風に…
今後のためにも、半角文字だけを使用するように修正して、きちんと動作するようにしておく必要がありそうです。
※miw は今のところ公開する予定はありません。
Dropsについて
またまた、Dropsの話です。
（まぁ、まだDropsしか出来ていませんからねぇ）
Dropsでは、落下物が下に落ちた状態でも少しの間動かすことができるようになっています。
アーケードゲームのコラムスでも同じように、少しの間は動かすことができました。
この少しの間動かすことができるのがものすごい重要で、これが無いとゲーム性が崩壊してしまうのではないかと思います。
落ちた後に回転させて色を揃えることが、後々のレベルでは非常に重要になっています。
なので、これだけは必ずできるようにする必要がありました。
結構、苦労したんですけどね。
アーケード版といえば、魔法石というものがありました。
魔法石の下の色と同じ色のものが消える…
これは同じように作るのはすぐにできます。
魔法石の場合には別判定にするだけですので、そんなに難しくありません。
でも、作りませんでした。
個人的には魔法石の存在はゲーム性を損なう可能性が高いと思われたからです。
この取捨選択は正しかったのだと信じていたいものです。
（まぁ、まだDropsしか出来ていませんからねぇ）
Dropsでは、落下物が下に落ちた状態でも少しの間動かすことができるようになっています。
アーケードゲームのコラムスでも同じように、少しの間は動かすことができました。
この少しの間動かすことができるのがものすごい重要で、これが無いとゲーム性が崩壊してしまうのではないかと思います。
落ちた後に回転させて色を揃えることが、後々のレベルでは非常に重要になっています。
なので、これだけは必ずできるようにする必要がありました。
結構、苦労したんですけどね。
アーケード版といえば、魔法石というものがありました。
魔法石の下の色と同じ色のものが消える…
これは同じように作るのはすぐにできます。
魔法石の場合には別判定にするだけですので、そんなに難しくありません。
でも、作りませんでした。
個人的には魔法石の存在はゲーム性を損なう可能性が高いと思われたからです。
この取捨選択は正しかったのだと信じていたいものです。
Dropsについて（判定編）
Dropsは縦・横・斜めに３つ以上並んだ場合には同じ色が消えることになります。
３つ並んだのかを判定するには、色のデータを２次元配列上に保存しておきます。
あとは、配列に対して８方向に同じ色があるかをチェックします。
(1) 上方向にチェックして連結数を数える
(2) 下方向にチェックして連結数を数える
(3) 上下方向の連結数が３以上か確認する
(4) 左方向にチェックして連結数を数える
(5) 右方向にチェックして連結数を数える
(6) 左右方向の連結数が３以上か確認する
(7) 左上右下方向、左下右上方向に同じチェックを行う
落下物に対してチェックを行うと、３回のチェックで終了することができチェック処理が速くなります。
しかし、チェックの結果落ちてきたものがある場合には、落ちてきたものもチェック対象としなければいけません。
その時には３回のチェックでは終わりません。
今回は全画面で色データがあるものをすべて８方向にチェックを行っています。
それほど大きな配列ではないのであっという間に判定が終わっていますが、本当は高速化する必要があると思います。
高速化の方法としてもう一つ配列を持ち、落ちた部分を設定しておくと落ちた部分のみを判定させる事ができますが、これは速度の問題が発生した時でいいかなぁと思います。
３つ並んだのかを判定するには、色のデータを２次元配列上に保存しておきます。
あとは、配列に対して８方向に同じ色があるかをチェックします。
(1) 上方向にチェックして連結数を数える
(2) 下方向にチェックして連結数を数える
(3) 上下方向の連結数が３以上か確認する
(4) 左方向にチェックして連結数を数える
(5) 右方向にチェックして連結数を数える
(6) 左右方向の連結数が３以上か確認する
(7) 左上右下方向、左下右上方向に同じチェックを行う
落下物に対してチェックを行うと、３回のチェックで終了することができチェック処理が速くなります。
しかし、チェックの結果落ちてきたものがある場合には、落ちてきたものもチェック対象としなければいけません。
その時には３回のチェックでは終わりません。
今回は全画面で色データがあるものをすべて８方向にチェックを行っています。
それほど大きな配列ではないのであっという間に判定が終わっていますが、本当は高速化する必要があると思います。
高速化の方法としてもう一つ配列を持ち、落ちた部分を設定しておくと落ちた部分のみを判定させる事ができますが、これは速度の問題が発生した時でいいかなぁと思います。
Dropsについて（インターフェース編）
今回作成したゲーム（Drops）ですが、まんまコラムスです。
ゲーム自体は１９９０年にセガより発売されたものですので、もう２５年前になります。
（月日が経つのは早いもので…）
このゲームを作るのは初めてではなく、３回目となります。
１回目は専門学校の卒業研究として。
２回目は会社で昼休みの暇つぶし用として。
３回目が今回での作成となります。
ＯＳは１回目がＰＣ－９８０１、２回目がＯＳ／２、そして今回がAndroidとなります。
ＰＣ系ですとキーボードが必ずありますので、インターフェースに困ることはあまりありません。
しかし、今回はAndroidです。キーボードがあるものもありますが、基本的にキーボードはありません。
ゲーム画面にソフトウェアキーボードを出すわけには行きません。
タッチパネルで、どうやって入力を受け付けるかが問題となります。
フィールド上で現在の落下物に対して左がタッチされたら左へ、右がタッチされたら右へ移動させると
直感的で動かせるかもしれません。
さらにタッチされた部分まで移動させると更に直感的になるでしょう。
じゃあ回転はどうしようとなると、落下物がタッチされたら回転でいいと思います。
しかし、ここは敢えてゲームに対する制限として左右キーを押すこととしています。
本当は、左右キーを押したままにした時にはどんどん移動できるようにしたかったのですが、押しっぱなし状態をうまく取ることができませんでした。この部分は現在の課題ですね。
ゲーム自体は１９９０年にセガより発売されたものですので、もう２５年前になります。
（月日が経つのは早いもので…）
このゲームを作るのは初めてではなく、３回目となります。
１回目は専門学校の卒業研究として。
２回目は会社で昼休みの暇つぶし用として。
３回目が今回での作成となります。
ＯＳは１回目がＰＣ－９８０１、２回目がＯＳ／２、そして今回がAndroidとなります。
ＰＣ系ですとキーボードが必ずありますので、インターフェースに困ることはあまりありません。
しかし、今回はAndroidです。キーボードがあるものもありますが、基本的にキーボードはありません。
ゲーム画面にソフトウェアキーボードを出すわけには行きません。
タッチパネルで、どうやって入力を受け付けるかが問題となります。
フィールド上で現在の落下物に対して左がタッチされたら左へ、右がタッチされたら右へ移動させると
直感的で動かせるかもしれません。
さらにタッチされた部分まで移動させると更に直感的になるでしょう。
じゃあ回転はどうしようとなると、落下物がタッチされたら回転でいいと思います。
しかし、ここは敢えてゲームに対する制限として左右キーを押すこととしています。
本当は、左右キーを押したままにした時にはどんどん移動できるようにしたかったのですが、押しっぱなし状態をうまく取ることができませんでした。この部分は現在の課題ですね。
AdMobについて(2)
AdMobの続きです。
今回のアプリでは、SurfaceView を使用していて、タイトル画面とAdMobの重ね合わせが必要になります。
タイトル画面は画像（pngファイル）で作成されていて、ボタンなどもすべて画像で作成済みの状態です。
（イメージボタンを使えば良かったのかもしれませんが、何故かうまく行かなかったのでOnTouchイベントで処理しています）
タイトル画面との重ね合わせはタイトル画面の view と AdMob の view を FrameLayout で実現できます。
※下のソースコードは、実際のソースコードから抜粋しています。
private FrameLayout flayout;
flayout = new FrameLayout(this); ← FlameLayoutの作成
gm = new GameMain(this , hd); ← ゲーム本体のビュー作成
flayout.addView(gm, new FrameLayout.LayoutParams( ← レイアウトへ追加
FrameLayout.LayoutParams.MATCH_PARENT,
FrameLayout.LayoutParams.MATCH_PARENT));
adview = new AdView(this); ← AdMobのビュー作成
flayout.addView(adview, params); ← レイアウトへ追加
setContentView(flayout); ← 表示の設定
表示するときには、flayoutに対してaddViewを行い、非表示にするときにはflayoutに対してremoveViewを行っています。
冷静に考えればそんなに難しくもないとは思うのですが、なにせ初めてのアプリ作成ということで、
ビューの使い方自体がはっきりわかっていなかったため苦労しました。
重ね合わせで行えば、他のゲームを作るときにも使い回すことができると思うので、
これはこれで良かったのかなぁと思います。
今回のアプリでは、SurfaceView を使用していて、タイトル画面とAdMobの重ね合わせが必要になります。
タイトル画面は画像（pngファイル）で作成されていて、ボタンなどもすべて画像で作成済みの状態です。
（イメージボタンを使えば良かったのかもしれませんが、何故かうまく行かなかったのでOnTouchイベントで処理しています）
タイトル画面との重ね合わせはタイトル画面の view と AdMob の view を FrameLayout で実現できます。
※下のソースコードは、実際のソースコードから抜粋しています。
private FrameLayout flayout;
flayout = new FrameLayout(this); ← FlameLayoutの作成
gm = new GameMain(this , hd); ← ゲーム本体のビュー作成
flayout.addView(gm, new FrameLayout.LayoutParams( ← レイアウトへ追加
FrameLayout.LayoutParams.MATCH_PARENT,
FrameLayout.LayoutParams.MATCH_PARENT));
adview = new AdView(this); ← AdMobのビュー作成
flayout.addView(adview, params); ← レイアウトへ追加
setContentView(flayout); ← 表示の設定
表示するときには、flayoutに対してaddViewを行い、非表示にするときにはflayoutに対してremoveViewを行っています。
冷静に考えればそんなに難しくもないとは思うのですが、なにせ初めてのアプリ作成ということで、
ビューの使い方自体がはっきりわかっていなかったため苦労しました。
重ね合わせで行えば、他のゲームを作るときにも使い回すことができると思うので、
これはこれで良かったのかなぁと思います。
AdMobについて(1)
アプリの下とか上とかに表示されたりするバナー広告。
Android（というかGoogle）のサービスでAdMobを使うと簡単に表示できて、うまくいけばお金にもなるらしいのですが
どこが簡単になんだよぉ
結構苦労させられたぞ！
まぁ、表示はすぐに出来た。
表示させるだけなら、他のサイトに書いてある内容で表示できるんだろうけど、
ゲームの場合には、タイトル画面などゲームに直接関係ない画面では表示したい。けれどゲーム中に表示されたら邪魔で仕方がない。
表示したり消したりさせることがこんなに難しいとは思ってもいなかった。
普通に表示させる方法はこちらを参照すれば作成できるのですが…
どうやったのかは、次回。
Android（というかGoogle）のサービスでAdMobを使うと簡単に表示できて、うまくいけばお金にもなるらしいのですが
どこが簡単になんだよぉ
結構苦労させられたぞ！
まぁ、表示はすぐに出来た。
表示させるだけなら、他のサイトに書いてある内容で表示できるんだろうけど、
ゲームの場合には、タイトル画面などゲームに直接関係ない画面では表示したい。けれどゲーム中に表示されたら邪魔で仕方がない。
メニュー画面（バナー表示されて良い）
ゲーム画面（バナー表示なんていらない）
表示したり消したりさせることがこんなに難しいとは思ってもいなかった。
普通に表示させる方法はこちらを参照すれば作成できるのですが…
どうやったのかは、次回。
開発 ことはじめ
Android用アプリケーションの開発方法などの覚書として書いていこうかなと思いましたが、
AndroidStudioのセットアップ方法なんかはキレイさっぱり忘れちゃった。まぁ、他のサイトなどにもセットアップ方法は書いてあるだろうからいいかなぁ。
今のSDKのインストール状況はこんな感じ。
気がついた時にアップデートしているから、ほぼ最新版を使用している感じ。
Google USB DriverとIntel x86 Emulator Accelerator(HAXM install) はインストールしておかないと
実機でのデバッグができないとのこと。
SDKでインストールしただけではHAXMは使用できないらしく、コマンドを実行する必要があるらしく
SDK Path（Android SDK Managerの上の方に表示されています）の中のファイルを実行します。
ディレクトリ：\extras\intel\Hardware_Accelerated_Execution_Manager
実行ファイル：intelhaxm-android.exe
実機でデバッグするときには、PCの方に実機のUSBドライバもインストールする必要があります。
（私は Arrows NX F-01Fを所有しており、富士通のサイトから該当のドライバをインストールしました）
この環境を作るだけでも２日位かかったように記憶しています。
（特に実機デバッグの時にUSBドライバが必要というのがわからなくて悩んでいました）
とりあえず、第一弾はここまで。
登録:
投稿 (Atom)