Celeste の RTA 練習をサポートするシステムを作りました

最近 Celeste の RTA(Speedrun) の練習をしています。

Celeste は練習や知識が活きやすいゲームで楽しいのですが、ある程度行くとどうしてもタイムを縮めるための壁に当たることがあります。

今回、その障壁を解消するためにシステムを開発しました。また、オープンにしてどなたでも利用してもらえるようにしたので今回はその紹介をします。

機能

早速ですが、システムについて説明します。

このシステムでは RTA の動画をアップロードすることで部屋移動、または Flag を通過したタイミングを自動で検出しそれぞれの区間で要した時間を解析します。
要するに部屋ごとのタイムを一覧できるということですね。

以下に出力の一部をサンプルとして貼ります。

マデリンが部屋の境界を通った時のスクリーンショットおよびその時点のタイマー(スクショの切り取りおよび OCR で読み取られたもの)がそれぞれ表示されます。
タイマーの差分を取ることで部屋ごとの所要時間が計算できる、という寸法です。

1Aの動画をアップロードした際の出力例

表としても閲覧できます

上記の画面はこの動画を入力した結果の一部です、 youtu.be

サンプルの全体像は以下から参照できます。
(実際にシステムを使う場合は HTML ファイルをダウンロードして各自のブラウザで閲覧してもらう形になります。) https://greenteasocha.github.io/celeste-analyzer-result-sample/sample.html

画面は部屋とタイムの対応を確認してもらうほか、検出された区間端点やタイマーを読み取った数値に誤りがあった場合に修正してもらう UI も兼ねています。
どうしても精度に一定の限界があったためこのような対応になりました。

上記サンプルは自由に触ってみてもらって構いません。(他の人の閲覧に影響を与えません。)

利用には以下の Discord サーバーへの参加をお願いしています。
詳しい利用方法なども案内していますので、興味がある方はぜひお願いします。

https://discord.gg/nnDXTxZ6V2

練習への組み込みかた

出力された計測値の活用方法として、主にラン同士の比較を想定しています。

自分の記録動画と他のプレイヤーの記録動画を比較して短縮余地がどの部屋にあるか知る、
もしくは自分の複数の記録を比較して sum of best を割り出したりよくロスしがちな区間を明確にする、といった用途です。

full run ではなくチャプター/サブチャプター単位の動画を解析し、短い区間に着目した繰り返し練習や strat (ルート)分析および改善のサイクルに組み込むことを想定しています。
(システム的に長すぎる動画は扱えないのもあり )

実際に自分が練習していた時のサイクルを活用例として示します。

• 自分のタイムと目標タイムの動画をシステムに入力します。(参考動画は実際の目標タイムよりいくらか早いものを選ぶとよいでしょう。)
• 出力を csv として保存できるので、適当なスプレッドシートなどで比較表を作ります。
• プラスがついている部屋のうち理由が分からないもの(ミスしてないのに遅い)については複数の動画を見るなどして strat の情報収集をします。
• 目標タイムとの差分を回収できるように見直す部屋を選び、区間練習や本走をします。
• 早くなります(楽しい！)

5Bのルートを精査していた時のメモ

上記は 5B 2:30 を目標に練習していた時の実践例です。

ちょっとだけ妥協... と思っていた部屋が実は取り返せないレベルの大ロスだったので strat 見直しを行い、デスや操作ミスを自覚していたロスも練度を上げて回収することで目標タイムが出ました。

また「速いサイクル見逃し」の部屋については、速いサイクルを目指すとかなり難易度が上がるかつ他の部屋の改善で目標タイムに届くということが分かっていたので無理をしない strat を採用することができました。

できるだけ面倒を減らしたい！という方針で開発していたので、もしよければ実際に試してみてもらえると嬉しいです。

ちなみにですが、そもそも目標タイムをどう設定しよう？という点に関しては以下のスプレッドシートがとても参考になります。

Celeste Any% Practice Sheet Template - Google スプレッドシート

開発の経緯

ここからはおまけになるのですが、なぜ自分がこういうシステムが欲しいと思ったか、そして実際に作ってみたかを書きます。

Celeste の RTA なのですが、中級者くらいのタイム帯になると練習の進め方がわからなくなってくるな、と感じていました。

というのも最終的にタイムを縮めるという一つの目標に対して取れるアプローチがどこにあるのかわからなくなってくるためです。

まだ主要なアクションとかを身に着けていなかったり明らかにミスしたなと感じたり難しいテクニックはまだ取り入れていないので仕方ないと自覚していたり... という場合はいいのですが、ひとまず満足のいくランができた後にどう改善するかが急に難しくなると感じます。

ルートも覚えてミスなどもなかったと思うけどなぜかそんなに早くない、さてどうする？といった状況ですね。

おそらくそこからは speedrun.com に投稿されている記録から自分の目標タイム程度のものを探し、自分と違う点を探していくという方法が主流です。ですが、これが結構面倒です。

まずそもそも差がついている区間と原因を特定することですね。

どのサブチャプターが負けているのか？→そのうち前半が遅いのか後半か？→実際どの画面が遅いのか？→遅い画面で違う操作は何か？

といったステップを踏む必要がありけっこう根気がいります。

またここに潜む罠として「基礎動作(movement)」とか「Celeste 自体の上手さ」とか呼ばれる要素があり、strat は同じなんだけど各部屋 0.x 秒の微差が積み重なって区間として3とか5秒の差として現れているパターンもあります。

こういう場合は「頑張って原因を探そうと思ったが、結局今はできることがない」という結論になってしまうんですよね。

そして strat の違いを見つけることとともに、その strat を練習してみる/実際のランでも使うのがどれくらい意味があるか？の判断も難しい所です。

• 導入してどの程度縮むかの見積もり(効果が保証されていなくても取り入れてみるというマインド)
• できそうなのか難しすぎるかの嗅覚

が必要かなと。

ということでいろいろと必要な作業や経験値が求められており Any% 30分前後まで来ている人はこの当たりを持っている雰囲気を感じるのですが、RTA を始めてみて 40-50 分付近のプレイヤーだとここが停滞やモチベーション低下のきっかけになってしまう可能性を感じます。というより、自分がまさにそんな感じですね。

ここを乗り越えるには

• 情熱や時間をある程度注ぎ込むことができる
• それを乗り越えた人に教えてもらう機会が多い
• なんかゲームがめっちゃ得意

などの要因が必要っぽそうなのでこの当たりの障壁を下げて持続可能な RTA ライフの助けになればな～と思った次第でした。

簡単に拾えるタイムを拾う、むやみな練習が非効率な部分には見切りをつけて進むことで楽しいまま Celeste が上手くなれる範囲を広げることができたらよいなと考えています。

ちなみに、Celeste コミュニティはゲーム自体の仕様に加えて、情報共有、ツールの開発、イベントの開催などが献身的な人々によってかなり活発に行われおり、ここまでの記事内容と矛盾するようですがすでにかなり持続可能かつ大規模なものになっていると感じます。

その様子をしばらく見てきたので自分もその一部として貢献してみたい、という欲求もあります。

環境をより良くするために、もしよければ使ってみてフィードバックなどをいただけると嬉しいです。

おわりに

色々書いたのですが、実際そんな色々な人に使ってもらうのも難しいなとは思っているので7割日記や振り返り目的で書いてます。

自分が欲しいものを自分で作ることの楽しさですでにかなりの充実感は得ていて、開発に費やした時間は自分が使って回収することでナンボですね。

Celeste に限らずなのですが、面倒だな～と思うことに対して改善ツールなどを作成することで満足することで本来やるはずだったことに戻らないみたいな前科があるのでこれを使ってちゃんと早くなりたいと思います。
結果が出ればシステムの有効性も証明できて一石二鳥！

今年は山の日並走イベントにも出ます！リラーニングの過程でやっぱり sub30 って遠いんだなと実感したりしている最中ですが、できるところまで仕上げたいですね。

それでは以上になります。ありがとうございました～

インスペクションにおける F2L#1 読みの簡略化

こんにちは。

最近、インスペクションにおける F2L#1 読みについてたびたび考えています。 今回はそのうち言葉にできそうな一部分について、備忘録もかねて共有します。

F2L読みの難しさ

インスペクションですが、クロス手順を回したときにU面に存在するコーナーを探す→対応するエッジを探す という流れで行っています。

クロスの難しさやパーツのくっつきなどによって読める度合いが違い、おおよそ以下のうちどれかになります。

• コーナー/エッジパーツの位置とすべてのステッカーがわかる(F2L 手順わかる)
• コーナー/エッジパーツの位置とEO, COがわかる
• コーナー/エッジパーツの位置のみわかる
• コーナーのみわかる

上二つの違いが分かりにくいと思うのですが、1枚目と2枚目の違いだと考えてもらえれば。

コーナーが赤黄という前提があれば、2枚目の情報だけでも論理的には F2L が決定します。 青ステッカーの位置が決まった時点で残りのステッカーも決まるためです。

ところがインスペクション中の限られた思考リソースではそうもいかないんですね。

画像のようにキューブにステッカーをおけたら上出来なもので、コーナー/エッジパーツ別々に動きを追っているものですからかなり断片的なイメージしか残らないことが多いです。

おおよそこれくらいの情報量

そこで今回は EO および CO (=クロス色ステッカーの位置) のみで回すべき F2L、とくに IT 化までの手順を読めないかを考えます。

ステッカーがU面にない場合の難しさ

今回はパーツが埋まっている場合を除き、両パーツともU面に存在する場合を考えます。

まず、クロス色がU面に存在する場合はかなり楽です。

• エッジ側面とセンターを合わせる
• 目的のスロットからパーツが離れる方向に回す

ことから、エッジが読めればコーナーの場所に関わらず最初の数手が固定されます。 U2 R とか回している間に次のことを考えればよいです。

(実は例外もいますが... エッジとコーナーが隣接している場合は注意が必要です)

「とりあえずエッジ側面とセンターを合わせてから考えよう」のやつら

一方でクロス色が側面を向いているものは結構判断が厄介です。

厄介なやつら

例えば

• 1枚目はそのままスロットインできる形なのに対して2枚目は R' U2 R によるT化が必要
• 3枚目は R U R' によるI化なのに対して4枚目は R U' R' によるT化

というふうに、判断結果によって regrip や指の初期位置が変わることが多いです。

「左右どちらのスロットに入るか」という基準の導入

前節の問題への対処として以下の考え方を導入します。

エッジパーツの EO を合わせた場合、かつその F2L を手前側でスロットインすると考えたときに左右どちらのスロットに入るか

1枚目は赤がF面なので左スロット、2枚目は黄色がF面なので右スロットです

重要なのは、左か右かは EO によって決まるということです。 言い換えればエッジパーツのみを見ればわかる、とも言えます。

1枚目が左スロット、2枚目が右スロットです

逆に、何色の F2L ペアなのかはこの区別に関係しません。

RU'Rと出せば左スロットに、L’ULと出せば右スロットになります。

スロット区別によるF2Lの判断

左スロットの場合 ... CO が Clockwise なら I化、Counter-Clockwise なら T化 です。
右スロットの場合 ... CO が Clockwise なら T化、Counter-Clockwise なら I化 です。

いきなりどうしたという感じではありますが、以下の画像からなんとなく察してもらえるのではないかと思います。

例で示しているのは「左スロットで Clockwise なので I化」のパターンです。 他の3パターンについても類推してもらえると助かります。

---

さて、この基準を用いて厄介なやつらの判別に戻ります。

1枚目は判断基準から I化 です。RUR' から適当にスロットインします。 2枚目は T化 です。RU'R' から適当にスロットインします。

この基準は実際使えるのか

先ほどの判断例ではかなり端折っていますが、いくつかの段階を踏むため正直複雑ではあります。

人やスクランブルによっては

コーナー/エッジパーツの位置とすべてのステッカーがわかる

に持っていくほうが簡単ということもあるでしょう。

個人的には「クロス後の具体的なパーツ位置に関わらず、まず I/T の判別のみをできる」というところに意味があるのでは、とは考えています。

背面にパーツが固まっていたりEOが合わず持ち替えが要求されるといった手順表にそのまま乗っていない状況などに役立つのでは、とぼんやり考えていますが... 上手く言語化できていません。
(本当はクロス終了時に EO が合っているようにしたいものですがクロスの回しやすさを優先して難しい場合もあると思います。)

まあ最終あんまり使わなかったとしても視点の一つとしてはいいかなと

終わりに

いかがだったでしょうか。
ここまで思い付きで書き進めたので今になってだれかもう言ってるないような気がしてきた。

タイムを縮める練習としては普通にクロスのルートを複数考えられるようにするとかペア保存とかそもそもLLなどほかのステップを鍛えるなどありますが、F2L 読みについて重点的に練習したいなと思ったときにはちょっと試してみていただけると嬉しいです。

公式 sub10 するぞ～

BLD練習用に作っているツールの話

挨拶

初めまして、もしくはお久しぶりです。

この記事は Speedcubing Advent Calendar 2025 - Adventar の12日目の記事です。

11日目は凛さんの「スキューブBLD」
13日目はCuCuberさんの「Skewb〜平均sub5と、その先へ」です。

スキューブに挟まれていますが今日はBLDの話です。

BLD練習の補助として以下のツールを作っているのでそれぞれ紹介します。

• 実行ステップの習得補助ツール
• 実行ミスの原因検出ツール

それではよろしくお願いします。

実行ステップの習得補助ツール

こちらは開発途中のものですがWeb公開しているので良ければアクセスしてみてください。 仮にBLD Execution Trainerとしています。

https://cube.sochadev.click/

BLDをやったことがない人も、キューブが解ける人であればなんとなく雰囲気はつかんでもらえるのではないかと思います。
またPCでのアクセスを想定しています。

使い方

BLD Execution Trainerは、主にM2OPまたは3styleを習得中の方を想定ユーザーとしたツールです。

初回アクセス時に解法を選択します。
解法選択後にスクランブルを入力すると、分析結果の一例とそれぞれの手順を表示します。

手順が表示されると、Enterキーで表示される手順を進めることができます。
実行ミスかバグがなければ最後にはキューブが完成していることでしょう。

任意のタイミングでCtrl+Enterで最初から表示、または別スクランブルの解法を表示することができます。

ツールの立ち位置

元々趣味というか個人利用的な範囲で作っていた簡素なツールではありますが、せっかく公開したのでできれば使ってもらう機会があればよいなと思っています。

そこでこのツールをどのような意図で作っているか、どのような人に向けているかを簡単に説明させてもらいます。

ずばり、主な対象ユーザーは以下を想定しています。

• BLDで揃えたことがない人
  • M2OPモードでとにかく回してもらう
• 3styleに移行したい人
  • 3styleモードでとにかく回してもらう

そもそも、BLDの練習を語るうえで欠かせない偉大な存在としてhinemosがあります。

hinemosはレターペアや手順管理を中心とした様々な機能で日本のBLDのレベルを底上げしており、早くなりたかったらhinemosで3styleクイズをとにかくやりこむというのが間違いないルートでしょう。

saxcy.info

一方でExecution TrainerはBLDの裾野を広げるようなサービスをゴールとして作っています。
機能を絞ることによって、特に「事前準備なく始められる」「とりあえずページを開けば練習できる」という風にハードルを下げる狙いです。
(毎日cstimerを開くような気軽さをイメージしています。)

そもそもBLD習得の難しさとして、とりあえずやって覚えるという方法がとりづらいという点があります。

BLDの解法で一回揃えてみるまでのハードル(ナンバリング設定、分析方法の理解、適用する手順の理解)が高く、独学だとなかなかexample solveを真似してみるところから先に進めない場合もあるのではないかと想像します。

そこでExecution Trainerでは意味が分かっていなくても画面の指示に従うままBLDの流れを体験することができて、しばらくしてから入門資料などを読み直してこういうことだったのかと後付けで理解してもらうことを目標にしています。

適当にそれっぽいこと言うなら 理解→実践 が主なBLD習得方法である現状の中で、実践→理解 派の人にもBLDを習得してもらうチャンスを増やせたら良いなという感じです。

逆にですが、スタートラインに立ってからより練度を上げたい場合はhinemosを使ってもらうのが良いと思います。

ちなみにhinemosも「3x3x3目隠し M2/OP法 甘やかし編 個人レッスン」や覚えた手順のみで解けるスクランブル生成機能(3-style Scrambler)など習得者向けの機能が充実しています。
hinemosを用いたBLDの練習法は以下のブログが参考になると思います。

https://sak-cube.hatenablog.jp/entry/2018/05/12/221500

https://sak-cube.hatenablog.jp/entry/advent-calendar-2020-1

未実装の機能

機能を絞るといいつつ、以下の機能は必要かなと思っています。
単純に間に合ってないだけなのでおいおい実装予定です。

• ログイン、手順登録
  • ログインしなくてもデフォルトの手順セットで利用可能にはします
• ランダムのスクランブル生成
  • 現状ではcstimerなどからスクランブルを取得する必要があるので、1画面で練習がすべて完結するようにする予定です
• 交換分析の有無、ループ後の選択パーツ優先度指定
  • 自分の解法の都合でパリティありの場合は必ず交換分析をさせる設計になっています。初心者向けという題目と矛盾しているので優先して修正す予定です。

実行ミスの原因検出ツール(仮)

ここからはもう一つのツールの紹介をします。
もう一つというよりは、源流が同じツールの完成していない部分って感じでもありますが...

BLDの練習における別の難しさとして、実行終了後に揃っていない場合どこでミスをしたのかわからないという点があります。
特にあるあるなミスを把握できていない初学者の場合は振り返りが難しいです。

そこで、実行終了後のキューブの状態を入力することで発生した可能性のあるミスを提示するツールを作成しています。

画面を見てもらったほうが把握しやすいかと思うので先に出します。

画面上の入力内容は主に二つで

• スクランブル
• 実行終了後のキューブの状態 (「誤った終了状態」とします) です。

状態の入力方法については詳細は省きますが、2006NISH01さんの記事での定義を使わせてもらっています。

qiita.com

さて、実行ミスは二つに大別されます。

1つ目は実行すべき手順の選択ミス。
例えば UF → UR → UL と実行すべきところを間違って UF → UR → DR と実行してしまったなどのケースです。
これには分析・記憶のミスも含まれます。

2つ目は特定の手順の実行ミス。
例えば R U R' D R U' R D' と実行すべきところを間違って 「R2」U R' D R U' R D' と実行してしまったなどのケースです。

ミス分析用ツールではこの両方を検知します。

画像は、先ほどの入力を行った場合の出力例です。

• スクランブルから完成状態にたどり着く手順列
• スクランブルから誤った終了状態にたどり着く手順列

をそれぞれ導出してその差分を出すようにしています。

(画像は特定の手順をミスした場合のパターンです。)

ブラウザで入力用のUIを作るのが面倒そうで公開の目途が立っておらず記事内では後回しにしましたが、どちらかというとこちらのツールのほうが本題です。
出力例を見るとわかると思うのですが、公開したほうの練習ツールは一部分を抜き出してWeb公開用に整えたものになります。

こちらもそのうちWeb上で動くようにしたいなと思っています。

おわりに

ということで、進捗報告的な感じでアドカレっぽくない記事になりましたが、作ったもの/作りたいものの話をさせていただきました。

最終的にはBLDの練習がもっと簡単になってBLDの裾野が広がったり競技レベルが上がればよいなと思っています。(何より自分が使いたい)
2019年のアドカレからBLDの話してるくせに肝心の練習から逃げ続けて全然早くなってないので、2026年こそは...

あとこれ元々は5BLDのミス分析をしたいってのが始まりだったんですが、見積もりがザルすぎて今のところ全く完成の目途は立ってません。

ツールはスローペースな開発速度になると思いますができる範囲で進めていきたいので、もしよければ反応やバグ報告などいただけると嬉しいです。

それではお読みいただきありがとうございました。
明日以降の記事もぜひお楽しみに。

FMC Advent Calendar 2023 22日目

FMC Advent Calendar 2023 22日目の記事です。

21日目は Shota さんのFMC Advent Calendar 2023 21日目でした。

23日目は たむそんさんの 「いいかい学生さん、sub25をな、sub25をいつでも出せるくらいになりなよ。それが、人間過ぎもしない神過ぎもしない、ちょうどいいくらいってとこなんだ。」です。

こんにちは。(挨拶)

普段FMCに取り組んでいる方では初めましてが多いでしょうか、煎茶と言います。
普段は3や3BLDをメインにやっています。

FMCについては11月に開催された綾瀬FMC2023の申し込みをきっかけに始め、BBをやっていました。
せっかく取り組んだFMCのモチベを保とうと思いアドカレに登録をしましたが、12月に入って Speedcubing Advent Calendar のほうであむす式簡易DR(以下、あむす式)の紹介記事が出ていたのでこちらを試しました。
BB歴も短く移行の苦労もないので。

あむす式については以下のブログをご覧ください。

amusucube.blogspot.com

解答

注意事項:
今回のソルブは最初から1時間を超える想定で行い、実際に2時間程度かかっています。これは探索を広く行ってより短手数を目指す意図ではなく、単純に自分がFMCおよびあむす式に不慣れでそもそもこれくらいの時間を要するためです。ご了承ください。

scramble:  R' U' F D B' U' L U B' R U' L2 F2 U2 R2 D' R2 L2 U' L2 B2 F D R' U' F
solution: L' D R' B2 U B' R2 B2 R U R U' L F2 R' B2 R F2 R' B2 R U R' U F L2 R2 B D2 L' B2 R2 U2 L' F2 B2 R' U2 F2 U2 F2 U2 L2 D2 B2 D2 L2 R2 U2 L2 R2 D2
(52手)

L' D R' B2 U // EO (U/D)

B' R2 B2 R          // 4c
U R U' L U R' U' L' // 8c (-3c) 

L U2 F L2 R2 B             // DR (L/R)
D2 L' B2 R2 U2 L' F2 B2 R' // HTR

U2 F2 U2 F2 U2 L2 // FR
D2 B2 D2            // 4e
L2 R2 U2 L2 R2 D2    // finish


skelton: L' D R' B2 U B' R2 B2 R U R U' L * U R' U F L2 R2 B D2 L' B2 R2 U2 L' F2 B2 R' U2 F2 U2 F2 U2 L2 D2 B2 D2 L2 R2 U2 L2 R2 D2
* = [F2, R' B2 R]

カレンダー上で大御所の二人に挟まれている中で大層な記録が出てしまいましたが、振り返っていきます。

振り返り

EO

FB軸で D' F D2 L' B(B'), UD軸で L(L') D R' B2 U(U') を発見しました。

他の方の回答を見ると4手があるようでしたが、残念ながら発見できませんでした。

次ステップがやりやすかった L' D R' B2 U を採用します。

4コーナー

今回あむす式で説いているので、次のステップは4コーナーです。

緑と橙を含むコーナーの配置が良く、残りの緑コーナーも B' R2 B2 R で簡単に入るのでこれで進めます。

あむす式ではHalf Turnのみで完成状態に持っていける配置であればOKなので青コーナーを入れることも一応考えましたが、これは上手くいきませんでした。

このステップではエッジを無視できるので自由度が高いと思いきや、EOで軸になっている面の制約が思った以上に大きくもどかしい気持ちになることが時々あります。

8コーナー

あむす式ではコーナーOLLからのPLL skip(CP skip)を狙いますが、自分は最初に3点交換で完成(とみなせる)状態に持っていけないかを確認します。

今回は残念ながら2点交換 + 1COでした。
4コーナー時点で最初に R をいくら挟んでもよかったので試してみたのですが、すべて2点交換 + 1COに収束してしまいました。

諦めてコーナーOLLを回します。

コーナーOLLを回すと3点交換になっていたのでOKとします。
ただしA-Permは長いので、最終的にコミュテータをインサートすることにして先に進みます。
(回答上ではまだコーナーを完成させませんが、実際は以降のステップのためにA-permで揃えています。)

DR, HTR

数をこなす地力もないので、とにかく完成することを祈ります。

あむす式で紹介されている形へのセットアップ及びDR手順の実行はやるだけなのですが、DR終了後に崩れたコーナーの復元が鬼門になることが多かったです。

コツとして、DRのセットアップの時に必要なQTが0~1に収まること、正しくDRの面に来ていないエッジが1~2個であることを祈ります。
そうでない場合自分の地力ではコーナーが復元できず詰むので、コーナーの作成に戻ったりします。

今回は最初にたどり着いた8コーナーでの運がよく進めることができ、またHTRで揃っていないエッジも2個で最も簡単なパターンでした。

FR

HTR完成後ですが、詰めキューブやBBが下手すぎてなかなか完成状態に持っていけなかったのでFR(Floppy Reduction)を覚えることにしました。

あむすさんのブログからも紹介されていますが kusanoさんのサイト や、FRについてのドキュメント が参考になります。

進め方自体はほぼ選択肢がない(と思う)ので、素直に進めます。

Finish

とりあえずブロックになっている部分を頼りにE層以外を完成させようと思ったら2e2eになりました。 スライスインサートをする体力が残っていなかったのでエッジ交換手順を実行して終了です。

insertion

終了じゃなかった。8コーナーの時に残した3点交換を処理します。

これに関してもキャンセルを見つける体力が残っていなかったので最初に気づいた地点に差し込んで終了です。

まとめ

アドカレ期日までに一応習得・完成まで持っていくことができて良かったです。

あむす式ですが、本当にブログに書かれている方法や手順だけで毎回完成までもっていくのは少し厳しかったです。
というのも、文章中でさらっと流されているところに結構な運や詰めキューブ力を要求される部分があるためです。
(これは自分視点の話であり、逆に言うとあむすさんが持つルートを増やすための探索力や詰めキューブ力がとても高いのだろうと感じました。)

というわけでコーナーを揃えるための試行錯誤を考えたりFRについて学んだりしましたが、この過程であむす式の思想である「DR習得までのハードルを下げる」の恩恵を大きく受けました。
比重の大きいDR, HTRをの理解をいったん最小限でパスできるからこそFRとかに目を通す気力が出ましたし、FRを先に習得することでDRやHTRの雰囲気も最初よりは分かるような気がしました。
(FRのMazeを見た後のHyper-Parity Mazeなど)

総合してあむす式はDRへの橋渡しとしておすすめしやすい解法なのではないかと思いました。何様目線？という感じですが...

おまけですが、8コーナー完成を目指すステップで試行錯誤した際のメモを貼っておきます。リンク

今後は1時間以内にそれなりの回答を出せるようになったり、DR自体も習得できれば良いなと思っています。

それではここまでお読みいただきありがとうございました。

C#が全く分からない人向け Celeste Code Mod入門: 環境構築編

0. 初めに/ 免責事項

こんにちは。

突然ですが、最近CelesteでFarewellの金苺狙いをしています。Farewellの金苺狙いはあまりにもモチベ管理が大変なので、自分用にEverestを用いてMODを作成しました。

Celesteで金苺持ちながら死んだ場所を自動的に記録できるようになった いいですね
これでやっとFarewellの練習が始められる pic.twitter.com/FnuG4elhH3

— 煎茶 (@sentya7) 2023年1月9日

環境構築に戸惑ったので、今後触る方に向けて少しでも助けになればと思い、記事を作成しました。

なお、「C#が全く分からない人向け Celeste Code Mod入門」の続編予定はありません。

この記事ではEverestの仕組みや、Everest APIを使って何ができるかといった説明は行いません。 自作MODを始める最低限のテンプレートを作成し、Everestに読み込ませるところまでを目標とします。

また、自分も「C#全く分からない人」であるため以下の方法で進めることが必ず正解ではありません。自分の一体験としての記録を残すつもりですので、ご了承ください。

環境はWindows / Steamでのインストールを想定したものです。

1. Everestのダウンロード および OpenGLへの切り替え

初めにですが、Steam上で簡単な変更を行います。

おそらくこのページを見ている人はすでにMODで遊んでいる(=Everestをインストール済み)かとは思いますが、起動方式を変更しておきます。(起動方式って呼び方で合っているかな...)

OpenGLという方式で起動する必要があるようです。コードをいじる気がなくても、Everestで遊ぶ場合はこちらを選んだ方がメモリ使用量やクラッシュする頻度が減るため変更しておくことをおススメします。

This setup doesn't require NuGet or git, but if you're a Windows user, you'll need to switch to the OpenGL branch.

参考: Code Mod Setup · EverestAPI/Resources Wiki · GitHub

変更方法

• SteamライブラリのCelesteを右クリック → プロパティ

• 「ベータ」 → openglを選択

プルダウンで選択した時点で変更が始まります。アクセスコードは入れなくて大丈夫です。

こうなっていたら大丈夫です

openglへ変更をすると、Everestを再度入れ直す必要があります。

普段通りOlympusからEverestを起動しようとするとインストールを求められると思うので、指示に従って進めてください。 セーブテータやMODは保持されているので大丈夫です。

説明についてはこのへん

2. Visual Studioのダウンロード

まずは .NETをインストールします。 docs.microsoft.com

次に、Visual Studioをインストールします。恥ずかしながらEverestを触ろうと思うまで自分も混同していたのですが、Visual Studio Codeとは別物です。 無料のCommunityバージョンでOKです。

visualstudio.microsoft.com

これ以降のVisual Studioについての説明は、おそらくバージョンが変わっても同じになるかとは思いますが自分がインストールしたバージョンは17.2.4でした。

Visual Studioのインストールが完了したら一回閉じておいて大丈夫です。

3. 自作MOD用のテンプレート作成

まずは、作成したMODを入れる空のフォルダ(ディレクトリ)を作成します。 Celesteに関連したファイルがどこに保存されているかは先ほどと同様にSteamから辿ることができます。

「ローカルファイルを閲覧」

Steamからプレイしている場合、おおよそ C:\Program Files (x86)\Steam\steamapps\common\Celeste のような場所にあるかと思います。

Mods フォルダの中に好きな名前で新しいフォルダを作成してください。

そうしたら先ほどダウンロードしたVisual Studioを起動し、空のMod用ファイルを開きます。

「ローカル フォルダーを開く」

開いた直後はこのようになっていると思います。「開発者用PowerShell」が見えない場合は、ウィンドウ上部の「表示」タブ→ 「ターミナル」で出してください。

PowerShell上で dotnet --version などを実行し、dotnetコマンドが使えるかどうかを確認します。

dotnetコマンドが使えない場合は、

winget install Microsoft.DotNet.SDK.7

でインストールします。指示に従って進めてください。
(注: 現在(2023/3)ではバージョン7が安定バージョンとなっていますが、今後新しいバージョンがリリースされると .7 の部分が変更になるかと思います。)

参考: Windows に .NET をインストールする - .NET | Microsoft Learn

dotnetコマンドが使えることを確認したら

dotnet new install CelesteMod.Templates

でテンプレート作成用ライブラリをインストールしたのち

dotnet new celestemod

を実行します。

必要なファイルが作成され、先ほど作成した空のフォルダが以下のようになっていれば成功です。

注: この時点でEverestを起動するとエラーになります。
正常に起動させるには次の「4. デフォルトの状態でビルド」節までの作業を完了するか、作業を途中で取りやめる場合は作成したフォルダ(例の場合は「MyTestMod」フォルダ)を丸ごと削除し、次回作業時に「3. 自作MOD用のテンプレート作成」節の最初からやり直すことをお勧めします。

4. デフォルトの状態でビルド

補足および謝罪

Mod作成時のメモに「初回ビルド時にDeveloper Toolがないと怒られたのでインストールした」と書かれていたのですが、3ヶ月くらい前のメモであるのと今になって再現できないので、割愛させてください。
おそらく何が足りないかがエラーメッセージなどに現れると思うので、適宜対応していただければと思います... 🙇‍♂️
もしも思い出したり再現できたら書きます。

気を取り直して...

Visual Studioを開いたばかりの状態ではメニューバーにないのですが、.sinファイルを開くと「ビルド」が表示されるようになるので(??)開きます。

① 「表示」 → 「ソリューションエクスプローラー」② 「(自分の作成したフォルダ名).sin」をダブルクリック

メニューバーの「ビルド」→「ソリューションのビルド」を実行します。

しばらく待つとウィンドウ左下に「ビルド正常終了」が表示されます。

ビルドが正常に終了すると、テンプレートで作成された bin フォルダの中にdllファイルが作成されます。
ここまで完了するとEverestを起動し自作したMODを読み込ませることができます。

ゲーム開始画面の「MOD設定」→「MODを有効化・無効化する」

5. おわりに

お疲れさまでした。ここまでうまく運べば、以降は公式リファレンスとコードとの対応付けを確認したり、Everest上での動作を見ることができるので少しは進めやすくなるかなと思っています。

公式リファレンスはそこそこ充実していますので、やりたいことに合わせて探索していただければと思います。

github.com

また、GameBananaなどで公開されているMODはGitHub上でコードが公開されていたりもしますので、自分がやりたいことと近いものがあれば覗きに行くのもよいかと思います。

自分もまだまだModのさわりしか分かっていないので、もし今後知識が増えたら続編として書こうかなと思っています。

それではまた。

Notionで3-styleを管理する試み

こんにちは、1年ぶりになります。
煎茶と申します。

この記事は Speedcubing Advent Calender 13日目の記事になります。

adventar.org

前日分はノムノム さんによる 「パリティ回すのが楽しくなる！パリティ回してる間に読めることがたくさんある！　読まないともったいない！」
翌日分はyukiさんによる 「いつのも大会ができなくなってもう2年が経ちますね」
になります。

今回は、タイトルのまとまりのなさから察されてしまうかもしてないのですが「とりあえずここまでやってみた」系の記事です。
3-styleを一通り習得するまでの辛さやマンネリをなんとかしたい！という思いから生まれたアイデアをとりあえず共有したくなって、アドカレの場を借りさせていただきました。

また、めちゃくちゃ宣伝なのですがもしよろしければ過去のSpeedcubing Advent Calenderに投稿させていただいた以下の記事たちもご覧ください。(主催の荒木さんいつもありがとうございます。)

2019:
UFRバッファ入門 - socha77’s blog
2020:
ルービックキューブにおけるGod's Number解明までの歴史 さわりだけでも理解したい！ - socha77’s blog

はじめに

3-style、覚えるの難しくないですか？？？

3-styleは主に目隠しでのソルブに使われる手順なのですが、
- 人によって好みの手順がまちまち
- 手順数が多すぎるので脳内だけでは管理しきれない(はず 一般人では)

といった理由から自分用に整理した手順集をドキュメントとして公開している人が結構います。

対象となるステッカー1個目と2個目の組によって回す手順が決まるためGoogle Spreadsheetを使った表形式で共有されることが多いです。

Graham Sigginsの手順表から引用(https://docs.google.com/spreadsheets/d/1-AnKGJMHN3SAOcZxem3XJ5tBm7Dk1dTRcZ7KcXYbGP4/edit)

世界のBLDerの手順表は以下のページによくまとまっています。
BLD tables/algorithms collection

ただ標準的な管理方法となったこの形式ですが、見ながらずっと練習してると飽きてしまうなあと思うことがありました。

基本的に呪文に近い文字列の羅列なので目が参ってしまうし、表がでかいので今回している手順(セル)がどのステッカーの手順(表の何行何列)なのか が分からなくなってきてしまうんですよね。

最終的には hinemos を使って1日1週するのが最強だと思うのですが、これは一通り手順を回せるようになった人向けなので、3-style練習の入り口に立っている時点では結局スプレッドシートとにらめっこすることになります。結構苦しいのではないでしょうか。(実際苦しかったです。)

というわけで、そういった状況に対する提案の一つとして別の形で手順表を作成してみました。

Notion上の手順表

作成したものが以下になります。 Notionというサービスを使っています。

全体公開にしているので以下のリンクから見ることができます。 https://www.notion.so/71395fd7cff44ad99d4a45bde9327999?v=11cf6925135f420ba4960e9b2cc175c0

こんな感じです

この表の大きな特徴として、ソートやフィルタリングを活用することで色々な視点で手順を整理することができます。
ためしにいくつかカスタマイズで設定してみました。左上のメニューから選択することができます。

また、このページはただの表ではなく、それぞれの行が詳細ページへのリンクになっています。マウスオーバーをして「OPEN」をクリックすることで詳細ページを見ることができます。
(今回は例なので、[U' R : [B2 , R' D R D']] のページだけ中身を作っています。)

Notion管理のいいところ

Notionで3-style管理に良さそうな特徴として、ざっくりと以下の4つがあります。 (すでにこの記事の中で言ったことと被っていますが)

ネット上で共有が可能

上に貼ったように共有用のURLを発行して公開することができます。なのでgoogleスプレッドシートと同じくらいの気軽さで共有、閲覧ができます。
スマホからだと個人的にNotionのほうが見やすそう。

また編集権限を設定することができるので、知らない人に手順表を破壊される心配なく公開ができます(設定はちゃんとやる必要があります)。

プロパティを設定してソートや絞り込みが可能

それぞれの手順にプロパティ (対象のステッカー、手順のうちピュアコミュテータ部分を抜粋したものなど) を設定することで、ソートや絞り込みを行うことができます。

プロパティは自由に追加できるため、例えば自分の得意度やregripのあるなしなどを記入してフィルタリングをしてもOKです。

各手順に細かいメモなどの記入が可能

DBの各行は実体が1手順につき1つのページになっており、各手順に対するメモなどを記入することができます。　　 (「OPEN」で開くページです)

回し方のコツやレターペアのイメージ画像といった補足情報を蓄積していくことでDBを育てていくのも面白いのではないでしょうか

スクリプトにより自動的に作成

ここが今回Notionに目を付けた1番の理由となります。

3-styleはコーナー/エッジ合計で818手順あるため、手動で入力しようとすると数日がかりになりますしミスもします。
しかしNotionが提供してくれている機能のおかげでこちら側でプログラムを組むことにより機械的にデータを登録することができます。 今回例として公開しているDBのプロパティは全て自動で作成しており、やろうと思えば各手順の詳細ページにも手を加えることができます。

終わりに

というわけで、「Notionで3-styleを管理する試み」でした。
本当は自分以外のBLDerの皆さんにも試してもらえるようツールを公開したかったのですが、色々と間に合いませんでした... (ある程度形になったら公開したいと思っています)
今までと変わった視点からの練習方法を考えるきっかけにでもなれたら嬉しいです。

(本音は全く手順を回せなくなったのになんとかしがみついている感出したいマンなので、何とか復帰したいところです)

それではここまでお読みいただきありがとうございました。

AWSでKali Linux入りのEC2を起動してCloudWatch Agentを仕込む

はじめに

今回Kali Linuxをはじめて触ってみたいと思ってちょっと調べていました。

手元にサブPCやサーバを用意するのが一般的かと思いますが、AWS上でも建てられるということを知りこちらを試すことにしました。

訳あってCloudwatchへログを転送したいと思ったのですが、設定中に少し詰まるところがあったので備忘録としてEC2作成からログ転送完了までの流れを記しておくことにします。

作業の流れ

大体の部分はCloudWatchでログ監視みたいな文脈で調べると出てくる手順とほぼ同じかと思います(今回の作業でもそう調べて従っているので)。

エージェント導入に関して参考にしたのはここ。
クイックスタート: 実行中の EC2 Linux インスタンスに CloudWatch Logs エージェントをインストールして設定する - Amazon CloudWatch ログ

EC2は作成済みの前提で進んでいますが、その辺りは色々な場所で解説されているので割愛。
少し普段と変わっている部分だけ次の節で補足します。

EC2の作成(補足)

Kali LinuxのAMI選択

インスタンス作成で一番最初の画面で、"Amazon MarketPlace"を選択 -> ”Kali”などで適当に検索

Kali LinuxのイメージはEC2インスタンス自体の料金に加えて、イメージ作成者へのサブスク料金が必要になります。

が、あってないような値段なのであまり問題にはならないと思います。
(AMIイメージの選択時に料金表が出てくるので確認してみてください。)

セキュリティグループの設定

Webサーバーではないので、自PCからのSSHだけ許可しておけばいいと思います。

「マイIP」で今コンソールを開いているPCのIPアドレスを指定できるということをこの前教えてもらって初めて知りました

ログイン

ログインユーザー名が ec2-userではなくkaliになっています。そこだけ注意

$ ssh kali@{EC2インスタンスのアドレス} -i {秘密鍵へのパス}

ログ転送などをする必要がなければここで終了です。

インストール用スクリプトの取得、修正

先ほどの公式導入ガイドに従っていきます。

AmazonLinux2であれば "sudo yum install -y awslogs" で済むところですが、
yumが入っていないのでドキュメント上「既存の Ubuntu Server、CentOS、Red Hat のインスタンスに CloudWatch Logs をインストールして設定するには」の部分に沿って行きます。(どれでもないのですが)

$ sudo apt-get update
$ curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O

ここで本来はawslogs-agent-setup.pyを起動するところですが、Kali Linuxに対応していないためエラーとなります

$ sudo python ./awslogs-agent-setup.py --region us-east-1
Launching interactive setup of CloudWatch Logs agent ...
ERROR: Failed to determine linux distribution. Exiting.

pythonスクリプト中で現在のLInuxディストリビューションを推測しデフォルトのシステムログの場所を指定する処理があるようなのですが、推測対象の選択肢にKaliが入っていないためエラーを吐かれているようです。

というわけでawslogs-agent-setup.pyに数ヶ所追記します。

なお、以下にある画像ではdiffの表示のためにローカルに落としたコードをVSCodeで表示していますが、実際の作業の際にはインスタンス内で使える各種エディタで編集をしてください。

修正箇所1

・enumっぽく定義されている定数にKaliを加えます。
・Kaliではパッケージインストーラにapt-getを使っているのでその旨を指定します。

修正箇所2

・ディストリビューションを推定する部分でKaliを発見できるようにします。
推定には /etc/issue の中身を見ているようで、Kali Linuxでは(?) "Kali GNU/Linux Rolling" と書いてあります。

修正箇所3

・もう一ヶ所、有効なディストリビューション一覧にKaliを追記します。

全然改行されていないせいで見えなくてすみません。末尾がこうなります。

修正箇所4

・最後に、システムログの場所を指定する分岐に追記します。 Kaliの場合は /var/log/syslog のほうのようです。(間違っていたらすみません)

以上でソースの修正は全部になります。
以下のリンクなどの情報を参考にしながら、"AmazonLinux" でファイル内検索をして修正箇所のあたりを付けていました。

VAL の LABO: CloudWatchのログ蓄積とモニタリングを使ってみる（その１）

Kali-Linux AMI & AWSLogs. Today we had to build a Kali Linux AMI… | by Netscylla Cyber Security | Medium

インストール ～ 起動

ここまでくればおそらくCloudWatch Agentを入れることができます。

# regionの設定はよしなにお願いします。
sudo python ./awslogs-agent-setup.py --region us-east-1

対話形式での各種設定が終わったらそのまま起動をすることができます。
ただし、公式マニュアルのほうにはenableが書いていないので注意してください。

$ sudo systemctl enable awslogs 
$ sudo service awslogs start    

CloudWatch Logsのほうでシステムログを見ることができると思います。　　

もしも表示されない場合はIAMロールの設定なども見直してみてください。

おわりに

クラウド便利だな～と思って軽い気持ちで始めたところ詰まってびっくりしてしまいましたが、無事にいってよかったです。

特に目的があって始めたわけではなくなんか面白そうだなくらいの気持ちなのですが少しずつKali Linuxの機能を触っていけたらなと思います。

ここまでお読みいただきありがとうございました。