VGSを育てる

業務連絡：
ちょっとばかり、このブログのテンプレートを変更してみました。
もしかすると、過去の記事（大きな図面があるもの）は、レイアウトが崩れているかもしれません。
実は、前のテンプレートだと、スマホで表示した時に上手く閲覧できないことがあったようなので、なるべく早く変更したかったのですが、諸般の事情で変更できませんでした。ですが、諸般の事情をクリアできたので、めでたくレイアウト変更した訳です。

以下、本題です。

私がSUZUKI PLAN - Video Game System（VGS）を完成させてから、早くも一年ぐらいの月日が流れてしまったようです。時の流れとは早いモノです...恐ろしい。VGSのアーキテクチャ設計をしていたのが昨日のことのようです。
その間に私は、Invader Block 2、NOKOGI Rider、VGS Chiptune Music、WTC1 on VGS、HOPPER、東方BGM on VGSの6本（Lite版を含めると8本、非公開にしたClassic Blockを含めると9本）のAndroidアプリをリリースし、内3本はiPhoneにも移植してリリースしました。

蛇足ですが、iPhone版はオマケです。過去の記事でも書いているように、私は今後、iPhoneではなくAndroidが伸びてくると読んでましたが、実際、そんな感じで遷移してきています（Appleの株価の転落っぷりを見て頂ければ分かると思いますが、やはり、iPhone5は失敗作だったようです）。恐らく、iPhoneの末路は、Macと概ね同じ運命を辿ると思います。AppleがAndroid版iPhoneを出せば、まだまだ伸びそうな気がしてますが、多分、iOSと共に心中するんじゃないかと思います。
でも、私自身、自作ゲームをプレイする時は専らiPhone版だったりしますが。60fpsで動いてくれるので。ゲーム機としてはAndroidよりiPhoneの方が優秀です。でも、スマホとしてはiPhoneよりAndroidの方が優秀。ただ、それだけのことです。（Jelly Beanなら60fpsで動くらしいので、私もJelly BeanにすればiPhoneではなくAndroidでゲームをプレイするようになるかもしれません）

で、メインのAndroidアプリの総ダウンロード数は、今数えてみたところ合計7620本でした。
内、ほとんどがNOKOGI Rider(Lite)です。（NOKOGI Rider(Lite)は5074本）
最近では、東方VGSのDL数が着々と伸びてきている感じです。
当面（紅魔郷の曲をコンプするぐらいまで）は、どんどん曲追加をしていこうと思います。
で、その後ですが、以前ニコニコ動画のブロマガでも書きましたが、Invader Block 2やHOPPERみたいな感じのミニゲームを大量に作っていく路線でいこうかと思っています。

VGSを開発した当初の目的は、NOKOGI Riderを作るためのエンジンとすることです。そして、それ自体は成功しました。ただ、私の真の目的は、自分でゲームを作ることでは果たすことができません。私は、私が面白いと思うゲームが世界に溢れて欲しいと思っています。もちろん、私自身がゲームを作ることが好きではありますが、私だけの力では、世界全体にイノベーションを起こすことは不可能だと想定しました。そこで、私以外の方にVGSでゲームを作って頂くことで、私にとって楽しいゲームを増やせば良いじゃないと思い、VGSをオープン化して無料で配った訳です。

VGSでゲームを作れば、そのゲームはSUZUKI PLAN臭の強いゲームになります。
そうなるようにデザインしたので。
これは、一種のブランディング戦略だと私は勝手に思っています。
私の現在唯一の収益化手段は有料アプリの販売ですが、有料アプリを買っていただくことの壁は、もの凄く高いです。その壁を乗り越える為に必要なのは、ブランドではないかと思います。
SUZUKI PLAN臭というのが、多分それ（ブランド）です・・・勘ですが。
「SUZUKI PLAN臭のするゲームなら売れる」という空気を作り出せば、自然と開発者が爆発的に増えるんじゃないかと期待しています。そして、当然ながら私が作ったゲームは売れるようになり、晴れて、世界に私が好きなゲームが溢れ、私自身も潤う・・・という、敗者の居ない理想郷ができる訳です・・・甘すぎるかもしれませんが。

ただ、今の時点ではVGSの普及率はイマイチです。まだまだ、私自身がVGSを育てていく必要があるということだと思います。なお、「育てる」というのは、VGSの機能拡張をすることではありません。VGSの機能自体は、細かい修正ならするかもしれませんがフィックスしています。つまり、大幅な仕様変更が発生することはまず無いと思ってくれて間違いありません。
私の言う「VGSを育てる」というのが意味する事は、「VGSの現時点の機能で面白いゲームを作ってリリースしていく」という事です。その為にもSHOT05を開発・・・というのが当初の計画でしたが、それについては、ブロマガでも書いた通り頓挫中です...SHOT05については、専業でアプリ屋ができる程度になったら開発を再開しようと思います。（いつになるやら...）

私自身がSTGが好きだからSTGを作っていた訳ですが、より幅広い開発者へVGSを訴求するには、色々なジャンルのゲームを作った方が得策なのかもしれない・・・と、思いつつある今日この頃です。

MS-Word2010導入

VGSの本の原稿は、とりあえずOpen-OfficeのWriterで執筆済みですが、清書をするためにMicrosoft-Word-2010を導入しました。Open-Officeだと、出版社との編集局面に入った時にいろいろと面倒だという事情も想定されますが、そんなことよりも「良い気分転換になるのでは？」と思ったことが導入の決め手。

先ほど、スタイルの作成が良い感じでできあがったので、１章を清書中。
こんな感じです↓。

今、企画出版をするために色々と動いていますが、こういう類の本は、これまでほとんど企画出版で出版された形跡が無いので、おそらく最終的には自費出版でやることになると思います。共同出版という線も無きにしも非ずですが。自費出版 or 共同出版の何れでも、原稿自体のクオリティを企画出版よりも自ら高くしておかないとマズイはず。（たぶん）

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

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

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

---

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とかで自費出版かな。今書いている書籍については、電子ではなくちゃんと紙の本にしたいので。
万が一、「ウチから出版しても良いぜ！」という奇特な出版社が居たら、ご連絡ください。

---

VGSマニュアル（No.6）をPDF化

VGSのマニュアル（No.6版）をPDF化してみました。
http://www.k2.dion.ne.jp/~ysuzuki/Manual06.pdf

主に、自分でチェックする用ですが、紙で（印刷して）読みたい方は、上記から落して印刷すれば良いと思います。

ちなみに、No.6版は49ページあります。
まだ、ギリギリ「薄い本」＝「同人誌」の範疇ではないかと思います。
なので、VGSのバージョン1.01がVectorにアップロードされたことを確認したら、電子出版の同人誌として、メロンブックスDLで出版してみる予定。

あとは、GoogleBooksとかにもアップロードできないだろうか？
（GooglePlayでの書籍アップロード方法は現在確認中）

[追記1]
一応、GoogleBooksで出版できる状態にしておきました。
あと、MelonbooksDLでの出版についても手順を確認済み。（問題なし）
いよいよ私も同人誌発行か・・・ちょっと、方向性が違う気もしますが。
折角なので、技術書だけでなく、淫靡な小説でも書いてみようかと、思ったり思わなかったり。
淫靡な小説は冗談ですが、精神論中心の技術書とかを出版してみるのは面白いかもしれません。

[追記2]
出版者登録の手続きは簡単にできましたが、出版するまでが大変そう？
とりあえず、GoogleBooksについては、保留かな。
しかし、GoogleBooksだと、図書館から引っ張り出してきたような古典経済学書とかが結構登録されていて、割りとそういう本が好きなんですが、スキャナ取り込みみたいな感じなので、そういう本は、携帯からだと読み難い・・・青空文庫なら、スキャナ取り込みではなく、ちゃんとディジタル化された情報っぽいので、読み易いですが。一応、そういう本も好きなので、当面は青空文庫だけでも結構楽しめそうです。読書は趣味ではないですが、ピーク時は文庫や新書を月20冊ぐらい読んでた時期もあるので、たぶん、嫌いではありません。

VGS has uploaded on Vector

VGSがVectorにアップロードされたようです。
http://www.vector.co.jp/soft/winnt/prog/se499640.html

これで、Version 1.01へVUPする作業に着手できます。
VectorにVersion 1.01がアップされるのは来週後半ぐらいになると思います。

VGEオープン化プロジェクト（完了）

ドキュメント込みで完成しました。

ドキュメント：
http://hp.vector.co.jp/authors/VA040196/vgs/index.htm

イメージ：
http://www.vector.co.jp/soft/winnt/prog/se499640.html

[追記] 9-Oct
印刷用にPDFにしてみたら、43ページもありました・・・さて、英語化はどうしたものか。
文字数カウントしたところ、約45,000文字。
Google提携の翻訳屋に依頼すると、１文字あたり2.6円～らしいので、117,000円～か。
サンプルプログラムや画面出力部分など自分でやれば良い部分（というか殆ど英語の部分）を削った所、約23,000文字（約60,000円～）。
なかなか微妙な額です・・・英語化はとりあえず保留で。

[追記] 10-Oct
あー・・・拡張データスロットみたいなのが必要かな？
任意バイナリデータをROMに取り込め、アプリから取得できる感じの。
必要っぽい気がします。
直ぐに欲しい人が居れば、メールで急かしてみてください。

VGEオープン化プロジェクト (5)

ドキュメンテーション作業中。

とりあえず、１章（概要）を書きました。

１章は唯一の駄文スペースなので、かなり遊びました。

以下、抜粋して掲載。（けっこう長いです）

※かなり短時間で書いたので、誤字・脱字が多いかも

　誤字・脱字はいつものことですが・・・

1-1 VGSとは

  VGS(Video Game System)とは、C言語を用いてWindows/Android共通の実装でゲームを作成できる仮想プラットフォームです。ゲーム開発者は、VGSを用いることでゲーム本質部分の開発に勢力を注ぎ込むことができます。似たような思想で作られた「プラットフォーム共通化ツール」の類は他にも腐るほどありますが、VGSの最も特徴的な点は、2Dゲームの開発に特化していることと、仮想ハードウェアの仕様が非常にチープであることです。
  ゲームハードウェアは、時代とともに「限界を無くす」方向へ進化してきました。しかし、その進化の結果、グラフィックのリアルさなどのゲーム本質とはあまり関係ない部分に対して開発リソースを注ぎ込む無駄が生じるようになりました。現在、１本のゲーム製作に掛かる費用は、嘗てのハリウッド映画に匹敵する莫大なものらしいです。その結果、とてもリアルでヌルヌル動く映画顔負けのゲームがリリースされている訳ですが、それらの「ゲームそのものの面白さ」に関しては、適切な費用対効果を得られているとは言い難いです。如何に動きがリアルであっても、ゲーム性が殆ど無く、つまらないものしか無いという印象です。ゲームを面白くするのに必要な投資の選択と集中を誤っていることがその原因であると、私は考えています。事実、注ぎ込んだ経営リソースはファミコン版マリオよりも桁違いに多い筈なのに、マリオの方が桁違いに面白かったと思うので。
  ゲームの本質部分を面白くするには、ゲーム本質部分の開発にリソース（資金や人材）を注ぎ込むべきです。ゲームハードウェアは、ある段階で進化を止め、ソフトの開発にのみリソースを集中するのが適切な選択だった筈です。しかし、全ての生物は遺伝的に、進化を止めることに対して背徳的な観念を持っているため、進化を止めることはできません。
  進化論の観点で見れば、ゲームに対して面白さを追求する行為そのものが淘汰されるべき存在なのかもしれません。
  しかし、私は今の「リアルでつまらないゲーム」より、嘗ての「面白かったゲーム」の方が好きです。もちろん、「ゲームが面白いか否か」の判断には多くの定性的な要素が関係するので、私の「嘗てのゲームの方が面白かった」という感覚は、ノスタルジーが創り出した幻想なのかもしれません。幾らでも反証の余地はあると思います。しかしながら、この議論について定まった解は得られていません。恐らくそれは「神のみぞ知る」領域の問題かもしれません。なので、これについて哲学しても禅問答にしかならないので、時間の無駄だと思います。最も賢い選択は、自分が正しいと思うことを信じることです。
  仮に私の考えが正しければ、このままでは面白いゲームは絶滅することになります。そこで、私は面白いゲームが絶滅を阻止するため、ゲーム開発者がゲーム本質部分の面白さを追求したモノ作りができるプラットフォームとして、この必要最低限のハードウェア機能のみを実装したシンプルな仮想ゲーム機「VGS」を開発しました。
  VGSで作られたゲームの具体例として、SUZUKI PLANが開発した「NOKOGI Rider」を遊んでみてください。
・Windows版 NOKOGI Rider
・Android版 NOKOGI Rdier
※製品版を買って頂けると嬉しいですが、無料の体験版（Lite版）でも、VGSの雰囲気を十分に掴める筈
  NOKOGI Rider（あと、Invader Block 2）は、VGSを用いて作られています。 NOKOGI Riderの場合、プログラム作成開始から完成まで半年弱の期間で作りました。 もちろん、開発に携わったプログラマは私ひとりだけです。 ついでに、NOKOGI Riderの開発が専業ではなく、普通の会社勤めのサラリーマン家業をこなしながらです。 普通の人間がこれだけのものを僅か半年弱でひとりで作るのは不可能です。 恐らく、専業で開発したとしても相当無理がある筈です。 別に私が特別能力が高い訳でもないと思います。
  VGSを採用したからこそ、それを実現できました。

1-2 使用許諾

  VGSを利用される前に、以下についてご了承ください。

VGSの著作権はSUZUKI PLANが有します。

VGSは、再配布可能とします。

VGSで作られたゲームを再配布する場合、必ずそのゲームに付随するユーザ公開ドキュメントに「本プログラムは、SUZUKI PLAN-Video Game Systemを用いて作られています。」と明記してください。

VGSを用いて開発されたプログラム及びデータは、その作成者が著作権を有し、 その作成者の責任で自由に配布又は販売できます。 それに際し、VGSに付属するモジュールの一部（ランタイム）を構成物の一部として同梱できるものとします。

VGSの不具合が見つかり、SUZUKI PLANに修正を依頼する場合、不具合の現象が発生する必要最小限のソースコードで実装したプログラム（再現プログラム）を提示しなければならないものとします。 再現プログラムの提示が無い不具合の報告は「VGS側の問題ではないもの」と見做します。 また、仮に再現プログラムの提示があっても、SUZUKI PLANは確実にその修正に応じなくても良く、修正の実施に関する判断はSUZUKI PLANの決定に従わなければならないものとします。

SUZUKI PLANは、VGS又はVGSを用いて開発されたプログラムの使用により生じた損失全般（VGSの不具合に起因する場合を含む）につき、一切の保障義務を負わないものとします。

（補足）
  明確な許諾条文とすることは避けますが、VGSを用いてゲームを作成する場合、極力商売をするようにしてください。 体験版などをフリーで配るのは良いですが、フリーで配るのはあくまでも体験版などの試供品に留め、開発者が利益を得る手段を確保することを推奨します。 なお、アフィリエイトはあまりオススメしません。なるべく有償で販売し、その対価で利益を得るように努めてください。 ただ、商売をするとなると色々と大変なところもあるので、使用許諾としての明文化は避けました。 ちなみに商売をする場合、特に気をつけないといけないのは、知的財産権（主に著作権）と税関系（源泉徴収や消費間接税）の事です。 知的財産権については、絵、音、プログラム(VGS部分を除く)の全てを自作すれば気にする必要がないので、それを推奨します。

1-3 基本スペック

  VGSは「仮想ゲーム機」です。つまり、概念はハードウェアですが、実体はハードウェアではありません。 要するにエミュレータです。しかし、模倣対象が物理的に存在しない点が普通のエミュレータと異なります。 この方式を採ることで、VGSというゲーム機が死ななくなるメリットがあります。 例えば、現行のハードウェアが廃れても、VGSを新しいハードウェアで動けるように移植することで、 ゾンビのように生き残り続けることができます。
（ハードウェアスペック）

項目	仕様
画面サイズ	240x320（縦画面のQVGA）固定
同時発色数	最大256色
ビデオメモリ	スプライト(1面) + BG(1面)
スプライト	・GSLOT(後述)から任意サイズの矩形データを転送できる ・パレット番号0番を透明色とする ・特定パレットでの単色表示（マスク表示）が可能 ・1/2サイズでの縮小表示が可能 ・縮小＋マスク表示が可能 ・拡大機能なし ・回転機能なし ・半透明表示機能なし
BG	・GSLOT(後述)から任意サイズの矩形データを転送できる ・８方向スクロールが可能
入力装置	シングルタッチのタッチパネル + ポーズボタン
入力装置 (Windows)	・左クリックをタッチとする ・右クリック又はESCキーをポーズとする
入力装置 (Android)	・シングルタッチをタッチとする ・3点マルチタッチ又は戻るボタンをポーズとする ・ホームボタンが押された場合、ポーズしてからホーム画面に戻る
音声	22050Hz / 16bit / モノラル
EFF音源	PCM音源
BGM音源	波形メモリ音源(後述)
ROM領域	以下の3種類×各256個のSLOT領域で構成される ・最大256x256のグラフィックを最大256個(GSLOT) ・PCM効果音を最大256個(ESLOT) ・BGMを最大256個(BSLOT) ※1つのゲームで使用できるROMファイルは1つのみ(複数ROM不可)
3Dグラフィック	対応しない（※対応していないではなく）
ネットワーク通信	対応しない（※対応していないではなく）
CPU	エミュレーションしない ※動作環境のNativeコードで動作

（波形メモリ音源 + 音源ドライバ）

項目	仕様
基本仕様	22050Hz / 16bit / モノラル
分解精度	22050fps
チャネル数 (同時発音数)	６チャネル
音色数	以下の4種類。 ・三角波 ・ノコギリ波 ・矩形波 ・ノイズ
音色の設定	チャネル毎に自由に設定や切り替えが可能
エンベロープ	チャネル毎に開始・停止について設定可能
ボリューム	マスターボリュームとチャネル毎のボリュームを設定可能
ピッチベンド	自動キーダウンが可能（自動キーアップは不可能）
その他	・ポーズ可能 ・フェードアウト可能

VGEオープン化プロジェクト (4)

Android版も無事完成。

ちょっとブレました。
写真で撮って気づきましたが、小指と薬指のツメが長いので切った方が良さ気です。
画面の内容は、昨日載せたWindows版から若干変更しました。
（Hello,World!の表示座標を出しただけですが）

あとはドキュメンテーション。
明日中には書ける・・・かは定かではないです。
まっさらな状態ではなく、ある程度書き進めている状態。
とりあえず、モノが完成したから、誤ってウソ情報を載せてしまうことは無いと思うので、区切りが良いところまで書けたら随時WEBにアップしていく予定です。（そして、職場や喫茶店からアクセスできるようにして随時チェックできるようにする予定）

せっかく、Google系サービスにドップリと浸かっているので、Googleドキュメントを使って書こうかと思いましたが、思ったよりも使い難いので、HTML（手書き）で書いています。
昔書いた、S/FTP-Serverのマニュアルみたいな感じ。

VGEオープン化プロジェクト (3)

Windows版が概ねできた感じです。

VGEのシステム（VGS; VideoGameSystem）の場合、プログラム作成を始める前に、プロジェクトの作成という作業をして、テンプレートから自アプリ向けの各種プロパティを設定した空プロジェクトを作成するのですが、その一連の仕組み（コマンドとかテンプレート）が完成しました。（たぶん）

プロジェクトを作成すると、最初にサンプルプログラムが自動生成されます。
サンプルプログラムは、古き良き伝統（？）を守り「Hello,World!」で。（下図）

VGSのHello,World!の場合、スライドで動かせたり、BGMがついていたり、効果音が鳴ります。
あとは、ポーズ処理なんかも実装しています。

このサンプルで、VGSの基本的な処理概要をカチッと理解できる・・・はず。
あとは、Android用を作成する作業ができれば、ドキュメンテーションを残すのみ。
３連休中にAndroid用も完成すると思いますが、ドキュメンテーションまで完成するかは微妙。
大枠の仕組みは、NOKOGI-Riderで既に完成しているから、ドキュメンテーションが一番大変。
できれば、英語のドキュメンテーションもやって海外でも配りたいところですが、流石にそれは厳しそう。

---

VGEオープン化プロジェクト(2)

マニュアル（HTML形式）を書きながら、仕様を固める作業中。
マニュアルは、作成途中のものをオンラインにupして、会社でも休み時間にスマホでチェックできるようにしたいところですが、まだ、色々とウソ情報が多いので、不特定多数（少数だろうけど）が参照し得るwww上に配置するのはまだまだ厳しい。

VGEオープン化プロジェクト

Androidのゲームデベロッパ人口を増やそうと思っています。

その為に必要なことはGoogleによる市場の整備が第一ですが、それは私のコントロールが及ぶ範囲ではありません。それは、将来的にどうにかなるかもしれませんが、どうにもならないかもしれません。第二に必要なことは、ゲームを作り易い開発環境を提供すること。

私は、ゲームを開発することそのものが好きですが、それと同じぐらい、『ゲーム開発プラットフォームを提供すること』をやりたいと思っています。私が思い描くゲーム開発プラットフォームの理想は、今亡き嘗てのシャープが残した名機X68000のような環境です。同人ゲーム開発者、プロのゲーム開発メーカーが同じ土俵（ハード）の上でゲームが開発できていたX68000全盛の頃が、ゲームが一番面白かった時代だったような気がするので。単なるノスタルジーかもしれませんが。まぁ、それならそれでも良いと思います。

理想は、私自身がそういうシステム（ハード＋市場）を作ることです。しかし、私にはそれを実現するだけの資金がありません。ですが、エミュレータであればお金を掛けずに作ることができます。そこで、手始めにWindows/Android共用のゲーム開発プラットフォームを開発し、無償で提供してみようと考えています。「それでどんなゲームを作れるの？」と疑問に思ったら、NOKOGI-Riderをやってみてください。

NOKOGI-Riderは、SUZUKI PLANが開発したWindows/Android共用のゲームエンジン「VGE」というシステム配下で動作しています。VGEの大まかなスペックは次の通り。
・グラフィック：
 - 解像度: 240x320（QVGA縦）
 - 発色数: 最大256色
 - スプライト: 1面
 　* スプライトはマスク表示（指定パレットによる単色表示）が可能
 　* スプライトは1/2サイズでの縮小表示が可能
 　* 拡大・回転・半透明は無し　
 - BG: 1面 （スクロール機能あり）
 - 他: Basicライクな画像描画機能を実装
・入力： タッチパネル
・音声： 22050Hzモノラル専用
・ＢＧＭ： VGS（VideoGameSound）
・メモリ：
　- グラフィックは、256x256サイズのものを最大256個のSLOTに保持
　　* グラフィックSLOTは、スプライト・BGで共用する
　　* スプライトの場合、パレット0番が透明になる
　- 効果音は、22050Hzモノラルの独自形式PCMデータを最大256個のSLOTに保持
　- 音楽は、VGSコンパイラでコンパイルしたものを最大256個のSLOTに保持
・CPU：
　- CPUエミュレーションはしない（動作環境のネイティブコードを使う）

パッと見でショボイ環境だということが一目瞭然だと思います。
3D？ナニソレ？の頃のゲーム機のスペックですね。
拡大や任意サイズの縮小、回転、半透明の機能が使えないので、若干スーファミに劣ります。

わざと、限界値を低くしてあります。
ゲハ屋さんは、限界を限りなくなくす方向で頑張ってしまっていますが、ハード的な限界値が低い方が、ゲーム本質の内容で勝負しなければならなくなるので、ゲームそのものの内容が面白くなるというのが私見です。下限方向にも一定の限界はありますが。（そのバランスが最も良かったのがX68000というのが私の認識）

そして、個人、法人関係無く、無償で利用＆販売しても良いことにする（ランセンス料もとらない）という方向で検討中（多分、法人利用の案件は発生しない想定ですが）。

アーキテクチャの概要図は、（昔載せましたが）下図のような感じ。

利用者は、Gameの部分を一定のルールに則ってC言語（C++も使えるけどC言語推奨）で作れば、Android/Windows共用のソースコードでゲームが作れるイメージになります。コンパイラを除くツール類は、原則的に全てCLI（Command Line Interface）で提供する予定（というより、CLIしか作っていないし、GUIを作る気は無いので）。あと、EclipseやVC++などのIDE関連のものは一切使いません。私自身がIDEを一切利用せずに作っていて何も不便は無いので（むしろ、CLIオンリーの方が慣れれば楽です）。

実現するかは未知数。外だしする為の作り込み（ライブラリ化＆その他、安全上の諸々の修正）とドキュメント化ぐらいの作業で実現可能な見通しなので、今年中にはできると思いますが。（時間が取れるかどうかが一番の不確定要因）

ちなみに、オープンソースにはしません。
オープンソースにしてしまうと、iPhone化が簡単にできてしまうので。
あと、VGEという名称は、変更する方向で検討中。
呼称はSUZUKI PLAN - Video Game Systemとか、そんな感じにして、内部モジュールとしてVGE（Video Game Engine）の名前を残す方向で。（私自身がVGEという名称で慣れてしまっているのと、関数名やらのプレフィックスがそうなっているので、VGEという名称は消さない予定）

---