ARGo: augmented reality-based mobile Go stone collision game

Abstract

In this study, we present a mobile Go stone collision game based on augmented reality, which we call ARGo, inspired by the traditional Korean board game, Alkkagi. ARGo aims to resolve two main issues: (1) the portability and space constraints of the original Alkkagi and (2) the limited sense of reality due to the touchscreen-based interface of the existing mobile Alkkagi games. To improve a sense of the reality of the game, ARGo provides a gameplay interface similar to the original Alkkagi by recognizing the user‘s hand motion based on AR. Additionally, it provides a customization mechanism for each user to improve the recognition of the hand motion and the strength of the attack considering each user‘s characteristics. Finally, we make the following three main contributions. First, we employ the automata theory to design the game and collision scenarios between stones. Consequently, we can clearly define the complicated states incurred by AR-based motion recognition and collisions between virtual objects. Second, we propose a collision equation based on Continuous Collision Detection tailored to ARGo, i.e., Go stones and their collisions. Through experimental studies, we demonstrate that the collision equation enables the simulation of the exact collision effects. Third, through user experience studies, we verify the effectiveness of ARGo by showing the effects of the functions implemented in ARGo and its superiority over the existing mobile game Alkkagi Mania.

1 Introduction

The results of recent statistics showed that about 6.6 billion people globally use smartphones as of 2022 (Oberlo 2022). With the increasing development of information technology, the use of smartphones has become a part of people‘s lives. The introduction of augmented reality (AR) technology has further accelerated this trend. A 3D smartphone game called Pokémon Go, based on AR, was launched in 2016. Pokémon GO is an innovative game that reached 21 million daily users within 6 days of its launch and is currently considered the most successful AR game (Allan 2016). Starting with Pokémon GO, the AR market has become invigorated. The outbreak of the COVID-19 pandemic accelerates the adoption of AR technology. For instance, OnePlus Nord smartphone (OnePlus 2020) was launched using the AR platform. The increase in the adoption of mobile AR technology to provide more immersive experiences contributes to the growth of the market. According to a market research firm, Grand View Research, the global AR market size was estimated at $25.33 billion in 2021 and is expected to expand at a compound annual growth rate of 40.9% from 2022 to 2030 (Grand-View-Research 2022). As AR has developed rapidly, its impact has been widely shown in various areas such as education (Yu et al. 2022), health-care simulation (Viglialoro et al. 2021), and smart manufacturing (Baroroh et al. 2021).

Alkkagi is a popular Korean board game where players flick Go stones to make their opponent‘s stones out of the Go board. However, a physical board and Go stones impose portability and space constraints; various mobile games have been developed to eliminate these limitations. The main components of Alkkagi affecting the gameplay are the direction and strength of the attack determined by the flicking hand motion imparting on stones intended to attack. However, all existing mobile Alkkagi games require physical touches on touchscreens for them. That is, they allow the user to input the direction and the strength of the attack by dragging the stone intended to attack on the touchscreen. The problem is that touchscreen interactions with stones result in completely different hand motions compared to the original Alkkagi, significantly decreasing the sense of reality of the game. There are diverse ways for integrating AR into traditional board games, utilizing tabletop setups or AR glasses as the primary interfaces. Nowadays, with the explosive growth of mobile devices, the adoption of AR in the mobile environment becomes more popular. In particular, recently, traditional board games have been developed as mobile games providing AR-based environments. This implies that AR has the superiority in enhancing usability (Nilsen and Looser 2005).

In this study, we introduce ARGo, a Go stone collision mobile game based on AR, inspired by the popular Korean board game Alkkagi. ARGo aims to resolve the following two main issues: (1) the limited sense of reality due to the touchscreen-based interface of the existing mobile Alkkagi games and (2) the portability and space constraints of the original Alkkagi. To improve a sense of the reality of the game, ARGo first provides a gameplay interface similar to the original Alkkagi by recognizing the user‘s hand motion based on AR. For this purpose, with the recognition of the palm and hand frames, ARGo recognizes the hand gestures, which are the core actions required in Alkkagi, providing a better sense of reality than the existing touchscreen-based mobile games. Second, we provide a customization mechanism for each user to improve the recognition of the hand motion and the strength of the attack considering each user‘s characteristics. We adjust the criteria for detecting the hand motion and the sensitivity of strength of the attack for each user.

We summarize our contributions in the following threefold:

• (1) We employ the automata theory to design the game and collision scenarios between stones. Consequently, we can clearly define the complicated states incurred by AR-based motion recognition and collisions between virtual objects.

• (2) We propose a collision equation based on Continuous Collision Detection tailored to ARGo, i.e., Go stones and their collisions. Through experimental studies, we demonstrate that the proposed collision equation enables the simulation of the exact collision effects.

• (3) Through user experience studies, we verify the effectiveness of ARGo by showing the effects of the implemented functions for ARGo and its superiority over the existing mobile game Alkkagi Mania, which are confirmed by the statistical tests.

The remainder of this paper is organized as follows. In Sect. 2, we describe previous related studies. In Sect. 3, we describe the background of this study. In Sect. 4, we present automata-based game design and collision scenarios. In Sect. 5, we present collision equations for the Go stones. In Sect. 6, we describe the design and implementation of ARGo. In Sect. 7, we present the results of the user studies and experiments. In Sect. 8, we provide concluding remarks and discuss future studies.

2 Related work

2.1 Board games with augmented reality

Due to the portability and space constraints of traditional board games, their mobile version games have been widely developed. For reproducing their sense of reality, supporting interactions between physical and virtual objects is an essential factor. AR has been adopted as the solution for it in games. Therefore, applying AR to traditional board games has been actively attempted. Traditional studies usually employed tabletop for digital board games. BattleBoard employed ARToolkit augmented with a webcam to detect a marker (Andersen et al. 2004). Here, the players interact physically with pieces triggering a virtual battle. Tankwar employed a tabletop augmented with a head-mounted display. The players follow other players‘ actions by sharing the same tabletop and manipulating tangible pawns (Nilsen and Looser 2005). ART-Chess was an AR-based chess that employed a camera-supported tabletop for the easier recognition of markers (Rayar et al. 2015). It requires two applications: one for camera-supported tabletops and the other for mobile devices. The player interacts with physical chess pieces, and the results are reflected in the mobile application via Bluetooth. Tilt five adopted AR-based glasses with integrated projectors, which are more flexible compared to previous approaches (TiltFive 2021). However, these approaches had a fatal limitation commonly due to the expensive costs and inconveniences because they require additional hardware for supporting AR.

With the explosive growth of mobile devices, AR-based board games on mobile environments are gaining increased attention. Recently, various board games that only require mobile devices for supporting AR have been developed. Balanced Tower AR (MASC 2015) was an AR-based Jenga game with mobile devices inspired by an original board game. Knightfall AR (A+E Networks 2018) was a simple AR-based mobile board game where the players fight as Knight Templar. ForFour (Hansjoerg Mikesch 2019) was a multiplayer mobile board game based on AR whose goal is connecting four stones. StackAR (Ketchapp 2016) stacked blocks on top of each other in mobile AR-based environments. With the same purpose of these approaches to eliminate the necessity of the additional devices, we design ARGo as an AR-based mobile game to achieve the sense of reality of the original board game by effectively resolving the issues incurred in the interactions between the physical and virtual objects depending on the original game‘s characteristics.

2.2 Motion-based interaction for augmented reality

Some previous studies have utilized AR technology to support the elaborate interactions between users and virtual objects based on the user‘s motion recognition. Kim et al. (2014) provided mid-air AR interaction with everyday life objects. Lv et al. (2015) presented a touchless interactive game in which AR is used to capture gestures with two vision-based wearable devices: (1) A device worn on users‘ wrists or knees and (2) a head-wearable vision device.  Xu et al. (2019) presented the DMove application that provides user interaction with virtual objects by providing AR-based directional walking guidance via head-mounted displays. Salas et al. (2021) proposed a Pong game that detects the players and their movements based on AR. Some research efforts have been performed to apply AR-based motion recognition to existing games. As an example, Fig. 1a shows Fruit Ninja in which players cut fruits by capturing hand movements (Khademi et al. 2014). It works through a leap motion controller, which is shown in Fig. 1b, replacing mouse events in the original version.

To develop AR-based mobile games that provide a convenient interface to the user, it is necessary to capture user actions without additional devices. However, none of the studies above used smartphone cameras in interacting with virtual objects. Instead, they required wearable devices (Lv et al. 2015; Xu et al. 2019; Khademi et al. 2014) or augmented with other devices such as imaging optics depth sensors and projectors (Kim et al. 2014; Salas et al. 2021).

Fig. 1

AR-based game with leap motion. a Fruit Ninja  (Khademi et al. 2014) and b leap motion device  (Reallusion 2020)

In this study, we focus on supporting AR-based interaction with virtual objects only equipped with a smartphone camera. As a result, we show that our touchless AR-based motion recognition can significantly improve the sense of reality compared to the existing touchscreen-based mobile game.

2.3 Collision detection

An elaborate simulation of collision detection between objects is essential for reproducing the sense of reality of the original Alkkagi. Traditionally, the overlaps between objects have been checked with a periodic time interval and their collisions have been detected by a constant frequency, which we call Discrete Collision Detection. This approach was simple and effective when we need to detect the collision itself while the objects are moving slowly. However, some collisions could be missing when the objects move fast because the consecutive frames may not catch the collision. Furthermore, because each collision affects the subsequent processing, its results become incrementally different from our expectations.

To resolve the limitation of Discrete Collision Detection, Redon et al. (2002) presented a Continuous Collision Detection method. Continuous Collision Detection checks collisions while restoring the continuous paths between two discrete timestamps. If the objects have simple shapes and motions, Continuous Collision Detection is usually performed by restoring the previous collision point. Otherwise, it iteratively checks the collision for the objects until the distance between them is close enough to be considered a collision. Virtual reality-based applications require fast and accurate detection of a collision between virtual objects. We note that diverse Continuous Collision Detection algorithms have been proposed for the virtual objects they focus on. For example, Redon et al. (2004) proposed an interactive Continuous Collision Detection algorithm for the articulated model, between a moving avatar and the surrounding virtual environment. Zhang et al. (2006) proposed Continuous Collision Detection algorithm for the moving polyhedral model. Ding et al. (2019) proposed Continuous Collision Detection for the haptic rendering of deformable objects, handling collisions between the proxy sphere and triangle meshes. These indicate that we also need to devise our own Continuous Collision Detection algorithms focusing on Go stones and their collisions.

In ARGo, our target objects are circle-shaped while they move in a linear movement. Accordingly, we propose a collision equation to support Continuous Collision Detection by restoring the exact collision point, which will be described in Sect. 5.2. We present its effectiveness through the user studies and experiments, which will be described in Sect. 7.2.1.

2.4 Game design based on automata theory

Game design based on the automata theory contributes to the removal of ambiguities by complex interactions occurring in the game. Many studies have employed automata theory for the game design and demonstrated its effectiveness (Qureshi et al. , 2012; Jamil et al. , 2016; Ali et al. , 2019), designed arcade games based on automata theory. To design various levels in the games, they used deterministic finite-state automata (DFA) and non-deterministic finite-state automata (NDFA). Jamil et al. (2016) designed a runner game “Hungry Bird” using a finite-state machine, Mealy machine, and observed that the designed results become more understandable and intuitive. Ali et al. (2019) designed a multiplayer game, Ludo, using DFA and NDFA, which resulted in bug reduction, high accuracy, and efficiency in the interaction of multiplayer. In this study, we employ automata theory for clearly designing the game design and collision scenarios, which involve the users and virtual objects and require complex interactions between them.

3 Background knowledge

3.1 Alkkagi board and mobile games

In this study, we aim to verify the superiority of ARGo compared to the original Alkkagi board game and an existing mobile game based on a touchscreen. Alkkagi is a popular Korean board game that is played on a Go board with Go stones. Figure 2a shows a screenshot of the Alkkagi board game. Initially, each player places the same number of stones on the board and shoots their stones with a two-finger flicking motion, usually using the thumb and index fingers. The player who makes all of their opponent‘s stones out of the Go board wins. The main constraints of the board game are portability and space because it requires the Go board and Go stones. As a result, mobile touchscreen-based games of Alkkagi were introduced.

There have been various mobile Alkkagi games in Google PlayStore, and we analyzed the features of the top 3 games. To provide realistic play experiences in a mobile game, we need to control the direction and strength of the attack by “flicking” so as to be similar to the original Alkkagi. To do this, we note that all of the existing mobile games require touching the screen. Figure 2b shows a screenshot of the user interface of the top 1 game Alkkagi Mania (mobirixsub 2013), which has been downloaded more than 1 million times. To adjust the direction of the attack, the stone was pulled to the opposite side of the intended direction. In addition, to mitigate the confusion about the direction, an arrow was employed. The other two games, which have been downloaded more than 100 thousand times, allow the users to adjust the direction by simply dragging the stones in the intended direction. All three games adjust the strength of the attack according to the length of the finger drag. In summary, they require the drag and touch on the screen to control the direction and strength of the attack. We note that, although they exclude the inconvenience of carrying the board game and Go stones, interaction with stones based on the touchscreen is completely different from that of the original Alkkagi, decreasing the sense of reality of the game.

ARGo aims to complement the shortcomings of both the original Alkkagi and mobile games. That is, ARGo resolves the issues of portability and space constraints compared to the original Alkkagi. At the same time, it resolves the decreased sense of reality of touchscreen-based mobile games that have a completely different mechanism for adjusting the direction and strength of the attack. ARGo offers a hand motion-based attacking mechanism similar to that of the original Alkkagi by recognizing the user‘s hand motions using AR techniques, which results in increasing the sense of reality. To show its effectiveness, we will provide the comparison of our touchless approach based on AR for the mobile Alkkagi game with the existing touch required approach in Sect. 7.

Fig. 2

Alkkagi board and mobile games. a Alkkagi board game and b existing mobile game, Alkkagi Mania (mobirixsub 2013)

3.2 Google MediaPipe

In this study, we use Google MediaPipe to track the user‘s hand motions (Lugaresi et al. 2019). We note that, while the previous other technologies for tracking hand motions have been operated on high-performance computers, Google MediaPipe supports it even on mobile devices. Figure 3 shows two behavior examples captured by MediaPipe. Figure 3a shows that the landmarks of the hand are recognized; Fig. 3b shows that the gestures can be recognized based on the topological relationships of the landmarks. In this study, by utilizing the landmarks of the hand recognized by Google MediaPipe, we capture the attachment and detachment between fingers to determine the direction and strength of the attack. Hence, we determine the speed of the attacking stone using the distance and time between the location of the attached fingers and the location after detaching the fingers, and its direction by capturing the player‘s hand motion.

Fig. 3

Examples of MediaPipe operations (Zhang et al. 2020). a Hand motions and b gestures

3.3 The implementation of game boards

In Android Studio, there are various ways to show different views on the screen. In this study, we design the UI for ARGo using both native XML and Android graphics, which are provided by default. Native XML is the most basic way to create a layout. It has the advantage of minimizing the memory load, but a disadvantage is that it cannot support dynamic conversion of the layout. Therefore, in this study, we implement a basic game board using native XML, and additionally, use Android graphics to support the dynamic conversion, resulting in a reduced memory overhead while achieving the implementation goals. With Java runtime, Android graphics can support the dynamic conversion of the game board. Specifically, after creating a view with Native XML, we can place images or objects on the view with Android graphics.

4 Game design based on automata theory

ARGo has a high-level complexity in the interactions because it involves not only players but also the virtual objects and it captures player‘s hand motions based on AR for gameplay. Furthermore, we need to clearly define the states before and after the collision of the stones to produce realistic collision effects.

4.1 Game scenario design

ARGo requires information that needs to be maintained for each state. In ARGo, each player tries to make the other‘s stones out of the board. To determine which player wins the game, we need to memorize the number of stones inside the board in every state. To maintain this information according to the changed states, we adopt a PushDown Automaton (PDA) (Hopcroft et al. 2001), to design the game scenario of ARGo.

• (1) Description of input alphabets:

  A pair of stone counts (nBS, nWS) defines the number of remaining black and white stones, respectively, in each state. When the game starts, it is initialized as (n, n), and if at least one element of the pair becomes zero, the game ends. According to the player‘s action, each stone can be removed from the board, and (nBS, nWS) is updated.

• (2) States for the ARGo game scenario are defined in Table 1.

Table 1 States for ARGo game scenario

Figure 4 shows the state transition of ARGo‘s game scenarios designed based on PDA. When the user starts the game, the state is transferred from START GAME to LOAD STONE. When all players‘ stones are pushed into memory, the state is transferred to MOVE STONE, which indicates a state where the stone is moved by the player‘s attack or by the collision of stone. In this state, when the stone is out of the board, the state is transferred to REMOVE STONE, and the stone count is updated. Each transition to REMOVE STONE deals with one stone removal and it is repeated until all the stone removals are completed. Then, it is transferred back to MOVE STONE. When the stone count of at least one player becomes zero, the state is transferred to FINISH GAME.

Fig. 4

State transition for the ARGo game scenario

4.2 Collision scenario design

In this section, we design the collision scenario between stones caused by the players‘ actions. First, we need to define the state transition according to each player‘s hand motions to clearly capture the player‘s actions. Then, we design a collision scenario caused by the hand motions based on non-deterministic finite automaton (NDFA).

4.2.1 State transition according to player‘s hand motions

When a player attacks stones in the original Alkkagi, the thumb and index fingers are attached and then detached during the process to shoot the stone. Therefore, in ARGo, we define the attached and detached states of the fingers to capture player‘s attacking actions. Based on this, we aim to precisely identify the moments these motions occur. While MediaPipe tracks the hand motions of the player in real time, the landmarks of the hand initially fluctuate until they are stably recognized. To wait until it becomes stabilized, we define a threshold to determine the start of the attachment, called the attached criteria. After detecting that the fingers are attached, MediaPipe keeps track of the hand motions. We define another threshold to determine the detachment, called the detached criteria.

After detecting that the fingers are detached, we calculate the moving speed of the stone. For this, another moment after the detachment is required to obtain the difference in the location and time between the two moments. For this moment, we use the right next subsequent frame captured after the detached moment, which is detected by MediaPipe periodically, because the action for flicking the fingers is sufficiently continued during the time interval.

The player‘s landmarks of the hand are captured periodically by Google MediaPipe in every frame. Based on the captured landmarks, the user‘s hand motions are recognized. The detailed process for this will be described in Sect. 6.3. In this section, we present automata-based state transitions for clearly defining the user‘s hand motions.

• (1) Description of input alphabets:

  $\{ac,dc\}$ defines the attached and detached criteria for players, respectively. We use a fixed value of dc for the players because we can clearly capture the detection for every user by a fixed value. However, ac can be different for each player. Thus, we customize ac for each player, which will be explained in Section 6.4. $\{d_{\textrm{current}}, d_{\textrm{detached}}\}$ defines the distances of the player‘s fingers captured in every frame. The current distance between two fingers captured in every frame is defined as $d_{\textrm{current}}$. If $d_{\textrm{current}}$ captured after the attached state becomes greater than dc, we define this $d_{\textrm{current}}$ as $d_{\textrm{detached}}$. Because of the periodic image processing by Mediapipe, the detached state could be detected when the distance between fingers is longer than dc. Therefore, we use $d_{\textrm{detached}}$, instead of dc, to calculate the difference to $d_{\textrm{current}}$ of the next frame, which will be used to calculate the strength of the attack.

• (2) States for player‘s hand motions are defined in Table 2.

Table 2 States for the player‘s hand motions

Figure 5 shows the state transition of recognizing the player‘s hand motions designed based on NDFA. In INIT, while $d_{\textrm{current}}$ is greater than ac, it stays in INIT; when it becomes shorter than ac, the state is transferred to ATTACHED. When it is shorter than dc, it stays in ATTACHED; when it becomes longer than dc, the state is transferred to DETACHED, and $d_{\textrm{current}}$ is regarded as $d_{\textrm{detached}}$. When $d_{\textrm{current}}$ captured in the next frame is shorter than $d_{\textrm{detached}}$, which is the criteria for determining further state transition, the state is transferred to ATTACHED; when it is longer than $d_{\textrm{detached}}$, the state is transferred to FINISH. Based on the distance and time differences between DETACHED and FINISH, the strength of the attack is calculated, and the player‘s motion recognition scenario ends.

Fig. 5

State transition for the player‘s hand motions

4.2.2 State transition according to the stone movement

MediaPipe periodically processes image frames in the mobile application. Accordingly, we also detect the stone‘s movement based on the MediaPipe‘s processing frequency. When the collision between stones occurs during the movement, the consecutive stone collisions after the first collision detection would be detected by the subsequent image frames. This means that a collision state could be continued in the upcoming next frames while the stones are overlapping each other, generating a significant difference in the collision effects. Therefore, to prevent consecutive and unnecessary collision detection and correctly calculate the collision effects, we need to clearly define the transition state of the stones before and after the collision. That is, after detecting the first collision, we need to distinguish the consecutive collisions from the first one by considering the current state.

The state transitions for the stone movement need to be managed from when the stone begins to move, which is initiated by the player‘s motions explained in Sect. 4.2.1, to when the stone and the collided stones are finished moving. The state is continuously managed and updated according to the distances between the attacking stone and the other stones.

• (1) Description of input alphabets:

  $\{currentPos, targetPos\}$ defines the current position, currentPos, and the target destination position, targetPos, of the moving stone, which are described as $(x_{\textrm{current}},y_{\textrm{current}})$ and $(x_{\textrm{target}}, y_{\textrm{target}})$, respectively. currentPos is updated in every frame. targetPos is calculated based on the strength of the attack. Here, distanceToTarget is defined as the distance between currentPos and targetPos. It is updated in every frame to check if the stone reaches its target position. In addition, to check if the moving stone collides with the other stones in the board, we update the distance between currentPos of the moving stone and the current position of each other stone. We process each state transition of the stone sequentially. Therefore, we calculate the shortest distance between the moving stone and other stones, which is defined as distanceToOther, to detect the collision with the other stones. If we detect the collision, the collided stone starts a new state transition for the stone movement.

• (2) States for the stone movement are defined in Table 3.

Table 3 States for the stone movement

Figure 6 shows the state transition for the stone movement that is designed based on NDFA. STOP is the initial state. The player‘s attacking action initiates the attacking stone‘s state transition from STOP to MOVE. In MOVE, distanceToTarget is updated in every frame. If distanceToTarget is equal to or shorter than the diameter, its state is transferred from MOVE to STOP. distanceToOther is also updated in every frame. If distanceToOther is equal to or shorter than the diameter, the attacking stone‘s state is transferred from MOVE to COLLIDE. Here, the attacked stone starts a new state transition, i.e., from STOP or MOVE to COLLIDE. When all stone states become STOP, the state transition for the stone movement ends, waiting for the next state transition according to the player‘s motion.

Fig. 6

State transition for the stone movement

5 Collision equations

In this study, during the collision between stones, we focus on only their interactions. Therefore, in designing the collision equation between them, we do not consider the friction of the board and the resistance of the air, which are orthogonal issues.

The most important aspect of ARGo is the realization of collision effects between Go stones. According to MediaPipe‘s working frequency for captured image frames, stone movement is calculated periodically, naturally leading to adopt Discrete Collision Detection for the collision equation, which will be explained in Sect. 5.1. However, it may incur collision errors due to the limitation of Discrete Collision Detection, which fails to detect the exact collision point. Therefore, we enhance the collision equation by restoring the original collision point to achieve Continuous Collision Detection, which will be explained in Sect. 5.2. As the previous studies in Continuous Collision Detection, (Redon et al. 2004), (Zhang et al. 2006), (Ding et al. 2019), which proposed the algorithms for the objects they focused on, we also propose a dedicated collision equation for our target virtual objects and their movements.

5.1 Collision equation with discrete collision detection

Let us suppose that we have two Go stones, $C_{0}$ and $C_{1}$, as shown in Fig. 7, and that one player tries to attack with a stone, $C_{0}$, to another player‘s stone, $C_{1}$. The basic concept for calculating the movements of $C_{0}$ and $C_{1}$ after the collision is as follows: when $C_{0}$ (x, y), collides with $C_{1}$ $(x_{1}, y_{1})$, at $C_{0}^{\prime }$ $(x_{0}, y_{0})$, $C_{0}$ moves into the orthogonal direction of $C_{0}^{\prime }$ and $C_{1}$, and $C_{1}$ moves into the vertical direction of the orthogonal direction. $C_{2}$ would be the destination of $C_{0}$ when $C_{0}$ does not collide with $C_{1}$, $\textbf{v}$ is a vector from $C_{0}$ to $C_{2}$, and $\textbf{s}$ is a vector from $C_{0}^{\prime }$ to $C_{2}$. Here, $\textbf{s}$ is split into $\textbf{a}$ and $\textbf{d}$, where $\textbf{a}$ is orthogonal to the vector from $C_{0}^{\prime }$ to $C_{1}$, which is the direction vector for $C_{0}$ after the collision, and $\textbf{d}$ is the direction vector for $C_{1}$ after the collision. We can calculate $\textbf{a}$ and $\textbf{d}$ by projecting $\textbf{s}$ into $\textbf{a}$ and $\textbf{d}$ by an angle ($\angle {\alpha }$) between $\textbf{d}$ and $\textbf{s}$.

Fig. 7

Movement situation after the collision between Go stones

The detailed processes to calculate the movement of the Go stones are as follows:

• (1) When $C_{0}$ starts to move toward $C_{2}$ along with a vector $\textbf{v}$ whose length is l, which is determined by the player‘s attack strength explained in Sect. 4.2.1. Then, we can obtain a $\theta$, which is a direction angle. $\textbf{v}$ and $C_{2}$ are represented by Eqs. (1) and (2), respectively:

$$\begin{aligned}{} & {} \textbf{v} = l \cdot <\mathrm{{cos}}\theta ,\mathrm{{sin}}\theta > \end{aligned}$$

(1)

$$\begin{aligned}{} & {} C_{2} = C_{0} + \textbf{v} = (x,y) + l \cdot <\mathrm{{cos}}\theta ,\mathrm{{sin}}\theta > \end{aligned}$$

(2)

• (2) When stone $C_{0}$ collides with $C_{1}$ at $C_{0}^{\prime }$, we have two vectors $\textbf{s}$ and $\textbf{b}$ and an angle $\alpha$ between them (where $0 <\alpha \le \frac{\pi }{2}$). We can obtain $\textbf{s}$, $\textbf{b}$, and $\mathrm{{cos}}\alpha$ using Eqs. (3), (4), and (5):

$$\begin{aligned}{} & {} \textbf{s} = \textbf{v} -<x_{0}, y_{0}> =<l \mathrm{{cos}}\theta , l \mathrm{{sin}} \theta> - <x_{0}, y_{0}> \end{aligned}$$

(3)

$$\begin{aligned}{} & {} \textbf{b} =<x_{1}, y_{1}> - <x_{0}, y_{0}> \end{aligned}$$

(4)

$$\begin{aligned}{} & {} \mathrm{{cos}} \alpha = \frac{\textbf{s}\cdot \textbf{b}}{\Vert \textbf{s}\Vert \Vert \textbf{b}\Vert }\nonumber \\{} & {} \quad = \frac{(<l \mathrm{{cos}} \theta , l \mathrm{{sin}} \theta> -<x_{0}, y_{0}> ) \cdot (<x_{1}, y_{1}> -<x_{0}, y_{0}>) }{\Vert<l \mathrm{{cos}} \theta , l \mathrm{{sin}} \theta> -<x_{0}, y_{0}> \Vert \Vert<x_{1}, y_{1}> - <x_{0}, y_{0}>\Vert } \end{aligned}$$

(5)

• (3) Stone $C_{1}$ reaches $C_{1}^{\prime }$ by adding a vector $\textbf{d}$, which is calculated by Eq. (6).

$$\begin{aligned} C_{1}^{\prime } = (x_{1}, y_{1}) + \textbf{d} = (x_{1}, y_{1}) + \frac{\mathrm{{cos}} \alpha \cdot \Vert \textbf{s}\Vert }{\Vert \textbf{b}\Vert } \cdot \textbf{b} \end{aligned}$$

(6)

• (4) Stone $C_{0}^{\prime }$ reaches $C_{0}^{\prime \prime }$ by adding a vector $\textbf{a}$, which is calculated by Eq. (7).

$$\begin{aligned} \begin{aligned} C_{0}^{\prime \prime } = (x_{0}, y_{0}) + \textbf{a} = (x_{0}, y_{0}) + \{C_{2}-((x_{0}, y_{0}) + \textbf{d}))\} \\ = C_{2} - \textbf{d} = (x + l \mathrm{{cos}} \theta , y + l \mathrm{{sin}} \theta ) - \frac{\mathrm{{cos}} \alpha \cdot \Vert \textbf{s}\Vert }{\Vert \textbf{b}\Vert } \cdot \textbf{b} \end{aligned} \end{aligned}$$

(7)

5.2 Collision equation with continuous collision detection

In ARGo, collision detection is the most important feature directly related to the sense of reality of the game. Therefore, we restore the correct collision point to achieve Continuous Collision Detection, and then, correct the collision errors that occurred by Discrete Collision Detection.

The collision equation with Discrete Collision Detection assumes that stone $C_{0}$ collides at exact $C_{0}^{\prime }$. However, in the actual application that works by a periodic frequency, $C_{0}$ could collide at $C_{0}^{\prime \prime }$ as shown in Fig. 8. Hence, in real applications, we cannot identify the exact collision point because of the discrete interval between two consecutive image frames processed by MediaPipe. As a result, Discrete Collision Detection can be caught after the actual collision, decreasing the sense of reality of gameplay. To do this, we restore the collision point detected by Discrete Collision Detection to the original collision point for Continuous Collision Detection.

The detailed processes for Continuous Collision Detection and the corrected equations are as follows:

• (1) When the collision of stone $C_{0}$ is recognized at $(x_{0}, y_{0})$, which is recognized by the MediaPipe operation frequency, we need to correct the position $(x_{0}, y_{0})$ to $(x_{0}^{\prime }, y_{0}^{\prime })$, which is the exact collision position. We have to obtain a linear equation for the moving stone with a direction vector $\theta$, which is represented by Eq. (8). Here, the two positions, the start position (x, y) and the target position $(x+l \mathrm{{cos}} \theta , y + l \mathrm{{sin}} \theta )$, are used to obtain the slope.

$$\begin{aligned} (y_{0}^{\prime } - y) = \frac{y+l \mathrm{{sin}} \theta -y}{x+l \mathrm{{cos}} \theta -x}(x_{0}^{\prime } - x) \end{aligned}$$

(8)

• (2) We can obtain the corrected $x_{0}^{\prime }$ by substituting $y_{0}^{\prime }$ in Eqs. (8)–(9). Here, 2r is the diameter of the stone, and $(x_{1},y_{1})$ is obtained from $C_{1}$. We note that the two positions are obtained by Eq. (9), as described in Fig. 8, where $x_{0}^{\prime }$ closer to x becomes the answer. Then, we can obtain $y_{0}^{\prime }$ by substituting $x_{0}^{\prime }$ to Eq. (8).

$$\begin{aligned} 2r = \sqrt{(x_{0}^{\prime }-x_{1})^{2} + (y_{0}^{\prime }-y_{1})^{2}} \end{aligned}$$

(9)

• (3) With the corrected position $(x_{0}^{\prime }, y_{0}^{\prime })$, we can obtain the corrected destination of stones, which are described as $C_{0}^{\prime \prime \prime }$ and $C_{1}^{\prime }$ in Fig. 8. First, we obtain $\mathrm{{cos}} \beta$, which is the angle between $\textbf{d}$ and $\textbf{s}$, by replacing $(x_{0}, y_{0})$ with $(x_{0}^{\prime }, y_{0}^{\prime })$ in Eq. (5). Then, we perform the same process as in Eqs. (6)–(7) in Sect. 5.1 using $\mathrm{{cos}} \beta$ to calculate $C_{0}^{\prime \prime \prime }$ and $C_{1}^{\prime }$.

Fig. 8

Movement situation after collision between Go stones with correction

5.3 Handling of consecutive collisions

In the previous equations, we deal with a collision between two stones by the action of the player. However, a chain of collisions could occur due to the previous collision. Specifically, we can consider two cases: (1) The collided stone could touch other stones after the collision, and (2) multiple collisions concurrently happens. Our collision equations can be generalized to those two cases. For the first case, there are two possible situations: (1) The touched stone is in the STOP state or (2) in the MOVE state. In both situations, a new state transition by the stone in the STOP or MOVE states is started in the same way. Here, we do not consider the collision equation between two moving stones because they are not frequently occurred. That is, even if consecutive collisions occur in a chain, each collision could be treated in the same manner in a sequence. For the second case, we handle each collision by an independent collision equation at the same time. That is, we process the movement of each stone as an individual thread, respectively, in the implementation.

In Sect. 7.2.1, through the actual experiments, we show the difference of the collision detection point between the two collision equations with Discrete Collision Detection (in Sect. 5.1) and with Continuous Collision Detection (in Sect. 5.2). We also demonstrate that the collision equation with Continuous Collision Detection makes the collision point to the theoretically correct position.

6 Design and implementation of ARGo

6.1 Screen composition and game scenario

ARGo is a mobile game played on a smartphone that implements a realistic board game. Figure 9 shows the screen composition of ARGo. When the application is first to run, the main page, as shown in Fig. 9a, is executed. The “Game Start” button starts the game, the “Customization” button customizes the two finger‘s attached criteria and the sensitivity for strength of the attack, and the “Tutorial” button views a tutorial of the game. The game starts on the screen, as shown in Fig. 9b. During the game, the “Settings” button in the upper left corner pops up the menu to restart the game, as shown in Fig. 9c. When one of the players loses their all Go stones, the game ends, and the result of the game pops up, as shown in Fig. 9 (d). The screen then moves back to the main page.

Fig. 9

Game screen composition of ARGo. a The main screen, b the game starting screen, c the game setting screen, and d the game ending screen

We design the overall flow of choosing the Go stone to be used to attack and deciding the direction and strength of the attack for each user to be realistic considering the original Alkkagi. The main steps of each user in the original Alkkagi are as follows: (1) selection of a Go stone to be used to attack, (2) selection of the opponent‘s Go stone to attack (i.e., the direction of attack), and (3) selection of the strength of the attack. In ARGo, we implement these steps based on AR for maintaining its sense of reality. Figure 10 shows the overall process of selecting the Go stones and determining the direction and strength of the attack. Figure 10a shows the screen before selecting the Go stone. In the first step, to choose a Go stone to be used to attack, the user tilts their mobile phone left or right to actuate the built-in gyro sensor of the smartphone, as shown in Fig. 10b. In the second step, for selecting the direction of the attack, we design an arrow rotated around the selected Go stone. Then, when the user gives their finger movement, as shown in Fig. 10c, we recognize the hand motions. Hence, when the player‘s flicking action is captured by the attached and detached criteria, both the direction and strength of the attack are determined. First, the direction of the stone is determined as the direction of the arrow at the moment the flicking action is captured. Second, the strength of the attack is calculated based on the distance between the fingers and the time taken for the action, as shown in Fig. 10d.

Fig. 10

Overall process of selecting Go stones and determining the direction and strength of the attack. a A step before selecting the stone, b a step of selecting the stone, c a step of selecting the attacking direction, and d a step of selecting the attacking strength

6.2 User interface implementation

We implement a static area fixed on the screen using the native XML and dynamic objects, e.g., Go stones and arrows, using Android graphics. First, through the native XML, we add the static elements necessary for the game to the screen, as shown in Fig. 11a. The yellow square frame indicates Go board. The user‘s remaining time is displayed with the progress bar below, and the number of remaining Go stones is displayed as well. Second, through Android graphics, as shown in Fig. 11b, a Go stone is added to the screen, and the movement and collision of the Go stones are implemented.

Fig. 11

UI implementaiton. a Static elements and b dynamic elements

6.3 Motion recognition

In this section, we describe a method for recognizing the user‘s motions based on the detection of landmarks of the hands from image frames captured by cameras. Figure 12 shows the hand landmarks captured by Google MediaPipe. Based on this, we track the frame and topological information of the hand to recognize the user‘s motions. Here, we assume that the thumb and index fingers are used to flick the stone, which is easily extendable for the case where the other fingers are used. Motion recognition is essential to determine the beginning and the end of the attacking action based on the attached and detached states, as explained in Sect. 4.2.1.

Fig. 12

Hand landmarks and motion recognition (Zhang et al. 2020)

6.4 Customization

The finger appearance and gesture style contacting the thumb and index fingers are different depending on the user. These can affect strength of the attack because they are calculated based on the distance between the attached and detached states between the fingers. In addition, each user has a different position to place their index finger on the thumb to flick, resulting in incorrect recognition of attachment between the thumb and index fingers. Furthermore, considering the target mobile environment, which is a hand-held device, the distance between fingers for recognizing attachment greatly varies depending on the distance between the camera and the fingers. That is, as the camera is closer to the fingers, the distance between the fingers becomes longer. This implies that the attached criteria could be different according to each player‘s style to hold the phone. These differences depending on the players considerably vary the attached criteria suitable for them, leading to failure in catching the player‘s attack intentions (i.e., attachment of their fingers). To effectively handle them, we present a customization mechanism for the users.

Users can customize two factors: (1) the attached criteria and (2) sensitivity for strength of the attack. We provide two methods for customizing each player‘s attached criteria: (1) automatic mode and (2) manual mode. In the automatic mode, the attached criteria is set automatically by the following process. As shown in Fig. 13a, the player‘s motion for the attachment between the thumb and index fingers is captured. Based on 100 captured image frames, the average and standard deviation of the distance between the thumb and index fingers are calculated, and these values are used to customize the range of distances that are in the attached state for the player. We set the confidence level at 99% using a one-tailed test.

However, the corrected image frames could not be sufficient for setting the attached criteria perfectly, especially in a severely fluctuating environment. Because requiring more image frames could be a burden for the users, we additionally provide a manual option that allows users to set the attached criteria manually. In the manual mode, the players can adjust the attached criteria by five-level options representing the strictness of the attachment judgment. The user clicks the “up” or “down” button to adjust the level, as shown in Fig. 13b. “up” makes the attached criteria wider, and the recognition degree of the attached state becomes less strict; “down” works in the opposite way.

Figure 13c shows the screen for customizing the sensitivity for the strength of the attack. The player adjusts the sensitivity for the strength of the attack with five-level options by clicking the “weaker” or “stronger” button based on a default value. Here, the selected value is multiplied in calculating the vector in Eq. (1) of Sect. 5.1. This customization helps users adjust the strength of the attack as they intend.

Fig. 13

Customization. a Automatic customization for the attached criteria, b manual customization for the attached criteria, and c the customization of the sensitivity for the strength of the attack

7 Performance evaluation

To evaluate the effectiveness of ARGo, we conduct both user experience studies and experimental studies. First, we design user experience studies to check (1) the effectiveness of the implemented functions for ARGo and (2) the comparison of ARGo with the original Alkkagi and a mobile game Alkkagi Mania. Second, through the experimental studies, we demonstrate that the collision equation with Continuous Collision Detection resolves the collision errors that occurred in the collision equation with Discrete Collision Detection. We also demonstrate the effectiveness of customizing the attached criteria by measuring the failure ratio of the attacking attempts.

7.1 User experience studies

7.1.1 Study setup

A total of fifteen participants took part in the study, all of whom were college students in their 20s with various majors such as computer science, music, and chemical engineering. We specifically recruited participants who were familiar with mobile environments and had prior experience playing Alkkagi. During the study, participants were exposed to all types of games and were required to complete a questionnaire. Due to their previous experience with Alkkagi, they had no difficulties playing both ARGo and the Alkkagi Mania.

First, participants are provided with the user manual for Alkkagi Mania and ARGo without any intervention. Sufficient time is given for participants to familiarize themselves with the gameplay. Subsequently, participants engage in playing both Alkkagi Mania and ARGo. Prior to playing ARGo, there is a customization period. The order of the games is randomized in each experiment to minimize its impact. All experiments are conducted using the same test device, Galaxy Note 9. There are two types of gameplay: (1) two-user play in pairs and (2) single-user play. For the first type, participants face each other, and the test device is held by the player attempting to attack the stone. For the second type, the participant holds the test device and assumes both player roles. Whenever switching roles, the participant rotates the device 90 degrees. Among fifteen participants, ten individuals participated in the first type while the remaining five engaged in the second type. The study proceeded until the participants achieved a satisfactory understanding of each game. The number of gameplays varied among participants due to differences in play speed. On average, the study duration was approximately 10 min, excluding the time for understanding the user manual. Following the gameplay, participants were required to complete a questionnaire. Each response was rated on a scale of 1–5, with ranges above 3 indicating positive responses.

7.1.2 Difficulty of adaptation

The adaptation difficulty of the game is an important component for the users to start the game. Because ARGo provides a completely different environment based on AR over Alkkagi, we evaluate how easy they adapt to ARGo compared to Alkkagi. To evaluate the adaptation difficulty of ARGo, the following three questionnaire statements are given: (1) selection of the Go stone, (2) selection of the attacking direction, and (3) selection of the strength of the attack, to be answered by five-level ratings from “very difficult (1)” to “very easy (5).”

Figure 14 shows the evaluation results. To avoid ambiguous situations occurring in mobile environments, ARGo provides a different Go stone selection style from Alkkagi. However, it provides a similar attacking action with Alkkagi by recognizing the hand motion based on AR. Considering that ARGo requires learning a different playing style compared to Alkkagi, the results show that ARGo‘s adaptation difficulty is acceptable. Specifically, the average adaptation score is 3.45, which is clearly greater than 3.

Fig. 14

Results for the adaptation difficulty evaluation

7.1.3 Sense of reality

In implementing ARGo, one of the important issues is the achievement of realistic gameplay because it depends on the original Alkkagi board game. We focus on two main factors that significantly affect the sense of reality of Alkkagi. The first factor is the recognition of the hand motion because it determines the direction and strength of the attack. The second factor is the collision effect because it directly affects the results of the game. To confirm its effectiveness, we conduct a sense of reality evaluation by comparing ARGo with Alkkagi Mania.

For the sense of reality, we adopt AR-based hand motion recognition instead of the touchscreen required in the existing mobile games to offer a similar environment to Alkkagi. We also devise a collision equation to preserve a similar collision effect to Alkkagi. We design two questionnaires according to the considered two factors to measure the degree of improvement in the sense of reality compared to Alkkagi Mania. For each factor, we define five-level ratings from “very unrealistic (1)” to “very realistic (5).” We hypothesize for the statistical test as follows: (1) “There is no significant difference in the recognition of hand motion between ARGo and Alkkagi Mania.” and (2) “There is no significant difference in the collision effect between Alkkagi Mania and ARGo.” To confirm whether the questionnaire result is normally distributed, we conducted a Shapiro–Wilk test (Shapiro and Wilk 1965). The result for the first hypothesis indicates that there is a significant departure from normality ($W = 0.813$, $p < 0.01$). Given the normality of the data, we conduct a Wilcoxon signed-rank test. The results indicate a significant difference in the sense of reality (i.e., Alkkagi Mania $(M = 2.6, SD = 0.98)$ and ARGo $(M = 4.27, SD = 0.59)$), with a result ($W = 0$, $p < 0.001$). Additionally, considering the substantial difference in average scores (i.e., 2.6 and 4.27), it is evident that the sense of reality of ARGo in terms of hand motion is significantly superior to that of Alkkagi Mania.

On the other hand, the Shapiro–Wilk test for the second hypothesis indicates no significant departure from normality ($W = 0.935$, $p = 0.334$). Given the normality of the data, we conduct a paired t-test. The results indicate no statistical difference in their collision effects (i.e., Alkkagi Mania $(M = 4.0, SD = 0.92)$ and ARGo $(M = 3.8, SD = 0.77)$), with a result ($t(14) = 0.675$, $p = 0.51$). Considering the average scores (i.e., 3.8 and 4.0), both show a high sense of reality.

7.1.4 The effect of customization

ARGo provides customization for users to adjust their own playing styles. We aim to evaluate the effectiveness of two customization features: (1) attached criteria and (2) sensitivity for the strength of the attack. For the former, the following true–false question is used: “After the customization of the attached criteria, is the player‘s intention for attacking correctly reflected?” For the latter, the following question is used: “After the customization of the sensitivity for the strength of the attack, is the player‘s intention reflected successfully in the actual strength of the attack?” to be answered by five-level ratings from “not reflected (1)” to “completely reflected (5).” Finally, to evaluate the overall satisfaction for customization, the following question is used: “Is the customization satisfied with attacking the stone according to your intention?” to be answered by five-level ratings from “very dissatisfied (1)” to “very satisfied (5).”

Figure 15 shows the evaluation results for the effect of the customization. The results clearly indicate that the customization works as intended in terms of both two customization features. Specifically, in terms of the attached criteria, 100% of the testers responded that stones move naturally after the customization, as shown in Fig. 15a. In terms of the sensitivity for the strength of the attack, the answer “mostly reflected (4)” and “completely reflected(5)” occupy about 73.3%, and the overall average score is 3.67.

Fig. 15

The results for the effects of the customization. a Those for the attached criteria and b those for the sensitivity for the strength of the attack

Figure 16a shows the results for the overall satisfaction of the customization. The results show that the answers of “very satisfied (5)” and “mostly satisfied (4)” occupy 80.0%, and the overall average score is 3.93 as shown in Fig. 16b, indicating that the users can handle the stones more naturally by the customization.

Fig. 16

The results for the overall satisfaction of the customization

7.1.5 The interests

We design questionnaires that measure the interests of ARGo in comparison with both Alkkagi and Alkkagi Mania. Participants are presented with the question “How interested are you?” in relation to pairs of ARGo and Alkkagi, as well as ARGo and Alkkagi Mania. They are required to provide ratings on a five-level scale ranging from “completely not interested (1)” to “completely interested (5).” We hypothesize for the statistical test as follows: (1) “There is no significant difference in interest between ARGo and Alkkagi.” and (2) “There is a significant difference in interest between ARGo and Alkkagi Mania.”

The Shapiro–Wilk test for the comparison between ARGo and Alkkagi indicates a significant departure from normality ($W = 0.827$, $p < 0.01$). Therefore, we conduct a Wilcoxon signed-rank test. The results for the questionnaire are comparable to each other (i.e., ARGo $(M = 4.13,~SD = 0.74)$ and Alkkagi $(M = 4,~SD = 0.75)$), with a result ($W = 18$, $p = 0.78$). Furthermore, 40% of the testers responded that ARGo is even more interesting than the original Alkkagi, which is twice the number of users who responded on the opposite side.

On the other hand, the Shapiro–Wilk test for the comparison between ARGo and Alkkagi Mania indicates no significant departure from normality ($W = 0.898$, $p = 0.088$). Hence, we conduct a paired t-test. The results for the questionnaire indicate a significant difference (i.e., ARGo $(M = 4.2,~SD = 0.77)$ and Alkkagi Mania $(M = 3.47,~SD = 0.91)$), with a result ($t(14) = -2.44$, $p < 0.05$). Based on the average scores, we can conclude that ARGo is significantly more interesting than Alkkagi Mania.

7.1.6 Satisfaction comparison between portability and space constraints over the sense of reality

We evaluate the overall satisfaction of ARGo over the original Alkkagi, considering improvements in portability and space constraints, which are strengths of ARGo, over the reduction of the sense of reality of the game, which is an inherent strength of Alkkagi. The following question is used: "How much are you satisfied with the improved portability and space constraints of ARGo considering the reduced sense of the reality?” to be answered by five-level ratings from “very dissatisfied (1)” to “very satisfied (5).” Hence, users responding with ratings higher than 3 (i.e., 4 or 5) accepted more advantages of ARGo by the improved portability and space constraints considering the lack of sense of reality of the game.

Figure 17 shows the evaluation results of the overall satisfaction. The overall average satisfaction score is 3.73, indicating a clear superiority of the improved portability and space constraints over the reduced sense of reality of the game. Furthermore, 60% of users responded positively, but only 6.67% of the users responded negatively.

Fig. 17

Results for the overall satisfaction of ARGo over the original Alkkagi

7.2 Experimental results

7.2.1 Effectiveness of collision equation with continuous collision detection

For the experiments, we track the positions of stones in every captured frame throughout the gameplay. Whenever a collision occurs, we capture the detected position using both the Discrete Collision Detection and Continuous Collision Detection methods. Subsequently, we calculate the results of the collision equation using collision detection methods for each collision situation. We explore various angles and strengths for collisions, aiming to capture a diverse range of collision situations. As a result, we observed a total of 11 actual collisions.

We confirm the effectiveness of the collision equation with Continuous Collision Detection presented in Sect. 5.2 compared to the collision equation with Discrete Collision Detection in Sect. 5.1. To verify this, we perform two experiments to measure (1) the distance between the attacking and attacked stones when the collision is detected, which should be the diameter of the stone theoretically, and (2) the difference between the final destination positions by the collision equation with each of collision detection methods, Discrete Collision Detection and Continuous Collision Detection. Through the first experiment, we attempt to confirm that the collision detection point by Continuous Collision Detection is the same as the real collision detection point; through the second experiment, we attempt to confirm the actual correction by the collision equation with Continuous Collision Detection compared to that with Discrete Collision Detection.

To verify if the theoretically correct collision detection point and the collision detection point calculated by Continuous Collision Detection are practically equivalent, we conducted an equivalence test, the two one-sided tests (TOST) (Schuirmann 1987), which can be used to demonstrate any effect that is less extreme than predetermined equivalence bound. Considering that the distance between stones is the diameter of the stone (i.e., 90), we set the equivalence bound to 0.01 (i.e., $\Delta _L = -0.01$ and $\Delta _U = 0.01$) because even small differences can have significant impacts after collisions.

Table 4 presents the distances between stones when the collision is detected using each collision detection method. For the Continuous Collision Detection detection point $(M = 89.996, SD = 0.005)$, we conduct a Wilcoxon rank-sum test for each equivalence bound, based on the normality test ($W = 0.624$, $p < 0.05$). There is a significant difference between the correct detection point and the Continuous Collision Detection for both the lower bound ($H_{0} < 89.99$, $W = 28$, $p < 0.01$) and the upper bound ($H_{0} > 90.01$, $W = 0$, $p < 0.001$). Therefore, we conclude that the detection point between the correct detection point and the Continuous Collision Detection is practically equivalent.

Table 4 Distance between attacking and attacked stones when the collision is detected by Discrete Collision Detection and Continuous Collision Detection

We also clearly observe the incorrect collision detection by Discrete Collision Detection because the distance between the stones is less than the diameter of the stone, indicating that they are overlapped. We assume that there is a significant difference in the final destination positions of the stones calculated by the collision equations with Continuous Collision Detection and Discrete Collision Detection, which is measured in the second experiment. Table 5 presents the difference in the target destination position based on each collision detection method. Considering the normality of the data with a Shapiro–Wilk test ($W = 0.759$, $p < 0.01$), we conduct a Wilcoxon signed-rank test. The test results reveal a significant difference ($W = 66$, $p < 0.001$), indicating that there is a statistically significant distinction in the target destination position between the Discrete Collision Detection and Continuous Collision Detection methods. This indicates that the final impacts of the collision detection on the game by the difference confirmed in the first experiment. Considering that the height and width of the board are 1728 and 1080, respectively, and the average difference, i.e., 63.56, in target destination position, collision equation with Discrete Collision Detection can generate a completely different result from the actual collision. Therefore, we note that the collision equation with Continuous Collision Detection significantly improves the sense of reality of the game because the effects of the stone‘s collision are similar to those of the original Alkkagi.

Table 5 Difference of target destination position between the collision equations with Discrete Collision Detection and Continuous Collision Detection

Figure 18 shows the actual collision situations as the case study to show the difference between the collision equations with Discrete Collision Detection and Continuous Collision Detection. We classify the collision situations according to the angle difference degree between $\textbf{d}$ and $\textbf{s}$ and the strength of the attack into four cases. Figure 18a and b shows high angles; Fig. 18c and d shows low angles. Figure 18a and c shows low strengths; Fig. 18b and d shows high strengths. According to the collision equation, a high angle and high strength significantly affect the difference in the target destination position. Specifically, when both the angle and strength of the attack are high, as shown in Fig. 18b, the difference in the target position is the highest; in contrast, when both the angle and strength are low, as shown in Fig. 18c, it is the smallest.

Fig. 18

Case study to show the difference between the collision equations with Discrete Collision Detection and Continuous Collision Detection

7.2.2 Effectiveness of customization

We demonstrate the effectiveness of the customization for the attached criteria. We measure the failure ratio of the attacking attempts in this experiment. We define the attacking success when the stone actually moves according to the player‘s action and the attacking failure when it does not move. For the comparison, we prepare two versions of ARGo: (1) the customization-enabled version with automatic settings and (2) the version working with the default attached criteria value. For each version, we performed 100 flicking motions. Figure 19 compares the results for the count of attacking successes and failures. The result indicates that customization dramatically reduces the failure ratio of the attacking attempts from 49% to only 4%, clearly showing the effectiveness of the customization.

Fig. 19

The results for the failure ratio of the attacking attempts between customization and non-customization. a Customization and b non-customization

8 Conclusions and discussion

In this study, we presented a mobile Go stone collision game based on augmented reality (AR), which we call ARGo. ARGo improved the portability and space constraints of Alkkagi by designing and implementing it in AR-based mobile environments without physical board and Go stones and maintained the sense of the reality of the game by providing a similar playing style to Alkkagi through AR-based design and implementation, resolving the limitations of all the existing mobile games based on the touchscreen. In this study, we made the following three contributions. First, we adopted an automata theory for the game design and collision scenario to define a clear state transition in complicated situations in AR-based environments involving virtual objects and interactions with them. Second, we proposed a collision equation to achieve Continuous Collision Detection by effectively resolving the collision errors that occurred in Discrete Collision Detection, which is a natural collision detection method according to the periodic image frame processing. Therefore, we effectively removed the errors in detecting the collision point and correctly calculated the final target destination of the collided stones, improving the game‘s sense of reality. Third, we verified the effectiveness of ARGo by showing the effects of the implemented functions for ARGo and its superiority over the existing mobile game Alkkagi Mania.

The development of AR allows us to handle virtual objects on a screen in various existing problems without additional equipment. For example, at CES2020, Samsung Electronics‘ in-house venture team proposed SelfieType, a virtual keyboard, using only the front camera of a smartphone (Samsung 2019). SelfieType can effectively replace typing on a small screen of a smartphone with typing in the real world using AR technology. As another similar example, recently, Matlani et al. (2021) proposed a virtual mouse using only a webcam. This allows users to interact with machines without physical devices. In this sense, ARGo also provides another actual example of solving the portability problems and space constraints of real-world board games by supporting the interactions between virtual and real objects.

As future work, we would like to extend ARGo to virtual reality (VR)-based 3D environments to more focus on improving sense of reality. Even if this requires a dedicated VR device, in this environment, we could achieve the complete implementation for the selection of stones and the attacking directions in a much more similar way with Alkkagi. Finally, as an ultimate goal, we plan to propose a shared framework of the current AR-based and new VR-based environments for ARGo to provide the advantages of both AR-based and VR-based environments and compare their usability in a fair way to the same target application.