2012年8月13日月曜日

お金使わないはずだったのに…

身近な知り合いが数人でドリランドをはじめた。一年近くも前の話だ。最初は課金は絶対にしないと言っていた。事実、最初の数カ月は課金をせずに楽しんでいた。課金をしないのが仲間内でのローカルルールとなっていた。彼らはリアルで顔を合わせる仲間と、通信先でのみコンタクトを取る仲間と、その両方がいた。

運営側にとって課金をしない雑魚たちは必要? 強者たちの下に居並ぶ存在として…
猛者たちに優越感を与えるエキストラ・その他大勢として…
…必要だ!
などとおっしゃるようになった頃には案の定、課金プレイをどっぷり楽しんでいました。

私もドリランはしなかったが、android アプリのゲームは勉強も兼ねてときどき新しいのを卸していた。洋物メインで無料ばっかり。というか、有料は手続きどうやるの? というそもそもの疑問があって、別にトライする気もなかったので長いこと、一年以上は有料アプリには手を出さなかった。

ところがある日、docomo のサイトで懐かしのファミコンゲームの映像きれいなリニューアル版があるんです。と
それも、 docomo の勝手に溜まるポイントで支払いができるということなので、私も 1400円分もポイント払ってダウンロードしちゃいましたわ。
結局、値段分は遊べたので文句はないっすが。

まあ要するに無料・無料で細く長く釣っておけば、そのうちお金払ってくれる可能性はあるというだす。まあそうはいっても、本当に訳の分らん得体のしれないものに対していきなり有料...というのはハードル高すぎなんでしょうが。方法はいろいろあるが、「金払いは悪いけれど興味は持ってくれている、うす~いファン」を確保することが布石になるのだろう。結論としてはローマは一日にしてならず、という実におもしろくもなんともない…。

2012年7月9日月曜日

脅威!!! Permission Remover という世の中

アンドロイドアプリで個人情報ダダ漏れやん。という状況は一般のニュースでも流され、一般のユーザーに脅威を与えたのは記憶に新しいところ。実際パーミッションにどのようなものがあるのかというと、
READ_CALENDAR : カレンダーの読み取り(詳細不明)
READ_CALL_LOG : 電話のログ、つまり電話履歴の読み取り?、怖い怖い
READ_CONTACTS : 電話帳に登録してある住所やメール情報の取得が許可されるらしい、怖いね
READ_PROFILE : ユーザーのプロフィールデータの取得(具体的に何なのか知りません)
ACCESS_FINE_LOCATION : 詳細な位置情報の取得
参考
mucchinのAndroid戦記(http://android.roof-balcony.com/shori/content-provider/getcontent-2/)

まあ電話帳データに着信履歴、画像データなんかは簡単に取得できるし、あとはサーバーにそれを送るだけ。 闇のデータベースがあってそこでは電話番号を検索すると名前、メールアドレスが判明。 逆にメルアドから名前や電話番号も分かるだろう。 また、誰から電話があったのかもデータがあるし、それはいかんだろっていう秘密の写真も見放題。 逆に何が盗まれていないんですか?っていうくらいの盛りっぷり。 おそらくメールの内容、文面までは抜きとれていないだろうが...。

電話帳は怖くって、あなたが安全なアプリしかダウンロードしていなくても、あなたのtel番やメルアドを携帯端末に 登録している友人が危険なアプリをダウンロードしてしまっただけでアウト。しかし、着信履歴やブックマーク、個人持ち画像なんかは自衛することで守れそうな気がする。

こんなご時世ですから、
トラブってもいいから消してしまおう、もろもろ
という気分になってもおかしくはない。その、、アプリが、、正常に、、まともに、、完全体で、、動かなくても、、いいから、、安全を買いたい。
通信機能を解体。
それが表題の Permission Remover !!!
こいつは INTERNET の権限をはく奪するらしい。通信を奪えばサーバーに送信されるリスクを回避できる。

ただこんなことされると、無料アプリで admob 導入して、広告費を稼いでやろうという戦略が破綻してしまう。 ネット通信機能を、アドモブ広告配信という目的だけで取り入れているアプリなんか、きれいに広告部分だけカットされるということになってしまう。これを防ぐためにはネット通信を他の目的でも使うようにしなければならない。 例えばサーバーから他ユーザーのスコアなどから作りだしたランキング的なものを配信するとか。 データそのものをサーバーからダウンロードする形式にするとか。

しかし、もっと根本的な潜在的危機としてはマイナーグループの低迷が考えられる。 とにかくわけのわからないものには手を出さない、有名な(DL数や評価量で判断可能)、老舗の(アイフォンからやっているような)、安心できるメジャーな製作者が作ったものだけダウンロードしよう、という風潮が広がるという懸念。つまり、何の実績もない新規参入組が大量のダウンロードを得ることが、より難しくなった可能性がある。 iphone と比べて参入障壁が低いのが特徴と称されることの多い android マーケットだが、承認制にしなかったことによる負の側面が今、アドモバーたちを窮地に陥れている。

2012年7月4日水曜日

簡単に作れる個人情報収集マシーン -ONMITSU-

admob をやっているおかげで、自作アプリの利用者がどの程度利用しているのかは大雑把には把握できる。国や言語で統計情報がでてくるので。ただ、今後に活かしていくにはもっと詳細な情報がほしいわけです。別に国や言語や電話のキャリア、電話番号などはいらない。自作アプリの詳細な進行状況(どこでつまづいて放置されているのか?)を知りたいわけです。

拙作ではtextファイル形式でゲーム状況を自動セーブするようにしてあるので、その自動セーブデータをサーバーに送信するようにしたい。そこまでは技術的にできました。ただ、単一ファイルの上書きを繰り返すことになるので、ユーザー別にファイルを1個1個作って管理できるようにしたい。そのためには、何らかの識別様式が必要となってくるわけです。

当初は面倒なので us とか jp とか ru とか uk とか de なんかの国コードを取得して同じ国は一つの人物として識別しようかと考えていた。どうせ厳密にわける必要はないし、アメリカ以外の国で同時期に2人以上がアクティブインストールしているケースは珍しいので、情報収集の手段としてはその程度の識別で問題ないと考えていた。実際に PHP で国判定、言語判定などを行うソースはネット上に出回っているのでそれらを利用するのも手だな、と思っていたわけです。

ただついでに送信元、Android Java サイドでそういう識別を行ってみるためにはどうすればいいのかも調べてみたら、TelephonyManagerクラスというものを用いれば電話番号、デバイスID、SIMの国コード...など、なんていうかかなりプライベート情報を取得できるみたいです。ただし、これを使うには READ_PHONE_STATE というパーミッションが必要らしい。電話状態の読み取り? みたいな訳になるのか。

ただ文献ではパーミッションが必要とのことだが、パーミッションなしで試しても以下の結果がでてきた。

電話番号だとかNTT Docomo だとかシリアルナンバー(端末個別の番号)などが楽勝ででてきます。 これがパーミッションなしで取得できる?

アプリのパーミッションはダウロード時、あるいは”設定”>”アプリケーション管理” などによって確認する機会がある。android のアプリは安全のために手枷、足枷をされているのが基本状態だとイメージしてほしい。その枷(かせ)をはずすための作業がパーミッションの追加という具合だ。例えばナビゲーション関連のアプリなら利用者の現在位置を知るために GPS を使うだろうが、この場合は詳細な位置情報 ACCESS_FINE_LOCATION を掲げる必要がある。パーミッションを知れば、それがどういうアプリなのか推測できる...かもしれない(できないっちゃ、できない)。

INTERNET
READ_PHONE_STATE

上記二つは
admob 広告を成立させるためには必須
残念!!!
READ_PHONE_STATE がないと↑画像下側の赤文字警告文がでてくる(むろん広告はでてこない)。

admob を取り入れているアプリは、少なくともTelephonyManagerクラス相当の個人情報が収集される危険性があるということだ。ここはもう、製作者の良心に委ねるしかない...。と締めくくるとありがちなので、モス少し突っ込んで考えてみよう。逆に、個人情報収集したい側の思考に立つならば、
もっと欲しい
もっと欲しい
位置情報も欲しい
電話帳の中身欲しい
と、なるわけで、本気で抜く気ならアプリ利用者本人の電話番号だけじゃ飽き足らないのは明白。確かに電話番号や国や利用キャリアが判明するだけでは...ちょっと使い道がない。アプリ単体の利用統計を取るには便利だが...。つまり、抜く気ムンムンなアプリにはもっといろいろなパーミッションが付いているはず...。

2012年6月28日木曜日

ソーシャル化 php ②

・SNS が流行ってるぜ
・android でソーシャル化するには PHP がお手軽だ

ということでアプリからレンタルサーバーに接続して、サーバー設置の PHP でデータベース管理的なことを行おうと試みているのですが、なかなかうまくいなかい。ネット上では情報やソースがごろごろしているが、それを試してもうまくいかないから困ったものです。

HttpClient
HttpPost
このあたりを外部ライブラリを導入して用いればサーバー設置の PHP と通信を行うところまでは何とかたどりつく。しかし、ファイルに書き込んだり、ファイルを作ったりすることができない。このあたりができれば、サーバー上に色々なユーザーから持ちあげた情報を蓄積していくことができるのだが...(個人情報とかそういうのではなく、ゲームアプリの個々の進行状況などをアップさせたい)。

答えはパーミッションにあった。FTPソフトにFFFTPを用いているが、こいつで簡単にファイルやフォルダのパーミッション(権限)を調べることができる。Excel なんかだと新しく作ったファイルをネットワーク上に置いたら誰でも上書き保存ができる。誰でも上書きできるのが不都合なら、設定を変えないといけない。

ところがネットファイルの場合は新規ファイルは 644 (オーナー「呼出」「書込」、グループ「呼出」、その他「呼出」)となっている。新規フォルダだと 755 (オーナー「呼出」「書込」「実行」、グループ「呼出」「実行」、その他「呼出」「実行」)となっている。書き込み権限のないファイルに(PHPプログラムで)書き込むことはできないし、書き込み権限のないフォルダ内では(PHPプログラムで)新規ファイルを作成することができない。
参考
http://homepage1.nifty.com/mystaff/howto/permisson.htm

セキュリティ上 777 にすることはよろしくないが、プログラムでファイルを自動生成したり書き込んだりしたいのなら 777 のフォルダ内に、そのような機能を持つ PHP ファイルを設置する必要がある。タネが割れたらけっこう簡単な話だが、この辺を分かりやすいように説明しているウェブサイトも知恵袋もないんですよね~。

2012年6月25日月曜日

ソーシャル化 php ①

前述の「ぐんまのやぼう」にもソーシャルアプリの要素があります。ゆる~く淡~くなんですが、ゲームの進行状況をツイッターにあげることができます。とりあえず昨今のヒットものにはソーシャルの要素が見え隠れする可能性がそれなりに、それなりに、あると思います。ちなみに20年前のゲームなんかソーシャル要素が含まれるものなんて 0% っすからね。社会化の波がキテるのは間違いない。

じゃあソシアルとは何なのか? あるいは君、ソシアルじゃないね! という区別。分別。一言でまとめるなら「ユーザー間の干渉があるか否か」でいいと思います。

パラレルワールド。平行世界...。それぞれが完全に独立しており、AとBに接点はない。AはBの内側を見ることができない。CはA、B、Dが存在していることさえ知らない。Dが神業プレイで即ゲームクリアしても、A、B、Cは「へ~」とも思わない(Dの暗躍を知る術がない)。まるで大都会のワンルームマンションのような世界。それが「非ソシアル型」。↑図の灰色バックの方がこれのモデル図となります。

↑の図(下段)ではAは○○を中継してDに情報(データ)を投げ込んでいます。先ほどのワンルームマンションに例えるなら、管理人さんを通してAさんがDさんに苦情の一つでも言ったような形態です。では、この○○とは何なのか? これがかの有名な「サーバー」さんでございます。必ず、サーバーを介する形で相互干渉なりデータや情報のやりとりを行います。サーバーをいじりたおすことができれば、アプリのソーシャル化など簡単なことです(ただしサーバーをいじりたおすのが難しい)。

私も社会化の流れを僅かずつでも進めていきたいと思い、ここ最近はウェブに接続して java script で動かすということをやったりしてみたが、ど~もサーバーいじりたおすのは java script じゃなしに cgi なり php で行わないといけないみたいだと今更気付かされたわけです。で、androidアプリからデータをサーバーに送ってサーバー内ファイルにデータ保存する、という流れを社会化実験の第一段階として行おうとしたが、それはもう、あっちのブログを見てAを試し、他のブログを見てBを試し、えっ? 結局だめなん? ということに気づいてCを試し、という膨大な試行を要するものであった。

①外部ライブラリ(apache 関連)のダウンロード
②上を eclipse 上でプロジェクトに組み込む
③無料かつ php を起動させることができるレンタルサーバーへの申し込み
④FTP ソフトのダウンロード
⑤php エディタのダウンロード(必須ではない)
⑥ネット上で見かけるソースを切った貼ったで送信側の java ソース完成
⑦受け手(POST)の php ソース完成
⑧⑦を④を使って③に送り込む
⑨空のテキストファイルを④を使って③に送り込む
10.android実機で動作確認(サーバー上にある⑨ファイルを送信文字列で更新することに成功)

まだ序の口ですが、サーバー柔術白帯です。

2012年6月13日水曜日

B級携帯アプリの妙を考える

いまだ500DLいってません。
やる気もうすくなってきて、当ブログも3ヶ月ぶりの更新となっている昨今。
レビューは★1個が2つと★5個を1ついただきました(★1個はほんとに嫌がらせかと思いたくなってきますよ)。
星5の方は謎のメールを送ってきてくれて、8割方内容は理解できたが 「一緒に仕事できることを楽しみにしている」と言われても...?
カネを払ったらアプリのプロモーションをしてくれるということなのかもしれないが よくわからんので、微妙な返事を英文で返してみたが、反応は無し。


話はごっそり変わるが、いま「ぐんまのやぼう」というアプリがミドルヒットの10万越えを達成したらしい。この作者はB級ライトのカジュアルアプリをやたらめっぽう作るという作戦でiphoneのころから実績を地味に重ねてきたところ、件の「ぐんまのやぼう」がまさかまさかの大ヒットとなったらしい。

僕も「信長の野望」とか「三国志」はやったくちなので統一もののゲーム性はわかりますよ。 国力を充実させて隣国に侵攻して制圧、それを繰り返して日本地図を一色に染めていくわけだ、と。 確かにこの一点、この一点に関してはまさに「○○の野望」を語るにふさわしい内容なのですが、、、、、 ものすごいゆるゲーであるということがガチガチの戦国シミュレーションゲームとは一線を画しているわけだ。

・人気の放置プレイ型
・特産物を収穫してGを獲得(一定時間経過でまた収穫できる)
・一定時間というのが起動時間ではなく、リアルタイムの時間であることがミソ
・Gを獲得すると隣国を制圧できる(人口の多い都道府県ほど大量のGが必要)
・他県を制圧するごとにミニゲームが増えていく
・ミニゲームで暇つぶしをすることによって、野菜が生えてくるまでの時間を潰せる
・ミニゲーム自体でもいくらかはGが手に入る
・敵が侵攻してくるなど、プレイヤー側が決定的に負ける要素はない

上記特徴のいくつかは今はやりの「ドリランド」のそれと驚くべき類似性を見せる。 重要なのはドリランドも放置しておくことで行動するためのパワーを回復するシステムとなっていることだ。 また、やればやるほど行動パターン(プレイヤー側の選択肢)が増えていく構造も似ているといえる。

実際に「ぐんまのやぼう」もコンプガチャを取り入れているが、これはシャレというか悪ノリであって、 ドリランドとの真の類似性は時間放置でゲーム内で重要なファクターを獲得(回復)できるという点にあると思う。作者もソーシャルゲームをそこまで意識して似せてゲームデザインを行ったわけではなく、たまたま作ったアプリがなんとな~くドリランド的要素を持っていることに事後的に気付いたのであろう。

ゲーム専用機と携帯電話ゲーム(スマホアプリ)ではユーザーから求められるものが違う、的な話は仮にもデベロッパーなら(個人といえども)100万回読んだことがあるだろう。では実際何が違うのか? タッチパネル? 無料? お手軽? そうだけども、それだけじゃない。いい線いっているが、ボールを芯でとらえていない、そんな気がする。そんな気がしていた。

分断、時間の分断...。

テレビを見ている間にも「それ」は溜まっていく。 仕事をしている間にも「それ」は溜まっていく。 寝ている間にも「それ」は溜まっていく。 一度ハマればちょっと時間があいた、そのあとに「それ」の溜まり具合を確認する作業が定常化してしまう。

・一定時間というのが起動時間ではなく、リアルタイムの時間であることがミソ
これに、これに尽きる。この点を上手に生かしたゲーム(ゲーム?みたいなゲーム)が流行しているような気がしてならない。

脱力系で集中力がいらない。
リアル世界での時間経過でゲーム内でもボーナス発生
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
かつてのゲームではプレイヤーが何もしなければゲーム世界でも何も起こらなかった。また、リアルタイム型のゲームであれば何もしなければ真面目に行動しているCOM側が優勢になるだけであった。
テレビはテレビでずっと見ていないとストーリーが分からなかったり、その日一番の盛り上がり部分を見逃してしまうという失態に繋がってしまう。何だかんだ言って油断ならない。
その点、時間があくことがプレイヤー側にとって決してマイナスにはならず、プラスの効果しか生まないという構造は(実際の世界ではそんな好都合は有り得ないのだが、むしろ、だからこそ...)安心できるし気分のいいものである。
このへんが肝のような肝するな。

2012年3月10日土曜日

検証!ファイルサイズとダウンロードの相関関係

先週の土曜で100DLをようやく達成、アクティブ率はここ最近は10%付近で低水準。しばらくは浮上の可能性すらみこめません。 なので、●●をしたらうまくいくぜぇ!と強気なことを書けるわけもないので検証記事です。

きっかけは、アップデータでファイルサイズが増えた→ダウンロード数が減ったような感触を得たことから...。 「もしかしてファイルサイズが大きいとダウンロードされにくいわけ?」と思ったのだが、どうだろうか。

上の図はアンドロイドマーケットでゲーム・人気の新着(無料)のカテゴリーにおいて、とあるてきとうな日、1~30位の群Aと301~330位の群Bを抽出したものである。30検体のファイルサイズがどのように分布しているのかを調査した結果だ。

一番右端のオレンジ帯は11MB以上の重アプリであり、20MBや30MBは当たり前という世界。この帯域が上位群ではなんと1/3を占めている。それに対して下位群ではこの帯域はたったの1/30、まずはこの結果に対して検証を行ってみよう。重アプリは美麗な画像を持つ---見た目がいかにも「お金をかけて企業体が作りました」という感じであるし実際そうである。ようするに作りこまれた課金型アプリ(入口は無料)が上位にたくさん食い込んでいるという非常に順当な結果である。

今度は逆に1MB未満の軽アプリ(左端の青)を見てみよう。人気群(A)の場合、10MB未満アプリの実に35%が1MB未満である。不人気群(B)の場合、10MB未満アプリの32%が1MB未満である。この割合は両者ともに大差ない。ざっくりといってしまえば世に生み出されるゲームアプリ、悪く言えば粗製乱造の中にあって1MB未満のアプリが多いことであり、絶対数が多いのだから人気群にも相当数入っていくということだろうか?さらに言えば「見た目の派手さがダウンロード数を左右するわけではないのだよ」ということだろうか。

別に0.5MBのゲームが気軽に作れて30MBのゲームを作るのが大変だというわけではないのだが、それでも小学生の落書きみたいなノリでべたべたと重くして30MBというゲームは実に見かけません。逆にぱっぱっと作って200KBということは多々ある。本当は小さい画像だけで面白そうな画面を作りだすのは難しいのだが...。結局ガリガリ脆弱(+やや脂肪肝)で1MB未満というケースもあれば、中身はあるけど絞りに絞って1MB未満というケースもありうる。「えっ、この内容で1MBないんですか?」というアプリは人気はでやすいだろう、確かに。

次にそうでもないアプリで大きな割合を占める1~2MBの帯域に注目したい。これ、人気群の中にあっては特に目立って割合が高いわけではないのですよ。なんていうか、「1.5MB? なんとか1MB未満にしちゃいなよ」という気概のある方が(そういう製作者の作ったアプリの方が)上位に食い込んでいく気がしてならない。

luxury or simple

上の英語でググってみてくださいよ、このキャッチコピーはたくさんでてくるから。「豪華か簡素か」「豪華か質素か」...? 日本語でシンプルのニュアンスをズバッと言ってるものはないかもしれないのですが...。 まあとにかく、中途半端はいかん、右か左に寄せて寄せて寄せまくれ。