Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

「RPGの宿屋」は必要ない?

今日は、このツイートが良い疑問を投げてるなぁと思ったので、僕の考えをまとめました。

たしかに、記号化したRPGの宿屋の必要性は考える余地はあると思います。

でも価値要素は無いと言い切れるのでしょうか?僕はそう思いません。 このブログ記事では「RPGの宿屋にも意味はある」という立場のもと、なぜそう考えるかを話します (あくまでその立場として書いているということなので、争ってやるという気持ちはありません)。

僕は、 RPGの宿屋の価値要素は「分かりやすい安堵感」 だと思います。

今回の話の元のツイートは、疑問を投げかけるという意味ですごく良いと思っています。 でも、ゲームの楽しみとかワクワク感とか「ドップリ浸かる感覚」とかは、機能的に「こうだからこう」というもの以上の何かが大切なんじゃないかな?と思っています。 それは 楽しむための「嘘のリアル」をどれだけ出すか ということだと思います。 安堵感や帰ってきた感覚を演出できる「RPGの宿屋」はそのために意味がある と思っています。

今回の話では、「宿屋にこういった機能を持たしているゲームもあるので、意味がある」というような、機能よりの話はしません。

僕とゲームについて(読み飛ばし可)

(この節は僕がゲーム好きだよと主張してるだけなので、読み飛ばして良いです)

僕は生まれてからずっとゲームが大好きです。仕事ではゲームに関わったことはない、ただのゲーマーです。 今はSwitchとXBOX ONEのゲームをよくやっています。FPSからRPG、縦横シューティングからパズルまで何でもやります。 TGM(ARIKAテトリス)の基盤も持っています。

最近良かったゲームは CELESTE です。これはまじでやったほうが良いですよ。 あと、この1ヶ月くらいで買ったゲームはマリオパーティの最新作(まだプレイはできない)とか、NiER Automataとか、ドラクエ10とか、ケロブラスター(Switch版)とかですかね。

大切な無駄があるという話

さて本題です。

僕はゲームはその中に存在しているときの気持ちとか、動きの手触りがすごい大事だと思っています。 ゲームをする中で「ドップリ浸かっている感じ」や「ワクワク感」は、単純な機能とか効率とかじゃない要素から生まれると思っています。

RPGの宿屋はたしかになくても良い

先のツイートでは「RPGの宿は不要では」と疑問を投げかけています。 この疑問はすごく面白いと思うし、主張はもっともだなと思います。

意図を汲み取ると、ゲーム内の街の中でわざわざ宿屋に行く必要性はあるのか?ということで、平たい話が「ドラクエの宿屋」をイメージしているのかなと思いました。

宿に歩いて行って回復する。確かに面倒くさくもあります。 「街に入ると自動回復するのはどうか」と提案されていますが、僕が拡大解釈するなら、例えば街に入った瞬間に一瞬ブラックアウトして「休まったよ」という表現すると良いかもしれませんね。

RPGの宿屋は、気持ちとして必要

でも僕は、プレイヤーが戦いから離れて「気持ちを落ち着ける」ために、宿屋とか自宅とかが必要なんじゃないかと思います。 プレイヤーが「帰る場所」、「安心する場所」と認識しやすい場所が必要 だと思います。

もちろん「街に入ると回復案」でも、帰る場所の意図は演出できますが、より分かりやすく直感的な「帰る場所」が大切だと思います。

例えば「宿」、「家」、「ベッド」、これは論理じゃなくて感覚の話です。 感覚的に、人間は「そこに行けば休まる」と知ってるからです。

それを日常生活で知っているからこそ、ゲーム内でもそれを求めるし、あれば気持ちの安心できる場所として機能すると思います。 そして、その場所に一回帰れるからこそ「よし、また戦おう!」と強く思えるんじゃないかなと思います。 (「いや、街で自動回復でも慣れれば安心感でるんじゃね?」という意見にも同意しますし、試す価値は大いにありそうです)。

つまり 「街に入ると回復」は「無駄は少ないけど表現は弱い」 ものになると思います。 「宿屋で回復」は「無駄はあるけど表現は分かりやすい」 ものになると思います。

無駄なリアリティは無駄

「熱砂で金属の防具が熱くなることを気にするプレイヤーはいない」と元のツイートにありましたが、その通りで、当たり前だと思います。

面白くもないリアリティは要らないから です。この要素はゲーム的に全く面白くもないし、気持ち的にも面倒くさいだけなので要らないと思います。 「リアリティ」を勘違いしたゲームにありがちですが、 楽しみとか、気持ち的なプラスにならない「リアリティのある」要素は無駄でしかない と思います。

ゲームは 「楽しめる嘘」、「楽しむために出すリアリティ」というのが大切 だと思います。逆に、不要な表現は排除すべきです。 例えば TF2 というTPSは、被弾したときのダメージ判定が頭でも足でも同じです。 これは「リアリティがない」ですが、このゲームのカジュアルさや「楽しみ」のためには不要だった要素ということです。

「宿屋」や「自宅」は帰る場所として分かりやすい要素だなと僕は思います。 もちろんこれも、ゲームのコンセプトや演出したい感覚に沿えば、排除しても良い要素だと思います。

RPGの宿屋は要らない」話は、「一旦どこかに帰って落ち着きたい」という感覚をどう満たすのかという話に行き着くのかもしれません。

現状を見直すべきゲームも多分にある

ゲームによっては街の設計を見直したほうが良い場合や、宿屋とか回復のシステムそのものを見直したほうが良いものもあります。

ReCoreにおける自宅は、安堵感もさほど無いし、回復もシステム的過ぎて面白味にかけていました。 ドラクエ10 の街の設計は導線を見直したほうが良いと思いますし、どのゲームにも常に改善の余地はあります (ReCoreはゲームとしての改善点は他にも多分にありますが)。

ともかく、「RPGの宿屋」だけでなく「機能性以外の気持ち」とか「プレイヤーと暗黙的に共有できる気持ち」とかは大切だと思います。

機能以外に実は求めているもの

例えばゲーム内で「馬」に乗りたいのは、移動速度をあげるためだけじゃありません。 「馬に乗って平原を走りたい」という、プレイヤーの根源的な気持ちがあると思います。純粋な「馬に乗る」ことに対する憧れみたいなのがあると思います。

他にもゲーム内で「自宅」を買いたいと思うのも、ゲームの世界の中で、自分の安堵できる空間が欲しいという気持ちが大きいと思います。 「回復するため」や「物を置く場所のため」だけじゃない理由があるはずです。 Skyrimとかで家買ってカスタマイズするの、僕はすごい好きなんですよね。家を持っているという所有欲も満たせます。

確かにゲーム内での機能も求めてるんだけど、そこにある「気持ち的な、それ以上」を本質的には求めているんだと思います。

なので、 直感的に「疲れたからベッドで寝たい」という気持ちに答える表現は大事にしたほうが良いと思います 。 街に入って自動回復したら、どんな気持ちになるんでしょうか。僕は、ちょっと冷めると思いますし、あんまり休んだ感がせずゲームにルーチン作業を感じてしまいそうです。 ぶっちゃけドラクエの宿も、カウンターで話すだけでブラックアウトして回復するのでイマイチ だと思います。

まとめ

ゲームなんて、そもそもやってること自体が無駄です。

なので「RPGの宿屋」は、たしかに無駄な場合とか改善の余地がある場合もありますが、それ自体がもたらす「分かりやすさ」とか、「安心感」とか、「帰った感」とか、「あぁ、宿に行ったから休んだのね」っていう気持ちの共有は必要だと思います。 「戦闘で疲れたときに、気持ち的にも帰りたくなる場所」としての役割が明確になるんだと思います。

RPGの宿屋は「必要な無駄」 だと思います。 無駄だけど気持ちとして必要 な場合があるということですね。

宝探しと仏像彫刻と、ものづくり

あなたが何かを作るとき、どういうイメージでものを作っていますか?

日経なんかを読んでいるとスタートアップが買収されたとか不祥事をおこしたとか事業撤退、転換したという話を毎日読めます (僕は日経とかそういうニュースは好きで読んでいます)。

そういう話題の中にある「ソフトウェア開発」や「起業」はみんな「宝探し」をしてるんじゃないか?と思いました。 買収する人も買収される会社も、何かを作る人も売る人も、みんな宝探しをしてるように感じることがあります。 でも僕がしたいのは、仏像彫刻とか、そういう別なものなイメージだなと思った。今日はそんな話です。

(単なる気持ちになったという話なので、何の知見もありません。また、誰かや何か、何かしらの主義や思想を否定する文ではありません)

ここでいう「宝探し」とは何でしょうか。僕の単なるイメージなんですが、大きな砂山かゴミの山があって、人間がその中に飛び込んだり掘り進んだりして、お宝を物色するイメージです。 あれでもない、これでもないと手に持つものを取っ替え引っ替えしつつ、いつか巡り合う最高の価値あるものを探しているように思います。 ソフトウェア開発、投資、起業、どの文脈でも構いませんが、「宝探し」的な「ものづくり」をしている人がいるなと感じています。 ゴールドラッシュに例えられがちなのも、そういうイメージが一致しているからなんじゃないかなと思っています。

それもワクワクするし、僕も「かっこいいな」と思いますが、僕がやりたいことは実は少し違うんじゃないかな、と思ったんです。 もっと僕のしたいものづくりは、仏像彫刻とか、旋盤の切削加工のようでありたいということです。 他に近いイメージは建築とか、旋盤とか、陶芸とか、盆栽のイメージです。 このイメージは何かを漠然とした中から探し当てるのでなくて、すでにある何かから目的のものを削り出したり整えていくイメージです。 カッコつけるなら魂を込めていくと言っても良いかもしれません。 このイメージに沿って考えると、この「ものづくり」の思想は1つのものを作るのにはかなりの時間がかかるだろうと思います。 何か対外的な正解を見つけるのなくて、内側にある何かを求める作業になります。内から出る良さというか、にじみ出るすごさみたいなものを作る作業です。

宝探しと彫刻、どちらが「正しい」のかは僕は分かりません。ただ僕は彫刻のようなものづくりをしていたいです。 正直に言うと、「数週間で作ったこのサービスが何万ユーザー獲得!」みたいな話を聞くと残念な気持ちになります。 製品の良さやユーザーさんへの価値を掘り下げれてないように思えるからです(もちろん、短期間で本当に良いものを作ってる人もたくさんいます)。

もちろん早期のフィードバックを得ることは何より大事ですが、自分たちですら納得のいっていないものを多くの人に届けていいのでしょうか (知り合いとか、よほど興味のある人には良いと思います)。 とても良い才能を持ってる人が、アテンションを集めるためや、早々に売り切るために人生を無駄にしているように思えてしまいます。 本質は製品であったり、使って本当に喜んでくれる人の近くにあるんじゃないでしょうか、と僕は思っています。

スタートアップとか起業の本を読むと、「宝探し」が良いという話が多いように思えます。 ですがそうでない本もあって、例えばリーンスタートアップは僕が読んだ印象では彫刻家よりな発想に感じました。 リーンアナリティクスも、拡大の前にエンゲージメントに注力するよう説いていますし、そっちの解釈で僕は勝手に共感しています。

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

Lean Analytics ―スタートアップのためのデータ解析と活用法 (THE LEAN SERIES)

起業の科学という本もリーンスタートアップの影響を強く受けている本で、ピボットするべきかどうかの判断について書かれています。 そのなかで「やりきっていないピボット(UX改善や機能の磨き込みをやらずにピボットしてしまうこと)」は良くないと具体的に書かれています。

[asin:4822259757:detail]

この「磨き込み」という表現が好きで、この部分以外も含めて良い本だと思います。

PyQ も作りはじめて2、3年くらいになりますが、ようやっと自分的にも納得がいき始めたラインです(まだまだ納得できていません)。 PileMd も単純なノートアプリのわりに、構想から足掛け1年以上、余暇で作り続けていた記憶があります。 正直、まだ僕の作った(作っている)ものは「こいつはマジすげぇな」と僕がドップリ心酔できるレベルに至っていないと自分で思っています。 もちろんマジですげぇ製品たちですし、人に十二分に価値を届けられるものだと思っているので、公開したり、サービスとして売っています。 ただ、木橋ミュージアムマツダロードスター、スタジオピクセル洞窟物語やCELESTEみたいなものには、まだ至れていないなと自分で思っているという意味です。

いつになったら作れるのか不安にすらなります。

kkaa.co.jp

www.mazda.co.jp

store.steampowered.com

store.steampowered.com

最近行った、建築の日本展という美術展もとても良かった。そういった工芸的な芸術性や、簡素な中にある深みとこだわりを感じれて良かったです。

www.mori.art.museum

僕は自分の作りたい製品があって、Webサービスや自分のものを作り続けていますが、人によって「サービス開発」や「起業」というものに思うものは違うんだなと最近よく思います。 「Webサービス開発者どうし」、「クリエイターどうし」、仲良くやっていきましょうとも言いますが、僕は人がそれぞれ見てるものは全く違うと思います。

僕はたぶん、「スタートアップ」になりたいわけじゃないのだなと最近思います。すごく憧れますし、かっこいいとずっと思っていますが。 僕は単に、良いものづくりをして、それを使ってもらいたいだけなのかなと思います。 高専で旋盤を回していたときから、このMake組ブログを作ったときからずっと、単に自分の作りたい良いものを作って誰かの役に立てば良いなと思ってるだけなんでしょうね。

そんなことを考えていた、PyConJP明けの休暇でした。

#stapy Pythonのコア開発者のパネルディスカッションでモデレーターをしました

f:id:hirokiky:20180914210903j:plain

photos.google.com

Start Python Club主催のPython Global Meetupというイベントで登壇しました。

https://photos.google.com/share/AF1QipPtD1KElDUYuK8aRbWrmA0YgMoEUiI9xdPiZlzJg1_jEbpi8VQRuQ5r7e-W8CdxjA?key=eEJsSUVZWExaZXExY0tJN21vYXd1UTZZMWtvckpR

このイベントのメインイベントであるパネルディスカッションで、司会をしました。

このブログはその次の日に書いています。 すごく良いイベントだったので、今のホットな気持ちで思うがままに書きたいと思います。

この会のスゴい点

このPython Global Meetup、本当にすごいイベントでした。 なぜか。間違いなく、登壇者の豪華さと、その人たちがパネルディスカッションをするということですね。

MarcさんはUnicodePythonに導入した人ですし、EuroPythonSocietyというEuroPythonを運営する組織の会長をされています。

稲田さんはBDFL deglegateとしてPythonの最終決定の一部を委任されていますし、CompactOrderedDictというPython3.6からの辞書の実装を作られた方です。

あつおさんはpython.jpを立ち上げていてかつ、Unicodeに関するPEPをAcceptされている方です。

Pavlosさんは金融、銀行の分野でオペレーションを自動化する企業をMarcさんと作っている方で、エンタープライズ領域でのPythonプログラミングの長い経験がありつつ、それをビジネスに繋げている人でもあります。

この豪華な布陣ですよ。 もはや、この中の1人だけでPyConのキーノートスピーチをできるんじゃないかというレベルです。

この方たちが集まるだけでもう十分というわけですが、野心的なのがこの4人でパネルディスカッションをするという点ですね。 その話を聞いただけで面白そうなことは間違いありませんが、誰が司会(モデレーター)をやるのかは難しいと思います。

そこで白羽の矢が立ったのが僕ということですね。

チャレンジングだったこと

チャレンジングな点は3つありました。

  1. ライブのパネルディスカッションであること
  2. Pythonの超すごい人が超深い話をすること
  3. 日英混合でのパネルディスカッションであること

当日うまく回るか全く分かりませんでしたが、周りの方のサポートもいただいて楽しいパネルディスカッションになって良かったです。

事前準備としてはPythonのコア開発についてやUnicode周りのPEP、登壇いただいた稲田さん、Marcさん、あつおさんのPEPを読み込んでいました。 あと、パブロスさんの興味分野が技術を使った問題の解決やビジセスサイドにあると事前に聞き、当日はなるべく「コア開発」に限らない質問に変えていました。

日英のパネルディスカッションで同時通訳は入っていましたが、司会者としてはレシーバーの設定を切り替えながら聞くのは不可能だと判断して通訳は聞いていませんでした。 ラグもありますし、ライブのトークでは通訳者さんに技術単語の共有もできないので僕がどのみち補足する必要もありましたので。

ただ今回かなり大変な、チャレンジングな機会でしたが、僕としては大きな自信になったなと思います。 司会としても話を回せるし、英語もその場でかなり話せることが分かったので良かったです。

知れたこと、面白かったこと

  • PythonのCompact Ordered Dictの実装は、メモリー効率や実行速度を狙った結果、副次的にキーの順序が保持されるようになっている。
  • Pythonのコア開発に触れるなら、やっぱりpython-devのメーリングリストを読むところから始めると良い
    • 日本の情報には限界があるので、コアの開発は英語を読もう
  • 昨今のOSS開発はテックジャイアントが強くサポートしている。どう変わってくるか、どう思うか
    • => 今までテックジャイアントはオープンソースの恩恵を強く受けてきた
    • 例えばmacBSDベースにしているところが大きい
    • そのテック企業が大きくなってOSSをサポートしている現状は、恩返しとしてポジティブに受け取っている
  • Unicodeには目に見える1文字1文字と違うユニットに分けたような構造で内部的に階層、表現方法がある
  • MedusaというWebサーバーを書く基本になるようなライブラリー(Webサーバー?)がある
  • Pythonに貢献するというのは何もコア開発だけでない。Pythonを使ったり、知見を共有したり、PSFのメンバーに登録したり、誰かに教えてあげることも十分素晴らしい貢献
  • もし本家に貢献したいのであれば、Issueで簡単なことから手伝いができる
    • バグという報告の動作検証をする
    • 質問の適切な投稿場所を案内する
    • 足りない情報があれば質問したり、自分で調べて書き込んであげる

いや、パネルディスカッション中の参加者の方からの質問も良かったですね。すごい良い質問でした。

他に事前に調べてたこととしては、UCSやPythonの新しいUTF-8モード、Windowsでのロケールの扱いやLANG_CTYPEがCのときの扱いの変更などでした。ですが理解が深まって良かったです。 BDFL deglegateやPEPについてなど壇上で簡単に解説しましたが、伝わっていれば嬉しいです。

まとめ

とにかく、うまく話がまとまってかつ、来てくださった方にも楽しんでいただけで良かったです。 うまく伝えられていると嬉しいですが、難しいこともあったと思います。できればその分からなかった内容やスライドの内容を調べてみて、ブログなどにまとめてくれると新しいPythonへの貢献になるのではないでしょうか。

登壇者の皆さん、Python Start Clubの皆さん、この企画に誘ってくれた寺田さん、三菱UFJ信託銀行の皆さん、会場提供のFiNCの皆さん、ホンヤクの皆さんありがとうございました。 そして何より、参加いただいた皆さん、ありがとうございました。

Enjoy Python!

CodeMirrorでphrasesオプションを使ってUIを日本語化できるようになったという話

2018年8月25日にリリースされたCodeMirrorの5.40.0から、検索ダイアログなどのUIを日本語化できるようになりました。

New features

New method phrase and option phrases to make translating UI text in addons easier.

github.com

何が嬉しいのか

CodeMirrorの検索アドオンなどを使うとき、ダイアログ内の一部UIを英語から日本語に置き換えられませんでした。 例えば Search:(Use /re/ syntax for regexp search) という文言が変更できませんでした (それほど難しい文言でもないので英語のままでも良いですが、置き換えられるとUI上、言語を統一できてキレイです)。

CodeMirror: Search/Replace Demo

phrasesオプションに指定して変更できます

phrases というオプションをCodeMirrorに指定して、置き換える言葉を設定できます。 プロパティーにキーになる文言を、値に変更したい文言を指定します。

以下の例では searchアドオンのフレーズ を置き換えています。

CodeMirror(targetElement, {
  ...,
  phrases: {
    'Search:': '検索:',
    'Replace:': '置換:',
    '(Use /re/ syntax for regexp search)': '(/正規表現/ と書いて正規表現で検索できます)',
    'With:': '置換する文字:',
    'Replace?': '置換しますか?',
    'Yes': 'はい',
    'No': 'いいえ',
    'All': 'すべて',
    'Stop': 'やめる'
  }
})

そうすると、表示される文言を日本語に変更できます。

f:id:hirokiky:20180903193303p:plain

文言がユーザーのAccept-Languageによって切り替わるわけではないので「国際化」とは呼べなそうですが、僕はかなりありがたい機能だと思います。

DjangoRestFrameworkのSerializerから関数/メソッドの結果をフィールドの値として返す

DjangoRestFrameworkのSerializer(ModelSerializer)で、フィールドの値を関数/メソッドの結果で返したいことがあります。 これはバリデーションとしてSerializerを使うのでなく、モデルから辞書に値を変換したい場合の話です。

例えば、フィールドの日時が何日前かや、何かしら加工した値が欲しい場合です。 もちろんモデル自体にプロパティとして実装すれば疑問なくフィールドとして使えますが、そのSerializerでだけやりたい処理の場合はこの方法が有効です。

以下の例では Foo モデルに、 bar というフィールドでメソッドの結果を返すようにしています。 serializers.SerializerMethodField を使ってできます。この場合 bar はリードオンリーのフィールドになります。

class FooSerializer(serializers.ModelSerializer):
    bar = serializers.SerializerMethodField()

    def get_bar(self, obj):
        return obj.bar.title()

    class Meta:
        model = Foo
        fields = (
            ...
            'bar'
        )

SerializerMethodField に何も指定しないと、メソッド名は get_bar がデフォルトで指定されます。 メソッド名を特別に指定したい場合は SerializerMethodField("calc_bar") のようにします。

でもこのときにメソッド名もフィールドと同じ名前(上記では bar )にしてしまうと、フィールドが無効になってしまうので気をつけてください。 (名前が被ってしまうので、クラス内の値として後に書いたものだけが有効になってしまう)。

www.django-rest-framework.org

Ansibleでファイルの存在確認にstatを使ったら大きいファイルには動作が遅すぎたのでやったこと

Ansibleでファイルが存在しているかによって処理を分けたいことがあります。 そんなときは stat を使うとできますが、対象のファイルが数GB単位で大きいと処理が遅くなります。

下の例ではファイルが存在しないときだけ実行するタスクを書いています。

    - name: とあるファイルが存在しているかチェックする
      stat:
        path: /path/to/file
      register: the_file_stat
    - name: (ファイルが存在してないときだけやりたい処理)
      shell: ...
      when: the_file_stat.stat.exists == False

ですがこの stat は、ファイルをチェックするだけでなくてチェックサムなども計算してくれます。 かなり重いファイルの場合、この処理で時間がかかってしまいます。 ファイルの存在チェックだけで良い場合は、チェックサムは不要なので以下のようにして遅くなる原因の処理を無くせます。

    - name: とあるファイルが存在しているかチェックする
      stat:
        path: /path/to/file
        get_checksum: false
        get_md5: false
      register: the_file_stat

このIssueで自己解決してる人が居たので、参考になりました。

github.com

Ubuntu18.04でDockerのDNS解決がホストのDNSにならない問題の話

Ubuntu18.04でDocker (17) を動かすとホストのDNSの設定を使わずに 8.8.8.8 を使ってしまう問題がありました。

何が困るかというと、AWSで動かしている場合ローカルのDNSを使わずにパブリックIPを引いてしまうとSecurityGroupの許可設定が効かないことです。 例えば、コンテナー内部からデーターベースにアクセスできないなどの問題が起こります (システムの都合上ECSなど使わずにEC2にDockerを入れて自分で可動させています)。

github.com

原因としては、ホストPCで systemd-resolved を見る設定になっているのだけど、 その設定を使おうとしたDockerコンテナーが使えずに 8.8.8.8 にフォールバックしたみたいな話のようです。

systemd-resolved 伝わないようにしちゃうみたいな回避が効きますが、まぁあんまり良い気持ちではないですね。 上記のIssueコメントで紹介されています。