Skip to content
xyspg
Go back

Digital Implementation of the 'Instruction Game' Based on Socket.IO

216
This article was translated from Chinese by AI. View Original
Digital Implementation of the 'Instruction Game' Based on Socket.IO

Using the WebSocket-based Socket.IO library to digitalize 'Instruction Game,' a traditional game at my residential college.

Foreword

The “Instruction Game” is a long-standing traditional orientation program for the Academy I belong to at the High School Affiliated to Peking University (BDFZ). The rules are simple: at the start of the game, the moderator randomly distributes cards with instructions to each participant. Everyone must execute their instructions in the correct order. If anyone makes a mistake, the game starts over from the very beginning. For example:

Card 1

Shout loudly: “Attention everyone, the game has begun!”

Card 2

After hearing “the game has begun,” find the light switch, flip it twice, and return to your seat.

Card 3

After the light has been flipped twice, invite the third student to your left to jump 3 times in the center of the circle with you, then lead them back to their seat.

Sounds simple, doesn’t it? At first, everyone thought so. However, the criteria for “making a mistake” include incorrect actions, wrong sequence, lack of cohesion (noticeable lagging), and anyone speaking out of turn.

During the “Instruction Game,” the hall is pin-drop silent, with everyone’s eyes fixed on the student currently executing an instruction. In such a high-pressure atmosphere, it’s inevitable that nerves lead to physical blunders, forgetting the sequence, and various other accidents (especially with instructions like “state the names of the five students to your right”). And that is exactly what happened. When I participated in the “Instruction Game,” we spent an entire afternoon (4–5 hours) just to complete a single round. For the new batch of students, the situation hasn’t improved much.

Undeniably, the “Instruction Game” helps new students become familiar with each other through its content, making it engaging and fun. It builds rapport among freshmen, helps them integrate into the collective quickly, and trains their ability to concentrate and exercise self-control—qualities that are vital for life at BDFZ.

Learning and life at BDFZ are highly independent and autonomous; every notice you receive is extremely important. Therefore, we hope this game helps everyone gradually realize the importance of execution and rigor regarding instructions. In your future campus life, the instructions you receive might be an assignment, a notice, or a piece of teamwork… If you are careless or negligent, you might miss an opportunity, a grade, or even the trust others place in you. Thus, during orientation, we as seniors hope this game not only brings you closer together but also allows you to gain insights and reflections to better embrace life at BDFZ. — “Activity Plan”

sit

During the actual game, I noticed that a significant portion of time was wasted on the process of collecting and redistributing instruction cards after a mistake. Once an instruction was botched, the process of seniors collecting the cards, shuffling them, and re-handing them out took about 2-3 minutes. During these repeated 2-3 minute waits, the participants’ patience and enthusiasm gradually drained, pressure mounted in the later stages, and overall discipline began to slacken. This anxious waiting led to feelings of “giving up.”

By the time the game ended, most participants felt more of a “sense of relief” than a “sense of achievement” or “collective honor.”

Therefore, can we improve this game through the lens of User Experience (UX) design thinking?

According to Nielsen’s Law of User Interface Design, a user’s patience begins to decline after a wait of more than 1 second, and they may lose focus entirely after 10 seconds. Thus, resets after errors and the distribution of instructions should be completed as quickly as possible to maintain participants’ attention and the game’s continuity. A digitalized game would be an effective solution.

Distributing instructions via electronic devices can reduce the waiting time associated with physical card collection and redistribution, allowing participants to focus their energy on executing the instructions. Furthermore, an electronic system can reset immediately after an error occurs, eliminating waiting time and alleviating participant anxiety.

At the same time, designing a friendly user interface and interaction model makes the game rules and current status clear at a glance, improving the flow and playability of the game. Such a design preserves the core philosophy of the game while optimizing the experience, helping to better stimulate participants’ enthusiasm and cultivate their teamwork spirit and instruction execution capabilities.

Defining Requirements

Based on the game description above, we can build the requirements:

The server needs real-time bi-directional communication with the clients.

client server

Distinction between administrators and player users.

Display of online users.

At the start of each game, all players are randomly assigned a card.

Administrators can trigger game starts and game resets.

Real-name system for players.

Error handling: contingency plans for unexpected network disconnections.

System Construction

With the requirements clarified, we can begin building the system.

For bi-directional server communication, I used the Socket.IO library based on WebSockets. Socket.IO features an event-driven architecture; by emitting and listening to events, message passing and data synchronization between the server and client can be easily implemented. I can define my own events and handlers to meet the specific needs of the game. Socket.IO has an automatic reconnection mechanism; when the connection between the client and server is broken, it attempts to re-establish the connection automatically. Additionally, Socket.IO provides error-handling mechanisms to catch and handle connection errors, timeouts, and other exceptions.

sequence diagram

For the server backend, I chose the Express framework based on Node.js for scalability. This way, the same system can be applied to Web Applications, Apps, and WeChat Mini Programs.

The core part of the program—implementing command assignment and shuffling:

function assignCommands(users, commands) {
  const shuffledCommands = shuffle([...commands]);
  return users.reduce((acc, user, idx) => {
    acc[user] = shuffledCommands[idx];
    return acc;
  }, {});
}

function shuffle(array) {
  for (let i = array.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [array[i], array[j]] = [array[j], array[i]];
  }
  return array;
}

User list and command distribution:

// Server Side
socket.on('start_game', (username) => {
    if (socket.isAdmin) {
      userCommands = assignCommands(users, commands);
      io.emit('game_started', userCommands);
      io.emit('command_list_update', userCommands);
    }
  });

  socket.on('refresh', (username) => {
    if (socket.isAdmin) {
      userCommands = assignCommands(users, commands);
      io.emit('commands_refreshed', userCommands);
      io.emit('command_list_update', userCommands);
    }
  });

  socket.on('disconnect', () => {
// Remove disconnected user from the list
    const index = onlineUsers.indexOf(socket.username);
    if (index !== -1) {
      onlineUsers.splice(index, 1);
      io.emit('user_list_update', onlineUsers);
    }
  });
});
// Client Side
socket.on("game_started", userCommands => {
  const command = userCommands[username];
  document.querySelector("#command").textContent = `${command}`;
});

socket.on("commands_refreshed", userCommands => {
  const command = userCommands[username];
  document.querySelector("#command").textContent = `${command}`;
});

socket.on("user_list_update", userList => {
  const list = document.querySelector("#user-list");
  list.innerHTML = "";
  userList.forEach(user => {
    const div = document.createElement("div");
    div.textContent = user;
    list.appendChild(div);
  });
});

Results Showcase

Currently implemented features:

Login restricted to players on the whitelist.

Image

Administrator controls for starting the game and refreshing instructions.

Image

Real-time updates of the online player list.

Image

Display of instructions for all players.

Image

User authentication: only administrators can execute game starts and instruction refresh operations.

Network disconnection alerts and automatic reconnection.

Image

Full Demo presentation:

Image

TODO: A major issue with the digitalized “Instruction Game” is that participants might occasionally switch to WeChat or other apps once they have access to electronic devices. To solve this, one could refer to exam pages like Wenjuanxing, using an Event Listener to detect screen-switching behavior and issue warnings.

TODO: Online user tracking. Currently, the online user array is stored in the server’s memory. This method loses all data if the server restarts or scales horizontally (multiple instances). In a more complex application, a database or centralized storage (like Redis) might be needed to store this data.

TODO: Offline user reporting and more sophisticated reconnection strategies.

TODO: More aesthetic, gamified interface design and interactions.

Summary

While the “Instruction Game” is a heritage tradition of the Academy’s orientation, its overly high-pressure and tedious process has been criticized. By digitalizing the “Instruction Game,” I hope to improve the game flow and player experience while preserving the core philosophy of the game and its role in freshman training.



Next Post
US Credit Card Guide for F1

评论

No comments yet

支持 Markdown