霜夜ゆく反省会移植編


  魔都新宿。略。

 

 2021年10月にSwiftUIで発売されたiOS版の、UnityによるAndroid/iOS両対応版が発売されたアプリ(長い)、『霜夜ゆく』および資料集の振り返り記事です。

 →前回と同様、ゲーム内容への言及はほぼなく、デベロップとパブリッシュ関係の話です。



Unityに関して


・M1シリコンの対応

 まずこれから。

 プロセッサなんて普通の人は気にしないし、わたくしもべつにPCに詳しいわけではないのでなかなか気づかなかった落とし穴。


 霜夜iOS版の最終段階であまりにもビルドが時間がかかりすぎたうえに扇風機を当てていないと熱暴走するので、当時使っていたMacbook(2013年だか14年だかのモデル)からM1チップ入りのMac Mini(2020年モデル)に移行しました。プロセッサが変わるなんて単純に性能アップした、くらいのものだと思っていたのですが、実は対応しないアプリがあったりして、OSが変わったくらいの変化だったのでした。


 いちおうRosettaという補助アプリでIntelプロセッサ用のアプリも動かせるようにはなっているとはいえ、完全に対応でなかったりすることもあり、Unity開発においてはそれが足を引っ張ることになりました。具体的にはAndroid用のアプリをビルドすると、実機では起動できないというトラブルが発生。


 単純にM1チップ向けのベータ版Unity入れれば良かったのだけれど、そこまでが長かった。実機でないと確認できない問題だったのもあって、M1チップが原因だと気づくまでものすごく時間がかかった。こういう「何が原因かわからないけどとにかく駄目」という状態はものすごく気持ち悪くて、「わからないからわからない」ならば調べればいいのだけれど、「駄目なはずがないのにわからない」だとどうにもならなくて苛々する。

 今回のトラブルはM1チップ入りのMacがそもそも2020年末からの登場だったので情報がなく、余計に大変でした。


 ちなみにMac Miniはもうひとつ失敗点があって、256GBしかないのでディスク容量がかなりカツカツだったりする。完全開発用なのだが、データが増えてきたりバックアップ取ったりすると意外と容量食うのだよな。512GBにしておけば良かった。



・セーブデータの移植

 iOS版(swiftUI)から両対応版(Unity)には到達したエンディングが移植できるようになっていますが、これも若干大変だった。

 

 簡単に説明すると、霜夜のエンディングデータのセーブは非常に簡単な仕組みになっていて、

[既に見たエンディング名]というセーブデータの中身 = [エンドA、エンドB、エンドE、エンドF]

みたいにエンド名が記載されているだけです。


 セーブする場所自体はswiftでもUnityでもUserDefaultで共通なので簡単に読み出せると思いきや、問題になったのはこの記載方法。

 swiftUIだと配列でセーブできるので文字列配列で保存していたのだけれど、Unityだと配列は取れないので読めない……という言い方をしてもわかりにくいのでプログラミングしない人向けにもうちょっとわかりやすく説明すると、iOS版は、

1行目 - エンドA

2行目 - エンドB

3行目 - エンドE

4行目 - エンドF

というように改行を入れつつエンド名を保存していたのですが、Unityだとこういう改行が入ったデータは読めなかったのです。


 なので両対応版の発売1ヶ月くらい前に急遽、

1行だけ - エンドA+エンドB+エンドE+エンドF

というように改行を入れずに1行で書き下したエンディングセーブデータを作り、保存するようにしたことでUnityへのセーブデータ移植を試みました。


 結果は……とりあえずレビューでもGoogleフォームでも「セーブが消えた😡💢🚗=3」という話は聞かないのでたぶん大丈夫だったもよう。そもそも一回クリアしたらそんなに何回もやるタイプのゲームじゃないので問題が起きる人もいなかったのかもしれない。


 と思いきやこの記事を書いている間にセーブが消えた人を見つけてしまった。うーむ、とはいえこれが正直最善策であったのは間違いない。最初はデータ移植できるとは思わなくて、諦めてもらうことも考えていたくらいなので。


・Prefabの扱い

 これもプログラム的な話。

 ざっと書き下すと、まず今回の移植版はUnityというゲームエンジンで作っています(エゴサしていたら「Unityで作ってたんじゃなかったんだ」というコメントがあったのですが、iOS版を作っていたのはswiftUIというUIフレームワークで、そもそも普通はあんまりゲームを作るためのものではなかったりする)。


 Unityではゲームオブジェクトという画面上に存在するものにいろいろと命令を与えることでゲームを動かすのですが、画面上に存在していないものを新たに生成したいときはPrefabというものを使います。たとえばFPSで銃の弾丸が飛んでいくときは普通prefabみたいなものを使っているはず(もともと弾倉に有限個の弾丸があってそれが実際に飛んでいく、より、撃った瞬間に弾丸が生成される、のほうが簡単なため)。


 霜夜だと、たとえばITEM画面のアイテムリストやタップエフェクトなんかはPrefabを使っていて、ひとつの物資やエフェクトに対してひとつのPrefabを生成しています。

 で、そもそもUnityだとオブジェクトを動かすときに命令を書いたスクリプトを何らかのオブジェクトをアタッチするという形式なのだけれど……だんだん説明するのが面倒になってきたので特にわかりやすい説明もせずに書き下すと、基本的にそのひとつの画面での動きは可能な限りひとつのスクリプトに書き、ひとつのディレクターにアタッチして動かしていたのだけれど、少なくともPrefab動かす場合においてはそのPrefabに対してアタッチして動かしたほうがいろいろと楽だったなー、ということ。説明を放棄した話ですが、次作以後は役に立つと思います。



・アセットの使い方

 Unityはアセットを入れることで他の製作者が作った機能を流用することができるのですが、霜夜だと使っているのはShapes 2Dという図形描画の無料アセットのみだったりする。

 理由としては、

  1. 使い方がよくわからん
  2. 良さげなのは高い
  3. そもそもiOS版の時点でアセットなんかには頼らずにほぼ自力で書いてきたのでUnityでもどうにかなるはず

というわりと後ろ向きな理由。

 Shapes 2Dはswiftだと簡単に描けた楕円とか縁取りがUnityだとできなかったから頑張って使いました。


 次作ではちょこちょこ使っていきたい。なんかいいやつ教えてください。ちなみにTextもuTextだったのでText Mesh Proも使いたい。



ゲームプレイに関して

・あまり要素が増えなかった

 UI等はいろいろと改善し、難易度やプレイ感もちょっと調整し、そもそもswiftUI -> Unityが大きな変化だったのだけれど、そういった視認しにくい細かい変化を除いてわかりやすく増えたといえるようなものといえば、

  • 行動イラストが増えた
  • 物資がちょっとだけ増えた
  • 着せ替えパーツがかなり増えた
  • 宇宙人を倒せるようになった

で、数的には些末すぎる変化。ルートは増えていないし、宇宙人を倒せるようになったのもべつにエンディングが増えているわけではない。


 特にエンディングに関してはちゃんと考えてはいたのだけれど、適当なものが思いつかなかった、というのが正直なところ。

 というのも、→移植録でも書いたのだが、「血清を開拓惑星に届けようとする」という前提を踏まえたうえでルートを新たに開拓するのはけっこう難しい。まったく関係ない要素を(移植録で挙げている、釣りの回数とか)エンディングの脇道として用意するのは簡単なのだけれど、それは本筋からは乖離した要素であって、物語には連らない。


 本作でメインルートからもっとも外れるとみなせるのはおそらくタンポポルートなのだけれど、これはアプローチを変えているだけで「血清を開拓惑星に届けようとする」というのは一致している。

 だからタンポポルートみたいに特殊な行為で血清を届けようとする(たとえば「重量問題はどうにもできないけど、そもそも船の速度がしっかり出せればいいだけだから宇宙空間で漕いで加速するぜ!」とか。少女はできそうだな)のはアリなのだが、こうしようとすると予定外の処理が増えてくるのが気持ち良くない。たとえば上に例で挙げた「真空空間で漕ぐ」だと、漕ぐ道具とか装備とかを単純に整えるのだけではなく、「漕ぐ」という概念をサジェストしなくてはならなくて、サジェストすること自体はヘックス提案でできるにしてもそこにたどり着くまでのアプローチが難しかったりする。


 タンポポルートのアプローチは、そもそも「棄てる」という本作のメイン行動がベースになっており、また、もともとわたしがインスパイア元である『冷たい方程式』を読んだときに思いついた解法のひとつなので、ほかにも思いついてくれる人がいるはず、という部分もあったが、あまりにも奇想天外(というかなんだよ真空を漕ぐって)だとその流れが綺麗ではないわけで、結局それを処理できるようなエンディングが思いつかなかったために、エンディング数は増やさなかった。


 ちなみにすごく余談なのですが、タンポポルートがタンポポなのは、ロバート・ヤングのSF短編『たんぽぽ娘』が元ネタだったりします。もともとはエンディング名はSFタイトルにしようとしていたので、花になってもうまく噛み合った。




テストプレイに関して

・Android版の内部テスト

 iOS側は前回と同様にTestFlightを使って匿名で簡単にできたのだが、Android側はうまい方法が存在せず、メールアドレスを登録してもらって内部テスト扱いにする、という形を取った。


 というのもAndroid版のGoogle Playはテストの種類として、

  • 内部テスト
  • クローズドテスト
  • オープンテスト

とあるのだけれど、クローズドとオープンテストは有料アプリだと購入しないとできない( https://support.google.com/googleplay/android-developer/answer/9845334?hl=ja )らしい。まじで? どうしているのAndroid開発者。


 今回は移植版なのでAndroidでテストしなくちゃいけないわけで、苦肉の策でメールアドレス登録してもらって内部テストという方式にしたのだけれど、今のご時世個人情報うんぬんとかであんまりやりたくない方式ではある。次回どうしよ。テストはiOS版のみにするという手はあるのだが。



・Googleフォームのミス

 内部テストの話に関連するが、最初Googleフォームのリンクを貼ったときに、編集ページのリンクを貼ってしまったために回答者にGoogleへのログインを要求される状態になってしまった。


 また、Googleフォームで回答を個々で見る方法を知らずに途中で編集を挟んだために、一部フォームでの回答が消えたりしてしまった。


 このへんは一回学習すれば忘れないことなので次回に活かせるだろう。




販売について

・最初にレビューしておけば良かった

 Androidは無法地帯だと聞いていたので審査とかないと思いきや、いまは普通にあるらしい。ひゃっはー! iOS版より時間かかったぜー! 単純だけど複雑だぜー!



・Android版の売り上げはいまひとつ

 Google Play Storeだと日別グラフとか出ないので大雑把に「iOS版」「両対応版iOS」「両対応Android」「資料集」で分けるとこんなかんじ。



 なぜかiOS版も改めて売れた……のだけれど、Android版の売り上げはiOS版当時に比べるといまひとつ。iOSは初期に売れてAndroidはジワ売れする、という伝説があるのでそうなってくれればいいのだが。



・RTキャンペーンの失敗

 コマーシャル目的で試みたもの。該当ツイートは以下。締め切り時点でたしか引用も合わせて120RTくらいだったはず。



 メモがわりにやり方書いておくと、該当ツイートをPickawで登録してRTユーザーページをHTMLで落としてpythonで読んだ。

 ただこれ、Pickawでの出力が有料ユーザーでないと1ページあたり20人くらいしか出ないのでめちゃくちゃ増えると面倒臭い。何か良い方法を考えねば……という以前にRT数がまったく伸びなかったので改善せねば。


 ほぼ現金に近いAmazonギフト券でキャンペーンやったにもかかわらず人数が伸びなかった最大の失敗だったのは、画像を載せなかったことだと推測している。

 YoutubeのTwitterカードが出るからいいや、と思っていたのだが、カードの数が多すぎるせいか詳細を見ないと表示されないので目立たず、RTキャンペーンであることも認識しづらい状態だった。


 個人的な考えとしては、まったく霜夜プレイしたことがない人でも応募してRT数稼いでもらってもぜんぜん良くて、というのは単純にツイートのRT数が増えると優先度が高いツイートとみなされるはずだし、普通のプレイヤーでRTする人もRTしやすくなるはずなので。そういう点から鑑みて、RTキャンペーンに参加するだけの人がもっと参加してもらいやすい土壌を作るのに失敗した。ハッシュタグもそれ系のものがあるのかもしれない。下調べが足りない。


 また、可能だったら販売からちょっと経ってからやったほうが良かったかな、と思わないでもない。そのほうがどれくらい効果があったかわかりやすいので。

 とはいえマーケティング的にはスタートダッシュかけるのが(前回のiOS版の売り上げ見るに)正しいわけで、実験的な行為をどこまで許容するか、なのだが。


 余談なのだけれど、今回のキャンペーンで「もともとのフォロー・フォロワーの関係で普通に会話をする相手に当たっちゃったら出来レースに見えやしないだろうか」とちょっと心配していました。




資料集に関して

・LaTeXでの制作失敗

 資料集は3章がデータ関連だったので、少なくともこの章に関してはLaTeXで作ろうとしていた……のだがうまくいかなかった。特にフォント周りがよくわからん。

 研究室時代にLaTeXをものすごく奨励していた人がいたのだけれど、これ論文書くには良いだろうけど、それ以外のものを作ろうとすると融通効かなすぎて辛いというのが正直な感想である。


 最終的には全部手打ちでWordで作ることになって、大量の誤字脱字データ欠損を生み出すことになってしまったので、次回はもっと良い方法を取りたいのだが、なんか良いツールないだろうか。


・BOOTHでの販売

 当初はSteamのようにApp StoreかGoogle Play Storeで付属品として売れるのではないか、と思っていたけどそんな機能はなかったぜ!


 なのでとりあえず手数料が安いBOOTHに登録して売ることに。

 ついでにアンケートで「BOOTH以外で登録してほしい場所はあるか?」とアンケートを取った(なぜか回答にBOOTHがある)ところ、意外と高かったのがDL Site。お好きですね。いやえっちなのも売ってるのか。


 実はBOOTHでの販売でいちばんありがたいのは、販売数が表示されないことだったりする。資料集ってそんなに売れるもんではないから、実販売数は伏せたい(アプリも伏せてるけど)なのだけど、DL Siteは出ちゃうのよね。今回はあくまで試験的なアンケートだかあらどっちにしろ出さないけど、うーむ次回はどうしよう。




 というわけで霜夜ゆく、移植版の振り返りでした。


 ちゃんと通過していれば5月のIndie Live Expoに出ている予定なのですが、一度動画ファイルの解像度が間違っていた連絡が来て修正したので、その後ちゃんと通ったかどうかよくわからぬ。通ってても抽選だったら駄目かもしれんけど。

0 件のコメント:

Powered by Blogger.