TOUCHLINE / PERFORMANCE

5つの操作を1/5以下へ

ゲームの計算・記録を維持し、保存と繰り返し計算を短縮した。

2026年9月29日 / 実装・比較検証

結果

変更前と変更後を交互に3回ずつ測定。新規キャリアと1月まで進めたキャリアの両方で、全5操作の中央値が変更前の20%以下になった。同じ初期状態・乱数条件で、保存したゲーム内容、結果・スタッツ・疲労・MOTMが一致した。

新規キャリア — 9月15日

操作変更前変更後変更前に対する割合
トレーニング開始2.44秒0.28秒11.3%
翌日へ3.32秒0.65秒19.6%
メンバー確定3.39秒0.25秒7.3%
キックオフへ2.58秒0.19秒7.5%
試合終了・MOTM2.10秒0.14秒6.8%

進行済みキャリア — 1月25日・自チーム27試合

操作変更前変更後変更前に対する割合
トレーニング開始11.17秒0.39秒3.5%
翌日へ11.52秒0.65秒5.6%
メンバー確定13.30秒0.63秒4.7%
キックオフへ13.25秒0.55秒4.1%
試合終了・MOTM21.72秒0.75秒3.5%

本PCのEdge、390×844px、独立したブラウザーで測定。実際のボタンの処理から、保存・画面更新を終えて2フレーム描画するまでを含める。試合終了は終了済みエンジンの集計・MOTM・保存・描画を測定。試合全体の再生時間ではない。外部画像の通信待ちは除外。端末負荷で時間は変動し、iPhone実機での数値は未測定。

原因と変更

最大の待ち時間は、操作のたびにキャリア全体をLZ圧縮して保存する処理だった。さらに、国内杯の日程に同じクラブの全選手データを何度も重複保存し、他クラブの試合で同じ選手適性・個別指示・所属名簿を繰り返し評価していた。

変更前
  1. ゲームを計算同じ評価を繰り返す
  2. 保存全体を再圧縮日程にクラブ情報を重複
  3. 途中画面も描画最終画面へ差し替え
変更後
  1. ゲームを計算同じ入力の評価を再利用
  2. 変更した部分を圧縮クラブ情報は一度だけ保存
  3. 最終画面を描画処理中表示・エラー復帰は維持

使用したOSS:fflate 0.8.2(MIT)。公式npm配布の整合性を検証し、ローカルに同梱した。

保存とゲーム内容の確認

旧JSON・LZ形式を読み込める。保存失敗、二重操作、他タブの古い保存による上書き拒否、再保存、ロールバックを維持した。ユーザーのキャリアは初期化していない。

全シーズンの検証では、当初の新方式が保存上限を超えたため、大きなセーブの圧縮率を上げた。再検証時は約243万文字の主保存と同一の復旧用保存を維持できた。

比較データ:新規キャリア / 進行済みキャリア。計測は現行コードと固定した変更前コードを比較した。