運ゲー排除マインスイーパーをAndroidアプリにした話と市場に対する雑感

(2016/12/18追記) 続きです。

dnek.hatenablog.com

この記事は KMC Advent Calendar 2015 - Adventar 6日目(12/6)の記事です。

www.adventar.org

5日目の記事は、id:Pasta-KさんのWebExtension現状確認してみた - Pastalablog in はてなでした。

はじめに

最近KMCで代表*1の任期が満了となり、晴れて平部員に昇格した*2dama*3です。

ちょっと前にPietのIDEのようなものを作っていました（宣伝）が、最近Androidアプリを作ってリリースしてみた（宣伝）ので、その辺で色々思ったことを書こうと思います。ちょっとだけ開発上の知見っぽいものも書きます(マインスイーパー以外でも役に立ちそう？)。

マインスイーパーの欠陥

さて、ある程度マインスイーパーで遊んだことがある人であればご存知だと思いますが、マインスイーパーには運ゲーという致命的欠陥（偏見？）があります。

f:id:dnek:20151202050012p:plain

例えば↑の画像では、右下の2マスのうちどちらに地雷が埋まっているのかは完全に五分五分です。このような単純な例を含め、特に上級においては頻繁に運ゲーが発生します。

頑張って考えて解いていたゲームがいきなり非論理的要素によって中断されてしまうのは非常に理不尽なことです。ですが私はこの運ゲーの存在によって元々論理的に解けるはずの盤面がきちんと解かれなくなることの方が問題であると思います。

つまりどういうことかというと、とても複雑であるが論理的に解ける盤面でも、絶対に運ゲーが無いという保証が無い故にその検証にかける時間を惜しまれ運任せにされてしまう場合があるのです。

ある程度プレイしている人にとってこの運ゲーの存在は当たり前のことかと思いますが、そもそも運ゲーが無いことが保証されていれば、どれだけ論理的思考に時間を使おうとする意識が高まるでしょうか。

UnambiSweeper

この理不尽とオサラバするため、私が1回生の時*4に作ったのがUnambi Sweeper*5です。 Unambiというのは"Unambiguous"*6の略です。

当時はWindows向けに~~VB.NETで~~書いたり*7、なんとなくUnityに移植したり*8していました。必ず論理的に解けるようにしたのに加え、私のようなキーボードプレイヤー*9 *10のために操作性を改善*11したりしました。

そしてAndroidへ

実はUnambiSweeperを作った頃、Androidを触ろうとしたがEclipseでの開発に手間取って頓挫した記憶があります*12。

それから時は流れてKMC春合宿2015。

このAdvent Calenderの作成者でもあるid:nonyleneさんのスライド発表を見ました。

https://www.slideshare.net/KMC_JP/android-45867155www.slideshare.net

実はそこでAndroid Studioの存在を知ったのです。 Eclipseはダメだったけどこれならイケそう、と思い、しばらく触れていなかった*13UnambiSweeperをAndroidに移植してみようと思い立ったのです。

そして半年ほど勉強しつつ頑張ってリリースしたものがこちら。

是非遊んでみてください！！！

で終わるわけではない。

UnambiSweeperの良い所

とりあえず運ゲーにならないというだけでも他のマインスイーパアプリではなくUnambiSweeperを選んでいただけることと思いますが、そもそもマインスイーパーとしての完成度が他とは違います（多分）。

UnambiSweeperの良い所

類似アプリの良くない所

というわけでここから今までよりも自信過剰な発言をしていきます。

現状、PlayStoreにて「マインスイーパー」で検索してみると、有象無象のマインスイーパーアプリが出て来ます。

gyazo.com

リリース時期にもよるでしょうが、初めの方に表示されるアプリには10万、100万DLレベルのものがいくつもあります。

ですが、これらの人気アプリでも(評価が高いものでも)実際に遊んでみると~~特に遊ぶ価値はない気がしますが~~色々と不完全な部分が見つかります。

以下、気付いたものを挙げていきます(すべて5万DL以上のアプリで確認できるものです)。

ボタンがフィールド上に重ねて置いてあってミスタッチし易い

おそらく現状で一番まともだと思われる類似アプリ(100万DL)でほぼ唯一気になった点です。 UnambiSweeperでは、画面の上下端に半透明のカバーをしてその上にボタンなどのUIを設置しています。

プレイ画面が表示された瞬間にタイマーがスタートする

これはなかなか致命的な問題だと思うのですが、100万DLのものを含めいくつかのアプリで確認できます。

最初に開けたマスの周囲に地雷が存在する

普通に考えれば分かることですが、最初に開いたマスの周囲8マスのいずれかに地雷が存在すれば、そこは数字マスとなり周囲のマスは自動的に開かれません。つまり初めから運ゲー状態となるわけです。これはおそらく半分以上の類似アプリで確認できる問題です。 由々しき状況です。ちなみにWindows付属のマインスイーパーではVistaから改善がなされています。特に実装上難しいものではないですし、マインスイーパーを実装する上で最低限のマナーだと私は思っています。

最初に開けたマスに地雷が存在する

最初に開けたマスに地雷が存在するものもあります。論外です。

周囲一気消しが出来ない

マインスイーパーでは、数字マスの周囲にその数字と同数のフラグが立っている場合、そのマスに旗立てと同等の操作*14を行うことでそれ以外のマスを一気に開けることが出来ます。 フラグを使うプレイヤー*15にとっては必須と言えるこの機能を有していないアプリも数多くあります。

地雷/フラグ切り替えが出来ない

多くのアプリでは、デフォルトで「タップ = マスを開く」、「ロングタップ = 旗を立てる」という仕様になっています。ですが、フラグを使うプレイヤーは上記の周囲一気消しを用いるため旗立ての操作をすることの方が多いし、単純に一々ロングタップするよりも操作を入れ替えてタップで旗を立てる方が速いです。そのため、切り替えボタンがあると便利なのですが実装されていないアプリもいくらか存在します。

動作が重い

SurfaceViewやGLSurfaceViewで実装しましょう。あるいは画像をあらかじめcreateScaledBitmap)などでScaleしてから描画しましょう。とかそんな所だと思います。

タップしにくい

触れてから少し指を動かしただけでスクロールと見做されてしまい中々タップできないという問題です。これはおそらくMotionEventのACTION_MOVEをそのまま使ってしまっているのが原因だと思われます。特に複雑な実装をしようと思わないのであれば、GestureDetector.SimpleOnGestureListenerのonSingleTapUpやonScrollなどを使えば良いと思います。

但し一度タップしてからすぐに近くの場所をタップした場合これはダブルタップと見做され、onSingleTapUpでは2回目のタップを検出することが出来ません。一応GestureDetector.OnDoubleTapListenerというものが存在するのですが、これでも何故か2回目のタップをスクロールと分けて検出することが出来ません。そのため、私はACTION_MOVEで初期タップ位置からの距離を計算してスクロールになるかどうかを判定しています。この距離は

ViewConfiguration.get(getContext()).getScaledTouchSlop()

などで取得することが出来ます。 ViewConfigurationでは他にも色々な値が取得できるので一度確認してみると良いと思います。

ピンチイン/アウトが変

いくらかのアプリではピンチ(二指ズーム)が出来ます。しかしその多くはフィールドの中心を基準に拡縮しているため、フィールドの端の方で拡大した状態からピンチアウトしようとすると、中心に吸い寄せられるように縮小されてしまいます。これは、ピンチ時にタッチしている2点間の中心を取得することで改善することが出来ます。

よく分からないUI

ズームが出来ない代わりに、タッチ位置の周囲を拡大して表示するようなUIを実装しているもの(10万DL)がありますが、正直かなり操作しにくいです。もう少し素直なズーム機能を実装してほしいものです。

よく分からない盤面デザイン

フィールドのサイズは画面一杯で固定、マスのサイズを設定するとそれに応じて画面に入るだけのマスが詰められる、難易度を変えると地雷の密度が変わる、というちょっと不思議な盤面のデザインをしているものがあります(50万DL)。これに関しては好みによるのかもしれませんが、同じ難易度でマスの数が変わりまくるというのは良くないのでは、と思います。