用 Rails 后端构建照片标记游戏Wheres Waldo 全栈实战指南【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum导读本篇指南围绕开源课程仓库中的经典综合项目展开使用 Ruby on Rails 作为后端、原生 JavaScript 作为前端从零构建一个「照片标记Photo Tagging」游戏——玩家需要在复杂照片中找出指定角色点击位置、弹出瞄准框、选择角色并经后端校验是否正确。读完本文你将掌握前后端分离协作的完整流程如何规划数据结构、如何用 AJAX 让前端 JavaScript 与 Rails JSON API 通信、如何在服务端计时防止作弊、如何记录匿名用户成绩最终交付一个可部署的完整应用。项目背景玩过找 Waldo吗如果小时候玩过《Wheres Waldo》威利在哪里系列绘本你一定对它的玩法不陌生一张拥挤热闹的大插画里藏着大量人物、物体和场景你要从中找到那个标志性角色 Waldo。本项目的目标就是把这种游戏体验搬到网页上——构建一个与照片标记 App体验高度一致的 Web 应用你准备一张大照片照片中包含若干玩家需要寻找的角色Waldo、The Wizard、Wilma……如果用自定义照片也可以自己命名角色玩家对每个角色进行选择应用给出正确与否的反馈。这个项目之所以特殊在于它是前期所学知识的总决算——来自 archive/old_lessons/javascript/project_rails_backend.md 的原文档开篇即指出This project will finally give you a chance to tie together everything youve learned so far.你需要同时驾驭前端的交互逻辑点击定位、弹框、标记与后端的校验、计时、持久化。项目复杂度不低所以官方建议一次只走一步take it one step at a time先在纸上或白板上把整体流程想清楚再动手编码。核心需求拆解一个全栈交互闭环动手之前先把产品需求拆成几个明确的模块。这既是项目规划也对应着后续每一步的实现目标。1. 照片与角色的坐标数据入库项目的第一步是选定一张照片并预先确定每个角色在这张照片中的精确位置把这些坐标保存到数据库中。这是整个校验逻辑的地基——后端判断对错的依据全部来自这份预置数据。2. 点击照片 → 弹出瞄准框当玩家点击照片时前端应在点击位置附近放置一个瞄准框targeting box框内列出所有可能的角色一个下拉菜单。点击照片以外的区域则收起瞄准框。3. 选择角色 → 后端校验 → 反馈玩家从瞄准框中选择某个角色后前端把点击坐标 角色标识发送给后端由 Rails 后端判断该角色是否真的位于瞄准框覆盖的范围内校验错误给玩家明确的错误提示error message校验正确在照片上该角色的真实位置放置一个永久标记marker。无论结果如何瞄准框都要被移除等待玩家下一次点击。4. 服务端计时与成绩记录游戏需要记录照片首次加载完成到玩家找齐全部角色之间所花的时间。原文档特别强调计时必须在服务端完成——如果放在前端玩家可以篡改自己的成绩hack their score。一轮游戏结束后弹窗询问玩家姓名并把名字和用时写入高分榜high scores table。这带来一个附带难点需要为匿名用户未登录玩家持续追踪其游戏进度。5. 可玩性与完成度找齐所有角色、看到自己的名字进入高分榜游戏即算完成。原文档还提供了一个可选扩展在数据库中加载多张照片允许玩家在开始游戏前自由选择。为什么用 Rails 做后端课程上下文在本仓库的课程编排中这个项目位于 JavaScript 课程的JavaScript 与后端环节其前置知识是 Ruby on Rails 全栈课程。配套的 archive/old_lessons/javascript/rails_backend.md 说明了选择 Rails 的动机你已经掌握了 Rails 技能可以自主构建一个能够处理JSON 请求的后端学习目标之一是练习用AJAX让前端 JavaScript 与 Rails 后端通信掌握两者之间传递数据的最佳实践虽然可以把后端外包给 Backend-as-a-ServiceBaaS如 Firebase但你已经具备了自己动手的能力因此本项目坚持自己用 Rails 搭建。配套文档 archive/javascript/javascript_and_the_backend/using_rails_for_your_backend.md 还点明了为什么需要真后端Local Storage 只能把数据存在玩家当前这台电脑上换一台设备就失忆要跨设备记住用户状态与成绩必须有一个真正的服务端。本项目的 Rails 后端正是承担这一职责。数据模型与系统架构设计从源码结构来看本项目没有提供现成的参考实现解决方案以学员提交的 GitHub 仓库形式存在因此以下数据模型属于基于需求的合理设计推断供你规划时参考Character角色name角色名x、y坐标或归一化坐标 所属照片 ID表示该角色在照片中的精确位置Photo照片照片资源路径以及该照片包含的字符集合Game / Round游戏局一次游戏会话记录照片 ID、开始时间、匿名玩家标识Score / HighScore成绩玩家姓名 完成用时秒用于高分榜排序。整体数据流如下玩家点击照片 │ ▼ 前端定位点击坐标 → 归一化坐标 → 弹出瞄准框 角色下拉菜单 │ ▼ 玩家选择角色 → AJAX POST坐标 角色 ID→ Rails API │ │ │ 校验坐标是否命中角色真实位置 │ │ ◀────────── JSON 响应正确/错误────────────┘ │ ▼ 正确 → 照片上放置永久标记错误 → 显示错误提示均收起瞄准框 │ ▼ 全部角色找齐 → 请求服务端结束计时 → 弹窗输入姓名 → 写入高分榜关键设计决策依据原文档的明确要求校验逻辑必须放在后端坐标是否命中、角色是否属于该位置由 Rails 判定前端只负责展示结果计时必须放在服务端开始时间在照片加载时由服务端记录或记录于会话结束时间在全部角色找齐时上报避免前端伪造成绩匿名用户追踪没有登录体系需要用 session 或客户端生成的临时标识把谁正在玩哪一局关联起来。分步实现指南九步走完整个项目原文档给出的作业步骤Assignment是项目推进的主线共 9 步每一步都承接上一步的成果。下面按顺序展开并补充每一步的实现要点。第 1 步建立 GitHub 仓库为项目创建一个新的 GitHub 仓库并完成初始提交。如果对 git 基础不熟可参考本仓库的 Git 基础课程 git/foundations_git/git_basics.md 与 git/foundations_git/introduction_to_git.md 复习。第 2 步先在纸上把全流程想清楚这是官方反复强调的一步A few minutes of thought can save you from wasting an hour of coding.想几分钟能省下编码一小时。建议画出上文的架构流程图明确以下问题每个角色的坐标存成什么格式像素坐标还是百分比瞄准框的判定区域有多大以点击点为中心的固定半径还是框内矩形前端与后端各提供哪些 API 端点、交换什么 JSON 结构第 3 步创建最小可用的 Rails 应用用rails new生成一个新应用现阶段只需要能加载你的 HTML 页面这个最小骨架即可不要急着写业务逻辑。按 archive/old_lessons/javascript/rails_backend.md 的提示这一步应该先回顾 Rails 如何构建能处理 JSON 请求的 API可对照本仓库的 ruby_on_rails/apis/apis_and_building_your_own.md 复习确保后续的校验接口有正确的基础。第 4 步先做纯前端功能不碰后端在完全没有后端调用的情况下实现前端的交互骨架玩家点击照片时在点击位置弹出瞄准框和角色下拉菜单玩家点击照片以外区域时收起瞄准框角色菜单的打开/关闭状态管理。这一步的价值在于把前端交互与后端数据彻底解耦之后接入 API 时只需替换校验这一环节无需重构交互层。第 5 步接入后端校验现在把校验逻辑接到 Rails 后端前端把点击坐标与所选角色发给后端由后端判断是否命中该角色的真实位置并返回正确/错误的结果。配套文档 archive/old_lessons/javascript/rails_backend.md 建议此时重温 Rails AJAX 用法来自 Rails Guides 的Working with JavaScript in Rails章节可略读前几节并用 AJAX 发起校验请求。第 6 步整合前后端把校验流程无缝接回前端交互玩家选择角色 → 前端发请求 → 后端返回结果 → 正确则在地图对应位置放置标记错误则提示。整个闭环应该一气呵成交互无卡顿。第 7 步计时、成绩与高分榜页面首次加载时开始计时由服务端记录开始时间防止篡改玩家成功识别全部角色时结束计时展示其分数用时若成绩够格进入高分榜弹出输入框让玩家填写姓名记录该用时。第 8 步试玩反复测试各种边界情况连续点击、选错角色、快速找齐所有角色、刷新页面后成绩是否仍然存在等。第 9 步推送并提交把解决方案推送到 GitHub 并部署上线然后提交你的解决方案链接。这标志着一个完整项目的收官。关键技术点详解一瞄准框、下拉菜单与坐标归一化瞄准框与下拉菜单的交互模式这是前端部分的核心交互。玩家点击照片后前端根据事件坐标在照片的对应位置渲染一个瞄准框框内或框旁是角色列表的下拉菜单。菜单的生命周期受两次点击驱动点击照片打开再次点击或点选角色关闭。坐标系的陷阱不同屏幕尺寸坐标不同在新版项目文档 react/react_and_the_backend/project_wheres_waldo_a_photo_tagging_app.md 中官方明确提示了一个实战中的大坑Depending on how you are getting the coordinates of a users clicks, different screen sizes may produce different coordinates. This could cause your app to record coordinates properly on a large screensize, but not smaller ones.也就是说如果直接使用浏览器事件给出的像素坐标在大屏上点击记录的位置可能与小屏上不一致——因为在不同屏幕尺寸下照片的实际渲染尺寸会变化。为此需要在点击逻辑中加入坐标归一化把点击坐标换算为相对于照片本身的百分比或与照片原始像素尺寸的比值数据库中也以归一化坐标存储角色位置。校验时把点击的归一化坐标与存储的角色归一化坐标比较命中判定即与屏幕尺寸无关。关键技术点详解二Rails JSON API 与 AJAX 通信让 Rails 既能渲染页面、又能响应 JSON在控制器动作中Rails 可以同时响应 HTML 与 JSON 格式典型写法是def validate # 伪代码接收坐标与角色 ID返回命中结果 if character_at?(params[:x], params[:y], params[:character_id]) render json: { correct: true } else render json: { correct: false, message: Thats not Waldo! } end end前端则用 AJAXfetch或 jQuery$.ajax把校验请求发给这个端点并处理返回的 JSON。前端如何加载自定义 JavaScript配套文档 archive/old_lessons/javascript/rails_backend.md 中引用的学习资源强调了一个实践要点在 Rails 的某个视图页面中按需加载自定义 JS。你既可以把游戏逻辑放进app/assets/javascripts由 asset pipeline 统一打包也可以在需要该功能的视图里通过content_for机制按页注入脚本避免所有页面都加载游戏代码。Unobtrusive JavaScript非侵入式 JavaScript这是 Rails 官方推荐的实践核心思想是让 JavaScript 不依赖内联的事件属性如onclick而是通过选择器绑定事件、渐进增强页面行为。对本项目而言意味着用事件监听器绑定照片的点击行为把数据通过data-*属性或 JSON 引导注入而不是把游戏数据硬编码进 HTML。CSRF token 的正确处理Rails 默认开启 CSRF 防护前端用 AJAX 发起 POST 请求如提交校验结果或成绩时必须携带 CSRF token否则 Rails 会报Warning, cant verify CSRF token authenticity。常规做法是从页面中的csrf-tokenmeta 标签读取 token并把它加到请求头如X-CSRF-Token中——这是从 Rails 后端向 JavaScript 发起的每个写操作都绕不开的一步。Bootstrapping JSON 数据进视图为了让前端拿到角色列表 角色真实坐标等初始数据可以在 Rails 视图渲染时把数据以 JSON 形式引导bootstrap到页面中例如写入一个script typeapplication/json标签或data-*属性前端直接读取避免额外一次异步请求。配套文档 archive/javascript/javascript_and_the_backend/using_rails_for_your_backend.md 将如何把数据从 Rails 应用传给 JavaScript列为明确的学习目标。为什么用 AJAX 加载大批量数据如果一次把全部照片、全部角色、全部坐标都塞进初始 HTML页面体积会急剧膨胀、首屏变慢。更优的做法是用 AJAX 按需拉取例如选好某张照片后再加载该照片的角色坐标这正是配套文档要求你理解为何用 AJAX 加载大批量数据的原因——本项目中可选扩展多张照片场景尤其适用。关键技术点详解三服务端计时、匿名用户与高分榜服务端计时防作弊原文档明确要求计时逻辑放在服务端否则玩家可以篡改分数。实现思路游戏开始时照片首次加载服务端或借助 session记录开始时间前端在玩家找齐全部角色后向服务端请求结束计时并结算由服务端计算真实用时。这样即使玩家修改前端代码也无法伪造一个更短的用时。匿名用户追踪本项目没有登录系统玩家在游戏中途刷新或重新进入时需要能继续追踪进度。可以推断的可行方案为每个游戏会话生成一个临时标识session ID 或前端生成的 UUID所有已找到角色的记录都挂在会话维度服务端据此判断还剩哪些角色没找到并在结算时把成绩关联到该会话。这既是数据结构设计问题也是前后端 API 设计的重点。成绩弹窗与高分榜一轮完成时前端弹出输入框请求玩家姓名将姓名 用时POST 给 Rails 后端写入数据库高分榜页面向后端请求并按用时升序渲染榜单。可选扩展多照片选择原文档的 Optional Extensions 提出一个扩展方向Load many images into your database and allow your use to select from among them before starting the game.实现要点为Photo与Character建立关联游戏开始前先展示照片列表供玩家选择选中照片后再由前端建议通过 AJAX拉取该照片的角色与坐标数据。这一扩展同时考验了按需加载大批量数据的能力是对上文 AJAX 应用场景的实战巩固。完成标准与部署建议按照原文档的验收口径项目完成的标志是玩家点击照片能弹出瞄准框与角色下拉菜单点击别处能收起选择角色后能收到后端校验反馈正确时在对应位置放置标记服务端计时准确完成后能记录玩家姓名与用时并展示高分榜整个流程流畅可玩代码已推送至 GitHub 并部署上线。部署方面本项目属于前后端一体的 Rails 应用可直接部署到支持 Ruby 的 PaaS 平台如 Heroku 等若选择前后端分离架构Rails API 独立前端则需分别部署并把 Rails API 的地址配置到前端环境中。本仓库的 nodeJS/express/deployment.md 与 ruby_on_rails/rails_basics/deployment.md 可作为部署思路的参考。最后正如原文档的结语所言——This is a serious project, congratulations!——当你完成它意味着你已经能把前端交互、后端 API、数据持久化与安全防作弊串成一条完整的链路这正是一个真实的 Web 开发者在工作中每天都在做的事。【免费下载链接】curriculumThe open curriculum for learning web development项目地址: https://gitcode.com/GitHub_Trending/cu/curriculum创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考