NOKOGI Rider掲載情報（iP）

本日（29-Nov）発売のiPという雑誌に、NOKOGI Rider（WindowsのLite版）が掲載されています。
http://www.amazon.co.jp/iP-%E3%82%A2%E3%82%A4%E3%83%94%E3%83%BC-2013%E5%B9%B4-01%E6%9C%88%E5%8F%B7-%E9%9B%91%E8%AA%8C/dp/B00A2VLLD2/?_encoding=UTF8&camp=247&creative=1211&linkCode=ur2&qid=1353985746&s=books&sr=1-20&tag=shinyushacojp-22

小さい記事ですが、一応写真付きです。
雑誌掲載されるとパイロット誌が貰えますが、私は本屋で購入。
掲載された雑誌を全部買っている訳ではないですが、基本的にそれなりの記事が書かれた雑誌は買うようにしています。（ちなみに、iPにはSHOT02も掲載されたことがあります）

---

スマホのランニングコストを下げる

今、私はauのスマートバリューというやつでスマフォを使っています。
通常、7000円ぐらい（内訳は下記）掛かるランニングコストを、5500円ぐらいで使えるというプラン。
ただし、最大2年間しか適用できない条件付きですが。

（内訳）
・5,460円（3Gパケット通信）
・780円（携帯基本料）
・何か色々500円ぐらい

正直スマートバリューでも高過ぎです。
という訳で、auのスマフォはヤメにしてガラケーに戻そうと思っています。
しかし、今更スマフォ無しでは不便過ぎるので、イオンSIMの一番遅いプランにしてみようと検討中。
# イオンSIMのスマフォ＋auガラケーの2台持ち。

スマフォを持ち始めて8ヶ月ぐらいですが、3G通信の主な用途は2ch閲覧とGmail。

ニコニコ動画やYouTubeとかは、Wi-Fi環境でしか見ないです。

その用途であれば、一番遅いプラン（980円/月）でも全く問題ない気がします。

それなら、スマフォ+携帯の月々のランニングコストは2,000円ジャストぐらいまで落せる筈。

とりあえず、今使っているau端末ではイオンSIMにできないので、docomo端末に変更が必要。
対応端末は、下記リストのものらしいです。
http://www.bmobile.ne.jp/devices/devices.html?t=3

という訳で、SonyのXperia ray（SO-03C）をAmazonで購入しておきました。
なお、私には、テレビ放送を受信できる装置を持つことが出来ない法律（放送法）上の縛りがありますが、SO-03Cであればワンセグが付いていないので安心。

とりあえず、SO-03Cが届いたらなるべく速くイオンSIMを契約して、1週間ぐらいauスマフォと並走してみようかと思います。それで何も不便なことが無かったら、auはスマフォからガラケーに戻します。ガラケー（本体）は、スマフォ交換前の機種のバッテリーが上がらないように保存処置をしていたので、新しい機種を買わずにそのまま使う予定。（もちろん、ガラケーもワンセグが見れない機種じゃないといけないので、新しく買うのは面倒）

---

一太郎断念...

執筆中の本の原稿をOpen-OfficeのWriterで書いていましたが、清書をしようと思い、一太郎2012の体験版をインストールして試用してみましたが・・・Word系の操作が体に染み付いてしまっており、結構厳しい。
更に、一太郎2012の体験版をインストールした状態で、Open-OfficeのWriterで書いた文書を開くと、日本語が文字化けする事象が発生したので、一太郎の導入は断念。ちなみに、一太郎2012をアンインストールすると、文字化けする事象は発生しなくなりました。

操作が慣れない点については、想定済みだったので大した問題ではありません。
マニュアルを読み、操作を把握後、合格点（試用期間内で慣れることが可能なU/I）であれば、製品版の一太郎を購入してみようと思っていたので。
しかし、文字化け問題は、致命的なので、断念せざるを得ません。

原稿の電子データは、「Wordか一太郎で」という出版社が多いで、Wordにするしかないのか・・・。
Wordは本業でも使っているので、操作性の面は問題ないです。
ただし、動作が不安定。

本業では、Word-2007を使っているのですが、クロスリファレンスが多い200ページぐらいの仕様書を書いているとよくアプリケーションエラー（Access-violation）で落ちます。一応、落ちても自動復旧で概ね復旧できますが、執筆が佳境のクソ忙しいときによく落ちてくれるので、寿命が縮まります。
更に、標準スタイルの箇所が見出しマップへ誤表示される問題もやや致命的です。見出しマップの誤表示だけならまだ良いのですが、PDF変換時にブックマーク（しおり）にも同じように誤表示されるのでやや致命的です。
ついでに、U/Iがコロコロ変わる難点もあります。
私はショートカット操作がメインなので、U/I変更については大した影響はありませんが。

今回、初めてOpen-Officeを使い、本（250ページぐらい）を書いてみましたが、今のところ、落ちたことは一回も無いので、動作品質についてはWordよりもかなり高い印象です。
操作性についても、概ねMS-Wordと同じなので、特に困りません。
難点は、図面の編集が若干使い勝手が悪い事と、Calc（Excel相当のもの）が使い難いことぐらい。

ワープロについては、総合的に見て、MS-WordよりもOpen-Officeの方が安定している分、使い勝手が良いかも。動作さえ安定してくれれば、MS-Wordを導入しても良いのですが。

---

見本原稿（VGS本）

VGS（SUZUKI PLAN-Video Game System）に関する本の執筆が先週完了し、企画出版をするため、先週、企画のたまご屋さんへエントリーしました。企画が出版社へ送られるかどうかは、企画のたまご屋さんの審議待ちという状態。

企画提案用の見本原稿は、こんな感じです。

企画の審議には結構時間が掛かるようです。
連絡が来るまでに最長で3ヶ月程度掛かるとか。
結構長いですね。
なお、企画のたまご屋さんから配信待ちの期間中であれば、当方から別ルートで出版社へ営業しても問題無いらしいので、本書の出版に興味のある出版社の方は、随時ご連絡していただいても問題ありません。ただし、企画のたまご屋さんから配信されている期間中の場合、企画のたまご屋さん経由での依頼をお願いします。
ちなみに、出版が実現した場合、本を売るための営業活動等については、出版社側で率先して行っていただきたい（私にはチャネルが無い）ので、出版社側にも相応のリスクを取って頂いた方が良いと考えています。そのため、出版する場合、私からの費用負担はゼロということにします。だから、企画出版という手法でいこうとしている訳ですが、逆説すれば、本の売上げ中の私の取り分（印税）は低くても問題無いということです。（もちろん、企画が何処にも通らなかった場合は、自費出版にせざるを得ませんが）

[追記1] 21-Nov
コメントで頂いた横置き画面対応ですが、Windows版、Android版ともに完成。
あとは、マニュアルを修正次第、Vectorへアップ申請します。
ちなみに、vgsmkpj2コマンドでプロジェクトを作ればランドスケープ（横置き）、vgsmkpjコマンドでプロジェクトを作れば従来通りのポートレイト（縦置き）という仕様にします。

※なお、基本的にWindows only・Android onlyというスペックは作りません。


[追記2] 22-Nov
Vectorにアップロード申請しました。
アップロード申請した直後、マニュアルの誤字が見つかりましたが・・・（オンライン版のみ修正）
本の方の原稿校閲が落ち着いたら、マニュアルの校閲ももう一度しっかりやっておきたいところ。
本の方の原稿校閲が落ち着く気配が無さそうですが。

[追記3] 22-Nov
とりあえず、企画のたまご屋さんを経由しない独自営業で2社ほど企画を送ってみました。
・（株）アーク出版（http://www.ark-gr.co.jp/shuppan/）
・（株）ブレイン/東京図書出版（http://www.tokyotosho.co.jp/）
しかし、専門書の企画出版というのはそもそも少ないっぽいので、ダメかも。
やはり、自費出版コースかな。

---

本の執筆状況

VGSの一般書籍ですが、あと細かい部分が残っているものの、ほぼ完成。
今のところ、227ページ（195,451字）書きました。
もう、疲れました。。。

まだ、最後の章を書き上げてません。
その後、全体校閲、見栄え調整、あとがきを執筆すれば、250ページぐらい？
企画時点では校閲は完了していなくても問題無いので、最終章が出来次第、企画屋に投げます。
そして、結果を待ちながら地獄の全体校閲。（私は誤字が多い方なので、全体校閲が大変...）

ちなみに、最終章は「Android移植」。
ここで、想定外の事象が起きたら、多少遅れるかもしれません。
最悪、執筆中に数回VGSのバージョンアップが必要になると想定していましたが、今のところバージョンアップは1回だけ（関数名の仕様変更のみ）で済みました。
順調すぎるだけに、最後で躓かないか心配。

[追記1] Nov-10
VGSに1つバグがあった（Android版でvge_termが呼び出されない）ので、Version 1.03にアップ。
無事、執筆完了したので、企画のたまご屋さんに企画をエントリーしておきました。
あとは、果報を寝て待つ・・・
ただ、校閲しなければいけないし、本の執筆過程で作ったブロック崩しゲームをマーケットに登録しておきたいので、まだまだ、寝ることができそうにないです。
校閲については、PDFにしたものをスマートフォンに入れて持ち運べるので、便利。

[追記2] Nov-10

この本の中で開発方法を解説する例題のブロック崩しゲーム（Classic-Block）を、さきほどGooglePlayに登録しました。
価格は無料です。

https://play.google.com/store/apps/details?id=com.suzukiplan.Block
タイトルが「古典的なブロック」になっているかも。
# 今、訂正しましたが。

[追記3] Nov-14
ひたすら校閲をしながら結果を待ってます。
ちなみに、「企画を配信するかどうか」という点の決定には、最長3ヶ月掛かるらしい。
随分と時間が掛かる・・・そして、配信された場合、2週間以内にオファーが無ければボツ確定。
ボツ確定するまでは、校閲の他に、自費出版に関する知識収集などをやっておきます。

---

M2 project

今は、VGSの本執筆で精一杯ですが、この本が書きあがった後にやってみたいことができました。
VGSは仮想ゲーム機ですが、ネイティブコードで動かす仕様です。
つまり、CPUエミュレーションはしてません。
これを、独自設計のCPU上で動かす純粋なエミュレーション方式にするという計画。
今、M2プロジェクト（VGS-MarkII Project）と名付けました。

割と壮大なプロジェクトです。
CPUについては、32bitの完全オリジナルCPU。
C言語との親和性の高いR/Aを持つ、CISC型CPUにしようと思っています。
CPU設計だけなら簡単なんですが、アセンブラとCコンパイラも自作しないといけません。
まずは、アセンブラのみのものを作るつもりですが、VGS用のCソースと互換を保ち、InvaderBlock2やNOKOGI-Riderを、再コンパイルして動かせるCコンパイラまで作ることが最終目標。

性能的にはNativeに劣ってしまいますが、これが実現すれば、１回のコンパイルで複数プラットフォーム対応ができるようになります。あと、VC++やGCCなどのサードベンダーのコンパイラも不要になります。

なので、M2プロジェクトにはそれなりに意義があります。
実現するかは未知数ですが。

---

VGS本の執筆状況

VGSの普及を促すべく執筆中の商業誌（契約出版社は今のところなし）ですが、割と進みました。

（状況）
・第１編（基礎）： 一通り執筆完了（校閲中）
・第２編（導入）： 一通り執筆完了（校閲中）
・第３編（実践）： 未着
・第４編（リファレンス）： 一通り執筆完了（校閲中）

（参考：目次）
■基礎編
1. はじめに
1-1 VGSとは
(1)仮想ゲーム機
(2)最低動作環境
(3)使用するプログラム言語
(4)前提知識
(5)必要な物
(6)推奨開発環境
(7)VGSを採用したゲームの例
1-2 VGSでできること
(1)面白いゲームの開発
(2)簡単にゲームを作れる
(3)効率的に高品質なAndroid用ゲームの開発
(4)低容量なゲームの開発
(5)開発したゲームの販売
1-3 iPhoneに対応しなかった3つの理由
(1)開発にはMachintoshが必要
(2)市場シェア
(3)機種自体の重要性の低下
1-4 iPhoneの魅力
(1)商売することが強制されるマーケット
(2)税に関すること
(3)アプリが「売れる」市場
1-5 VGSができること
(1)マルチプラットフォーム対応
(2)iPhone対応
(3)情勢を見守ること
2.アーキテクチャ概要
2-1 処理系
(1)VM方式とソース互換方式
(2)メリットとデメリット
(3)VGSの制約
2-2 ストレージ
2-3 入力装置
(1)タッチパネル
(2)設計思想
(3)ポーズボタン
(4)明確なEXITインタフェース
2-4 SLOT領域
(1)SLOT領域とは
(2)SLOT領域の種類
(3)SLOT領域への展開
2-5 グラフィックス
(1)画面サイズ
(2)VRAM
(3)同時発色数
(4)スプライト
(5)BG
(6)矩形転送
(7)図形描画
(8)Windowsでのエミュレーション
(9)Androidでのエミュレーション
2-6 サウンド
(1)ゲームと音楽
(2)音声品質の固定
(3)品質論
(4)PCM音源
(5)波形メモリ音源の概要
(6)波形メモリ音源の仕組み
(7)波形情報のメモリストア方式
(8)波形メモリ音源ドライバ
(9)波形メモリのストア範囲
(10)Windowsでのエミュレーション
(11)Androidでのエミュレーション
2-7 演算装置

■導入編
3.事前準備
3-1 ハードウェア
3-2 必須ソフトウェアの入手
3-3 導入手順
(1)インストール方法
(2)システム環境変数の設定
(3)デバイスの設定
3-4 推奨ソフトウェアの紹介
(1)秀丸エディタ
(2)ALFAR
(3)効果音エディタ_D
(4)Pxtone Collage
4.プロジェクト作成
4-1 プロジェクトとは
4-2 vgsmkpjコマンド
(1)コマンド仕様
(2)作成されるディレクトリ
(3)実行結果の例
5.ビルド手順
5-1 全体の流れ
(1)ビルドフェーズ
(2)makefileの仕組み
5-2 ROMデータのビルド（Windows/Android共通）
(1)ビルド手順
(2)解説
5-3 DLLのビルド（Windows用）
(1)ビルド手順
(2)解説
(3)実行
5-4 JNIのビルド（Android用）
(1)仕組み
(2)ビルド手順
5-5 APKのデバッグビルド（Android用）
(1)ビルド手順
(2)転送手順
(3)実行
5-6 APKのリリースビルド（Android用）
(1)キーストアファイルの準備
(2)リリースビルド
(3)キーストアファイルの適用
(4)ZIPアラインの調整
6.ROMデータの作成
6-1 ROMデータとは
6-2 vgsromコマンド
(1)コマンド仕様
(2)データソース
6-3 CHR形式データの作成（vgsbmpコマンド）
(1)指定できるBitmapファイル
(2)ファイル名の命名規則（GSLOTxxx.CHR）
(4)コマンド仕様
(5)実行例
(6)留意点
6-4 PCM形式データの作成（vgswavコマンド）
(1)指定できるWaveファイル
(2)ファイル名の命名規則（ESLOTxxx.PCM）
(4)コマンド仕様
(5)実行例
(6)留意点
6-5 BGM形式データの作成（vgsmmlコマンド）
(1)指定できるデータソースファイル
(2)ファイル名の命名規則（BSLOTxxx.BGM）
(4)コマンド仕様
(5)実行例
(6)留意点
6-6 DAT形式データの作成
(1)指定できるデータソースファイル
(2)ファイル名の命名規則（DSLOTxxx.DAT）
(3)使いどころ
(4)留意点
7.プログラムの作成
7-1 ゲームソース（game.c）
(1)配置先
(2)makefileの編集（hoge.cを追加）
(3)Android.mkの編集（hoge.cを追加）
(4)Windows版とAndroid版のソースコード同期
7-2 インタフェース関数
(1)処理の流れ
(2)インタフェース関数の仕様
(3)フレーム間隔
7-3 初期状態のgame.cの解説
(1)概要
(2)利用推奨ヘッダ <1～8行目>
(3)当たり判定マクロHITCHK <10～12行目>
(4)InputInf構造体の宣言 <14～21行目>
(5)vge_init <26～44行目>
(6)vge_term <46～54行目>
(7)vge_loop [1/3] <56～68行目>
(8)vge_loop [2/3] <69～86行目>
(9)vge_loop [3/3] <87～97行目>
(10)vge_pause [1/5] <99～111行目>
(11)vge_pause [2/5] <112～129行目>
(12)vge_pause [3/5] <130～138行目>
(13)vge_pause [4/5] <139～155行目>
(14)vge_pause [5/5] <156～166行目>
(15)myprint <168～191行目>

■リファレンス編
A. ハードウェア仕様
B. API仕様
C. 初期状態のgame.c
D. MML仕様
E. サンプルMML（bslot000.mml）

ページ数は、今のところ、ジャスト90ページ。（90,763字）
ただし、私の校閲はかなり大手術が入ることがあるので、1,2,4編の量は、まだまだ流動的です。
図解が少ないので、図解を増やしたいところ。（しかし、無意味な図は載せたくない）
あと、分量的には、第3編を100ページ程度書けば、バランスが良さそうな気がします。

なお、本当に出版されるかは未知数です。
完成したら、企画のたまご屋さん経由で営業を仕掛ける予定ですが、採用されるかは分からないので。（たぶん、企画書は結構良い感じだと思うので、最低でもたまごには成れると思いますが）

採用されなかったら、お蔵入りです。
「ウチから出版しても良いぜ！」という奇特な出版社の方が万が一居たら、ご一報ください。

---