ＨＡＸＭはａｍｄでは動きません

なんか体調がすぐれないというか、どうも書きかけて全て消去するという日が続いていました。

それだけで終わらしてしまっては仕方がありませんので、何を書こうかなと…

家には開発に使ったり、ベッドサイドに置いているノートＰＣ
（これを書いているのも、ノートＰＣです）
他に、ゲームで使ったり、ビデオ編集に使用しているメインＰＣ
（メーカ製ではありませんので、自作ＰＣというやつですね）
ＣｅｎｔＯＳを無理やり入れてサーバとして動かしているＭａｃＭｉｎｉがあります。

メインＰＣに開発環境を入れようとしたら、ＨＡＸＭが動かなくて
「なんでかなぁ？」と思っていたら、ＣＰＵがａｍｄでしたというオチだったりしました。
（ＨＡＸＭはｉｎｔｅｌＣＰＵでしか動きません）

自作ＰＣをｉｎｔｅｌＣＰＵで作りなおさないといけないのかなぁ
とか考えたりしています。

プログラム開発の時間帯、環境

アプリの開発をするのにいい時間なんて、本当に人それぞれですね。
これを言っちゃうとそれが全てなんですが…

私の場合で書いてみます。

会社勤めをしていた時は、大体、１日２回ぐらい「調子がいい時」がありました。

出勤後１時間～２時間の間の１時間。
ご飯を食べ終わって、１５時～１６時くらいの１時間。


出勤した直後は地下鉄や電車の中で揺られ続け、駅から会社まで歩いて、それこそ「何もしたくない」状態でした。
１時間もあると落ち着いてきて、「さて、そろそろ真面目にやりますか」ってな感じでした。
午前中に会議をしなければいけない時には、本当は９：００～１０：００くらいが良かったです。
会議で頭をつかうことなんて、ほとんどありませんでしたから。
１０：００以降になると、「さっさと会議終わって、仕事やらせろよ」な感じです。
（もちろん、言葉にはしませんが）

午後はご飯を食べ終わって、１３：００～１４：００ぐらいまでは、もう眠たくて仕方がありません。
１４：００～１５：００くらいで眠気が覚めてきます。
覚めてくるだけで、まだ頭は働いていません。
１５：００位からが本番です。
「ここらへんから仕事しないと、今日、帰れなくなるしなぁ…」とか考えている状態です。

どちらも、１時間ぐらいしか継続しません。
それ以降は惰性で仕事をしていますね。

残業時間中は、途中のインターセプトが入らなければ、１時間おきくらいに調子が良くなりました。
多分、余計な邪魔が入らないからなんでしょうね。

上の２回の調子がいい時にインターセプトが入ると、残業確定です。
残業したほうが、調子がいいのだから仕方がないです。

Androidアプリを開発しているときは、いつでも残業状態と一緒ですから、開発が面白いように進みます。
開発中は他のことで邪魔しない環境って大事なんですよね。

そういえば、以前にいた会社で、ヘッドホンで音楽を聞きながら開発をしていた時があり、その時も、面白いように開発が進みました。

開発中は邪魔されないというのが大切なのかもしれません。

乱数生成

乱数の生成については、Math.random()を使う方法と、Randomクラスを使う方法があります。

Drops、HexaDropsでは特に悩まずMath.random()を使用していますが、多分どちらでも問題はありません。

Math.random()を使用する場合には、これで返される値が 0～1までのdouble値が返されるということです。
0.002154とか0.9999とかですね。

使用したい値は整数でしたので、100倍して整数部分を使用しています。
また、得たい値は０～６までの値でしたので、上記の値の余りを取得します。
以下は乱数取得のサンプルです。

    public int rand(int num)
    {
        return ((int)(Math.random() * 100) % num);
    }

呼び出し側では rand(7)とすれば、０～６までのランダム値を取得できます。

HexaDropsリリース

HexaDropsをリリースします。

繋がり判定は解説した内容を元に作成されています。

公開準備中ですので、公開されたらリンクも設定します。


(2015/07/12 追記）リンク追加しました

繋がり判定(2)

突然旅に出て、ようやく今日（もう日付が変わっているので昨日ですが…）帰ってきました。

どこまで書いたのかを覚えていなかったので、前々回の投稿を参照して…
つながり判定の部分でした。

再帰処理での判定方法ですが、そんなに難しくありません。
今現在の時点が呼び出し元と同じ色かを判定し、違う場合には処理（現在の呼び出し処理）を終了します。
すると、呼び出し元の処理へ戻るわけですね。

同じ色だった場合には、上下と斜めに隣接する部分を判定するように呼び出す感じです。

まぁ、こんな感じ…

 1:    private void check(int x , int y , int color)
 2:    {
 3:        if ((y >= 0) && (y < GAME_SCREEN_Y) && (x >= 0) && (x < GAME_SCREEN_X) &&
 4:            (screen_data[y][x] == color))
 5:        {
 6:            check(x , y + 1 , color);   // 下方向のチェック
 7:            check(x , y - 1 , color);   // 上方向のチェック
 8:
 9:            check(x + 1 , y , color);   // 右方向のチェック
10:            check(x - 1 , y , color);   // 左方向のチェック
11:            if (x % 2 == 1)
12:            {
13:                check(x - 1 , y + 1 , color);   // 左下のチェック
14:                check(x + 1 , y + 1 , color);   // 右下のチェック
15:            }
16:            else
17:            {
18:                check(x - 1 , y - 1 , color);   // 左上のチェック
19:                check(x + 1 , y - 1 , color);   // 右上のチェック
20:            }
21:        }
22:    }

前回の図と説明を参照してください。
(0,0)の場合にチェックする部分は、(0,1)→下方向、(1,0)→右方向です。

範囲のチェックは呼び出された側で行うようにしておくと、呼び出す側は座標を渡すだけで良くなります。
範囲チェックは３行目で行っています。
同じ色かの判定は４行目で行っており、異なる色の場合には再帰処理も終了しています。

下方向への呼び出しは６行目で実行されており、ここからまた１行目が呼び出されますが、１つ下の石に対しての判定となっています。
上方向への呼び出しは下方向へのチェックが終了後に呼び出されますが、この時は(0,-1)に対しての判定となりますが、呼び出された先の範囲チェックにより、すぐに呼び出し元へ帰ることになります。

１１行目からの部分では、 (0,1)と(1,1)の横方向へのチェックを考えてみるとわかります。

(0,1)の場合にチェックするのは、 (-1,0)、(-1,1)、(1,0)、(1,1)が対象です。
これは、相対位置で考えると(-1,-1)、(-1,0)、(1,-1)、(1,0)となります。
(-1,0)、(1,0)の座標は９行目および１０行目でチェックしていますので、(-1,-1)、(1,-1)のチェックを行うために、１８行目および１９行目を処理します。

今度は(1,1)ですね…（う～ん、長いなぁ）
(1,1)の場合にチェックするのは、 (0,1)、(0,2)、(2,1)、(2,2)が対象です。
これは、相対位置で考えると(-1,0)、(-1,1)、(1,0)、(1,1)となります。
(-1,0)、(1,0)の座標は９行目および１０行目でチェックしていますので、(-1,1)、(1,1)のチェックを行うために、１３行目および１４行目を処理します。

１１行目は、Ｘ座標の位置が偶数か奇数かを判定しています。
偶数の場合には１８行目、１９行目を処理し、奇数の場合には１３行目、１４行目を処理しています。

このようにして、繋がりの判定を行っています。