Amine BEN YEDDER

January 14, 2026

Build a Bicycle tap Game in React Native Part 5: Game Logic

Previous: Build a Bicycle tap Game in React Native Part 4: Game Movement

This section explains how game logic is structured using a centralized state machine to control when the simulation runs, pauses, and ends. It covers introducing explicit game states to prevent automatic start, gating frame-based updates through state checks, and synchronizing animations with gameplay transitions. It also details how pause, win, and lose conditions are detected in world space and handled consistently through state changes. The focus is on keeping all gameplay rules in one place, allowing the UI to simply reflect the current state while the frame loop drives progression.

Game State

At this point, the simulation runs as soon as the app loads, which isn’t ideal for a game. We need a way to control when the game actually starts, instead of having movement and animations begin immediately.

To solve this, we introduce a minimal game state that lets us pause the simulation on load and start it explicitly via a Start button. This section adds a simple state machine with two states: READY and RUNNING:

App.tsx

type GameStateType = "READY" | "RUNNING";

READY: the game is idle (no movement updates, overlay visible)
RUNNING: the game is active (movement updates, overlay hidden)

Define game state and animation refs

We store the state in a Reanimated shared value so it can be read directly inside useFrameCallback and animated styles, without React re-renders.

App.tsx

const monsterRef = useRef<Dotlottie>(null);
const gameState = useSharedValue<GameStateType>("READY");

The monster animation is controlled imperatively via a ref, so it can start exactly when the game starts.

Gate movement updates with game state

Movement should only run when the game is in RUNNING. The frame loop is gated by the current state:

App.tsx

useFrameCallback(() => {
  if (gameState.value !== "RUNNING") return;

  monsterPosition.value++;
  characterPosition.value += characterSpeed.value;
});

This keeps the simulation control centralized: flipping gameState is enough to start or stop movement.

Start the game (explicit control)

To prevent the game from starting automatically, the monster animation is first configured not to autoplay. This ensures that nothing moves or animates until the player explicitly starts the game.

App.tsx

<DotLottie
  ref={monsterRef} // add the monsterRef to control the animation
  source={require("./assets/monster.lottie")}
  style={{
      width: MONSTER_SIZE,
      height: MONSTER_SIZE,
   }}
   loop
   autoplay={false} // set should be false to prevent auto-start
/>

With autoplay disabled, the monster remains idle while the game is in the READY state.

We then define a startGame function that explicitly starts the simulation:

App.tsx

const startGame = () => {
  gameState.value = "RUNNING";
  monsterRef.current?.play();
};

When the player presses the Start button:

the game state switches from READY to RUNNING
the frame loop becomes active
the monster animation starts playing

This makes the start of the game intentional and predictable, with gameplay and animation beginning at the exact same moment.

Add a style to show/hide the gamestart overlay

The overlay should be visible and interactive in READY, and fully disabled during RUNNING. This is handled with an animated style:

App.tsx

const startOverlayStyle = useAnimatedStyle(() => ({
   display: gameState.value === "READY" ? "flex" : "none"
}));

display: controls the appearance of the element.

Render the play overlay

App.tsx

<Animated.View
  style={[
    {
      position: "absolute",
      inset: 0,
      backgroundColor: "#00000062",
      alignItems: "center",
      justifyContent: "center",
    },
    startOverlayStyle,
  ]}
>
  <FontAwesome5
    name="play"
    size={160}
    color="yellow"
    onPress={startGame}
  />
</Animated.View>

This creates a clean "start screen" that:

blocks gameplay input while in READY
disappears automatically once the game enters RUNNING

Pause, Win, and Lose conditions

Now that the game can start explicitly, we can extend the state machine to support pausing and end conditions. The goal is to keep all rules centralized in one place: the frame loop decides what happens, and the UI simply reflects the current gameState.

Pause

Once the game can start and run, the next step is to let the player pause, resume, or restart at any time. We do this by extending the game state and rendering two UI layers:

a pause button that only appears while running
a pause menu overlay that only appears while paused

Extend the game state

App.tsx

type GameStateType = "READY" | "RUNNING" | "PAUSED";

Pause, resume, and restart actions

Pausing switches the state to PAUSED and pauses animations immediately:

App.tsx

const pauseGame = () => {
  gameState.value = "PAUSED";
  monsterRef.current?.pause();
  characterRef.current?.pause();
};

Resuming switches back to RUNNING, plays the monster animation, and only plays the character animation if it was moving:

App.tsx

const resumeGame = () => {
  gameState.value = "RUNNING";
  monsterRef.current?.play();
  if (characterSpeed.value > 0) characterRef.current?.play();
};

Restarting resets positions, stops animations, and returns to READY:

App.tsx

const restartGame = () => {
  characterPosition.value = CHARACTER_INITIAL_POSITION;
  characterSpeed.value = 0;
  monsterPosition.value = MONSTER_INITIAL_POSITION;
  gameState.value = "READY";
  monsterRef.current?.stop();
  characterRef.current?.stop();
};

Show/hide pause UI with animated styles

We use the same pattern as the start overlay
This keeps UI layers mounted but makes them visible and interactive only in the correct state.

Pause button (only when running):

App.tsx

const pauseButtonStyle = useAnimatedStyle(() => ({
  display: gameState.value === "RUNNING" ? "flex" : "none",
}));

Pause menu (only when paused):

App.tsx

const pauseMenuStyle = useAnimatedStyle(() => ({
  display: gameState.value === "PAUSED" ? "flex" : "none",
}));

Render the pause button and pause menu

Pause button (top center):

App.tsx

<Animated.View
  style={[
    {
      position: "absolute",
      left: "50%",
      top: 50,
      transform: [{ translateX: "-50%" }],
      flexDirection: "row",
    },
    pauseButtonStyle,
  ]}
>
  <FontAwesome5 name="pause" size={40} color="yellow" onPress={pauseGame} />
</Animated.View>

Pause menu overlay (full screen):

App.tsx

<Animated.View
  style={[
    {
      position: "absolute",
      inset: 0,
      backgroundColor: "#00000062",
      alignItems: "center",
      justifyContent: "center",
    },
    pauseMenuStyle,
  ]}
>
  <Text style={{ color: "white", fontSize: 50, fontWeight: 700 }}>
    PAUSE MENU
  </Text>

  <View style={{ gap: 16, flexDirection: "row" }}>
    <FontAwesome5 name="play" size={40} color="yellow" onPress={resumeGame} />
    <MaterialIcons name="replay" size={40} color="yellow" onPress={restartGame} />
  </View>
</Animated.View>

Key takeaway

PAUSED is just another game state, controlled the same way as READY and RUNNING.
The pause button and pause menu are always mounted, but only visible + clickable in the appropriate state.
Resume logic is careful to restart only the animations that should be active (monster always, character only if speed > 0).

Win

To add a win condition, we introduce a new game state (WON) and detect when the character reaches the flag position at the end of the world. Once the win condition is met, we freeze gameplay by pausing both Lottie animations and showing a win overlay.

Extend the game state

App.tsx

type GameStateType = "READY" | "RUNNING" | "PAUSED" | "WON";

Reusable helper: pause Lottie animations

We’ll use a small helper to freeze both animated entities consistently:

App.tsx

const pauseLotties = () => {
  monsterRef.current?.pause();
  characterRef.current?.pause();
};

We also reuse this in pauseGame to keep behavior consistent:

App.tsx

const pauseGame = () => {
  gameState.value = "PAUSED";
  pauseLotties();
};

Detect the win condition inside the frame loop

The win condition is checked in world space: if the character reaches the end-of-world flag position, we switch to WON and stop updating movement.

App.tsx

useFrameCallback(() => {
  if (gameState.value !== "RUNNING") return;

  if (characterPosition.value >= worldWidth - FLAG_OFFSET - FLAG_SIZE) {
    gameState.value = "WON";
    return;
  }

  monsterPosition.value++;
  characterPosition.value += characterSpeed.value;
});

This keeps all gameplay progression in one place: the frame loop advances the simulation and decides when the game ends.

Pause animations when entering WON

State changes happen on the UI thread, but pausing the Lottie refs must happen on the React Native side. We listen for state transitions using useAnimatedReaction and schedule the pause on RN:

App.tsx

useAnimatedReaction(
  () => gameState.value,
  (value, previous) => {
    if (value === previous) return;
    if (value === "WON") scheduleOnRN(pauseLotties);
  },
);

This guarantees that when the game switches to WON, animations stop immediately and the scene visually "freezes" in its final position.

Show the win overlay

Just like the pause menu, the win overlay uses display so it becomes visible only when the state is WON:

App.tsx

const winOverlayStyle = useAnimatedStyle(() => ({
  display: gameState.value === "WON" ? "flex" : "none"
}));

App.tsx

<Animated.View
  style={[
    {
      position: "absolute",
      inset: 0,
      backgroundColor: "#00000062",
      alignItems: "center",
      justifyContent: "center",
    },
    winOverlayStyle,
  ]}
>
  <Text style={{ color: "white", fontSize: 50, fontWeight: 700 }}>
    YOU WON!
  </Text>

  <View style={{ flexDirection: "row" }}>
    <MaterialIcons name="replay" size={40} color="yellow" onPress={restartGame} />
  </View>
</Animated.View>

Key takeaway

The win condition is checked in world coordinates inside the frame loop.
Switching to WON stops simulation updates (because RUNNING is required to progress).
useAnimatedReaction is used to respond to the state transition and pause Lottie animations safely.
The win screen is just another overlay controlled by game state.

Lose

To complete the game loop, we add a lose condition with a new state: OVER. The idea is simple: if the monster catches up to the character, the game ends, animations freeze, and a "Game Over" overlay appears.

Extend the game state

App.tsx

type GameStateType = "READY" | "RUNNING" | "PAUSED" | "WON" | "OVER";

Detect the lose condition inside the frame loop

Just like the win check, the lose condition is evaluated inside useFrameCallback while the game is running.

App.tsx

useFrameCallback(() => {
  if (gameState.value !== "RUNNING") return;

  // Win
  if (characterPosition.value >= worldWidth - FLAG_OFFSET - FLAG_SIZE) {
    gameState.value = "WON";
    return;
  }

  // Lose (monster catches the character)
  if (monsterPosition.value >= characterPosition.value - CHARACTER_SIZE / 2) {
    gameState.value = "OVER";
    return;
  }

  // Continue simulation
  monsterPosition.value++;
  characterPosition.value += characterSpeed.value;
});

The lose rule here is a minimal overlap check in world space:

the monster advances forward each frame
once it reaches the character’s trailing edge (approximated by CHARACTER_SIZE / 2), the game switches to OVER

Freeze animations on end states (WON or OVER)

We reuse the same reaction mechanism to pause Lottie animations when the game ends whether by winning or losing:

App.tsx

useAnimatedReaction(
  () => gameState.value,
  (value, previous) => {
    if (value === previous) return;
    if (value === "WON" || value === "OVER") scheduleOnRN(pauseLotties);
  },
);

This ensures the final frame stays visible and the scene "locks" immediately.

Show the lose overlay

The lose screen is another overlay controlled by the game state:

App.tsx

const loseOverlayStyle = useAnimatedStyle(() => ({
  display: gameState.value === "OVER" ? "flex" : "none",
}));

App.tsx

<Animated.View
  style={[
    {
      position: "absolute",
      inset: 0,
      backgroundColor: "#00000062",
      alignItems: "center",
      justifyContent: "center",
    },
    loseOverlayStyle,
  ]}
>
  <Text style={{ color: "white", fontSize: 50, fontWeight: 700 }}>
    GAME OVER
  </Text>

  <View style={{ flexDirection: "row" }}>
    <MaterialIcons name="replay" size={40} color="yellow" onPress={restartGame} />
  </View>
</Animated.View>

Refactoring

At first, the UI states (Pause, Win, Lose, Start) are often implemented as separate full-screen overlays. Each state gets its own <Animated.View> that covers the screen, with the same styling repeated every time:

position: "absolute"
inset: 0
dark background
centered layout

This works, but the duplication becomes painful fast. Any visual tweak (overlay color, alignment, spacing, font sizing) has to be applied in four places.

The cleaner approach is to keep one shared overlay container and make the content inside it depend on gameState.

Step 1: Keep a single "overlay wrapper"

Instead of rendering multiple screen-sized overlays, render only one wrapper that appears whenever the game isn’t running:

App.tsx

const overlayStyle = useAnimatedStyle(() => ({
  display: gameState.value === "RUNNING" ? "none" : "flex",
}));

This wrapper becomes the "UI layer" for all non-running states.

Step 2: Add small styles for each state’s content

Now define tiny visibility styles for the pieces inside the overlay:

App.tsx

const pauseStyle = useAnimatedStyle(() => ({
  display: gameState.value === "PAUSED" ? "flex" : "none",
}));

const winStyle = useAnimatedStyle(() => ({
  display: gameState.value === "WON" ? "flex" : "none",
}));

const loseStyle = useAnimatedStyle(() => ({
  display: gameState.value === "OVER" ? "flex" : "none",
}));

const startStyle = useAnimatedStyle(() => ({
  display: gameState.value === "READY" ? "flex" : "none",
}));

const replayStyle = useAnimatedStyle(() => ({
  display: gameState.value === "READY" ? "none" : "flex",
}));

This keeps the logic readable:

Pause state shows pause text + resume button
Win state shows "You won!" + replay
Lose state shows "Game over" + replay
Ready state shows big play button only

Step 3: Render everything once, toggle visibility per state

Now your overlay UI becomes one component with stable structure:

App.tsx

<Animated.View
  style={[
    {
      position: "absolute",
      inset: 0,
      backgroundColor: "#00000062",
      alignItems: "center",
      justifyContent: "center",
    },
    overlayStyle,
  ]}
>
  <Animated.Text style={[{ color: "white", fontSize: 50, fontWeight: 700 }, pauseStyle]}>
    PAUSE MENU
  </Animated.Text>

  <Animated.Text style={[{ color: "white", fontSize: 50, fontWeight: 700 }, winStyle]}>
    YOU WON!
  </Animated.Text>

  <Animated.Text style={[{ color: "white", fontSize: 50, fontWeight: 700 }, loseStyle]}>
    GAME OVER
  </Animated.Text>

  <View style={{ gap: 16, flexDirection: "row" }}>
    <Animated.View style={pauseStyle}>
      <FontAwesome5 name="play" size={40} color="yellow" onPress={resumeGame} />
    </Animated.View>

    <Animated.View style={replayStyle}>
      <MaterialIcons name="replay" size={40} color="yellow" onPress={restartGame} />
    </Animated.View>
  </View>

  <Animated.View style={startStyle}>
    <FontAwesome5 name="play" size={160} color="yellow" onPress={startGame} />
  </Animated.View>
</Animated.View>

Why this refactor is worth it

Less duplication: The overlay container styling exists once.

Easier maintenance: Update the overlay look (background, padding, typography) in one place.

State-driven UI: Instead of “render a whole new overlay,” you’re expressing:

"show this piece when we’re paused"
"show this piece when we won"
"show this piece when we lost"

That’s a much cleaner mental model for game UI.

Key takeaway

The lose condition is evaluated in world coordinates inside the frame loop.
Switching to OVER immediately stops the simulation (because updates only run in RUNNING).
A single useAnimatedReaction handles freezing animations for both end states.
The lose overlay follows the same pattern as pause and win.

Next: Build a Bicycle tap Game in React Native Part 6: Game Menu