スポンサーサイト

--/--/--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
comment (-) @ スポンサー広告

[ダウンロード数] おっさんと川公開から1週間

2015/08/31
ゲーム「おっさんと川」を公開してから1週間が経過したので、
ここまでの経過をまとめておきたい。

まず私のiPhoneゲーム処女作の前作「ほるほる」は、
公開時には一切告知せず、1週間の経過を見守ったが、
その際は、1週間のDL数は40程度だったかと思う。
その後、DL数が低下し、合計DL件数100くらいで頭打ちした。

そして第二作の今回だが、
公開初日にダウンロードは40ほど、
一週間の合計は270件となった。

前回とやったことの大きな違いでは、
前日から公開をサイトなどで告知したことと、
Twitterツイート機能を実装したことによる効果などだが、
それらが大きかったようだ。

今回も、早い段階で2つほどのレビューサイトで取り上げて下さっていたのを発見。
前回は、私のブランドで取り上げて下さっているような感じだったが、
今回は、ゲームの内容のシュールさで目に留まってもらえたようである。

突っ込み所のあるコンテンツが取り上げられ易いという傾向は、
SNSにおけるニュースという形態が充実・認知されてきた昨今のネットの特徴の1つだとは思う。

しかし、今のところ、数字を見る限りは、
それらのレビューサイトからの実際のDL数は5~30ほど。
ありがたいことだし、大変なモチベーションにもなるが、
これは、小説やCDを出した時に、そこそこのニュースサイトに掲載されても、実際の売り上げにはさほど貢献されない、というのと似たようなことかもしれない。
でも、とてもありがたいことなので、数字が伴わなくても嬉しい。


二作目は、一作目よりもずっとDL数が伸びたとは言え、
一週間掛かってようやく300近く。
通常のPCゲームのネット公開レベルには、まだまだ程遠い。
せめて目先、通常のネット公開のPCゲームくらいの数字を超えるのを、目標としたい所ではある。

閲覧数だけに絞っても、下らない数分動画を投稿した方がまだ上をいくレベル。
基本的には、Apple App storeは、無名のゲームに対するアプローチは皆無。
一個人が公開しても、ただのダウンロードツールとしての意味しかないという方が近い。
そのため、今回は無意味だろうと思いSEO対策などは考慮しなかった。

ちなみに前作では、閲覧数500に対し、DL数100というような感じで、
ダウンロード率は20%だった。
(ダウンロード率が20%もあるということが、App store自体に、広く認識させる能力が乏しいことの証拠とも言える。
 つまり逆を言えば、最初からダウンロードするつもりで検索した人が多い、ということになる)

ただ、今回はその閲覧数に、少し不思議なことが起きた。

今回は、閲覧数が一週間で既に2000を超えており、
DL数を300とすると、ダウンロード率は前作よりは低めにはなるが、
その閲覧数の多さの原因は、
実は、私の告知でも、Twitterでも、レビューサイトでも、SEOでもなく、
全然別の所にあった。

それは、中国である。

この閲覧数の内訳は、40%が中国からのアクセスによるもので、
その数字に驚いた。
前作では全く見られなかったか現象だ。
ちなみに前作は、中国からの閲覧数は一桁しかない。

ではなぜ今回、こんなにも中国から閲覧されたのかと言えば、
思い当たる節が1つある。

それは、アプリをiPadにも対応させたこと。

どういう理屈かは分からないが、iPad対応にさせると、何故か中国の検索に多く察知されるのかもしれない。
ちなみそのプラットフォームは、iPhoneが50%、iPad50%と、日本に比べれば確かにiPadが多いが、iPhoneだって50%はある。
もしかしたら、そういうシェア構造が理由となって、中国では最初からuniversalアプリしか検知しないような仕組みが導入されているのかも??

ただ、閲覧数がいくら伸びた所で、その中国からのDL率は 3%ほどと、あまりDLされていない。
まあ日本語だから当然だろう。
しかも、実際にアクティブとなったケースでも、広告表示はされているようだが収益は0。
中国からのアクセスは、閲覧数を稼げるというだけで、どうやらそれ以外のメリットはないようだ。
まあApp storeでの順位を少しでも上げるのには貢献しているのかもしれないが、
上位に食い込んでもいない限り、底辺で少し順位が変動しても、無意味と言えば無意味かもしれない。


あと、今作では自前でネットランキングを実装したため、
DLしたユーザーが、実際にどれくらい遊んでくれたかが、そのランキングに登録されたかどうかで
ある程度予想できた。

この一週間でランキングに登録されたユーザー数は90人程度。
この数字は地味にリアルで、正直辛い。

即ち、まとめると、
今作は一週間で、

アクセス 約2000(内国内は約1200)
DL 約300
実際に遊ばれた数 約100

となる。
一ヶ月丸々を注ぎ込んだけど、実際には、100人にしか遊ばれていない……、ということに。

しかし、逆をかえせば、その100人はとても貴重な100人。
その100人を励みに、次もがんばりたい。


以上が、二作目公開後一週間のDLレポートだ。

ここから新しく学べることは、

1、他で構築したネットワークでの告知や、他のSNSでの宣伝に頼ると、それなりの効果がある。
2、universalアプリにすると、中国からのアクセスが凄く増える

というようなことだろうか。

スポンサーサイト
comment (0) @ ゲーム公開

[新作iPhoneゲーム・リリース]おっさんと川

2015/08/23

ようやく、iPhone用の新作ゲームをリリースしました。
2作目になります。

↓こんな感じのゲームです。

title.png

5.png

無料なので、良かったら遊んでみてください。

npie.png
iPhone用ゲーム 『おっさんと川』

comment (0) @ ゲーム公開

[iPhoneゲーム新作・申請] 一発で通った

2015/08/20
申請中だった2作目のゲームが、
今日、リジェクトなく一発で審査を通過した。

アプリ内課金やインターネットランキングなど、初めて実装した要素がたくさんあったから
どこかで引っかかりそうと覚悟していたので、
ちょっとびっくり。

しかしこれでいよいよ二作目が公開となる。

で、リリース日の設定についてだが、
このリリース日の設定というのが、けっこう重要なのでは、と最近気付いた。

前回の時は、リリース日は申請時点から now にしていたが、
ネット上での情報によると、
審査通過後の日付をリリース日にしていないと、
審査中にリリース日に到達した場合は、新着ランキングに掲載されないとか。
もしこれが本当だったら酷い話である。
だから誤情報の可能性もあるが。

しかしそういうことも考慮し、今回は申請時点では2週間+3日後の日付を設定しておき、
審査通過後の今日、今日から4日後の24日にリリース日を再設定した。

APP STORE公開は審査通過から72時間後?らしいので、
4日の余裕を持たせた。

このあたりの情報は本当に曖昧だ。
APPLEが何度も仕様変更し、しかも最初のアナウンスが英語なのが原因かもしれないが、
この辺、分かりやすい所に随時はっきりと明記して教えてほしいものだと思うが、
APPLEとはこういう性格だから諦めよう。

なにはともあれ、4日後が楽しみだ。

comment (0) @ 申請

[SpriteKit] 描画の拡大縮小における美しさ、処理の重さ、分からないことだらけ

2015/08/12
SpriteKitでは、一画面の描画幅はiPhone6の場合、
375 x 667 になります。

そしてスプライト描画の際は、

.Nearestと.Linearという2種類のテクスチャーフィルタリングモードがあります。

前者は、拡大縮小の際に荒くなるが、処理が速く、
後者は、美しく拡大縮小されるが、処理が遅い、

というのも。

しかし、実際どんな風にどれくらい処理に影響が出るのかは全然分かりません。

それにまた、美しく拡大縮小される・・・、というよりも、

Nearestは、そのまま拡大縮小し、
Linearは、アンチエイリアスをかけて拡大縮小している、という感じ。

ですので、画像によっては、Linearの方が汚くなる場合もあります。
例えば、
ドット絵を拡大縮小したい場合は、Nearestの方が適しています。


また、この拡大縮小のモードとは別に、

どうもiPhoneでは、
画像をそのまま表示させるより、
大きな画像にして縮小表示させる方が美しい、・・・ような気がします。

というわけで、もし美しさを重視するなら、
できるだけ大きな画像を用意し、それを.Linearで縮小表示させることになるわけですが、

この拡大縮小やモードが、どれくらい処理に影響が出るのかわからないので、とても不安です。


他にも分からないことがあり、

同じ画像のスプライトをたくさん表示するケース。

テクスチャーは多分最初に読み込んでおいて、それを使用するのが良いのでしょうが、
しかしそもそも、XCODEのimage assetの方に入れていれば、
自動的に適度なタイミングで読み込まれているような気がしてなりません。
そして一度読み込めば、同じ名前のファイルを再度読み込もうとした際にはメモリにあるものを再利用しているような気がします。
というのも、毎回読み込むようにしている場合、
最初は読み込みのせいで、多少のもたつきを感じますが、二度目以降は快適だったりするからです。
ということは、Aeestにいれて、imageNameで読み込むケースにおいては、
毎回読み込むことに特に気にせずにいいのかもしれません。
しかし、あくまで私の想像なので分からないというのが結論です。

この辺は対照実験をすれば答えは出てくると思いますが、
そういう情報ぜんぜんネットにないんですよね・・・
自分でやれということなのか・・・

comment (0) @ 未分類

[iPhoneゲーム申請] 2作目を申請。

2015/08/12
今日、2作目が完成したので、申請に提出しました。

最後の方まで手探りだったアプリ内課金ですが、
もう一度はじめから見直し、
実機テストをしたら、上手く作動しました。

アプリ名のローカライズの方はあいかわらずです。

また、macに繋いで実機テストをしていると、時々、フリーズするという妙な現象に見合わせました。
エラーは何も出ておらず、実機の方もXCODEのモニタの方も、しーんと止まったままになる現象です。

ログから察するに、どうもiADが広告を取りに行く際に発生しているような雰囲気を感じとりましたが、
はっきりとしません。

メモリやCPU占有率の問題だろうかとも思いましたが、原因不明。
今回のゲームは、XCODEからのモニタではCPUは平均30%程度、メモリは40MBほどを使用しているようですが。

ただ、この現象は、XCODEにつながずに、実機だけでのテストでは
発生していないので、とりあえず放置することにしました。

あと、今回は初めてuniversalアプリとして提出してみました。
それに関してですが、
universalで、iPadにおいては、iAdのバナーサイズが異なるというの部分でつまづきました。

iAdのバナーサイズの変更方法がついぞわからず、
もういいやということで、iPadの場合は広告を表示させないことにしました。
(もしかしたら、表示させていない、という所でリジェクトされる可能性があるかも・・・)

というわけで、
二週間くらいは、生活費を稼ぐ仕事に戻ります。

comment (1) @ 申請

今作っているゲームがようやくひと区切り

2015/08/11
今作っているゲームがようやくひと区切りつこうとしています。

まるまる一ヶ月かかりましたが、おもえば、まるまる一ヶ月ほぼずっとゲームを作ったのは、
大学生時代以来かもしれません。

こんなにも時間を要したのは、分からないことでつまづくのは仕方ないとして、
それを除けば、とにもかくにもmacと、XCODEが重いせいです。

私はwindowsの方では、未だに15年以上前のDELPHIを使っていますが、
数万行のコードを書いても、1秒かからずコンパイルしてくれます。

しかしXCODEは、1000行も超えれば、あくびが出るくらいには遅くなります。

そして今回も、前回に続いて解決できなかったことが残りました。


・まず、アプリ名のローカライズが今回もうまくいかなかったこと。

 これだけやって上手くいかないのは、きっと私が大きな見落としをしているからでしょう。
 しかし、上手くいかないので諦めました。
 info.Plistで直接bundle display nameに日本語で書いて、英語は無視しています。


・コンパイルが遅い。

 今回はいくつにもファイルを分散することで、少しでも軽さを維持しようと努めてみました。
 分散は結構効果があったと思います。
 コーディング中の重さも軽減されるようです。
 しかし、それでもやっぱり遅いです。
 あと思いつく対策と言えば、コンパイルせずにコードを書く時間を長くさせることでしょうか。
 それはあんまり性に合わないので、無理かもしれません。
 これがAPPLEの限界なんだろうと思って、諦めるしかないかもしれません。


・また、今回はiPhoneアプリ2作目でしたが、今回で初めて挑戦したことと、
 それに併せて、その中で解決できずに残った問題点を羅列しておきます。


・アプリ内課金

 実装には苦労しました。
 ネットに、Swiftによる分かりやすい情報がほとんどないのが辛かったです。
 多くの書籍も頼りましたが、ネットとあまり変わりません。
 そして、sandboxでのテストは最後まで上手くいきませんでした。
 今回、リジェクト可能性が一番高いのがここだと思います。

・横向き

 横向きは、縦向きよりずっとゲームの幅が広がるような印象でした。
 今の時代の人間は、縦の空間認識より、横の空間認識の方が得意であることに起因するかもしれません。
 しかし、横向きだと、HOMEボタンを押した時に、画面のアスペクトが一瞬変になります。
 これはSpriteKitの何かの設定のせいだと思うのですが、これに関する情報はネットでは見つかりませんでした。
 大した問題ではないのですが、ちょっと気になります。

・ネットランキング

 意外に簡単に実装できた方だとは思います。
 しかし、一番悩んだのは、エンコードタイプです。
 どうも、アプリ側は、ネットから受け取るHTMLを、自分なりにそのコードを解析して、エンコードタイプを判別しているような節が見受けられ、それに悩まされました。
 というのも、HTMLの一番上の数行の文字列を変えるだけで、UTF-8と判断されたり、ASCIIコードでしかデコードできなかったりと、不安定だったからです。
 まあこれは普通のブラウザも似たような挙動をするので、仕方ないかもしれませんが。

・フリックやスクロール

 全て自前で作りましたが、絶妙な感覚を得るまでに微調整が大変でした。
 フレームワークを利用した方が早いのでしょうが。

・UIはほとんど自作

 UIKitの一番面倒そうなのは、個人的にはリストです。
 デリゲートを使うセル更新とか大嫌いです。
 だから今回は自分でSpriteKitだけで作りました。

 しかし、まあ重い重い。
 数百行のリストを作るだけで、単純に数千nodeを作成するわけですが、とにかく重くなります。
 特に作成時が重いです。
 表示に関しては、一画面内に表示されるnodeが少なければ軽くなるようなので、
 一画面内に収まるリスト項目が少なければ、そこそこ軽くなります。
 しかし、作成は重いので、頻繁に全体を更新するのは苦しいです。
 けれど、UIでやるより多分ずっと楽にいろんなことを実装できたと思います。

・ビットマップフォント

 結構悩まされました。
 ビットマップフォントで作った「 」スペースのせいで、レイアウトが崩れたりして、それに悩みました。
 「 」スペースの指定は、自分でfntファイルを開き、その大きさを自分で手打ちして調節することで解決させました。


・サウンド関連

 前回同様にSpriteKitで鳴らしましたが、
 どうもSpriteKitで鳴らすと、重い時などに音が鳴らないことがあるようです。

 ここは絶対に重くなるというような所で、鳴るタイミングは少々ずれてもいいという場面では、
断片的にAVAudioを使用しました。


・タッチノードに困らされた。
 タッチの検出は、TouchBeganを用いて、タッチされたNodeを検索することで行っていましたが、
 ここに一つの問題が。

 どうもタッチされたNodeを検索するやり方では、
 当然かもしれませんが、Nodeが重なっている場合だと、最前面のNodeのみが検出されます。
 普段はそれでも問題ないかもしれませんが、
 例えば、半透明の煙のエフェクトなんかを手前に描画していたりすると、問題が露呈します。
 その時検出されるのは、煙の向こう側のキャラクターではなく、煙だからです。

 タッチ位置だけを取得して、あとは自分で処理するのがよいでしょうね。


・配列

 今回一番エラーが出たのが、配列でした。
 indexがオーバーしている、というやつです。
 最近の言語の多くは、可変配列のようですが、それがこの問題の根本です。

 最初に配列の最大値を決めて、そのあとは、その中で自分でやりくりする、というやり方なら、この問題は発生しにくくなりますが、可変配列は、最大値が可変するので、それで何度もつまづかされました。

 もちろんこれは人間側のミスですし、想定外の問題がエラーとなって見つけやすいという利点もあるので、悪いというわけではありません。 
 悪いのはそのたびに必要なコンパイルの遅さです。


・クラス

 今回はクラスをたくさん使いました。
 きっと多くの人には当たり前のようなクラスですが、
 私の場合、クラスを使わないと、ファイルを分散しづらかった、というのが動機でした。

 でもやはり、クラスを多様することで、不可解な挙動の温床が多々生まれ、その原因究明に
 頻繁に時間を割かれました。
 
 前回作ったゲームは、ほとんどの動作を一本化した自分のルーチンの中だけで回して作りましたが、
 他人から見たら大変見づらいコードではあると思いますが、このやり方だと、何か新たしいことをやる際に、
 すぐに導入できるのが利点です。
 全ての挙動と変数は、一つの中で保持・管理しているので、自分の頭のメモリはたくさん使いますが、
 コードの中では自由度がたかいです。
 クラスをまたぐことはないので、そういった境界を気にせずにすむのが良いです。

 逆にクラスを多様すると、クラスをまたぐための処理のせいで、そこで問題が発生することが私の場合はよくあります。
 これは私がクラスを完全に理解していないからだとは思いますが。
 今後はもう少しこの変を改善したいところではあります。


・リアルタイム描画

 SpriteKitは、その名のとおりスプライトを使用しますが、
 私はこのスプライトというのが、あまり好きではありません。
 重いし、一度描画してしまうと、描画レベルでの変更が利きづらいからです。
 ドット単位で描画を制御したい人にとっては、そういう描画を想定するメソッドが不在だと、悲しくなります。
 ただSpriteKitでも、
 SpriteをaddChildし、1フレーム後には、再びremoveして新たに描画したものをaddChildという風に繰り返せば、
 リアルタイム描画のようにはなりますが、
 なんかすごい、無駄なことをしているような気になります。

 結局、コードもルーチンも描画も、全て自分で一元化して把握管理したいのが、私の性格のようなので、
 そこが単に時代にあっていないだけなのでしょうけども。


comment (0) @ エラー
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。