テストステ論

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

(etiles report) タイルのデザインを変えようかと思っている

etilesの面白さは, タイルの裏表のセットが決まっていて, プレイしていくとこれがなんとなく染み付いてくるため, 運ゲーから実力ゲーになるところにあると思っている. 例えば, この黄色の裏は赤の確率が高いなどを瞬時に判断していくことで手数を少なくして, 素早く回答することが出来る. 今リーダーボードのトップレベルにいるプレイヤーは意識的かは知らないがこれをやっている.

一方で, これが出来ないといつまで経っても運ゲーから抜け出せず, 面白みを感じることは出来ない. 今のetilesのような小規模なゲームに対して初期投資としてタイルの組み合わせを全暗記してくれる人はほぼいないと思われるため, このラーニングカーブのきつさは導入の障壁になる.

今, これを解決する策として, 色に数字を振るということを考えている.

f:id:akiradeveloper529:20180626175627p:plain

色に数字を振った時, etilesでは「偶(奇)数の裏は奇(偶)数のどれか」という性質を持つことが明らかになる. これならば, 色を覚えるよりはわかりやすい. また, 現在etilesが5x5までサポートしていないのは色盲者にとっても認識可能な色のセットとして明らかなものが10個だったからだ. 全部白塗りでやってみた時のモックが以下となる. このように色を消せば理論上はNxN一般についてゲームを提供することが出来る.

f:id:akiradeveloper529:20180626175628j:plain

しかしこの場合には「どの色が足りてないか一発で分からない」という視認の難しさが問題として上がる.

そこで今おれは, 既存のデザインの上に数字を乗せるという折衷案を考えている.

視界でエイムすればクロスヘアがなくても当たる

www.youtube.com

視界速度があなたにとって正しい場合,

  • クロスヘアがなくてもフリック出来る
  • どこを見てるのか分からなくなった時でもPSAをやれば三角法の原理で見えないクロスヘアを見つけることが出来る

視界速度が正しいとはこの逆なのだ. 1つ目がn0thingの理論. 2つ目はそのPSAへの応用.

PSAは正確にやることが難しいので, 短い距離についてフリックした時にピッタリ合うセンシを見つける方がいい. その上で, PSAを試験薬として使うとよい.

日本でもっともn0thingの理論に近づいたのはr6sのkenkiで

www.youtube.com

の中では壁撃ちによる調整が紹介されている. 方法自体は実はAVAのshakaも似たようなことを言ってるのだが

www.youtube.com

なぜkenkiの方が近いかというと,

  • フリックしてる. shakaのは遅い
  • kenkiは手首でエイムしていることを, 彼の手元動画から知っている

からである.

やっていることはn0thingの理論に近いのだが, その理論背景の説明がないので京大入試においては0点となる. 手首だけでやるのが良いことの説明があれば100点だった.

ただ, r6sやAVAのように比較的エイムの重要性がCSGOに近いゲームで同じセンシ合わせにたどり着いていることという事実は, n0thingの理論の正しさをより確からしくするものである. OWのことは知らない. OWはどうでもいいしマルス先輩にでも聞いてりゃいい.

電話をかけてくるな。封筒を送ってくるな。

インターネットの発達した現代社会において, 早く滅んだ方が良いと思ってるものがある. 電話と封筒郵便だ.

まず電話. おれは知らない電話番号から電話がかかってきてもまず100%とらない. 知らない電話番号はその電話番号をググってどの会社の電話番号かを調べた上で再コールしてきた場合のみとる. これについては面倒なので, 会社だとかは電話をかけた時に名前が表示される機能があったら便利だと思う.

電話をかけるということは電話をかけたらとってもらえると思ってるのだろうが, 知らない電話番号に出ることはリスクの高い行為だ. まず, こちらが男性なのか女性なのか, 何歳くらいなのか特定されてしまうだけでも危ない. 特に女性は危ない. それを元にしてストーカー行為に発展する可能性もある. 名字などは絶対に名乗ってはならない. 会社などで電話対応をしてる人は自社名を名乗ることが習慣づけられてるのでうっかり名字を言ってしまいそうだ. そんなやつが家族にいたらトロールでしかない.

次に封筒郵便. 例えば保険会社とかクレジットカード会社とかから送られてくる封筒だ. あれもやめた方がいい.

まず, 封筒を開けるということは見たことになってしまうということだ. 可能性は低いものの, 開けた瞬間に爆発する可能性だってある. だから本当に自分に関係あるかわからないのに封筒を開ける行為はリスクが高い. だからおれはほとんどの封筒はそもそも開けない. そしてゴミに出すわけだが, これはゴミに個人情報を含めてしまうことになる. そんなものを送ってくるというのは害でしかない. 重要書類を燃やすためだけの特別サービスというのが実はヤマトなどが提供しているのだが, はっきり言ってそこまでするのはめんどくさい. もちろん自分でシュレッダーにかけるのもめんどくさい.

もし締切がすごく重要なものであれば封筒の表に締め切りを書くべきだ. それならば開ける確率は高くなる. そもそもその程度のこともしないのは, 送ったら開けてもらえると勝手に思ってる甘えにほかならない. 開けてもらう努力を怠るべきではない.

開けた場合もほとんどの場合, 読みにくい. 特に新しいサービスがありますと言われても, 今のものとどう違うのか読まないとわからないし, 価値があるかどうかわからないものを必死に読み解こうとするわけがない. だからせめて, 15秒間斜め読みして分かるように一枚のまとめを添えるべきだ. 論文でいうアブストラクトだが, それで関心をもってもらえなければ本編の方を読んでもらわなくても構わないくらいの気持ちで, そのまとめは本気で作った方がいい. 書きたいことを全部べたーっと書かれた文章など, よほど暇な人間じゃないと誰も読まない.

共通するところとして, 何かしたら必ず応答してもらえると思ってるところに昭和感がある.

これらのシステムでは時代遅れで, もうemailで送ってほしい. 電話の方が効率が良い場合も, まずはemailでコンタクトをとってからしたらいい. まぁ, Githubが設計図共有サイトな国では無理か.

ゲーム間センシはMonitor Distance 0%で合わせろ

昨日, ゲーム間でセンシを合わせるためには, マウスを微小距離動かした時のモニター上の移動距離を同じにするという考え方を示した.

akiradeveloper.hatenadiary.com

これはつまり, mouse-sensitivity.comでいうところのMonitor Distance 0%と同じであるという話もした.

今回は, 理論ではなくおれの体感の話をする.

おれがCSGOで使っているセンシは1.225 (800dpi). これがOW, Sniper Elite 4 (SE), Far Cry 5 (FC)の3つのゲームでMonitor Distance 0%, Viewspeed v2でどのセンシに変換されるかを以下に示す.

Game FOV Monitor Distance 0% Viewspeed v2
OW 103 3.85 3.93
SE 82 2 5
FC 75 0.7050 0.8091

この動画の途中でおれの体感について述べた.

youtu.be

実際にViewspeedで合わせた5というのは, Monitor Distanceで合わせる場合にはCSGOで1.35に相当する. 実際に5でやると視界がぷるぷるする具合が1.35でやった場合と同じように感じた. SEやFCのような遊びゲーの場合はそれほどエイムを突き詰めなくても良い(特にSEは全く関係ないと言ってもよい)ため, 今までViewspeedでやっていても気づかなかったが, 実際に確かめてみると確かにViewspeedで合わせると速いということがわかった. 例えばSEの場合は1.35相当ということだから, この「速い」という感覚は正しいと思う. なぜならばこのセンシはCSGOでやると全く使い物にならないレベルのハイセンシだからである.

逆にOWの場合はCSGOとFOVが近いこともあり差が出ないため, どっちでもそれほど差は感じず, 結果としてViewspeed v2によるセンシ合わせが悪いことに気づけなかっただけならず, OWでいいと思ったセンシをCSGOに逆輸入しての行ったり来たりを繰り返して混乱していたものと思われる.

以上より今のおれの考えとしては, Monitor Distance 0%でセンシを合わせることは間違ってないというものであり, みなさんも是非使っていただきたい. mouse-sensitivity.comがない場合でも, マウスの振り向き距離を正しく測ることが出来るのであれば, 先のブログに示した計算式によって合わせることが出来る.

エイム数学: ゲーム間で視界速度を一致させる方法

2つのゲーム間(例えばCSGOとOW)でセンシを合わせると言った時に, FOVの影響を考えず振り向きに必要なマウス移動距離で合わせてしまう人がいるが, これは間違ってるという話をする. その上で, どういう計算式によって合わせれば良いかという話をしようと思う.

f:id:akiradeveloper529:20180610172634j:plain

まずFOVとは何かというと「全方位360度のうち何度分を平面のディスプレイに投影しますか?」という数値だ. 例えばCSGOでは106.26度, OWではデフォルトで103度となっている.

マウスをある距離動かした時に, どのくらいの角度を進むかは, 振り向きの逆数で表すことが出来る. 例えば振り向き3cmの人と30cmの人と比べると, 1/3と1/30で後者の方が10倍角度が進まないということが言える.

例えばFOVの異なるゲーム間で振り向きを一緒にしてしまうと何が起こるかというと, FOVの小さい方では視界速度が速くなる. これは例えばPSAの結果に影響する. たとえば極端にFOV10度と100度のゲームがあったとしたら, これは自明だろう. (試しにOWのFOVを80度に下げてみると良い) だから, FOVの異なるゲームではFOVを意識した変換を行う必要がある.

ではどういう変換をすれば良いか?問題は円周には膨らみがあるのにディスプレイには膨らみがないことだ. これが誤差になるため, モニター上の距離を一致させるという方式では「では何度ないしは何パーセントの範囲でモニター距離を一致させるのか」で結果が変わってくる. これが, mouse-sensitivity.comのMonitor Distanceの設定でMatch Atというパラメータがある理由である. これは75%が推奨されているが, 特に数理的な根拠があるわけではない.

そこで考えられたのが視界「距離」ではなくて「速度」(つまり微分)に着目するという方式で, これがmouse-sensitivity.comではViewspeedという形で実装されている. これについて説明する.

f:id:akiradeveloper529:20180611142942j:plain

マウスをいくら振っても, 視界は常に画面の真ん中にある. だから, 大きな視界移動であっても, 微小な視界移動の積み重ねと考えることが出来る. こう考えると, 微小な視界移動について着目しても良いと分かる. (そもそも視界速度の定義はdθ/dt)

f:id:akiradeveloper529:20180610173845j:plain

上の図でθが極めて微小な時, 円の曲がりは無視することが出来る. つまり, 円上の動き(つまり振り向きの逆数)とモニター上の距離の関係は, 図にあるようにαで表すことが出来る. これより, α = cos(θfov/2)が言える.

今目指すことは, マウス上の微小移動距離に対してゲーム間でモニター上の微小移動距離のモニター上の割合を一致させることだから, 前者を固定して議論しても良く,

1 / 振り向き1 * cos(θfov1 / 2) / sin(θfov1 / 2) = 1 / 振り向き2 * cos(θfov2 / 2) / sin(θfov2 / 2)

という関係が得られる. ここで添え字の1,2はゲーム1,2のこととする.

実際にmouse-sensitivity.comを使って確かめてみる. 例えばScreaMが使ってる1000edpiというCSGOのセンシの場合, 一周は41.5637cmである.

上の式は,

振り向き1 * tan(θfov1 / 2) = 振り向き2 * tan(θfov2 / 2)

となるから,

>>> 41.5637 * math.tan(106.2/2/180*math.pi) / math.tan(103.0/2/180*math.pi)
44.033463805534595

となって, OWでは3.93が適正と分かる.

しかし, これは, mouse-sensitivity.comのViewspeedとは違う. むしろただMonitor distanceで0%の場合を再計算しただけに相当する. Viewspeedはどうやらモニターのアス比や2D-3D変換も考慮に入れているようだが, おれとしてはFPSにおいてはほとんどのエイムはヘッドラインを保って水平方向に動かすだけであり, 縦横を平等に扱うこと自体が間違ってると思うので, 今回紹介した考え方に間違いがないのであれば, この方法でいきたいと思う.

(etiles report) Android版を正式リリースしました

Google Playで"etiles"で検索してダウンロードしてね!!

Android版のリリースに向けて, iOS版の実機テストを行った. なぜかというと, Android版とこれから出すiOS版は出来るだけ同じソースコードにしたいので, iOSで破綻するコードならAndroid側に妥協してもらう必要があるからだ.

そのために, ipod touchをアキヨドで買ってきた. これは23000円もした.

f:id:akiradeveloper529:20180609024703j:plain

react-nativeで作ってるので当たり前ではあるが, iOSでも動作した.

iOS版は6月末に出せればいいかなと思っている. お楽しみに

(writeboost report) v2.2.9をリリースしました

github.com

4.15の段階でACCESS_ONCEが消去されたことでコンパイルが通らなくなったため, 各方面から「いつになったら修正版がリリースされるんだ」と突きまくられていたが, おれはイータイルズの開発に集中していたため, なかなか手を戻せなかった. よってなんと8ヶ月ぶりのリリースとなった.

修正コミットのうち1つはAllenという学生がやってくれたものだが, コードのことについて熱心に質問してくると思ったら, 学校のプロジェクトでライトブーストの性能測定をする目的があったようだ.

github.com

まぁ, 正直に言って何やってるか正しく読み取ることは難しいし, 教育は学校の先生に任せるとする. ただ, ライトブーストが学校の教材として採用されていることは素直に嬉しく思う. ライトブースト開発の目的の1つは, このコードをLinuxカーネル開発の入門として使ってもらうことだからだ.

v2.2.8の間にあったもう1つのニュースは,

RedIRIS - Jornadas Técnicas de RedIRIS

ライトブーストを学内のサーバで使った成果をスペインの学会で発表してもらったことだ. スペイン語なので何を言ってるかはわからないがとても速いみたいなことを言ってるような気がする.

おれがイータイルズを開発しているうちにライトブーストは着実に広がっており, たぶん今後も広がり続ける. 細々とメンテナンスだけはしていこうと思う.