なっぱ箱

ゲームとか読書の感想とか時々技術系の話とか

じぶん Release Notes (ver 0.31.11)

じぶんリリースノート

なっぱ(ver 0.31.11)がリリースされました。更新内容は下記のとおりです。

技術関連

着手済未完了

イベント

買物

ゲーム

クリア

プレイ中

読書

読了

読書中

アウトプット

ふりかえり

Keep

  • 長々と読んでいたDDD本を読み終わらせることができた
  • RTAにチャレンジすることができた
  • ポケモンピカチュウ、undertale共に積むことなく全クリすることができた
    • 特にポケモンは図鑑を完成させることができた
    • 今回は楽になってるとはいえ、自力で図鑑完成は初の快挙🎉
  • ウォーキングだけでなくランニングをするようになった
  • 少しだが家事の改善を行った
    • 「人生が整う家事の習慣」を参考に

Problem

  • 教習所にあまり行けなかった
    • 教習所のシステムリニューアルがあったので仕方ないが・・・
  • 技術系のアウトプットが全然できていなかった
    • Pixelastの更新もできていない
  • もともと書こうと思っていたブログ記事が書けていない
    • LS Miniの導入について
    • crateの公開手順書
    • ロックマン11感想
  • NESエミュレータHelloWorldが全然速度出ていなかった

Try

  • 技術系
  • ゲームの感想を簡単にシェアできる方法、サービスを検討する
  • 教習は2段階後半まで進めたい
  • 来月も何作品かゲームが出るので積まないように気を付ける

ポケモンでRTAの一端に触れてみた

ゲーム 雑記

いつか自分もやってみたいなーと思っていたRTAに初チャレンジしたので感想をちょっと残しておく。

RTAとは

そもそもRTAって何？っていう人のために一応説明しておく。

「RTA」は「Real Time Attack」の略で、ゲーム開始からクリアまでの実際の時間の短さ(ゲーム内時間じゃなくて実際の時計の時間)を競うゲームのプレイスタイルの事。 よくある「タイムアタック」はゲーム内の時間(マリカーとかの最速タイムとか)を競うものだけど、RTAは実際の時間で計測するのが大きな違い。

ほかには言わずと知れた「TAS」があって、こちらは「Tool-Assisted Speedrun」の略。エミュレータ等を使って人間には不可能な操作して最速を競うというプレイスタイル。 エミュレータのクイックセーブを使っていい結果だけを残したり、メモリの中の値をみてエンカウントの調整したりしながら最速のプレイ結果を作って、最終的に最速の動画を作り上げる感じ。

今回やってみたRTA

ポケットモンスター ピカチュウ 専用ダウンロードカード特別版 (『ポケットモンスター X・Y・オメガルビー・アルファサファイア』で利用できる幻のポケモン「ミュウ」の特典コード付) - 3DS

ポケットモンスター ピカチュウ 専用ダウンロードカード特別版 (『ポケットモンスター X・Y・オメガルビー・アルファサファイア』で利用できる幻のポケモン「ミュウ」の特典コード付) - 3DS

今回は懐かしき「ポケットモンスター ピカチュウ版」をチョイス。ノイズ交じりの「ピッカー！(鳴き声)」がすげー懐かしい。 なお、選んだ理由としては下記の通り。

  • プレイ時間が2-3時間程度
  • アクションゲームじゃないから練習しなくてもとりあえずできそう
  • ぐぐったらチャートがすぐ出てきた
    • チャートはゲームごとの手順書的なもの。先駆者の方々が残した「どういう手順でプレイすればいいのか」がまとめてある
  • 偶然3DSのVC版を持ってた(残ってたセーブデータ見てみたら最初の草むらで止まってた)

ちなみに今回使わせていただいたチャートがこちら

ポケモン　ピカチュウ版チャート（並走用）:青にいとのブロマガ - ブロマガ

一言でいうと「ニドキング無双」

  1. 開始してすぐにニドラン♂をゲット(トキワの森前)
  2. 序盤から中盤は「つのでつく」と「あばれる」で殲滅
  3. 中盤以降は豊富な技幅と必中化した「つのどりる」で殲滅
  4. 最終的にニドキング1体で殿堂入り

※初代(赤緑)と2代目(金銀)の「ヨクアタール」は技が必中になるのだ！！！一撃必殺技でも！！！ちゅよい！！！

同じピカチュウ版をニドキングで走ってる人の動画はこんな感じ。

www.nicovideo.jp

結果

クリアタイムは3時間17分でした。 普通は2時間30分は普通に切れるっぽいのでクッソ遅い。

テストプレイしてないのがもろに影響していて、ダンジョンの中身が頭に入ってなくて大苦戦。特にイワヤマトンネル(フラッシュ無しで進む)

ちなみに殿堂入りしたときのゲーム内時間はこんな感じ。

差が出てるのは鬼門であるカスミのスターミーに何回かやられて全滅してたから・・・バブルこうせんこっわ。

感想

なかなか普段やってるゲームとは違う感覚で遊べて新鮮だった。 しいていえばそれこそレースゲーのタイムアタックに似てるんだけど、レースゲーはスプリント、RTAはマラソンって感じ。 やってみるうえで独別な機材もいらないし、タイムアタック好きの人は一度試してみるといいと思う。完走したときの解放感はなかなか。

興味あるけど自分でやるのはちょっと・・・という人はRTA動画見てみるのをオススメ。 人間がやってるからミスがあったりするし、運要素でドラマがあったりするから見ていてドキドキハラハラできる。 TAS動画見て「すごいけど失敗しないの分かってるし物足りないなー」って感じる人には向いてると思う。

とりあえずすぐに別のソフトで走ってみる予定はないけど、またいずれ何かにチャレンジしてみようと思う。

読了: 人生が整う家事の習慣

読書

本の概要

人生が整う 家事の習慣

人生が整う 家事の習慣

著者 本間朝子・藤原千秋・河野真希/監
ページ数 224ページ

内容

これまでの家事をリセット！家事の方法を見直して、効率のよい仕方、負担のない習慣をお教えします。

【本書の内容】
●一度やればずーっとラク！家事の棚卸し、家事の時間割
●人生が整う！掃除、洗濯、料理の新習慣
●できていない原因は家にあった...家事がしやすい家づくり

目次

  • １章　家事を見える化する
  • ２章　家事を習慣化する
    • （掃除）
    • （片づけ）
    • （洗濯）　
    • （料理）
  • ３章　家事がしやすいおうちづくり

感想

Kindle Unlimited対象になってたのと自分の家事を見直すためにサクっと読んでみた。 内容としては基本「家事のコツ集」なんだけれども、方向性が「家事を習慣化させるためには」に絞ってある内容になっている。

  • 1章: 家事の全体を可視化し、全体のコントロールをできるようにする
  • 2章: いろいろな家事のコツを知る。各家事を効率化
  • 3章: 再度全体に立ち返って最適化

このような流れ。 2章で家事のコツをつまみ食いするだけでもいいし、1章から読んで家事を全体から最適化するのに使ってもいい。

イラストも多めで読みやすいし、ボリューム的にもライトなのでKindle Unlimitedユーザーで家事やる人はザっと目を通してみるといいと思う。

家事の習慣とは

タイトルにある通り家事を習慣化させるには、というのがこの本のメインテーマになるんだけども、 ここでいう「習慣」は定期的にやる、というより「日常生活の一部として意識しなくてもいいくらいになりましょうね」といった側面での意味合いが重要になる。

「週末には頑張ってまとめて家事するか・・・」のように気合を入れて頑張って家事をするんじゃなくて、 「朝起きる → 着替える → 歯を磨く → ついでに洗面所をかるく掃除 → 出かける」といった具合で日常の定例動作の一部にしてしまえ、というもの。

家事を習慣化させるためには

意識しなくていいくらいの習慣にするためには「家事をするための心理的/物理的ハードルを下げる」というのが必須になるんだけれども、そこを助けてくれるのが「家事のコツ」。 例えば紹介されてるコツの中に「汚れやすい場所に掃除用具を置く」というのがあるんだけれども、これは「すぐに手に取れるところにないと掃除しないから」というのが理由。

朝歯を磨いているときに、「あ、洗面台汚れてるな」と気付くひとは多いと思うけど、その場ですぐ掃除にとりかかれる人となると数は結構限られてくる。この場合実行に移せない心理的ハードルとしては「掃除用具を取りに行くのが面倒くさい」というのが大きなウェイトを占めてると思うので、最初からメラミンスポンジとかの掃除道具を洗面台のところに置いておく、というのが解決策。

この場合使い捨てできるものが向いていて、下手に普通のスポンジが置いてあるだけだと「使用後にきちんと水を絞る」「おいてある場所に水垢ができていないかチェック」などの余計な手間もかかってしまう。

  • 非習慣化家事
    1. 洗面所が汚れているのを発見
    2. 掃除道具を持って来なければならない
      • 持ってくるの面倒くさい。戻すことも考えると億劫
      • あきらめたら汚れが積み重なって掃除がさらに大変に
    3. なんとか持ってきて掃除
    4. 終わった後は掃除道具を綺麗にする
    5. さらに掃除道具をもとにもどす
  • 習慣化家事
    1. 洗面所が汚れているのを発見
    2. 目の前にあるメラミンスポンジを手に取る
    3. ササっと掃除
    4. 使ったものはゴミ箱にぽい

「こうするべき」という固定観念にとらわれない

これは「抜ける手は抜いて調理をラクにする」という項目の一文なんだけれども、これって家事全体でも同じことが言える事で、「トイレは毎日掃除しなきゃ耐えられない」なら別にいいんだけども「毎日トイレ掃除しなきゃいけないのつらい・・・でもそういうもんだし」っていうのはちょっと思考停止だよね、という。

不衛生にならないようにするのが目的なんだから、便器が汚れにくいようにグッズ使うなりして便器が汚れない状態が保てるなら毎日の掃除をやめてスパンを長くしてもいいわけだし、目的と状況に応じて工夫していくのが大事なのかなと。

ちなみにこれって一番闇が深いのが調理で、「料理は手間暇かかってなきゃいけない！」っていうのを調理する本人が固く信じ込んでいて疲弊していたりするのってよくあるし、家族とかからプレッシャー掛けられる場合が家事の中でもダントツだと思う。

ちょっと前にバズってた「彼女にはクックドゥ使ってほしくない」みたいなのとか。

この本をお勧めする人

すでに日常的に家事をしてる人が「もっと効率的に家事したいなー」とか「家事もっと楽にできないかなー」と思ったときに一度目を通すといいのかと。もしくはこれから家事を本格的にやり始める人決意ができた人が読んでも参考になると思う。

ただ、実用的な本であって自己啓発成分が薄いから「普段全然家事しない人」が読んでも「よし！習慣的に家事しよう！」みたいなことにはならなそう。 (こんな簡単なことでいいならやろうかな、という思考に至る可能性はあるけど)

読了: エリック・エヴァンスのドメイン駆動設計

読書

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

DDDといえばこれ。読んでくじけちゃうやつ。 実際後半はくじけかけてた、というかきちんと理解できてないけどとりあえず読むだけ読んでみた感じ。

他にDDD関連本読んで基礎知識入れてからでないと前半で撃退されるのでは。

本当ならためになる部分とか自分の理解を書いたほうがいいんだろうけど、これはただの読了メモエントリなのでその辺は省略。IQ低めなざっくり感想と読書中のメモだけ張り付けておく。

目次

全4部の17章構成になっている

  • 第1部　ドメインモデルを機能させる
    • 第1章 知識をかみ砕く
    • 第2章 コミュニケーションと言語の使い方
    • 第3章 モデルと実装を結びつける
  • 第2部　モデル駆動設計の構成要素
    • 第4章 ドメインを隔離する
    • 第5章 ソフトウェアで表現されたモデル
    • 第6章 ドメインオブジェクトのライフサイクル
    • 第7章 言語を使用する：応用例
  • 第3部　より深い洞察へ向かうリファクタリング
  • 第4部　戦略的設計
    • 第14章 モデルの整合性を維持する
    • 第15章 蒸留
    • 第16章 大規模な構造
    • 第17章 戦略をまとめ上げる

まえがきでは2.3.4.9.14章は読むべきである。と案内している。 全部読もうとして挫折するくらいだったら、いったんおすすめされてる章だけ読むだけでもいいと思う。

ざっくり感想

  • 非常にためになる。ためになるがハイカロリー
    • DDDに関心があるならぜひ1度読んでおきたい
    • ただ内容がとても難しい・・・意識を強く持たないと読んでるけど頭に入ってこない状態になりがち
  • 読了後はできればだれかと議論したほうがいい
    • 内容が複雑、多岐にわたることもあって個々人によって解釈や理解度がバラけそう -　読み終わった人同士で本持ち寄って議論できたりするとグッと理解が深まりそう
      • 輪読会なら最大値の効果が得られそうだけど、いかんせん会の継続運営難易度が高い
      • 特定の章に絞るとかならあり？
  • DDD入門で読もうと思ってる人はやめておいたほうがいい
    • 先に数冊DDD関連本読んでから戦うことをお勧めする
  • ある程度読み進めた後に自分のコード振り返ってみたら割と効果が出てた気がする

以下読書中の簡単なメモ

第1章

  • ドメインモデリングはモデルを写実するのではなく映画製作のように現実の概念を表現している
    • 不要な部分は見せない
    • 現実をすべてその通りに再現するのではない

  • モデルの有用性

    • モデルと設計の確信が相互に形成しあう
    • モデルはチームメンバの全員が使用する共通の言語である(ユビキタス言語)
    • モデルは蒸留された知識である

  • 効果的なモデリングの実装

    1. モデルと実装を紐づける
    2. モデルに基づいて言語を洗練させる
    3. 知識豊富なモデルを開発する
    4. モデルを蒸留する
    5. ブレインストーミングと実験を行う

第2章 コミュニケーションと言語の使い方

  • ユビキタス言語
    • ドメインエキスパートとエンジニアによって作成されたモデル(共通言語)
    • 使いにくい、不適切なものがあるときは随時見直さなければならない
    • ユビキタス言語における変更はすなわちモデルに他する変更となる
    • 専門用語が交差するところで高められる
      • 専門的なビジネス用語 -> ドメインエキスパートの領域
      • システム的な専門用語やデザインパターン -> エンジニアの領域
      • 業務用語、構造の用語やパターン名 -> 両方の領域

第3章 モデルと実装を結びつける

モデルと機能の紐づけが複雑だと理解が難しく、設計が変更された時に紐づけを維持できなくなることがある

第Ⅱ部

第4章 ドメインを隔離する

  • レイヤ化アーキテクチャ

    • 原則は「下にある」レイヤにしか依存しないという事

  • ユーザーインターフェース層(もしくはプレゼンテーション層)

    • 人間や別システムのコマンドを解釈
  • アプリケーション層
    • ビジネスに意味があるか別システムのアプリケーション層と相互作用するもの
    • この層は薄く保つ。やるべき作業の調整のみ
  • ドメイン層
    • ビジネスの状況の反映を行う
    • その後のデータの永続化(DBへ保存)などはインフラ層
  • インフラストラクチャ層
    • 技術的機能の提供
      • アプリケーション層のメッセージ送信、ドメインの永続化等

第5層 ソフトウェアで表現されたモデル

  • エンティティと値オブジェクトの違い

    • エンティティは同一性を追跡できるもの

  • 値オブジェクト

    • 通販における「住所」
      • 同居人などが複数人が同一住所で注文したとしても、それが「同じ住所」であるかは関係ない
      • つまり同一性を追跡する必要はなく、値オブジェクトとなる
  • エンティティ
    • 電力提供事業者における「住所」
      • 「住居」に対して電気料金が発生する。住居を表す「住所」は同じ住所であれば同一とみなさなければいけない
      • つまり同一性を追跡する必要があり、エンティティとなる

第6層 ドメインオブジェクトのライフサイクル

  • ドメインの集約
    • 例: 自動車
      • 自動車/タイヤ/位置/といったエンティティになる
      • この時自動車エンティティがルートになり、外部からはタイヤを直接参照できない
    • こうして集約することで管理しやすくする
  • ファクトリパターン
    • 本来ドメイン層の責務だが、複雑化したオブジェクトや集約の生成を管理
    • デザパタなどで紹介されている
    • 不変条件をすべて満たすもののみ作成する。満たせない場合は作成不可。例外発生など
    • またファクトリは具象クラスではなく、型に応じて抽象化する
    • コンストラクタではだめなのか？
      • 単純である、かつコンストラクタ内でべつのコンストラクタを呼び出さなければよい
      • 複雑であればファクトリに任せたほうがよい
  • リポジトリパターン

第7層 言語を使用する

  • 集約をどのように分けるか
    • 参照用途などを考慮して経路を考える
    • 貨物 → 荷役イベントの場合は貨物に集約してもよさそうだが、輸送機器側からも参照される
      • その場合は独立すべき
    • リポジトリはそれぞれ集約のルートに対して作成される
  • 腐敗防止層
    • 別のアプリケーションなどと連携するとき、相手側のモデルをそのまま受け入れない
    • こちら側のモデルに変換する「腐敗防止層」を作成して噛ませるのが良い
  • エンタープライズセグメント
    • 理解できていない。あとから解説があるか？

第Ⅲ部

第9章 暗黙的な概念を明示的にする

  • オブジェクトの制約はそれ単品でモデル化した方がいい場合もある
  • 検索などでドメインにあるルールをクエリに適応しないと行けない場合はどうするべきか
    • リポジトリに汎用的なクエリビルダを設置して使用するのが良い

第10章 しなやかな設計

  • 意図の明確なインターフェイス
    • カプセル化しても別の人間が使うときに中身を見なければ理解できないのはだめ
  • 副作用のない関数
    • 既存オブジェクトには影響を与えず、新規オブジェクトを生成など
  • 表明
    • 事前条件や不変条件などを明確にコード化。テスト書いたり
  • 概念の輪郭
    • 読み直し
  • 独立したクラス
    • 依存関係が多くなればなるほど設計を理解する処理の負荷は大きくなる。クラス内の依存関係を可能な限り取り除き、プリミティブを使用することで単独で理解できるクラスになる
    • ただなんでもかんでもプリミティブにすればいいものではない
  • 閉じた操作
    • 戻り値と引数の型が同じであればそれはそのインスタンス集合の中で閉じていると言える

第11章 アナリシスパターンを適用する

  • アナリシスパターンはビジネスモデリングにおける共通の構造、概念のグループ。ドメイン一つの場合もあればまたぐこともある
  • 同一性によって定義されるオブジェクト=エンティティ
    • 例: 同日同金額同口座への振込=区別する必要があるエンティティ
    • 例: その取引の金額オブジェクト=区別する必要はない。エンティティではない
  • アナリシスパターンちゃんと調べる

第12章 デザインパターンをモデルに関係づける

  • ストラテジーパターンとは
    • デザインパターンをモデルに適応する場合はレイヤーを一つ増やす
    • 適応するパターンの考え方がドメインの概念に合うかを確認すること

第13章 より深い洞察へ向かうリファクタリング

  • ドメインに馴染む
  • 常に違う見方をする
  • ドメインエキスパートとの対話を途切れさせない

第Ⅳ部

第14章 モデルの整合性を維持する

  • モデルには統一性が必要
    • ただし巨大なシステムにおいてドメインモデルを完全に統一するこのとは現実的ではないし、コストに見合わない
    • これを無理にやろうとすると次のようなリスクがある
      1. 一度に多くのレガシーシステムを置き換えてしまうかもしれない
      2. 調整にかかるオーバーヘッドが限界を超えてしまうかもしれない。巨大なプロジェクトは身動きが取れない
      3. 特殊な要件の場合は要求を満たさないモデルを使うことになるかもしれない
      4. 単一モデルでどうにかしようとすると複雑になり使いづらい
  • モデルが適応されるコンテキストを明示的に定義すること
  • 境界はチーム編成、アプリケーションの特殊な用途、コードベースやスキーマ定義などの視点から行うこと
  • 偽同族語
    • 同じ言葉でも若干意味が違う
  • 腐敗防止層
    • レガシーなシステムの遺産を使わざるを得ない時に汚染されないためのレイヤー
    • ファサード、アダプタ、変換サービスで構成
    • ファサードが外部を直接操作。アダプタがメインシステムとの橋渡し。変換サービスが必要に応じて形式を変換

第15章 蒸留

  • リファクタリングする時どうするか
  • 全部ダメだからどこからやってもいい、はトッププログラマだけの集団でないと難しい、困ったところから、だと対処療法でしかない
  • 困った時にコアに関連するものであれば頑張って対応する。余裕があるときはコアの適切な抽出、サブドメインからの不純物除去がよい

第16章 大規模な構造

メモ消えてた

第17章 戦略をまとめ上げる

戦略的意思決定を行うために大事なこと

  • 意思決定はチーム全体に伝えなければならない
  • 意思決定プロセスはフィードバックを吸収しなければならない
  • 計画は進化を許容しなければならない
  • アーキテクチャチームが最も優秀な人材をすべて吸い上げてはならない
  • 戦略的設計にはミニマリズムと謙虚さが必要である
  • オブジェクトはスペシャリストだが開発者はジェネラリストである

じぶん Release Notes (ver 0.31.10)

じぶんリリースノート

@a-knowさんの「じぶん Release Notes (ver 0.36.7) - えいのうにっき」が月次の振り返りにとても良かったので、ちょっと使わせていただきました

なっぱ(ver 0.31.10)がリリースされました。更新内容は下記のとおりです。

技術関連

イベント

  • 自動車免許の第一段階を修了しました
  • 葬儀に参列しました
    • ホテルに上着をわすれ、まさかの義兄に借りるという実績を解除しました🏆

買物

ゲーム

プレイ中

読書

読了

読書中

アウトプット

ふりかえり

Keep

  • 初crateをリリースすることができた
    • crate公開の手順を知ることができた
  • AWSを学びなおし始めることができた
  • 免許の第一段階を早めに修了する事ができた
  • ロックマン11をサクっとクリアすることができた
  • 満員電車がつらくて停滞していた読書を再開することができた
  • LS Miniを購入してスマートハウス化を進めることができた

Problem

  • 普段全く使わないため冠婚葬祭の準備等ができていなかった
  • 礼服をホテルに忘れるという大ポカをやらかしてしまった
    • しかもバスに乗り遅れそうになり早朝全力ダッシュでバスを追いかけるという始末
  • 技術書展に行くことができなかった。ぐぬぬ
  • 進めたとはいえスマートハウス化はまだ課題が多い

Try

noteの「ランキング設計はどうあるべきか？」を読んだ

雑記

Todoisの読物タグに突っ込んだまま読むのを忘れていたnoteの「ランキング設計はどうあるべきか？」を見つけたのでちょっと読んでみたので後から見返すように概要をメモ書き。元記事は下記の3つ。

note.mu

note.mu

note.mu

PVランキングの本質

  • 本質的に収奪的な構造である
    • 収奪的 = 勝者がすべてを独占してしまう事
    • ランキングが上がる → 露出が増える → PVが増える → ランキングが上がる
  • 階層(クリエイターの地位)を固定する
    • ランキング常連になる → フォロワーが増える → PVが増える → ランキング常連を維持する
  • 収奪的なシステムがもたらすもの
    • 記事ごとの露出格差の拡大
    • 同様にフォロー格差の拡大と階層固定
  • 格差が拡大することによって新規ユーザーにとって極端に不利な状況発生する

公平で分散的なランキング構造

  • そもそもとして競争原理として格差は当然だが、その格差を極端化したり固定化するシステム設計はよくないという話
  • 実装する場合はこれらの2つを解決する必要がある
    • ランキングは注目を独占してはならない
    • ランキングのトッププレイヤーは新陳代謝しなければならない

正しいランキング設計のためにどうするか

  • 「ランキング」以外の名称を用いる
  • 時間による重力的な減衰モデルを用いる
    • 投稿されてからの経過時間に係数をかけ合わせてマイナスのスコアにする
  • 読了率を加味する
    • こうすることでタイトルのインパクトだけで注目を集めたものは評価が低くなる
    • この手法は階層固定性そのものは解決しないことに注意
  • 順位のシャッフル
    • 単純に上位XX位などでシャッフル表示
    • 上位XX位間の格差は是正できるが、「ランカーであること」そのものの是正はできない
  • 上位XXXX位からランダムにXX件を抽出する
    • ランキング範囲を拡大しその中からランダムに抽出する(500位内から100件など)
    • ランキングの収奪性、階層の固定化どちらも軽減できるが、軽減しすぎてしまう場合もある
      • 格差を完全にフラットにすると良いコンテンツである意味がない
  • ランダム抽出時に、スコアに応じた重さを与える
    • スコアが高いほどランダム時の出現率を高くする
    • パラメーターの変更で柔軟にコントロールできるのが強み
  • 小選挙区制を導入する
    • カテゴリ単位などでランキング作成して合算
  • 比例代表制を導入する
    • 小選挙区ごとのユーザー人口を加味してランキングの選出をする
    • メジャージャンルであるほど多く、マイナーであれば少なく
  • 2つ以上のスコアをブレンドする
  • ランキングに複数のユーザークラスタをブレンドする
    • 新規ユーザーとベテランユーザーなどを混ぜ合わせてランキングを作成
    • 階層の固定化是正にきく
  • 人のキュレーションをブレンドする
    • 手動調整。バランス調節ができるが依怙贔屓もできるため慎重に
  • PVなどスコアに、コンテクストに応じた重み付けを行う
    • TwitterなどのSNSからの流入は加点を1/10とすればバズった影響を極小化できる
  • ペイジランクを導入する
    • Googleのラリー・ペイジ提言の「良い記事を描いてる人がライクしている記事は、良い記事」といったルール
    • 精度が高くて使い勝手もいいが、ルールをハッキングされやすいのが難点
  • 友達の読了率、スキ率からランキングを生成する
    • 自分をフォローしている人、友達の評価からランキングを生成する
    • 精度が上がりそうだが同じような価値観で固まってしまう
  • 読者のリアクション率を加味する
    • 「リアクション数/読了率」といった式を使うとスコアを高めることができる
    • ただ良質で少数のユーザーを抱えていると有利だったりするので他のアルゴリズムと合算が必要

だだーっと記事の中身を羅列しただけだが、今後もしランキングの作成を行うことがあった場合は改めて参考にしようと思う。 この記事自体はnoteのようなコンテンツ投稿サービスでの話なので、他種サービスになると他の手段の検討の必要は出てくるとは思うけども。

おっさんたちがかつて熱中したラグナロクオンラインはまだあったのだ

ゲーム 雑記

ラグナロクオンライン(以下RO)。

インターネット黎明期にネトゲにいそしんでいた人なら1度は手を出したことがあるんじゃないかと疑うくらいクッソ有名なMMO。 このBGM聞いて「あぁーーー！！！！懐かしいーーー！！！」ってなった人とは絶対いい酒が飲めると思う。

www.youtube.com

そんなROを久方ぶりにやってみた。 本当は細かく色々昔の思い出書いたり今回やってみた感想を細かく書いていきたいけど、きりがなくなるのでただの殴り書きだけしておこうと思う。

なんで今更RO？

「キャラのレベルを一気に130まで上げてくれるブースターチケットを配布してるらしい」ってのに釣られました。はい。

どうやらワールド倉庫なるものが実装されて(むしろ今までなかったの・・・？)、そのキャンペーンで配っているとかなんとか。 それに新規アカウントなら14日無料だしね。気まぐれ気まぐれ。

ちなみにブースターチケットについてはここ参照。 ragnarokonline.gungho.jp

今のROの感じ

  • ノービスはレベル上げしなくていい(チュートリアル進めると1次職になれる)
  • お使いクエストとか討伐クエストがたんまりあって狩場とか考えずにレベル上げ出来る
  • それらのクエストこなせば装備もちゃんと適したのもらえる
  • なんかインスタンスダンジョンがめっちゃある。さすが長いだけあってコンテンツ多い
  • でもやっぱりROの雰囲気はそのままな気がする。

昔は「ボス = MVPボス = ソロ討伐なんて夢のまた夢」みたいな感じだったけど、低ランクのインスタンスダンジョン行けばボスっぽいのとか普通にいて楽しい。思い出補正の分余計に。

あとはめっちゃ過疎ってるのかと思ってたけど、どうも一番にぎわっているBreidablik(ブリザブレイク？)だと2000人くらいいてめっちゃビビった。プロンテラが昔やってた時みたいな露天状況になってるとは思わなんだ。

ブースターチケット感想

これってやっぱり「すでにプレイしている人」が行きたくても資産移動できなくて行けなかった別ワールドに移行するためのもの、ってのは感じた。

正直復帰勢がLV130の3次職になっても装備とかスキルの使い方も全く分からなくてどうしようもなくなる。金がないから店売り装備すら下手に買えないし。

「金策ならローグ系やろ！」ってことでシャドウチェイサーにしてみたけど、

  • 装備が全くない
  • ほかの町に転送する金もない
  • それどころか倉庫を開く金すらない

という金欠状況になった結果、裸でプロンテラ周辺のポリンを叩いてはした金を稼ぐというやってることはかつてのRO初期と変わらないというノスタルジック感をひしひしと感じる復帰プレイになった。

ブースターチケット効果で人が多いのか、サバキャンされまくってログインゲーになったり、プロンテラの町中が重すぎて移動できないとか、なんか大昔にタイムリープしたかのような感覚はめっちゃ楽しかった。

なお、シャドウチェイサーはポリンがドロップしたナイフが初武器となりました。しょぼい。 さすがにそのままだとどこにも行けないから、最終的には金策の準備をするために別途商人を作って斧背負ってサベージ狩りしてました。たのちい。

そんで？

おっさんの思い出補正がでBGMが最高 of 最高だし、雰囲気とかグラフィックもやっぱり好き。

ネット黎明期からなんだかんだで生き延びたROはいろいろ変わってはいたけど、おっさんの心に残ってる思い出補正をくすぐるには十分なほどROはROしてるんだなって感じた。

とりあえずしばらく(少なくとも無料期間は)遊んでみようと思う。 昔は倒せなかった敵を倒したり、インスタンスダンジョンに行ってみたり、昔欲しかったけど取れなかったカードをだらだらフィールド狩りして狙ってみたりとか。

なんか成果があったらあとでまとめておこうと思う。