投稿

シンデレラのおしごと 拡張「Step by Step」妄想カード評価

J.C.クリエイツから販売されている「シンデレラのおしごと」に、待望の拡張第4弾が出ました。各アイドルの能力に関して、プレイ前の強さ評価の妄想講評を置いておきます。強さは基本的にゲーム開始時ドラフト(アグリコラのようなやり方)での想定です。

佐城雪美 評価:B 安定して点数を出してくれそうだが、本人のパラメーターが今ひとつぱっとしない。終盤に出して、確実に10点+αをもらう運用がいいところか。

結城晴 評価:B サッカーボールトークン、3つ必要というのが扱いづらい。営業での調整必須で無理にシュート決めに行くと逆に点数下がりがちになりそう。ただし体力8があるので、比較的最低限の活躍はできるはず。このゲームは歌か体力があればとりあえず出番はある。

宮本フレデリカ 評価:Z Cuの宇宙の法則が乱れるシリーズ。強い弱いではなく宇宙。宇宙だからという理由でピックしそう。なぜか宇宙の法則が乱れる能力の持ち主はCuに多い、ゲームデザイナーの土井ヴぃさんの中でCuアイドルはどういう認識なんだろうか。評価Zにしてるけど、見たらピックして損はしないという意味で実質S評価。

池袋晶葉 評価:修正前SSS (予想される)修正後 S CivBGの修正前ギリシャ。カードテキストを読むと特レで3トークン、レッスンで2トークン自分に乗せることが出来てしまう。卯月やしぶりんの完全上位互換。なのでレッスンカウンターは自分には乗らない前提だとして、それでもめちゃくちゃ強い。レッスンカウンターが湧く能力は危険。

白菊ほたる 評価:B 3人目か4人目にスカウトする枠。8Rスカウトでも雑に10点産むのでえらい。ドラフトで3巡目くらいで残っていたらピックして多分困らない。

佐藤心 評価:A レッスンカウンターの悪用ができるアイドルのプールは結構あるので、とりあえずピックで出番は割とありそう。

村上巴 評価:C 特にドラフトでは営業が取られないラウンドはほぼ存在しないと思われるので、実質歌唱7のバニラみたいなもの。普通のワカプレに比べてスタプレを取るアクションが戦略上極めて重要なので、もうちょっと強化されてもいい気がする。

浜口あやめ 評価:S ライブで確定12点、レッスンカウンター1個が3VPになる。ただつよ。CivBGのアラブ。

日記

興味深い間違いをしているツイートがあったので備忘的に。
え、霞ヶ関官僚の人たちって本当に「競争に晒されて」「勝ち抜いて」「生き残ってきた」と思ってるの?そりゃー日本の行政が歪むわけだ。霞ヶ関官僚なんて「有名大学の有力学部を卒業して」「皆で一切の回り道なく出世して」みたいな絵に描いたようなエリート集団で護送船団方式の極致みたいなものでは — TJO (@TJO_datasci) July 27, 2019 霞ヶ関の住人が「競争に晒されて」「勝ち抜いて」「生き残ってきた」こと自体は真で、このツイート者の認識は明確に間違っている。彼らは同期入省同士で出世競争を行っている。もちろん世間、ここではツイート者が思っているように、「皆で一切の回り道なく出世して」と勘違いされる要素はある。彼らは、特に若手のうちは表向きは出世の速度に差がつかず、同期入省は同じように出世してはいく。ではどこで差がつくかというと、40以降になると「肩たたき」が始まる。出世をしない官僚は存在しないのだ - なぜなら彼らは官僚でなくなるのだから。出世の階段を1つ登るたびに同期が1人2人と減っていき、定年時の「アガりポジション」にいる時には同期は自分一人になっている。これが競争的でないというなら、何をやったら勝ち抜いた人となるのだろうか。少なくともGoogleのエンジニアはそうではない。
霞ヶ関官僚に「本当に競争に勝ち抜くこと」の意義を知らしめるために、ジャック・ウェルチ・ルールを霞ヶ関に導入したら良いのでは。業績査定の下位5-10%を自動的にクビにして、その分を新規採用で補充するという人事戦略。霞ヶ関にも緊張感が生まれて良さそう — TJO (@TJO_datasci) July 27, 2019
業績の低い下位何%の社員を切り捨てる戦略、結局短期的な業績はランダム性に左右されすぎるためにたまたま運が悪かった有能人材まで解雇してしまうことになるというのが実践した企業の結論ではなかったかな。https://t.co/P3pH2nHJEE — Ryou Ezoe(江添 亮) (@EzoeRyou) July 27, 2019 そして霞ヶ関官僚のクビをかけた出世競争は、かのウェルチ・ルールそのものと言える。それがどういう結果を産むかは、IT業界の人なら知っている人も多く江添氏のような認識になるだ…

百合紅の競り周期表による分類

スパ帝国刊「ルールデザインノート」は、「競りの元素周期表」という章でゲームにおける競りメカニクスの分類をしています。分類方法は
支払うリソースが「お金」 vs 「機会」「イングランド式 」vs 「オランダ式」競り対象が「物品」 vs 「手続き」競りへの参加が「直列」 vs 「並列」競り対象が「単体」vs 「組み合わせ」競りの価格が「公開」 vs 「封印(秘密)」 の5つの二項対立の組み合わせで、全ての組み合わせ 2^6 = 64 通りに対してそれぞれ0~63の「元素番号」を振るというもの。元素番号については機械的に割り振っているだけなので、本稿では以下省略。
例えば「ハゲタカのえじき」は「お金」「イングランド」「物品」「直列」「単体」「封印」という特性を持つ、という風に著書中では分類されています。
#ここまでの説明で「なるほど分かった!」となる人は少ないと思うので、気になる方は「ルールデザインノート」の購入をおすすめします。現在日本語で読める中では最高レベルのゲームデザイン本の一冊です。

以上が前置き。百合紅も競りのメカニクスを内蔵しているので、上記の分類で周期表上の位置を考察できるというのがこの記事の主題です。百合紅の特性は、
支払うリソースは「お金」数量化可能な支援点で、推しの組を落札しに行くゲームと捉えることができます。一番高く支援点をつけたプレイヤーが落札をするので「イングランド式」競りの対象は「手続き」コントロール点は女の子を操作する権利。支援点もモノとしてプレイヤーの所持品になるわけではありません7C2もしくは9C2通りの組が同時に競り対象になるん「並列」支援点とコントロール点が必ずセットになるので「組み合わせ」支援点は言うまでもなく秘密なので「封印」 で、他にはあまりない組み合わせになっているようです。「ルールデザインノート」からこのタイプ(元素番号15番)の解説部分の引用すると、
14番:アクションの組み合わせが複数並びそれぞれに対して値を付ける。この時点で相当ややこしい。
15番:14番を封印入札で行う。誰が遊べるんだこんなもん。
という感じです。誰が遊べるんだこんなもんとか言われていますが、現実に存在しますし割と広い層に遊んでいただけるゲームになっていると思います。
参考までに、百合紅がメカニクスに関して元ネタにした「クレムリン」も同様の分析をしてみる…

ホスト名にア○カツ!の登場人物の名前をつける生活

私のPCはホスト名をアイ○ツ!シリーズのキャラクター名から取る運用にしている。
Windows → あかりジェネレーションLinux → いちごジェネレーション その結果、現状の構成が ichigo - Archデスクトップ。開発とか一番使われてる稼ぎ頭akari - Windowsデスクトップran - Archサーバ。一番高性能。今仕事がなくて電力の無駄飯ぐらいしてるaoi/sumire - それぞれFedoraとWindows Thinkpad X1 Carbonでデュアルブート なので、「バリキャリのいちごがニートの蘭を養ってる。あおいとスミレは同棲してる」のようなストーリーが自然に発生したりしている。これはおいしい

Radeon RX470 Miningチャレンジ失敗の話

イメージ
暗号通貨ブームで売り出され、値崩れとともに格安で放出されたRX470 Mining版が調達できたので、これ機械学習に使えるのでは!?という目論見で自宅サーバをセットアップまでしました。

これがどういうシロモノかというと「出力系統が一切ついていないRadeon」です。HDMIやDisplayPortのようなシャレたものはもちろん、DVIなども一切ありません。Radeonなのにゲーム用途を一切想定していない、マイニングのためだけに生まれた時代の徒花がグラフィックカードの形をとって生まれた子。

キワモノ製品だけど、OpenCLが動くんならちょっと頑張れば機械学習にも使えるやろ、という見込みでArch機に挿してちゃんと認識もされました。CUDAに比べるとOpenCLでの機械学習は面倒事が多そうですが、安さとOpenCLを応援する気持ちでそこは織り込んで乗り越えるつもりでした。

が!騒音がすごい。あまりにすごい。

自宅では既にGeForce RTX1070搭載のマシンで機械学習を回していました。静音性の高いケースに入れていることもあり、フルロードでも「あー耳をすませば全力で回転してるんだな」という程度でした。冷蔵庫やエアコンの方がよほど音がするので、気にすることはなかった。それがこのマイニングGPUだと、音の絶対量も大きいし変な共鳴もして頭が痛くなってくる。

冷静に考えるとこの手の製品はデータセンターやサーバルームで回すことが想定されるわけで、冷却できればファンの静音性なんて気にする理由は一切ないわけですよね。出力系統がなくてお安いのは合理的じゃん!と思ったら、静音性もカットされる合理性のせいでご家庭で使えるものではなかった、というオチがつきました。

マキネーション図とボードゲームの経済エンジンのデザイン

ゲームデザイン用ツールにMachinationsというものがある。マキネーション図(machination diagram)を作成して、それに沿ったシミュレーションまで出来るツール。
https://machinations.io/

以前に発売されたゲームメカニクス本で使われていて、当時それなりに話題になった本だったのでMachinationsを触ったこともある。ある程度触った感想としては「やりたいことは分かる」「でもMachinationsでシミュレーションに値するものを組むのは大変、シミュレーションレベルの詳細度でやるなら普通にプログラミングする」だった。

ところで私は最近になって、経済エンジンを組み入れたボードゲームデザインをしている。”経済エンジン”という単語はスパ帝の造語だったと思うが、要するに拡大再生産がある時に色々増えていくリソースがあったりするアレのこと。

スパ帝が以前ゲームデザイン本の中で、経済エンジンには多脚構造が必要という話をしていた。その本の主張の内容は妥当だけど、いかんせん全てが散文で書かれているので現実のゲームデザインで実践するには微妙にハードルが高かった。頭の中で経済エンジンの各要素を動かして多脚にするのはワーキングメモリも圧迫がキツく、彼のように地頭に恵まれない人には実行に難がある。ゲームデザイン理論自体は正しいだけに、これは困った。

ということで、ゲームメカニクスレベルの内容を紙とペンでグラフ(折れ線グラフ等のグラフではなく、ノードとエッジ・点と 線で関係を表す方のグラフ)に書き出して、冗長な部分やゲームが単線になっていないかチェックすることにした。この形式にしておけば、グラフの簡約が自動化できる可能性もあるし、最高効率で回す最適解も理屈の上では計算できるかもしれない(これは最長路問題になりがちで、NP困難なわけだけど…)

ここまでやってみて気づいたこと:マキネーション図じゃねーかこれ!

最初に書いたように、Machinationsはシミュレータとして使うにはちょっと厳しいツール。でもマキネーション図は書いてみると、ゲームメカニクスの見通しが良くなるし根本的にアホな設計をする可能性は減らせそう。ということで、マキネーション図は理論的分析には今後は活用して行こうと思います。

HyTouch - Pythonのローカルパッケージインストーラー作った

Pythonでもpackage.jsonがあってnpm iしたらローカルインストールしてくれる感じのものが欲しかった。これまで機械学習用の環境構築はDockerに閉じ込めていたのだけれど、必要なパッケージを追加して行った結果いい感じに熟成してしまったDockerfileを見てDockerfile以外の解決法が欲しくなった。

作ったもの HyTouch https://pypi.org/project/hytouch/
基本的な使い方などはGitHubで https://github.com/tackman/HyTouch

pip install hytouch でインストールできると思います。

概要 Python上で実行されるLisp方言、Hyを利用したPythonローカルパッケージインストーラ&タスクランナー。プロジェクトディレクトリにpackage.hyファイルを置いて

hytouch install

とすると、プロジェクトディレクトリ内の.hytouchにインストールしてくれる。

hytouch run task-name

でいろいろ実行可能。

検証環境 Arch Linux/ Python 3.7

Pythonバージョンに関しては3.7でハードコードしているので、これ以外では確定で動かないと思います。OSに関してはUNIX-likeなCLI上では多分動くはず。生のWindodwsは知らない子なので、WSL使ってください。
virtualenvについて Pythonで環境保持といえばvirtualenvが一番メジャーだけれど、毎回activateコマンド打つのはダルいしプロジェクト単位での依存性がプロジェクト内で閉じてくれない感じがしてイヤだった。あと手なりでやると環境構築がコード化されない(package.json相当の標準的なものがない)のがつらい。

オチ これでPythonの依存性管理もできるじゃん!わたし天才!と思ったけれど、ディープの環境構築で2番目に闇なCUDA導入まわりが全く解決しないことにHyTouchを作ってから気づいた(1番目はGPUのドライバ)。そもそもnvidia-docker利用をしている理由の95%くらいがCUDAまわりの環境汚染が嫌だったからなので、ここがなんともならない以上Dockerから離れられる理由がなかったのです。