こんにちは。
吉田P/Dよりコメントのあった、マクロの個数拡張に関する進捗状況をお伝えします。

現在開発では、主にパッチ3.1の新規項目の実装を進めています。

マクロ改修タスクは 3.1の開発期間に
「改修の方法を調査検討し、改修に必要な見積りを完了させる」までを予定しています。

多くの機能改善系のタスクは、優先度を数値化して一覧リストで案件管理していますが、
原則として各パッチの新規コンテンツ追加に必要なUIの実装目処が立たない限り、
機能改善系タスクには着手できません。
※UIができていないコンテンツがひとつでもあればパッチのリリースが遅延してしまうためです。

そのため、いつマクロ改修がリリースできるか定めるにはパッチ3.1の期間で、
　1) 実装方法を確定させる
　2) その方法に必要な作業時間を見積もる
まで進め、その見積もり数値と パッチ3.2以降の新規実装項目の見積もりを確認し、
担当者の実装時間を確保できるか判断できてから、リリース想定パッチが確定します。

多分この方法でできるはず、という目算はありますが、担当者がしっかり調査するまでは
適当なコメントを出せないので、お時間をいただく事をご容赦ください。

　＊　＊　＊　

補足情報
現状のマクロ仕様は様々な複数の制約を考慮して決まった設計なので、
これを変更するとアッチが立つとコッチが立たない的なトレードオフが生じる
「高難易度ではないが、割りと厄介な類」の改修が必要です。

先般吉田P/Dより、
ローカルストレージの使い方を従来のキャラクター個別に100マクロの方式から、
アカウント共通のマクロに統合・集約しキャラクターが使えるマクロの数を増やし、
ストレージの利用量の総計を減らす、という大まかな変更方針の説明をさせていただきましたが、
これを成立させるためにはクリアしなければならない課題があります。

その中でも、以下の２つが対応コストが高そうな課題です。


１．リリース済みのフォーマットを変更する一般的な方法が取れない問題

　　ビジネスアプリ等では、保存データに冗長性をもたせて安全にフォーマット移行させますが、
　　本件では「ローカルストレージの容量制約を回避するためにフォーマット変更」が必要なので、
　　安全のための冗長性をデータに追加する ＝ 容量が増える → 本末転倒、NG！となります。

　　従って、具体的な方法として「リスクの高いデータ変換手順」を選択しなければならない
　　可能性が高く、その場合は変換プロセスに多くの障害対策を加える必要があります。

　　例えば、変換処理中にハードが予期しない理由(*)で停止してしまうレベルの対処まで
　　想定しなければ、既存データを破壊／修復不能な状況が発生してしまいます。
　　*) 変換処理中にかあちゃんがコンセント引っこ抜いた、といった物理的障害も想定する


２．メモリガ

　　マクロはその役割上、可能な限り迅速／確実に実行したいものです。

　　そのため、現状でも100個のマクロはキャラクターログイン時に、クライアントのメモリに
　　全て読み込み、いつでも即時実行できるようにしています。
　　※それでもサーバ側で実行可否を制御しているアクションは実行できないケースがある
　　
　　ローカルストレージの容量制約もありますが、それ以上にマクロをメモリに置く領域を
　　どのくらい確保できるかが、マクロの個数に影響します。
　　
　　呼び出しに応じてロードし、キャッシュメモリに溜める方法も考えましたが、
　　同じくキャッシュ方式をとっているアイコンの表示速度の挙動を見る限り、
　　マクロを同方式に変更すると体感できるレベルの操作性の悪化が懸念されるため、
　　マクロ実行の確実性と量を天秤にかけた最後の手段と考えています。

　　メモリに空き領域を確保するためには、今回のマクロとは直接関わりのない、
　　他の機能を最適化してメモリに空きを作る必要があり、この作業時間や最適化部分の
　　チェックも本件の実装コストに乗ってきます。

　　※特にアナウンスしていませんが、これまでのアップデートでも継続して
　　　様々な内部処理の最適化を行い、メモリの空き確保をしています。