Presenting and Evaluating Smart²: A Bidirectional Real-Time Input Framework for Smartphone–Smartwatch Videogames

Abstract

Smartwatches offer new opportunities for extending mobile gameplay through wearable input, but their integration into real-time game interactions requires communication frameworks capable of maintaining low and stable latency. This study evaluates ${\mathrm{Smart}}^2$, a smartwatch–smartphone communication module designed to integrate Wear OS input into Unity-based mobile games. The framework was evaluated through five minigames implementing Tap, D-Pad, Hold, Joystick, and motion-based input. A quantitative latency evaluation was conducted across five Android smartphones using a Samsung Galaxy Watch 7 as the smartwatch input device. Latency was estimated through a round-trip time approach and reported as estimated one-way latency. Results showed stable connectivity and no observed message loss, as verified through sequential event identifiers and their corresponding acknowledgments. A two-factor main-effects ANOVA showed statistically significant differences in mean estimated one-way latency between the five experimental tests and between minigames, indicating variability in the evaluated test conditions and interaction modalities. These findings suggest that ${\mathrm{Smart}}^2$ can support real-time smartwatch-based interaction in Unity gameplay while highlighting the importance of evaluating latency in relation to both test conditions and interaction design.

1. Introduction

Advances in pervasive and ubiquitous computing have progressively narrowed the gap between digital systems and daily activities [1]. Smartphones, in particular, have become central interaction spaces for communication, work, and entertainment across multiple contexts [2]. Within this landscape, pervasive games have emerged as interactive experiences that intentionally connect digital mechanics with players’ physical actions, mobility, and real-world environments [3]. These games commonly rely on mobile sensing, connectivity, location-awareness, or context-aware interaction to extend gameplay beyond the screen and into daily routines [4].

Pervasive games have been extensively explored through both commercial and research-driven applications, particularly in domains where digital experiences are expected to influence behavior, movement, or situated decision-making [5]. A prominent example is Pokémon Go, which combines augmented reality and geolocation to encourage players to physically explore their surroundings, demonstrating the potential of pervasive games to reach large populations and promote behavioral changes such as increased physical activity [6,7]. Similarly, Pikmin Bloom illustrates how everyday activities such as walking can be gamified through location-based mechanics, while also revealing key design tensions between improving daily experiences and avoiding disruption of routine life [8].

More broadly, location-based games take advantage of GPS and mobile connectivity to transform public spaces into interactive environments, raising both opportunities and challenges regarding player engagement with physical and social contexts [9,10]. However, pervasive gameplay is not limited to geolocation. Context-aware approaches have also been explored through alternative interaction modalities, including speech-based systems that adapt recognition based on in-game context [11], full-body interaction paradigms that interpret natural player movements [12], and gesture recognition techniques that rely on sensor data to enable embodied gameplay experiences [13,14,15].

Wearable devices take advantage of context awareness based on mobile sensing data to enable more adaptive and embodied forms of interaction. In many mobile configurations, these devices do not replace the smartphone; rather, they complement it by capturing body-centered or contextual data, while the smartphone remains the main platform for visualization, feedback, application execution, and interpretation of such data [16]. Studies in this area have explored how different types of wearable devices can be integrated into game experiences; however, this integration remains largely exploratory and fragmented. For instance, prior work has proposed design implications for next-generation gaming wearables, highlighting opportunities and challenges associated with incorporating body-centered interactions such as motion, touch, and physiological sensing into games [17]. Similarly, other studies have examined the relationship between a wide range of wearable devices and gameful experiences, analyzing how features such as sensing capabilities and feedback modalities influence player engagement across multiple devices rather than focusing on a single integrated system [18].

While these works provide valuable insights, they primarily address wearable gaming from a broad and conceptual perspective, with limited concretization into fully integrated systems for specific devices. This reflects a broader trend: although wearable technologies are widely studied in the context of mobile sensing and embodied interaction, their application in gameplay-oriented scenarios remains relatively limited and dispersed across device types.

This work focuses specifically on smartwatches, as they represent a ubiquitous, non-invasive, and widely adopted category of wearable devices across multiple manufacturers, while also providing touch input, motion sensing, connectivity, and everyday wearability [19]. These characteristics make them suitable candidates for scalable and real-world deployment as complementary interaction devices in smartphone-centered applications [20]. In this context, prior research on smartwatches in mobile gaming has mainly focused on domains such as exergames [21,22], rehabilitation [23], and health-oriented applications [24], leaving their role in gameplay-oriented interaction largely underexplored, even though immediacy, responsiveness, and reliability are critical in such contexts.

Translating this potential into mobile game prototypes, however, is not straightforward. Smartwatch-based gameplay requires more than pairing two devices: developers must define how smartwatch events are captured, encoded, transmitted, received, interpreted, and finally mapped into game logic. This becomes especially challenging in mainstream game engines, where external wearable inputs are not usually represented as reusable gameplay components. As a result, each new interaction modality or game prototype may require a custom communication pipeline, making it difficult to prototype and compare multiple interaction-driven versions of the same game system.

This challenge is particularly relevant in Unity-based mobile development. Engines such as Unity are widely used because they support cross-platform deployment, rapid prototyping, and reusable gameplay architectures. Comparative studies between major engines highlight Unity’s advantages in accessibility, mobile deployment, and developer adoption, making it a practical choice for experimentation and integration in mobile contexts [25]. However, support for smartwatch-based input in Unity remains limited, typically requiring ad hoc communication pipelines, custom Android plugins, or low-level device-specific implementations [26]. Therefore, although Unity facilitates the creation of mobile game prototypes, integrating smartwatch input into reusable and comparable gameplay mechanics remains a non-trivial task.

Existing technical alternatives further illustrate this gap. Native solutions based on Bluetooth Low Energy (BLE) and platform-specific APIs can enable communication between devices, but they often require developers to manually implement message handling, serialization, synchronization, and mappings between external input and game logic. Research-driven solutions also tend to remain domain-specific, exploratory, focused on immersive environments, or dependent on architectures that are not directly reusable in smartphone-centered Unity gameplay [22,24,27]. Other frameworks focus on extended reality (XR) ecosystems rather than mobile gameplay, limiting their applicability to smartphone-centered pervasive games [28]. This fragmentation complicates experimentation with smartwatch-based interaction schemes and limits the reuse of solutions across projects, devices, and gameplay modalities. In contrast to these domain-specific or XR-oriented approaches, ${\mathrm{Smart}}^2$ provides a publicly available Unity integration that maps multiple smartwatch input modalities into a shared gameplay interface for smartphone-centered games.

To address the challenge of game engine integration, our previous work introduced ${\mathrm{Smart}}^2$, a communication framework that enables bidirectional communication between smartphones and smartwatches within Unity-based applications [29]. The framework source code is publicly available (Smartwatch native implementation: https://github.com/ClaudixoPG/WearOs_Smartphone_Connection, accessed on 10 August 2026). Unity integration: https://github.com/ClaudixoPG/UPluginConnection, accessed on 10 August 2026). That study demonstrated the technical feasibility of transmitting and interpreting multiple smartwatch input modalities in real time. However, technical feasibility at the communication-module level does not fully characterize how smartwatch input behaves when embedded into gameplay mechanics with different temporal and interaction demands.

For gameplay-oriented integration, this remaining gap is also a timing problem. Prior work in interactive systems and games has shown that latency becomes relevant when input events are mapped to time-sensitive actions or continuous control loops [30,31]. In smartwatch-based gameplay, each event passes through wearable capture, wireless transmission, smartphone-side processing, Unity forwarding, and gameplay mapping; therefore, feasibility must be assessed at the level of the complete pipeline, not only at the device-pairing or message-delivery level. Accordingly, this study follows end-to-end latency characterization practices in interactive systems [32,33].

The present work extends this line of research by evaluating ${\mathrm{Smart}}^2$ under system-level gameplay conditions through controlled internal laboratory tests. Rather than conducting a user-centered evaluation, this study examines whether the interaction modes supported by ${\mathrm{Smart}}^2$ can be consistently captured, transmitted, and interpreted within Unity minigames that impose different timing and input requirements. To this end, five Unity-based minigames were designed as controlled interaction probes, each targeting a specific input modality: Tap, D-Pad, Hold, Joystick, and Gyroscope. These scenarios progressively introduce increasing interaction demands, from discrete event-action input to continuous and motion-based control, allowing the analysis of responsiveness, input continuity, latency distribution, jitter, and communication stability in real-time gameplay contexts. Accordingly, the evaluation focuses on the technical behavior of the integrated pipeline across different execution environments and interaction modalities.

The main contributions of this work are threefold. First, it presents the integration of ${\mathrm{Smart}}^2$ into five Unity-based minigames covering discrete, sustained, continuous, and motion-based smartwatch input modalities. Second, it reports a quantitative latency evaluation across heterogeneous Android smartphones using a common Samsung Galaxy Watch 7 input device, including estimated one-way latency, upper-tail latency, jitter, and message-loss observations. Third, it analyzes how latency performance varies across independent tests and interaction modalities, showing that smartwatch-based gameplay input should be evaluated in relation to both execution environments and gameplay mapping strategies.

This article is structured as follows: Section 2 describes the research methodology, communication pipeline, measurement strategy, and minigame design rationale. Section 3 reports the latency results and statistical analysis. Section 4 discusses the implications of ${\mathrm{Smart}}^2$ for smartwatch-based gameplay and pervasive game design. Finally, Section 5 presents the conclusions, limitations, and future research work lines.

2. Materials and Methods

This study follows the Design and Creation research methodology [34], which is well suited for investigating interactive systems through iterative design and implementation. The methodology comprises five stages: (1) awareness of the problem, (2) suggestion of a solution, (3) development, (4) evaluation, and (5) conclusion.

In previous work, the first three stages were addressed through the design and implementation of ${\mathrm{Smart}}^2$, a communication framework that enables bidirectional communication between smartphones and smartwatches within Unity-based applications [29]. That work established the technical feasibility of transmitting and interpreting smartwatch inputs inside Unity through four interaction modes: Tap, D-Pad, Joystick, and Forcebar. The present study extends this foundation by evaluating technical feasibility under gameplay-oriented conditions, that is, whether smartwatch-based inputs can be embedded into time-sensitive game mechanics and characterized in terms of latency, stability, and message delivery.

To support this evaluation, the framework was embedded into five Unity-based minigames, each isolating a specific interaction modality. Three modalities were directly derived from the prior implementation: Tap, D-Pad, and Joystick. The original Forcebar modality was refined into Hold, a sustained-touch interaction represented as a normalized time-based value. This change was made because the term Forcebar could imply pressure-sensitive input, whereas the implementation relies on the duration and progression of a hold gesture rather than physical force. In addition, this study introduces a motion-based modality using gyroscope input, extending the framework from touch-based smartwatch controls toward sensor-based interaction.

Evaluation combines (i) exploratory gameplay inspection focused on observable behavior, such as responsiveness, integration, and interaction constraints surfaced during play, and (ii) lightweight quantitative testing designed to characterize end-to-end input timing and communication robustness under real usage conditions. The goal is not to establish device performance rankings but to characterize whether ${\mathrm{Smart}}^2$ can technically support the evaluated interaction modalities across heterogeneous mobile hardware.

The evaluation considered two complementary dimensions. First, variability was examined across five independent tests, each conducted with a different Android smartphone. Second, variability was examined across the five minigames executed sequentially within each test. Considering both dimensions makes it possible to examine the technical behavior of the same communication framework under different mobile execution environments and interaction modalities.

The smartphones were selected to represent heterogeneous hardware generations, processor families, CPU/GPU architectures, and memory configurations. This diversity allowed ${\mathrm{Smart}}^2$ to be evaluated across different mobile execution environments while keeping the Samsung Galaxy Watch 7 constant across all tests.

Table 1. Hardware and software characteristics of the smartphones used in the experimental evaluation. All smartphones were updated to the latest software version available for each device at the time of testing.

Manufacturer and Device	SoC and Process	CPU and GPU	Memory Subsystem	Android Version and UI	Bluetooth
Samsung Galaxy S25+	Snapdragon 8 Elite for Galaxy; 3 nm	64-bit Qualcomm Oryon octa-core CPU; Qualcomm Adreno GPU	12 GB LPDDR5X	Android 16; One UI 8	5.4
Xiaomi POCO F3	Snapdragon 870; 7 nm	Qualcomm Kryo 585 octa-core CPU, up to 3.2 GHz; Adreno 650 GPU	8 GB LPDDR5; UFS 3.1	Android 13; MIUI 14	5.1
Xiaomi POCO C85	MediaTek Helio G81-Ultra	Octa-core Cortex-A75/Cortex-A55 CPU, up to 2.0 GHz; Mali-G52 MC2 GPU	LPDDR4X; eMMC 5.1	Android 15; Xiaomi HyperOS 2	5.4
Samsung Galaxy S22+	Samsung Exynos 2200; 4 nm	64-bit octa-core CPU, up to 2.8 GHz; Xclipse 920 GPU	8 GB RAM	Android 16; One UI 8	5.2
Xiaomi 15T Pro	MediaTek Dimensity 9400+; 3 nm	Cortex-X925/Cortex-X4/Cortex-A720 octa-core CPU; Immortalis-G925 MC12 GPU	12 GB LPDDR5X; UFS 4.1	Android 16; Xiaomi HyperOS 3	6.0

summarizes the hardware characteristics of the equipment used.

2.1. Communication Pipeline and Measurement Strategy

The ${\mathrm{Smart}}^2$ framework operates through a bidirectional communication pipeline involving three modules: (1) the Wear OS smartwatch module, (2) the Android handheld module, and (3) the Unity Framework module. Figure 1 summarizes this architecture, including the direction of input messages, acknowledgment messages, timestamp collection, and the integration points between the native Android implementation and the Unity framework.

• The Wear OS smartwatch module is responsible for generating and preparing smartwatch interaction events before transmission. This module is organized into two functional blocks: Input Event Sources and Message Preparation and Dispatch. The Input Event Sources block contains both control-based inputs, including Tap, D-Pad, Hold, and Joystick, and sensor-based inputs, including Gyroscope, Location, and Heart Rate. These interaction sources are unified through shared interaction fragments that standardize smartwatch interaction handling. Once an interaction event is generated, the Message Preparation and Dispatch block encapsulates the input into a payload containing the raw input data, a unique event_id, and a smartwatch-side timestamp, send_ts_watch. This timestamp is recorded immediately before dispatch and marks the beginning of the measured cycle. The resulting message is then transmitted to the paired Android smartphone using the Google Play Services Wearable API, specifically through the Message API and MessageClient.sendMessage().
• The Android handheld module is responsible for receiving, processing, and encapsulating smartwatch messages before integration with Unity. This module is divided into three functional blocks: Message Reception, Message Processing, and Plugin Encapsulation. The Message Reception block receives incoming smartwatch events through a MessageClient.Listener connected to the Wearable API. At this point, receive_ts_phone_native is recorded to identify the message arrival at the native smartphone layer. Since messages are transmitted as binary data, the Message Processing block decodes incoming events into instrumented events containing event_id information and direct raw input events. Finally, the Plugin Encapsulation block exposes the native Android functionality to Unity through the exported PluginActivity interface. This plugin provides both smartwatch communication utilities and a Unity-consumable messaging interface based on UnityPlayer.UnitySendMessage(...) for forwarding processed smartwatch events into the Unity runtime and dispatching the ACK returned after Unity processing.
• The Unity Framework module is responsible for interpreting smartwatch messages and mapping them into gameplay interactions. This module contains a single functional block, Message Interpretation, which is composed of two main components: Gameplay Mapping and Minigames. The Gameplay Mapping component receives forwarded messages from the Android plugin interface, records receive_ts_unity, parses telemetry information such as event_id, and maps smartwatch inputs to the shared IGameController interface. This shared interface acts as a common abstraction layer between the communication framework and the different gameplay implementations, allowing smartwatch interactions to be interpreted consistently across minigames. The Minigames component contains the gameplay implementations used in this study, including Runner for Tap interactions, Rhythm for D-Pad interactions, Fishing for Hold interactions, SpaceShip for Joystick interactions, and Gyro for motion-based interactions. The Unity module also supports telemetry and latency data persistence for later analysis. After the event is delivered through HandleMessage(event_id, data), Unity invokes the native plugin to return an ACK containing the corresponding event_id and receive_ts_unity.

A key challenge in measuring latency across this pipeline is the absence of a shared clock between smartwatch and smartphone devices. Direct timestamp comparison, such as subtracting send and receive times across devices, is therefore unreliable due to clock drift and synchronization offsets. To address this limitation, we adopt a round-trip time (RTT) strategy [35]. The smartwatch records send_ts_watch immediately before message dispatch and ack_ts_watch when the corresponding ACK is received. RTT is computed on the smartwatch as the elapsed time between the original message dispatch, send_ts_watch, and the reception of the acknowledgment, ack_ts_watch. Because both timestamps are collected using the same smartwatch clock, the calculation does not require clock synchronization between devices. The intermediate timestamps receive_ts_phone_native and receive_ts_unity are retained to trace the message through the pipeline but are not directly combined with the smartwatch timestamps. Since this measure includes transmission, processing, and scheduling delays across both directions of the pipeline, one-way latency is approximated as RTT/2 under the assumption of symmetric delays. RTT is therefore the directly measured quantity, whereas RTT/2 represents an estimated one-way latency. Because the forward input path and the return ACK path perform different operations, the estimated values should be interpreted as approximations rather than direct one-way measurements.

To avoid saturating the communication channel, the system follows an event-based communication model in which all interactions are encoded as events. Two transmission strategies are applied depending on how these events are generated: (1) event-per-action transmission, used for interactions that occur at specific moments in time, such as Tap or D-Pad presses, where each event is transmitted individually as it represents a complete user action; (2) time-based sampling transmission, used for interactions that evolve continuously over time, such as Joystick position or Hold progression.

For Hold, Joystick, and Gyroscope, values were sampled and transmitted every 30 ms, corresponding to a nominal application-side rate of approximately 33.3 Hz. This interval was applied only while the corresponding interaction was active, that is, while the user was actively generating input through the smartwatch interface; no continuous input messages were transmitted during periods without user interaction. All transmitted messages were instrumented with a unique event_id and generated an ACK after delivery to the active Unity minigame controller. Message loss was assessed by verifying the continuity of sequential event_id values within each session and their correspondence with received ACK message. This measurement strategy allows the system to capture realistic timing behavior under gameplay conditions while preserving the integrity of the interaction experience.

2.2. Development

The development phase focused on integrating the ${\mathrm{Smart}}^2$ framework into a set of Unity-based minigames explicitly designed to evaluate smartwatch-based interaction under gameplay conditions. Rather than prioritizing narrative depth or audiovisual complexity, each prototype was intentionally minimal, allowing the analysis to focus on input capture, transmission, interpretation, and integration within core mechanics.

Five minigames, Runner, Rhythm, Fishing, SpaceShip, and Gyro, were designed and implemented, each associated with a specific interaction modality supported by ${\mathrm{Smart}}^2$. The set was deliberately structured as a progression of interaction complexity, moving from event-per-action to continuous time-based measurement.

All prototypes were developed in Unity 3D, version 6000.0.51f1, using C# scripts to process smartwatch inputs received through the ${\mathrm{Smart}}^2$ plugin. Interactions were captured on a Wear OS application, transmitted through the smartphone native layer, and interpreted in Unity as gameplay commands. This consistent architecture allows each minigame to function as a controlled interaction probe, isolating specific input characteristics while maintaining identical communication conditions across scenarios.

2.3. Minigame Design Rationale

Runner—Tap Interaction. The Runner was conceived as the simplest interaction scenario and serves as the baseline for evaluating gameplay feasibility. The core mechanic consists of executing an event-action, such as jumping or avoiding obstacles, at the correct moment. The smartwatch operates as a Tap input device, where each touch generates a single event mapped directly to an in-game action. From an interaction perspective, this prototype evaluates instantaneous input under time-sensitive conditions. The key objective is not control complexity but to determine whether an event-action generated on the smartwatch can be transmitted and interpreted in Unity with sufficient responsiveness and consistency to sustain gameplay. Figure 2a illustrates the interaction between smartwatch and smartphone interfaces.

Rhythm—D-Pad Interaction. The Rhythm extends the interaction demands by introducing sequential and temporally constrained input. Players must reproduce directional patterns, up, down, left, and right, synchronized with visual stimuli, requiring not only correct input detection but also correct ordering and timing. The smartwatch acts as a D-Pad interface, where each direction corresponds to an event-action. This prototype evaluates the system’s ability to sustain sequences of event-actions without loss, delay accumulation, or ambiguity between commands. Unlike Runner, correctness depends on both temporal precision and input identity. Figure 2b presents the smartwatch and smartphone interaction.

Fishing—Hold Interaction. The Fishing represents a transition from event-action to time-based sampling. The interaction is performed on the smartwatch through a Hold modality, where the user sustains and modulates input over time to control a hook. This input is transmitted as sampled values and reflected in real time on the smartphone as a dynamic bar, representing the hook position, which must be kept aligned with a moving target associated with the fish. The objective is to maintain alignment long enough to achieve capture, while loss of control leads to the fish escaping. Unlike event-action interactions, where each input corresponds to a single transmission, this approach relies on the continuous update of the interaction state over time. This introduces challenges related to temporal stability, signal consistency, and accurate detection of interaction phases, including initiation, sustain, and release. From a methodological perspective, this minigame evaluates input through time-based sampling, emphasizing temporal control over event-action execution. Figure 2c illustrates the interaction setup.

SpaceShip—Joystick Interaction. The SpaceShip relies on time-based sampling to support bidimensional control and represents one of the most demanding interaction scenarios. Players control a spacecraft in a two-dimensional space, requiring constant adjustment of direction and intensity to navigate, avoid threats, and react dynamically to the environment. The smartwatch provides a Joystick-like input, represented as sampled two-dimensional values that are continuously updated and transmitted to the smartphone. Unlike event-action interactions, where each input corresponds to a single transmission, gameplay depends on the sustained update of directional input over time. This makes the minigame particularly sensitive to latency, jitter, and sampling frequency, while enabling the evaluation of the system’s ability to sustain real-time control under conditions that require fluid motion and rapid directional changes. Figure 2d illustrates this interaction.

Gyro—Motion-Based Interaction. The Gyro introduces a sensor-based interaction modality, where input is derived from the physical orientation of the smartwatch. Players must tilt the device to control the movement of an object, such as guiding a sphere toward a target, mapping wrist motion directly to in-game behavior. This interaction relies on time-based sampling, where the smartwatch continuously captures and transmits gyroscope readings to represent device orientation over time. Unlike event-action interactions, input is not triggered by explicit actions but by the ongoing measurement of motion. This introduces additional complexity, as the system must interpret real-time sensor data, handle noise, and maintain stable control under potentially irregular sampling conditions, enabling the assessment of motion-driven interaction within the ${\mathrm{Smart}}^2$ framework. Figure 2e illustrates the interaction between smartwatch and smartphone.

3. Results

An assessment of several metrics was conducted to characterize the latency performance of ${\mathrm{Smart}}^2$ during mobile gameplay sessions. The goal was to evaluate whether the framework could sustain responsive smartwatch-based interaction across the five independent tests and the evaluated minigame interaction conditions.

Tests were conducted using five Android smartphones spanning different performance tiers, while all experiments used a Samsung Galaxy Watch 7 as the smartwatch input device. Each smartphone was evaluated independently in one complete test comprising the five minigames presented sequentially. This setup isolated the smartwatch side of the pipeline and allowed the evaluation to focus on variability introduced by the smartphone, the selected interaction modality, and the computational demands of each gameplay scenario.

Rather than using isolated hardware benchmarks, the evaluation was conducted through complete gameplay sessions. This allowed latency performance to be analyzed in the context of the full ${\mathrm{Smart}}^2$ pipeline, including smartwatch input generation, smartphone message handling, Unity integration, and in-game execution.

3.1. Metrics

The evaluation focused on the latency performance of the ${\mathrm{Smart}}^2$ communication pipeline. Because the smartwatch and smartphone do not share a synchronized clock, direct timestamp comparison across devices was not used. Instead, latency was estimated through a round-trip time approach.

• Round-Trip Time (RTT, ms): The time elapsed between sending an input message from the smartwatch and receiving an acknowledgment (ACK) after the message has been processed through the smartphone and Unity pipeline. RTT was computed on the smartwatch as

$$RTT=t_{\mathrm{ack}}-t_{\mathrm{send}},$$

(1)

where $t_{\mathrm{send}}$ is the timestamp at which the message is sent, and $t_{\mathrm{ack}}$ is the timestamp at which the acknowledgment is received.

• Estimated One-Way Latency (ms): Approximated as half of the RTT, under the assumption of symmetric communication delays:

$$L\approx {\displaystyle \frac{RTT}{2}}.$$

(2)

• Mean and Median Latency (ms): The central tendency measures used to describe the typical latency of each minigame. The mean captures the average latency, while the median provides a value less sensitive to extreme observations.
• P95 and P99 Latency (ms): The upper-tail latency measures used to characterize high-latency cases. These percentiles are relevant for real-time interaction because occasional latency peaks may affect perceived responsiveness even when average latency remains low.
• Jitter SD (ms): The standard deviation of event-level one-way latency, used as an indicator of temporal stability. Higher jitter indicates more variable latency between input events.
• Minimum and Maximum Latency (ms): The observed latency range for each minigame, used as descriptive indicators of the lowest and highest recorded values after preprocessing.

3.2. Procedure and Latency Computation

Each smartphone was evaluated in a complete gameplay session composed of five minigames executed sequentially. Each minigame was played for approximately five minutes, resulting in an estimated total duration of 25 min per smartphone.

During execution, interaction messages were generated on the Samsung Galaxy Watch 7 and transmitted through the ${\mathrm{Smart}}^2$ communication pipeline. Each measured message included an identifier and a timestamp generated on the smartwatch. After the message was received and processed through the smartphone and Unity pipeline, an acknowledgment was sent back to the smartwatch, allowing RTT and estimated one-way latency to be computed as defined in the previous subsection.

For event-action modalities, such as Tap and D-Pad, measurements were recorded per input action. For time-based sampling modalities, such as Hold, Joystick, and Gyroscope, measurements were recorded for every transmitted event. This approach allowed representative latency data to be captured while preserving the integrity of the gameplay experience. The reported descriptive and inferential analyses were based on the 6547 preprocessed events presented in

Table 2. One-way latency by smartphone and minigame. Each cell reports the number of events and mean latency; the last column shows the per-device mean. Event counts vary by minigame and smartphone according to user activity during gameplay. The Total row reports event-weighted means across the five smartphones.

Smartphone	Runner		Rhythm		Fishing		SpaceShip		Gyro		Per-Device Mean
	Events	ms	Events	ms	Events	ms	Events	ms	Events	ms	ms
Xiaomi POCO C85	37	47.18	84	53.06	140	52.34	154	46.64	73	50.82	50.01
Xiaomi POCO F3	142	43.84	245	50.90	387	44.93	372	36.65	196	44.82	44.23
Samsung Galaxy S25+	90	40.86	243	29.61	465	27.68	465	19.16	191	31.19	29.70
Samsung Galaxy S22+	115	28.20	239	28.85	504	31.09	495	23.76	180	37.60	29.90
Xiaomi 15T Pro	73	31.34	482	24.89	496	29.39	472	26.29	207	31.91	28.76
Total	457	37.59	1293	33.27	1992	34.05	1958	27.53	847	37.57	–

and

Table 3. Event-level one-way latency by minigame. Mean and median describe central tendency, P95 and P99 describe upper-tail latency, and jitter SD describes temporal variability.

Minigame	Mean (ms)	Median (ms)	P95 (ms)	P99 (ms)	Jitter SD (ms)	Min (ms)	Max (ms)
Runner	37.59	29.67	80.12	116.57	20.68	14.64	140.63
Rhythm	33.27	27.74	71.58	131.34	19.97	13.93	162.10
Fishing	34.05	32.67	64.70	82.81	12.69	15.28	107.38
SpaceShip	27.53	22.95	59.08	79.52	13.44	12.15	98.00
Gyro	37.57	36.48	66.30	75.74	12.02	13.80	100.27

.

3.3. Latency Results

The integration of the ${\mathrm{Smart}}^2$ module into Unity-based minigames showed that smartwatch input can be translated into real-time gameplay actions across the five evaluated interaction modalities. In all tests, the input messages were successfully recognized by the smartphone and Unity pipeline, and no missing event identifiers were found when the recorded sequences were checked within each test. Therefore, the latency analysis focuses not on communication failures but on how response times varied across experimental tests and minigame-specific interaction demands.

Table 2 summarizes the estimated one-way latency by experimental test and minigame. The mean shown in the Total row for each minigame was calculated as an event-weighted mean across the five tests, rather than as a simple average of the five test means. This accounts for the unequal number of events generated in each test, since event counts depended directly on the interaction performed during gameplay. For minigame m, the weighted mean was calculated as

$${\overline{L}}_m={\displaystyle \frac{{\sum }_{s=1}^5{n}_{s,m}{\overline{L}}_{s,m}}{{\sum }_{s=1}^5{n}_{s,m}}},$$

(3)

where $n_{s,m}$ is the number of events recorded for minigame m in test s, and ${\overline{L}}_{s,m}$ is its mean estimated one-way latency. For example, the Runner mean was calculated as

$${\overline{L}}_{\mathrm{Runner}}={\displaystyle \frac{37\left(47.18\right)+142\left(43.84\right)+90\left(40.86\right)+115\left(28.20\right)+73\left(31.34\right)}{37+142+90+115+73}}=37.59\mathrm{ms}.$$

(4)

The table highlights two relevant patterns. First, latency was not uniform across tests: the first two tests showed higher per-test means, 50.01 ms and 44.23 ms, whereas the remaining tests stayed around 29–30 ms. Second, this variation was observed in several minigames, suggesting that latency differences are not explained by a single interaction modality alone. These results demonstrate variability in the five independent tests.

Table 3 summarizes event-level latency by minigame using central tendency, upper-tail latency, variability, and observed range. SpaceShip showed the lowest mean and median latency, 27.53 ms and 22.95 ms, indicating the fastest response profile among the evaluated minigames. Runner and Gyro showed similar mean latency values, 37.59 ms and 37.57 ms but differed in variability: Runner presented the highest jitter SD, 20.68 ms, while Gyro showed the lowest jitter SD, 12.02 ms. This distinction is important because average latency and stability do not always move together. The P95 and P99 values further show that Runner and Rhythm had the largest high-latency tails, indicating that event-action interactions may be more exposed to isolated latency peaks.

3.4. Statistical Analysis

A two-factor main-effects ANOVA was conducted on the test-by-minigame mean latency table to evaluate differences associated with (1) the five experimental tests and (2) the minigames. The dependent variable was the mean estimated one-way latency for each test–minigame combination. One mean value was used for each test–minigame combination. This gave equal analytical weight to each combination despite differences in event counts and avoided treating temporally related events from the same gameplay session as independent observations. Paired post-hoc comparisons were then used to identify which specific pairs differed, with Holm correction applied to control for multiple comparisons. The analysis showed a statistically significant effect of each independent test, $F(4,16)=28.02$, $p<0.001$. This indicates that mean estimated one-way latency differed across experimental tests. The first two tests showed higher latency than the later tests.

The analysis also showed a statistically significant effect of minigame, $F(4,16)=3.44$, $p=0.0328$. This indicates that mean estimated one-way latency differed across minigames. Post-hoc paired comparisons with Holm correction showed that the only statistically significant minigame difference was between Fishing and SpaceShip. Fishing showed higher latency than SpaceShip, with an adjusted mean difference of 6.59 ms, $p_{\mathrm{adj}}=0.028$. No other minigame pair remained statistically significant after correction.

4. Discussion

4.1. Latency Variability in Experimental Tests

The results show that latency varied significantly across the five experimental tests. This finding indicates that the ${\mathrm{Smart}}^2$ pipeline does not behave identically across all runs, even when the same smartwatch, minigames, and communication structure are used. Therefore, latency should not be interpreted as a fixed property of the framework across heterogeneous test conditions.

Because each test was conducted using a different smartphone, the observed differences cannot be attributed exclusively to either hardware characteristics or test-specific runtime conditions. Instead, they should be interpreted as variability in the evaluated test configurations. The result shows that reporting latency by test provides a more transparent view of system performance than reporting only a single global average.

This observation is relevant for real-time pervasive gameplay because technical responsiveness depends not only on average latency but also on consistency across tests. A system may perform well overall while still presenting run-specific variations that affect responsiveness in particular conditions. For this reason, future evaluations should include repeated tests per smartphone under more controlled conditions and monitor contextual variables such as battery level, temperature, system load, and connection state.

4.2. Latency Variability in Interaction Modalities

The results also show that latency varied significantly across minigames, showing an association between latency profiles and how smartwatch input was mapped into the evaluated gameplay mechanics. In other words, the same ${\mathrm{Smart}}^2$ communication pipeline can produce different latency profiles depending on the interaction modality, sampling strategy, and gameplay use of the received input.

The evaluated minigames covered two main interaction strategies. Runner and Rhythm used event-action interactions, where messages are generated in response to specific user actions. Fishing, SpaceShip, and Gyro used time-based sampling, where the smartwatch updates and transmits values over time. These categories are relevant because they impose different temporal demands on the communication pipeline.

The descriptive metrics provide additional insight into these differences. Mean and median latency describe the central response profile of each minigame, while P95 and P99 identify upper-tail latency events that may affect perceived responsiveness. Jitter SD complements these measures by capturing temporal variability. Runner and Rhythm showed the highest jitter values and larger upper-tail latency values, suggesting that event-action interactions may be more exposed to irregular timing or isolated high-latency events. In contrast, some time-based sampling interactions showed lower jitter, indicating that periodic updates can produce more stable latency distributions.

However, time-based sampling interactions should not be treated as equivalent. The clearest statistical difference was observed between Fishing and SpaceShip, with Fishing showing higher latency. Fishing depends on sustained regulation of a hold-based value, where the player controls a hook represented by a bar and must keep it aligned with a moving fish. In this case, latency and stability are relevant to the continuity of control. SpaceShip, by contrast, maps sampled joystick values to bidimensional movement and showed the lowest mean and median latency, suggesting that sampled spatial control can be efficiently handled by the pipeline. Gyro extends the same time-based logic to motion input but introduces additional requirements related to sensor noise, filtering, and calibration.

The measured means ranged from 27.53 to 37.59 ms across minigames and from 28.76 to 50.01 ms across the five experimental tests, while P99 values ranged from 75.74 to 131.34 ms. Prior studies of interactive systems and games show that latency effects depend on the task, input modality, and temporal demands [30,31,32,33]. Accordingly, these measurements provide an initial system-level characterization of ${\mathrm{Smart}}^2$ as a framework capable of supporting responsive interaction under the evaluated conditions. Future user-centered studies are required to determine how this measured performance translates into perceived responsiveness and playability.

These results indicate that smartwatch input should not be evaluated only at the level of the communication mechanism. The same pipeline can support different input strategies, but each modality introduces specific requirements for sampling, stabilization, and gameplay mapping.

4.3. Implications for Smartwatch-Based Gameplay

Across all experiments, the ${\mathrm{Smart}}^2$ pipeline demonstrated stable communication and successful translation of smartwatch input into Unity gameplay. The results indicate that the framework can support both event-action and time-based sampling interactions. Nevertheless, the statistical analysis shows that latency performance varies across both experimental tests and minigames, indicating that interaction modality and variability in the five tests must be considered when evaluating technical performance.

These findings have three main implications. First, latency should be reported not only as a global average but also by test or run, because substantial variability was observed in the five experimental tests. Second, smartwatch input should be evaluated in relation to the gameplay mechanic it supports, because the same communication pipeline may behave differently depending on the interaction mapping. Third, distribution metrics such as median latency, P95, P99, and jitter should complement mean latency, especially in real-time interaction scenarios where isolated peaks or unstable timing may affect the gameplay experience.

Overall, the results suggest that ${\mathrm{Smart}}^2$ functions not only as a communication layer but also as a framework for exploring how smartwatch-based interaction can be integrated into real-time Unity gameplay. The findings show that performance evaluation should account for both test conditions and interaction design, since latency varied across the evaluated tests and gameplay mappings.

Rather than simply replicating or porting existing mobile game interactions to a smartwatch, the framework supports the exploration of new forms of wearable-assisted interaction in which smartwatches operate as complementary devices integrated into the gameplay experience. This enables the design of interaction mechanics that combine touch-based input, motion sensing, context awareness, and continuous wearable interaction within the same gameplay pipeline.

These capabilities are particularly relevant for the development of pervasive mobile games, where interaction extends beyond the smartphone screen and becomes embedded within real-world activities and contexts. In this sense, frameworks such as ${\mathrm{Smart}}^2$ could support new gameplay experiences in location-based or context-aware games similar to Pokémon GO or Pikmin Bloom, where wearable devices may enrich player interaction through complementary sensing, continuous monitoring, or less intrusive forms of gameplay input. This opens opportunities for designing pervasive gameplay experiences that integrate wearable interaction more naturally into everyday mobile play while allowing responsiveness and gameplay continuity to be assessed in future user-centered studies.

5. Conclusions

This study evaluated the latency performance of the ${\mathrm{Smart}}^2$ communication module in real-time Unity-based gameplay scenarios. The evaluation was conducted through five minigames targeting Tap, D-Pad, Hold, Joystick, and motion-based interaction modalities. Tests were performed across five Android smartphones using a Samsung Galaxy Watch 7 as the smartwatch input device. Across all tests, smartwatch inputs were consistently recognized and translated into in-game actions, with stable connectivity and no observed message loss, as assessed through event-identifier continuity and the corresponding ACK message.

The results show that ${\mathrm{Smart}}^2$ can support both event-action and time-based sampling interactions in gameplay contexts. However, latency was not uniform across all conditions. The statistical analysis showed significant differences between experimental tests, showing variability across the five evaluated execution environments. Because each smartphone was evaluated in a single test, hardware and test-specific effects cannot be separated. Significant differences were also found between minigames, with the clearest difference observed between Fishing and SpaceShip. These findings suggest that latency should not be treated as a single fixed property of the communication framework but as a performance measure that varied across the evaluated test and minigame conditions.

The latency distribution metrics further showed that mean latency alone is insufficient to characterize real-time interaction performance. Median latency, upper-tail latency, P95 and P99, jitter, and observed ranges provide complementary information about responsiveness and temporal stability. In particular, the results suggest that minigames with similar average latency may still differ in variability, while occasional latency peaks may be relevant for time-sensitive interaction.

Beyond the technical evaluation, the results highlight design opportunities for smartwatch-based gameplay. ${\mathrm{Smart}}^2$ enables modular interaction schemes that can be adapted to different gameplay mechanics, including single-action input, directional control, hold-based regulation, joystick movement, and motion-based interaction.

Limitations

This study presents three main limitations that should be considered when interpreting the results. First, all experiments were conducted using a single smartwatch model, Samsung Galaxy Watch 7. Although the framework was evaluated across multiple Android smartphones, the observed latency patterns may still be influenced by the specific hardware, operating system behavior, sensor configuration, and communication characteristics of the selected smartwatch device. Second, each smartphone was evaluated using a single test, so device hardware differences cannot be separated from test-specific runtime conditions. Relevant runtime variables, including thermal state, background load, and connection state, were not systematically controlled. Third, the reported one-way latency was estimated as RTT/2. Because the forward input path and return ACK path differ by construction, symmetry cannot be guaranteed.

Future work will include controlled user studies assessing usability, accessibility, perceived responsiveness, and perceived playability; more detailed instrumentation of runtime variables such as battery level, temperature, connection state, and system load; repeated tests per smartphone; and evaluation with additional smartwatch devices to assess whether the observed latency patterns generalize across wearable hardware.