開発状況2（IB6）

ステージ2をもりもり作成中。
Invader Block variatio 6 のステージ2は Battle Marine 仕様です。

ゲーム内容については、だいたい旧Battle Marineを去就した形になっています。敵の種類やグラフィックは流用。
プログラム的な部分は完全にゼロから作り直していて、コンボの爽快さなどを追求。

今週夏休みなので今日中ぐらいにステージ2を完成させるつもりですが、やや遅れ気味。

ステージ1（Invader Block仕様）からステージ2に進むまでの演出を凝らせていたら、作り始めるまでに結構時間が掛かってしまいました。

それ以上に、このタイミングでデレステを始めてしまい、それに時間が取られた感が否めない。
本当はコーヒーブレイク用に始めたのですがね。
ソシャゲって体力回復待ちがあるから、体力が尽きるまでプレイして、回復するまでの間に開発。そして、回復したらまたプレイみたいな風にすれば割と良い感じなんじゃないかと。
しかし、実際には無料石を回収し、石を使って（ガチャには回さず）体力回復してプレイを延々と繰り返し、そのコーヒーブレイクにIB6の開発を進めていた感が否めない。
夏休みはあと4日（木、金、土、日）で、土曜は予定があるから、流石に木、金は石を使った回復は自重するなどの縛りを入れねば。

開発状況（IBV6）

タイトル画面やらチュートリアルをザックリ作成。

システム的には NSWindow でのフルスクリーンモード（安定している方）にしておきました。

ウィンドウモードはナシです。

チュートリアル（というかHOW TO PLAY）は、昨今のチュートリアルと違ってかなりアッサリしたもの。アーケードゲームのインストに書いてある相当の情報量以上は入れないつもり。

ゲーム本編としては、ステージ1がだいたい完成したというところ。

Invader Block 5からの要素的な意味での変更点は、

・画面上部に吹き抜け（左右ループ）を入れてみた

・画面下にブロックを配置

・（メダルを消費して）ショットを撃てる

・（Battle Marineの）鳥が登場する

といったあたり。

かなりカオスな感じです。

難易度的なところはより一般向けに低くしています。

インベーダーを数グループ撃破するとステージクリアになって、Battle Marineシステムのステージ2に進む予定。

ステージは、

・Invader Block

・Battle Marine

・RENCON

・Invader Block（裏）

・Battle Marine（裏）

・RENCON（裏）

の全6面にするつもりで、特定条件を満たせば周回ループ（最大2周）できるようにしようかなと思っています。まだステージ1までしか作っていなくて、そこで色々と鬼調整をしているところなので、ステージ2以降は完全に未定。

ちなみに、今のところMac版しか作っていないですが、Windowsへの移植もすぐにできます（ゲーム本体はVGSで書いているので技術的には移植は一瞬でできる）。今秋ぐらいまでにMac AppStoreでの販売開始が目標で、その後Greenlightに出して成功すればSteam版（Steamのスコアボードやアチーブメントに対応したもの）を作ろうと思っています。（要するにGreenlightを通らない限りWindows版は世に出さないつもり）

課金要素としては有料販売のみで追加課金ナシ。

Mac AppStore版は1usd、Steam版は5〜10usdの間ぐらいにする予定。

Nintendo Developer Portalに登録した

任天堂から、Nintendo Developer Portal なるものが個人向けにも解放されたので、個人名義で登録しておきました。（ビジネス名はSUZUKI PLANにしておきましたが）
https://developer.nintendo.com/

NTSCみたいなものだろうか？（実務での任天堂ハードでの開発経験はゼロなので、その辺の詳しいことはよく分からない）

登録自体は無料でできるので、個人/同人のゲームデベロッパはとりあえず登録しておけば色々と見えてきて面白いかと思います。
とりあえず、3DS or WiiU向けの開発ならできそうです。
実際に開発を始めようとすると、開発機材の初期費用がそこそこ掛かるので、中々敷居が高いですが。

私自身も、実際に3DS向けゲームの開発に乗り出そうとして登録した訳ではなく、どういうSDKがあってだいたいどんな感じの仕様かを把握しておく為に登録しました。恐らく、今回のNDP解放は次（NX）に本格的にインディー開発者を取り込む流れにするための布石ではないかと思ったので。（5年前ならともかく、今から3DSだとミニマムの開発費用20万円をペイすることすら個人だと難しいんじゃなかろうかと）

3DSのSDK（nativeの方）の仕様書をまだ読み途中で、SDKがC++だったのは予想通りですが、Unitiyなんてものもあるんですね。
使いませんが。

Unityをディスっている訳ではなく、私の場合、ネイティブで動くVGSエミュレータを先に作り、その後ゲームを開発するというスタイルで、それはプラットフォームがどのように変化しようとも変わらないことなので、そうなるとUnityという選択肢は無意味だということ。

しかし、結構最近のコンソール開発環境って色々充実している感じなんですね。
無駄に充実しているというか。
Visual Studio統合って何なんですか（要らない）。

NXでは、CTR_SDK（CLI）のLinux版やMac版が欲しいところです。
あと、ハードは実機+USBケーブル+PCだけで開発できるようになっているといいなぁ。

Macでフルスクリーンゲーム開発のつらみ

macOS用のゲーム開発ですが、NSViewのフルスクリーンで開発すると中々つらい。というのも、落ちる系のバグが残っていると、電源OFFして止めるしか無い状況に陥る。そして、電源OFFにすると落ちる系のバグを特定できる情報が飛んでしまうとか。

という訳で開発中はウィンドウモードで作っておくことにしました。

ウィンドウの大きさに応じてアスペクト比を保った状態でゲーム画面を拡大。
そして、余白は（とりあえず）黒塗り。

余白がある場合は下図のような形になります。

上図は試験的にインタレース描画にしているので、若干画面が暗いな。

緑ボタン（or NSWindow の toggleFullScreen）でフルスクリーンにしてやれば、結果的にはNSViewをフルスクリーンにした場合と見た目は同じになります。なので、こっちの方法でフルスクリーン対応しておくべきかも。

macOSでフルスクリーンのアプリ（主にゲーム）を作る方法としては、

・NSViewをフルスクリーンにする方法（OSX 10.5以降）
[self.view.window.contentView enterFullScreenMode:self.view.window.screen withOptions:nil];
・NSWindowをフルスクリーンにする方法（OSX 10.7以降）

[self.view.window toggleFullScreen:nil];

の2種類があるのですが、どちらかといえば後者で対応した方が良いのだろうか... 前者の方が色々と考える事が少なくて実装が楽になるのですが。

前者にも色々とトラップ（※）がありますが。

※ドキュメントから抜粋: On OS X v 10.5, invoking this method when the view was not in a window would cause an exception. On OS X v 10.6 and later, you can now send this message to a view not in a window. For applications that must also run on OS X v 10.5, a simple workaround is to place the view in an offscreen dummy window.

まぁ、古いOS（10.6以下）を救うメリットはWindowsと違ってほぼ無いので、素直に新しい方（後者）で対応しておいた方が良いのではないかと思います。

後者での対応は色々と面倒臭いのですが。

最小化を考慮した対応、Windowサイズの制御、Storyboardをいじってメニューをちゃんと作らないとMac AppStoreへ出す時の審査でよくリジェクトされたりなど。

INVADER BLOCK variatio Ⅵ

SUZUKI PLAN というサークル名で活動を初めてからそろそろ丸8年経とうとしています。

8年やって当たったモノといえば 東方BGM on VGS ぐらいですが、これはノーカウントで。（純粋にオリジナルのものではないので）

特に生活が掛かっている訳でもないので、好きなゲームを好きなように作っていけば良いのではないかと思っています。

私が好きなゲームというと、例えばドンキーコング、アルカノイド、スペースインベーダーなどのような固定画面アクションゲームで、だから SUZUKI PLAN が最初に作ったゲームはINVADER BLOCKだったし、その後もBATTLE MARINE、CANON SNIPER、LUNATIC CRAYといった固定画面アクションゲームの比率が高い感じになっています。

中でも INVADER BLOCK は、最初に作ったためか特に思い入れが強く、私が新しい開発環境でゲームを作る時、必ず最初に作るのは INVADER BLOCK のリメイクという形になっています。

・ファミコン版: INVADER BLOCK FC（※未発表）
・スマートフォン（iOS, Android）版: INVADER BLOCK 2
・VGS mk-II版: INVADER BLOCK 3
・HTML5版: INVADER BLOCK 5
という具合。

あぁ、INVADER BLOCK 4が無いですね。まぁ、2と3は未発表のファミコン版を飛ばして採番しているので、INVADER BLOCKシリーズは実質5作品あることになります。
実のところHTML5版は公開しているもの（enchant.jsを使用）とは別のゲームエンジンを使ったバージョンもあったりしますが。

どれもそんなに大ヒットはしてません。
どちらかといえば試作的に作ったものなので当然ですが。
しかし、SUZUKI PLAN は今まで結構な数のゲームを作ってきましたが、その中で大ヒットの芽があるであろう作品は INVADER BLOCK だろうと思っています。

そこで、今の私ができ得る最大限のクオリティのINVADER BLOCKを作ろうと思いたち、現在開発中です。
タイトルは INVADER BLOCK variatio Ⅵ（仮）

対応プラットフォームはMacとWindowsで、最初にMac版だけAppStoreで出し、反応が良ければSteamでWindows+Mac版（AppStore版とは別でSteam関連のアチーブメントやリーダーボード等を実装する予定）を出そうかなと計画してます。

Steamで出すにはグリーンライトを通過する必要があるので、出ない可能性もありますが、AppStore版については今秋ぐらいまでには販売開始しようと思っています。

なお、スマホ版は今のところ予定していません。
VGSで開発しているので、スマホにはほぼノーコストで対応可能ですが、今回はタッチパネルではなくゲームパッドやジョイスティックを前提としたゲームプレイにしたいので、タッチパネル操作という足かせを付けながらのゲームデザインは避けようと思っています。
完成後であれば、スマホ移植する可能性が無い訳ではないです。
（要するにスマホファーストではないというだけのこと）

gamepad-osxの実装詳解

前回記事で書いた gamepad-osx の実装内容を軽く解説。

まず、mac OS (OSX) や iOS で HID（Human Interface Device; キーボード、マウス、ゲームパッドといった入力デバイス）へのアクセスは HID Manager 経由で行うので生成。

IOHIDManagerRef hid_manager = IOHIDManagerCreate(kCFAllocatorDefault, kIOHIDOptionsTypeNone);

次に、取得対象のデバイス情報を指定した CFMutableArray を作成する。
Objective-cなら割と簡単にできるが、Core Foundation を用いる必要があるので物凄く面倒くさい。

static void append_matching_dictionary(CFMutableArrayRef matcher, uint32_t page, uint32_t use)

{

    CFMutableDictionaryRef result = CFDictionaryCreateMutable(kCFAllocatorDefault, 0, &kCFTypeDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);

    if (!result) return;

    CFNumberRef pageNumber = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &page);

    CFDictionarySetValue(result, CFSTR(kIOHIDDeviceUsagePageKey), pageNumber);

    CFRelease(pageNumber);

    CFNumberRef useNumber = CFNumberCreate(kCFAllocatorDefault, kCFNumberIntType, &use);

    CFDictionarySetValue(result, CFSTR(kIOHIDDeviceUsageKey), useNumber);

    CFRelease(useNumber);

    CFArrayAppendValue(matcher, result);

    CFRelease(result);

}

余談ですが、Core Foundation を C/C++ で書いたコードを見ていつも思うのが「無駄なオーバーヘッド要因が異様に多い」ってことですね。その代わり拡張性は高い。これが所謂 Mach の設計思想から引き継がれたオドロオドロしい部分なんだろうと思います。要するに効率性ではなく柔軟性・拡張性みたいなところに特化した仕組みで、だからNeXTSTEPは実用に耐えられなかったのだろうと。iOS世代もそのCFを内部で引きずり続けているから、結局のところ処理効率はそんなに良くない。何故スマホ初期の頃にピュアなLinux Phoneが出なかったのかと今でも思っています（今となっては商業的な意味で手遅れですが）。

上記関数の page は kHIDPage_GenericDesktop で use は以下のような値を指定する。
なお、ジョイスティックとゲームパッドは別useになっているので注意。私の手持ちのゲームパッドの場合, kHIDUsage_GD_GamePad を指定しないと認識しませんでした。
・kHIDUsage_GD_Joystick : ジョイスティック
・kHIDUsage_GD_GamePad : ゲームパッド
・kHIDUsage_GD_Keyboard : キーボード
・kHIDUsage_GD_Mouse : マウス（トラックパッド）

そして、作成したCFMutableArrayで指定したものが取得したいデバイスだということを HID Manager へ通知して、そのデバイスが接続されたことと切断したことを検出するコールバックを登録。

IOHIDManagerSetDeviceMatchingMultiple(hid_manager, matcher);

IOHIDManagerRegisterDeviceMatchingCallback(hid_manager, device_attached, c);

IOHIDManagerRegisterDeviceRemovalCallback(hid_manager, device_detached, c);

なお、接続（切断）のコールバックの形式は以下のような感じ。（detachedも同じ）

void device_attached(void* ctx, IOReturn result, void* sender, IOHIDDeviceRef device);

このコールバックでは、接続（切断）されたデHIDの情報を教えてくれるだけなので、そのHIDからの入力を検出したり解除するには、更に別のコールバックを設定する必要があります。（詳細は後述）

あとは、HID Managerを動かすrun-loopをスケジュールしてOpenすれば、デバイスの接続と切断が検知できるようになります。

IOHIDManagerScheduleWithRunLoop(hid_manager, CFRunLoopGetMain(), kCFRunLoopCommonModes);

IOHIDManagerOpen(hid_manager, kIOHIDOptionsTypeNone);

ここまでが、HIDの接続・切断を検出するまでの手続きです。

あとは、接続を検出したHIDに対して入力を受け付けるコールバックを設定してあげれば、入力された内容を検出することが可能になります。

これは接続時のコールバックで次のように実行すればOK。

IOHIDDeviceOpen(device, kIOHIDOptionsTypeNone);

IOHIDDeviceScheduleWithRunLoop(device, CFRunLoopGetCurrent(), kCFRunLoopCommonModes);

IOHIDDeviceRegisterInputValueCallback(device, device_input, c);

デバイス入力コールバックの形式は以下のような感じです。

void device_input(void* ctx, IOReturn result, void* sender, IOHIDValueRef value);

最後に、この入力コールバックで以下を発行すれば入力された情報が検出できることになります。

IOHIDElementRef element = IOHIDValueGetElement(value);

type = IOHIDElementGetType(element);

page = IOHIDElementGetUsagePage(element);

usage = IOHIDElementGetUsage(element);

val = IOHIDValueGetIntegerValue(value));

ね、簡単でしょ？

Steamで購入したとある日本製のゲームが、ゲームパッドに対応できていない（海外製のゲームはだいたい対応できている）ので、そのサポートに対して「簡単だからゲームパッドの入力に対応してくれ」とお願いしてみたのですが、日本語でIOKitの仕様を正しく解説できているサイトがほぼ皆無だったんですよね...

そういう事情もあって、もしかすると多少ニーズがあるかもしれないと思い、かなり簡単な手続きでmac OSのアプリでゲームパッド入力に対応できるライブラリ（gamepad-osx）を作ってみた感じです。

まともな資料は英語しか無かったけど、冷静に読めば結構簡単なことしか書いていないので、特に困る人が居ない→だから日本語資料が無いのかもしれませんが。

ちなみにこのIOKitというフレームワークですが、mac OS（OSX）の中ではかなりベーシックなもので、Wikipediaなんかを見ても（かなりあっさりとだが）MachやBSDと同列に解説されています。要するに、mac OS（OSX）の仕組みを理解する上でかなり重要な部分なので、技術書ぐらい幾つかあるんじゃないかなと思ってAmazonで検索してみたのですが、見事に皆無。
https://www.amazon.co.jp/s/ref=nb_sb_noss?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&url=search-alias%3Daps&field-keywords=IOKit&rh=i%3Aaps%2Ck%3AIOKit
Appleによる情報統制でも掛かっているのかな？
まぁ、このブログは妄言ということで許される（のだろうか^^;）

mac OS (OSX) のアプリでゲームパッドを使う方法

Windowsだとゲームパッドへの対応は簡単（DirectInputで可能）ですが、mac OS(OSX)だとかなり躓きどころが多い。

まず、GameControllerを検出する標準フレームワークがありますが、これが全く使い物にならない。
対応機種が限られてしまうので。
AppleがMagic Gamepadみたいなものを出していればまだ良いのですが。

という訳で、mac OS(OSX) でゲームパッドの入力に対応する場合、HID Device Interfaceを使う方法が一般的です。

ただし、GameControllerと違って日本語の資料も無いし、ぐぐっても情報が全く出てこない。（ゼロという訳ではないですが）

という訳で、割と簡単に使える mac OS (OSX)用 のゲームパッド・ライブラリを作ってみました。
https://github.com/suzukiplan/gamepad-osx

呼び出しはC規約なのが若干面倒かもしれませんが、Objective-cのXcodeプロジェクトであれば問題無く利用できます。（開発中のOSX用STGに組み込んでみたのですが、問題なく動きました）

swiftのXcodeプロジェクトで使えるかは未確認ですが、int型とvoid*型しかインタフェースに使っていないので、まず問題ないでしょう。

[追記]
どうせなら、入力系統は全て gamepad で処理した方が良いということで、キーボードとマウスの入力も受け付けられるようにしました。
ただし、キーボードに関しては実装する NSView のサブクラスをファーストレスポンダに設定しておく必要があります（そうしないとキー入力時に警告音が出てしまうので）。
また、これはかなりベーシックなレイヤーで入力を受け取っている関係で、NSWindowなどの状態が非フォーカスでも入力が受け付けられる筈です。また、マウス座標も全体座標の筈。（要するにキーボードとマウスはどちらかといえばフルスクリーンで動作するゲームを想定したものです）