2017年1月29日日曜日

なんとなく音ゲーの形をしてきた

開発中のVGS Keyboardに単発ノートを実装してみたところ、何となく音ゲーの形になってきました。
とはいえ、まだ遊べるのは カエルの歌 限定ですが。
そういえば、VGSの波形メモリ音源を最初にテストした時の楽曲もカエルの歌でした。
この記事を書いていて気づいたのですが、カエルの歌よりもきらきら星の方が良かったかも。(移調はできないけどマルチノートの検証ができるので)
このカエルの歌ですが、ハ長調、ロ長調、変ロ長調、イ長調、変イ長調、ト長調、嬰ヘ長調、ヘ長調、ホ長調、変ホ長調、ニ長調、嬰ハ長調の12スケールで演奏できたりします。(なるべく全ての鍵盤を叩けるテストがしたかったので)

ノーツの判定も一応実装しています。
デレステと同じく、Perfect, Great, Good, Bad, Missの5段階判定を一応しているのですが、結果表示されるのはxcode console上のみという、ベータ臭がプンプン漂う状態です。(まぁ、今日開発開始初日だから仕方ないね)
私レベルでも、12音階全てでAP(All Perfect)できる激甘判定となっています。
というより、判定間隔が60fpsだから、ある程度甘くせざるを得ないんですよね...

あとは、ロングノーツを実装すれば基本的な入力システムはできあがります。

ロングノーツの実装は特に問題ないのですが、問題はその後に控えているVGSの楽譜データとノーツとの連携をどうするかという点。

とりあえず東方VGSで音ゲーを作ることにする

前の記事で書いたVGS-Keyboardで、とりあえず音を鳴らす仕組みを実装。
これで、単純なMIDIキーボード対応のVGSシンセサイザーみたいな感じになりました。

この音を鳴らす仕組みですが、1鍵1voiceという面白い仕様にしました。
通常のVGS音源(6voices)とは別音源としてVGSキーボード音源という24voices(!?)の新たな音源システムを定義する形で実現。(このキーボード音源の各voiceの実体はこの辺りで実装している構造体要素ですね)

これは、本物のチップチューン音源だったら割と実現が難しいです。
ピアノ等のリアル楽器は1鍵1voice方式だから、よりリアル楽器に近い自然な実装といえますが、それだとコストが掛かり過ぎるので。

しかし、こうした方が音ゲーとして扱い易そうかなと。

今考えてる音ゲーの大枠での仕組みは、VGSのNOTEオペレーションに通常の譜面データと同じ形でノーツ発生命令みたいなものを作りそれに従って操作していく感じのもので、このノーツに合わせて鍵盤を叩くことがゲームの操作としてそれとは別のスキームで発音ロジックを実装していくというものです。つまり、それなら音源システムはオリジナルVGS音源とは別枠にしておいた方が何かと都合が良いということになります...多分(この辺はカンだけを頼りに作っているので必ずしも正解ではないかもしれません)。

まずは、東方VGSの曲データをベースにして、とりあえず1曲遊べる状態のものを作ってみないと分からないですね。(理屈を捏ねる時間があったらコードを書けと)

音ゲーをオープンソースで作っていこうと思っています

既に作り始めてます。
https://github.com/suzukiplan/vgs-keyboard

もっとも、この記事を書いている時点ではMIDIキーボードの入力に合わせて鍵盤を描画するだけみたいな感じですが。
音ゲーというのは、比較的歴史が浅いこともあって、特許回避などが非常に面倒くさいジャンルとして知られています。歴史が浅いといっても、代表的な特許が出願からそろそろ20年経過して効力が切れようとしている頃合いなので、来年あたりから自由度が増してくるかもしれませんが。

ちなみに、README.mdの方で書いていますが、ゲーム本体はオープンソース&完全無料です。ついでに、コンテンツのデータ・フォーマットについてもデコーダ部分はオープンという、ほぼおっ広げ状態で開発していこうと思っています。
ゆくゆくは、楽曲データを同人ショップで売るなどしてマネタイズしようという作戦ですが、当面は(これがゲームとして面白いと確信できるまでは)無料で出すつもりです。

2017年1月28日土曜日

OSXでMIDIキーボードの入力信号を取得する方法(完結編)

前回と前々回の記事の続きです。

簡単におさらいしておくと、
・前々回:MIKMIDIを使えば実現できそうだと理解。
・前回:MIKMIDIを使ってnanoKEY2のデバイス情報が取れることを確認。
という感じで、今回はMIKMIDIを使って、nanoKEY2の入力信号をハンドリングする方法の解説です。

先に回答を書くと、以下のような感じで実装すれば、「★ココで捕捉」の箇所で入力信号を捕捉できます。

    MIKMIDIDeviceManager* dm = [MIKMIDIDeviceManager sharedDeviceManager];
    NSArray<MIKMIDIDevice*>* devices = [dm availableDevices];
    for (MIKMIDIDevice* device in devices) {
        NSArray<MIKMIDIEntity*>* entities = device.entities;
        for (MIKMIDIEntity* entity in entities) {
            NSArray<MIKMIDISourceEndpoint*>* sources = entity.sources;
            for (MIKMIDISourceEndpoint* source in sources) {
                NSLog(@"source: %@", source);
                [dm connectInput:source error:nil eventHandler:^(MIKMIDISourceEndpoint * _Nonnull source, NSArray<MIKMIDICommand *> * _Nonnull commands) {
                    // ★ココで捕捉
                    NSLog(@"detected commands: %@", commands);
                }];
            }
        }
    }

以降は、上記の実装をザックリと解説するだけなので、コードだけ見れば分かる人は読まなくても、もう自分のプログラムでMIDIキーボードを入力機器として使うことができますね。

まず、MIKMIDIDeviceManageravailableDevicesで接続されているデバイスの一覧を取得します。
デバイスの実体(MIKMIDIDeviceMIKMIDIEntity)には、
・source endpoint
・destination endpoint
という2種類の情報があり、入力信号を捕捉するにはsource endpointの方を使います。

入力信号の捕捉は、MIKMIDIDeviceManagerconnectInputで対象のsource endpointを指定してあげれば、入力信号が発生した時にeventHandlerがコールバックされるという感じです。

簡単ですね。

で、このプログラムを動作させた状態で、nanoKEY2の「ド」のキーを押してみると、押したタイミングで、XCodeのconsoleに

2017-01-28 18:41:57.014351 VGSKeyboard[36587:9378038] detected commands: (
    "<MIKMIDINoteOnCommand: 0x600000024aa0> time: 18:41:57.013 command: 159 channel 0 note: 48 velocity: 118 \n\tdata: <903076>")

という感じのMIDIイベント(MIKMIDICommand)が発生します。
そして、キーを離してみると、

VGSKeyboard[36587:9378038] detected commands: (
    "<MIKMIDINoteOffCommand: 0x608000029860> time: 18:41:57.549 command: 143 channel 0 note: 48 velocity: 64 \n\tdata: <803040>")

というMIKMIDICommandが発生しました。

つまり、キーボードのキーを押すとcommand 159が発生して、離すとcommand 143が発生するという感じでしょうか。そして、noteで対象の音階が分かるという感じです。

いやー、簡単ですね。このMIKMIDIというライブラリはCore MIDIというframeworkを使っているのですが、直にCore MIDIを叩くよりは大分楽な感じではないでしょうか。

しかも、OSXだけでなくiOSにも対応しているので、入力機器としてブルートゥースMIDIキーボードを使うiPhoneアプリなんかも作れてしまうのではないでしょうか。(今回はスマホ関連のことは未調査ですが)

OSXでMIDIキーボードからの入力信号を取得する(導入編)

前の記事で書いた MIKMIDI を使ってみる件の導入編です。
まず、XCodeで適当なプロジェクト(VGSKeyboard)を作り、CocoaPodsでMIKMIDIを取り込みます。

Podfileを以下のように作成して、

source 'https://github.com/mixedinkey-opensource/MIKMIDI.git'

target 'VGSKeyboard' do
  pod 'MIKMIDI', :git => 'https://github.com/mixedinkey-opensource/MIKMIDI.git'

end

pod update と pod install を実行すれば取り込めます。
そして、podにより生成されたワークスペース(VGSKeyboard.xcworkspace)を開き、ViewController.mでとりあえず、デバイス一覧を拾ってログに出すコードを書いてみました。

$ git diff VGSKeyboard/ViewController.m
diff --git a/VGSKeyboard/ViewController.m b/VGSKeyboard/ViewController.m
index 6ba3050..e9a5aea 100644
--- a/VGSKeyboard/ViewController.m
+++ b/VGSKeyboard/ViewController.m
@@ -7,13 +7,15 @@
 //

 #import "ViewController.h"
+#import "MIKMIDI.h"

 @implementation ViewController

 - (void)viewDidLoad {
     [super viewDidLoad];

-    // Do any additional setup after loading the view.
+    NSArray* availableMIDIDevices = [[MIKMIDIDeviceManager sharedDeviceManager] availableDevices];
+    NSLog(@"availableMIDIDevices: %@", availableMIDIDevices);

 }

そして、実行してXCodeのログを確認してみたところ、

2017-01-28 15:54:45.962064 VGSKeyboard[34236:9311302] availableMIDIDevices: (
    "<MIKMIDIDevice: 0x608000262100> Bluetooth:
        Entities: {
        }",
    "<MIKMIDIDevice: 0x600000075a40> \U30cd\U30c3\U30c8\U30ef\U30fc\U30af:
        Entities: {
        }",
    "<MIKMIDIDevice: 0x6080002628c0> nanoKEY2:
        Entities: {
            <MIKMIDIEntity: 0x600000075a80> nanoKEY2:
        Sources: {
            <MIKMIDISourceEndpoint: 0x600000051a60> nanoKEY2 KEYBOARD,
        }
        Destinations: {
            <MIKMIDIDestinationEndpoint: 0x608000047890> nanoKEY2 CTRL,
        },
        }"

)

おぉ、ちゃんとnanoKEY2のデバイス情報が取れている。

OSXでMIDIキーボードからの入力信号を取得する方法(模索中)

VGSの技術を応用した音ゲーとか作ったら面白いかもしれない。

という訳で、MacにMIDIキーボードを繋いで、そこから入力信号を拾うにはどうしたものか。

以前、ゲームパッドの入力信号を拾うため、色々と調べてみた結果、IOKitを使えば良いということが分かり、gamepad-osxというライブラリを作りました。
これは、IOKitのHID(Human Interface Device)の接続・切断・入力信号を拾う機能を使って実現しています。

MIDIキーボードも、HIDの一種と言えるので、同じ方式でいけるのでは?

と、思って色々と試してみたのですが、どうもMIDIキーボードはHIDとして認識されないらしい。ちなみに、使っているMIDIキーボードはKORGのnanoKEY2です。このMIDIキーボードは、Logicでは普通に使えているので、OSとしては認識できているようです。

MIDIキーボードはHIDとは別の手段で入力を検出するのかな?

そう思ってGitHubで何か良いものは無いものかと探してみたところ、良さそうなヤツがありました。
https://github.com/mixedinkey-opensource/MIKMIDI

上記を使えば、MIDIキーボードに限らず、MIDIデバイス全般を操作(MIDI信号の送受信)ができるらしいです。コレを使って、MIDIキーボードをMIDIデバイスとしてコンテキストが取れれば、そこから入力信号が取れる筈。

とりあえず、今回は足回りはコレで何とかなりそうだということで、試しに使ってみよう。
使ってみた結果の記事は別途書くつもりです。

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ダウンロードぐらいされているらしい。東方強い。

2017年1月23日月曜日

若者の酒離れ

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

【参考記事】
進む若者の酒離れ 20代男性の4割が「月に1回も飲まない」理由
http://www.zakzak.co.jp/society/domestic/news/20161231/dms1612311000006-n1.htm
若者の「酒離れ」は必然! そもそも日本人の約半数は酒が弱いので「無理やり飲ませてた今までが問題」
若者の「酒離れ」は本当だった! 飲食店はノンアルコール飲料で若者を呼ぶ時代になる?

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

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

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

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

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

少し話しが逸れますが、酒に関する法律の話しで、よく「免許を持っていない人が酒を造るのは違法」といったことを聞きますが、これは、酒税法7条で酒を製造するには免許が必要だからと規定しているためです(同法で罰則も規定されています)。
そういえば、昔自宅で梅酒みたいなものを作っていた気がするが、あれは違法なのかな?と思ったのですが、梅酒とかについては合法らしい(国税庁のHPのQ&Aを参照)。
以下、全く根拠の無い妄言を書きますが、私は、この法律で免許が必要とするものを「製造」ではなく「販売目的での製造」などにした方が、税収も売上も伸びるのではないだろうかと考えています。

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

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

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

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

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

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

2017年1月18日水曜日

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の間(だから、フルコンを取れた順としては順当)。

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

2017年1月14日土曜日

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時間程度プレイしているとか、これなんてブラック企業?というレベルです。

2017年1月9日月曜日

今更、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ベースとかにした方が、色々と良くなったりしそうな気がする。

iOS版のLaiNESを作成

先日Androidで作成したLaiNESをiOSにも移植してみました。
https://github.com/suzukiplan/LaiNES-iOS

前の記事で書いているように、最初Android版と同様OpenGLを使う方向で作っていたのですが、如何せんパフォーマンスが悪いと感じたので、CoreAnimationLayerで映像バッファをダイレクトに書き込む方式(VGSと同じ方式)で実装するように作り直していたら丸1日掛かってしまった...(その間、デレステのイベントが走れずランキングが500位台から2000位のボーダーギリギリまで落ちてしまった)

結果的に、パフォーマンスはOpenGLよりも良くなりました。
知っていたことですが、やはりGPUレンダリングはピクセルバッファの描画に弱い。
CPUレンダリング最高です。
(※レンダリングにはピクセルバッファしか使わない勢限定ですが)

Android版と若干異なる点として、バーチャルパッドのデザインを変えました。

Android版のバーチャルパッドは、「普通に考えればこうなるよね」という形。
エミュレータだけでテストしていると、こういうダメなデザインになります。

一方、iOS版はこんな感じ。
一見すると野暮ったい。
ですが、実機で動かしてみると明らかにコチラの方が操作し易い筈です。

Android版のデザインのダメなところは、まず、左右のカーソルキーとA/Bボタンを同じ平行線上に並べている点ですね。
これだと、右カーソルキーを入れながらA/Bボタンを押すのがツライ。
具体的には、左親指が邪魔でA/Bが押し難くなる形になります。
この「右カーソルキーを入れながらA/Bボタンを押す」という操作は、例えば、横スクロールのアクションゲーム(スーパーマリオとか)で頻繁に使います。

そして、A/Bを横並びにしているのもマズイ。
Bを押そうとしてAを押してしまう頻度が高くなってしまうので。
この状態だと、例えば、スーパーマリオでBダッシュで助走をつけてジャンプといった操作で頻繁に誤操作が発生することになります。
縦並びにしてみたところ、誤操作はほぼ発生しなくなりました。
(ただし、スーパーファミコンのように4ボタンだと悩ましい)

2017年1月8日日曜日

iOSでもOpenGLを使ってみる

現在公開している LaiNES Android を単純に iOS へポーティング中。
https://github.com/suzukiplan/nes-view-ios/tree/open-gles-20
(追記: 諸般の事情で消しました)

Androidでは今回、描画をOpenGLにしてみたので、折角だからiOSも同じ方式を試しておこうと考えました。

iOSでOpenGLを使う場合、Viewのinterface宣言を

@interface NESView : GLKView <GLKViewDelegate>

という風にしました。
・UIViewではなくGLKView(#import <GLKit/GLKit.h>)にする
・GLKViewDelegateを設定

また、このNESViewのイニシャライザ(一応全部)の延長処理で、

self.context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
[EAGLContext setCurrentContext:self.context];

という風にOpenGL/ES 2.0のコンテキストを設定。

あとは、AndroidのC++部分の実装と同じ形で、
・映像の頂点バッファを準備
・シェーダープログラムの作成
GLKViewDelegateのプロトコル(※)でピクセルバッファに対応するポリゴンの色を変更
などの処理を実装。

※これ
-(void)glkView:(GLKView *)view drawInRect:(CGRect)rect

OpenGLのインタフェースはC規約で、Androidのものと全く同じです。
だから、ソースコードはAndroidと共有できて良い感じなのですが、なんか微妙に遅い気がする。まだ、iOS固有の部分(core animation layerやUIView)にパフォーマンスの改善余地があるので何とも言えませんが。

あと、glViewportが想定通りに(というかAndroidと同じように)動いていない気がする。(これはコチラのバグかもしれません)

iOS的にはOpenGLよりもMetal推しだろうから、頑張ってOpenGL化するモチベーションがあまり沸かないんですよね。生Metal(?)を叩くのは結構面倒くさそうですが、Unityとかを使っていればAutomatic Graphics APIの項目をチェックするだけで簡単に使えたりします。

OpenGL自体結構deprecate方向に倒れつつある感じですしねぇ。
iOSならMetal、AndroidならVulkanにシフトしている流れです。
(Windowsについては相変わらずDirectXを魔改造する流れ)

Androidは例の如くOSバージョンのフラグメンテーション化が阻害要因になって普及は遅い筈です(本当、Androidなんか無くなれば良いのに)。Vulkanについては、そういった事情もあって聞き慣れない人も多いかもしれないので、(私もあまり詳しく無いですが)念のため補足すると、OpenGLと同じクロノスグループが開発しているもので、OpenGLは元々特定のハードウェアに依存しないように設計されたものですが、それが現代の最新のGPUには合わない(陳腐化した)ものになってしまったとかいう経緯で作られたものだったかと思います。「結局ハードウェアに依存してるじゃねーか」と突っ込みたくなりますね。しかし、実際その通りなので、その結果、より上位層のゲームエンジン(Unityなど)が直にOpenGLなどを叩きプラットフォーム依存を吸収する責務を負うという現代の潮流が出来上がったものと考えられます。その為、VulkanやMetalといった次世代のグラフィックスAPIはOpenGLと比べてローレイヤー寄りの設計になっているので、直に叩こうとするのはかなりツライですが、変態プログラマ諸氏にとっては格好の玩具だったりもします。

2017年1月6日金曜日

マリオランの価格考察

先日話題になったマリオランですが、一応私もプレイしました。
先週ぐらいにクリア済み。
当然ですが、クリアというのは、全ステージのカラーコインをコンプリートして、スペシャルステージやキノピオランの最終目標(ケーキの取得)も完了した状態です。
追加課金の無い完全落とし切りのゲームなので、恐らく追加コンテンツは発生しないのだろうと思います。
公式でもそういう発言をしているらしい記事があったので貼っておきます。
http://heavy.com/games/2016/12/super-mario-run-downloadable-content-additional-new-update-updates-maps-levels-items-nintendo/

このマリオランの価格設定(1200円)が「高すぎる」とかで少し話題になっているらしい。
参考記事:
任天堂マリオランは「高すぎる」 フォーブス記者も怒り爆発
任天堂 スーパーマリオランの1,200円はなぜ高い?

この意見が、ソシャゲなどを無課金でしかプレイしない人たち(いわゆる乞食勢)限定のものであれば、無視して問題ないと思うのですが、実のところ、課金をすることに全然躊躇しない私でも最初「ちょっと高いかな」と思ったりしたので、その原因について考察してみたいと思います。

なぜ、最初「ちょっと高いかな」と思ったのか。

それは、単純にワールドをアンロックすることに魅力を感じなかった為です。
フリーで提供されている3ステージを遊んでみて、これと同じのようなものの繰り返しだろうから、すぐに飽きるだろうなと。
一応、カラーコインを全部(ブラックコインまで)集めてみて、それ自体そこそこやり応えがあると思ったものの、それでも私ならすぐに全ステージ揃えてしまい飽きてしまうだろうと想像しました。
それだけのために1200円ということであれば、100%課金しなかった筈です。

そう思いつつ結局課金したのは、キノピオラリー(※)が楽しかった為です。
※他人のリプレイと競争してコインの獲得数で勝敗を決めるという対戦ゲーム
キノピオラリーは非同期対戦(対戦相手がリプレイ)のゲームなので、同期対戦のゲーム(例えば、デレステのライブパーティーというイベントなど)と比べて飽きがくるのが早そうだと思ったものの、1200円分は楽しめると思うことができたので、購入しました。

このことから、ゲーマー層(ゲームを極めるタイプの人)向けにはキノピオラリー、ライト層(カジュアルゲームなどを遊んで満足するタイプの人)向けにはステージアンロックがマリオランを購入させるための導線として考えられたモノなのだろうと想定できます。(他にも王国の建築要素など色々あったりするのかもしれませんが、そこら辺は専門外なので省略)

つまり、そこそこじっくりプレイしてみれば、1200円支払うことに納得感が得られる程度に楽しめるものだが、そこに至るまでの導線が弱いことが「1200円だと高いな」という印象を私に与えた原因だと言えます。

最初から有料であれば、何も不満無く気持ちよくプレイできた筈。

というのも、お金を最初に支払ってしまえば、それだけで「元を取る分まで遊び尽くそう」というモチベーションが生まれた筈なので。タダで手に入ったものだと、どうしても表面的なところで評価を下してしまいます。(購入導線の「強さ」みたいなことをチラホラ言ってますが、この「表面的なところ」だけでも買いたいと思わせるようなものが、要するに「強い」ということ)

また、フリーであるために、無課金勢によるレビューが沢山付き、購入する上で参考になる有益なレビュー(購入した上でのレビュー)が埋もれてしまうのも良くない。

free to play で出すのであれば、メインとなるコンテンツは全て基本無料でプレイできるようにした上で、サブコンテンツをアドオンにするなどで収益化の手段を作るしか無く、飽くまでもメイン・コンテンツに対して対価を求めるのであれば、基本有料にするのがベストな売り方だと思います。

つまり、今回1200円が高いと私に印象付けた根本的な原因は、本来「基本有料」で売るべき商品を「中途半端な基本無料」で売った為ではないかと考察しました。

pixel bufferのOpenGL/ESのロジックをC++化

昨日書いた記事で、Android版LaiNESの描画ロジックをOpenGL/ES2.0に書き換えることに成功しましたが、OpenGL/ESの実装をJavaで書くというしょっぱい作りになっていました。

AndroidのOpenGL/ESはNDK(C/C++)で書くことができるので、Javaで書くのはナンセンスです。

という訳で、サクッと Java → C++化。
https://github.com/suzukiplan/nes-view-android/pull/6

これで描画周りのパフォーマンスは大分良い感じになったと思います。

ただし、実機で動かした時の最大のボトルネック要因は描画周りではなくAPUエミュレータ(音関連)なので、その部分を何とかしたいところ。(これはLaiNESの問題で、VGSでは問題ないことだからあまり深追いするつもりはありませんが)

2017年1月5日木曜日

OpenGLで pixel buffer を60fps描画する方法

たまには技術的なことを書こう。

かなり以前、Android版VGSの描画をSurfaceViewからOpenGLに変更する試みをしたものの、60fpsのパフォーマンスが確保できず断念したことがあります。

VGSの描画処理は、

  1. 描画API(vgs_putSP等)を発行するとメモリ(システムメモリ)上に確保された8bit仮想VRAMに出力(OS非依存)
  2. VSYNC(垂直同期)の間隔で8bit仮想VRAMの内容を画面に出力(OS依存)
という流れで映像を画面に出力してます。

Android版VGSの上記2(OS依存部分)の実装は、RGB565のBitmapに8bit仮想VRAMの内容を(パレット変換をしながら)書き込み、それをSurfaceViewへCanvas#drawBitmapで描画する形になっています。

当時、これをOpenGL化するに当たって、毎フレームテクスチャを生成して描画するという方法を試しました。

しかし、テクスチャ画像の生成には結構時間がかかります。
また、システムメモリからGPUのメモリへの転送速度は物凄く遅い。
色々工夫して、50fps台ぐらいまで出せるようになったものの、それでは実用上問題がある(フレームレートだけでなく発熱量や消費電力も凄いことになる)ので、当時は結局OpenGL化を断念しました。

今回また、映像処理をOpenGL化することに再挑戦してみようと思います。

今回は、映像をテクスチャで表示するのではなく、1pixelを2ポリゴン(1つの四角形)で表現し、ポリゴンの色を変更することで映像を表示する仕組みを試してみることにします。

また、今回はVGSではなく、先日作ったLaiNESベースのファミコンエミュレータを使います。VGSのアーキテクチャはゲーム機エミュレータと同じ仕組みで作っているので、やっていることはファミコンと大差はありません。

以下、実際にOpenGL対応したAndroid版LaiNESを作成時の Pull Request です。
https://github.com/suzukiplan/nes-view-android/pull/4

ファミコンの場合、画素は256x240なので、pixel数=61,440 になります。
ポリゴン数 = pixel数 x 2 なので, 1フレーム辺り122,880ポリゴン。
60frame で描画するポリゴン数は, 7,372,800(737万2,800ポリゴン/秒)。

初代PlayStationの最大ポリゴン数のSCE公表値は、

  • 演算能力 = 150万ポリゴン/秒
  • 表示能力 = 36万ポリゴン/秒

とのことなので、この方式だと少々キツイ。
まぁ、初代PlayStationで動かす訳ではないですが。
ただ、もう少しポリゴン数を抑えた方が良い感じかなと。

そこで、上記のPull Requestでは、色情報の変化があったpixelのポリゴンのみ色を変更するようにしています。

これで適当なゲーム(某横スクロールアクションゲーム)を動かしてみて、1フレームあたりに更新されたピクセル数を測定した結果が下図です。
画面切り替わり直後などに最大更新が走りますが、ゲームプレイ中は多くても1万pixel未満の更新(これはスクロール時)で、スクロールしていない状態であれば100pixel未満の更新しか走らないようです。

常にスクロールしている状態(1万pixel更新)であれば、120万ポリゴン/秒ということになるので、これなら演算能力的には初代PlayStationでも耐えられそうです。(表示能力は追いつかなそうですが)

ナッツ&ミルクやドンキーコングみたいな固定画面アクションゲームなら余裕です。
まぁ、最近のスマホならフル更新(737万ポリゴン)であっても60fps保てそうな感じかと思います。(Android実機が手元に無くてエミュレータでしか動作確認してません)

2017年1月4日水曜日

デレステの上達方法

最近デレステのことしか書いていませんが、そういえばデレステは音ゲーなのに、音ゲーっぽいネタを書いてないな。という訳で、音ゲー部分の上達方法みたいなものを書いてみます。

参考までに私の腕前は、プレイ開始3日目でおねがいシンデレラのMasterをギリギリクリアできた程度で、プレイ開始から約4ヶ月経過した現在は、Master95曲中69曲フルコンしている感じです。(下手の横好きレベル)

音ゲーをじっくりプレイしたのは今回(デレステ)が初めてなのですが、一応ピアノをやっていたことがあるため、私のデレステ練習方法は基本的にピアノの練習方法の応用(ピアノで「こうやったら上手く出来るようになった」というネタが幾つかあるので、それをデレステ向けにカスタマイズしたもの)です。ちなみに、ピアノの腕前は平均律が弾ける程度でした(※今はもう弾けない)。

以下、我流の上達方法を項目毎に書いてみます。

①適正レベルより高めの曲のプレイを繰り返す
プレイ開始当初は、初回キャンペーンで獲得した無料石(2500個)を全て消費し尽くすつもりで、お願いシンデレラを繰り返しプレイしました。
自分の適正レベルより少し高めのレベルの曲(ギリギリクリアできるぐらいの曲)を繰り返しプレイすると上達スピードが早くて良い感じです。
やり込みの目安としては、ClearランクS(100回クリア)を取れるあたりを目標にすると良いでしょう。ちなみに、おねシンの次は(曜日限定だけど)咲いてJewel(Lv25)でそれをやりました。
しかし、一番難しい曲でも平常時はLv28までしか無いので、この方式で成長できるのは適正レベル(フルコンが狙えるレベル)26〜27辺りが限界になります。
イベントでLv30のMaster+曲が来れば、適正Lv28辺りにまで成長できるチャンスですが、Lv29のMaster+だとLv28のMasterとの差が少なすぎてあまり練習にならなかったりします。

②タップする指の接地面積を可能な限り小さくする
例えば、指の腹でタップするとミスし易くなります。
AppStoreでレビューを見てみると、「ロングノートが途中で切れる」「タッチしていないのにタッチ音が鳴る」といった不具合報告みたいなものをチラホラ見ますが、iPhone/iPadの場合、指の接地面積が大きすぎることが原因でそういった現象が起きている筈です。
タップするのは、置きプレイの場合は指先の肉の部分(爪を短めに切った状態で画面につかない程度の位置)にすれば、こういった問題は改善できます。(親指勢の場合は左手親指は右側面、右手親指は左側面の先端付近の肉の部分)

③椅子の高さを調整する
置きプレイ限定の事ですが、タッチしている時、腕が地面と並行になる程度の高さに椅子の高さを調整しましょう。
かなり重要なことです。
この高さでないと、②で書いている指先でのタップがやり難くなったりします。
また、脱力もし難くなるのでプレイしていて疲れやすくなります。
ピアノを習った経験がある人なら分かると思いますが、この腕が地面と並行になる程度の高さというのは、ピアノを演奏する時の椅子の高さのことです。
例えば、TOKIMEKIエスカレートやOrange Sapphireなどのフルコンが取れそうで取れないというレベルの人は、椅子の高さ調整をするだけでアッサリとフルコンが取れるかもしれません。

④単発ノートをスタッカート奏法で処理する
単発ノートは、タップした瞬間にポンと弾ませるようにする(スタッカート奏法でプレイする)ことで、次のノートの処理が迅速にできるようになり、その結果、Master+クラスの曲などで出てくる高速パッセージのようなノートでも簡単に処理できるようになります。

ただし、下手にスタッカート奏法でやろうとすると、ヘンな力みが入ってしまい逆効果になるので気をつけたいところです。以下のサイト(ピアノ向けのスタッカート奏法のやり方)あたりを参考にすると良いです。
https://allabout.co.jp/gm/gc/448849/all/

上記サイトで挙げられているポイントを、デレステに応用した形に修正すると、

  • 指先を立て、iPadに触れる面積をできるだけ小さくする
  • 指先からiPadまでの距離をできるだけ揃える
  • 指先が硬いイメージをもつ(指先が小さなメタルや陶器のようなイメージ)
  • 手首をぶらぶらと上下に振りすぎない
  • 指先だけに意識を集中させず、肘でコントロールするイメージをもつと過度に力むことを防げる
  • 肩を上げない(上半身をかたくしない)
  • 軽く跳ね上げられた反動で次のノートをタップするように意識する

という感じになります。
これらのことをしっかりと意識して、まずはProや易しめのMasterの曲で試してみると良いかと思います。

⑤使う指
デレステのキー配置を (1)(2)(3)(4)(5) とすると、ホームポジションを
(1) 左手の薬指
(2) 左手の中指
(3) 左手の人差し指 + 右手の人差し指
(4) 右手の中指
(5) 右手の薬指
という風にします。

稀に小指も使います(左右両方使いますが、どちらかといえば左の方が良く使う)が、小指についてはデレステ(5鍵)であれば、使っても使わなくても運動量に大差は無いかもしれません。(5鍵なら5指使えば必要十分ですが、スライドで動かした後のノート処理で移動量を少なくするために小指を使います)

親指は、遊びで片手プレイをする時にのみ使います。

デレステは2指(人差し指のみ or 親指のみ)でもプレイ可能な配置しか無いので、6〜8指だと過剰かもしれませんが、使う指を多くした方が、目的とするキーを押すために必要な運動量を減らせるため、処理可能な曲の幅が増えたり、体力(ゲームのスタミナではなくプレイヤー自身のリアルなスタミナ)の消耗を抑えられるといったメリットがあります。

一応、親指勢でLv30フルコンとかしている人も居ますが、そういったプレイ動画を見てみると、明らかに無用な力みが入っていたり、運動量が無駄に多い(バタバタしている)ことが分かります。体力がある内はそれでも良いのでしょうけど、エネルギーを無駄に使いたくなかったり、より難しい曲をフルコンできるようになりたいといった場合は、6〜8指でプレイしましょう。

⑥端末について
一応、デレステの曲は全て2本指で処理可能なので、iPhoneでもiPadでも問題ありませんが、適正Lv27以上を目指す場合はiPadじゃないと(私は)キツかったです。
というか、6〜8指でのプレイはiPadじゃないと、画面が小さすぎて無理があります。
最低でもiPad miniのサイズが必要で、できれば9.7インチ or 12インチの方が良いです。

⑦別の音ゲーをプレイする(適正Lv28以上)
デレステの Perfect の判定は、かなりガバガバです。
だからこそ初心者でも気持ちよくプレイできるのですが、Lv28以上だとこのガバガバさが仇になって正確なノート処理できずにGoodやBadになって切れてしまうことが多くなるように感じました。
要するに、デレステのガバガバ判定に慣れてしまっていることがマズイのではないかと。
これを矯正する方法として効果的なのは、デレステよりも判定がキツめの音ゲーに慣れることかなと考えました。
そこで、他の音ゲーを色々と試してみたのですが、スクフェス(ラブライブ)のPerfect判定がデレステよりはシビアで良い感じでした。

Lv27強〜Lv28以上の曲で「何故、GoodやBadになったのか分からない」という場面を多々経験したことがある人は、例えばスクフェスのExpertをall perfectでクリアなどを目標にプレイする練習を取り入れることで、繋がるようになるかもしれません。(これはまだ私が秘密のトワレでフルコンを取るために試行中の段階なので、これで本当に上達できるかは不明)

2017年1月1日日曜日

課金をするでごぜーます

気長にスカウトチケット(3000円払えば無料でSSRをゲットできるという例のアレ)のリセットを待とうと思っていたら、まるで見計らっていたかのように元旦にリセットされたので、速攻で購入しました。

で、誰をスカウトするのか。

候補は12/29の記事で書いた、
①仁奈(ともだちたくさん)
②高森(てづくりのしあわせ)
③及川(はつらつハーヴェスト)
④相葉(束ねた気持ち)
の4人に絞ることができます。

ステータス的には、
vo:5,781, da:3,817, vi:3,169
vo:5,791, da:3,161, vi:3,812
vo:5,816, da:3,866, vi:3,218
vo:5,858, da:3,184, vi:3,845

何も考えずに④相葉で良さそうです。
④相葉は、SRでまずまず使い込んでいたので、育成手間という面でも割とお得です。

育成手間というのは、現時点で付いているファン数の少なさのことで、ポテンシャルを解放するには最低でも50万人(1属性maxするのに必要な最低数)揃えることが必要で、1曲のプレイで得られるファン数は(90万点ぐらいなら)だいたい1000人前後だから、少なくとも500曲プレイする必要があるということになります。(同種キャラクタの配置で減らすこともできますが)

という訳で現時点のファン数の降順で並べると、
②>④>①>③
で、②高森が一番多い。

②高森のSRが判定強化なので、Pa曲のフルコンを狙ったプレイ(粘着プレイ)でよく使っていたから、自然とファン数が多くなった感じのようです。
①仁奈は初期の頃に使い込んでいましたが、R止まりだったため最近は全く出番が無く、③及川に至っては編成した覚えが全くないという感じです。

しかし、スコア狙いであれば、単純にステータスの高さや現時点のファン数だけで見るのは不味くて、なるべく同系統&他キャラクタの特技の発動間隔と被らないようにする事が大事らしい。

そこで、今回の候補の特技を見てみると、
11秒毎、高確率でしばらくの間、PERFECT/GREATのスコア17%アップ
13秒毎、高確率でかなりの間、PERFECT/GREATのスコア17%アップ
6秒毎、中確率でわずかな間、PERFECT/GREATのスコア17%アップ
7秒毎、高確率でわずかな間、PERFECT/GREATのスコア17%アップ
という具合。

それらと、現状最強構成(以下a〜d)の特技発動との相性で見てみます。
a. コンボボーナス / 18%up / 7秒ごと / 高確率 / わずかな間
b. コンボボーナス / 18%up / 6秒ごと / 中確率 / わずかな間
c. スコアアップ / 17%up / 13秒ごと / 高確率 / かなりの間
d. スコアアップ / 17%up / 9秒ごと / 高確率 / 少しの間

コンボボーナス(a, b)はスコアアップと並走できるので考慮不要ですが、スコアアップ(c, d)は被ると無駄打ちになります。
だから、②高森(13秒毎)はcと被るため、候補から除外できます。

他は・・・パッと見ではよく分からない。

そこで、理論値を計算できるサイトで、現状の最強構成でポテンシャル+特技Lvをmaxまで育てた時の流れ星キセキの理論値を計算してみたところ、
①仁奈: 1207663
②高森: 1195138
③及川: 1211879
④相葉: 1207014
という感じでした。

あれ?
ダントツで相葉だと予想していたのですが理論値だと仁奈より低いのか。
高森は想像通り低くなりましたが。
単純にステータスだけ見れば④相葉で、特技相性から見ても④相葉を選ばない理由は無いと思っていたのですが、分からないものですね。実際、多少アピールが低くても特技構成を良い感じに編成した時の方がフルコン時の平均スコアが気持ち高かった気がするので、そういうものなのかも。

そんな感じで、様々なことを総合的に判断した結果、
さば・・・ではなく、仁奈をスカウト。

あとは、今やっているイベントを只管走り続けて、最強編成のファン数をモリモリ上げれば良いでしょう。今回のイベントは1/9迄で、ちょうど私の正月休暇が1/9迄だから、恐らく(初の)2000位以内が狙えるかもしれません。

2000位以内=SSSランクが取れる目安ということで。
SSSの場合、誰でも参加できるイベントと違って参加条件がキツイので、イベントで2000位以内よりはSSSの方が単位時間当たりで見れば楽なはず。(SSSの場合、測定期間が長いので、イベントが短距離走ならSSSはマラソンというイメージ)

今のところ3桁以内で走っています。
3桁以内で走れているのは Flip Frop以来。
その Flip Fropでは2000位以内入賞を逃しましたが。(2021位)


今回はMaster+のフルコンも期間中に狙えると思うので、ハイスコアランキングでも初のトロフィーを狙えるかもしれません。(というか、ハイスコアを狙っていない安全な編成でMasterをフルコンしただけのスコアで、既に銅トロフィーが狙えそうな位置に居るような気がする)

イケると思っていたFlip FropのMaster+のフルコンを取り逃しているので、Master+のフルコンが本当にいけるのかは、結構怪しいところですが。(Flip Fropと違って前座で3曲やらないといけないイベントだから、更に怪しい)

色々な意味で Flip Frop の雪辱を果たす良い機会かもしれません。