An example of refactoring a jigsaw puzzle game using vue3

Preface

It took two days to reconstruct a puzzle game in the project (also known as Digital Huarong Road). For ease of use, it was extracted into independent components. The effect is as follows:

Online Experience

The source code address is at the end of the article!

Main reconstruction points

The original jigsaw puzzle game was modified through open source code using vue2. Everything works fine in actual projects, but there are still the following pain points

The source code is bloated and the exposed configuration items are insufficient, especially when combined with the existing logic of the project.
The generated game may have unsolvable situations. In order to avoid unsolvable situations, we have to write several situations and then generate them randomly.
The source code is vue2 version, and does not support vue3

Finally decided to use vue3 to re-implement the jigsaw puzzle game, paying attention to the following details

The components are simple enough to use
Customizable game difficulty
Supports both picture and array modes

Implementation ideas

Whether it is puzzle pictures or puzzle numbers, the principle is to move the originally shuffled array into an ordered state. There are also many algorithms on the Internet that implement digital Huarong. The main thing the algorithm needs to solve is how to generate a set of random and solvable arrays. Some people may wonder, is it possible that array Huarong is unsolvable?

If the generated game looks like the one above, then there is no solution. The principle is just like playing with a Rubik's Cube. Normally, no matter how messed up we are, we can restore it. But if we take out some blocks and change their positions, we may not be able to restore it.

There are many algorithms on the Internet that can avoid generating unsolvable problems, but they are all relatively advanced. In addition, my ability to read algorithms is limited, so I finally decided to implement it according to my own ideas.

My idea is actually quite simple. It can be summarized in one sentence as reverse reasoning. We can start with an arranged array and then randomly disrupt its order by moving it. This will definitely ensure that the generated questions have solutions. At the same time, we can control the difficulty of the game according to the number of disrupted steps. It is really an idea that kills two birds with one stone.

Source code implementation

Data Storage

First, I considered using a one-dimensional array to store the data.

let arr = [1,2,3,4,5,6,7,8,0] // 0 represents blank

But there will be a problem, that is, the logic becomes quite troublesome when moving, because a one-dimensional array can only record data and cannot record the vertical position. At this time, we naturally think of using a two-dimensional array. For example, when we need to generate a 3*3 game, the data is like this:

let arr [
  [1,2,3],
  [4,5,6],
  [7,8,0]
]

In this way, we can simulate the x and y axes to indicate the position of each number. For example, the position of 0 is (2,2) and the position of 6 is (1,2). If I want to move the positions of 6 and 0, I just need to swap their coordinates.

Move Function

The most critical interaction of Digital Huarongdao is to move the block that the user clicks on, but it should be noted that only the array near 0 can be moved. Next we complete the move function

 function move(x, y, moveX, moveY) {
  const num = state.arr[x][y];
  state.arr[x][y] = state.arr[moveX][moveY];
  state.arr[moveX][moveY] = num;
 }

Isn't it very simple? In fact, we just need to swap the subscripts of the two numbers to be moved. With the moving function, we can realize the movement up, down, left and right.

// Move up function moveTop(x, y) {
  if (x <= 0) return -1;
  // Start exchanging positions const okx = x - 1;
  move(x, y, okx, y);
  return {
   x: okx,
   y,
  };
 }
 //Move down function moveDown(x, y) {
  if (x >= level - 1) return -1;
  const okx = x + 1;
  move(x, y, okx, y);
  return {
   x: okx,
   y,
  };
 }
 // Move left function moveLeft(x, y) {
  if (y <= 0) return -1;
  const oky = y - 1;
  move(x, y, x, oky);
  return {
   x,
   y: oky,
  };
 }

 // Move right function moveRight(x, y) {
  if (y >= level - 1) return -1;
  const oky = y + 1;
  move(x, y, x, oky);
  return {
   x,
   y: oky,
  };
 }

Now let's implement a method to determine the moving direction, as shown below:

 function shouldMove(x, y) {
  // Determine where to move const { emptyX, emptyY } = seekEmpty();
  if (x === emptyX && y !== emptyY && Math.abs(y - emptyY) === 1) {
   // Indicates that it may move left or right on a horizontal line if (y > emptyY) {
    moveLeft(x, y);
   } else {
    moveRight(x, y);
   }
  }
  if (y === emptyY && x !== emptyX && Math.abs(x - emptyX) === 1) {
   // Indicates the need to move up and down if (x > emptyX) {
    moveTop(x, y);
   } else {
    moveDown(x, y);
   }
  }
 }

The judgment in if means that if the block we click is a blank block or is not adjacent to a blank block, then we will not do anything.

Generate game board

In fact, it is to randomly call the up, down, left, and right shift functions to disrupt the array

 // Randomly shuffle function moveInit(diffic) {
  state.arr = createArr(level);
  const num = diffic ? diffic : state.diffec;
  const fns = [moveTop, moveDown, moveLeft, moveRight];
  let Index = null;
  let fn;
  for (let i = 0; i < num; i++) {
   Index = Math.floor(Math.random() * fns.length);
   // moveConsole(Index);
   fn = fns[Index](startX, startY);
   if (fn != -1) {
    const { x, y } = fn;
    startX = x;
    startY = y;
   }
  }
 }

In just a few functions, the core logic is completed. There are still a few functions that have not been introduced, such as judging the completion of the game, finding the location of the blank block, and creating a two-dimensional array. You can read the source code by yourself.

Refactoring with vue3

The above logic seems to have nothing to do with vue3, but we have overlooked the most important point, that is, after changing the array, the view also changes. Isn't this responsive? After using vue3, we can put all the logic about the game into a js, which greatly reduces the coupling of the code

const { arr, shouldMove, moveInit } = useCreateGame(
 gamedata.level,
 gamedata.difficulty,
 gameEndCallback
);

Some people may have questions? Isn't it normal to extract all the logic? Is it impossible to extract it when using vue2?
But don't forget, our array needs to be responsive. If we extract the logic separately, will it still be responsive if we change the array in the js file?

But when we use the composition-api of vue3, we can declare a responsive variable in the js file, and it is still responsive when used in the component

export default function useCreateGame() {
//Declare a responsive variable...
 const state = reactive({
  arr: [],
 });
...
 return {
 ...toRefs(state)
 ...
 }
 }

const { arr, shouldMove, moveInit } = useCreateGame(
 gamedata.level,
 gamedata.difficulty,
 gameEndCallback
);
// At this time, arr is still responsive

This is the power of composition-api. With composition-api, we can assemble our logic code arbitrarily.

In vue2, if we want to maintain a responsive variable, do we have to use a state manager like vuex, which increases the coupling of the code

About vite2

Now vite has reached vite2 version, and the official is still iterating rapidly. Projects created with vite2 can use the new setup features by default. For example, we can write:

<template>
 <div>
  {{ name }}
 </div>
</template>

<script setup>
import { ref } from "vue";
const name = ref('"The public number does not stop"');
</script>

This is equivalent to writing

<template>
 <div>
  {{ name }}
 </div>
</template>
<script>
import { ref } from "vue";
export default {
 setup() {
  const name = ref("The public number does not stop");
  return {
   name,
  };
 },
};
</script>

It looks a lot simpler, and Vue has released several APIs in the setup version. If you are interested, you can go to the official website to check it out. I personally feel that it is quite good. Because the new syntax is still experimental, this code refactoring did not use it.