Three-Phase Player Profile Engine

• Three-phase player profile engine is a structured architecture that segments player modeling into data acquisition, profile inference, and adaptive response for actionable insights.
• It leverages multi-modal inputs and diverse methods such as BiLSTM, CNNs with triplet loss, and stateless microservices to transform raw player data into actionable profiles.
• The engine is versatile across domains, supporting adaptive gameplay, season-level identification, and scalable telemetry analytics in game-based learning and sports analytics.

A three-phase player profile engine is a staged computational architecture that separates player modeling into data acquisition, profile inference, and downstream use. Across recent work, the same three-phase pattern appears in distinct forms: a multi-modal classification pipeline for 36 player profiles in an AI-controlled text-based RPG (Starace et al., 6 Sep 2025), a triplet-network system for deriving season-level soccer player representations from tracking data (Kim et al., 2021), and an Open Player Model architecture for game-based learning that couples telemetry, analytics, and feedback services (Lin et al., 27 Mar 2026). The shared abstraction is structural rather than algorithmically uniform: phase boundaries are stable, but the representation, objective, and deployment target vary with domain.

1. Architectural pattern and scope

The available systems partition player profiling into three operational stages. In adaptive game profiling, the stages are Phase 1: Data Acquisition, Phase 2: Profiling, and Phase 3: Adaptive Response. In soccer tracking, they are Phase 1: Data Preparation and Heatmap Generation, Phase 2: Triplet Network Architecture and Feature Extraction, and Phase 3: Profile Generation, Similarity Scoring, and Evaluation. In open player modeling for game-based learning, they are Phase 1: Frontend, Phase 2: Stateless Backend, and Phase 3: Two-Tier Log Storage (Starace et al., 6 Sep 2025, Kim et al., 2021, Lin et al., 27 Mar 2026).

Work	Three-phase decomposition	Primary output
(Starace et al., 6 Sep 2025)	Data Acquisition → Profiling → Adaptive Response	Posterior over 36 profiles
(Kim et al., 2021)	Heatmap Generation → Triplet Feature Extraction → Profile Aggregation	Final season profile
(Lin et al., 27 Mar 2026)	Frontend → Stateless Backend → Two-Tier Log Storage	Prompts, recommendations, visualization guides

This recurring decomposition indicates that a three-phase engine is best understood as an organizational pattern for end-to-end player modeling rather than a single model family. A plausible implication is that the term remains domain-relative: in one setting, phase 3 is adaptation; in another, it is similarity retrieval; in another, it is storage and feedback-loop support.

2. Phase 1: data acquisition, segmentation, and preprocessing

In the multi-modal RPG pipeline, phase 1 combines behavioral telemetry and semantic descriptions. The corpus contains 19,413 complete gameplay sessions from an AI-controlled text-based RPG, exported as sequences of decision events with fields such as {timestamp, action_id, available_choices, chosen_choice, location_id, etc.}. Ambient text at each decision point—room descriptions, NPC dialogue, and item tooltips—was originally embedded with a pre-trained BERT encoder per text chunk (≈512–768 D) and later compressed. Behavioral features were defined as 48 dimensions per timestep, comprising transition patterns between action types (15 features), available vs. selected choice vectors (12 features), early vs. late game time bins (15 features), and dungeon movement (“north→east”) patterns (6 features). Semantic features were compressed to ~128 D per timestep, and the combined representation was the concatenation of the normalized behavioral vector and compressed text embedding, yielding 176 D per timestep. Preprocessing further included Z-score normalization on the 48 behavioral dimensions, unit-norm scaling for text embeddings, under-sampling to ~4,100 sequences per class to reduce class imbalance from 1.78∶1 to 1.15∶1, and zero-padding or truncation to a fixed length $T$, exemplified as 100 decision points, with masking for shorter sessions (Starace et al., 6 Sep 2025).

In 6MapNet, phase 1 begins from raw tracking: for each match, at fixed time steps $t = 1 \ldots T$, each tracked player has a 2D position $x_t=(x_t, y_t)$ and an instantaneous velocity vector $v_t$. Matches are split into phases of roughly 10 minutes; any phase shorter than 10 minutes is merged with its neighbor so that every phase is at least 10 minutes, and phases with fewer than 8 tracked players are discarded. This produces 1,989 merged phases, with 17,953 player–phase entities from 436 distinct players. Two heatmaps are then constructed: a locational heatmap $H_{\text{loc}}$ of size 35×50×1, and a directional heatmap $H_{\text{dir}}$ of size 35×50×8. The pitch is discretized into 35 rows × 50 columns, while 360° is divided into 8 equal angular bins. Both heatmaps collapse the entire 10-minute trajectory into a fixed representation by summing over time; explicitly, no RNN is used and temporal dynamics are pooled by count or occupancy across the grid (Kim et al., 2021).

In OPSAI, phase 1 is implemented in the Frontend. It captures core interaction events such as {"movePiece", "placeSemaphore", "undo", "hintRequested"}, system events such as {"levelStart", "levelComplete", "levelFail"}, and context exports as full or diff snapshots of game state. The JSON schema includes sessionId, userId, timestamp, eventType, and a payload. Every user action is emitted immediately, while snapshot exports occur once per second (configurable). Client-side preprocessing drops noisy UX events such as cursorHover, scroll, and UI-tooltip, and aggregates rapid event bursts into burst records. Backend preprocessing is carried out by AWS Lambda, with metadata written to DynamoDB and every 30th event written as raw JSON to S3. An example aggregate is the cumulative count of moves per minute:

$$A_t = \sum_{i=t-\Delta t}^{t} \mathbb{1}\{\text{event}_i=\text{“movePiece”}\}.$$

The reported enrichment step adds geo-tags, device type, and cognitive load estimate (Lin et al., 27 Mar 2026).

Phase 1 therefore determines what kind of player profile is even representable. In the RPG setting, semantic context is introduced before classification; in soccer, spatial occupancy and directionality are elevated to first-class signals; in OPSAI, telemetry capture is designed for low-latency analytics and transparent feedback.

3. Phase 2: profile inference and representation construction

The RPG profiling pipeline uses a single, multi-modal bidirectional LSTM that accepts the 176 D fused vector per timestep. The reported architecture is: Input sequence (batch × $T$ × 176) → BiLSTM (2 layers, hidden_size=128 per direction) → mean-pool over $T$ to 256 D and max-pool over $T$ to 256 D → concatenate to 512 D → fully connected layer (ReLU, 256 units) + Dropout(0.5) → softmax output (36 classes). The model uses 2 stacked BiLSTM layers, hidden size 128 units per direction, bidirectionality enabled, and dropout between LSTM layers of 0.3. Fusion is explicitly early fusion, with behavioral and semantic vectors concatenated at each timestep. The optimization objective is categorical cross-entropy over 36 classes:

$t = 1 \ldots T$0

Training uses Adam, initial learning rate $t = 1 \ldots T$1, batch size 64, 50 epochs with early stopping on validation loss, ReduceLROnPlateau(factor=0.5, patience=3), weight decay $t = 1 \ldots T$2, and gradient clipping at norm 5.0 (Starace et al., 6 Sep 2025).

In 6MapNet, phase 2 is a triplet network operating on paired heatmaps. The architecture consists of twin-branch CNNs—one locational and one directional—with identical layer topology except for input depth. Each branch applies convolution, max-pooling, flattening to 1,920 dims, a 128-unit ReLU FC layer, Dropout with $t = 1 \ldots T$3, and a final 10-D output. The two branch outputs are concatenated into a 20-D embedding $t = 1 \ldots T$4. Batch-norm after every layer is reported, with dropout inserted at select layers. Training is driven by the triplet loss

$t = 1 \ldots T$5

with $t = 1 \ldots T$6 and margin $t = 1 \ldots T$7. Hard-negative mining is performed every 10 epochs or fewer by sampling 5 random heatmap pairs per identity, pairing each anchor with positives from the same identity, and selecting the most difficult negative that violates the margin constraint; if none violate, one of the 10 closest negatives is chosen. This yields ~244,310 triplets for training and ~14,940 for validation per selection round. Optimization uses Adam, initial lr=0.05 (decay over time), batch size 1,000, and up to 10 epochs per triplet set (Kim et al., 2021).

In OPSAI, phase 2 is a Stateless Backend rather than a single neural model. An Ingest API (REST endpoint) receives metadata records, triggers analytics micro-services via Kafka, and applies services including feature extraction such as pace and accuracy, clustering / segmentation such as k-means over time-series traces, Bayesian Knowledge Tracing (BKT) for skill mastery, RL-style reward shaping signals for hint recommendations, and social comparison (peer percentile). The reported BKT update is

$t = 1 \ldots T$8

while recommendation ranking uses Thompson Sampling:

$t = 1 \ldots T$9

The backend is explicitly stateless: no session state is kept on server, all state is passed in the request payload or pulled from S3/DynamoDB, intermediate summaries are returned to the client, and backend pods are replaceable (Lin et al., 27 Mar 2026).

These systems instantiate three distinct interpretations of phase 2: supervised multi-class classification, metric-learning-based representation extraction, and modular analytics services. The commonality is that each transforms raw player traces into a compact intermediate object: a posterior distribution, an embedding, or actionable analytic summaries.

4. Phase 3: profile materialization, storage, and adaptation

In the RPG engine, phase 3 is Adaptive Response. The phase-2 model ingests sliding windows of the last $x_t=(x_t, y_t)$0 actions, performs incremental BiLSTM inference every $x_t=(x_t, y_t)$1 actions (or on-demand), and emits a posterior over 36 profiles that is smoothed via exponential moving average. The system supports online updates as new data are appended to the window, with re-normalization if necessary. Downstream uses include adjusting NPC dialogue style with more probing for ambiguous profiles, tweaking difficulty or reward types aligned to detected motivations, and triggering reflection prompts when neutral classification remains high, for example, “What is your goal here?” Real-time deployment recommendations include a rolling buffer + masked LSTM to avoid re-processing the entire history, a lightweight copy of the BiLSTM model on the game server or client, and online updates of normalization statistics for new feature distributions (Starace et al., 6 Sep 2025).

In 6MapNet, phase 3 produces a stable player representation by aggregating phase-level embeddings. For a player or player–role entity with embeddings $x_t=(x_t, y_t)$2 over $x_t=(x_t, y_t)$3 matches or phases, the season profile is the element-wise average

$x_t=(x_t, y_t)$4

followed by $x_t=(x_t, y_t)$5 normalization to unit length. Similarity between two season profiles $x_t=(x_t, y_t)$6 is then defined by

$x_t=(x_t, y_t)$7

or squared-Euclidean distance. Because both profiles are unit vectors, the paper notes that this is equivalent to a monotonically decreasing function of cosine similarity. Phase 3 is thus not adaptive control but profile materialization and similarity scoring (Kim et al., 2021).

In OPSAI, phase 3 is the Two-Tier Log Storage, coupled to a feedback loop. The heavy raw data store is Amazon S3 with JSON objects, keyed as <userId>/<sessionId>/<timestamp>.json.gz, storing full event + board state every 30 events. The lightweight reference index is an AWS DynamoDB table with primary partition=sessionId and sort=timestamp, plus a GSI on (userId, eventType) for rapid filtering. The reported index entry size is ≈ 1 KB, compared with raw data of ≈ 50 KB. Frontend–backend communication uses HTTPS/REST for telemetry and WebSockets for real-time suggestions. The timing diagram closes the loop from client event to indexing, raw storage, analytics production, and WebSocket prompt delivery (Lin et al., 27 Mar 2026).

Phase 3 therefore ranges from immediate gameplay adaptation, to long-horizon similarity computation, to storage-backed transparency and low-latency intervention. This suggests that the third phase is defined less by a single algorithm than by how inferred player state is operationalized.

5. Empirical results and benchmarking

Reported performance must be read in relation to task definition. One system addresses 36-class profile classification, another performs Top-1 player identification, and another reports systems latency and throughput rather than classification accuracy. The numbers are therefore complementary rather than directly comparable (Starace et al., 6 Sep 2025, Kim et al., 2021, Lin et al., 27 Mar 2026).

System	Task or metric	Reported result
(Starace et al., 6 Sep 2025)	Random baseline, 36 classes	2.8% accuracy
(Starace et al., 6 Sep 2025)	Behavioral-only, XGBoost on aggregated features	10.4%
(Starace et al., 6 Sep 2025)	Multi-modal LSTM (176 D + multi-pooling)	22.8%
(Starace et al., 6 Sep 2025)	Non-Neutral profiles, 16 classes	42.1% accuracy
(Starace et al., 6 Sep 2025)	Neutral profiles, 20 classes	24.8% accuracy
(Starace et al., 6 Sep 2025)	Motivation sub-task	74.8% accuracy
(Starace et al., 6 Sep 2025)	Alignment sub-task	30.3%
(Kim et al., 2021)	Top-1 ID with a single held-out phase	~55% correct
(Kim et al., 2021)	Top-1 ID with two phases	~78% correct
(Kim et al., 2021)	Top-1 ID with four phases	~93% correct
(Kim et al., 2021)	Top-1 ID with all ten phases	~98% correct
(Kim et al., 2021)	Validation triplet “accuracy”	94.5%
(Lin et al., 27 Mar 2026)	Telemetry ingest	up to 10 K events/sec per API node
(Lin et al., 27 Mar 2026)	DynamoDB index writes	≈ 5 ms latency, 99% within 15 ms
(Lin et al., 27 Mar 2026)	S3 writes	≈ 50 ms end-to-end
(Lin et al., 27 Mar 2026)	Analytics compute per mini-batch of 100 events	100–300 ms
(Lin et al., 27 Mar 2026)	WebSocket push	<20 ms

Within the RPG profiling study, the principal empirical finding is that behavioral data alone plateaus at ~10% for 36 categories, while multi-modal integration raises that to ~22%; the abstract also summarizes this result as 21% and states that multi-modal integration enables 25%, reflecting two closely related reportings in the same source (Starace et al., 6 Sep 2025). The same study reports that prediction beyond 20 categories remains unexplored, making the 36-category scale itself a benchmark contribution. In 6MapNet, the notable result is that player identification improves sharply as more phases are aggregated, reaching ~98% when all ten held-out phases are used. OPSAI’s contribution is infrastructural: it demonstrates a telemetry and analytics loop with sub-second component latencies and horizontal scalability through stateless backend pods (Kim et al., 2021, Lin et al., 27 Mar 2026).

6. Failure modes, misconceptions, and reported extensions

A recurring misconception is that behavior alone is sufficient for fine-grained player profiling. The RPG study directly contests this claim. It identifies semantic conflation as a core failure mode: identical actions such as “help merchant” may correspond to Lawful Good altruism, strategic patience, or deceptive Evil, while neutral classes dominate confusion because the model over-predicts neutral alignments when it cannot detect a clear moral signal. The reported conclusion is explicit: without player explanations or dialogue, the classifier cannot resolve intent vs. outcome, and conversational interactions or explicit “why” questions appear essential to close the semantic gap (Starace et al., 6 Sep 2025).

A second misconception is that a three-phase engine implies a canonical model family. The documented systems show otherwise. One uses a BiLSTM with early fusion and multi-pooling, another uses twin-branch CNNs trained by triplet loss, and a third uses stateless micro-services combining clustering, BKT, RL-style ranking, and social comparison. A plausible implication is that the three-phase formulation is architecture-agnostic so long as it preserves the sequence from data capture to profile derivation to downstream action (Kim et al., 2021, Lin et al., 27 Mar 2026).

The reported extension paths are correspondingly heterogeneous. For the RPG engine, the recommendations are to combine telemetry with intermittent conversational cues, to retain the multi-modal LSTM as the backbone while layering on a small transformer-based “intent summarizer” for short player utterances, to actively solicit brief natural-language justifications when confidence in neutral or ambiguous profiles remains low, and to log all adaptive responses and player feedback for continuous retraining (Starace et al., 6 Sep 2025). For OPSAI, extensions include per-user baselines in clustering & BKT priors, dynamic adjustment of $x_t=(x_t, y_t)$8 and $x_t=(x_t, y_t)$9 per learner, integration of Eye-tracking or Biometric Data, addition of an LLM-based reflective dialogue agent via GPT-3+, and multi-agent modeling for cross-peer influences in collaborative gameplay (Lin et al., 27 Mar 2026). In 6MapNet, the design choice that no RNN is used and that temporal structure is pooled into heatmaps suggests an emphasis on stable movement style rather than event-by-event decision semantics; this suggests strong suitability for profile similarity and identification, with less direct access to explicit intent (Kim et al., 2021).

Taken together, these systems establish the three-phase player profile engine as a flexible systems pattern for player modeling. Its main unresolved issue is not phase decomposition itself, but observability of intent: where the available signal is purely behavioral, fine-grained motivational inference remains constrained; where data capture, representation, and feedback are co-designed, profiling becomes more operationally actionable.