Leveraging Grammarware for Active Video Game Development

Abstract

This paper presents a grammarware-based approach to developing active video games (AVGs) for sensor-driven training systems. The GCGame domain-specific language (DSL) is introduced to define game logic, sensor interactions, and timing behavior formally. This approach ensures cross-platform consistency, supports real-time configurability, and simplifies the integration of optimization and visualization tools. The presented system, called GCBLE, serves as a case study, demonstrating how grammarware enhances modularity, maintainability, and adaptability in real-world physical interaction applications. The results highlight the potential of a DSL-driven design to bridge the gap between developers and domain experts in embedded interactive systems.

1. Introduction

Software development is a resource-intensive process, requiring significant investments of time and money. Despite substantial progress in development tools and methodologies, the increasing interconnectivity of modern systems continues to introduce additional layers of complexity. Modern software must strike a delicate balance: it must be highly user-friendly and integrate seamlessly with digital ecosystems while remaining adaptable to diverse user needs and capable of interoperating within complex environments [1]. This paper explores the application of a DSL through the development of an active hockey stick-handling video game, addressing key challenges such as dependency decoupling, connectivity, extensibility, flexibility, and maintainability.

The rising popularity of video games and the corresponding increase in inactive lifestyles have raised significant health concerns among players, including obesity, postural issues, and spinal problems. In response, researchers and engineers have turned to AVGs as a potential solution. These games shift the focus from traditional keyboard-and-mouse interactions to body-oriented engagement, requiring players to use physical movement to interact with the game [2,3,4].

Designing a purpose-built platform for AVGs involves balancing the competing demands of connectivity, scalability, and standalone functionality. For example, the Game Changer Classic (GCC) platform, designed to enhance puck control, reaction time, and overall skills in ice hockey stick-handling training [5], lacks connectivity, user configurability, and scalability, limiting its potential for broader applications. To address the need for flexible, user-configurable game design in sensor-driven training systems—while maintaining cross-platform consistency and long-term maintainability—we pose the following research question: How can we achieve flexible and user-configurable game design in sensor-driven training systems while ensuring cross-platform consistency and long-term maintainability?

This paper introduces a grammarware-based approach to software development for specialized, sensor-driven devices. The proposed method facilitates seamless integration with various systems, including cloud services, mobile applications, and external hardware components.

The main contributions of this paper are as follows:

• Novel DSL for AVGs: We introduce a modular and extensible DSL for defining AVGs. It supports time- and event-based gameplay, sensor configuration, and state annotations. We demonstrate the DSL’s extensibility by introducing new features with minimal effort. Applying grammarware principles ensures cross-platform consistency and reduces system complexity, enabling a broader range of use cases.
• Configuring a dedicated system with a dsl to act as a mobile game controller: A novel use of the DSL is demonstrated, where the flexibility of DSL-defined games enables the system to function as a remote controller for a mobile video game. This functionality is achieved without requiring modifications to either the software or hardware, illustrating how grammarware allows devices to operate beyond their originally intended purpose.
• Optimization problem constraints defined by DSL programs: Implementing and parameterizing optimization problems are typically complex and time-consuming tasks. This complexity is reduced by utilizing DSL programs to define constraints and objectives directly. Instead of hardcoding parameters, the optimization process relies on DSL-based specifications, improving both flexibility and readability in game generation tasks.
• Case study of a GCBLE system: We present the GCBLE system as a real-world case study of grammarware in development. The system demonstrates the practical benefits of using a DSL in a connected, sensor-based training environment.

This paper is structured as follows: Section 1 introduces the research context and objectives. Section 2 reviews related work, establishing the foundation for our approach. Section 3 provides a conceptual overview of the hardware and basic functionality of the game-changer hockey stick-handling training system. Section 4 explores the core aspects of grammarware development, with a focus on language design. Section 5, titled ‘Grammarware Use Cases’, demonstrates the advantages of the grammarware approach through game visualization, its use as a mobile game remote controller, and the definition of an optimization problem constraint using DSL, accompanied by a small-scale optimization experiment. Finally, Section 6 concludes with a discussion and summary of the key findings.

2. Related Work

AVGs integrate physical activity with gameplay, relying on embedded systems for real-time sensor processing and feedback. Recent advances use microcontrollers like the ARM Cortex-M series to handle inputs from accelerometers and force sensors [6]. Systems such as the GCC embed sensors in sports equipment for precise motion tracking [7]. These designs prioritize low-power efficiency, using C/C++ firmware for resource-constrained hardware [8]. The traditional approach relies on hardcoded game logic in general-purpose languages, limiting flexibility and reusability, unlike the grammarware-based method proposed here [9,10].

One critical challenge in software development is decoupling dependencies to enhance testability and enable independent development. This challenge intensifies when managing intricate data structures. To address this, we leverage grammarware [11], where a DSL [12,13] encapsulates core data. Grammarware—a methodology rooted in formal language definitions and DSLs—enables better decoupling of software development concerns by separating high-level game logic from low-level implementation details. This approach enhances modularity, reusability, and maintainability, allowing developers to focus on game design and mechanics while abstracting the technical complexities [14]. By defining clear, structured rules for game behavior, grammarware facilitates seamless collaboration among tools such as game editors, play-session visualizations, smart game generators, and analytical tools. This mirrors the ecosystem of traditional programming languages, where tools like debuggers [15], profilers, verifiers [16], and editors with autocomplete [17,18] improve development efficiency and productivity. Key differences between the traditional approach and the grammarware approach are summarized in

Table 1. Comparison of software development approaches: traditional vs. grammarware.

Feature	Traditional Approach	Grammarware
Paradigm	Imperative, object-oriented	DSL specification
User	Game developers	Domain experts, designers, or non-programmers
Modularity	Logic tightly coupled with objects	Language constructs define modular logic
Code Reuse	Manual; duplication is common	High, via reusable language patterns
Flexibility	Low; changes often require code edits	High; new logic via grammar
Maintainability	Low to moderate	High
Extensibility	Requires major refactoring	Extend DSL
End-user configurability	Low (hardcoded behavior)	High—users write DSL scripts/programs
Tooling	General-purpose IDEs	DSL editors, grammar tools, code generators
Example use	Hardcoded games	Custom game rules, training workflows, level generation

.

A formal game description builds on advancements in programming tools, ranging from basic parsers to sophisticated program analysis techniques. For instance, parsers can detect syntax errors in game descriptions and provide detailed error reporting, enhancing the development process significantly. This formalization also improves testing by ensuring consistent data exchange across various tools. Moreover, it enables the creation of both textual and visual editors, streamlining game design and implementation [19].

The use of DSLs has been well-established across various domains. In video games, DSLs are employed to describe game rules, levels, non-playable character behavior, or even entire games [20,21,22]. To frame the comparison between grammarware and traditional development approaches in the context of AVGs, we have organized the related work around three key aspects: software development, peripheral device integration, and procedural level generation.

2.1. AVG Software Development

AVGs typically operate on dedicated embedded hardware to optimize cost, performance, and user experience. Traditionally, this hardware is standalone, featuring built-in sensors and controllers to track player movement and deliver real-time feedback [23]. Such a standalone operation is vital for seamless interaction in settings like training facilities or public venues. Software development for these embedded systems relies conventionally on general-purpose languages like C or C++, using specialized environments such as PlatformIO [24,25]. Unlike traditional game engines (e.g., Unity, Godot, Unreal) [2,26], which offer extensive features but are ill-suited for resource-constrained embedded environments, this approach demands device-specific tools—like level editors and resource managers—for consistency and maintainability [27].

In contrast, our grammarware-based approach, exemplified by the presented GCBLE system and the GCGame DSL, overcomes these limitations. Traditionally, hardcoded game logic in general-purpose languages restricts flexibility, reusability, and end-user configurability. Grammarware introduces a DSL that abstracts low-level complexities, enabling modular, reusable game designs adaptable across platforms. This facilitates the development of visualization tools, such as real-time game state editors, and smart generators, enhancing collaboration between developers and non-technical users (e.g., coaches). By integrating structured rules and AI-driven optimization, our method improves developer efficiency and empowers end-users to customize gameplay, delivering more dynamic, immersive experiences [27,28].

2.1.1. AVG Peripheral Devices

AVGs often extend existing platforms through specialized peripheral devices that track players’ movements and enable physical interaction. Examples include motion detection via cameras [29] and controllers with motion sensors [30]. Traditionally, these devices function as input mechanisms for various applications, relying on middleware to integrate them with digital games [31]. With the rise of the Internet of Things (IoT), controlling games via diverse devices has gained traction [32], though altering their functionality remains complex, requiring intricate software modifications.

In contrast, our grammarware-based approach, implemented in the GCBLE system with the GCGame DSL, simplifies this process. Traditionally, middleware-driven integration limits flexibility and demands technical expertise for reconfiguration. Grammarware enables seamless adaptation of peripheral functionality through a DSL, transforming devices like GCBLE into versatile controllers without extensive recoding. This enhances configurability for developers and end-users, such as coaches, fostering innovative, interactive experiences with reduced complexity.

2.1.2. Procedural Level Generation

This subsection reviews procedural level generation to contextualize our grammarware-based optimization within existing methods for creating dynamic game content. Generating engaging video game levels is a time-consuming and resource-intensive challenge [2]. Traditionally, developers leverage algorithms like noise-based generation (e.g., Perlin or Simplex noise) for terrains, cellular automata for caves, and Binary Space Partitioning (BSP) for rooms [33,34,35]. Techniques such as Wave Function Collapse (WFC), tile-based assembly, and mesh-based 3D modeling balance randomness with control, often using seeding for reproducibility [36,37]. These methods, while effective, typically rely on predefined rules or manual tuning, limiting adaptability in real-time contexts.

In contrast, our grammarware approach, implemented in the GCBLE system with the GCGame DSL, enhances procedural generation for AVGs. Traditionally, static algorithms lack flexibility for dynamic adaptation. Grammarware integrates real-time player data and DSL-defined constraints, enabling adaptive, personalized levels that respond to performance (e.g., via the genetic algorithms in Section 5). This improves engagement, reduces manual effort, and supports non-technical users in customizing training scenarios.

3. Ice Hockey Stick-Handling System

We utilized the versatile GCC ice hockey training system for the functionality benchmark, designed to enhance puck control, reaction time, and overall skills [5]. It features nine single-player training modes and two multiplayer games, all aimed at improving on-ice performance (Figure 1). The device includes 10 multi-colored target lights, two rebounder bands, and two ePucks (pucks with embedded magnets). Its compact, foldable design (85 cm × 83 cm) ensures portability. The system targets primarily players seeking to sharpen their stick-handling skills and react instinctively in high-pressure situations.

The core gameplay mechanic involves guiding the ePuck over a light source with a stick, where its presence is detected. This detection mechanism drives various game state transitions, such as advancing to the next level, adding or deducting points, or triggering a game-over condition.

While the GCC system provides effective training capabilities, it has several limitations. It offers only a fixed set of pre-programmed games, restricting customization. The result logs are stored solely on the device, with no options for external storage or analysis. Additionally, the system lacks a detailed usage history, preventing long-term progress tracking and performance comparison [5]. The GCBLE prototype addresses these shortcomings by incorporating a Bluetooth Low Energy (BLE) connectivity module. This addition enables seamless data transfer to external devices, real-time performance monitoring, and enhanced user analytics.

Essential device management—such as game selection and result tracking—is a standard feature of connected active training devices and lies outside the scope of this discussion. Instead, we focus on defining and executing new, customized games, which are critical for supporting user engagement and delivering tailored training experiences. These game definitions rely on a DSL designed specifically for this context. Each game functions as a program executed on the GCBLE platform, enabling flexible and customizable gameplay.

3.1. Device Design

Designing a DSL requires a thorough understanding of the system’s functional requirements and hardware limitations. To establish a foundation for the DSL design, we first examine the basic architecture of the GCBLE hardware.

The system hardware architecture is illustrated in Figure 2 and consists of the following components:

• ControlBoardBLE: The main motherboard (highlighted in orange) serves as the system’s central hub. It facilitates communication between all the connected components, including sensors, buttons, and the display, and incorporates the BLE module.
• Buttons: Physical buttons (represented as a white box) provide user input to the system. Connected directly to the ControlBoardBLE, the board includes two buttons: one for power on/off and another to select the next game.
• SwitchGlow Sensors: Multiple sensors, arranged in two rows and labeled as SwitchGlow X-Y (where X denotes the row number and Y the sensor number), operate bidirectionally and communicate with the ControlBoardBLE in a daisy-chain configuration. Each sensor includes a Hall sensor for puck detection and a red-green-blue light-emitting diode for light indication.
• Display: An onboard six-digit digital display, connected to the ControlBoardBLE, that provides feedback to the user about the game status.

3.2. System Architecture

Integrating BLE connectivity expands the system’s capabilities, enabling its use by independent applications tailored for players and coaches. These applications may include mobile apps for real-time performance tracking, training session management, progress visualization, or personalized feedback delivery.

The system architecture of the GCBLE platform, depicted in Figure 3, illustrates interactions between its key components:

• Game changer BLE: Represented as an orange box, this central hardware device (playing board) is used for gameplay. It interacts directly with the player via its display and lights and with the support application via BLE.
• Player: Represents the user engaging actively in gameplay with a stick. The player interacts with the GCBLE system for real-time feedback and can operate it standalone, without a connected device.
• Support application: Represented as a light blue box, this mobile device application acts as an intermediary between the GCBLE, the player, and the application backend. It facilitates communication, data exchange, and control, enabling game selection, configuration, and data analysis.
• Application backend: Represents cloud services supporting the support application. It provides functionalities such as data storage, analytics, and game management, interacting with the support application and GCBLE via the cloud.
• User: Represents the application user (e.g., a player, coach, or administrator). The user interacts with the system primarily through the support application for configuration, monitoring, and feedback. Often, the player and user are the same individual.

The GCBLE conceptual firmware diagram provides an overview of the system’s functionality, as shown in Figure 4.

The main firmware software components include Select, which handles game selection from the repository via physical buttons or BLE services. The Run/Interpret component, highlighted in orange, is the core module responsible for executing and interpreting the selected game (Figure 4). The players interact with the game through SwitchGlow sensors, while the game state is displayed via board lights, the display, or broadcast to the application. The Upload component, a specialized BLE service, allows new games to be added to the GCBLE system. Game execution can also be controlled through physical buttons or BLE game manager services.

4. Grammarware Design Development for Active Games

The core of grammarware development lies in language design. This section focuses on designing a DSL for creating games on the game-changer hockey stick-handling training system. The DSL defines the rules and mechanics of various games, enabling developers to craft custom gameplay experiences. It encapsulates game logic in a structured, reusable format, enhancing the platform’s versatility and scalability.

4.1. Domain Analysis

A detailed understanding of the domain is essential for supporting and describing various game types effectively. The basic GCC device supports up to 12 distinct games, ranging from simple random light sequences and repetitive light pattern challenges to complex scenarios involving random lights with “mines” (sensors to be avoided).

Based on their dynamic characteristics, these games fall into two primary categories: time-limited and sequence-limited. Time-limited games aim to accumulate as many points as possible within a fixed timeframe using a countdown timer. Sequence-limited games focus on completing a predefined sequence as quickly as possible, typically measured with a stopwatch timer. An additional classification distinguishes between random state selection and sequence-based board state progression.

The following conditions define the game board (or challenge) state:

• Normal: Triggering a sensor advances the game to the next state.
• Start: Similar to a normal state but with a blinking indicator; triggering this state starts the clock.
• Clear: The game waits until all the lights are deactivated before progressing.
• Mine: Involves obstacle lights that, when triggered, either clear the current light, activate an error state (mine), or revert to a clear state.

Game board states may optionally include an autoskip property, defined by a specific duration. This feature rewards players with multiple points for sliding the ePuck back and forth rapidly over a switch, adding a layer of skill and strategy. Each board state also specifies which sensors remain active or inactive.

4.2. GCGame DSL Design

The design and implementation of a DSL typically progress through several phases: decision, domain analysis, design, implementation, and deployment. As outlined in [12,38], multiple factors justify developing a DSL, including task automation, data structure representation, and graphical user interface construction, as discussed in previous sections.

In the domain analysis, conducted informally for this case study, domain concepts and terminology familiar to end-users must be defined [39]. There is a strong relationship between domain concepts and nonterminals in a grammar description. Each terminal represents a concept (e.g., expression, declaration), and a concept’s structure can be described with grammar productions, as is showen in the syntax description using Backus–Naur Form (BNF) in Figure 5. While developing the DSL syntax, it became clear that borrowing from existing languages was impractical, leading us to apply a language invention DSL design pattern [12].

The formal game language description provides modularity and reusability, enabling developers to combine predefined components to create diverse games efficiently. Its clarity and readability stem from well-defined structures and enumerations, reducing ambiguity (Figure 5). It offers flexibility by supporting various game types (e.g., time-limited or sequence-based) through configurable components. It is easily extensible, allowing new states, colors, or mechanics to be added without disrupting the existing functionality. The formal description reduces errors through automated validation, ensures separation of concerns by decoupling game logic from visual elements, and scales well for complex, multi-state games. It promotes standardization, simplifies development and maintenance, enhances debugging and testing through component isolation, and serves as a documentation and communication tool, providing a clear, shared framework for teams.

Figure 6 describes the most popular game from the original GCC system, known as Mode 1 or “Classic.” The objective is to touch as many lights as possible within a 60 s time limit. Each time a light is touched, the next one is selected randomly. Only one sensor is active at a time, and the board has 10 sensors. The game begins with a blinking red indicator to signal the start, and each successful state change (touching a light) awards one point.

Another example, Figure 7, involves a game where multiple lights are active simultaneously. The objective is to switch off all lights in the current set before the system activates the next set. The game state consists of four stages, each presenting a unique challenge. Completing the final sensor state ends the game, with the time taken serving as the player’s result.

The number of sensor states depends on the number of sensors on the playing board, which varies with the board’s size. Defining the physical layout or outline of the sensors ensures accurate interpretation of game states, maintaining consistency and clarity regardless of the board’s dimensions.

4.3. Device Board Outline

To analyze player results, understand gameplay, and plan new games effectively, visualizing the course of an individual game is essential. To this end, we describe the device board outline from Figure 8 formally.

Applying these rules to the board in Figure 8, which contains 10 sensors at various locations, yields Figure 9.

The descriptions from Figure 5 and Figure 10 combine to form a complete representation. Since the system supports multiple game definitions, this capability is reflected in Figure 11.

4.4. GCGame DSL Scalability and Extensibility

Designing game logic with modular grammar rules allows new constructs—such as additional game state types, input conditions, or configuration parameters—to be added with minimal changes to the existing codebase. For example, introducing a new game mechanic (e.g., timed bonus states or combo challenges) requires only extending the grammar with new productions and rules, leaving the existing syntax intact. Using parser generators like ANTLR [40] ensures that grammar updates propagate automatically to the supported target languages (e.g., C++11 (Bjarne Stroustrup/ISO/IEC, Murray Hill, NJ, USA) and Dart 3.2.0 (Google, Mountain View, CA, USA)), maintaining cross-platform consistency. Additional languages (e.g., Python 3.6+ (Python Software Foundation, Wilmington, DE, USA), Java 8+ (Oracle Corporation, Redwood City, CA, USA), or JavaScript-ECMAScript 5/6+ (Ecma International, Geneva, Switzerland)) can be supported in the future by generating parsers from the same grammar definition.

The development of the visual representation tool (Section 5.1) validated the DSL’s extensibility by adding support for game state annotations. A new optional rule, GAME_STATE_ANNOTATION, was incorporated, requiring only a minor grammar extension and minimal interpreter updates, demonstrating the DSL’s flexibility and ease of evolution. Parsers for the firmware (C++) and visualization tool (Dart) were generated from the same grammar definition.

Table 2. Lines of code comparison between parsers for GCGame v1 and v2.

Programming Language	v1	v2	Difference
C++	2133	2222	89
Dart	1296	1355	59

compares the lines of code generated by ANTLR (version 4) for two versions of the GCGame project: v1 (without state annotation support) and v2 (with state annotation support) in C++ and Dart. The increase in code size reflects the extended DSL features and grammar enhancements in v2. Without grammarware, this additional code would require manual development and maintenance.

These results confirm that the GCGame DSL is easily extensible and well-suited for agile, cross-platform development. The final language specification is defined in Figure 11.

4.5. Program Execution

GCBLE game execution is tied to player activity, where higher skill and engagement levels correlate directly with improved outcomes. Leveraging grammars augmented with attributes enables automated generation of evaluators [41,42].

Games defined in GCGame are either loaded onto the ControlBoardBLE system via BLE or retrieved from the system firmware. The game execution process is managed by the ControlBoardBLE system (Figure 4), which monitors user inputs, updates the game state, and provides real-time feedback continuously (Algorithm 1).

The system operates as follows:

• Initialization: The system initializes the game state using a predefined default game (defaultGameID) from the set of available games.
• Event handling loop: The system reads input events continuously from the buttons, sensors, and BLE commands.
• Event processing:
  • If the event is a new game selection (NewGame), the system reinitializes the game state with the selected game ID (newGameID).
  • If the event is a sensor activation (SensorTriggered), the system updates the current game state (gameSession).
• System state update: If a game state change is detected (StateChanged), the system updates the output components, including the display, LEDs, and BLE broadcast.
• Game lifecycle management: If the game reaches its termination condition (IsSessionComplete), the system resets the game state for a new iteration.

Algorithm 1 Main Game Loop

Require:  defaultGameID: Identifier of the default game 1: games: List of available game definitions 2: buttons, sensors, BLE: Input sources Ensure:  Real-time handling of game logic, input processing, and output updates 3: gameSession←Init(defaultGameID, games) 4: while true do 5:       event ← ReadInput(buttons, sensors, BLE) 6:       if event = NewGame then 7:             gameSession ← Init(newGameID, games) 8:       else if event = SensorTriggered then 9:             UpdateSession(gameSession) 10:     end if 11:     if StateChanged(gameSession) then 12:           UpdateOutput(display, LEDs, BLE) 13:     end if 14:     if IsSessionComplete(gameSession) then 15:           RestartSession(gameSession) 16:     end if 17: end while

An interpreter-based implementation [12] ensures continuous monitoring of user interactions and sensor inputs, dynamic game state updates, and real-time feedback delivery via physical and wireless interfaces.

5. Grammarware Use Cases

Using support tools—ranging from visual editors to resource management systems—is standard practice in modern video game development. Some of these tools are integrated directly into advanced game engines, while others require manual implementation. AVG development presents similar needs, particularly when dealing with configurable input devices and real-time feedback. In this section, we present three use cases where grammarware offers greater flexibility and extensibility compared to traditional development approaches.

5.1. Visualizing Gameplay Defined with GCGame DSL

The development of the GCBLE, from its initial design stages to final active tuning, necessitates the cooperation of developers, players, and coaches. This collaborative structure enables rapid prototyping and a largely independent development cycle.

To lower the barrier to using the GCGame DSL further, we developed a dedicated visualization and editing tool that provides a graphical representation of game logic defined through DSL programs. This tool parses DSL programs and presents each game state visually on a grid-based interface, enabling an intuitive understanding of the game flow and spatial structure. Users can click on visual elements to reveal or edit associated DSL constructs, making the link between code and gameplay more tangible. The editor supports real-time updates, syntax validation, and inline tooltips to guide novice users through editing.

Program from Figure 9 contains nearly all the information required to generate a visual representation of the playing board. Furthermore, the game state descriptions provided in Figure 6 and Figure 7 include details about the statuses of the SwitchGlow sensors. Figure 12 shows the visualization of program from Figure 7.

Transitioning from game board state visualization to an interactive editor was a natural progression in the development process. By incorporating standard functionalities such as move, delete, add, and edit, the editor became a powerful tool for designing and modifying game states. The edit functionality, in particular, allows users to customize light colors and configure parameters such as game state type (e.g., normal, clear, or mine) and duration.

The tool was initially developed to facilitate communication between domain experts (coaches and advanced players) and developers, especially given the project’s asynchronous and geographically distributed nature. Coaches could inspect and review games by visualizing their structure, discuss specific aspects collaboratively, and provide developers with precise feedback. The most commonly used feature was the “simulate gameplay” function, which enabled coaches to follow the game flow visually, with next and previous functionality.

While the editor includes editing capabilities, this functionality was disabled for coaches temporarily, as it had not yet undergone full testing. Despite this limitation, early user feedback was overwhelmingly positive. The coaches appreciated the ability to visualize games and compare variations efficiently, which enhanced their understanding and input quality significantly.

Expanding the tool’s functionality for coaches is planned for future development. As the product is still in a testing phase and undergoing rapid iteration, features are being introduced incrementally. Given the diversity of the coaching group—ranging from younger, tech-savvy individuals to older users with limited technical background—we plan to roll out additional features gradually to ensure accessibility and usability for all.

Using Grammarware simplified data exchange between the visualization tool and the GCBLE system significantly, as both games and system logic are defined using a shared DSL. This common representation ensured consistency and reduced ambiguity during development and communication.

Furthermore, the DSL enabled the automatic generation of parsers for programming languages, including C++ (version C++11) for embedded systems and Dart (version 3.2.0) for the visual tool implemented in Flutter (version 3.16.0).This facilitated the creation of tested and consistent code across different development projects and platforms, improving maintainability and reducing the likelihood of implementation errors. The grammar-driven approach ensured that the same game logic could be interpreted uniformly by both the embedded device and the visualization/editor tools, streamlining integration and accelerating the overall development workflow.

5.2. Configuring GCBLE with GCGame DSL to Act as a Mobile Game Controller

With GCBLE and its BLE communication services, every in-game event is broadcast, enabling direct use of these events as inputs for external video games (Algorithm 1). This setup supports a grammarware-based approach, positioning the system effectively as controller middleware. Instead of implementing separate features for controller functionality, the existing DSL defines controller behavior in a structured and consistent manner. This approach ensures that the controller logic remains well-defined, reusable, and easily configurable. Each sensor functions as a virtual controller button, with the additional capability of assigning distinct colors to individual sensors.

For demonstration, we developed a prototype IceHockey video game for mobile devices (Figure 13) [43].

The game was created using the Flame game engine (version 1.7.3), which is built on Flutter and supports various mobile platforms [44,45]. This is a runner-style game where the goal is to skate from start to finish. The player must avoid obstacles by moving left, right, or jumping while collecting as many gems as possible.

The IceHockey game interprets board game states as commands, which are transmitted to the mobile device via BLE. This integration allows the physical game board to act as a remote controller, creating a seamless and interactive gaming experience.

At the beginning of the game, the IceHockey video game sends controller definitions to the GCBLE system as a program (Figure 14) and waits for the player to start the game. The player initiates gameplay by moving the ePuck over the start state, which triggers the video game character to begin moving. The player then controls the mobile screen character by interacting with specific board states: touching the red light triggers a left move, the green light triggers a right move, and the violet light triggers a jump.

Configuring GCBLE as a remote controller using the GCGame DSL enables a wide range of video games to incorporate the active components of the GCBLE system. This approach allows developers to create AVGs that can be controlled by the GCBLE system, providing a unique and engaging gaming experience.

5.3. Procedural Game Generation with GCGame DSL

Randomness is an essential aspect of game design, particularly in training scenarios, as players can memorize fixed sequences quickly, either cognitively or through muscle memory [46,47]. To maintain engagement and prevent repetitive patterns, variability must be introduced into the gameplay.

Generating random games with n game board states and m lights is straightforward. However, the challenge increases significantly when we introduce more complex constraints, such as defining the game’s intensity based on the minimal distance the ePuck must travel. In this scenario, the distance is determined by the Euclidean distance between the current sensor and the next sensor light in the sequence, calculated from their respective sensor positions. For instance, the distance between sensor 1 and sensor 8 can be computed as the Euclidean distance between the coordinates $(10,10)$ and $(100,30)$, as illustrated in Figure 8. This approach adds a layer of complexity, requiring precise calculations and strategic placement of lights for every game board state to ensure the desired gameplay intensity.

Searching for game board states that satisfy specific requirements while adhering to predefined constraints and objectives represents an optimization problem.

5.3.1. GameDistance: Optimization Problem Definition

The GameDistance combinatorial optimization problem is defined in collaboration with hockey coaches who have prior experience using the original GCC system. Their primary objectives include controlling three aspects of the training game: game duration, puck movement range, and the degree of randomness in the sequence of actions.

Game duration can be specified either by a time limit (in seconds), or by the number of board states, denoted as n. Since time-based games are already implemented in the GCC system and have been replicated in the new GCBLE platform (to ensure the comparability of results), we focus here on the board-state-based definition.

A state $s_i$ in the GCGame DSL consists of sensors statuses, where the active state is defined by the illuminated lights, based on the game board’s physical layout.

The puck movement range is quantified as the sum of Euclidean distances between consecutive states in a sequence:

$$D_{actual}\left(s\right)=\sum _{i=1}^{n-1}dist(s_i,s_{i+1})$$

where $s_i$ and $s_{i+1}$ are consecutive board states, and $dist(·,·)$ denotes the Euclidean distance between the illuminated light positions of those states defined in the GCGame DSL.

The optimization goal is to find a sequence of states s of length n such that the total puck movement distance is as close as possible to a predefined target distance. The fitness function is defined as the absolute difference between the actual puck movement range and the coach-defined target distance:

$$f\left(s\right)=\left|D_{actual}\left(s\right)-D_{target}\right|$$

The objective is to find the sequence s that minimizes the fitness function $f\left(s\right)$.

The target distance $D_{target}$ reflects the intended intensity or difficulty level of the drill. It is bounded between the minimum and maximum possible distances between lights, multiplied by the number of states:

$$D_{target}\in \left[n·d_{min},n·d_{max}\right]$$

To simplify configuration for domain experts, the target distance may also be expressed as a percentage of the maximum possible total distance, allowing intuitive control over drill difficulty.

5.3.2. Optimization Method for the GameDistance Problem

For the optimization of the GameDistance problem, various optimization algorithms can be employed, such as Evolutionary Algorithms (EA), Random Search (RS), Monte Carlo Tree Search (MCTS), and Simulated Annealing (SA), among others [48,49,50,51].

In our case, RS was selected due to its alignment with the previous system, GCC, which used simple random generation to create game variations. Since the problem required specific recombination operators, we chose the genetic algorithm (GA) from the EA group as a more advanced optimization technique that remains straightforward to implement while also offering flexibility for incorporating additional constraints or objectives in future iterations [52,53]. Both selected methods are inherently stochastic, enabling the generation of diverse game variations while adhering to similar or identical constraints.

GA Recombination Operators

Stochastic optimization algorithms require well-designed operators to explore the search space effectively and exploit high-quality solutions [48,52].

• Mutation operator: For exploration, we use a mutation operator primarily, controlled by a mutation probability $p_m$. A random number $r\in [0,1]$ is generated for each candidate solution in the population. The mutation operator is applied if $r<p_m$. The mutation operator modifies the current state by selecting a new challenging light position randomly, based on the predefined board outline configuration.
• Crossover operator: The crossover operator is used for exploitation. We used a traditional two-point crossover, selecting two candidate solutions randomly from the population based on $p_c$ and random cutting positions based on n, and swapping the subsequences between them.

5.3.3. Experiment

The experiment aims to generate games consisting of 150 game board states using the board layout defined in Figure 8 and the board definition program outlined in Figure 9. The evaluation includes two optimization scenarios: one requiring a minimum ePuck travel distance of 60 m and another requiring 100 m.

It is common practice to predefine the number of fitness/problem evaluations as a stopping criterion for the GA and RS algorithms. For the experiment, we capped the total number of game evaluations at 3500 to maintain computational efficiency ($0.9\pm 0.4$ s).

For the GA, we used the following control parameters:

• Population size ($pop\_size$): 50
• Number of generations (G): 70
• Mutation probability per game board state ($p_m$): 0.1
• Crossover probability ($p_c$): 0.4
• Elitism size (e): 1

The number of generations can be calculated as $MaxFEs/po{p}_{s}ize$. This setup allowed us to explore the solution search space efficiently while balancing exploration and exploitation [54,55,56], ensuring that the generated sequences met the desired ePuck travel distance constraints.

The results of a typical run, where we monitored the progress of the best solution (convergence), are shown in Figure 15 and Figure 16. Since we are working with stochastic algorithms, we repeated the experiment 100 times to ensure statistical reliability. The results are presented in

Table 3. Average distance error ($\mu \pm \sigma$) for 100 runs.

Method	60 m	100 m
RS	$82.1\pm 14.2$	$283.4\pm 98.3$
EA	$0.1\pm 1.3$	$0.1\pm 0.9$

.

A two-sample t-test assuming unequal variances was conducted to compare the distance errors between the GA and RS methods for both the 60 m and 100 m problems (Table 3). In each case, the difference in means was found to be statistically significant, with $p<0.001$, using a significance level of $\alpha =0.05$. These results confirm that the GA outperforms RS in terms of both accuracy and consistency.

Defining problems through DSL constraints provides the flexibility and extensibility needed for evolutionary optimization to generate games, demonstrating the power of a grammarware-based approach.

6. Discussion

The field of AVG development continues to grow in relevance due to increasing societal emphasis on physical activity and the ongoing convergence of sports and interactive technologies. This work addresses the design and implementation of an AVG platform focused on hockey stick-handling, demonstrating how grammarware can serve as a foundation for building configurable and extensible sensor-driven systems.

The development of such systems involves multiple stakeholders, including developers, designers, and domain experts. Supporting their collaboration requires a clear separation of concerns, structured communication, and tools that reduce reliance on manual coding. A grammarware-based approach meets these needs by introducing a DSL that captures game logic, sensor interaction, and timing behavior in a formal and modular way.

This work demonstrates four main contributions that leverage grammarware principles. First, the DSL enables platform-independent descriptions of active games, simplifying maintenance and ensuring consistent behavior across systems. Second, the flexible design of the language allows the system to operate beyond its original scope—for example, acting as a controller for a mobile game without requiring changes to hardware or firmware.

Third, the integration of DSL-defined constraints into the optimization process streamlines procedural game generation. By replacing hardcoded parameters with structured language constructs, the system allows domain experts to express gameplay goals directly, improving both clarity and adaptability. Finally, the implementation and evaluation of the GCBLE system illustrate the practical viability of this approach in a real-world context.

The proposed framework adapts established software engineering principles—including modularity, abstraction, and formal specification—for use in embedded, sensor-integrated applications. Furthermore, the DSL and associated tooling support end-user engagement by enabling visual configuration, simulation, and rapid feedback. This facilitates collaboration between technical and non-technical contributors, reducing development overhead and enhancing the overall design workflow.

Challenges and Considerations

Despite the numerous advantages of using DSLs [57], there are also some challenges and considerations. One of the main difficulties is that developing a DSL is demanding and requires extensive knowledge and experience. Additionally, it traditionally required a significant amount of time and effort to develop an effective DSL, although this is less critical today with the use of advanced tools and approaches [40,42,58,59,60,61,62,63].

The case study involves end-users—players and coaches—who do not have programming expertise, making the direct use of the DSL impractical. To address this challenge, we developed a visual tool that abstracts away the underlying syntax and enables users to interact with the system intuitively.

7. Conclusions

Grammarware opens new possibilities for AVG development by combining formal software design with real-world training needs. The modularity, cross-platform consistency, and configurability achieved through the use of DSLs provide a foundation for building scalable and adaptable systems. The GCBLE case study demonstrates that grammar-based approaches can simplify development and enhance user experience, even in systems that blend hardware, software, and physical interaction.

By introducing a structured way to define, extend, generate, and visualize interactive gameplay, this work offers a path forward for designing smart training systems that meet the needs of both developers and domain experts.

References yes