https://note.mu/r_nikaido/n/ncac16b5a1001

これを読んでの反論というか雑感。

なお自分の腕前はざっくりいうとS+下位、おもにスピナー使いのエンジョイ勢。1のときはS+に上がれたことがあったかどうか、という程度のS帯。

で。

自分の違和感というか異論の根幹は

ゲージを溜めに溜めた貴重な必殺技

というスペシャルの位置づけではないかとおもった。スペシャル、そういうんじゃないでしょ……。名前がいうほどには特別感はないし、せいぜいブキの機能のひとつぐらいでしかないようにおもう。それに必殺技ってのもちょっとちがう。

敷衍して、また全体的な論旨からかんがえるに、この文章の著者はスプラトゥーンをFPS/TPSの一種であって、スペシャルを発動させて敵を蹂躙するなどのアクションを楽しむゲームとして位置づけているのではないか？

自分はあんまりそうおもってない。キル数そのもので勝敗が決するわけじゃないわけで、ある特定のルールの上での勝敗を決するゲームであるとおもっている。敵と戦って撃ち勝つのは大事なんだけど、それだけじゃないし、だからこそユニークな面白さのあるゲームなんではないか……べつないいかたでいうと、ぶっちゃけ自分はエイムもゴミだしぜんぜん戦えないプレイヤーなわけなんで、そういうゲームだとつらい。よくつかってるスピナーもだいたい補助的な役割が多いし。

そういう観点からいうと、スペシャルは状況におうじて的確につかうもので、キルをねらいにいくときもあれば、それ以外の目的でつかうこともある。たとえばマルチミサイルやハイパープレッサーはたいしてキルをとるのには向いてないけど、敵を移動させたり妨害したりといった使い方がある。

これに比べると1のころのスペシャルはつかいみちも限定されてて、それこそキルを取るぐらいしかできないものばっかりで、ゲームプレイを単調にしていたのではないか。

その意味で、

・1のスペシャルは、「キルできたのは自分が上手かったから」
・2のスペシャルは、「キルできたのは相手が下手だったから」

というのは全く違うとおもう。キルをとれたかどうかに限定せずスペシャルが有効に使えたかどうかで考えてみると、「相手が下手だったから」なんてことはまったくなくて、状況をちゃんとみて必要な行動を理解する必要があって、1のころより2のほうがずっと、プレイヤーの習熟を必要とする。

あとチャクチ狩り、S+下位でもふつうによく見られるとおもうんだけど。ヘタな人が無敵状態になる前に落とされるやつ。むしろS+ぐらいだとそこまでヘタな人がすくないのであんま見られないかも。

これは「eSportsに寄せた調整」というべきなのか？　自分は、戦闘アクションやスペシャルで一掃する「爽快感」ではない、スプラトゥーンのもっていたゲーム性というものがあって、そちらによせてきた、ということではないかとおもう。

さっきもかいたけど、自分がよくつかうのはキルのとりやすいブキじゃなく、どっちかというと補助的な役割のほうがおおきい。そもそもそんなに上手くないのでキルはぜんぜんとれない。そういう人間からすると、キルのとりあい一辺倒なゲームよりも、いろんなタイプのブキがそれぞれに意味があって、それぞれのプレイスタイルが噛み合わないと勝ちづらい、そんなゲームのほうが優れたゲームではないか、とおもえる。それがeSports的だ、というなら反論はしないけど、であればべつに実況や大会を志向しているってことではないとおもう。

でもそうだとすると、1のほうが初心者向けでわいわいたのしめたよね、2は玄人向け、ということはあるだろうか？　自分は1をやっていたから、そこはわからない……けど、2がかならずしも玄人向けってことはないんじゃないかとおもう。それぞれのブキによるプレイスタイルの多様さ、シューター系ゲーム経験者じゃなくてもたのしめる間口のひろさ、っていう言い方もあるのではないかなあ。

ただ、このゲーム性の関係上、スプラトゥーンは複数人がきちんと協力しないと勝ちづらいつくりになっているのは確か。1ではそれでも単独で無双していれば勝てたりしたんではないかとおもうけど、2ではこれがかなり難しくなったように調整されているとおもう。新ルールのガチアサリもこの方向性で、あれマジで一人でがんばってもまったく勝てない。開始当初のC帯のつらさよ……。

その結果、ランダムなガチマッチがつらい、ボイスチャットしながらリーグマッチするほうがたのしい、という話は、わかる。自分はリーグマッチとかプライベートマッチとかあんまりしてなくて、ふつうのガチマッチもたのしいと思っている。こまかい意思疎通できないなかだからこそおもしろいってのはあるんじゃないかとおもうけど、マッチングした味方がヘタでまけたりするとつらいしな……。真剣なガチ勢はストレスをためがちかも、っていいう気はする。

なおボイスチャットなしの非常にかぎられたコミュニケーションしかないセッティングは正しかったんじゃないか。いやたぶんこれはゲーム性とはあんま関係なく、見知らぬ人とのランダムプレイにボイスチャットがあると罵詈雑言のとびかうイヤな世界になっただろうからだが。

ともあれ、スプラトゥーンは2において、キルのとりあいなシューターゲームとはまたちがった、独特の立ち位置を志向したのだとおもっている。もちろんそれがうまくいっているかどうかとか、バランス調整がうまくいっているか、というのは別な話であるけれど、でもスペシャルのこの方向性は、理不尽がどうとかいうことではなくて、そういうゲームの方向性の話ではないか（だいいち理不尽さが課題なら1確のブキとかもっと調整するはずでは）。で、自分はその方向性じたいは支持する。

まあそんなかんじです。

 

ウェブ系のストレージやクォータまわりのことをあんまり追ってなかったらけっこうかわっていたのでメモ。

そもそもは、 https://voice-memos.appspot.com/ というウェブアプリがあって録音ができるんだけど、で録音したデータはローカルに保存してるっぽいんだけど（IndexedDBを使っているっぽい）、どれぐらい長時間の音が録音できるんだろうか？ってのが気になったのだった。せいぜい数分なのか、それなりの時間でもオッケーなのか？　というのは気になるところではないか？

ストレージ容量

クォータはnavigator.storage.estimate()という関数でとれる。ふつうにpromiseをかえすので、console.logなどしてみれば、てもとの端末だと（Chrome 64, Pixelbook）、

> navigator.storage.estimate().then(({quota}) => console.log(quota / 1024 / 1024 / 1024))
Promise {<pending>}
7.009137216955423

7GBくらい。意外とある。

ただ、実際にいろいろためしてみると（Chromeの場合）どのサイトにいっても同じ容量が提示される。もちろんそんなに無制限にストレージがつかえるわけがない。基本的にはこうしたデータは一時的なストレージであって、実際につかえるストレージを使いはたしそうになると問答無用に消されていく。

このへんの挙動やクォータ設定は、もちろんブラウザごとにいろいろちがう。https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa に情報がまとめられているが、Chrome / Firefox はデバイスの残容量にもとづいてクォータを設定していて、ストレージを使いまくるとLRUでふるいデータを消していく。SafariとEdgeは消されないけどクォータはかなりすくないようにみえる。

さていきなり消されてしまうとこまるので、persistent storageとしてつかいたい、というリクエストを発行するAPIが用意されている。APIをよびだして許可されれば、つかったストレージはLRUにもとづいて消されたりせず永続化する。ただ許可といっても一般的なパーミッションAPIと（Chromeの場合は）ちがって、ユーザに許可をもとめるのではなく一定の条件で自動的に許可が降りるようになっている。詳しくは  https://developers.google.com/web/updates/2016/06/persistent-storage に記載がある。

ストレージの種類

かつていろんなストレージ系APIがあった。webSQLとか、filesystem APIとか、なんやかんや……。だいたいみんな消えた。現状、このへんはだいたい3種類に絞られてきているようだ。localStorage、CacheStorage、IndexedDBのみっつ。

localStorageとIndexedDBは前からあるけど、CacheStorage？っておもったのだが、service workersの文脈でよく登場するので誤解していたけれど、じつはふつうのブラウザ内のJSからもふつうに使える。ふつうのKVSとしても使える。IndexedDBとくらべるとだいぶ使うのがラクに思える。ただ、httpsでしかつかえないし、名前的にもフェッチ結果等のキャッシュにかぎって使ったほうがいいのだとおもう。swに保持してほしいデータをページからコントロールしたいときとかに使うべきなのだろう。

まあこのへんは直接さわるよりはなんかwrapしてくれるAPIを使うことのほうが多いんじゃないか、という気がするが。

---

そういうわけでもとの疑問に戻ると、当該ウェブアプリはストレージにIndexedDBを使っているので、Chromeとかであればわりとまともな時間でも保存できるようだ（iOS Safariだと無理かも）。ただpersistent storageは要求していないので、あんまり昔に録音したデータとかがいつのまにか消えている、てことはある。常識的な範囲内でつかえば意外とふつうにつかえそう。

1のときにも記事かきましたけど。

2における最大にして重大な変更といえば、なにをおいても

カモンがC’mon!からThis way!になった

ことでありましょう。

1のとき、日本語版における「カモン！」のメッセージは、英語版では（おそらく深い考えなしに）「C’mon!」と訳されていました。が、英語でcome on!といえば、日本語における「カモン」のように「来い」という意味もある一方で、こう、相手を煽るというか、けなすというか、そういった意味合いもありました。実際、ヘマして水に落ちるとc’mon!連打する人とかもいた。

これはよろしくないので本来の意味がより直接的につたわるよう、This way!となったわけで、まぎれがなくなりました。

それにしてもこの翻訳、「いわれてみればなるほど」だけど、おそらく非ネイティブであればなかなか見逃してもしかたないようなミスだよなあ。あらためて、ゲーム翻訳の世界における興味深い事例といえるのではないかなあとあらためて思った次第。

マニューバはdualies、シェルター類はbrella

ほかだと新武器類であるマニューバ、シェルターはどうか。マニューバは英語でmaneuverですがこれだと意味は通らないからか、dualiesという名前になっています。dualは二重という意味。他の言語でもだいたい二重とか2つといった意味の語が選ばれているようです。

シェルター系。パラシェルターはsplat brella、キャンピングシェルターはtent brella、スパイガジェットはundercover brellaというように、brellaを武器種名としてつかっています。umbrella（傘）からの語ですね。これはまあわかりやすい。というかパラシェルターのほうがよくわからないよな。

ガチアサリはClam Blitz

新ルールのガチアサリですが、英語版ではClam Blitzとなっています。Clamはアサリみたいな貝のこと。Blitzはドイツ語の「電撃戦」（blitzkrieg）から転じて急襲といった意味のある語……ただこれ、アサリの形状がどうみてもアメフトボールなので、まあアメフト用語のブリッツ（blitz）を念頭において考えられた語だろうな、とおもいます。

バッテラストリートがThe Reef

新ステージ名はバッテラだの海女だのガンガゼだのフジツボだのエンガワだのと、なかなか翻訳がむずかしそうな語がおおいですが、だいたい適当にぜんぜん違う海産物系の名前をつかってます。

が、バッテラストリートについてはもうなんか完全にあきらめたのか、The Reefとなっていました。Reefは岩礁といった名前の語です。某ウィキによると、他の言語ではスシなんとか、みたいな名前のようなので、なぜ英語だけおもいきって変えたのかは、ちょっと謎ですが。

海女美術大学はInkblot Art Academy。まあ海女は訳せないよな、訳しても意味ないし。Inkblotはインクのシミといった意味。

ただ完全にそのまんまな例もあり、たとえばManta Maria（マンタマリア号）。そのまんまでわかりやすいときはそのまんまにしてるようです。

デボン海洋博物館の裏設定？

こないだでてきたデボン海洋博物館ですが、英語版ではShellendorf Instituteとなっていました。Instituteは研究所、といったところなので博物館とはちょっとちがうけれどもそう遠からずですが、さてShellendorfとは？

とおもったら、なんとこれ、1で言及のあったブキチ（英語版Sheldon）のおじいちゃん、日本語版でいうカンブリヤ・ブキノサイの英語名がAmmoses Shellendorfなんだそうで。

するってーと、このおじいちゃんが設立した、といった裏設定があったりするのか？　とか想像するのもちょっとおもしろい。それにしてもどうして英語版にだけこんな名前を採用してるんだろ。

そんなこんなで、ローカリゼーションにしても翻訳にしても、逐語的に訳してるわけじゃないんだよなー、まあいろいろがんばってんだな、とおもうなどしました。

そういえば、Goには可変長引数でナントカオプションみたいなデータをわたす、というパターンがよくある。これってGoに特有のパターンだなとおもう。

とくに顕著な例として、たとえばgRPCがある。gRPC/Goには、たとえばDialOptionという型があって、gRPCサーバにつなぐときに、

conn, err := grpc.Dial(target, grpc.WithInsecure(), grpc.WithCompressor(grpc.NewGZIPCompressor()))

などのようにconnをカスタマイズするためにつかう。

DialOptionは型のなかみとしては関数になっていて、privateなdialOption型をうけとって何らかの処理をすることになっている。dialOptionは外からはみえないが実際にはただのstructで、いろんなオプション（たとえばSSLするかどうかとか、圧縮するかとか）をそれぞれフィールドとして持っている。個別のDialOptionはこれらのデータをセットする関数になっている。

func WithInsecure() DialOption {
  return func(o *dialOptions) {
    o.insecure = true
  }
}

といった具合。こういうデータを受け取る関数の側では、

func Dial(target string, opts ...DialOption) (ClientConn, error) {
  opt := defaultOptions()
  for _, o := range opts {
    opts(opt)
  }
  ...
}

といったふうに適用していく。

こういう “dialOptions” みたいなstructがほしいんだとすると、単純にその型をexposeしておいて、指定させておけばいいのではないか？とおもうかもしれない。つまり、

func Dial(target string, opt *DialOptions) (ClientConn, error) {
  ...
}

こんなかんじで定義しておいて、

conn, err := grpc.Dial(target, &grpc.DialOptions{})

こんなふうにつかうイメージ。

この手法と比較すると、可変長引数のオプションをつらねる方式の利点はいくつか考えられる。

• そもそもオプションをとくに指定したくない場合には何もかかなくてもよい
• デフォルト値をゼロ値と想定しなくてよい
• それなりに記述的な表現ではある

いっぽう、欠点としては、

• gRPCの例でもそうなんだけど、なんとかオプションみたいなものが多種類あるとあつかいがめんどうになりうる。おなじような意味で対応するDialOptionとServerOptionを指定したいときに関数名をかえないといけなかったりとか（がんばればできるかもしれないが、型が微妙にちがう場合などもありうるとすると限度がある）
• 可変長引数としてつかえるのは一種類のデータだけなので、何種類も使えない

でもまあおもしろいイディオムだなーとおもう。Goのシンボル可視性、可変長引数の挙動、関数型の扱い、などが絶妙にくみあわさっているようにかんじる。

それにしても、おもしろいとおもうのにGo以外でぜんぜんみたことないパターンだよな、なぜだろうか……とつらつらかんがえてみたところ、なんのことはない、ほかの言語にはふつうにデフォルト値指定できるラベル引数があるからであった。どっちかというと言語レベルでラベル引数あればよかっただけで、いまはこういうパターンでしのいでいるとみるべきだろう。ガッカリおち。