- 文档
- 教程
【免费下载链接】app-ideas
A Collection of application ideas which can be used to improve your coding skills.
Boole Bots Game 是 app-ideas 仓库 3-Advanced 分级中一个极具教学价值的游戏项目:它把"布尔逻辑"直接变成游戏的胜负裁决规则,让玩家在配置机器人、观看它们对撞、淘汰的过程中直观理解 AND、OR、XOR、NOT 等运算。本文将以 Projects/3-Advanced/Boole-Bot-Game.md 这份规格文档为主体,逐条展开其用户故事与进阶特性,并结合仓库内其他游戏项目的工程实践,给出可落地的数据结构、裁决算法、状态机设计与分阶段开发路线。读完本文,你将能独立设计并实现一套完整的"布尔机器人对战"游戏,包括四机器人配置面板、Battle!/Stop! 对战控制、8×8 竞技场碰撞结算、排行榜统计以及日志、计时器、八方向、图标面板等全部进阶功能。
项目定位:用游戏化方式学习布尔代数
该项目的完整规格定义于 Projects/3-Advanced/Boole-Bot-Game.md,其核心设想如下:
- 游戏拥有一块8×8 的竞技场(arena),由 64 个游戏格(tile)组成;
- 4 个机器人(bot)在竞技场内以随机的速度和轨迹移动;
- 每个机器人被赋予一个布尔值(boolean value,0 或 1)和一个布尔运算(boolean operation);
- 当两个机器人发生碰撞(collision)时,根据双方布尔运算的结果判定胜、负或平局;
- 失败者消失,胜利者继续移动,直到竞技场中仅剩一个机器人,游戏结束。
项目等级为3-Advanced。对照 README.md 中的分级定义,Tier-3 面向已经熟悉 UI/UX 与开发工具、正在学习后端与更高级技术的开发者——本项目恰好要求你同时处理"图形渲染/游戏循环/碰撞物理"与"纯逻辑的布尔裁决引擎"两部分,是体验分层架构的绝佳切入点。
规格文档还给出了唯一的硬性约束:
Developers may use graphics and game physics libraries to build the game.(开发者可以使用图形与游戏物理库来构建本游戏)
这意味你可以自由选择 Canvas 原生实现、p5.js、Phaser 等方案,甚至引入简单的刚体物理库来处理反弹与碰撞;但需要说明,规格并不强制使用任何特定技术栈,渲染之外的核心裁决逻辑完全由你自己设计。
碰撞裁决:把布尔运算变成"胜负判定引擎"
机器人模型
从规格描述中可以归纳出每个机器人至少需要如下字段(这属于对用户故事的合理数据建模,你可以自行调整字段名):
| 字段 | 含义 | 取值来源 |
|---|---|---|
name | 机器人名称,必须唯一 | 配置面板文本框 |
value | 布尔值 | 下拉框选择 0 或 1 |
operation | 布尔运算 | 下拉框选择 AND / OR / XOR / NOT |
speed | 移动速度 | 滑块设置 |
heading | 起始方向 | 下拉框选择 North / South / East / West |
position | 在 8×8 竞技场中的落位 | 定义名称后随机分配 |
wins/losses | 胜负统计 | 碰撞结算后更新,供排行榜展示 |
真值表:胜负裁决的数学基础
规格文档 Projects/3-Advanced/Boole-Bot-Game.md 在描述部分提到运算集合为 AND、OR、NOR、NOT,而配置面板的用户故事则列出 AND、OR、XOR、NOT。这是规格原文中存在的一处表述差异,实现时建议以配置面板的 AND / OR / XOR / NOT 为准,并可顺带实现 NOR 作为额外运算。各运算的真值表如下:
| A | B | A AND B | A OR B | A XOR B | A NOR B |
|---|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 0 | 1 |
| 0 | 1 | 0 | 1 | 1 | 0 |
| 1 | 0 | 0 | 1 | 1 | 0 |
| 1 | 1 | 1 | 1 | 0 | 0 |
NOT 是一元运算:NOT 0 = 1,NOT 1 = 0。
裁决算法的可执行模型
规格文档对碰撞结果的描述原文如下:
When a bot collides with another bot its boolean operation is applied to both it and the other bots' boolean value to determine which one wins or looses, or if the collision results in a tie.
同时竞技场小节进一步规定:
- 机器人消失的条件是"它自己的布尔运算应用到它自己的布尔值和对方布尔值后的结果为 0";
- 平局的条件是"双方得到相同的布尔结果(同为 0 或同为 1)"。
由此可以推导出一套自洽的裁决模型:碰撞发生时,双方各自用自己的运算、以自己的布尔值和对方的布尔值作为输入(NOT 则只作用于自身值)计算出一个结果;结果相同则平局,结果不同则结果为 1 的一方获胜、结果为 0 的一方消失。注意,规格并未规定碰撞后布尔值是否变化,因此"机器人布尔值在整局游戏中保持不变"是一个合理且简单的默认选择,如需动态演化可作为自选扩展。
参考实现(伪代码,非仓库现成代码,请根据你的语言调整):
// 运算求值:二元运算以 (ownValue, otherValue) 为输入;NOT 为一元 function evaluate(operation, ownValue, otherValue) { switch (operation) { case 'AND': return ownValue & otherValue; case 'OR': return ownValue | otherValue; case 'XOR': return ownValue ^ otherValue; case 'NOT': return ownValue === 1 ? 0 : 1; // 反转自身布尔值 // 可选扩展 case 'NOR': return (ownValue | otherValue) === 1 ? 0 : 1; } } // 碰撞裁决:返回 'tie' | 'a_wins' | 'b_wins' function resolveCollision(botA, botB) { const resultA = evaluate(botA.operation, botA.value, botB.value); const resultB = evaluate(botB.operation, botB.value, botA.value); if (resultA === resultB) return 'tie'; return resultA === 1 ? 'a_wins' : 'b_wins'; }这个裁决函数是整个游戏唯一与布尔逻辑强耦合的纯函数,没有 DOM、没有渲染依赖,天然适合单元测试。例如可以断言:value=1、operation=AND的 A 撞上value=1的 B,resolveCollision必须返回a_wins;两个 XOR 机器人无论值如何,结果永远相同,因而两个 XOR 机器人碰撞恒为平局——这类边界行为值得在开发早期就用测试固定下来。把裁决逻辑与表现层分离的做法,与仓库中同为 3-Advanced 的 Battleship-Game-Engine 所倡导的"引擎与表现层分离、通过函数调用驱动游戏"的架构思路完全一致,可以作为本项目的设计范本。
游戏窗口:四大组成部件
规格文档 Projects/3-Advanced/Boole-Bot-Game.md 要求游戏窗口至少包含四个部件:
- 游戏配置输入面板(Game configuration input panel):完成 4 个机器人的全部参数设置;
- 排行榜(Leaderboard):按得分展示各机器人的排名;
- 游戏控制(Game controls):开始/停止对战的按钮;
- 8×8 游戏格竞技场(Arena):机器人战斗发生的区域。
建议的布局可以是:左侧/上方为配置面板与控制按钮,右侧为竞技场与排行榜;也可以采用"配置面板 → 竞技场 → 排行榜"的纵向三段式。规格没有限定布局,你可以根据目标平台自由安排。
游戏配置面板:四机器人参数输入与校验
规格 Projects/3-Advanced/Boole-Bot-Game.md 定义了配置面板的完整交互,共包含四个机器人面板,每个面板需要以下子控件:
- 名称文本框:输入该机器人的唯一名称;
- 布尔值下拉框:0 或 1;
- 布尔运算下拉框:AND、OR、XOR、NOT;
- 速度滑块:设置移动速度(具体速度范围由开发者定义,规格未规定上下限);
- 方向下拉框:North(北)、South(南)、East(东)、West(西)四个基本方向。
名称唯一性校验
- 用户输入的名称若与另一个机器人重复,必须显示错误信息;
- 结合仓库中同样强调名称/图标唯一性校验的 Bug-Race-Game 项目可见,"唯一名称 + 错误提示"是本仓库游戏类项目反复出现的交互惯例,通常的实现方式是:在失焦或提交时遍历其余 3 个机器人的
name字段,重复则拒绝输入并在面板旁渲染错误文案,同时保持「Battle!」按钮不可用。
随机落位
- 一旦机器人名称被定义,该机器人应被随机分配到 8×8 竞技场中的某个格子;
- 实现时要保证 4 个机器人落在互不重叠的格子上。一个简单策略是:在 64 个格子中随机挑选,若已被占用则重新抽取,直到 4 个机器人全部落位。
游戏控制:Battle! / Stop! 的状态切换
规格 Projects/3-Advanced/Boole-Bot-Game.md 对控制按钮的定义形成了一个清晰的三态状态机:
| 状态 | 按钮显示 | 行为 |
|---|---|---|
idle(待机) | Battle! | 点击后开始对战;机器人按各自速度与方向移动 |
battling(对战中) | Stop! | 点击后立即暂停全部机器人运动 |
gameOver(单胜者) | Battle! | 场上只剩一个机器人时自动切回,等待下一局 |
实现要点:
- 开始对战后,按钮文本必须从
Battle!切换为Stop!; - 点击
Stop!暂停所有机器人运动(但保留当前场上状态,便于恢复或重开); - 当只剩一个机器人时,按钮文本自动切回
Battle!,游戏结束。
状态机建议与"竞技场更新循环"解耦:游戏循环只在battling状态下推进机器人位置,idle/gameOver状态下循环只负责渲染静态画面。
竞技场:移动、反弹、碰撞与结算
移动模型
规格要求机器人"以分配给它们的速度和方向移动"。速度滑块控制的是每单位时间的位移量(例如每秒移动的格子数或像素数),方向决定运动向量。一种常见做法是维护每个机器人的方向角heading,并每帧按如下方式更新位置(伪代码):
bot.x += bot.speed * Math.cos(bot.heading); bot.y += bot.speed * Math.sin(bot.heading);注意规格中的"随机速度和轨迹"指的是不同机器人之间的速度与轨迹差异(速度由用户通过滑块配置),并非要求每帧随机扰动轨迹。8×8 网格意味着两种可选的移动实现:按格子离散步进(机器人从一个 tile 跳到相邻 tile),或连续像素移动并在碰撞检测时换算到 tile 坐标。两者都满足规格,选择取决于你想用的图形库。
边界反弹
规格要求机器人碰到竞技场边界墙后以新方向反弹。对 8×8 网格而言,实现方式为:判断机器人坐标是否越出[0, 8)的网格边界,若越界则将对应的速度分量取反(连续模型),或反转其方向(离散模型)。伪代码示意:
if (bot.x < 0 || bot.x >= ARENA_COLS) bot.heading = Math.PI - bot.heading; if (bot.y < 0 || bot.y >= ARENA_ROWS) bot.heading = -bot.heading;反弹在battling状态下每帧检测,保证机器人始终停留在竞技场内。
碰撞检测与暂停
规格定义了三种碰撞后的行为,必须全部实现:
- 碰撞瞬间暂停:两个机器人相撞时暂停一个瞬间(例如停顿 200–500ms),给玩家看清对决结果的时间;
- 失败者消失:若某机器人自身运算结果(应用到双方布尔值后)为 0,则该机器人从竞技场消失;
- 胜利者继续:赢得碰撞的机器人以原来的速度与方向继续移动;
- 平局继续:双方结果相同(同为 0 或同为 1)时,两个机器人都以原来的速度与方向继续移动。
碰撞检测可以基于 tile 网格进行:当两个机器人落入同一格子即判定碰撞。需要留意一个实现细节:8×8 网格上 4 个机器人理论上可能在同一帧产生多组碰撞,规格只定义了双人碰撞的结算规则,因此多机同格时的处理顺序(例如按机器人编号逐个结算)由开发者自行决定,建议在文档中注明这一设计取舍。
结束条件
- 场上仅剩一个机器人时,游戏循环停止;
- 按钮文本切回
Battle!; - 排行榜应显示最终胜者。
排行榜:胜负统计
规格 Projects/3-Advanced/Boole-Bot-Game.md 对排行榜的定义是:
- 展示每个机器人的胜场(wins)与负场(losses);
- 赢得碰撞的机器人wins 加 1;
- 输掉碰撞的机器人losses 减 1(注意:规格原文措辞是"decremented",即"递减"。如果从 0 开始递减会出现负数,实践中更常见的做法是"输家 losses 加 1";这是规格原文的措辞细节,实现时请自行决定最合理的语义,并在交付说明中注明你的选择)。
排行榜建议与碰撞裁决事件联动:每次resolveCollision返回非平局结果时,同时更新双方统计并触发排行榜重渲染。进阶特性还要求"胜场最多的机器人以某种方式高亮",这可以在排行榜数据驱动渲染时通过比较wins最大值实现。
从用户故事归纳的整体状态机与事件流
综合配置面板、游戏控制、竞技场与排行榜四部分用户故事,可以归纳出完整的运行时状态机(以下内容属于从规格推导的设计建议,非规格原文,实现时可酌情调整):
idle ──(点击 Battle!)──▶ battling ──(只剩一个机器人)──▶ gameOver ▲ │ │ └────────(点击 Stop!)──────┘ │ └───────────────────────(重开新局)───────────────────────┘对应的事件流为:
- 配置阶段:用户完成 4 个机器人的名称/布尔值/运算/速度/方向输入,机器人随机落位;
- 点击
Battle!:状态进入battling,按钮变为Stop!,启动游戏循环; - 每帧:推进机器人位置 → 边界反弹检测 → 碰撞检测;
- 碰撞触发:双方暂停 →
resolveCollision裁决 → 失败者消失/胜利者与平局方恢复移动 → 更新排行榜; - 场上剩 1 个机器人:状态进入
gameOver,按钮变回Battle!。
约束、技术选型与工程化建议
允许使用图形与物理库
规格的 Constraints 明确允许使用图形库与游戏物理库。结合本仓库其他游戏项目的参考实现可见,可选方案包括:
- 原生 HTML5 Canvas + requestAnimationFrame:适合想深入理解游戏循环、碰撞检测与渲染原理的开发者;
- p5.js:轻量、上手快,适合快速搭建 2D 动画(仓库中 Shell-Game 的"画布 + 动画 + 交互"模式与本项目高度相似);
- Phaser 等游戏框架:内置精灵、物理与场景管理,适合想聚焦规则设计而非底层渲染的开发者。
规格同时指出"可以从原生实现中获得更多收获"的理念(见 Bug-Race-Game 对动画库的类似建议),因此优先推荐使用语言原生特性实现核心逻辑。
逻辑与表现分离
本项目最值得工程化的地方,是把布尔裁决引擎做成一个与渲染完全解耦的纯逻辑模块:
- 机器人数据模型(名称、布尔值、运算、速度、方向、坐标、胜负统计)独立于任何 UI 类型;
evaluate/resolveCollision作为纯函数,可直接用断言驱动测试;- 游戏循环只负责"移动 + 碰撞检测 + 调用裁决",并把结果广播给渲染层和排行榜。
这种"引擎可被任意表现层复用"的架构,正是仓库中 Battleship-Game-Engine 明确倡导的模式——先实现可调用的引擎,再实现一个薄薄的表现层用于测试与演示。
可测试的边界场景
建议至少覆盖以下测试用例:
AND(1,1)=1方获胜,AND(1,0)=0方消失;OR(0,1)=1方获胜;- 两个 XOR 机器人碰撞恒为平局;
- 两个运算结果同为 0 或同为 1 时为平局;
NOT机器人结果为其自身布尔值的反转;- 名称重复时校验函数返回错误;
- 随机落位永不重叠。
进阶特性(Bonus Features)
规格 Projects/3-Advanced/Boole-Bot-Game.md 提供了 6 个进阶特性,均在完成基础用户故事之后可选实现:
- 日志面板(Log panel):展示游戏里程碑(战斗开始、碰撞发生、胜负结果、最终胜者等)。规格特别提示这对开发与调试阶段很有价值——例如在
resolveCollision每次调用时追加一条日志,可以快速定位规则实现的偏差; - 游戏时钟(Game clock):显示当前已进行的游戏时间,每秒更新一次,从
battling状态开始时计时,暂停与结束时停止; - 八方向起始方向:将方向选项从四个基本方向扩展为 North、Northeast、Southeast、South、Southwest、West、Northwest(即 45° 为步进的全方位),注意东-西向量与网格的对应关系需要自行定义清楚;
- 可配置竞技场尺寸:将固定的 8×8 抽象为可配置的行列数参数,意味着随机落位、边界反弹、结束条件等全部逻辑都要改为参数驱动;
- 图标面板(Icon palette):允许用户从图标面板为机器人选择唯一图标,一旦某图标被选中即禁用,防止重复——这与 Bug-Race-Game 的图标唯一性约束一致;
- 排行榜高亮:对胜场最多的机器人以某种方式(颜色、加粗、图标等)进行高亮展示。
分阶段开发路线与验收清单
结合用户故事的依赖关系,推荐按以下阶段递增式开发:
| 阶段 | 内容 | 对应用户故事 |
|---|---|---|
| 1 | 数据模型 + 配置面板(4 机器人、名称校验、布尔值/运算/速度/方向控件、随机落位) | 配置面板全部故事 |
| 2 | 竞技场渲染 + 机器人移动 + 边界反弹 | 竞技场移动/反弹故事 |
| 3 | 碰撞检测 + 布尔裁决 + 胜负/平局结算 | 竞技场碰撞全部故事 |
| 4 | Battle!/Stop! 控制 + 结束条件 | 游戏控制全部故事 |
| 5 | 排行榜胜负统计 | 排行榜全部故事 |
| 6 | 进阶特性逐项实现 | Bonus 全部故事 |
最终验收时,可将规格文档中的用户故事逐条转译为测试与手工验收项(以下为完整清单,覆盖 Projects/3-Advanced/Boole-Bot-Game.md 的全部要求):
- 游戏窗口包含:配置输入面板、排行榜、游戏控制、8×8 竞技场
- 配置面板含 4 个机器人面板:唯一名称、布尔值、运算、速度滑块、方向下拉(N/S/E/W)
- 名称文本框可输入唯一名称;重复时显示错误信息
- 布尔值下拉框可选 0 或 1
- 运算下拉框可选 AND / OR / XOR / NOT
- 速度滑块可调节机器人速度
- 方向下拉框可选择起始方向
- 名称定义后机器人随机落到竞技场格子中
- 提供
Battle!按钮;点击开始对战 - 对战中机器人按分配的速度与方向移动
- 战斗开始后按钮文本变为
Stop! - 点击
Stop!暂停游戏 - 只剩一个机器人时按钮文本变回
Battle! - 机器人撞到边界墙后以新方向反弹
- 机器人碰撞时暂停一个瞬间
- 自身运算结果(应用到双方布尔值后)为 0 的机器人碰撞后消失
- 赢得碰撞的机器人以原速度、原方向继续移动
- 平局时双方以原速度、原方向继续移动
- 仅剩一个机器人时游戏停止
- 排行榜显示每个机器人的胜场与负场
- 获胜机器人的胜场 +1
- 失利机器人的负场 -1
- 【Bonus】日志面板展示游戏里程碑
- 【Bonus】游戏时钟每秒更新已进行的游戏时间
- 【Bonus】起始方向支持八方向
- 【Bonus】竞技场尺寸可配置
- 【Bonus】图标面板提供唯一图标选择,被选图标禁用
- 【Bonus】排行榜高亮胜场最多的机器人
仓库文档约定与进一步资源
- 项目规格原文:Projects/3-Advanced/Boole-Bot-Game.md;
- 项目分级体系与完整项目列表:README.md(Tier-1 至 Tier-3 的分级说明与全部项目索引);
- 本仓库各项目文档的统一模板与写作约定:Example Guide(目标描述 → 用户故事 → Bonus → 资源链接 → 示例项目);
- 引擎/表现层分离架构的姊妹项目参考:Battleship-Game-Engine;
- 动画与游戏循环相关项目参考:Shell-Game(画布动画)、Bug-Race-Game(速度配置、名称/图标唯一性校验);
- 社区贡献方式:CONTRIBUTING.md。
规格文档中 "Useful links and resources" 一节原本推荐了三类公开资料主题:乔治·布尔(George Boole)与布尔代数的背景知识,以及"视频游戏物理教程——刚体动力学入门"这一篇面向碰撞/反弹实现的经典资料;"Example projects" 一节当前标记为 N/a,即尚未收录示例实现,因此本项目没有现成参考代码可以直接照搬,你需要依据本文的规则模型与开发路线从零构建。
总而言之,Boole Bots Game 是一个"规则简单、工程挑战充足"的高级项目:布尔裁决引擎只占几十行纯函数,但移动模型、边界反弹、碰撞时序、状态机、排行榜与六个进阶特性组合起来,足以完整锻炼你的游戏循环设计、分层架构与测试能力。建议先从纯逻辑的resolveCollision写起,用测试把真值表锁死,再逐步加上渲染与交互,最终交付一个既好玩又能当布尔代数教具的完整游戏。
- 文档
- 教程
【免费下载链接】app-ideas
A Collection of application ideas which can be used to improve your coding skills.
相关推荐
xLearn:5-13倍提速的高性能机器学习包完整指南
xLearn:5 13倍提速的高性能机器学习包完整指南 xLearn 是一个高性能、易用且可扩展的机器学习包,专为处理大规模稀疏数据而设计。它支持线性模型(LR
Web-Dev-For-Beginners 太空游戏系列实战作业:用矩形碰撞检测亲手打造碰撞迷你游戏
Web Dev For Beginners 太空游戏系列实战作业:用矩形碰撞检测亲手打造碰撞迷你游戏 本作业承接 太空游戏第四课「添加激光与碰撞检测」 http
文档教程前端3步提升IsaacLab机器人碰撞检测性能的实战指南
3步提升IsaacLab机器人碰撞检测性能的实战指南 IsaacLab作为NVIDIA Isaac Sim上的统一机器人学习框架,在机器人仿真中发挥着重要作用。
人工智能强化学习机器人具身智能深度学习
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考