テストステ論

高テス協会会長がテストステロンに関する情報をお届けします

Tobiiのアイトラッカーがすごすぎる件

配信を少し面白くしようと思ってアイトラッカーを買った.

Tobii Eye Tracker 4C Gaming Peripheral

Tobii Eye Tracker 4C Gaming Peripheral

StellSeriesが出してるSentryというのは, これの1世代前のものをOEMして出した製品で, Amazonで買えるものの中ではおそらくこれが最新だと思われる. 今回買った製品で, 配信に視線を載せるというレベルでは十分なレベルにあるため, アイトラッカーが欲しい人は次を待たずして買ってしまっても良いと思う. というか猛烈に売れているわけではないだろうし次は出ない可能性が高い.

セットアップは簡単で, OBSと連携させるのは以下の公式ブログが役に立った. Tobiiのソフトウェアの出力をゲーム画面として取り込み, 背景を透過させる設定をチェックするだけで良い.

help.tobii.com

アイトラッキングの有名なテストとして篠崎愛の写真を見るものがある. 男としては当然やっていく必要がある.

www.youtube.com

見てもらえば分かるとおり, 顔や胸など見てるところにきちんと視線が行ってることが分かると思う. この精度はさすがに視線だけでFPSが出来るというレベルではないが, 索敵など補助的な要素としてアイトラッキングを使っていくには十分だと思われる. 実際に現在プレイ中のFarCry5ではTobiiのアイトラッキングバイスを使ってプレイの一部を行うことが出来る.

肝心のゲーム配信への応用だが, CSGOの1vs1をやってみたものが以下

www.youtube.com

結論を言うと, CSGOではアイトラッキングはそこまで面白い要素ではないと思う. なぜならばCSGOではプリファイアを慎重にしながら動くことが重要であり, クロスヘアを置いてない場所を見ていたら間違っているからである. この動画でも基本的にはクロスヘアと視線が一致していて, そうでない場合は物陰に隠れながら目で索敵しているときくらいである. MMではほとんどの場合, 視線とクロスヘアが合わないのはミニマップとキルログを見る時くらいになると思う.

ではどういうゲームではアイトラッキングが特に有用かというと,

  • バトロワ系 (PUBG, フォートナイト): 配信者がどのように索敵しているかを視聴者に示すことに大きな意味がある
  • オーバーウォッチ: 敵や仲間のライフの確認など, クロスヘアを合わせないまま行う作業が多いため意味がある
  • MOBA系 (LoLなど): やったことはないがたぶん意味がある

が挙げられる. おそらくCSGOやR6SなどのゆっくりとしたFPSはアイトラッキングの恩恵がもっとも小さい部類だろう.

価格は2万円と少し高いが, 性能には満足している. まぶにゃんなどバトロワ中心にやっている配信者にはぜひ導入してもらいたい.

(Overwatch report) プログラマ視点で見たAvoid as Teammateのアルゴリズム

オーバーウォッチの最新パッチでAvoid as Teammateという機能が追加された. これは1人あたり2人まで「こいつとは同じチームになりたくない」というプレイヤーを選択出来る機能だ. プレイヤーのみなさんの中には, 「なぜ2人なんだ?少なすぎて意味ないだろ」と思った人も多いと思う. 実際にOWではより多くの(意図的かどうかに関わらず)トロールプレイヤーとマッチしてしまい, 毎試合「こいつとはもう二度とやりたくない」と思うプレイヤーがいるものだ. だから2人では明らかに足りない. ブリザードにしても当然同じことを考えているはずだ.

ではこの一見意味のない機能はただの気休めであり, またブリザードはプレイヤーをバカにしているのか?この記事ではおれがプログラマ視点で見た時に, たぶんこの機能のアルゴリズムと真の意図はこうだろうと思うことを述べる.

まず, オーバーウォッチのマッチングが目指すべきところは, 一方的な試合を出来るだけ排除することだ. このためにはトロールプレイヤーを排除をして実質的な5対6の可能性を排除すること, ロールのバランスを強制することなどがアイデアとして考えられる. 後者について, ロールキューのアイデアについてジェフはすでに考えているが, OWの目指すべきところではないとして「他の方法によって解決を目指したい」と今は述べている. 今回の機能は, 前者の「トロールプレイヤーの排除」を目的としているとおれは考えている.

仮に無限にAvoid出来るとする. するとAvoidしまくった結果, マッチングが却って機能しなくなる可能性がある. これがまず2人という少数に絞られなければいけない理由. Avoidというのは何らかの6人を選んだ時, その中の誰一人としてAvoidがあってはならないということだから. 直感的には2でも高いくらいだ.

では2人ぽっちAvoidすることで何が達成出来るのか?この2人は投票券だと思ってもらっていい. あなたは全プレイヤーの中から「こいつはゴミだ」と思うプレイヤー2人に投票する. そしてその投票は毎週行われる. 結果としてブリザードのデータベースにはゴミプレイヤーランキングが構築されることになる.

ここで何らかの数値を考えることにする. 初期値は0. 1票得ることに+1される. 例えばあるゴミプレイヤーAは100, Bは80, Cは10, Dは5とする. この時, マッチングアルゴリズムは「出来るだけ近い値を持ったプレイヤーを選ぶ」ということを優先する. 例えばAから見るとBは-20, Cは-90, Dは-95だ. だからまずBと一緒のチームになることが優先される. 逆にCとDは一緒のチームになりやすい. こうすることで, ゴミプレイヤーはゴミプレイヤー同士. クリーンなプレイヤーはクリーンなプレイヤー同士チームメイトになりやすくなる. こうすることで, ゴミプレイヤーを次第に隔離していくことが自然と達成される.

では仮にDがCをAvoidしていた場合はどうなるか?当然DはCとチームメイトになってはならない. しかしここで明らかなことは「クリーンなプレイヤーがクリーンなプレイヤーをAvoidしてる可能性は低い」ということであり, 可能性が低いのだからもう一回マッチングをやり直したとしても, 再マッチングの平均時間には影響がない. 逆にゴミプレイヤーだが, 彼らは悲惨なことにゴミプレイヤーとマッチングされることが多く, その仮チームメイトの中に一つくらいはAvoidが存在する可能性はわりと高いから, 永遠にマッチしなくなる. こうやってゴミプレイヤーはゴミプレイヤー同士でしかチームメイトにならないどころか, 次第にマッチしなくなる.

リザードがこのアイデアを本当に実装してるかは知らない. しかしこのアイデアは非常に理に適っており, おれが1分で気づくことだからブリザードのエンジニアも1分で気づく. 何らかの数値を与えるというアイデア自体汎用性のある基盤であり, 他のBlockやReportなどとの組み合わせもしやすいだろうから, 現実的なことを考えるとこのように実装されてる可能性はわりと高いと思う. というか実際にはすでにマッチングのためのヒント情報として何らかの数値を持っているというのが自然なので, それを利用した実装になってる可能性が高い.

逆にもしブリザードの意図が本当に「たった2人をAvoidするだけ」なのであればブリザードはまじでバカだし, オーバーウォッチはプレイする価値のないゴミクズだと思う. でも仮にこの記事で述べたアイデアが実装されているのであれば, おれはオーバーウォッチは次第に良くなっていくという希望が持てる.

以上. ゴッドエイムあきらでした.

(etiles report) Playfabを使ってiOS対応していく計画がある

akiradeveloper.hatenadiary.com

で, 当面はAndroid一本で行きたいという話をしたが, 気が変わりつつある. iOSをサポートしていないことによる損失が思っているより大きいかも知れないからだ.

iOSをサポートしていない最大の理由は, Google Play ServiceがiOSをサポートしていないことだ. 以前はサポートしていたのだが, iOSからの使用頻度が低いという理由で廃止されてしまった.

しかし, iOSをサポートしていないことで, Android潜在的なユーザも失ってるかも知れないのだ. etilesの広まりを考えた時に, Android -> Androidのリンクしかないことは, 単にiOSユーザをまるまる失うよりも大きいことは言うまでもない.

そこで今はリーダーボードをAndroid/iOSで一本化出来るサービスを探している.

Playfabはそんなサービスの一人である. APIがすべてRESTで定義されており, 各言語向けライブラリは自動生成されたラッパーにすぎない. おれがもしゲームバックエンドの汎用サービスを作るならば間違いなくこう作るというものがPlayfabだと言える. react-nativeから使う場合はjsのライブラリを使えばいいだろう.

playfab.com

もう1つ考えているのは, そういうサービスを自分で作ってしまうことだ. 自分で作った場合には, スコアに対して偏差値計算を返すことが出来るようになるのが良い点だ. これによって, 他のゲームでも見られるようなランクシステムを導入出来る. 具体的には上位1%にはグローバルエリートという称号を与えるなどだ. これはこのシステムはリーダーボードと併用するとetilesの魅力に直結すると考えている. この機能はどう考えても有用なものだが, Google Play ServiceやPlayfabには見つからなかった. サーバーを立てて定期的にユーザデータを全部読み込んで平均と標準偏差を更新するというのはあり得る実装だが, ユーザが多くなってしまった場合には読み出しが遅すぎてスケールしないだろう. やはりデータベースの中で直接実行する必要がある.

もちろん, このままAndroid一本に絞ってしまうという方針も残されている. 今あるフィードバックは日本からのものであり, 海外をメインターゲットにした場合はiOSを捨ててしまっても大きな問題にはならない可能性があるからだ. これは他の人気ゲームを調査することによって分かると思う. ざっくりした感覚でいうと, グラフ内の組み合わせは2乗オーダーだから, 仮にAndroidのシェアが70%なのであれば, Google Play Serviceを使う利便性をとってiOSを捨てるという選択も妥当となる. 実際にAndroidの世界シェアというのはそのくらいだから, iOSはやっぱりやめますとなるかも知れない.

おれのリソースは有限であり, 副業として出来ることは限られている. 理解してほしい.

(追記)

Androidのシェアについて

xera.jp

Androidはむしろシェアが上昇していて, 8割に届く可能性すらあります. iOSユーザが少なくなっていくれば, 淘汰は進むでしょう. もともとAndroidのOSはそれほど良いものではなかったのですが, 少しずつ改善してきて, それに伴ってデバイスも良いものが手に入るようになりました. これはLinuxがサーバ市場をほぼ独占しているのと同じ歴史が繰り返されているだけに見えています. 10年先にはiOSは駆逐されているのではないでしょうか.

カウンターストライクの歴史が15年. CSGOの歴史が5年程度なので, etilesも競技性が認められるならばそのくらいのスパンでは運営していきたいと思っているのですが, 果たして5年後10年後に10%以下のシェアになるOSをサポートするのが妥当な判断かどうかというと, GoogleiOS向けにGoogle Play Serviceのサポートを切った本当の理由はそこにあるのではないかとすら思えてきます.

(etiles report) 進捗報告

etilesは少しずつ開発を進めていて, 昨日, beta19をリリースしました. 少しずつですがインストールやアクティブユーザも増えてきています. (現在インストール28. うち海外3)

みなさんも参加してください.

play.google.com

リーダーボード

Google Play Serviceを使ったリーダーボードでは, 一部のユーザによる熱い戦いが繰り広げられています. おれはもともと, 人間のワーキングメモリの都合上, 人間が解けるのは4x4が限界で5x5はテレンスタオしか解けないだろうと予想していたのですが, そんなことは全くなく, 5x5でもすでに20秒台で解くユーザが現れています. 特にakuto4405とTheTarouTanakaが互いに抜きつ抜かれつで競っていて, 記録がどんどん向上しています. ここでは, etilesがもつ競技性が発揮されてると感じています. 今後, この2人をわからせていくプレイヤーが出てきて, 競争が加速していくとより一層おもしろくなっていきます.

f:id:akiradeveloper529:20180402104425p:plain

f:id:akiradeveloper529:20180402104429p:plain

f:id:akiradeveloper529:20180402104432p:plain

ちなみに2x2は0.94秒で解いたこの二人をわからせています.

Bluestacks

現在etilesはAndroid向けにしかリリースしておらず, iOS向けには今のところ予定がありません. その理由は,

  • Apple Storeへの登録が非常にめんどくさい
  • 年1万円の場代がかかる
  • iOSユーザは世界的には多くない
  • Google Serviceのリーダーボードを共有出来ない
  • リリースをAndroidに限っておいた方が将来的にReact Nativeをやめてネイティブで書きたいと思った時に転換が効く

などです.

ただ, ではiOSユーザは永遠にプレイ出来ないのかというとそうする気はなくて, 色々と可能性を探っています. Web版を作るというのはその選択肢の一つですが, それより手っ取り早い手段として, デスクトップにBluestacksというAndroidエミュレータをインストールして, その上で動かすというのがあります. Bluestacksは, デスクトップ上でAndroidアプリを楽しむことに特化された環境で, 余計な設定もいらず, インストールも簡単でした. 少し縦が長くて不格好ですが, プレイには影響ないと思います. もし気になるなら設定で変えることは出来ると思います.

www.youtube.com

www.bluestacks.com

今, etilesの課題はユーザを増やすことで, Bluestacksでもプレイ出来ることは貢献すると考えています. 今後, Androidでアクティブユーザがより増えれば, iOS版のリリースもやると思いますが, 当面はBluestacksでプレイしてください.

今後

色々やりたいことはあるのですが, いわゆるシェアボタンを作りたいです. LINEやTwitterなどで拡散することでユーザを増やす手段になります.

他には,

  • ディープリンク実装
  • リーダーボードのデータから偏差値を計算してランクを表示する (Google Play Serviceが偏差値を計算してくれたらいいんですが・・・)
  • 目覚ましが鳴って, 黙らせるためには問題を解かなければいけない => 一瞬で覚醒する
  • ファイルと一緒に問題を送って解かないと中身が見れない (パスワードみたいな感じ)
  • 通信対戦 (同じ問題を同時に解きはじめて, 先に解けた方が勝ち)

などを考えています.

今後もetilesをよろしくお願いします.

(csgo) 認定はNOVA4でした

今CSGOをやってる人の大半は何百時間もやっていてプライムになっているので, ノンプラのおれはたまに「サブ垢ですか」と聞かれることがあるのですが, サブ垢ではありませんしサブ垢を作る予定もありません.

はじめての認定10戦はかなり長かったです. たぶん5回くらいはtieがありました. その他はたぶん勝ち負け半々くらいだと思います. 1戦目は雑魚しかいなかったのですが2戦目からいきなり強くなって, K/D的にはあまり活躍出来なかったですが, statサイトに書いてある「K/Dだけでなくヘッドショット率なども考慮したレート」では1.2弱(1が平均)でしたので, NOVA3,4くらいかなとは思ってました.

欲を言えばMG認定が良かったですが, 無理でした. 相手にチーターがいて負けになってしまうこともノンプラでは少なくないので. その証拠に特にチーターが多いDust2はエイムで活躍しやすいマップにも関わらず勝率が4割程度です. 完全にかちこまれています. 今のおれはエイムでわからせる以外には出来ることがないので, エイム負けするとボコボコになります.

今後ですが, とりあえずプライムにならないとこれ以上やる気が起きないため, WingmanやCasualなどでプライムに上げようと思います. 現状では, 壁が透けて見えてるんじゃない?と思う人はかなりいて, その度に疑うのが嫌になってきました. バタリオンのアジア鯖がまともに稼働してればバタリオンを始めるんですが, あれは開発陣がアホなのか, 永遠にまともになりそうもないですね.

(etiles report) 色組み合わせの設計について語る

f:id:akiradeveloper529:20180315203343p:plain

このゲームの素晴らしいアイデアは,

  • 任意のNxNに拡張可能
  • kxkの色組み合わせが(k+1)x(k+1)の色組み合わせに全て含まれる

という点です.

前者の性質は, より簡単な2x2の実装を可能にし, より上級者向けの4x4や5x5も可能にしています.

このゲームは究極的には「すべての色組み合わせを記憶する」ことが求められます. 後者の性質は, 段階的にボードを大きくしていった時に, 以前の記憶が無駄あるいは邪魔にならないことを保証します. 例えば友だちと遊ぶ時は3x3を使うが, 家ではより上級者向けの4x4でリーダーボードを狙うということも出来るわけです. 後者の性質がないと, 混乱します.

これらの性質は, 見て分かると思いますが色の組み合わせに対称性を持たせることで実現しています.

まるで奇跡のような話ですが, 実は後者はあとになってから発見しました. もともと, 幼児向けの2x2, 大人向けの5x5を実現したいと思っていて, そのためには対称性が必要だということはふつうなんとなく分かることだと思いますが, その中にrecursionが含まれてるとは想像出来なかったです.

実際にプレイしていて, 2x2の組み合わせがすべて3x3に含まれてるような感じがしたのでよく調べてみると確かにそうでした. 一般に関する証明はありません. 証明したい人は勝手にしてください.

(etiles report) Google Play Serviceのリーダーボードと連携させました

play.google.com

当初の予定ではリーダーボードの実装は正式リリース後と思っていたのですが,

  • このゲームはリーダーボードなしでは続けてプレイするモチベーションを保てない
  • リリースしたあとに難しい実装を追加するのは大変

ということでBetaでやることにしました. お楽しみください. 上のリンクをスマホから開くか, あるいはGoogle Playで"etiles"と検索してもらえば見つかります.

www.youtube.com

Google Play Serviceは, アカウントの管理やリーダーボードなど, モバイルゲームに必要な機能を無料で提供しています. アカウント管理は認証自体はグーグルアカウントと結びついていて, 他のアプリでログインしてると(通常はGMailとかでログインしてますよね)自動的にログインされます(そしてそれが要求仕様です). しかし, 本名でリーダーボードには載りたくないのがふつうなので, Gamers IDというのを設定することが出来て(というか自動的に要求されます), これが使われます. おれはGodAimAkiraです.

実装上の仕組みとしては, Androidの起動時にMainActivityを立ち上げるところで(実際には閉じてからまた開くケースを考えてonResumeに実装することが推奨されています)バックグラウンドのサインイン(signinSilently)を実行して, 失敗した場合のみIntentを表示します. その後はReactNative用とのブリッジが初期化されて, その中でアプリケーショングローバルなコンテキストを使ってサインイン状態に常にアクセスしつつ, リーダーボードへの処理(submitScoreImmediateなど)を実行するという感じです.

Androidのことがわからなかったので少し勉強が必要でしたが, 実装は自体は難しくありませんでした. しかし, なかなかリーダーボードにスコアを送ることが出来ずに嵌りました. リーダーボードが使えないとこのアプリは完全に無価値です. すでに100時間はゆうに時間をかけてしまっており, オープンソースにしてしまい開発実績として終わりにするのも少しためらわれるレベルになっていました. ノイローゼになってました.

症状としては, 「Google Playにリリースしたものはダメだが, ローカルでのデバグビルドやリリースビルドはスコアを送信出来る」というもので, 色々なことを疑って, 結果として副次的にgradle.buildを改善出来たりもしたので良かったとは思いますが, 根本的な原因を共有します.

Google Play Serviceのリーダーボードを利用する時には, アプリとリンクします. アプリには鍵がついており, リンク時にはアプリのパッケージ名と鍵のSHA1で認識します. リンクされたアプリから送られてきたリクエスト以外は弾くという仕組みです. リーダーボードは複数作ることが出来て, etilesの場合ではオープンβ用のbetaと, ローカルでのデバグビルド用のtestという2つのリーダーボードを使い分けています.

Androidのアプリを開発する時にサインをすることが必要です. デフォルトではデバグ用の鍵は自動生成されますが, リリース用には必要で, keytoolを使って作成します. その上で, 作ったkeystoreを使うように設定ファイルを書いたりすれば, ビルド時にサインをするという仕組みです. etilesの場合は, デバグビルド用にも鍵を用意してます. なぜかというと, 自動生成された謎の鍵ではリーダーボードとリンクすることが出来ないからです. そのためリリースビルドと同様に明示的に鍵を作る必要があります.

その上で, 以下のようにリーダーボードと鍵をリンクさせたために失敗していました.

  • リーダーボード (beta)
    • リリース用鍵
  • リーダーボード (test)
    • デバグ用鍵

しかしこれではGoogle Playから落としたAPKでプレイした時にリーダーボードに弾かれます. なぜかというと, Google Playに上げた時点で, Google PlayはAPKをサインし直すからです. 以下のページのUse Google Play Signingというのを見てください.

Sign Your App | Android Studio

このGoogle Play Signingという機能は使わないことも出来るのですが, ガイダンスに自然に従うと使うように設定されてしまうため, ほとんどの人は使うようになっていると思います. 使う場合, 自分で生成した鍵というのは正確にはupload時にしか使われない鍵であり, それ以降は捨てられてしまうのです.

なので, 動くようにするためには

  • リーダーボード (beta)
  • リーダーボード (test)
    • デバグ用鍵

のように設定する必要があるのです. こうすれば, ローカルのどのビルドでも, Google Play経由でもAPKが正常動作します.

Google Play Serviceを利用するとか, React-Nativeから使うとかに関しての知見はたまったので, 困っている方は相談してください.