プラグイン全体の中心線です。Bukkit イベントや各種ミニゲーム・ボス・イベントから発生したスコアがどこを通って保存され、月次ランキングや報酬へ繋がるかをまとめています。
rankingscoremysqlmonthlyreward
このページは手書き密度を上げたサブシステム解説です。 クラス単体の一覧では見えにくい、モジュール横断の処理遷移を図と文章で読めるようにしています。
読むときの姿勢
- まず図で境界を把握する
- 次に関連クラスの章立て解説へ降りる
- 最後にメソッド詳細で個別実装を確認する
サブシステム解説
どこから読めば良いか
起動順を知りたいときは RankingPlugin の onEnable、通常の加点経路は ScoreManager の公開メソッド群、保存・月次集計の実装詳細は MySQLScoreService のテーブル初期化・月替わり処理を見るのが自然です。Web に出る値がずれている場合も、ほとんどはこの経路へ戻って確認すると原因が見つかります。
この層が横断するもの
このサブシステムは root パッケージだけで閉じません。Season、EventPoint、Sidebar、Web、Reward、Login 系が後段でぶら下がり、スコアを読んで別の体験へ変換します。そのため「保存だけ直したつもり」が表示や報酬の破壊に繋がりやすい領域です。
モジュール横断の処理遷移図
加点から永続化まで
Bukkit event / game result
→
各機能の manager
→
ScoreManager
→
ScoreService 実装
→
MySQLScoreService
→
monthly / total 更新
後段参照
→
Sidebar
→
WebDataServer
→
RewardService
→
SeasonService
スコア付与は一箇所に寄せられているため、個別機能で直接 DB を叩くより ScoreManager 経由に揃える設計になっています。横断影響を確認するときは後段参照を必ず見る必要があります。
月替わりと報酬反映
起動 / 定期確認
→
last rollover 読み込み
→
月境界判定
→
top / monthly 集計更新
→
報酬サービス
→
表示側更新
関連クラス
→
MySQLScoreService
→
MonthlyRankingRewardService
→
RewardService
→
WebDataServer
月替わりは単なる月番号更新ではなく、ランキング確定・報酬・キャッシュ再構成まで連鎖します。月初だけ壊れる不具合はこの一連で追うべきです。
変更時の注意点
- スコア保存の入口を増やすと二重加点や月次反映漏れが起きやすいので、まず ScoreManager に寄せられるかを確認すると安全です。
- 月替わり処理は Web 表示キャッシュとも密接です。DB 更新だけ直しても dashboard に古い値が残るケースがあります。
- Reward / Season / EventPoint は「後から読む」側なので、保存フォーマットやキー命名を変えると追従先が壊れやすいです。