アトーの日記

スマブラ DX プレイヤーのアトーが日記を書きます。

cpu-level-11 を動かしてみた

cpu-level-11 -- それは、新時代のハッカブル CPU

Kounotori さんのツイート見て知った。

スマブラ DX でキャラクターの入力をプログラミングできるらしい。

基本のアーキテクチャは dolphin でスマブラ DX を動かす & cpu-level-11 のバイナリを実行 -> dolphin 内のメモリを監視、ソケット通信で cpu-level-11 が読む -> ユーザープログラムがコントローラー入力を名前付きパイプで送信 -> キャラが動く! というものみたい。

凄くね???

メモリ監視でほぼすべてのゲーム内状態が取れて、コントローラー入力によって人間できる入力は全て入力できる……夢が広がるな! ソース見たところ、メモリ監視もコントローラー入力も十分に抽象化されてて使いやすそう。これは流行る。

というわけで起動してみた。

若いプロジェクトがすんなり動くわけもないだろ

REAME に Ubuntu で動かしてね、とあったので、VirtualBox仮想マシン作成。普通に Ubuntu をイントール。 いつもどおり。

次にこれまた README に dolphin の master ブランチビルドしろよ、とあったので、dolphin のソースコードをダウンロード。 dolphin のソースコードが重く、git clone が完了しなかったのでシャローコピー。git clone --depth=0 ... master ブランチをビルドしたいだけだからこれでよい。

次に dolphin のビルド。dolphin のドキュメントを見たら CMake であとは勝手にどうぞ、って感じだったので CMake 実行。 依存パッケージが足りない、と何度も言われるので、その度にネットで調べて apt-get install をする。 面倒だったし、本当に正しいかわからないけど、とりあえず apt-get だけで解決したからいいや。 OpenGL やその他諸々が足りないと言われます。

CMake 完了したら make。待つだけ。。。 そして sudo make installしたら完了! dolphin が起動できるようになりました。

dolphin の起動は ubuntu のアプリランチャーから起動すると実行ユーザーが違うのか、/usr/local/shared/.dolphin-emu/ 以下に設定ファイルが作られて困るので、 コマンドラインから起動するべし。/usr/local/bin/dolphin-emu にインストールされてるからパス通ってる。

DX の ROM をホストマシンから持ってきて、無事起動を確認。

cpu-level-11 の README に従って、~/.dolphin-emu/MemoryWatcher/ に Location.txt をコピー、~/.dolphin-emu/Pipes/ に cpu-level-11 という名前付きパイプを作成。 MemoryWatcher と Pipes というディレクトリはないのでちゃんと mkdir してあげる。

あ、cpu-level-11 のバイナリ自体も作成する必要があるので、make する必要あり。特に README には書いてないけど、ここらへんはお約束。

README に従って DX を起動、./cpu を実行、マルスを選ぶんだけど……特に反応無し。ここからが結構詰まった。。。

(この記事は動かせた後から書いているため、時系列がバラバラですが、ここで詰まってからソースコードを読み始め、大体のアーキテクチャを把握)

どこにも書いてなかったんだけど、dolphin の設定で、コントローラーの入力ソースに作成した名前付きパイプの Pipes/cpu-level-11 を指定する必要がある。 +各ボタンの対応の設定も必要。えー知らねー

設定が終わって、再度起動し直すと、キャラ選択画面に入ったら 2P が勝手にカーソルを動かしてフォックスを選択。なかなか見れない光景。 対戦が始まったらダブラ撃ちまくるフォックス。 そして転がりには見てから余裕の上スマ。Level 11 だ……。

これで DX がプログラミングできるようになりました。これ未来には本当にプレイできる環境で俺の考えた最強の CPU を実装できるのかもしれないね。

大会形式のリストアップ

前回、大会形式を調べると書いたが、Wikipedia で事足りるかもしれない。 トーナメント方式 -- Wikipedia を噛み砕いた形で書く。

トーナメントの種類の一覧

グループトーナメント

Wikipediaではどうも定義がはっきりしないので、英Wikipediaを参照した。

全プレイヤーが固定数の競技を行う形式のトーナメントのことを指す。行った競技で得たポイント(合計勝利数や平均勝ち点など)に基づき、順位を決定する。

勝ち残りに比べ、試合数が多くなりがちだが、その分多くのプレイヤーと直接の競技結果による比較を持つので、より平等な方式と言える。

総当り(リーグ)もグループトーナメントの一種だが、総当り(リーグ)以外にもいくつかのグループトーナメントが存在する。

総当り(リーグ)

グループトーナメントの一種。 各プレイヤーは全てのプレイヤーと一回以上競技を行う。

シングルラウンドロビン

f:id:atossbm:20150314224048p:plain

総当り(リーグ)の一種。各プレイヤーは全てのプレイヤーと一回だけ競技を行う。

いわゆる"リーグ戦"と聞いて想像するのがこれ。

ダブルラウンドロビン

単に、シングルラウンドロビンを二回やるというだけの方式。

なぜわざわざ分類したかというと、ホームアンドアウェーの説明のため。 サッカーなどの開催地が試合結果に強く影響する競技では、公平のため、各プレイヤーのホーム(自国や自地域)と相手プレイヤーのホーム(=アウェー)で競技を行う、すなわちダブルラウンドロビンを行う。これをホームアンドアウェー方式と呼ぶ。

スイス式(スイスドロー

f:id:atossbm:20150314224137p:plain

グループトーナメントの一種。 全プレイヤーが一斉に競技を行い、足並みをそろえ、その結果に基づき、一斉に次の相手プレイヤーを決定する方式。これまでの勝ち数に基づいた対戦相手の決定を行うので、対戦相手との実力差がつきにくい形式となる。

スイス式の例としては、一回戦はランダムに行い、二回戦は1勝0敗プレイヤーと0勝1敗プレイヤーにグループを分けランダム、三回戦は2勝0敗、1勝1敗、0勝2敗プレイヤーでグループ分けランダム、と繰り返す。

競技の時間のばらつきが余り無い場合や、一斉に行える競技の数に制限がない場合に有利か。 全プレイヤーのランキングを非常に効率よく作成できる形式だと思われる。 進行するに従い、平行して行える競技数が減る勝ち抜き方式の裏で、低順位プレイヤーの順序付けを行っている方式と考えるとわかりやすい。 各プレイヤーは勝ち負けに関わらず一定の競技数を行えるが、次の対戦相手が不明で、毎回決定する手間があるため、進行のコストが大きい。

勝ち抜き(ノックアウト)トーナメント

競技を行い、結果に基づき次に進出できるプレイヤーを決定する方式。進出できるプレイヤー以外はその時点で脱落となる。(Wikipedia では1対1の戦いによると定義しているが、そのすぐ後の文章で一度の予選に複数人が参加し上位が上のステージに進出する形式もこれに類する。と書いており、矛盾しているが大丈夫か?)

シングルイリミネーション

f:id:atossbm:20150314224238j:plain

勝ち抜き方式の一種。 競技結果、上位(固定数)に入れなかったプレイヤーは即時脱落する方式。

日本で一般にトーナメントと言うとこの方式のこと。

名前の通り、即死方式。 運要素が強い競技だったり、優勝候補が初戦で当たったりなど、あまり公平でないという欠点があるが、単純でわかりやすい方式である。

ダブルイリミネーション

f:id:atossbm:20150314224309p:plain

勝ち抜き方式の一種。 シングルイリミネーションにおける脱落が一度目は許され、二度目で初めて脱落となる形式。すなわち、全てのプレイヤーは勝者側サイドからスタートし、一度上位(固定数)に入れなかったプレイヤーは敗者側サイドに進出する。敗者側サイドから勝者側サイドに戻ることはなく、敗者側サイドで再び上位に入れなかった場合、脱落となる。

単にシングルイリミネーションの試合数を倍にすることでランダム性を減らす調整である。調整の一つとしてトリプルイリミネーションがあってもおかしくはない。 この方式を表す敗者復活戦の言葉の響きとわかりやすさが素晴らしい。

パラマス(ステップラダー)

f:id:atossbm:20150314224408p:plain

勝ち抜き方式の一種。 全てのプレイヤーが予め順序付けされている場合に用いる。順序付けの下位から固定数のプレイヤーが競技を行い、脱落する。脱落していないプレイヤーのうち、再び下位から競技を行うことを繰り返す。

これは非常に偏った形式であり、パラマス開始時の順序付けで1位のプレイヤーは一度競技で勝ち残れば優勝する一方、最下位のプレイヤーは他の全てのプレイヤーに勝たなければ優勝とならない。

ポーカートーナメント

全プレイヤーがポイントを持ってスタートし、プレイヤーが競技を通じてポイントを奪い合う方式。 ポイントを全損したプレイヤーは脱落する。外部からのポイントの追加や損失が無ければ、脱落したプレイヤーのポイントは残っているプレイヤーに分配されていることとなる。

最後に

出来る限り(ただの Wikipedia のコピーだがな!!!)、リストアップしました。 他にもこんな大会形式あったよ、みたいなの教えてもらえたら嬉しいです。追加します。


以上です。

大会を記述するフォーマット

トーナメントを抽象化して、様々な形式のトーナメントを記述できるフォーマットを作りたい。

動機

f:id:atossbm:20150313205028p:plain 大会は競技において重要な要素である。
競技というのは現実の複雑な様々な要素を、プレイヤーの優劣という単純な比較に落としこむ。 その比較を競技の直接的な参加者の範囲から広げようと思うのは至ってシンプルな希望だ。 直接的に競技に参加出来る人数、例えば将棋なら 2 人、の範囲を広げ、もっと多くのプレイヤーで優劣を付けるために、大会という仕組みを利用する。競技という少人数用のルールを拡張し、大人数でも優劣を付けるためのルール、それが大会となる。

f:id:atossbm:20150313205054p:plain 大会のルール、形式は多種多様である。
大会は競技のルールとは独立して決められる(競技はプレイヤーの優劣の比較という抽象化)ので、プレイヤーにとって競技そのもののルールさえ同じであれば大会のルールの変更を受け入れることは比較的容易だ。また、競技そのもののルールは直接的に競技に参加したプレイヤーの優劣を決定するが、それは抽象化であり比較にすぎないので、参加したプレイヤーの優劣を越えて与える情報はほぼ無い。 そのため、競技のルールを越えた大人数において、優劣の付け方をより正しく思えるように多くの工夫が試みられた。 同時に、大会の時間的なり金銭的なりなどのコストも制約となり、大会のルールに反映しなければならない。

大会のコストは出来る限り、抑えたい。
前述のとおり、大会のコストに制約があるなら、コストを抑えるほど、より正しく思えるようなルールの決定をできるかもしれないからだ。 大会の運営者にとっては言わずもがな、競技プレイヤーにとっても、競技の外という煩わしい物事はできるだけ少なくしたいだろう。

f:id:atossbm:20150313205105p:plain 大会にコストの削減はルール、形式の工夫だけでなく、自動化によっても行える。
大人数の参加を想定している以上、その仕組みはシンプルなものになりやすい。また、ルールという論理的に成り立っている枠組みが存在するならそれは自動化の得意分野だ。 実際、多くの大会で自動化が取り入れられてきたし、ネット将棋などのランキングは大会の一種とみなせる。 (僕の周りの話では MasterHand がトーナメント進行に Tio を取り入れて上手くやっていた)

大会の形式、ルールが多種多様である一方、自動化は単純な形式、ルールにしか対応していないものがほとんどだ。
自動化できるツールを幾つか探したが、多種多様なものに対応できる仕組みは見つからなかった。

f:id:atossbm:20150313205118p:plain そこで大会の形式、ルールを上手く抽象化し、様々な大会を記述できるフォーマットを作りたい。
それは競技そのもののルールとは独立しているので、どんな競技にでも使えるだろう。 それが必要なだけの情報を持つなら、自動化できる。

大会形式

おおまかに分けてリーグ方式とトーナメント方式の二つがあると思っているが、その中でも色々な方法があるようだ。 もっとしっかり調べて別記事でまとめる。

トーナメント

トーナメントを表現できる JSON スキーマを試作した。
トーナメントは木構造であるため、アルゴリズムで扱うのが容易だ。応用が期待できる。 進行待ち(競技に参加するプレイヤーは決定しているが、結果が未決定)のリストを吐く関数も簡単に作れた。

今後

リーグ方式も含めた形式も記述できるように慣ればフォーマットとして十分だ。 大会形式をできるだけ多く集め、抽象化してフォーマットを作りたい。 フォーマットができれば、その有用性を訴えるために応用例を少し作って終わろうと思う。


以上です。

煽りガチ勢

昨日、スマブラfor3DS のガチ部屋で当たった煽りガチ勢が忘れられないので書く。

  • プレイヤー名: ここでは伏せるが下品の代名詞と言えるある漫画のキャラ
  • Mii の見た目: そのキャラにそっくり。クオリティ高し。
  • 使用キャラ: ワリオ

(ちなみにこちらの使用キャラはクッパ

基本的な立ち回りはワリオバイク。バイクを崖から落とすこともなく、終点化ステージの端から端へとブーンブーンと走り回ってた。そして隙あらば減速してからの騎乗アピール。ジャンプ読みにはウィリーしてたのでそこそこ面倒。

バイクに乗れなかった時は横スマと噛みつきの二択。噛みつきに関してはヒット後にしっかりとアピールを入れてコンボ火力を取っていく貪欲さ。噛みつきって持続技なんですね。珍しい。

相手バースト後に「アピールしたらアピール合戦になって無敵やり過ごせないかなー」とアピールぶっぱしたら冷静に処理されて真顔になった。

ずっとおならは使われなかった。常に臭そう。

ワリオバイク、いまいち対処がわからん。


以上です。

スマブラポータルの仕組み

完全に技術的な話です。スマブラポータルをどのように動かしているか。

以前にも書いたとおり、名前解決(ssbp.info という URL の登録)にはバリュードメインを、サーバーには Heroku を利用しています。 バリュードメインでは .info の契約の 940 円/年 で、今のところスマブラポータルにかかっている唯一の料金です。 Heroku は Web サーバー、プラグイン含めて全て無料プランで動かしています。 サービスは Node.js の Sails.js を使って作成しました。

Heroku

Heroku は PaaS と呼ばれる、ソースコード実行環境、サーバー、運用環境などを全てまるっと提供するサービスです。 このおかげで僕はソースコードを書いて、git pushするだけでスマブラポータルを公開出来ました。 Heroku はフリーミアムで経営してるので、貧弱なスペックで良いなら無料で利用できます。貧弱なスペックと言いましたが、もしもっと高スペックにしたくなったらいつでも Web サイトにアクセスしてポチッとするだけで性能アップできます。その分、お金取られますが。 サーバーも課金する時代なんですね。自宅サーバーでは得られない気軽さです。

Heroku のびっくりしたところが、サーバーが一日一回再起動するという仕様です。 もしサーバーにアップロードフォルダを作っても一日経っちゃうと消えます。メモリ内のデータもリセットされます。 じゃあユーザーデータとかどうすんの?となりますが、ちゃんとデータベースプラグインが用意されているので、それを使います。 Heroku を使っている = データベースが分離されている となるわけですね、おもしろーい。

データベースには MongoDB を使っていて、MongoLab の無料プランを使っています。 無料プランは 500 MB まで。ここも課金の仕組み。ビバ課金。 バックアップは手動でやってます。自動化したいけど使えるサーバーがない。

メールは SendGrid それだけ。

Pingdom

サービスを運用するにあたり気をつけたいのは不測の事態によるサービスの停止です。 Heroku 側でサーバーが落ちるということはほぼないでしょうが、僕のプログラミングのバグによって落ちる、アクセスが集中して応答が遅すぎて切れる、ということは十分ありえます。なので少しだけ対策をしています。

Pingdom というサービスを使って、外側から定期的にスマブラポータルにアクセスしてもらっています。 もし Pingdom がスマブラポータルにアクセスできなくなると、僕の携帯にメールが送られてきます。 死活監視というらしいんですが、要は「サーバーが死んだ!」「ピコン!」

新着一覧の仕組み

スマブラポータルのメイン機能の新着一覧はどういう仕組みか。 ユーザーがトップページにアクセスすると(JavaScript が非同期でスマブラポータルの API を叩いて)新着一覧を表示するように要求します。 この要求が発生するとスマブラポータルのサーバーが各種サービス(はてなブログや Zusaar, Twitch など)のフィード or API にアクセスします。 そして返ってきた値を処理してブラウザに返します。

結局のところ各種サービス元へアクセスするので、あまり頻繁にアクセスするとサービス元へ迷惑がかかります。 また、ブラウザ→スマブラポータル→外部の各種サービス→スマブラポータル→ブラウザ という流れなので結構遅い処理です。 その二つを改善するためにスマブラポータル側でキャッシュしています。日記だと 1 時間キャッシュします。 初回アクセスだけ妙に重い場合があるのはそのためです。また、日記の投稿などがすぐに反映されないのもそのせいです(これをスマブラポータルでユーザーに説明する必要あるか?どうやって?は悩ましい)。 定期的にアクセスして常にキャッシュを作ることも考えたんですが、あんまり外部サービスへのアクセス増やしたくないなぁと思ったのでこうなりました。


以上です。

スマブラDXイベントカレンダー終了

半年ほど続けてきたスマブラDXイベントカレンダーの更新を停止しました。

スマブラDXイベントカレンダーとは

大会やオフ会などのスマブラDXに関するイベントを Google カレンダーにまとめてました(僕の目に入ったイベント全て)。 公開する設定なので誰からでも見られて、Google カレンダーということで連携もしやすいものでした。実際スマブラDX 対戦攻略指南に載せてもらったり、他のオフ募集カレンダーに入れてもらったり、後僕のスケジュール管理のカレンダーにも組み込んでました。

こんな感じ。

載ってる情報は次の通り。

  • タイトル(大会は正式名称、オフ会は"〇〇宅オフ")
  • 日時
  • 場所(都道府県と市 or 区まで)
  • 参照元 URL

作った動機とポリシー

元々は僕が「スマコムが終わってからどこでオフ募集をしてるかわからない」と思い始めたのがきっかけで、そこ見ればオフ募集の一覧がわかるものが欲しくなりました。 そこから色々考えたんですが(カット)、新規参入するかもしれない人にスマブラDXオフはまだまだ活発ということをアピールしたいので頻繁にオフが開かれていることが一目でわかるカレンダーになりました。

作成する際、最初にいくつかポリシーを作ってました。

一つ、全て自分一人でやる

カレンダーの結論になる前、自力でサービスを作ることも選択肢としてありました。 それを選ばなかった理由に、どれだけ素晴らしいサービスを作ろうともオフ募集ごときでユーザーは慣れない方法をとることはないだろうという予想がありました。例えば新しくグレートなサービスを作ったとして、最初使ってても徐々に面倒になってきて Twitter とかで「今日の夜オフやるけど〜」ってなるんじゃないでしょうか? たとえ Twitter のメンションやハッシュタグ程度でも流行らないと思ってました。

(ちなみにこの予想、後に見事に打ち砕かれました。詳しくは Twitter#スマブラDX_オフ会というハッシュタグを!)

なので募集する人には全く影響ない方法で情報を集める必要がありました。ハッシュタグすら NG と思ってました。そういう付加情報を付ける風潮(≒面倒くさいことをやらされる圧力)が最悪、募集をオープンにしないことに繋がる恐れがあったからです。

そしてこの恐れ自体がかなり臆病なものであり他の人に理解されづらいため、一人でやるポリシーとなったわけです。(協力者が協力者を募れば恐れていた圧力と同じ)

ああ、オフ募集の労力を厭わない人はスマブラポータル + Zusaarで募集を作成した後、Twitter とかでアピールしてくれると嬉しいな!

一つ、終了は必ず宣言する

終了(更新停止)は最も決意を強くしたポリシーです。もし事情に詳しくない人が更新されなくなったカレンダーを見たら「最近はもうやってないんだな」と思うかもしれません。なので始めるからには面倒くさくなってやめようと思ったら、絶対にちゃんと宣言しよう!と思ってました。

そしてここ一ヶ月忘れて放置してました。最も強い決意(笑)

一つ、載せてもいいかは許可を取る

SNS は身内感強いですからね……。そこ拾われて勝手に宣伝されるのを嫌う人もいます。 まあネットの誰からもアクセスできる状態で投稿した時点で文句言う権利ないというのが僕の考え方ですが、ネット社会が大きくなってそうも言いづらくなりました。

許可取るというのが表の理由で、裏半分はカレンダーの宣伝目的でした。

ちなみに十人程度に聞いて全員快く許可していただいたので、大丈夫だろうということで途中からはやめました。

続けた感想

このカレンダーは僕の中で始めからアイデアのお試し、という面が強いものでした。 というのも自慢することではないが、継続は苦手なり。人間が手動で更新し続けるサービスは基本的に信用してないので。 そういう感覚で半年更新した感想。

活発に見える

上の画像見てもらえればわかりますが、やはりというか見た目の面で強い! パッと見で頻繁にオフやってるんだなー、という印象を与えられると思います。

ただ地理的に行ける場所、という意味合いでは詐欺ってるので本当にグレートなサービスにするなら地図上に表示するとかして地理の側面も固めたいかなーと。(やりませんよ)

それほど面倒ではない

最初は手動更新に眉をひそめてましたが、やってみると意外と楽でした。 オフでも多くて週に 5, 6 個で、更新するのは 10 分もかからない。10 min/week なら余裕でした。

というよりも「僕が知らないオフはどうでもいいや」という適当さが良かった気がします。

思ったよりオフ多い

僕が知らなかっただけ

#スマブラDX_オフ会に喰われた

やめる理由

ここ一ヶ月忘れたのがきっかけで、自分のアイデアを十分に試せて満足したのがやめる理由となります。 繰り返しになりますが、負担面はそれほどではなく意義もそれなりに感じてました。ただ、アイデアの鮮度が(自分で存在を忘れる程度に)落ち、更新忘れちゃうぐらいなら停止しなければと思ったので。

(最後に小さく書いときます。誰かやってみませんか?)


以上です。

艦これサーフィン TL の経緯

待望の艦これアニメの PV が発表されました!

これが……

こうなって

こう。

Twitter 民は祭りに盛り上がり、そして飽きた。


(あまりもシュールだったので。勢いで書いたはいいけど後で後悔しそう)