スポンサーサイト

--/--/--
上記の広告は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) @ エラー

[Swift] SpriteKit SKSceneからpresentViewControllerを使う方法

2015/07/30
SpriteKitから、presentViewControllerを使用することは通常では難しいようだ。
理由はSKSceneが、UIViewControllerを既に継承しているらしく、
多重継承になってしまうかららしい。
(既に継承しているはずなのに、使えないのはどういうことなのか詳しくは私には謎・・・)

まあそのせいで、SpriteKitから、
presentViewControllerを呼び出すのが難しく、そのせいで
ダイアログを出したり、ツイッターやFacebookを使ったりするのが簡単にはいかなくなるようだ。

ネットで色々調べると、presentViewControllerを使用せずに使う方法を模索している情報が多いが、
そんな
中、最もシンプルなやり方をとっている情報があったので書き留めたい。

SKSceneと言えど、Viewの最も最前面にはUIViewContollerが存在しており、
それを取得してきて、そこから使用するというもの。


var currentViewController : UIViewController? = UIApplication.sharedApplication().keyWindow?.rootViewController!
currentViewController?.presentViewController(・・・・・・・)



これだけで取得できる。
すごい。


たとえばダイアログなら、以下のようにすぐに使用できる。

let alertController0 = UIAlertController(title: "確認", message: "すべてのデータを初期化しますか?", preferredStyle: .Alert)
let otherAction0 = UIAlertAction(title: "Yes", style: .Default) {
    action in println("初期化しました")
}
let cancelAction0 = UIAlertAction(title: "No", style: .Cancel) {
action in println("やめました")
}
alertController0.addAction(otherAction0)
alertController0.addAction(cancelAction0)

var currentViewController : UIViewController? = UIApplication.sharedApplication().keyWindow?.rootViewController!
currentViewController?.presentViewController(alertController0, animated: true, completion: nil)
comment (0) @ tips

[Swift] シーン変更によるクラスの持続と破棄・インスタンスの持続と破棄

2015/07/23
まず、クラスの概念について、私はまだ完全に理解していません。
というか、ほとんど分かっていません。

というかクラスをどんな風に利用するのが適切なのかが、
分かっていないんだと思います。

しかし、それでも手探りに利用しているわけですが、
そのせいで、様々な不具合のような現象に出くわします。

1、SpriteKitのSKシーン切り替え時に、クラスやインスタンスはどのように残ったり、自動破棄されたりするのか。

現在のSwiftでは、クラスは参照元がなくなると自動破棄されるようです。
そのため、SKシーンを切り替えたりすれば、SKシーンのインスタンスが破棄されるため、
それによってクラスは自動消滅し、データ等を自分で破棄したりする必要がないとのことらしいのですが、
しかし、実際にはものすごくクラスが残っていたりするかもしれません。

たとえばSpriteKitにあるSKNodeですが、
シーン表示させているクラス内で作成したNodeを、
異なる二つの別クラスに、それぞれのインスタンス時に受け渡したケースで、

このNodeは、シーン切り替え3回目あたりで、突然表示されなくなるという
怪奇現象に出くわしました。

私がクラスを理解していないので、完全にあてずっぽうですが、
多分、二つ以上の別クラスに、メインクラスのnode等を受け渡した場合、
メインクラスのシーンを切り替えても、
その二つの別クラスのインスタンスは破棄されずに残っているんだと予想します。

この二つの別クラスは、メインクラスからインスタンス化しているので、
メインクラスが破棄されれば、自動的に参照元を失うはずなのですが、なぜか残り続けます。

こういうのは、多分そうじゃないかなーと警戒していても、
扱うクラスやインスタンスやnodeが膨大になればなるほど、
絶対に知らないうちに発生することだと思うのですが・・・。

なので、偶然発見できればいいのですが、もし発見できなかった場合は、
致命的なクラッシュバグ等として残ることになる非常に危険なものだと思います。


2、クラス内タイマーは残る。

NSTimer というタイマーがありますが、
これをクラス内で使用すると、個別に稼働するタイマーとなり非常に便利になります。
しかしこのタイマー、SKシーンが切り替わろうが、インスタンス元を破棄しようが、ずっと動き続けているようです。

なのでクラス内でタイマーを走らせる場合、
シーン切り替え時などには、
インスタンスしたクラス全てに対し、タイマーを止めるメソッドを実行してやらねばなりません。


・・・とまあ、今の所気づいただけでこのような重大な要素があるので、
きっとまだまだありそうです。

そして、これらのインスタンスがずっと残り続けると、
SKシーンの切り替えを行うたびに、それらが不要に重複し、思わぬ不具合を引き起こす原因となりそうです。


■ 対策 ■

SKシーン切り替え時には、SKシーンや各クラスに、

Dinit{
   println (" class名 end!! ")
}

の一文を挿入する。

これで、一応そのクラスのインスタンスが完全に破棄されたかどうかが判明します。

破棄されていないとしたら、私の場合の多くは、

・そのクラス内で使用しているNSTimerが破棄できていない。
  or
・そのクラス内で宣言したSKNodeを、2つ以上の別クラスに参照させている。

の2つが多いです。
前者は、シーン切り替え前に、NSTimerを終了させればOKですが、
後者は見落とす可能性が高いです。
対策としては、なるべくSKNodeを参照させる場合、個別にSKNodeを作って参照させ、
共有を避けるということくらいでしょうか。


最後に、
これらを一切考慮せずに済む方法は、
私の思いつく限りだと、SKシーンの切り替えはせずに、
表示させるシーンは常に1つに固定するという手法でしょうか。

そして画面遷移は、自分で全ての描画を管理することで、
シーン切り替えを利用せずに、自前で行えば、
シーンのクラスを呼び出すのは一度だけとなり、
再インスタンス化するというケースを排除できます。
そうなれば、クラスやインスタンスの不要な持続や破棄をいちいち考えずに済むではと予想します。


クラスを使用すると、
様々なものを個別に管理でき、
また再利用もできるのでとても便利です。

でも、予期しないことがあまりに多すぎて、
そういう対処に、大半の時間を持って行かれている感じです。

こんなことなら、
クラスは最低限の使用にとどめ、
その他全てを自分で構築した一つのループの中で回す方が、
何倍も開発速度が上がりそうです。

インスタンスが破棄されずに残っていることが一目でわかるようなシステムや、
そういうケースが発生した場合には警告で教えてくれたりすれば、まだいいのですが、
そんなことも一切ないし・・。

とまあ、時代に逆行したようなことを言ってみましたが、
個人で全てをやっているので、他人との共有管理を予定する必要がないし、
また一方、予期しない問題が発生すると個人では対応できない可能性が高いという点からも、
ひとりでゲーム開発なんかをやっている人には、
この辺、本当にめんどうな問題だと思います。


UIKitをSpriteKitと一緒に導入した時に、あまりにUIKitの仕様に手こずった時にも思いましたが、
UIにしても、こういう便利だと提示されがちなプログラム要素にしても、
私の場合は、0から自分で作った方が、結局早いし便利だったりするのが、
なんだか個人的に時代とマッチしていない感じがして、いつもちょっと寂しいです。
comment (0) @ エラー

[ダウンロード数] スマホゲームレビューサイトに載った翌日。

2015/07/22
さて、公開から5日ほどで、DL数が13件ほどだった私の処女作は、
ありがたいことに、なぜか2箇所のスマホゲームレビューサイトで取り上げて頂いておりましたが、
その翌日の今日、ダウンロード数をみると、

13件 → 37件

と、約20件ほど増加しておりました。

さて、
昨日の数字なども合わせて考えると、
私の作品の内容がしょぼいからだという要素を含めても、
数年前から巷で耳にするようになった
スマホゲームにおけるジャパニーズドリームですが、
そんなものはとっくに地に落ちている・・・のかもしれません。

例えば、
今、どこにも告知せずに、ネット上のフリーゲーム登録サイトである「ふりーむ」に、
内容の全くない作品をアップロードしたとしても、
5日間のダウンロード件数はこの数字を簡単に上回りそうです。

また、ネット上だとかつて登録サイトとしてアクセス数の多かったVECTORが、
昨今では利用者が激減したのか、
ほとんどダウンロードされない状況になっていますが、
今回のiPhoneゲームにおけるダウンロード数は、
その今のVECTORの水準に近いでしょう。

しかしappストアのユーザー数が激減するはずはないので、
つまりは、iPhoneのappストアのシステム自体が、
現在のユーザーからのアクセスに対し、
非常に寡占的な構造になっているということかもしれません。
(まあ、あの見たままのシステムでは、こうなるのは必然でしょうが)

ふりーむに登録した方が、まだ数字が伸びそうと思われる点は、
ふりーむには新着リストというものが存在しており、
それが正しく機能しているからでしょう。
そのおかげで、内容がどんな作品であれ、必ず初期においては、ある程度の人目に触れるという平等性が少なくとも担保されています。
 (appストアにも新着ランキングのようなものがありますが、
 通常ランキングのページと同じ見栄えですね)

ふりーむに登録する内容を問わないゲームよりもダウンロード数が劣ってしまうなら、
スマホでゲームを制作し公開する意味は、かなり薄くなるかもしれません。

こうなってくると、
もはやappストア自体は、ただの大手appを宣伝するだけの広告媒体ということになってくるので、
appストアへのSEO対策は無意味且つ、それ以外のアプローチが必要になってきそうです。

例えば、存在するのかどうかはまだ調べてないのでわかりませんが、
スマホユーザー向けの、
新着作品における周知能力の高いスマホゲームの登録サイトなどがあれば、
そこへ登録するのが重要かもしれません。
(ただ第一感、PCブラウザ環境でもないので、そんなものを一般スマホユーザーが閲覧しているとも思えないのですが。
コアなスマホゲームユーザー?みたいな人がいるならいいのですが、そんな人はスマホゲームよりPCゲームをしてそうだし……)

確かにPCゲームも、ただ作って自分のサイトに載せただけでは、
認知ゼロの状態からダウンロードされる回数はほぼ0に近くになるものではあります。
(悲しいかな、appストア自体が、個人の無名サイトと同レベル・・・という風に見た方が、ダウンロードされる機会という意味では本質的かも・・・)

さて、この辺はゲームとは全く異なる問題ですので、
今後の大きな課題の一つになりそうです。

しかしこの時点でこのダウンロード数なら、
もはやappストアの有能性もスマホフロンティアも、そんなものは存在しない、と鼻から無視して、
自己満足で色々とやる方が健全かもしれません。
comment (0) @ 未分類

[iPhoneゲーム公開] 申請通った。公開後3日の状況。SEO対策は全く無意味?

2015/07/21
ちょっと数日すぎましたが、2回のリジェクトを経て申請が通りました。
2回ともリジェクトに対する予想と対応は合致していたようです。

まとめると
1回目
 ・広告識別子IFADの質問に、iAdしか使っていないのに、yesと答えてしまっていた
 ・iPad Airだけに発生するエラー

2回目
 ・広告が配置できない
  →iTunes connect内のiAd watchrunch→ iAd Networkの登録がまだだった。

でした。
2回目は、登録して、登録しましたけど、このことでしょうか? と返信すると、10分後くらいには申請完了になっていました。
そこからは72時間待って、AppStoreに公開されました。

さて、AppStore公開にあたっては、前もっていろいろとApp情報を登録しているわけですが、
その辺は、申請時におけるネット情報を見ると、どこもかしこも、
「SEO対策はしっかりしろ、さもないと、誰もDLしない」というようなことが書かれているので、
なるべくそれらのサイトに書かれている通り、詐欺まがいなキーワードを設定したり、
説明文を書いたり、スクリーショットを選んだりしました。

そして、公開から3日くらいが経ちました。

3日経って、状況を見てみると・・・・

DL数 13
閲覧数 150


うん、ネットに転がっているSEO対策なんて、全く無意味だと感じました。
一切キーワードを載せないのと同レベルです。


試しにAppStoreで、登録したキーワードで検索すると、確かに自分のAppがでてきます。
しかし、トレンドなキーワードを設定したところで、
当然ながらそれらのキーワードをみんな付けているわけで、
結果、大手Appが上位を独占していて、そんな所に新規個人が同じ手法で仕掛けても、
遥か下の方に表示されるだけで、誰もそこまで見ません。

ただ、自分しか付けていないようなキーワードなら、当然一番上に自分のAppが表示されます。
しかし、そんなのキーワードは誰も検索しないからこそ、自分しか付けていないことになります。

つまりSEO対策としては、
あらかじめ大手Appと競争できる広告なり認知度なりがあるApp公開においては重要でしょうが、
それ以外では、考慮の必要性はないと言ってもいいかもしれません。

そんなトレンドキーワードを狙うより、
誰も検索しないかもしれないが、自分のAppの概要や特徴を正しく表すカテゴリキーワードを正確につけるので十分であると、今回感じました。

そしてもう一つ、
ネット情報だと、
予め用意できるものとして、DL数に影響するのは、だいたい以下のことが重要である、という風に出てきます。

1、ICON画像
2、スクリーンショットと説明文

しかし、これもおそらく、大手App以外は、無関係と言ってもいいレベルかもしれません。

確かに、ICON画像は目をひかせられなければ、クリックされないわけですが、
その必要性が出てくる状況というのが、スマホの場合、

"ずらずらーと大手Appが並ぶ、その最初の数ページに、自分のAppが並んだ時"

・・・という、その時点で非常に類まれなる状況の時だけでしょう。

通常のPC閲覧でのネットでは、1ページに表示されるサムネイル数が多くなるため、
この状況は比較的生まれやすいでしょうが、
スマホだと、その数は激減しますし、
ユーザーも2ページ以降を見る機会は、ブラウザに比べ遥かに低いと思われます。
そうなってくると、ずらずらとICONが並ぶ所を閲覧してもらう機会は、
大手以外ほとんどないかもしれません。

つまり、このICON画像等も、
キーワード設定と同様に、なにもないのと同レベルということになってしまいます。

むしろ、ICONもキーワードも、自分の好きなように個性的で奔放なものを用意する方が、
新規個人開発者にとっては有利かもしれません。

なぜなら、こうした現在の状況において、
私のような新規の個人開発者が作ったAppが、検索されて目に入るケースというのは、
もはや、
「ニッチ」なケースだけになるだろうと考えられるからです。

そして、ニッチ層のユーザーは、当然ながらトレンドキーワードではなく、
誰も登録していないような個性的キーワードの先に潜在します。
ある一定以上キーワードが認知されれば、それはもはやニッチではなくなるので、すぐさま大手の新しい餌食になるからです。
というわけで、好き勝手なキーワードの方が、まだ誰も開拓されていないニッチに偶然突き当たる確率は上になります。

またそのようなニッチユーザーに偶然閲覧されたとした場合、
彼らは当然ながらトレンドとは全く無関係、むしろ逆方向なユーザーの可能性が高いです。
すると、そんな彼らは、トレンド的な目を引くようなICONだと、逆効果である可能性が多分に出てきます。
むしろ、なんだこの変なICONは・・・というような個性的ICONの方が、彼らは気に入るかもしれません。
そもそもニッチキーワードで閲覧されている状況では、ライバルAppはほとんど表示されていない状況なわけですから、他にAppも表示されていないのに、わざわざ目を引くようなICONである必要性はないわけです。


というわけで、
私のような状況の場合は、
ネットで氾濫しているようなSEO対策とは全く逆行するスタイルが、本当の意味でSEO対策になる、ということかもしれません。

ちなみに、
iAdの解析で見てみると、内2件くらいは中国や台湾でDLされているようです。

また、私は今回あえて、App公開のことをこのブログでしか書いていません。
その上このブログでも、App名はまだ伏せています。
そうすることで、初動のDL数等の数字を純粋化し、
現在のスマホゲームにおける状況というのをできるだけ正確に認識できます。


さて、上記は全て私の個人的見解なので、当たっているか外れているかは全くわかりませんが、
それとはまた別に、今日ネットを巡回していると、
私のAppが、2箇所のスマホゲームのレビューサイトで紹介されているのを発見しました。

その2つのレビューサイトの管理人はすごいですね。
なぜなら、昨日までのDL数はまだ一桁でした。今でも13件です。
そんな状況のAppなのに、よく見つけたな・・・と感心します。
新着のゲームだけでも相当な数があるはずで、そんな中から一桁ほどのDL数しかないアプリを見つけ出すのは、かなり難しそうです。


というわけで、もしネットのスマホゲームレビューサイトに掲載されたら、
その影響度がどれくらいなのか、というのが今日のDL数の増加数から判明しそうです。


さて、現在は2作目を開発中ですが、
2作目公開時点あたりで、このブログでも私のAppを公開したいと思っています。
このブログのアクセス数からすると、ほとんど無意味かもしれませんがw
comment (1) @ ゲーム公開
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。