理解扫雷游戏中的边界单元格问题
在开发像扫雷这样的网格类游戏时，确定一个单元格的相邻单元格是核心逻辑之一。常见的做法是通过简单地对单元格编号进行加减运算来查找相邻单元格，例如 cellnumb - 1（左邻居）、cellnumb + 1（右邻居）、cellnumb - gridlength（上邻居）等。然而，这种方法在处理网格边界时会遇到问题。
当一个单元格位于网格的边缘时，例如最左侧或最右侧，cellNumb - 1 或 cellNumb + 1 可能会错误地指向网格另一端的单元格，而不是实际意义上的相邻单元格。例如，在一个10x10的网格中，如果单元格90（第一列最后一个）的左邻居是89，但 cellNumb - 1 可能会被错误地判断为99（最后一列最后一个，如果单元格编号从0开始且换行）。这种“跨界”现象会导致游戏逻辑错误，例如在雷的旁边错误地标记了“绿色”或“蓝色”单元格。
原始代码中，当雷位于边界时，其相邻单元格的判断逻辑（例如 bombsArray.includes(cellNumb - 1)）未考虑边界条件，导致非相邻单元格被错误地标记为绿色。
精确的边界检测与“绿色”单元格逻辑
为了解决上述问题，我们需要引入精确的边界检测机制，确保只有在有效范围内才进行相邻单元格的判断。这可以通过模运算（%）来实现。
假设网格的单元格编号从1开始，并且按行从左到右递增。gridLength 代表网格的行/列长度（例如，10x10网格中 gridLength 为10）。
立即学习“Java免费学习笔记（深入）”；
-
判断左右边界
- 一个单元格位于右边界：当其编号是 gridLength 的整数倍时。
- 一个单元格位于左边界：当其编号模 gridLength 的结果为1时。
const atRightSide = cellNumb % gridLength === 0; const atLeftSide = cellNumb % gridLength === 1;
-
修正“绿色”单元格判断逻辑 “绿色”单元格表示与雷相邻的单元格。在判断这些单元格时，需要将边界条件纳入考虑。只有当单元格不在左边界时，才检查其左侧的邻居；只有当单元格不在右边界时，才检查其右侧的邻居。
// 假设 bombsArray 是包含所有雷单元格编号的数组 // cellNumb 是当前正在处理的单元格编号 // gridLength 是网格的边长 if (bombsArray.includes(cellNumb)) { singleCell.classList.add('bomb'); // 当前单元格是雷 } else if ( // 检查水平方向的邻居，并排除跨界情况 (!atLeftSide && bombsArray.includes(cellNumb - 1)) || // 左邻居 (!atRightSide && bombsArray.includes(cellNumb + 1)) || // 右邻居 // 检查垂直方向的邻居，垂直方向无需特殊边界处理（因为不会“跨行”到另一端） bombsArray.includes(cellNumb - gridLength) || // 上邻居 bombsArray.includes(cellNumb + gridLength) || // 下邻居 // 检查对角线方向的邻居，同样需要排除跨界情况 (!atLeftSide && bombsArray.includes(cellNumb - gridLength - 1)) || // 左上对角 (!atRightSide && bombsArray.includes(cellNumb - gridLength + 1)) || // 右上对角 (!atLeftSide && bombsArray.includes(cellNumb + gridLength - 1)) || // 左下对角 (!atRightSide && bombsArray.includes(cellNumb + gridLength + 1)) // 右下对角 ) { singleCell.classList.add('green'); singleCell.addEventListener('click', function () { addGreenPoints(); }); }
扩展至多层邻近单元格（“蓝色”单元格）
除了直接相邻的“绿色”单元格，有时游戏可能需要标记距离更远的单元格，例如在扫雷中表示“两步之外有雷”的“蓝色”单元格。对于这些距离更远的单元格，同样的边界检测原则也适用，但需要根据距离调整边界判断逻辑。
例如，对于距离为2的水平方向单元格 (cellNumb - 2 或 cellNumb + 2)，我们需要判断当前单元格是否距离边界至少有两格的距离。
// 距离边界两格的判断 const twoRightSide = cellNumb % gridLength === 0 || (cellNumb + 1) % gridLength === 0; const twoLeftSide = (cellNumb - 1) % gridLength === 0 || (cellNumb) % gridLength === 2; // 注意：twoLeftSide 的 (cellNumb) % gridLength === 2 意味着 cellNumb 模 gridLength 余 2，即在第二列。 // 如果 cellNumb 从 1 开始，则第一列是 1, 1+gridLength, ... // 第二列是 2, 2+gridLength, ... // 因此 (cellNumb - 1) % gridLength === 0 是第一列 // (cellNumb - 1) % gridLength === 1 是第二列 // (cellNumb - 1) % gridLength === gridLength - 1 是最后一列 // 这里的 twoLeftSide 和 twoRightSide 定义需要根据具体需求和 cellNumb 的起始值精确调整。 // 通常，atLeftSide 和 atRightSide 足够作为基础，然后在此基础上判断是否需要进一步的偏移量检查。
在判断“蓝色”单元格时，每一个潜在的邻居（无论是水平、垂直还是对角线，距离为2）都需要结合相应的边界条件进行检查。例如，检查 cellNumb - 2 时，必须确保 !twoLeftSide；检查 cellNumb - gridLength - 2 时，同样需要 !twoLeftSide。
由于“蓝色”单元格的组合非常多，其判断逻辑会变得冗长。核心思想是：对于任何可能跨越边界的计算，都必须在其条件中加入对应的边界检查。
性能优化与代码规范
除了逻辑修正，以下建议有助于提升代码质量和性能：
拼写修正：将代码中的 gridLenght 统一修正为正确的 gridLength。
-
使用 Set 优化 bombsArray： bombsArray.includes() 方法在大型数组中查找元素时，其时间复杂度为 O(n)。如果 bombsArray 包含大量雷，这会影响性能。将 bombsArray 转换为 Set 数据结构可以显著提高查找效率，Set.prototype.has() 方法的平均时间复杂度为 O(1)。
// 在初始化时，将雷的编号数组转换为 Set const bombsSet = new Set(bombsArray); // 之后在判断时使用 .has() 方法 if (bombsSet.has(cellNumb)) { // ... } else if ( (!atLeftSide && bombsSet.has(cellNumb - 1)) || // ... ) { // ... }
总结
在网格类游戏开发中，精确处理边界条件是确保游戏逻辑正确性的关键。通过运用模运算进行边界检测，并根据单元格编号的起始值（本例中为1）进行调整，可以有效地避免因“跨界”计算导致的错误。对于不同距离的邻近单元格，应灵活应用相应的边界判断逻辑。同时，采纳如使用 Set 优化查找等性能建议，将有助于构建更健壮、高效的游戏应用。
