Apple開発者アカウントをどうするか

Apple開発者アカウントの更新時期がそろそろ迫ってきました。
が、今回は更新しようか若干悩ましい。
今のところ、更新しない方向で考えています。

最低限、更新できる程度の売上がAppStoreから出ていれば良いのですが、ここ1年間、新作を出していないこともあって、更新費用（12000円）すら稼げていない感じです。（ちなみに、過去365日での売上は37ドルと67セントで、収益は26ドルと9セント）

新作を作ろうとする意欲はまだ有るのですが、今作っているものはPC（Windows+Mac）向けで、MacであればAppStoreよりはWindowsとセットで出せるSteamとかの方が良いと思っていて、それならApple開発者アカウント（正確にはAppStoreでの配信権）を維持する必要がありません。

仮に更新しなかった場合、SUZUKI PLAN製のアプリをAppStoreから新たにインストールすることができなくなります。念のため、最近のダウンロード数をかなり久々にチェックしてみましたが、東方VGSとかはまだ1日平均100ダウンロードぐらいされているらしい。東方強い。

若者の酒離れ

私は酒をほぼ飲みません。
だたし、下戸ではないです。
ビールは苦いからあまり好きではないですが、日本酒であれば、美味しいものは美味しいと思っていたりします。ですが、飲むのはほぼ飲み会限定で、飲み会が無ければほぼ飲みません。稀にコンビニで買って飲むことがありますが、それも、数ヶ月に1回あるか無いかという頻度です。
「若者の酒離れ」みたいなキーワードの記事をチラホラ見るので、これは恐らく私に限ったことではなく、世間一般で起きている現象らしい。

【参考記事】

進む若者の酒離れ　２０代男性の４割が「月に１回も飲まない」理由
http://www.zakzak.co.jp/society/domestic/news/20161231/dms1612311000006-n1.htm

若者の「酒離れ」は必然！　そもそも日本人の約半数は酒が弱いので「無理やり飲ませてた今までが問題」

http://blogos.com/article/194190/

若者の「酒離れ」は本当だった！ 飲食店はノンアルコール飲料で若者を呼ぶ時代になる？

http://www.inshokuten.com/foodist/article/4115/

お酒といえば、そういえば主にビール類等の酒税がもうすぐ変わるとか。

ビール類酒税５５円に統一へ　１０月めど　メーカーと本格協議　来年度税制改正

http://www.sankei.com/economy/news/160906/ecn1609060029-n1.html

今まで境界があやふやだったビール類（ビール、金麦、第三のビールなど）の酒税が統一され、その結果、ビールの税額は若干安くなるが、金麦や第三のビールは高くなる（ビールと同じ税額になる）らしいです。

発泡酒（ビールなど）、醸造酒（日本酒、ワインなど）、蒸留酒（ウィスキー、ウォッカ、焼酎など）などの製法毎に税率が別れる感じになるとか。これ自体はシンプルで良いねと他人事のように思っています。

この改定は、「メーカーと協議した上で決定」しているということは、国にとっては税収、メーカーにとっては売上がこれで上がると踏んでいるんでしょうけど、それで（税収・売上が）上がるのか割と疑問です。

少し話しが逸れますが、酒に関する法律の話しで、よく「免許を持っていない人が酒を造るのは違法」といったことを聞きますが、これは、酒税法7条で酒を製造するには免許が必要だからと規定しているためです（同法で罰則も規定されています）。

そういえば、昔自宅で梅酒みたいなものを作っていた気がするが、あれは違法なのかな？と思ったのですが、梅酒とかについては合法らしい（国税庁のHPのQ&Aを参照）。

以下、全く根拠の無い妄言を書きますが、私は、この法律で免許が必要とするものを「製造」ではなく「販売目的での製造」などにした方が、税収も売上も伸びるのではないだろうかと考えています。

酒に税を掛けたり、製造を免許制にするのは、世界的には割と普通なことですが、日本で酒の製造を免許制にしたのは明治32年から（参考）と、割と歴史的に見て浅かったりします。江戸時代やそれ以前にも普通に酒屋はあった筈なので、もっと前からあったのではないかと思っていたのですが、明治以降の近代化という名の「西洋かぶれ化」のムーブメントの過程でようやく誕生したものなんですね。

酒の製造免許を取ることは、設備を準備するのが難しい関係で個人ではほぼ無理ですが、酒を作ることそのものは割と簡単なようです。まぁ、実際に作ったことが無いから分からないですが、コチラのサイトでどぶろくの作り方を確認した限り、素人でも作れそうです。（当然、クオリティの高いものを作れるかは別でしょうけど）

で、仮に酒の個人製造が合法化された場合、酒を飲む人は皆個人で酒を作って飲むから税収は落ちるか？高度成長期より前の物質が豊かでなかった頃と違い、現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、（販売さえ抑えておけば）税収への影響は皆無だろうと思います。

この推測が正しければ、免許制度を製造から販売に変えても税収と売上は変わらないということになります。

しかし、酒造りにも「モノをつくることの楽しさ」みたいなものはある筈で、実際、それを巡って起きた裁判（通称、どぶろく裁判）なんかもあったりしたようです（参考）。この裁判は結局国が勝っています。ですが、モノをつくることに対する欲求は、食欲や性欲などと同じぐらい人間の根源的欲求みたいなもので、それを法で縛るのはどうなんだろうと。勿論、規制する必要性があるのであればともかく、果たしてその必要性は有るのかがイマイチよく分かりません。そして、割とこういう所で本来発生している筈の需要の原体験みたいなものを潰してしまっていることがあるので、それによる上積み分が「税収も売上も伸びるのではないだろうか」と思っている根拠です。
つまり、昨今言われている「若者の酒離れ」の根本的な原因は、その需要の原体験みたいなものを潰したことによるものだろうという風に考えている訳です。

まぁ、額にしてどんくらいとか全然分かりませんが。ついでに、参考で出したどぶろく裁判の主旨によると「個人に製造を許すと税収が減ると予想される」とのことなので、判例ベースで考えれば、先述した「現代であれば個人製造する手間を支払うより、安定した品質で且つ量産化できる設備が整ったメーカー製のモノにカネを支払う方が安いはずなので、（販売さえ抑えておけば）税収への影響は皆無だろう」という私の考え方は、最高裁判所のお墨付きで間違っている（と予想される）ということになります。

Lv28のフルコンとか

ありえんわ〜

などと思っていたが、アッサリと取れてしまった。

今朝寝起きの半トランス状態だったのでスクショ等は撮り忘れた模様

現在、78/96曲フルコンが取れているので、残り18曲。

内訳は、
・Lv25以下: 44/44曲（フルコン率100%）
・Lv26: 27/33曲（フルコン率82%）※あんきらはまだ分母に入れていない
・Lv27: 6/12曲（フルコン率50%）
・Lv28: 1/7曲（フルコン率14%）
という具合。

Lv28の残り6曲をフルコンが難しい順に並べると、
・TOKIMEKI (rank: C)
・キノコ (rank: C)
・トワレ (rank: C)
・M@GIC (rank: B)
・LENGE (rank: A)
・Trancing Pulse (rank: A)
ですが、これは人によってかなり割れるらしい。

上記の並び順は、単純に現時点のコンボランクが低い（＝フルコンまで遠い）順に機械的に並べたもので、今朝フルコンを取った「あんずのうた」は、LENGEとTrancing Pulseの間（だから、フルコンを取れた順としては順当）。

余談ですが、「半年ぐらいプレイしていれば全曲フルコン取れるんじゃね？」とか思って始めたのですが、当初想定よりやや遅い & 半年で全曲は無理かもしれないと思い始める。かつて、キーボードマニアにハマっていた頃は、もっと短期間でバキバキ上達していたのに。衰えたのかなぁ...

SSS（廃人レース）

PRP1000に到達して、晴れてSSSランクを目指すレースの参戦権利を獲得。

ありがとうオーバーロード

改めてルールを確認してみたところ、

1000位以内・・・だと・・・
イベントの報酬と同じく2000位以内かと勘違いしていたけど、これだとかなりキツイな。

前期（2016.12）のボーダーは、

なるほど、821万か。

1曲あたりの獲得ファン数を平均5000人ぐらいとすると、
・ボーダー到達までに必要なプレイ数 = 1642回
・1日あたりの平均プレイ数 = 約53回
1曲平均2分ほどなので、1日あたりだいたい2時間プレイすればボーダーを超えられそう。
まぁ普通かなという感じですが、これを1ヶ月フルで続けるのは、やはり中々しんどいな。M@GICのフルコン安定化とか、普通の人が取らないシフトに夏休みを取るなどして全力で走るなどの工夫が必要かもしれない。

まぁ、ボーダーは人間レベルの争いなので、廃人レースというほどのものではないけど、上位陣は控えめに表現して狂っている。
6000万とかね。
平均獲得数を多めに見積もっても9230プレイぐらい必要な筈だから、時間換算で308時間ぐらいとか。休み無しで1日あたり10時間程度プレイしているとか、これなんてブラック企業？というレベルです。

今更、MFiゲームコントローラに対応してみる

バーチャルパッドを操作し易くするため、あれやこれやの工夫をしているところですが、やはりバーチャルパッドはどう頑張っても操作しにくいものなので、本命は物理コントローラー対応でしょう。

iPhone関連のコントローラは、iOS7の頃にMFi（Made For iOS）というApple公式認証が開始して、同時にデベロッパー向けに公開された GameController.framework を使えば、MFiコントローラでの動作が保証されるという盤石の体制が組まれました。

しかし、現在のところそんなに普及はしていない感じですね。
（価格.comやAmazon等でレビューを見る限り）

まぁ、細かいことは気にせず、とりあえず LaiNES for iPhone に GameController.framework を組み込んでみました。
https://github.com/suzukiplan/LaiNES-iOS/pull/2

実装自体はすごく簡単で、新幹線で移動中の社内で30分ほどでサクッと実装できました。
問題は検証できるハードが無いから、動作テストできないということ。
つまり、正常に動くかは分かりません。

一応、Apple Storeで取り扱っているものがあるようなので、どれか買って確認しようかと検討中。

http://www.apple.com/jp/shop/product/HKFY2ZM/A/steelseries-nimbus-wireless-gaming-controller?fnode=a3

http://www.apple.com/jp/shop/product/HJ172J/A/horipad-ultimate%E3%83%AF%E3%82%A4%E3%83%A4%E3%83%AC%E3%82%B9%E3%82%B2%E3%83%BC%E3%83%A0%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9?fnode=a3

http://www.apple.com/jp/shop/product/HJ162ZM/A/steelseries-nimbus-wireless-gaming-controller?fnode=a3

http://www.apple.com/jp/shop/product/HJEN2VC/A/iphone-6-6-plus%E3%81%A8iphone-6s-6s-plus%E3%81%AB%E5%AF%BE%E5%BF%9C%E3%81%99%E3%82%8Bgamevice-controller?fnode=a3

一番最後のヤツは無いですね。（iPhone 6/6plusは持っていないので）
候補的には、上からHORIPAD（上から2番目）あたりか。
メーカーの注意事項を見る限り Mac にも対応してそうですし。
（Macでも検証しておきたい）

バーチャルパッドのボタンをUIButton/ButtonでやるのはNG

スマホのバーチャルパッドって操作し難いですね。
知ってたことですが。
改善の余地が色々あって楽しい箇所ではあります。

前々回の記事でファミコンのA/Bボタンの配置について触れましたが、今回はその中身の実装について触れます。

最初、上記のA/Bボタンをそれぞれ UIButton（AndroidならButton）クラスを使って実装したのですが、それだと実際のところかなり操作し難いです。

どうすれば、改善できるだろうか?
まず、昔実機でファミコンをプレイしていた時に、どうやってコントローラを操作していたのか思い出してみることにしました。
そして、スーパーマリオで「Bダッシュをしながらジャンプ」をする時、親指の先でBボタンをホールドした状態で少し右（Aボタン寄り）にスライドして親指の腹でAボタンを圧迫することでジャンプしていた事を思い出しました。

これはiOSやAndroidの標準のボタンでは処理できない操作です。
何故なら、Bボタンをタッチしたイベントは、Aボタンの方でスライドしてもBボタンのイベントとして処理されてしまうので。

そこで、ボタンをUIButtonからタッチ判定の無いUIImageViewに変更して、その上にA/Bボタン両方を覆いかぶせるようにUIViewを配置し、そのUIViewでタッチイベントを処理するようにしてみました。

変更時のcommit
①タッチ判定の変更
②中央付近で両方のボタンを押せるように修正

タッチエリアのイメージは下図のような形です。

処理的には、
・タッチ位置がタッチエリア外ならA/B両方OFF
・タッチ位置が重なるボタンをON
・タッチ位置が中央付近（※若干の遊び領域あり）ならA/B両方ON
という形。

このようにしてみたところ、バーチャルパッドでも「スーパーマリオでBダッシュしながらジャンプ」といった操作ができるようになりました。

スマホのバーチャルパッド自体が邪道だと思っていますが、それでも作るのであれば、可能な限り操作し易いものを作りたい。

ただし、ランドスケープのバーチャルパッド・・・お前はダメだ。

ゲーム画面にバーチャルパッドを重ねるという行為が許せません。
これは、ゲームコンテンツに対する冒涜だとすら思っています。
しかし、実際GooglePlayで公開されているエミュレータアプリのデザインを見てみると、そういう配置のものが多いこと...
そういう配置にせざるを得ないことは理解できますが、それでも何故、そんなクソみたいなデザインにしたのかと。

今回、一応ランドスケープでも動作できるように作っていますが、

このように、バーチャルパッドの無い美しいデザインにしてやりました。
現時点ではランドスケープでは何も操作できません。
観賞用ですね。
もちろん、将来的には外付けのキーボード or ジョイパッドで操作できるようにするつもりです。

ランドスケープの場合、キーボードやジョイパッド必須（持っていないならポートレイトでプレイしてね）って仕様にすべきだと思っています。

そうすれば、
・ユーザーは持っていなければポートレイトでプレイすれば良い
・開発者はクソみたいなバーチャルパッドのデザインを拒否できる
・外付けコントローラを売っているメーカーが潤う
という具合に、ユーザー・開発者だけでなく新たな第三者までもが得をするという素敵な形になります。

更に言うと、そもそもランドスケープだとスマホの画面をタッチ操作し難い（スマホはポートレイトで持つ前提だから縦長になっている）という構造的な問題もあるので、ランドスケープなら外部入力機器を使うべきというのは、すごく理に適ったデザインだと思うのです。

XCodeでsubmoduleでC/C++のソースを持ってくる方法

XCodeのプロジェクトに、GitHub上の別プロジェクトのソースをsubmoduleとして組み込みたいのですが、検索してもあまり良い方法が見つからなかったので、個人的なメモを兼ねてそのやり方を書いておきます。

なお、これは実際LaiNES-iOSで実施している手順です。
https://github.com/suzukiplan/LaiNES-iOS
あと非公開ですがInvader Block 6のリポジトリでも同じやり方でVGSモジュールを組み込んでいます。

まず、XCodeでプロジェクト作成直後のLaiNES-iOSのディレクトリ構成が以下のような感じだったとします。

$ pwd

/Users/suzukiplan/programs/LaiNES-iOS

MacBook-Pro:LaiNES-iOS suzukiplan$ ls -l

total 208

drwxr-xr-x  34 suzukiplan  staff   1156  1  9 08:40 LaiNES

drwxr-xr-x   5 suzukiplan  staff    170  1  8 17:30 LaiNES.xcodeproj

MacBook-Pro:LaiNES-iOS suzukiplan$ 

このディレクトリ上で、git submodule add をします。

$ git submodule add https://github.com/suzukiplan/LaiNES.git cpp

※本当はそのままの名称にしたかったのですがXCodeで作成したプロジェクトのディレクトリと被ってしまうのでC++モジュールのリポジトリはcppという名称にリネームしています。

そして、Finderでそのcppディレクトリを開き、コンパイル対象のモジュールをドラッグ＆ドロップでXCodeのプロジェクトに持っていきます。

この時、「Copy items if needed」のチェックを外すことで、プロジェクト内からcppを参照する形にします。

このやり方で追加すれば、同じリポジトリ内で相対パス参照でモジュールを参照する形になります。

試しに、project.pbxprojファイルの内容を覗いてみると、確かに相対パス参照になっていることが分かります。

$ cat LaiNES.xcodeproj/project.pbxproj | grep apu.cpp

74B47A4C1E1F748200B5ADFE /* apu.cpp in Sources */ = {isa = PBXBuildFile; fileRef = 74B47A451E1F748200B5ADFE /* apu.cpp */; };

74B47A451E1F748200B5ADFE /* apu.cpp */ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; name = apu.cpp; path = cpp/src/apu.cpp; sourceTree = SOURCE_ROOT; };

74B47A451E1F748200B5ADFE /* apu.cpp */,

74B47A4C1E1F748200B5ADFE /* apu.cpp in Sources */,

あとは、このリポジトリを git clone した時、何もせずにXCodeでプロジェクトを開くと参照切れでエラーになってしまうので、忘れずに git submodule init と git submodule update をする必要があります。

この手順で困るケースとしては、参照するモジュールがディレクトリ階層を意識する構成になっている時です。その場合、何か色々とやる必要があって面倒くさいです。（だから、私はXCodeで扱う前提のC/C++リポジトリを作る時、いつもソースコードは src ディレクトリ以下に階層を掘らないようにしたり、ファイル名が被らないように気をつけているつもり）

まぁ、本格的に複雑な構成のプロジェクトにするなら、cocoa podsを使うべきですが、cocoa podsを使うまでもない簡易的なモジュール組み込みをしたい場合のTIPSということで。

しかし、cocoa podsは極力使いたくない... 遅いしわざわざフレームワークとして作るのが面倒だし、ついでに podfile や podspec の書き方に謎が多い（それでいて公式ドキュメントも中途半端なものしかない）ので、どう書けば良いのか分からず色々と試行錯誤 → 動作がイチイチ遅いので無駄に時間を浪費 というコンボが頻発するので、苦手です。

余談ですが、XCodeの公式ツール類が充実してなさっぷりは酷すぎる。
cocoa pods的なものは公式で準備すべきなのに未だに無いとか。
それでいて、非公式プラグインはバッサリ切ってくるというね。
Android Studioと並行して使っているとXCodeの酷さが色々と目立ちます。
XCodeも公式にIDEAベースとかにした方が、色々と良くなったりしそうな気がする。