Mahjong Handle の和了形10009件を分析してみた
はじめに
Mahjong Handle というゲームがあります。
麻雀の手をWordleするゲームです。理牌されているという条件のパズル要素が高く楽しめます。
ただ、このゲームは答えとなる手がどういう手なのかという情報がないです。 これが不明なまま挑戦するのはもやっとしますよね。 jsのコードの中に10009件の出現しうる和了形のコードが埋め込まれていたので、分析してみました。
TLDR
役の出現率
役 | 出現率 | 出現率(天鳳) |
---|---|---|
摸和 | 38% | 18% |
平和 | 32% | 20% |
一盃口 | 26% | 4.3% |
断么九 | 21% | 22% |
摸和のみ | 17% | - |
役牌1枚 | 17% | - |
役牌1枚のみ | 9.4% | - |
三暗刻 | 3.0% | 0.68% |
七対子 | 2.8% | 2.3% |
混一色 | 2.0% | 1.1% |
三色同順 | 1.6% | 3.5% |
役牌2枚以上 | 1.0% | - |
清一色 | 0.86% | 0.84% |
一気通貫 | 0.43% | 1.7% |
二盃口 | 0.34% | 0.04% |
混全帯么九 | 0.33% | 1.1% |
対々和 | 0.31% | 3.1% |
ほか | 0.37% | -% |
ほかの役(0.37%)は何がありえるかは楽しみのためにあえて記載しませんが、他にも様々な役がでる可能性があります。
役牌の出現率
役牌 | 出現率 | 出現率(天鳳) |
---|---|---|
白 | 3.7% | 7.8% |
中 | 3.6% | 7.8% |
発 | 3.4% | 7.8% |
場東 | 2.0% | 8.1% |
場南 | 1.9% | 0.16% |
北 | 1.1% | 1.6% |
南 | 0.99% | 1.9% |
東 | 0.9% | 1.8% |
西 | 0.82% | 1.8% |
和了形の飜数の確率
1飜 | 2飜 | 3飜 | 4翻 | 5翻以上 |
---|---|---|---|---|
58% | 28% | 8.9% | 2.8% | 2.3% |
理牌位置に対する牌の出現率
数値の単位は %。 Any は一枚でも出現する確率。 1が一番左で、13が一番右。和了は和了牌。
牌 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 和了 | Any | 牌 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
🀇(1m) | 16 | 6 | 2 | 1 | 25 | 🀇 | ||||||||||
🀈(2m) | 16 | 16 | 5 | 2 | 2 | 42 | 🀈 | |||||||||
🀉(3m) | 14 | 16 | 14 | 5 | 4 | 2 | 1 | 2 | 57 | 🀉 | ||||||
🀊(4m) | 12 | 13 | 14 | 8 | 6 | 3 | 1 | 1 | 3 | 59 | 🀊 | |||||
🀋(5m) | 9 | 11 | 11 | 8 | 7 | 5 | 2 | 1 | 1 | 3 | 59 | 🀋 | ||||
🀌(6m) | 8 | 9 | 10 | 9 | 8 | 6 | 3 | 2 | 1 | 3 | 60 | 🀌 | ||||
🀍(7m) | 6 | 7 | 8 | 9 | 9 | 7 | 4 | 3 | 2 | 1 | 3 | 59 | 🀍 | |||
🀎(8m) | 2 | 5 | 5 | 5 | 7 | 6 | 4 | 3 | 2 | 1 | 1 | 3 | 43 | 🀎 | ||
🀏(9m) | 1 | 1 | 4 | 2 | 4 | 3 | 2 | 3 | 1 | 1 | 1 | 2 | 25 | 🀏 | ||
🀙(1p) | 4 | 1 | 2 | 5 | 2 | 3 | 2 | 1 | 1 | 2 | 24 | 🀙 | ||||
🀚(2p) | 3 | 4 | 4 | 7 | 6 | 4 | 5 | 3 | 2 | 1 | 3 | 43 | 🀚 | |||
🀛(3p) | 3 | 3 | 5 | 8 | 8 | 8 | 7 | 5 | 3 | 3 | 1 | 4 | 58 | 🀛 | ||
🀜(4p) | 2 | 2 | 4 | 7 | 8 | 8 | 8 | 7 | 5 | 3 | 2 | 1 | 4 | 62 | 🀜 | |
🀝(5p) | 2 | 2 | 3 | 6 | 6 | 8 | 8 | 7 | 5 | 5 | 3 | 1 | 1 | 4 | 61 | 🀝 |
🀞(6p) | 1 | 1 | 3 | 5 | 6 | 7 | 8 | 8 | 7 | 5 | 3 | 2 | 1 | 4 | 61 | 🀞 |
🀟(7p) | 1 | 1 | 2 | 4 | 5 | 6 | 8 | 8 | 7 | 6 | 4 | 2 | 2 | 4 | 59 | 🀟 |
🀠(8p) | 1 | 1 | 2 | 3 | 3 | 5 | 6 | 5 | 6 | 4 | 2 | 2 | 3 | 42 | 🀠 | |
🀡(9p) | 1 | 1 | 1 | 2 | 2 | 3 | 3 | 3 | 3 | 1 | 2 | 2 | 25 | 🀡 | ||
🀐(1s) | 1 | 2 | 1 | 3 | 3 | 3 | 4 | 2 | 2 | 1 | 1 | 2 | 25 | 🀐 | ||
🀑(2s) | 1 | 2 | 2 | 4 | 6 | 5 | 6 | 5 | 4 | 3 | 1 | 3 | 42 | 🀑 | ||
🀒(3s) | 1 | 2 | 2 | 4 | 5 | 7 | 9 | 8 | 7 | 5 | 4 | 4 | 59 | 🀒 | ||
🀓(4s) | 1 | 2 | 3 | 5 | 6 | 9 | 9 | 8 | 6 | 5 | 5 | 60 | 🀓 | |||
🀔(5s) | 1 | 1 | 3 | 4 | 6 | 8 | 9 | 10 | 8 | 7 | 5 | 61 | 🀔 | |||
🀕(6s) | 1 | 2 | 3 | 4 | 7 | 9 | 11 | 10 | 8 | 6 | 60 | 🀕 | ||||
🀖(7s) | 1 | 2 | 4 | 6 | 8 | 11 | 11 | 10 | 5 | 59 | 🀖 | |||||
🀗(8s) | 1 | 1 | 3 | 5 | 6 | 10 | 12 | 4 | 42 | 🀗 | ||||||
🀘(9s) | 1 | 1 | 2 | 3 | 4 | 10 | 3 | 25 | 🀘 | |||||||
🀀(東) | 1 | 2 | 2 | 4 | 4 | 1 | 15 | 🀀 | ||||||||
🀁(南) | 1 | 1 | 2 | 4 | 4 | 1 | 15 | 🀁 | ||||||||
🀂(西) | 1 | 1 | 2 | 4 | 4 | 1 | 12 | 🀂 | ||||||||
🀃(北) | 1 | 2 | 4 | 4 | 1 | 13 | 🀃 | |||||||||
🀆(白) | 1 | 3 | 5 | 5 | 2 | 16 | 🀆 | |||||||||
🀅(発) | 1 | 2 | 5 | 5 | 2 | 15 | 🀅 | |||||||||
🀄(中) | 3 | 6 | 7 | 2 | 17 | 🀄 | ||||||||||
牌 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 和了 | Any | 牌 |
以上の表から考察すると、以下のような特徴があると分かります。
- 実践(天鳳)の出現率と似た傾向の和了形になる。平たい安い手が出やすく、変な高い手は出にくい。
- 自摸率が38%で自摸のみ率が17% → 自摸の回は45%の確率で自摸のみのゴミ手。
- 一盃口が通常の肌感覚より異常に出やすい(4% → 26%)
- 実践通り34567のような中央の牌は出やすい。么九牌は出にくい。
- (独立に)JustHit率が最大になる手は「🀈🀉🀊🀍🀍🀜🀝🀞🀓🀔🀕🀖🀗 🀕」
- 66%の確率で字牌を一切使わない手になる
宣伝
麻雀の牌効率をチェックするWebアプリを公開しているので麻雀に興味があれば一度遊んでみてください。
さいごに
分析に使ったコードはこちら。
ソフィー2やるつもりだったのになんで麻雀なんかやってるんだ
ISUCON11予選の感想戦:ユーザーを一人も増やさない戦略が最強で1373637点出た
はじめに
弊チーム百万円ドリブンのISUCON11の本戦出場が決まりました。 実はこれで本戦出場は連続5年目です。運がいいですね。 弊チームの予選当日の動きはメンバーのaokabiかnakarioが書いてくれると思いますので、そちらを御覧ください。
今回の問題の構成はこんな感じでした、シンプルで不必要な部分は削られており、今年も良い問題でした。
感想戦
さて、予選当日は449781点で7位通過できたのですが、我々は百万円ドリブンなので百万円にしか興味ありません。限界までチューニングをします。
感想戦では、この CloudFormation テンプレートを使うと予選と同じ環境が一瞬で構築できました。すごい。
目につくところを細々と直す
https://github.com/1m-yen-driven/isucon11q/tree/e235715f52ef2ddd15091d79b5d19db5cb2bfa27 予選一週間後、チームメンバーで細々とチューニングしていくことで60万点くらいまで行きました。
今回の問題は複数台構成でした。以下の構成にしていました。 PostCondition専用サーバーがいるので、DropProbabilityは0.0です。
- app 1:Nginx + GoApp (PostCondition以外)
- app 2:MySQL
- app 3:GoApp (PostCondition専用)
IsuConditionをRedisに乗っける
GetTrendを高速化しましょう。
PostIsuCondition のAPIで更新されるISUのコンディションのうち、GetTrendで参照されるのは「そのISUの最新の状態」のみです。 そこで、Redis のソート済みセットの出番です。Redisのソート済みセットでは、float型のスコアをキーにして値を保存でき、スコアを元にした検索ができます。スコアをタイムスタンプとすることで、最新の状態のみを取得することが可能です。(古いタイムスタンプのものが送られてくることもあるので、リストにpushしていくだけではだめなのです)
というわけで実装しました。ソート済みセットにCondition情報を全て載せるとEncode/Decodeに時間がかかるのでGetTrendで使用される最低限のみにしました。
... これで115万点ほどでました! Redis最強!
IsuConditionをRedisに乗っける(?)
あれあれ、このコミット、ちょっと待ってください。
これ、ローカルホストに繋がってませんか? PostConditionは3台目でやってるので、3台目のローカルホストに情報を追加しても、1台目のGetTrendで参照するローカルホストのRedisには情報が更新されて無くないですか?あれあれ?
え、じゃあGetTrend更新されて無くないですか...?
GetTrendを更新せずユーザーを増やさない戦略
ISUCONDITION アプリケーションマニュアル · GitHub
アプリケーションマニュアルを読むと、GetTrendは「ちゃんと更新されているとユーザーが増える」という機能のためのAPIのようです。なるほど。確かにベンチマーカーのログを見るとユーザーが増えていない。つまり、古参メンバーのみがずっと使い続けて新規メンバーが参入してこないアプリケーションになっていたようです。
ちなみに、 127.0.0.1
を 198.168.0.13
にして、ちゃんとGetTrendが更新されるようにすると、ユーザーがすごい速度で増えていきまたたく間にパンクしてFailしました...。
結局、GetTrendは最初のまま永遠に更新する必要がないことが分かったので、一回生成したら二度と更新しないようにし、ユーザーの存在チェックだけRedisに乗せたところ 1373637点でました。
ゆーざー、ふえてない
まとめ
ユーザーが増えると捌ききれないかつ、初期状態のユーザー数のままでも130万点まで行くので、今回の問題はユーザーを増やさないのが最善だと言えそうです。つまり、手を加えると逆に遅くなるAPIがあるということで、気をつけないと行けないな...と思いました。
今年こそ100万円欲しい
AtCoder Beginners Selection を ImageMagick でやってみた!
はじめに
ImageMagickというプログラミング言語があることを皆さんはご存知でしょうか?
この言語は汎用的なプログラミング言語のはずなのに、何故か画像処理用途としてしか使われていないようです。もったいないですよね。 そこで、プログラミング言語ImageMagickの汎用性を広めるべく、競プロ入門に最適な問題が集まっている AtCoder Beginners Selection - AtCoder をImageMagickで解いてみました! この記事を読んでぜひ皆さんもImageMagickで競技プログラミングを始めてみてください!
0問目 cat
まずは前提として入出力処理の書き方から始めましょう。 ImageMagick では入力のバイト列を受け取ってそのまま出力するcatプログラムは以下のように書くことができます。
convert -depth 8 -size 1x1 gray:- -
実際に echo "いめーじまじっく" | convert -depth 8 -size 1x1 gray:- -
と実行すると いめーじまじっく
と表示されます。各コマンド・引数の意味は以下の通りです。
convert
: ImageMagickが提供するコマンドの一つ。画像変換をしたそうなコマンド名前ですが、そんなことはさせてあげません。-depth 8
: 入力文字列を1バイト単位で処理するための引数です。何も指定しない場合-depth 16
となり 2バイトずつ処理してしまうので注意です。-size 1x1
: 1x1毎に区切るための引数です。gray:-
:-
は入力を(ファイルでなく)標準入力から取るという意味です。gray:-
とフォーマットを指定(raw gray)しています。
1問目 ABC081A - Placing Marbles
それでは早速解いていきましょう。この問題は、0 or 1 の が与えられるので、足し算をするだけの問題です。
例えば 入力101
には 2
を、 入力 000
には 0
を出力します。この問題のImageMagickでの解答コードは以下になります。
convert \( -size 1x1 -depth 8 gray:- \) \( -resize '2x1!' -fx ' sum = (u[0] - 48/256) + (u[1] - 48/256) + (u[2] - 48/256); i == 0 ? sum + 48/256 : 10/256 ' \) -
このコードを code.sh として保存し、実際に echo "101" | sh code.sh
と実行すると 2\n
が表示されます。
各引数の意味は以下の通りです。
\( -size 1x1 -depth 8 gray:- \)
: 先程の例と同じく入力を1バイト単位でパースします。\( -fx '...' -resize '2x1!' \)
: ↑のパースにより、入力は配列u
の中に保存されています。これを-fx
というオペレータ を使って頑張って望む出力に変換します。ImageMagickでは予め出力のサイズを定数で定めておく必要があるので-resize '2x1!'
として出力は2バイト(答えと改行)であると宣言します。1
さて、-fx の中身は以下でした。
sum = (u[0] - 48/256) + (u[1] - 48/256) + (u[2] - 48/256); i == 0 ? sum + 48/256 : 10/256
u[0] などの中身は[0,1]の範囲で正規化されたASCIIコードとして入っており、'0' なら 48/256 が、 '1' なら 49/256 が格納されています。 i == 0
、つまり出力の1文字目ならその総和sumを正規化されたASCIIコードとして出力し、そうでない場合、つまり出力の2文字目なら '\n' のASCIIコードである 10 を 正規化されたASCIIコード 10/256 として出力しています。直感的ですね!
2問目 PracticeA - Welcome to AtCoder
以下のようにスペース区切りの3つの数字(範囲は[1,1000])と文字列(長さは最大100) が与えられるので、その数字3つの和と文字列を出力する問題です。
72 128 256 myonmyon
があれば
456 myonmyon
と出力するわけですね。この問題のImageMagickでの解答コードは以下になります。
convert \( -size 1x1 -depth 8 gray:- \) \( -resize '110x1!' -fx ' for((qa=0,qx=0),abs(u[qa]-10/256)>=1/256,(qx=qx*10+floor(u[qa]*256-48),qa++)); for((qb=qa+1,qy=0),abs(u[qb]-32/256)>=1/256,(qy=qy*10+floor(u[qb]*256-48),qb++)); for((qc=qb+1,qz=0),abs(u[qc]-10/256)>=1/256,(qz=qz*10+floor(u[qc]*256-48),qc++)); sum=qx+qy+qz; txt=i+qb+1<n?u[i+qb+1]*256:0; ia=floor(sum>=1000?sum/1000:sum>=100?sum/100:sum>=10?sum/10:sum)+48; ib=floor(sum>=1000?sum%1000/100:sum>=100?sum%100/10:sum>=10?sum%10:-16)+48; ic=floor(sum>=1000?sum%100/10:sum>=100?sum%10:sum>=10?-16:txt-48)+48; id=floor(sum>=1000?sum%10:sum>=100?-16:txt-48)+48; ie=floor(sum>=1000?-16:txt-48)+48; (i==0?ia:i==1?ib:i==2?ic:i==3?id:i==4?ie:txt)/256 ' \) -
このコードを code.sh として保存し、実際に echo "72\n128 256\nmyonmyon" | sh code.sh
と実行すると 456 myonmyon\n
と表示されます。
各引数については先程の問題と同様の仕組みです。出力の長さは最大110文字なので、-resize '110x1!'
とし、なにもない場合は '\0' を出力しています。
このコードの -fx
は冗長ですが、本質的には以下のようなコードとなります。
for((qa = 0, qx = 0), u[qa] != 10/256, (qx = qx*10+u[qa]*256-48, qa++)); for((qb = qa+1, qy = 0), u[qb] != 32/256, (qy = qy*10+u[qb]*256-48, qb++)); for((qc = qb+1, qz = 0), u[qc] != 10/256, (qz = qz*10+u[qc]*256-48, qc++)); sum = qx+qy+qz; txt = i+qb+1<n ? u[i+qb+1]*256 : 0; ia = sum>=1000 ? sum/1000 : sum>=100 ? sum/100+48 : sum>=10 ? sum/10+48 : sum+48; ib = sum>=1000 ? sum%1000/100+48 : sum>=100 ? sum%100/10+48 : sum>=10 ? sum%10+48 :32; ic = sum>=1000 ? sum%100/10+48 : sum>=100 ? sum%10+48 : sum>=10 ? 32 : txt; id = sum>=1000 ? sum%10+48 : sum>=100 ? 32 : txt; ie = sum>=1000 ? 32 : txt; (i==0 ? ia : i==1 ? ib : i==2 ? ic : i==3 ? id : i==4 ? ie : txt) / 256
ImageMagickでは内部的にはQ16で処理するので素朴に書くと精度の問題で想定と少し異なった出力をしてしまいます。そこで元のコードでは適宜floorを入れたりしているわけですね。 コツとして、128/256と129/256あたりの境界に注意しておくと吉です。 ImageMagickの変数名には数字が使えないので適宜a,b,c,とアルファベット順でこのコードでは変数を宣言しています。変数の説明は以下の通りです。
- qa : 最初の改行文字のindex
- qx : 1つめの数字を10進数としてパースした値
- qb : 2つ目の区切り文字である空白文字のindex
- qy : 2つめの数字を10進数としてパースした値
- qc : 3つ目の区切り文字である改行文字のindex
- qz : 3つめの数字を10進数としてパースした値
- sum : 答えとなる3つの数字の和
- txt : 文字列を出力する場合、その出力場所で出力すべき文字。 n は入力の長さが入っています。
- ia..ie : 1文字目から5文字目までは文字列を出力するか数字を出力するか入力に依存するので、それに応じて分岐して計算した出力文字。
最後に
画像処理だけでなく競プロまでできるなんて、ImageMagick は最高のプログラミング言語ですね。みなさんもぜひImageMagickで競プロをしてみてください!
なお、僕はここまで解いただけでやる気力が失せたので、もうImageMagickを画像処理用途以外には使わないと思います。
- 実は頑張れば出力を可変長にできるかもしれません。↩
猫島でねこがねこでほわわぁぁぁ
みやぎけんのいしのまきにねこのしまがあってね
ねこがたくさんいてね
ねこがねこで
ねこねこで
ねこー!!!!!!!!ってなって
ねこほわぁ!!!!!ってねこで
ごくらくねこねこねこで!!!!!!
もう!ぐへへへへ!!!!!!!!ってかんじで
ぼへぇぇ!!ねこ!!!ねこ!
うへへへへへへ
ぐへへぐへぐへ
ねこ!ほわあぁぁぁぁ!!
ISUCON10予選の感想戦をして7827点を出した
はじめに
弊チーム百万円ドリブンのISUCON10の本戦出場が決まりました。
予選当日の動きはメンバーのgnuの記事、aokabiの記事 に書かれているのでそちらを御覧ください。チームメンバーが最強なので僕は歌って踊っていただけで突破できました。感謝。僕は当日色々躓いたりして結局まともに貢献できなかったのでまじで感謝...
ISUCON用にこういうDBとの関係性可視化ツールを作っているので毎回使っているのですが、今回の予選の問題は上図のようにシンプルな関係となっており、非本質的な部分が削られているのだなぁと感じました。
感想戦
さて、予選が終わった段階で21位・2281点のスコアが出ていたのですが、我々は百万円ドリブンなので百万円にしか興味ありません。限界までチューニングをします。
予選当日でメンバーが重たいところを殆ど潰してくれたので、残りは getLowPricedChair
、getLowPricedEstate
、searchChairs
、searchEstates
だけでした。この記事ではこの処理をオンメモリにしてMySQLへの問い合わせオーバーヘッドを無くすというチューニングを行い、7827点を出します。
リポジトリはこちら。
chair, estate のオンメモリ
よく見るとchairs・estateのデータはそれぞれ35000件しかありません。またメモリも潤沢に2GBあるため、まるでオンメモリにしろと言われている気配すら感じます。Goのアプリ上でオンメモリにし、データの検索・追加・更新をO(logN)で行いたい気持ちになります。
getLowPricedChair
, getLowPricedEstate
こちらは要するに、「データ全N個の中から値段の昇順でK個取得せよ」というクエリです。 データはオンラインで更新される可能性があるため、平衡二分探索木のデータ構造(挿入・検索がO(logN)ででき、常にソートされていてk番目の値がO(logN)で取れる)に乗せればよさそうです。 ここの探索木は標準ライブラリにないため自分で書いてもいいのですが、本質ではないのでhttps://github.com/wangjia184/sortedset を使うことにします。 それぞれの値段をソートの順序として用いる平衡二分探索木を使えば簡単にオンメモリにできますね。
searchEstates
こちらは要するに「データ全N個の中から、Rent・Height・WIdthで条件を絞り込み、Popularityの降順で並べたときに、[A,B]番目のデータを取得せよ」というクエリです(本当はFeaturesも見る必要がありますが殆どクエリが飛んでこないので無視します)。 また、Rent・Height・Widthはそれぞれ4種類(例:Height < 80, 80 <= Height < 110, 110 <= Height < 150, 150 <= Height) のいずれかであり、絞り込み条件に含まれない場合もあります(例:Heightの指定なし)。
結論から述べると、Popularityをソートの順序として用いる前記の平衡二分探索木を計125個、5x5x5の三次元配列として持てば、O(logN)でクエリ・追加・更新にそれぞれ対応できます。 条件が4種類(例:Height < 80, 80 <= Height < 110, 110 <= Height < 150, 150 < Height)あり、それを0,1,2,3番と対応させます。条件指定なしの場合は4番と対応させます。 例えば「Rent指定なし・80 <= Height < 110・110 <= Width < 150 」のクエリは、4番・1番・1番と対応します。更新のときは0~3番の対応するものと4番を更新すればよく、計8(=23)箇所更新すればよいですね。
searchChairs
こちらも殆どsearchEstatesと同じですが、条件が更に追加で3つ(Color, Kind, Depth)増えます。
これらの条件も同様に扱うと、前記の平衡二分探索木を計56875(=5x5x5x7x13x5)個、5x5x5x7x13x5の六次元配列として持てばO(logN)でクエリ・追加・更新にそれぞれ対応できます。
更新が64箇所必要ですが、まぁこれは仕方がないでしょう。
これを愚直に実装すると余裕でメモリ制限2GBはオーバーするので気をつけましょう。僕はこれでswap領域を作らずにメモリを食い尽くしたせいでサーバーが1台死んでしまいました
さいごに
やったことはISUCONというより競プロですね。
感想戦として上記の残りネックになっていた箇所に対してオンメモリ対応をすることで7827点を出すことができました、やったぜ。
追記:当初は7670点として記事を公開していましたがもう一度回したところ7827点が出たので更新しました。
最高のインターネットと文脈の破片たち
この記事は KMC Advent Calendar 2019 - Adventar の13日目の記事です。
前日の記事は zeke さんの EDPC A~M問題についての備忘録 - Qiita でした。
ところでこの記事は怪文書の類の記事なので、 怪文書に慣れていない人は明日の Strelka さんの 闇鍋をした話 - strelka_dogのブログ を読みましょう!
はじめに
「最高のインターネットは文脈の破片たちから形成される」
これはとある人物のインターネット上での呟きです。 これについて述べることは無粋な行為なのですが、ここではあえてその禁忌を犯してみましょう。
みなさんは、インターネットに疲れていませんか。 「○○がxxしたから嫌だった」「○○がxxしてるwww」「xxするなんて信じられません!」「バカはすぐxxする」のような呟き・投稿、 こういう悪い感情の共有は巷に溢れていて、気を付けていないといつの間にか摂取してしまい、精神が徐々に疲弊していきます。
また逆に、「○○がxxだったから嬉しい!」「○○がxxしてくれた!」「xxするの最高!」「天才はxxしている」のように、良い感情の共有も溢れています。 これらは悪い感情よりは精神への影響は少ないのですが、これも他人への劣等感が少しずつ刺激され、精神を疲弊させる原因の一つとなります。
上記をまとめると、インターネットでの感情の共有が精神を疲弊させているのではないか、という考えが導かれます。 「最高のインターネットは文脈の破片たちから形成される」とはつまり、精神を疲弊させない「最高のインターネット」は、 感情を抜き取りただフォーマットに沿った事実だけが次々と投稿される「文脈の破片」から形成される、ということを述べているのだと私は解釈しました (この解釈は私個人によるものであり、当然「最高のインターネットは文脈の破片たちから形成される」と考えた人物の解釈とは異なる可能性が大いにありますので予め断っておきます)。
#kashi-tweet
ここからは文脈の破片たちから構成されるインターネットを紹介します。
#kashi-tweet
は、KMCのSlackのチャンネルの一つで、その名の通り歌詞ツイ(歌詞の一部を投稿すること)だけが流れます。
このチャンネルは2016年11月5日に突如現れ、今日まで寂れることなく残っています。
#go-go-575
#go-go-575
も、KMCのSlackのチャンネルの一つで、その名の通り575(≒川柳)だけが投稿されます。
このチャンネルは2015年3月3日に現れ、今日まで残っています。
Nuita
部員が作成したNuita というSNSがあります。 このサービスの内容について言及するのは不適切な気がするので、以下の記事を読んでください。
#飛ぶことは救いではない
文脈の破片を投稿するのが上手な人が居て、その人が文脈の破片を投稿するのでそれを愛であっていました。
この文脈の破片は質が高く、昨年の夏コミで本にして出しました。 現在Boothで公開中です ( 飛ぶことは救いではない合同誌 - tobusuku - BOOTH )。
応用
折角なので現実のインターネットに応用してみましょう。 今回はTwitterを「漢字の破片だけが流れるSNS」に改造してみます。
5秒で思いつく以下のjsを実行します。
setInterval(()=> document.querySelectorAll("p.tweet-text").forEach(x=>x.innerText = (x.innerText.match(/[一-龠]/g) || []).join("")),1000)
精神に悪影響を及ぼしやすかったあのTwitterが、文脈の破片を紡ぐ最高のインターネットへと華麗に変身しました! やったね!
さいごに
明日の記事は Strelka さんの 闇鍋をした話 - strelka_dogのブログ です。たのしみ!
ポケモン剣盾でマスボ級にいったノーマル統一パの覚え書き
ノーマル統一でマスボ級到達!!チュートリアル終了です!#ポケモン剣盾 #NintendoSwitch pic.twitter.com/Cm2btIHUIQ
— むらため (> <) (@paradigm_9) 2019年12月5日
だいたい「エレザード・ホルード・メタモン」の並びになりがち。
死ニーゴとかの面倒そうな相手が2体居るときにはタチフサグマが刺さるので入れる。 (死ニーゴはナイトヘッドやたたりめでしか攻撃できないことが多い(うずしおとかもあるのにね)ため殆ど選出されないので死ニーゴだけなら無視している)。
格闘対策は、イエッサン。 ルカリオ・ローブシンが居ると大抵出してくれるのでイエッサンで叩く。壁ロンゲもだいたい悪を見てフェアリーわざしかないのでイエッサンのサイコメーカーで処理できる。 ルチャブルはダイマックスイエッサンで倒すしか無いけど難しすぎるのでこれは出てきたら負けでいいです。
カビゴンは...環境外の強そうなやつがいるときに出すと壁になってくれるけどあんまり役に立ったことがないかも...バイウールーに変えようかな...
エレザードはとにかく強くて、バンドリをきあいだまで倒せる。 エレザード先手からのスカーフドリュのじしん連打の負け筋を引かなければだいたい勝てるのでカモ。バンギから入るとほぼ勝ち。 ダイマックスじゃくほで倒されてもホルードがいればばかぢからで処理できるし、ホルードが居ない場合は最大まで積ませてメタモンでパクって全抜きできる。 サザンドラやアイアントを上から倒せるのもロトムには無い強み。 相手の知識がないとエレザードに水技を打ってくれることもあるし、そうでなくてもウォッシュロトムには対面勝ちできる。
スカーフホルードが結構強くて、スカーフ・タスキ・ハチマキ・ダイマックスのどのドラパルトでも対面イカサマで勝てるほか、ドリュも対面なら打ち勝てる。 ミミッキュもじしん連打でも倒せるし剣舞積み後ならイカサマでも倒せる。
メタモンが最強で、ダイマックスして強化したりじゃくほしてくれたらそれをまるまるパクってタスキか素早さ乱数勝利で打ち勝ったあと全抜きができるほか、 普通に状況に合わせて残りのメンバーでは処理しにくい相手を強引に処理できるので最強。 スカーフよりもタスキのほうが強い。スカーフだと(ほぼ)確定対面勝ちしか利点が無いが、タスキだと技が拘られないので状況に合わせて柔軟にへんしんできる。 先制技はあんまり見ないしミミッキュはかげうち合戦するだけだし積みエースに強すぎる。 メタモンにも弱点はあって、みがわり状態の相手にはへんしんができないのと、ばけのかわはコピーできない(相手のばけのかわが剥がれていなくてもこちらのばけのかわは剥がれてしまっている)のが痛い。みがわりとばけのかわは絶対に剥がすしかない。 ギルガルドのバトルスイッチもコピーできない(キングシールドを使っても変わってくれない)ので、なるべくブレードフォルムの方をへんしんできるようにしておきたい。 あとへんしんするとPP5になるのは弱みでもあり強みでもある。最後に害悪系が残ったときにへんしんするとPPで負けてわるあがきで死んでしまう。しかし仲間が居るとPP5にしてリセットができる。隙きを見て入れ替えれば無限のPPを得られるので1回勝てた。
よくある負け筋はエレザードとアーマーガー対面からのでんき技読みスカーフドリュ変えでじしん連打されること、これを読んでイェッサンが出せれば好転するけどむずい... 後はヌオー・トリトドン・ゴリランダー・オノノクス・(スカーフ)ヒヒダルマ・ルチャブルはかなり相性が悪い. 上三体は読んでダイマックスイエッサンで処理するしかない。下三体は自身を強化してくれないし有効打も無いのでどうしようもない。出てきたら負けです。 カビゴンをこれらに有利なポケモンに変えたほうが良さそう。
あとメタモンで環境のパーティの技構成を完全に知れるため、こちらも今後それを対策できるのが一番偉かったかもしれない