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などの状態が非フォーカスでも入力が受け付けられる筈です。また、マウス座標も全体座標の筈。（要するにキーボードとマウスはどちらかといえばフルスクリーンで動作するゲームを想定したものです）

レベル3の壁超えについて

さて、あなたは以下の幾つが YES だろうか。

Level 1. ゲームを作りたいと思ったことがある
Level 2. ゲームを作ろうとしたことがある
Level 3. ゲームを完成させたことがある
Level 4. 完成したゲームを不特定多数の人に向けて公開したことがある
Level 5-1. 公開したゲームが法人から評価されたことがある
　・例1: 雑誌に取り上げられた（掲載された）
　・例2: コンテストで入賞した
Level 5-2. 公開したゲームで収益を得たことがある
　・例1: 入賞賞金をゲットした
　・例2: 原稿料をもらった
　・例3: 有料販売して売れた
　・例4: 広告収益を得られた
Level 6. 公開したゲームの収益が1年あたり20万円以上（確定申告が必要）になったことがある
Level 7. 公開したゲームで得られた収益を青色申告している
Level 8. 公開したゲームで得られた収益を白色申告している

細かいルールですが、レベル5とレベル6の判定ルールは以下のような感じです。
・5-1 or 5-2 何れか一方をクリア = レベル4.5
・5-1 and 5-2 両方をクリア = レベル5
・5-1 or 5-2 何れか一方をクリアしていなくても、レベル6をクリア = レベル6
要するにレベル4.5からレベル6への飛び級があり得るということ。
まぁ、どうでも良いことなのですが。

上記の「ゲーム」を「サービス」に置き換えても良いかも。
私は 1〜4 と 5.1&5.2 が YES で 6〜8 が NO。
つまり、レベル5 です。

私は2008年にゲーム作りを再開した当初から、このレベル設定を考え、最終的にレベル8を目指すという超絶難易度のクソゲーを遊んでいる訳です。

私がSUZUKI PLANを名乗るようになってからの遍歴を晒すと、2008年にSHOT01を完成させ（レベル3）、公開して（レベル4）、2009年にSHOT02で何冊か雑誌に載ったりして（レベル4.5）、2012年にSHOT04でようやく売れるようになってきた（レベル5）という感じです。

レベル4.5からレベル5への壁は、スマホ普及以前と比べれば大分低くなってきたものの、まだまだ依然として大きい。AdMobとか入れれば少しぐらいの収益ならゲットできるだろ？と思われる方も居るかもしれませんが、一定額（確か100$ぐらいだったかな？）以上ならないと振り込みはされないので、結構大変なことだと思います。

それでも、手段が皆無に等しかった昔と比べれば、レベル3の壁さえ超えればワンチャンあると言っても過言ではないでしょう。

しかし、レベル3の壁を超えられないという人は意外と多い。
恐らく、最初っからハイレベルなものを狙い過ぎているんじゃないですかね。
レベル3に達せない人は、まずレベル3を超えるだけのことを考えれば良いと思います。
例えば、ドラクエ3みたいなゲームを作りたいけど、プログラムは書けるが絵や音楽は無理なら、絵や音楽はキャプチャするなりROMから抜くなり（^^;）してでも作れば良いのではないかなと。
もちろん、キャプったり抜いて作った場合は公開してはいけませんが、まずはレベル3をクリアすることだけ専念すれば良くて、どうしても公開したければ、完成後に権利上問題ない素材を作るなりフリー素材から集めるなりして差し替えれば良いでしょう。
動くものがあれば、「じゃぁ、素材は俺が作ってやんよ」みたいな友達が見つかり易いかもしれません。

ポケモンgoの各国評価を見たら割と面白かった

ポケモンgoの人気凄いですね。
私もやっていますが、あまりやり込んではいなくてLv18, 集めたモンスターは43種ほど。

スマホゲームは、パズドラ、モンストが長年AppStore, GooglePlayの売上1位を独占し続けていた事からも分かるように、一発当てれば息が長い。果たしてポケモンgoはどうなるのか。

各国の売上ランクはAppAnnieで確認した限り1位キープという状態。パズドラやモンストが1位キープを続けたのは日本限定ですが、ポケモンgoの場合全世界（※一部地域を除く）で1位キープを（今のところ）続けているという違いがあります。

それはさておき、各国の評価を見てみると結構面白いことになっていました。

※図面+データはAppAnnie（https://www.appannie.com）から引用してます

まずは、日・米・英

だいたい同じような形です。
米英は 5 > 1 > 4 > 3 > 2 という並びに対して
日本は 5 > 1 > 3 > 4 > 2 という並び（3と4が逆）だったりと、
細かい違いはありますが。

余談ですが、これは私のアプリの評価を見ていても同じ傾向がある（日本人は３を付ける確率が他国と比べて若干多い）ような気がするので、これは国民性かな？「良い」「普通」「悪い」の選択肢で迷ったらとりあえず「普通」を選べ的な感じのアレです。

日本の評価1の指摘内容を見てみると、地域格差を指摘する声が多いので、各国だいたい同じような状況で評価1が集まっているのではないかと思います。（Ingressのポータルの情報がポケストップになっているので、Ingressが流行していた地域なら田舎でもそれなりに充実しているかもしれませんが）

ドイツ、オーストラリア、カナダ、オランダ、スウェーデン、スイスでもだいたい同じ評価分布になっています。世界各国だいたい同じような都市構造になっているんでしょうね。

しかし、イタリアは大分違う形をしている。

★１が圧倒的に多い。
これは一体・・・
Ingressポータルが全般的に少なかったとか？

逆にフランスは★1が圧倒的に少ない。

なお、フランスの評価件数が少ないのは、日本と同じく配信開始が遅かったためのようです。

世界各国で同じようにヒットしているので、評価分布は世界各国でだいたい同じ形（逆コの字型）になると推測していましたが、何故こんな差が出たのかな？色々と想像が湧いてきて面白いのですが、如何せん私はイタリアとフランスには実際に行ったことが無い（陽気なイタリア人と適当なフランス人といった漠然としたイメージぐらいしかない）ので、空想の域を出ません。