2013年10月6日日曜日

10月6日

Hi, Tom!
今日は、トムの日ですね・・・いや、めでたい。
少し、疲れているのかもしれない。

そろそろ、ガス抜きが必要かもと思い始めてます。
東方VGSについては、ちゃんと終わらせるつもりですが。
しかし、モチベーションを保ち続けることが出来るか微妙かも…
まぁ、そこは何とかします。

創作活動とは、楽しいモノです。
楽しいだけに恐ろしい。

如何に労力を掛けようとも、対価(評価)が得られるものではありません。
才能(運も含む)だけがモノをいう世界です。
ただ、創作の第一の目的は、対価を得る事ではなく、「創ること」だったりします。
創る人にとって、対価は割とどうでも良い事で、第一の目的は、自己満足を得る事です(多分)。
その理屈が正しければ、創作とは、究極的には自慰行為でなければなりません。
それで対価が得られるというのは、ものスゴイ奇跡です。

そういった意味では、創作はビジネスと相性が悪い。
黎明期のゲームと違い、昨今のゲームがつまらなく感じる最大の原因はそこにあります。
VGSのマニュアル(概要)では、ゲームがつまらなくなった原因を「ハードの不要な進化の結果」と書いたような気がしますが、本質的にはゲーム作りがビジネスになってしまった為です。「ハードの不要な進化の結果」という理屈は、実は私自身が結構眉唾物だと思っています・・・それは単に、表面上の事情ではないかと(著者の私自身がそんな事を言うのは如何なものかw)。

東方VGSは割と好評ですが、これは、私に対する評価ではなく、上海アリス幻樂団への評価が99%で、私に対する評価は息を吹けば消し飛ぶレベルです。第一、音楽に関して言えば、私自身は完全に専門外のシロートですし。

私に対する評価というのは、NOKOGI Riderに対して付けられている星の数のみであろうと。東方VGSの評価が上がれば上がるほど、それを実感し、ナーバスな気分になるという悪循環。それでもクオリティを落とすつもりはないし、しっかり完結させるつもりです。ある程度、そういう結果になることを理解した上で始めた側面もありますし。(だから、東方VGSから「操作性改善」という名目でSUZUKI PLANボタンを躊躇なく消したり出来る訳です)

欲を言えば、
「無料のLite版だけでも良いからもうちょっと伸びてくれたらなぁ」
とか、思ったりして…

それは言わない約束だよ、おとっつぁん!

2013年9月16日月曜日

作品相互紹介の副次的効果に関する検証

私が参加しているGoogle+のコミュニティで、アプリの作者同士が、互いの作品を紹介し合う試みをやっています。前回の記事(Hello Algorithmの紹介)前々回の記事(Smart Shelfの紹介)は、その一環で作成した記事になります。この試みの趣旨は、作者が相互の作品を触れあうことで理解を深め合うというものです。

私の方からは、東方BGM on VGS(東方VGS)の紹介をお願いしました。
そして、それぞれの作者さんに以下の紹介記事を書いていただきました。
http://nabeyang.hatenablog.com/entry/2013/09/14/103738 (iPhone版)
http://bukowski19200816.blogspot.jp/2013/09/blog-post_15.html (Android版)
これにより、私のSmart ShelfとHello Algorithmへの理解は深まったと思います。

なお、この試みは、他作者さんが作った作品をブログ等で公表する形態を採っているので、互いの作品のインプレッション機会が増加する副次的な効果も期待できると思います。そこで、その副次的な効果が、具体的にどの程度だったか、定量的に検証してみました。

まず、Android版の東方VGSの1日当たりのダウンロード数には、下図のようになりました。
Android版の東方VGSの1日あたりのダウンロード数は、だいたい40~50本前後ですが、この試みを行った日(9/14)は、142本のダウンロードがありました。

続いて、iPhone版は下図のようになりました。
なお、上図は東方VGSだけでなく、私が公開している全てのiPhoneアプリの合計ユニット変化数(インストール数+アンインストール数)です。東方VGS以外は誤差程度(orz)なので、だいたい東方VGSのユニット変化数だと思って頂いて問題ありません。こちらも、前日200ユニット(だいたい100インストールぐらい)だったものが一気に360ユニット(だいたい200インストールぐらい)に増えました。

Android/iPhone共に、普段と比べて+100本程度のインストールがあった計算になります。

2013年9月14日土曜日

【作品紹介(2)】Hello Algorithm

Google+のコミュニティーで、「アプリの作者同士で作品を紹介し合いましょう」という趣旨のイベントがあり、それに参加してみることにしました。本稿は、その第二弾として、Hello Algorithmというアプリを紹介します。

(1)紹介

Hello Algorithmは、数学ガール-乱択アルゴリズム-という書籍内で登場する疑似プログラミング言語のシミュレータです。
数字配列をソートするプログラムを実行したところ(初期画面)

山ガール、杜ガール、仏像ガール、電影ガール・・・そして、数学ガール。
ガールって付くだけで、何やら甘美な響きがします。
キャッキャウフフみたいな。

この数学ガールという書籍は、簡素な数式からフェルマーの最終定理まで、数学に関する色々なネタを取り扱ったシリーズ物の書籍のようです。フェルマーの最終定理の巻は、ちょっと賛否が多いようですが、恐らく興味を持つための導入書としては手ごろそうな内容だろうと思います。ちなみに、私はこの本を読んだことはありません。ただ、少女を題する書籍は、導入書的な意味合いのものが多いので、恐らくコレもその類かなと。

そして、このアプリは、数学ガール第4弾「乱択アルゴリズム」内で用いている独自プログラム言語のシミュレータのようです。数学ガールを読みながら、実際にHello Algorithmでプログラムを書き、アルゴリズムの流れを確認してみると面白いと思います。ちなみに、このアプリでは、デバッガーのようにステップ実行もできるので、プログラムの動きを視覚的に分かり易く確認することができると思います。

このアプリはWeb版とChromeアプリ版があります。
Chromeアプリ版の方は、オフラインでも使えます。

言語仕様としては、各種演算(四則演算、論理演算、比較)、ループ、関数などが実装できるようです。余談ですが、個人的には、入れ替え演算子(変数a,bの内容を入れ替える)というのがある点が珍しかったかも。普通のプログラム言語には、有りそうで無かったりします。

例えば、C言語で変数a,bの内容を入れ替える場合、
c=a;
a=b;
b=c;
みたいな感じ(ワーク変数cが必要)になったりします。
最近のプログラム言語だと普通なのかな?

(2)雑談

私は、中学時代にプログラミングの世界に踏み込んで以来、学校の勉強を殆どやりませんでした。それでも、成績は上位の方だったと思います(中学までは)。世界史とか化学とか「知らなければ解けない系」の学問は必然的に苦手でしたが、数学は、例え公式を知らなくとも勘だけで解けます。だから、好きでした。しかし、その「好き」という感情は、純粋な数学愛ではないですね。「アッシー君」や「都合が良い女」に対する「好き」という感情みたいなものです。つまり、そこに愛はありません。仮に有るとすれば、それは捻じ曲がった愛です。

捻じ曲がった愛の結末は、得てして悲劇になります。

高校レベルの数学になると、勘だけで戦うのは厳しくなります。
良い成績をとるには、勉強をしなければなりません。
しかし、それでも私は、「勉強如きの為にプログラミングをする時間を削るのは無意味だ」と考え、従来通り、一切勉強をせず、勘だけで問題を解き続けました。その結果、成績はみるみる落ち、中学時代にトップクラスだった成績が、高校時代には下から数えた方が早い、所謂「落ちこぼれ組」になりました。幸い、テストで赤点を取ることは一度もありませんでしたが、常にそのギリギリのラインでした。

余談ですが、高校生の時、進路希望の調査みたいなものがあり、「コンピュータ系の専門学校に行く」と宣言した時、担任の教師(高学歴)から鼻で笑われ、「お前なんかが行っても、ついていけないだろ?テラワロスw」的なことを言われました。その後、私は専門学校へ進学して、首席で卒業。

ぶっちゃけてしまえば、高校時代の勉強が、社会に出てから役立つことは99%無いです。生きていくのに必要な知識は、義務教育だけで十分得られます。ただ、重要なのは、勉強している内容そのものではなく、学ぶことに対する姿勢です。

人は、学ばなければ成長しません。

それは、学問に限った話しではなく、絵画、音楽、演劇、スポーツ、仕事など色々な分野で共通することだと思います。そして、学ぶために必要なことは、恐らく愛です。当然、先述した捻じ曲がった愛ではなく、純粋な意味で「好き」になる必要があります。

この数学ガールという書籍は、数学を好きになるための良い入口になるかもしれません。
そして、乱択アルゴリズムを読み進める時は、この作品を使ってみてはどうでしょうか。

(3)作品情報

・対応機種: Chrome / ブラウザ
・Chrome版: https://chrome.google.com/webstore/detail/hello-algorithm/pdpjhjlfphfhjofjigmiiphifbndpgci
・ブラウザ版: http://hello-algorithm.com
・仕様: http://w.livedoor.jp/nabeyang/d/HelloAlgorithm
・作者: Noriaki Watanabeさん(https://plus.google.com/u/0/115305041286184037742/about

2013年9月13日金曜日

【作品紹介(1)】Smart Shelf

Google+のコミュニティーで、「アプリの作者同士で作品を紹介し合いましょう」という趣旨のイベントがあり、それに参加してみることにしました。本稿は、その第一弾ということで、Smart Shelfというアプリを紹介します。

(1)紹介

Smart Shelfは、本の情報を管理できるアプリです。

(動画)

動画でチラッと紹介してますが、バーコードから本の情報を登録できます。
バーコード入力は、若干コツが要りますが、コツを掴めればスムースにできると思います。
バーコード入力してる所
登録できる項目は、ジャンル、シリーズ、タイトル、作者、出版社、価格、発売日などの基本項目に加えて、他にも評価やコメントなど。基本項目については、だいたいバーコードから拾えます。

(2)雑談

私は昔、結構な読書家だったと思います。

主に、岩波の哲学書(文庫版)を読むのが好きでした。有名どころでは、アリストテレスの形而上学とか、モンテスキューの法の精神とか。一番最近読んだ本は、新約聖書(※岩波じゃなくて、なんかそれっぽい感じの所が出版している日英対訳のTEV)です。ちなみに私はキリシタンではありません。(念の為)

読書家にとって、読んできた本というのは、言わば戦歴みたいなものです。

しかし、悲しいかな、人間の記憶力(私の記憶力)は、花のように儚いらしく、昔読んだことがある本の全てを記憶に留めることはできません。そもそも、全てを記憶に留める必要は無くて、必要な情報だけを吸収すれば良いと思いますが。なお、何が自分にとって必要なのかは、全部読んでみないと分からないので、当然ながら全部読む必要がありますが。必要な所だけ読めばOKならどれほど楽チンか・・・少し話しが逸れましたが、要するに戦歴は然して重要ではありません。必要なモノは、望まなくても己の血となり肉となっている筈で、忘れていくものは、必要がないから忘れていく・・・ただ、それだけのことです。

しかし、それでもやはり戦歴を残しておきたいものです。
その為、大抵の読書家は、読書ノートなるものを記録していると思います。
私も記録していました。

読書ノートは、手書きのA6サイズのノートに、1ページ/1冊ぐらいの文量で書きます。書く内容は、その本に関することならなんでも自由です。例えば、「東京へ向かう汽車の車中にて読んだが、窓から見えるサクラが綺麗だった」とか、本の内容と直接的に関係ない内容でもOKです。要するに、本を読み終わった時に記す日記帳みたいなものです。過去に日記帳を付けようとして、3日坊主で辞めてしまった人は数多く居ると思います。手書きで読書ノートを記すことは、そんな方々(日記を書きたい意思はあるが続かない方々)にオススメです。

日記が続かない最大の理由は、「書くネタが無い」からです。
読書ノートなら目的と記述すべきタイミングがハッキリしているので、長続きすると思います。
もっとも、私の読書ノートは、最近は読書をする時間が無くて、埃を被りつつありますが。

さて、「手書き読書ノートのすゝめ」みたいになってしまった感が否めないな・・・

Smart Shelfなら、簡単な操作(バーコード入力)で本の正確な情報を記憶できるので、索引的なものを記録する用途で使うと便利だと思います。なので、読書ノートは手書き派だょ?という古風な方も、一度使ってみてはどうでしょうか。

(3)作品情報
・対応機種: Android 2.3.3以降の端末
・作品URL: https://play.google.com/store/apps/details?id=info.pulps.ss
・作者: Noz Oさん(https://plus.google.com/u/0/102903912989809953917/about

2013年8月24日土曜日

iPhoneでバックグラウンド動作させる場合のTIPS

久々に技術ネタを書きます。
今回は、iPhoneアプリでのバックグラウンド動作について。

1. 概要

元々(iOS3の頃)のiOSは、サードパーティ製のアプリ(一般アプリ)のバックグラウンド動作は出来ない仕様でした。しかし、iOS4でバックグラウンド動作が出来るように仕様変更されました。

ただし、バックグラウンド動作は、特定の種類のアプリにしか許可されていません。
バックグラウンド動作をしても良いアプリは、次のもののみです。

  • 音楽プレーヤーのように、バックグラウンドで音声を再生するアプリケーション
  • ナビゲーションのように、常に位置情報を知らせるアプリケーション
  • VoIP(Voice over Internet Protocol)対応アプリケーション
  • 最新号をダウンロードして処理する必要があるNewsstandアプリケーション
  • 外付けアクセサリから定期的に更新情報を受け取るアプリケーション

詳しくは、Appleが発行している「iOSアプリケーションプログラミングガイド」の「バックグラウンド実行とマルチタスク」というセクション(65ページあたり)に書かれています。上記以外の種類のバックグラウンド動作をするアプリだと、Appleの審査でリジェクトされると思います。

2. 基本的な実装方法

plistに「Required Background Mode」を追加して、オーディオアプリならitem0に「App plays audio」を設定します。あとは、デリゲートで起動完了時に、オーディオセッションのカテゴリをプレイバックに設定する必要があります。

以下の記事あたりが分かり易いと思います。
http://d.hatena.ne.jp/KZR/20100920/p1

一般的なアプリなら、この実装をするだけでOKです。ですが、OpenALを用いているプログラムの場合、その他にも色々な改造が必要です。本項の情報なら、割と沢山出回っていたのですが、その点について解説したTIPSが見当たらなかったので、若干苦労しました。以下、OpenALを用いているプログラムをバックグラウンド対応する為に必要なTIPSについて記します。

3. バッファリング間隔の変更

バックグラウンド動作時のバッファリング間隔を修正する必要があるかもしれません。iOSでは、バッファリング間隔の目安として、CD品質(44100Hz、ステレオ、16bit)の音声であれば500ms程度※としています。
※Appleが発行している「オーディオセッションプログラミングガイド」の「最適なオーディオハードウェア設定の指定」(40ページあたり)を参照

SUZUKI PLAN - Video Game System(VGS)の音声品質は、22050Hz、モノラル、16bitなので、125ms辺りが目安値になります。しかし、バッファリング間隔をそんなに長くしてしまうと、効果音の再生処理の遅延が酷くなってしまいます。そのため、VGSでは通常(フォアグラウンド動作時)は、バッファリング間隔を50msにしています。フォアグラウンド動作であれば50msでも問題無く動いてくれていましたが、スリープボタンを押すと、音飛びが発生してしまいます。どうやらiOSは、スリープ時に(電池消費を抑える為に)プロセスに対して割り当てるプライオリティを、意図的に低く設定しているようです。

そこで、バッファリング間隔を
・フォアグラウンド時は50ms
・バックグラウンド移行後は500ms
という具合に、状態に応じて切り替える制御を実装する必要があります。

4. メインルーチンの別スレッド化

私のアプリの場合、メインルーチンは、CADisplayLink(垂直同期)の仕組みを使って1秒間に60回呼び出される形になっています。しかし、バックグラウンド移行後は(アプリに対して垂直同期時に割り込み通知をする必要が無いため)それが呼び出されなくなってしまいます。そこで、バックグラウンド移行後は、メインルーチンの呼び出しを別スレッドで行うようにする必要があります。

5. デバイスロスト(割り込み)の対処

従来の私のiPhoneアプリは、ホーム画面に戻った場合、プロセスを停止するようにしていました。しかし、バックグラウンドでの動作(※サスペンドを含む)を想定する場合、OpenALのデバイスロストを検知した時の処理を実装しなければなりません。OpenALのデバイスロストが発生すると、割り込みにより、予め定義したコールバック処理が実行される仕組みになっています。そのコールバック処理で、適切な復旧処理を行う必要があります。

ちなみに、コールバックが未登録の場合、デバイスロストが発生しても、特にエラーが発生せずに処理を続行します。しかし、その状態(適切な復旧処理を行っていない状態)では、音が鳴らなくなってしまうので、注意する必要があります。

なお、割り込みは、競合するオーディオデバイスを使用するアプリを起動した時に発生します。分かり易い例としては、アプリが動作中に電話が掛ってきた時とか。


こんな感じです。

東方VGSをバックグラウンド再生に対応させるため、これだけのことをやりました。割と大変でした・・・大変だったけど、結構沢山の方から要望を頂いたので、速めに対応した方が良さそうだということで、予定外のバージョンアップで対応することにしました。(本当は、妖々夢の全曲が揃ってからアップするつもりでしたが、それでは遅すぎるだろうと思ったので)

今回の敗因は、「iPhoneではバックグラウンド動作はできない」と私が勝手に思い込んでいたことかな。いわゆる「だろう設計」ってヤツです。Appleの設計思想は、そんなにコロコロ変わらないだろうと勝手にイメージしていましたが、どうやら、そうでもなかったようです。

2013年8月23日金曜日

NOKOGI Rider 祝100+&1周年

何気なく、Google PlayでNOKOGI Riderをチェックしていて、重大なことに気づきました。
Google Playの様子(8/23撮影)

お分かりいただけたでしょうか。

ダウンロード数が「100+件」になりました!!!

感無量です。
あれっ?
嬉しい筈なのに涙が・・・
ご購入いただいた方は、本当にありがとうございます。

ついでに、製品版のNOKOGI Riderをリリース開始してからもうすぐで1年になります。
「サクラを一切使わず1年で100本売る」
という販売目標(KPI)を立ててやっていたので、ギリギリ達成することができました。
Invader Block 2の時は、職場の知り合い数名に購入していただいたりしたのですが、NOKOGI Riderについては本物の「実力only」で勝負したかったので、Lite版を勧めることはあっても、製品版の購入は催促しないようにしました。

「1年で100本」と聞くと、とてもささやかな数字に見えるかもしれません。
ですが、ほぼ無名の個人が作ったアプリを100本売ることは、相当大変なことです。
CAVEの怒首領蜂大復活ですら5,000~10,000本しか売れていないし、パズドラが大ヒットしているガンホーも、実は有料アプリを出しているのですが5,000~10,000本しか売れていません。

無料(広告モデルとか)であれば100本なら割と簡単にクリアできますが、無料と有料の間の壁は、余りにも大きすぎます。「iPhoneなら」と、思っていた時期が私にもありましたが、iPhoneだったとしても大変なことです。(一昔前なら良かったかもしれませんが)

ちなみに、販売数の国別の内訳としては、次の通りでした。
国別の内訳
日本:外国=4:6という感じですね。
概ね想定通りの割合です。

私は、元々「スマホで作るなら、グローバルで売れるゲームを作りたい」と考えていました。グローバル路線でいくことについては、もしかすると、賛否両論があるかもしれません。日本人なら日本人向けに特化したゲームを作った方が、良いのは確かです。ただ、ロケールフリーなゲームを作るということは、言語による柵を超えることを意味します。私は常々、ゲームはシンプルでなければならないと考えていたので、グローバル路線を意識したことは、私の作品にはプラスの作用をしたと思います。

さて、次の目標ですが、「このやり方で100本売れたのなら、1万本は売れるんじゃない?」と思っていたりするのですが、それはまだまだ先のことになりそうです。地道なブランディングを推進して、「SUZUKI PLANのゲームなら買っても良い」と思っていただけるようになれば、恐らく達成できると思いますが、道はまだまだ遠い。っていうか、無料のLite版ですら10,000本に届いていないですし...(Lite版の総DL数は、現時点で6,000本ぐらい)

2013年8月4日日曜日

iPhone/Android両対応の有料アプリの売り方に関する考察

私は、SUZUKI PLAN - Video Game System(VGS)を用いることで、iPhoneとAndroid両対応のアプリを効率的に開発することができます。ですが、そのポテンシャルの活かしたマーケティング方法について、あまり考察せず、「完成したら可能な限り早くリリース」というスタンスでやってきました。ただ、ちょっとばかり考えてみると、どうもそのやり方はあまり宜しくないかもしれない…ということで、記事に纏めてみることにしました。

(1)マーケット特性
GooglePlayとAppStoreの特性の違いを、下表に纏めてみました。
比較項目
GooglePlay
AppStore
申請から公開迄に掛かる期間 1~2時間ほど 1~2週間ほど
新着インプレッション機会 一定の人気が有る場合に限る 必ず有る
ランキング変動スパン 長め 短め
価格変更 ○有料→無料
×無料→有料
○有料→無料
○無料→有料

(2)申請から公開迄に掛かる期間
GooglePlayの場合、申請したアプリについて、人手による審査は無いため、申請すればすぐに公開されますが、AppStoreの場合、Appleによる審査に1~2週間程度の期間を要します。そのため、AndroidとiPhone両方のアプリが同時に完成でき、可能な限り早く申請を行った場合、公開される順序は必ずGooglePlay→AppStoreの順序になります。

(3)新着インプレッション機会
GooglePlayとAppStoreの場合、新着アプリのインプレッション機会に大きな違いがあります。GooglePlayの場合、公開から1ヶ月以内の人気のあるアプリに限り、「新着ランキング」に載ることができますが、AppStoreの場合、全てのアプリに「新着アプリ」への掲載機会があります。
つまり、以下のようなことが言えます。
・GooglePlay:プロモーション(広告、SEO等々)をしなければ、殆どダウンロードされない。
・AppStore:何もしなくても数日間はダウンロードして貰える。

(4)ランキング変動スパン
人気ランキング(※新着に限らない)は、GooglePlayの場合、変動が少ないのに対して、AppStoreは非常にコロコロ変動します。この違いにより、GooglePlayでは、一度人気を取ったアプリは長期間ランキング掲載されるのに対して、AppStoreでは、人気が長続きすることは無いという特徴があります。換言すれば、GooglePlayでは、ランキング上位へ食い込むことが極めて困難であるのに対して、AppStoreでは、誰でもランキング上位へ食い込むチャンスがあると言えます。

(5)価格変更
AppStoreとGooglePlayの最大の違いは、無料アプリの有料化ができるか否かです。
AppStoreならできますが、GooglePlayではそれができません。
なお、有料アプリの無料化ならどちらでもできますが、それは基本的に禁じ手です。有料時に買っていただいた方に申し訳ないので、「お客様第一主義」という観点では、絶対にやってはいけないことだと思います。(個人的には、値下げ販売も同様だと思っています…割と横行してますが)

(6)考察
上述の事情を考察した結果、最も理想的な販売戦術は、次のような形だと思います。
①最初に、iPhone版を無料(広告すら無しの完全無料)でリリースする
②一定期間経過後、有料化する
③Android版を最初から有料でリリースする
④広告出稿等のプロモーションを必要に応じて行う
上記①は、アプリの内容について評価をして頂くためのものです。一般ユーザの声が聞けるので、プロモコードを発行するよりも遥かに有益だと思います。そして、評価されればランキング上位に食い込み、更なる評価機会を得ることができます。
その後(一定の評価が得られてから)、有料化(②)を行います。「有料→無料は禁じて」だと先述しましたが、「無料→有料」ならOKだと思います。ただし、「有料の別バージョンをリリースして、無料版を非公開にする」という方式はNGです。実際、そういうやり方をしているアプリを見た事があるのですが、☆1でボロクソに叩かれまくっていました。少し考えれば、そんなことは誰でも分かるのに、何故そんなことをしたのか不思議です。無料で提供することで得られなかった収益は、「プロモーション費用」だと割り切って考えるべきだと思います。
そして、iPhone版での一定の成功を待ってから、Android版をリリース(③)します。そうすれば、口コミ(ブログ等)でアプリの情報が広まった状態になっていると期待できるので、ランキング上位へ食い込むことが難しいAndroidでも、そのチャンスが訪れるかもしれません。
また、iPhone版で得た収益から、広告費用を捻出できるかもしれません。Android版の方が、売るのが難しい分、売れれば大きい(World wideでの数がiPhoneよりも遥かに多い)ので、iPhone版はテストマーケティング、Android版で本気のマーケティングを仕掛けるやり方の方が、売り上げが大きくなるのではないかと想定しています。なので、必要に応じてAndroid版の広告出稿など(④)を行います。

次(SUPER REAL RACING(仮))からは、この作戦で行ってみるか。
作り手サイドの思考としては、作ったらなるべく早くリリースしたいのですが...
ただ、そこは、グッと堪えた方が、得策かもしれません。

合理的ではないものを作りたい

ここ最近、実機版の東方VGSの開発が忙しくて、東方VGSの曲追加が滞っています。 東方VGS(実機版)のデザインを作りながら検討中。基本レトロUIベースですがシークバーはモダンに倣おうかな…とか pic.twitter.com/YOYprlDsYD — SUZUKI PLAN (...