調整

SHOT04のライト版を作成する作業を進めておきました。
あと、エンディングやらを作ったりして、とりあえず形だけは仕上がった感じです。
残るは最終調整のみ。

ちなみに、チュートリアルというかHow to playは、Demonstrationを見れば分かる程度の内容しかなかったので削る方向で。細かいルールの説明は、日本語と英語でWeb＋マーケットの説明文でアップすることにしました。（そろそろ、情報処理の勉強をしないとマズイ感じだから、８月中にはマスターアップしたいので、作り込みは避けたい心境）

なお、ライト版は製品版リリースとほぼ同時にバージョンアップします。
あと、Windowsでもライト版をビルドするようにしておきました。
Android版の製品版をリリース後にWindows版のライト版もリリースする予定。
Windows版の製品版は主に販路の調整中。（DLマーケットあたりが妥当な線です）
で、結局今日はそういった作業に追われてしまい、肝心なゲーム本編の調整が進まず・・・
調整は明日から会社で休み時間などにスマホを使ってやる予定。とりあえず、APKをSDカードで持っていき、Androidを持っていてゲーム好きな感じの人にテスタになってもらいます。

調整目標は、
・Beginner = 私がノーミスでオールできる程度
・Soldier = 私がほどよくオールできる程度
・Ninja = 私がギリギリ、オールできる程度
まだまだ遠い。。。

SAI

エンディングのスタッフロール（というほどのスタッフはいないけど）の字を書こうと重い、新開発環境にBambooを設置して、SAIのライセンスファイルを再発行する作業をしていて気づいたのですが、SAIが久々にバージョンアップされているようです。
http://www.systemax.jp/ja/sai/devdept.html

とりあえず、すごいペースでベータアップ中のようなので、旧バージョン（Ver.1）を入れておきました。
新バージョン（Ver.2）でも、ライセンスは引継ぎ可能（再購入は不要）なようです。

状況を見ると、ソースリファクターしている？
微調整レベルのエンハンスならリファクターするのは効率が悪いですが、SAIの場合、既にVer.1で微調整レベルのエンハンスはし尽くしていると思っているので、SAIのエンハンスをするなら、リファクタしか無いってことですかね。

カンストはしない・・・はず

とりあえず、SHOT04のラスボスが完成。
第三形態を作るかどうかは、調整の状況を見て決めようと思います。
たぶん、調整すると難易度は落ちる方向になる筈なので、「これでは物足りない！」という難易度だった場合に第三形態を入れます。「もう十分です＞＜」という場合、入れない方向で。（現時点で結構な鬼畜難度なので、後者に倒れる可能性が高そう）

で、この状況でとりあえず「ノーミスでオールした場合、どのぐらいのスコアが入るのか？」という素朴な疑問があったので、無敵フラグを立てた状態で最高難度をノーミスでオールしてみました。

１億５～６千万ちょいぐらいのようです。
理論値（もっとも稼げるパターン）でクリアしたとしても、２億ぐらいですかね？
ちなみにカンストは999,999,990点。
なので、どんな変態シューターがプレイしたとしても、カンストすることは無いと思います。
現時点の難易度で普通にプレイした場合の私のベストスコアは2千万弱ぐらい。
全国一レベルの方の場合でも5千万前後。

さて、これから鬼調整をするか・・・
調整というのは、ひたすらプレイして難度を弄る作業。
遊び要素が大きいので、あまり苦にはなりませんが、時間が掛かる作業です。
基本的に、Ninja以外はどんどん緩くする方向で調整する方向。

ちなみに、SHOT03の時の調整に要した時間は100時間前後。
SHOT04は、現時点ですでに100時間ぐらい調整しています。。。
難易度を３種類にしたことに加えて、機種を３機種にしたことが色々と痛い。。。
「機種は２種類で良かったんじゃない？」と、今更思っていたりします。

生産状況（18-Aug）

SHOT04の現時点（５面ボスの第２形態を３～５割ぐらい作成完了したところ）の生産ステップ数を取得。

実行行数がほぼ１６ｋｓというところ。（8/4の前回の生産状況から＋３ｋｓ増加）
まだ、エンディングとか、チュートリアルとか、調整とかでワサワサと増えそうな感じなので、完成時点で２０ｋｓぐらいになるかも。

以下、蛇足

ちなみに、仕事でプログラムを作る場合、ステップ数を見積もり値にしている所が意外と多くあるようですが、ステップ数の見積もり値なんて全然アテにならないのにやる意味あるんですかね？私が仮に、想定規模を計上する必要に迫られた場合、とりあえずFP法（私の場合、画面単位ではなく機能単位で算出する方が精度が高い）なりで何かしらの根拠のある数字を出しますが、だいたい以下のような要因でその数字はフェーズとともに上下します。
①「この機能とこの機能は共通化できる」（機能レベルの共通化見落とし）
②「この機能はｘ機能とｙ機能に分割しなきゃダメだ」（機能レベルの分割漏れ）
③「この機能が必要だった」（機能レベルの実装漏れ）
④「この機能は要らなかった」（機能レベルの冗長実装）
そして、より下流フェーズに進むと①～④の「機能」が「関数」とかの細かい単位に変わります。まぁ、下流フェーズでも機能レベルの設計ミス（＝すり抜け不良）がある程度残存するものですが。一般的に、見積もり値の上下幅は、上流フェーズの設計ミスほど広く、下流フェーズの設計ミスであれば狭くなります。自社開発なら、それでも大して問題は無いと思います。問題は、他社に請負契約で発注するケース。請負契約の場合、発注時点で発注に掛かる費用（予算）を決めますが、プログラムが完成していない時点（コーディング前）の場合、幾ら掛かるのか客観的に分かり難いため、適正価格が発注時点で分かりません。だから、かなりアヤフヤな値であることを承知で想定規模（想定される画面数やプログラムのステップ数）なんかを指標にしている企業がたくさん居る訳です。個人的には、請負契約が妥当なプロセスは、テスト工程（※定性的な項目が多い統合テストなどを除く）ぐらいだと思います。請負契約で上手くやる（見積もりと実績の乖離を減らす）のに有用な開発手法は、経験則ではスパイラルモデルの開発ぐらいです。要は、見積もりと実績の乖離を減らすには、すり抜け不良を少なくすれば良い訳で、それをやるのに一番良い手段は、開発サイクルを小さく分割することだけだと思っています。学問レベルでは色々な手法が考えられているようですが、スパイラル以外の実用レベルで使い物になる手法は未だ見たことがありません。ただし、スパイラルだとそれを第三者が管理するのは無理に等しいから、開発作業とマネジメント作業を両立できるエンジニア以外できないこと（＝要員確保が困難なこと）がネック。そして、そういうエンジニアは得てして単価が高いから、予算オーバーになり易いという落とし穴があります。そもそも、スパイラルで妥当な程度の規模にサイクルを分断すると、発注のオーバヘッド（恐らく裁断したサイクル単位で発注する→妥当な規模に裁断すると契約がポコポコ増える→大変になる）でパフォーマンスが落ちるような気もするので、結局のところ「コーディングまで委任契約がベスト」だと思っています。

要は、「コーディング＝定量的な作業」という風潮をなんとかする必要があるんじゃないかと。

開発状況（17-Aug）

ネット環境がスマホしか無いところで１週間弱過ごし、今帰ってきました。
ポータブルな開発環境を整えたので、そういう所の方が捗るのかもしれません。
温泉宿とかで１週間ぐらい篭ったりするのが理想。
シーズン中は嫌ですが。（混むので）

「せっかく温泉宿に行ってゲーム作りなんて・・・」と、思うかもしれませんが、結構オススメです。
ゲーム作りでなくても、例えばその他の創作活動（漫画とか小説など）や試験勉強などにも良いです。
「ｘｘｘをする為にｙｙｙに居る」という意識が働くことで集中力が増します。
更に、貧乏性の私の場合、「お金を払ってまで」という意識が更に集中力を増幅させます。

なので、コストは高ければ高いほど良いから、温泉宿がベスト。
ただし、温泉宿だとちょっと足が出ない場合、ビジネスホテルとかでも良いかも。
または、（音が気にならないのであれば）漫画喫茶とか。
あと、国内出張ならグリーン車、海外出張ならビジネスクラスかファーストクラスというのもアリです。
（もちろん、普通料金からの差額は自腹で）

まぁ、今回私が行ってきたのは温泉宿でもなければビジネスホテルでもありませんが。
法要で田舎で宿泊してただけ。（漫画喫茶にはチョクチョク行って作業しましたが）
とりあえず、SHOT04の５面の道中が完成し、ラスボスを作成しているところ。
ラスボスは作画が終わっていて、あとはアルゴリズムを組むだけという感じです。
この土日でとりあえず完成させて、あとは８月中に調整を終わらせ、９月中にはリリースしたい...

４面完成

４面が完成。

割とゴチャゴチャしたステージになりました。
一定距離を保って箱を打つと、アイテムジャラジャラみたいな感じです。
難易度はほど良い感じ。

あとは今週中に５面完成すれば良いなぁ・・・。
そういえば、説明書とかってAndroidだと、Windowsみたいにドキュメント（Readme.txt）を付属する習慣が無いから、やっぱり、チュートリアル的なものを作らなければ駄目かな？と、今さら考え始めました。
しかし、言語フリーで作るのは結構大変そうかも。
基本、ゲーム画面中には、単語レベルの英語以外は入れたくないと思っています。
例えば、基本的な操作系であれば、
1. Touch -> Fire and Move
2. Not touch -> Charge
3. Fill & Touch -> Laser
ぐらいが、言語を用いる上限になるイメージ。

今、ふと、「リプレイの機能を使ってそれを流しながら上記の単語レベルの説明入れていけば良いんじゃないか？」というナイスな考えを思いつきました。ちょっと面倒くさそうですが、そういう部分には力を入れた方が良さそうな気がしないでもないです。

動く開発環境

今日購入したUltraBook（になるのか？）のAspireV3にAndroidビルド環境の構築が完了。
もちろん、Windowsの開発環境（Visual C++ Express 2010 ＆ DirectX-SDK）も構築済み。
これで、ノート環境ですべての開発ができるようになりました。

Androidのビルド環境の構築手順が、自宅マシンに構築したときと若干変わっていたので、構築手順をメモっておきます。なお、青字部分は、SonyのWalkman Zシリーズをデバッグ機として使う場合の設定です。

■SDKを使うための手順
①JDKを入手してインストール
②システム環境変数JAVA_HOMEにインストール先パスを指定
③システム環境変数PATHに%JAVA_HOME%\binを追記
④Android-SDKの入手してインストール（※C:\android\sdkにインストールした前提で説明）
⑤システム環境変数PATHにC:\android\sdk\platform-toolsを追記
⑥システム環境変数PATHにC:\android\sdk\toolsを追記
⑦SDK Managerを起動し、以下のパッケージをインストール
- Android SDK Tools
- Android SDK Platform-tools
- Android 2.3.3 (API level 10) の SDK-Platform
- Google USB driver
⑧Apache-antを入手（※C:\android\antにインストールした前提で説明）
⑨システム環境変数PATHにC:\android\ant\binを追記

■Zシリーズを使うための手順
⑩C:\android\sdk\extras\google\usb_driver\android_winusb.infをメモ帳で開く
[Google.NTx86]と[Google.NTamd64]に以下の行を追加。
%CompositeAdbInterface% = USB_Install, USB\VID_054C&PID_0691&MI_01
⑪以下のコマンドを実行
echo 054c > "%SystemDrive%%HomePath%\.android\adb_usb.ini"
⑫Zシリーズをパソコンに接続
⑬デバイスマネージャを開き、警告マークが付いているZシリーズのアイコン部分を右クリックして、デバイスドライバを選択（探索パスには、C:\android\sdk\extras\google\usb_driverを指定）

■NDKを使うための手順
⑭cygwinを入手してインストール
※自宅環境のディスクから持ってきたディレクトリを使ったので、どのパッケージを入れたかは忘れました
⑮システム環境変数HOST_AWKに/usr/bin/gawkを設定
⑯NDKを入手してインストール（※C:\android\ndkにインストールした前提で説明）
⑰システム環境変数PATHにC:\android\ndkを追記
⑱システム環境変数NDK_ROOTにC:\android\ndkを設定

以上です。
ちなみにEclipseは入れてません。
コマンドラインとテキストエディタのみで作業する方が楽なので。
Javaでガッツリと書く場合は、入れた方がよいです。
（私の場合、Javaコードは全体の1%未満なので、Eclipseを使わない方が楽）