简介：围绕“麦田物语”主题搭建的Unity课程设计项目，适合高校学生、毕业设计选题者及Unity初学者用作完整案例参考，可帮助理解2D游戏项目从资源组织到场景配置的基本流程。压缩包共2007个文件，约109.8MB，以meta、png、asset、anim等资源为主，包含贴图、动画、音频、配置与预制体等素材，并带有Unity工程所需的场景、控制器、混音器、PDF说明及少量txt、json配置，目录模块较完整，便于按资源类型检索与复用。已有288人学习，说明该案例具备一定参考价值。读者可从中查看主题美术资源、角色下落与旋转、树木状态变化等动画片段，以及音频配置和项目结构组织方式，用于课程设计复现、功能拆解和资源替换练习，也能为毕业设计中的场景搭建、动画状态配置与资源参数管理提供可直接借鉴的工程样本。

1. 麦田物语主题课程设计：种地玩法谁都懂，时间结算才是分水岭

每年课程设计选题公布那阵子，农场经营类题目总能收到一堆报名：种地、浇水、收获、卖钱，规则谁都懂，画个格子就能开工。真坐下来写两周才发现，出问题的地方往往不在画面，而在时间。一天怎么结算、浇水和生长怎么挂钩、存档读回来作物还记不记得自己长到第几天，这些问题在答辩现场被追问三句就露底。

基于麦田物语主题的课程设计项目，本质是把一套轻量模拟经营玩法压进一到两周的开发周期，用可控的代码量交出能跑、能讲、能改参数的东西。下面按模块拆分、最小循环、状态机与存档、排查清单的顺序走一遍，适合正在赶课程设计、或者想拿这类题材做前期原型的人。

2. 把麦田物语拆成可验收模块：六块职责与三张数据表

课程设计和产品开发最大的差别是验收方式。产品看留存，课程设计看的是你能不能在三五分钟的演示里把一条完整链路跑通，并且被问到任何一处时都能指出对应的代码位置。所以拆模块的第一原则不是“功能全”，而是“每块都能单独讲”。常见做法是先列玩法清单，再往回倒推数据结构，最后才决定画什么。

2.1 玩法清单收敛成六个模块

刚上手时很容易把清单列成一篇小作文：种地、浇水、施肥、钓鱼、养鸡、NPC 好感、节日活动、天气。写到第三天就会发现，光是天气和作物状态联动就能吃掉一半时间。我一般的做法是划一条线，凡是不能在同一条演示链路里被点到的功能，一律砍到二期。

留下的六个模块，每个都有明确的职责边界和可验收点：

这张表的用法是：答辩前逐行过一遍，每行都能打开文件指给人看。扛不住的模块就合并或者删掉，别留半成品在那儿，半成品是最容易被追问的地方。

依赖关系也有讲究。时间系统和地块网格必须做成零依赖的纯数据层，不能 import pygame。原因很实际——纯数据层可以在命令行里跑单元测试，不需要开窗口。等到后期调生长曲线时，你会发现能在 REPL 里直接构造一个GameClock往前推 200 天，比开窗口等时间快一百倍。

2.2 时间是唯一真相：累计 tick 派生天数与季节

新手最容易踩的坑是把时间拆成好几个字段：day、hour、season、year各存一份，每帧各自加。跑起来没问题，一旦跨天、跨季、读档，就会出现“天数加了季节没加”“小时归零了天没进”这类不同步。这类 bug 极难复现，属于典型的玄学问题。

稳妥的写法是只存一个累计 tick，其余全部用属性派生：

# core/clock.py from dataclasses import dataclass, field SEASONS = ["spring", "summer", "autumn", "winter"] DAYS_PER_SEASON = 14 # 一季 14 天，课程设计够用 TICKS_PER_DAY = 60 # 一个游戏天切成 60 个 tick REAL_SECONDS_PER_TICK = 2.0 # 每个 tick 对应 2 秒真实时间 @dataclass class GameClock: total_tick: int = 0 # 唯一真相：开局以来的累计 tick _acc: float = field(default=0.0, repr=False) @property def tick_of_day(self) -> int: return self.total_tick % TICKS_PER_DAY @property def day_index(self) -> int: return self.total_tick // TICKS_PER_DAY @property def season_index(self) -> int: return (self.day_index // DAYS_PER_SEASON) % len(SEASONS) @property def season_day(self) -> int: return self.day_index % DAYS_PER_SEASON @property def season(self) -> str: return SEASONS[self.season_index] def advance(self, dt: float) -> int: """推进时钟，返回本次跨过了几个游戏天（可能为 0 或大于 1）。""" self._acc += dt passed = 0 while self._acc >= REAL_SECONDS_PER_TICK: self._acc -= REAL_SECONDS_PER_TICK self.total_tick += 1 if self.total_tick % TICKS_PER_DAY == 0: passed += 1 return passed

这段的核心是_acc这个浮点累积器。dt是上一帧到这一帧的真实秒数，直接加到累积器里，只有当累积器攒够REAL_SECONDS_PER_TICK才推进一个 tick。为什么必须用while而不是if：如果某一帧卡顿了两秒，累积器一次可能攒够两三个 tick 的量，用if会漏掉，表现为“游戏时间比真实时间慢，而且越卡越慢”。

advance的返回值是这次跨过的天数，这个设计很关键。跨天结算必须由调用方显式触发，绝不能写在tick_of_day == 0的某处判断里，否则低帧率下一次跨两天只结算一次，作物就少长一天。把所有日结逻辑收口到一个函数，是后面排查问题的前提。

参数怎么改：想让演示时一天过得快一点，把REAL_SECONDS_PER_TICK从 2.0 调到 0.5，一天从 120 秒变成 30 秒；想让季节变化更明显，把DAYS_PER_SEASON从 14 调到 7。这两个值都是模块级常量，改完立刻生效，不需要动任何逻辑代码。

提示：TICKS_PER_DAY和REAL_SECONDS_PER_TICK一起决定一天的时长，改的时候两个都过一遍，别只改一个导致 UI 上的时刻显示对不上。

2.3 作物参数放 JSON：改数值不用改代码

课程设计答辩有个高频环节叫“现场改参数”。老师看着屏幕说“你这个长得太快了”，你如果得回去翻代码找那个硬编码的if growth > 3，场面会比较尴尬。把作物参数抽成外部文件，改完保存重跑就行，这个动作本身就是加分项。

data/crops.json长这样：

{ "wheat": { "name": "小麦", "stage_days": [1, 2, 3], "seed_price": 10, "sell_price": 35, "regrow": false, "seasons": ["spring", "autumn"], "sprite_prefix": "wheat" }, "strawberry": { "name": "草莓", "stage_days": [2, 2, 2, 2], "seed_price": 40, "sell_price": 18, "regrow": true, "seasons": ["spring"], "sprite_prefix": "strawberry" } }

stage_days是每个阶段需要的有效生长天数，长度就是阶段总数。小麦三个数字表示三阶段：发芽 1 天、生长 2 天、成熟 3 天，累计 6 天可收。草莓四个阶段各 2 天，累计 8 天，但regrow为 true，收完会回退到倒数第二阶段继续长。

加载时要顺手做一次预计算，把“每阶段天数”累加成“累计阈值”：

# core/crop_data.py import json from pathlib import Path _CACHE = None def load_crop_table(path: str = "data/crops.json") -> dict: global _CACHE if _CACHE is None: with open(Path(path), encoding="utf-8") as f: raw = json.load(f) _CACHE = {k: _normalize(v) for k, v in raw.items()} return _CACHE def _normalize(entry: dict) -> dict: entry = dict(entry) entry.setdefault("regrow", False) entry.setdefault("seasons", ["spring", "summer", "autumn"]) acc, thresholds = 0, [] for d in entry["stage_days"]: acc += d thresholds.append(acc) entry["stage_thresholds"] = thresholds # 例：[1, 3, 6] entry["total_days"] = acc return entry

为什么要预计算阈值：生长判断在日结里每天对每个地块跑一次，如果每次都去累加stage_days的前 N 项，等于每帧做一次 O(n) 求和。换成阈值后，判断退化成一次整数比较growth >= stage_thresholds[stage]。这个优化在十几个地块上看不出来，但当你把田扩到 16×12 = 192 块时，差距就体现出来了。

_CACHE的用法是模块级缓存，第一次读盘之后就不再碰文件。调试阶段如果改了 JSON 想立刻看到效果，需要重启进程；如果嫌麻烦，在load_crop_table开头加一句_CACHE = None强制重读，正式演示前记得删掉——留着会导致每次日结都读盘，卡顿很明显。

2.4 地块用一维数组存，索引换算集中在两个函数里

地块的存储方式有两种：二维列表tiles[row][col]，或者一维列表tiles[row * COLS + col]。前者直观，后者在存档和遍历时更省事，而且和渲染的绘制顺序天然对齐。我一般选一维。

# core/grid.py from dataclasses import dataclass TILE_W, TILE_H = 48, 48 COLS, ROWS = 16, 12 @dataclass class Tile: tilled: bool = False # 是否已开垦 watered: bool = False # 今天是否浇过水 crop: object | None = None # 作物实例，None 表示空地 def make_tiles() -> list[Tile]: return [Tile() for _ in range(COLS * ROWS)] def index_of(col: int, row: int) -> int: return row * COLS + col def coord_of(index: int) -> tuple[int, int]: return index % COLS, index // COLS

Tile里只放“这块地现在什么状态”，不放作物的生长细节，作物细节全部在Crop对象里。这个拆分的好处是存档时可以分别序列化，读档时也能分两步重建：先铺地块，再往地块上挂作物。如果混在一起写，读档顺序一旦搞错就会出现“作物挂在了没有开垦的地上”这种脏状态。

index_of和coord_of这一对函数是全篇唯一做行列换算的地方。别在渲染、点击、存档里各处手写row * COLS + col，一旦有一处写反，表现就是“点这块地，旁边那块浇水了”，而且因为只错一格，肉眼很难第一时间发现。

3. 用 pygame 跑通最小可玩循环：从主循环到地块点击

数据层铺好之后，剩下的事情是把它接到一个能看的窗口上。这一步的目标不是画面好看，而是把“点一下 → 状态变 → 画出来”这条回路跑通。回路一通，后面所有玩法都是往这个骨架里塞逻辑。

3.1 目录结构与依赖安装

# 目录结构 # mai_tian/ # main.py # config.py # core/ # clock.py # grid.py # crop.py # crop_data.py # inventory.py # save.py # data/ # crops.json # assets/ # tiles.png # crops.png # saves/ # slot1.json python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install pygame python -c "import pygame; print(pygame.version.ver)"

这里只装 pygame 一个第三方依赖，这是刻意的选择。课程设计最怕的是环境装不上，答辩机房的 Python 版本和你的不一样，多一个依赖就多一个现场装包的风险。pygame 单个包就能覆盖窗口、事件、绘制、字体、音频，够用了。图形库层面不要上引擎，上了引擎你讲不清渲染管线，反而丢分。

python -c那行是验证安装，输出一个版本号就说明环境通了。如果报ModuleNotFoundError，先确认虚拟环境激活没有，再确认 pip 和 python 是不是同一个解释器——pip装到了系统 Python、python跑的是虚拟环境，这个错我见过不止一次。

3.2 主循环：累积器推进时钟，日结只在这一处触发

# main.py import sys import pygame from core.clock import GameClock from core.grid import make_tiles, COLS, ROWS, TILE_W, TILE_H, index_of from core.farm import on_click_tile, on_day_end, draw_scene SCREEN_W = COLS * TILE_W SCREEN_H = ROWS * TILE_H + 72 FPS = 60 def screen_to_index(pos: tuple[int, int]) -> int | None: x, y = pos if y < 0 or y >= ROWS * TILE_H or x < 0 or x >= COLS * TILE_W: return None return index_of(x // TILE_W, y // TILE_H) def main() -> None: pygame.init() screen = pygame.display.set_mode((SCREEN_W, SCREEN_H)) pygame.display.set_caption("mai_tian demo") frame_clock = pygame.time.Clock() game_clock = GameClock() tiles = make_tiles() running = True while running: dt = frame_clock.tick(FPS) / 1000.0 for event in pygame.event.get(): if event.type == pygame.QUIT: running = False elif event.type == pygame.MOUSEBUTTONDOWN and event.button == 1: idx = screen_to_index(event.pos) if idx is not None: on_click_tile(tiles[idx], game_clock) passed = game_clock.advance(dt) for _ in range(passed): # 跨几天就结算几次，一天都不能少 on_day_end(tiles, game_clock) draw_scene(screen, tiles, game_clock) pygame.display.flip() pygame.quit() sys.exit(0) if __name__ == "__main__": main()

三个变量名要分清：frame_clock是 pygame 的帧率控制器，game_clock是游戏内时间。这俩混了是很常见的翻车点，一旦把frame_clock.tick(60)的返回值当成游戏时间加，帧率一高游戏时间就飞。

passed那个循环是整段的关键。for _ in range(passed)保证跨 N 天就结算 N 次，哪怕一次卡顿跨了三天，作物也老老实实长三天。如果把on_day_end写成“只有在tick_of_day == 0时调用”，低帧率下就会漏结算，表现是“演示的时候作物长得比在家慢”。

SCREEN_H多留了 72 像素，是给底部状态栏留的，显示天数、季节、余额。别小看这条栏，答辩时老师看的最多的就是它——数字在跳，说明系统活着。

3.3 屏幕坐标到地块索引：两个方向各写一个函数

坐标换算是这类网格项目里最容易出细节问题的地方。鼠标点击拿到的是像素坐标，你要把它变成地块索引，涉及两次整除和一次边界检查。

def screen_to_index(pos: tuple[int, int]) -> int | None: x, y = pos if y < 0 or y >= ROWS * TILE_H or x < 0 or x >= COLS * TILE_W: return None return index_of(x // TILE_W, y // TILE_H) def index_to_rect(idx: int) -> pygame.Rect: col, row = idx % COLS, idx // COLS return pygame.Rect(col * TILE_W, row * TILE_H, TILE_W, TILE_H)

screen_to_index里的边界判断顺序别调。要先判断y再判断x，因为底部状态栏占据的是y >= ROWS * TILE_H的区域，如果先判x就判断不到这个越界。返回None而不是随便给个 0，是为了让调用方明确知道“这次点击无效”，而不是默默地把 0 号地块浇了水。

index_to_rect是反方向，渲染时用。这两个函数必须成对存在，且只在grid.py里定义一次。我见过把index_to_rect的逻辑在渲染循环里手写一遍的代码，结果某次改了TILE_W忘了改另一处，点击和显示整体错位半格，调试了半天。

注意：窗口如果做了缩放（比如用pygame.transform.scale放大画面），点击坐标必须先按缩放比例反算回逻辑坐标，否则整个田会整体偏移。课程设计建议干脆不做缩放，固定SCREEN_W、SCREEN_H，省掉这类问题。

3.4 渲染分三层：地面、作物、UI

绘制顺序决定遮挡关系，定死了就别乱动：

def draw_scene(screen, tiles, game_clock): screen.fill((92, 132, 78)) # 第一层：底色 for idx, tile in enumerate(tiles): # 第二层：地块 + 作物 rect = index_to_rect(idx) color = (120, 88, 56) if tile.tilled else (92, 132, 78) if tile.watered: color = tuple(max(0, c - 24) for c in color) pygame.draw.rect(screen, color, rect, border_radius=4) if tile.crop is not None: draw_crop(screen, rect, tile.crop) draw_hud(screen, game_clock) # 第三层：状态栏

tile.watered用整体压暗 24 的方式表示浇水，是最省事的占位方案。等素材到位了再换成贴图，逻辑一行不用改。这种“先用色块占位、后替换素材”的做法在课程设计里非常实用，因为你的时间应该花在状态机和存档上，不是花在找图。

draw_crop里根据crop.stage选不同的绘制高度或者颜色，阶段 0 画一个小点，阶段末画满格。这样即使没有任何美术素材，演示时也能肉眼看出生长过程。答辩现场，能看到“东西在变”比“画面好看”重要得多。

状态栏放在最后画，保证它盖在所有地块之上。HUD 的坐标要写死在地块区域之外（y >= ROWS * TILE_H），别用地块坐标算，否则改了ROWS就会压住最后一行。

4. 作物状态机与存档：答辩追问最多的两块怎么落

前两章搭的是骨架，这一章填的是肉。生长规则和存档格式是这类项目里唯二会被反复追问的地方，因为前者体现你对状态建模的理解，后者体现你有没有想过“程序关了之后会怎样”。

4.1 生长按“有效浇水天数”推进，而不是自然天数

最直觉的写法是“种下去过了 N 天就成熟”，代码量最少，但这样浇水就没意义了，玩法链条断掉。要让浇水有作用，生长就必须按“有效生长天数”算——只有当天浇过水，这一天才算数。

# core/crop.py from dataclasses import dataclass from core.crop_data import load_crop_table DRY_LIMIT = 3 # 连续 3 天没浇水就枯死 @dataclass class Crop: crop_id: str growth: int = 0 # 累计有效生长天数 stage: int = 0 # 当前阶段索引，0 表示种子 dry_days: int = 0 # 连续未浇水天数 harvestable: bool = False dead: bool = False def advance_one_day(crop: Crop, watered: bool) -> None: """日结时对单个作物推进一步。watered 为地块当天的浇水状态。""" if crop.dead or crop.harvestable: return cfg = load_crop_table()[crop.crop_id] thresholds = cfg["stage_thresholds"] if watered: crop.growth += 1 crop.dry_days = 0 while crop.stage < len(thresholds) and crop.growth >= thresholds[crop.stage]: crop.stage += 1 crop.harvestable = crop.stage >= len(thresholds) else: crop.dry_days += 1 if crop.dry_days >= DRY_LIMIT: crop.dead = True

growth和stage是两个不同粒度的状态。growth是连续量，stage是离散量，由growth跨越阈值推导出来。为什么要两个都存：growth用于判断，stage用于渲染。如果只存growth，每次画图都要现算阶段，代码里到处是if growth < 1 elif growth < 3，改一次数值要改五个地方。

那个while循环处理的是“一天跨多个阶段”的情况。正常参数下一天最多推一个阶段，但如果某个作物stage_days配成[1, 1, 1]，理论上不会一次跨两级；可一旦你为了演示把某个阶段改成 0 天，while能兜住，if就会卡在中间出不来。多写一层循环不费事。

harvestable单独存一个布尔值，而不是每次比较stage >= len(thresholds)。后者看着更简洁，但读档时如果stage数据损坏（比如手动改了存档），计算出的harvestable会跟着错，而存成字段至少能看出“存档里写的是什么”。调试期这个区别很有用。

4.2 干旱、季节和收获：三个边界规则

规则一，干旱计数只在日结时累加，浇水当天清零。这意味着玩家有一天缓冲，忘了浇一天不会立刻枯死。DRY_LIMIT取 3 是个经验值——取 1 太狠，玩家一次操作失误就毁一茬；取 7 又太松，浇水变成了可有可无的动作。

规则二，季节切换时要判枯萎。春季作物到了夏天，即使浇着水也应该枯掉：

def on_season_change(tiles, new_season: str) -> None: table = load_crop_table() for tile in tiles: crop = tile.crop if crop is None or crop.harvestable: continue allowed = table[crop.crop_id]["seasons"] if new_season not in allowed: crop.dead = True

这里特意放过了harvestable的作物。原因很实际：玩家在季末最后一天种下的作物如果还没收就被季节判死，体验很差。让成熟作物跨季保留，是非成熟作物枯死，规则简单且不容易被投诉。

规则三，可复收作物收获后回退到倒数第二阶段：

def harvest(tile, inventory) -> bool: crop = tile.crop if crop is None or not crop.harvestable: return False cfg = load_crop_table()[crop.crop_id] inventory.add(crop.crop_id, 1) if cfg["regrow"]: thresholds = cfg["stage_thresholds"] crop.stage = len(thresholds) - 2 crop.growth = thresholds[crop.stage] crop.harvestable = False else: tile.crop = None return True

len(thresholds) - 2是倒数第二个阶段的索引，growth同步回填到该阶段阈值，保证growth >= thresholds[stage]成立。如果只改stage不改growth，下一次日结的while会立刻把阶段推回成熟，草莓就变成一秒一收，经济系统直接崩掉。这个 bug 我在第一次写的时候踩过，收获后连点几下屏幕，余额涨到四位数。

4.3 存档把 dataclass 整个摊平，再补一个版本号

存档的核心矛盾是“存少了读不回来，存多了改起来麻烦”。稳妥的做法是把所有游戏状态收进一个字典，版本号写在最外层：

# core/save.py import json from dataclasses import asdict SAVE_VERSION = 2 def collect_state(game_clock, tiles, inventory) -> dict: return { "clock": {"total_tick": game_clock.total_tick}, "tiles": [ { "tilled": t.tilled, "watered": t.watered, "crop": asdict(t.crop) if t.crop is not None else None, } for t in tiles ], "inventory": dict(inventory.items), } def dump(state: dict, path: str) -> None: payload = {"version": SAVE_VERSION, **state} with open(path, "w", encoding="utf-8") as f: json.dump(payload, f, ensure_ascii=False, indent=1) def load(path: str) -> dict: with open(path, encoding="utf-8") as f: payload = json.load(f) ver = payload.get("version", 1) if ver < SAVE_VERSION: payload = _migrate(payload, ver) return payload def _migrate(payload: dict, ver: int) -> dict: if ver == 1: for t in payload["tiles"]: if t.get("crop"): t["crop"].setdefault("dry_days", 0) t["crop"].setdefault("dead", False) payload["version"] = 2 return payload

asdict(t.crop)直接把 dataclass 摊成字典，好处是新增字段不用改存档代码。代价是字段名和 JSON key 强绑定，将来改字段名等于改存档格式，所以版本号和迁移函数必须一起上。

_migrate那段是给答辩准备的。老师看到“版本号 + 迁移函数”这个组合，基本会认为你想过长期维护的问题。哪怕当前只有一版存档，写个占位的if ver == 1也比什么都没有强。setdefault的用法保证老存档读进来能补齐新字段，不会因为KeyError直接崩。

只存total_tick不存day_index和season，是 2.2 节那个设计的直接收益。存档文件里时间是唯一真相，天数和季节读档时现算，永远不会出现“存档里天数是 3、季节是夏天但总 tick 只够春天”这种自相矛盾的数据。

4.4 读档顺序：先时钟、再地块、最后重建索引

def restore(payload: dict): from core.clock import GameClock from core.grid import Tile from core.crop import Crop clock = GameClock(total_tick=payload["clock"]["total_tick"]) tiles = [] for t in payload["tiles"]: c = t.get("crop") crop = Crop(**c) if c else None tiles.append(Tile(tilled=t["tilled"], watered=t["watered"], crop=crop)) return clock, tiles

顺序不能反。时钟先建，因为地块里的作物状态虽然不直接依赖时钟，但读档后第一帧就要advance，没有时钟会直接抛异常。地块按原数组顺序重建，不做任何排序，因为index_of依赖插入顺序，一旦排序，田里的作物会整体错位。

Crop(**c)这种写法要求存档里的 key 和 dataclass 字段名完全一致。加了dry_days字段却没跑迁移，这里会抛TypeError: unexpected keyword argument。所以迁移函数不是可选项，加字段就必须加迁移。

5. 排查清单：麦田物语课程设计里最容易翻车的五个点

下面这几条基本都是我在类似项目里真实踩过的，按“出现频率 × 排查难度”排序。每条按现象、原因、解决三段写，症状对上了直接照着改。

5.1 演示时作物长得飞快，回家跑就正常

现象：在自己的机器上一天 120 秒，到答辩机上十几秒就过了一天，作物哗哗地长。

原因：日结写在了固定帧率的假设里，比如用pygame.time.get_ticks()的毫秒差直接除以 1000 当秒数，然后又乘了个与帧率相关的系数；或者把frame_clock.tick(60)的返回值当成游戏秒数加进去，帧率越高加得越多。

解决：时间推进必须只依赖真实dt，而dt来自frame_clock.tick(FPS) / 1000.0，且累积器逻辑要用while。同时在主循环里临时打印dt和total_tick，观察三秒，dt应该在 0.016 上下浮动，total_tick每两秒加一。数字对不上就是这里的问题。

5.2 存档读回来，长得正好的作物全变回种子

现象：存档时屏幕上是成熟的小麦，读档后全变成刚种下的小苗，但地块位置和浇水状态都对。

原因：只存了crop_id，没存growth和stage。读档时Crop(crop_id=...)用默认值构造，growth=0、stage=0，于是全部回到种子状态。

解决：确认存档里的 crop 节点包含全部字段。用asdict就不会漏，手写字典最容易漏。排查方法是在dump前打印一次state["tiles"][0]["crop"]，看字段齐不齐。

5.3 浇了水，第二天作物反而不长

现象：第一天浇水正常生长，第二天再浇一次，第三天发现growth没变。

原因：日结函数里先读了tile.watered，判定完之后没有重置，或者重置写在了continue之后的分支里。结果第二天开始watered永远是True，看着像浇了水，实际走的是“已浇水但被跳过”的分支。

解决：日结末尾统一重置，不要在中间分支里重置。写法是遍历完所有地块后单独一个循环把tile.watered = False，或者像 4.1 节那样在每个分支的出口重置。判断顺序固定为“读 → 处理 → 清”，不要交叉。

5.4 鼠标点击整体偏半格，越往右下偏得越多

现象：点第一块地浇的是旁边那块，点到右下角偏移了快一格。

原因：窗口做了缩放，或者TILE_W、TILE_H在渲染和点击两处用了不同的值。也有可能是绘制时加了border_radius导致视觉边界和逻辑边界有差异，让人误以为偏移。

解决：把TILE_W、TILE_H、COLS、ROWS全部收进grid.py，其他地方一律 import，禁止手写字面量。如果做了缩放，点击坐标要按逻辑坐标 = 屏幕坐标 * (逻辑宽 / 实际宽)反算。排查时画一次网格线（pygame.draw.line遍历所有行列），线对上了就说明逻辑没问题，是视觉错觉。

5.5 收获可复收作物时程序直接崩

现象：收草莓的瞬间抛异常，或者收了之后一秒一熟，余额疯涨。

原因：regrow的回退逻辑里stage算成了负数（阶段数少于 2 时len - 2为负），或者只改了stage没改growth，导致下一次日结立刻推回成熟。

解决：回退前先判len(thresholds) >= 2，不满足就按一次性作物处理；回退时同步设置growth = thresholds[stage]。验证方法是连收三次，看growth是否每次都能稳定回退到同一个值，三次之后数值应当完全一致。

6. 从能跑到能讲：砍掉什么、留什么、演示时先点哪里

课程设计的评分点和产品不一样，它奖励“讲清楚”，不奖励“做得多”。同一批项目里，功能堆到二十个但每个都半成品的，往往不如功能只有六个但每条链路都闭合的。我后来带别人的项目时，第一件事就是让他们列一张取舍表。

砍掉这些之后代码量大概在六七百行，正好是一个人一到两周能吃透的规模。

演示时的顺序也有讲究，别一上来就展示画面。先开口讲数据：打开data/crops.json，现场把小麦的stage_days从[1, 2, 3]改成[1, 1, 1]，重跑，作物肉眼可见地加速成熟。这个动作十秒钟，但它证明了三件事——参数是外部化的、逻辑是数据驱动的、你随时能改。很多项目在这一步就已经分出高下了。

第二个动作是存档验证。收获两茬、浇水若干次，存档，关掉进程，重新启动，读档，对着屏幕逐项核对天数、余额、地块状态。这一步要慢，慢到老师能看清每个数字都对得上。我见过太多项目在这里翻车：读档后作物位置对但阶段错，或者余额对但背包少一格。慢一点展示，比快速闪过然后被追问强。

第三个动作是制造一次“干旱枯萎”。故意连续三天不浇水，让一株作物枯死，然后解释DRY_LIMIT这个常量在哪儿、改成 5 会怎样。这是主动暴露一个设计决策，比被动等老师问“你这个作物会不会死”要好得多。

有个习惯我从第一次做这类项目保留到现在：所有可调参数集中在两三个文件里，且每个常量旁边写一行注释说明“改大了会怎样、改小了会怎样”。答辩时被问到任何一个数值，都能立刻说清楚它的影响面。这个习惯花不了半小时，但它是“我做的”和“我抄的”之间最直接的分界线。

还有一点，别在演示前夜改架构。改参数、加一个作物、调一调颜色都可以，动状态机或者存档格式就算了。时间不够的时候，能稳定跑起来的旧版本永远比跑不起来的新版本值钱。这个教训我是付出过代价才记住的，希望帮到你。

本文还有配套的精品资源，点击获取