本の執筆状況

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ページ程度書けば、バランスが良さそうな気がします。

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

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

---

VGS 1.02

SUZUKI PLAN - Video Game Systemをバージョン1.02にアップする手続きを取りました。
Vectorで公開申請中です。
恐らく、来週のウィークデー中には公開されるものと思われます。
変更点などについては、オンライン版のマニュアルに載せておきました。
http://hp.vector.co.jp/authors/VA040196/vgs/index.htm

なお、変更点は、前記事のコメントでご指摘いただいた関数名の変更（kkd→deg）のみです。
template/vgeapi.hに以下の#defineを追加しただけ。
#define vge_deg vge_kkd
#define vge_deg2rad vge_kkd2rad
#define vge_rad2deg vge_rad2kkd

そういえば、VGSの使用許諾で、『VGSで作られたゲームを配布する場合、必ずそのゲームに付随するユーザ公開ドキュメントに「本プログラムは、SUZUKI PLAN-Video Game Systemを用いて作られています。」と明記してください。』という要求事項を掲載していますが、これの真意は、VGSで作られたゲームの所在を私がチェックし易くするためだったりします。あとは、VGSの普及活動（主に執筆活動）を私が頑張り、それなりに普及してくれれば、アプリの利用者サイドにとっても良い検索手段になるのではないか・・・という期待も込めてます。

その期待に沿えるようにするためにも、書籍化は何としても完遂したいです。
今週は若干忙しかったので、進捗は良くないですが。

---

VGSのぶ厚い本を執筆中

VGSの厚い本を執筆中。今年中には執筆完了したいです。
一応、商業誌で出しても問題ないレベルのものを執筆中。
たぶん、200～500ページぐらいの範囲ぐらいの規模のものになる予定です。（アバウトすぎ？）
今のところ、第一編の触り部分が書きあがりました。（だいたい40ページぐらい）
第二編と付録編では、電子マニュアルで公開済みの情報を更に詳しくした上で掲載し、第三編で実際にゲームの開発例を示しながら、学習できるような内容の書籍（全四編の1冊の本）にするつもりです。書きあがっても出版できるかは、定かではないですが。企画のたまご屋さん経由で営業を仕掛けて、ダメだったらAmazonとかで自費出版かな。今書いている書籍については、電子ではなくちゃんと紙の本にしたいので。
万が一、「ウチから出版しても良いぜ！」という奇特な出版社が居たら、ご連絡ください。

---

PDFにしおりをつける

VGSのマニュアル（PDF版）にしおりをつけてみました。
http://www.k2.dion.ne.jp/~ysuzuki/Manual06.pdf

断然見易い。

しおり（ブックマーク）をつけるのって、ウン万円するAdobeソフトが必要かと思いきや、OpenOfficeのみでいけました。ただ、個人的にOpenOfficeはちょっと使い難いですが。（動きがモッサリしているから、事務ツールとしては使えません）

私の場合、マニュアルや仕様書を書くときは、だいたいHTMLで書いています。WordとかOpenOfficeだと、ついつい、改ページとかのスタイルを気にしながら書いてしまう悪い癖があるので、HTMLの方がそういうことを気にせず書けるし、容量も小さいし、即座にWEBアップできたりするので、色々とお得。

なお、HTMLは、フロントページ（？）とかは使わずに、テキストエディタでダイレクトに書いています。
※上記PDFも、原本は、その方法で作成したもの（以下）
http://hp.vector.co.jp/authors/VA040196/vgs/index.htm

HTMLでマニュアルを書く時に、
・章（1.xxx）はH1タグで囲む
・節（1-1 xxx）はH2タグで囲む
・項（(1) xxx）はH3タグで囲む
という風に注意して書くようにすれば、あとはブラウザに表示される結果をOpenOfficeにコピペするだけで、スタイル情報が勝手に付与されます（Hxタグが見出しxに対応する形）。
ただし、テーブル（表）の幅が若干おかしくなるので、それについては手動修正が必要ですが。
修正が終わったら、PDFでエクスポートする時に、「初期値」タブの「区画」エリアのラジオボタンで「ブックマークとページ」をチェックしてエクスポートすれば、上記PDFのようにしおり（ブックマーク）が自動的に入ります。

HTMLでマニュアルを書く人なんて、かなりの少数民族なので、誰得情報ですね。

課題

過去数本ゲームを作ってみて、最新作ができるたびに、過去のゲームが皆つまらなくなります。
概ねいつも、今作ったゲームに飽きたら次回作の製作に取り掛かかることが、その理由。
個人的にNOKOGI-Riderはかなりよくデキていると思っていて、今のところ、私自身の総プレイ時間が100時間を超えましたが、まだまだ楽しめそう。（それだけ、次回作の開発が遅れる訳ですが）
とりあえず、SoldierをノーミスALLぐらいまではやっておこうかなと思ってます。
NinjaのノーミスALLは、私には無理。（ゴリ押しでALLするだけでもギリギリなので）

あまり、自分を褒めすぎるのもアレなので、課題めいたものも挙げておきます。
①グラフィック：次回作は全部自作グラフィックでいきたい（モデルツールに頼らないようにしたい）
②難易度：だいぶ易しくしたつもりですが、高評価・低評価ともに「難しい」という意見が多い。
③演出(1)：もうちょっと敵爆破ギミックを凝らせたい。（プレイし難くならない程度に）
④自機タイプ：テストプレイをして頂いた海外の方からの意見で３機種にしてみました（元々、タイプAの1機種のみの予定でした）が、やはりバランスがあまり良くならなかった（というより、私自身のテストプレイは、もっぱらタイプAだけでやっていたのが最大の要因）。もうちょっと多様なプレイスタイルで楽しめる機種差みたいなものを盛り込むべきだったかもしれない。
⑤演出(2)：背景をもっと凝らせたい。（プレイし難くならない程度に）
⑥演出(3)：地上系の雑魚敵の動きが単純。（複雑なら良いという訳ではありませんが）

音関係やスコアシステムについては、概ね文句なしなので、このままいきたいです。