企业官网建设流程全解析

简介：使用 Python 与 Pygame 实现的《星露谷物语》风格游戏完整源码，面向毕业设计、课程设计及项目开发场景，适合有一定 Python 基础、希望深入游戏开发的学习者参考。项目实现了耕作与觅食、昼夜循环、天气系统、商人交易等核心玩法，并采用 Tiled 地图编辑器制作地图，便于扩展自定义关卡。压缩包共 188 个文件，约 1.33MB，主要包含 12 个 Python 源文件、121 张 PNG 图像素材、Pygame 编译生成的 pyc 文件，以及 tsx/tmx 地图配置、wav/mp3 音效音乐等，目录结构清晰，可对照源码与素材理解游戏模块设计。目前已有 3467 人浏览学习。通过该源码，读者可完整了解 Pygame 游戏循环、碰撞检测、状态机切换、资源加载与地图渲染等关键实现，并可直接在源码基础上修改参数、替换素材或新增功能，作为课程设计或毕业设计的起点，省去从零搭建框架的时间。

1. 为什么用 Python 和 Pygame 做星露谷物语风格的毕业设计

复刻《星露谷物语》听起来是野心很大的选题，但拆到技术层，它恰恰是课程设计和毕业设计里性价比极高的类型。Pygame 把精灵绘制、键盘事件、音效播放封装成非常薄的 API，剩下的大部分工作都落在游戏逻辑上：状态机、碰撞、时间推进、数据序列化。这些恰恰是答辩时最容易被追问、也最能体现工程能力的地方。

我一般会把这类项目定位成“规则完整但规模受控”的可玩 demo：地图不一定要大，但要能纵向做深——播种、生长、收获的完整状态流转必须真实存在；存档不一定要复杂，但要能关掉程序再打开，角色还站在原来的位置上。这样既能绕开美术和音效的高投入，又能把软件工程的模块划分和文档补全。

接下来按从业者做小型游戏的标准顺序走：先把 Pygame 环境装干净，再搭主循环、写地图渲染和角色控制，然后把农业、时间和背包三个支柱接上，最后聊存档、打包和答辩演示。

2. Pygame 搭建最小可玩框架：安装、项目结构与游戏循环

2.1 安装 Pygame 的推荐路径与 wheel 构建失败处理

先把环境问题解决掉，否则后面代码写得再多也跑不起来。最省事的安装方式是直接执行pip install pygame，但很多机器上第一次都会碰见一个很误导人的错误：

error: failed to build 'pygame' when getting requirements to build wheel

这个报错的字面意思是“构建 wheel 失败”，但根因绝大多数不在 pygame 本身。它只代表 pip 在当前 Python 版本和平台组合下找不到预编译好的二进制包，决定退回源码编译，而源码编译需要 SDL2 开发库。Windows 上更常见的触发原因是 pip 太旧或 Python 位数不对，Linux 和 macOS 则基本都属于系统缺失 SDL 头文件。按平台对照处理：

换到 Python 3.12 以上的环境时，更应该先建独立虚拟环境再安装，避免污染系统 Python。跑下面的命令把环境和包一次准备好：

python -m venv .venv source .venv/bin/activate python -m pip install --upgrade pip pip install pygame python -c "import pygame; print(pygame.version.ver)"

最后一条能打印出版本号，就说明 pygame 和 SDL 底层链接全部正常，可以开工了。安装阶段常见的另一个坑是同时装了 Python 的 32 位和 64 位版本，终端里python --version和 IDE 解释器对不上，装完却在 IDE 里import pygame报错。遇到这种情况，统一路径后重开终端，别在同一个会话里反复折腾。

2.2 目录结构：从第一天就把代码和数据分开

小游戏项目的通病是前期图快，把所有类和函数塞进一个main.py，等做到农作系统时文件已经上千行，改哪里都怕崩。我一般会在一开始就采用下面的分层结构：

stardew_clone/ ├── main.py # 入口，负责初始化并启动主循环 ├── settings.py # 窗口尺寸、帧率、瓦片大小等全局常量 ├── core/ │ ├── __init__.py │ ├── game.py # Game 类，跑主循环 │ └── camera.py # 相机跟随与边界限制 ├── systems/ │ ├── player.py # 角色移动与碰撞 │ ├── inventory.py # 背包数据结构 │ ├── farming.py # 作物的生长与收获逻辑 │ ├── save.py # 存档与读档 │ └── time_system.py # 游戏内时间推进 ├── data/ │ ├── maps/ # 地图二维数组，独立成 py 或 json 文件 │ ├── images/ # 瓦片图、角色精灵、作物贴图 │ └── saves/ # 运行期生成的存档文件

模块划分的原则是渲染调度归core，业务逻辑归systems，地图和图片归data，且任何业务模块不直接 import 对方。玩家模块不关心作物长到第几阶段，农作模块也只需要站在自己的数据结构上工作。这个划分对答辩很有帮助，老师问“这个类干什么的”，你直接指向文件说明职责，再加一段类图就讲完架构了。

2.3 固定时间步长的主循环与帧率控制

Pygame 的主循环是整棵树的根，所有事件、更新、绘制都从它分发出去。最精简的框架只需要三个方法：处理事件、更新状态、绘制画面。

# main.py import pygame from settings import SCREEN_SIZE, FPS from systems.player import Player from systems.inventory import Inventory class Game: def __init__(self): pygame.init() self.screen = pygame.display.set_mode(SCREEN_SIZE) pygame.display.set_caption("Stardew Clone") self.clock = pygame.time.Clock() self.running = True self.player = Player(96, 96) self.inventory = Inventory() def run(self): while self.running: dt = self.clock.tick(FPS) # 限制帧率，返回毫秒 for event in pygame.event.get(): if event.type == pygame.QUIT: self.running = False self.update(dt) self.draw() pygame.quit() def update(self, dt): self.player.update(dt) def draw(self): self.screen.fill((92, 148, 92)) self.player.draw(self.screen) pygame.display.flip() if __name__ == "__main__": Game().run()

tick(FPS)返回上一帧耗时，单位是毫秒，后面所有移动、计时都拿它当时间基准。这里有个容易被忽略的参数选择：FPS 要按玩法层来定。地图滚动和角色动画用 60 没问题，但如果你在答辩机器上跑，集显加高分辨率屏可能会掉到 40 以下，体验就很差。我一般把 FPS 定成 60，同时把游戏逻辑写成与帧率无关——移动距离用speed * dt / 1000计算，而不是每帧固定走几个像素。

3. 地图渲染与相机移动：让游戏世界先跑起来

3.1 用二维数组定义地图和碰撞层

星露谷的地图本质是网格系统，每个格子有地形 id，另有独立一张表标记“能不能走”。用二维数组定义数据是最直观、也最容易写进文档的表达方式。我这里的地图规模只有 8×6，对应一张很小的手工地图：

# data/maps/grassland.py # 地形编号：0=草地，1=耕地，2=水，3=石头 MAP_TILES = [ [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 2, 0, 0, 0, 0, 0], [0, 1, 1, 1, 1, 0, 0, 0], [0, 0, 2, 0, 0, 0, 3, 0], [0, 0, 0, 0, 0, 0, 3, 0], [0, 0, 0, 0, 0, 0, 0, 0], ] # 碰撞层：1 表示不可通行，行列数与 MAP_TILES 对齐 MAP_COLLISION = [ [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 1, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 1, 0, 0, 0, 1, 0], [0, 0, 0, 0, 0, 0, 1, 0], [0, 0, 0, 0, 0, 0, 0, 0], ]

水在视觉上能看到，但角色不能走，石头同理。两套数组的行列必须严格对齐，这是最容易出 bug 的地方——改地图某一行时漏改碰撞层，主角就会穿模。建议在加载地图后加一段断言，检查两个二维数组的 shape 是否一致，跑起来就能立刻发现。

在这种网格地图上，把像素坐标换算成格子坐标只需要一次整除：tile_x = px // TILE_SIZE, tile_y = py // TILE_SIZE。角色、落点、交互检测都以这个换算为基础，所以 TILE_SIZE 建议全局统一为 32 或 48，不要中途改。

3.2 瓦片裁剪：只绘制相机能看见的格子

地图只有 8×6 时看不出性能问题，一旦扩大到 50×50 甚至 100×100，每帧把整张地图blit一遍就会明显卡顿。做这类 2D 游戏的标准做法是可视区域裁剪：根据相机坐标算出一屏内能看到哪些格子，只画这些瓦片。

# core/camera.py import pygame from settings import TILE_SIZE def draw_map(screen, tiles, images, camera_x, camera_y, map_w, map_h): # 计算屏幕可见范围的起点和终点格子索引 start_x = max(0, camera_x // TILE_SIZE) start_y = max(0, camera_y // TILE_SIZE) end_x = min(map_w, (camera_x + screen.get_width()) // TILE_SIZE + 1) end_y = min(map_h, (camera_y + screen.get_height()) // TILE_SIZE + 1) for y in range(start_y, end_y): for x in range(start_x, end_x): tile_id = tiles[y][x] img = images[tile_id] # 减去相机偏移，实现镜头效果 screen.blit(img, (x * TILE_SIZE - camera_x, y * TILE_SIZE - camera_y))

这里的关键点是end_x和end_y的边界补 1。屏幕宽不一定是瓦片大小的整数倍，最后一行或一列刚好超出屏幕边缘时，如果不补+1就会出现边缘黑缝。另一个值得注意的参数是camera_x // TILE_SIZE的向下取整行为：当角色移动未满一个瓦片时，start_x不变，避免每帧因为浮点抖动而多画一列。

地图尺寸超过 200×200 时，这个循环也会开始吃力，届时要换成先做一层“图层合并”：把静态草地、水、石头预先烘焙到一张大地图 Surface 上，每帧只需一次blit整张截图，再叠加动态物体。对毕设规模来说，裁剪方案已经足够，烘焙方案可以作为论文里的优化章节来写。

3.3 相机跟随与边界限制

古人视角的相机逻辑很简单：把视口中心对准角色，同时把相机坐标 clamp 到地图范围内，否则贴图边缘会露出窗口背景色。下面这个 Camera 类可以直接覆盖上面 draw_map 的参数：

# core/camera.py（追加） class Camera: def __init__(self, width, height, map_w, map_h): self.rect = pygame.Rect(0, 0, width, height) # 相机最多能移动到的坐标 = 地图总像素 - 窗口尺寸 self.max_x = map_w * TILE_SIZE - width self.max_y = map_h * TILE_SIZE - height def follow(self, target_rect): # 窗口中心对准目标中心 self.rect.centerx = target_rect.centerx self.rect.centery = target_rect.centery # 防止相机越界 self.rect.x = max(0, min(self.rect.x, self.max_x)) self.rect.y = max(0, min(self.rect.y, self.max_y)) def get_offset(self): return self.rect.x, self.rect.y

max(0, min(...))这行把相机坐标强行压进[0, max_x]区间。地图小于窗口时max_x会变成负数，这时 clamp 会把相机固定在 0，画面从窗口左上角开始绘制，不会有异常。相机类独立出来后，后续做镜头平滑过渡（lerp）和抖动效果都直接在follow里改，不影响地图绘制函数。注意 camera 的 rect 中心点设置顺序：必须先设 centerx 再 clamp x，反过来会因为 rect.x 被 clamp 后 centerx 再次改变，导致角色始终不在画面正中。

4. 角色控制与碰撞检测：核心操作手感从哪来

4.1 事件驱动和持续按键的取舍

Pygame 里读取键盘输入有两条路线：监听pygame.KEYDOWN事件做单次触发，或调用pygame.key.get_pressed()做持续状态查询。星露谷这种耕田游戏，移动必须用持续查询，因为玩家大部分时间按着方向键跑图；而快捷键动作（按 E 打开背包、按 F 收起工具）适合用 KEYDOWN 做边缘触发，避免按住时反复弹开背包。

# systems/player.py import pygame from settings import TILE_SIZE SPEED = 120 # 像素/秒 class Player: def __init__(self, x, y): self.rect = pygame.Rect(x, y, TILE_SIZE - 4, TILE_SIZE - 8) self.vx = 0 self.vy = 0 def update(self, dt): keys = pygame.key.get_pressed() self.vx = 0 self.vy = 0 if keys[pygame.K_LEFT]: self.vx = -SPEED if keys[pygame.K_RIGHT]: self.vx = SPEED if keys[pygame.K_UP]: self.vy = -SPEED if keys[pygame.K_DOWN]: self.vy = SPEED self.move(dt) def move(self, dt): dx = int(self.vx * dt / 1000) dy = int(self.vy * dt / 1000) self.rect.x += dx if self.collides(): self.rect.x -= dx self.rect.y += dy if self.collides(): self.rect.y -= dy def collides(self): # 由关卡提供 collision map，这里简化成读全局 from data.maps.grassland import MAP_COLLISION left = self.rect.left // TILE_SIZE right = (self.rect.right - 1) // TILE_SIZE top = self.rect.top // TILE_SIZE bottom = (self.rect.bottom - 1) // TILE_SIZE for ty in range(top, bottom + 1): for tx in range(left, right + 1): if MAP_COLLISION[ty][tx] == 1: return True return False

rect 尺寸用TILE_SIZE - 4和TILE_SIZE - 8，让角色比瓦片略小一圈，视觉中心不变但碰墙时不会贴得过死。这是模拟“角色占格，但实际身体小于格子”的做法，为后面跟 NPC 交互留出余量。right - 1和bottom - 1是为了防止角色右边缘正好压在格子边界时误判到下一格。

4.2 拆轴碰撞：为什么分两步移动而不是一次移动

看完上面代码你可能发现，水平移动和垂直移动是分开做的，每步都重新检测一次碰撞。这是 2D 游戏最经典的处理方式——“拆轴碰撞”。如果同时把 dx 和 dy 加到坐标上再检测，斜向撞墙时算不清楚到底哪个方向被挡住了，回退时会丢失有效轴向的移动量。

分轴检测时如果撞了墙，不能简单把坐标清零，而要把这半轴的位移原样减回去。上面的self.rect.x -= dx就是回退当前帧的水平位移，下一帧继续照常走垂直方向，这样角色贴着墙跑时始终能保持一条直线前进。碰撞检测里循环遍历角色覆盖的所有格子，是为了避免物体横跨多个格子时只查到一个碰撞点的情况。

与栅格对齐的另一种做法是把角色强制吸附到格子边界，视觉上很整齐但移动手感僵硬，而且在半格宽度的通道里会卡死。我的建议是毕设阶段用分轴回退，代码量小、行为稳定，答辩演示也够用。

4.3 交互判定：用角色前方的探测格

种植、浇水、砍树这类交互动作，关键在“判定范围”。玩家按空格键时，得知道玩家面朝哪个方向、面前哪一格可以交互。这里不依赖碰撞 map，而是在角色前方追加一个探测矩形：

def get_interact_rect(self, direction): # direction: (0,-1) 上, (0,1) 下, (-1,0) 左, (1,0) 右 x = self.rect.centerx // TILE_SIZE * TILE_SIZE + direction[0] * TILE_SIZE y = self.rect.centery // TILE_SIZE * TILE_SIZE + direction[1] * TILE_SIZE return pygame.Rect(x, y, TILE_SIZE, TILE_SIZE)

探测格的计算基准是角色的中心点映射到所在格子，再偏移一个瓦片距离，这样探测窗口永远与地图网格对齐。把返回的 rect 与作物、宝箱、NPC 的 rect 做colliderect判断，即可精确命中目标，不需要单独维护一张交互标记表。关键参数 direction 必须与角色朝向状态联动，否则玩家面朝左时却检测右边格子，操作会非常别扭。把朝向存成元组(dx, dy)，在 update 里按键时同步更新，后续画朝向帧动画也直接读这个元组。

5. 农业、时间与背包：星露谷玩法系统的三个支柱

5.1 时间系统：用累计帧数换算游戏内时间

星露谷的昼夜循环本质是一个“数值节拍器”：每秒对应游戏内 10 分钟，每 10 秒推进 1 小时，早上 6 点开始，凌晨 2 点强制睡觉。实现时不需要单独开线程，主循环里累积 dt 就能保证时间的推进与游戏逻辑完全同步。

# systems/time_system.py MINUTE_LENGTH = 1000 # 每 1000 毫秒 = 游戏内 10 分钟 HOURS_PER_DAY = 24 class TimeSystem: def __init__(self, start_hour=6): self.minutes = start_hour * 60 self.day = 1 def update(self, dt): # dt 单位毫秒，累计满一个周期就推进 10 分钟 self.minutes += dt / MINUTE_LENGTH * 10 def get_time_str(self): hour = int(self.minutes // 60) % HOURS_PER_DAY minute = int(self.minutes % 60) return f"{hour:02d}:{minute:02d}" def advance_day(self): self.day += 1 self.minutes = 6 * 60 # 睡醒从早上 6 点开始

使用 dt 换算而不是每帧固定加数值，保证 60Hz 和 30Hz 机器上时间流速一致。作物成熟、NPC 移动、商店开门都直接读get_time_str()做区间判断，例如商店营业条件写成"08:00" <= now <= "20:00"。答辩时很加分的做法是把MINUTE_LENGTH改成配置项，现场演示时调成 100 毫秒，观众能直接看到作物在几十秒内走完全部生长周期，比空口讲状态机直观得多。

5.2 农作物状态机：播种、生长、收获

作物是典型的状态机：种子 → 阶段1 → 阶段2 → …… → 成熟可收获。设计上用配置字典描述作物属性，用实例对象记录每株作物的状态，两者分离，新增作物只改配置不动逻辑。

# data/crops.py CROPS = { "parsnip": { "stages": 4, # 含成熟期共 4 阶段 "days_per_stage": 1, # 每阶段需要 1 天 "seed": "parsnip_seed", "sell_price": 35, }, "cauliflower": { "stages": 5, "days_per_stage": 2, "seed": "cauliflower_seed", "sell_price": 175, }, }

# systems/farming.py class CropInstance: def __init__(self, crop_id, planted_day): self.crop_id = crop_id self.planted_day = planted_day self.current_stage = 0 def update(self, today, config): grown_days = today - self.planted_day total_stages = config["stages"] # 每过 days_per_stage 天推进一个阶段，封顶为成熟阶段 self.current_stage = min( total_stages - 1, grown_days // config["days_per_stage"] ) @property def is_harvestable(self): return self.current_stage >= CROPS[self.crop_id]["stages"] - 1

update里用整除计算阶段是本实现的核心推理。法是从种下的天数出发做区间映射，而不是记住“明天该长到哪了”，这样即使玩家几天不上线，回到游戏也能用today - planted_day直接算出正确的生长状态，天然支持跨天加载。阶段索引对应贴图编号，画作物时按current_stage找图即可。浇水加速、季节枯萎这类进阶规则，可以后期在CropInstance.update里追加成长倍率，不影响已存盘的作物字段。

5.3 背包数据结构：用 Python 列表搭的轻量实现

背包在课程设计阶段不需要做复杂网格，一个可堆叠物品的列表就能撑起完整玩法。每个槽位保存(item_id, count)，物品数量叠加时只改 count，UI 层按槽位渲染图标和数量。

# systems/inventory.py class Inventory: def __init__(self, size=12): self.slots = [None] * size def add(self, item_id, count=1): for i, slot in enumerate(self.slots): # 同种物品堆叠 if slot and slot[0] == item_id: self.slots[i] = (item_id, slot[1] + count) return True for i, slot in enumerate(self.slots): if slot is None: self.slots[i] = (item_id, count) return True return False # 背包满了 def remove(self, index, count=1): slot = self.slots[index] if slot is None: return False if slot[1] <= count: self.slots[index] = None else: self.slots[index] = (slot[0], slot[1] - count) return True def get_total(self, item_id): return sum(s[1] for s in self.slots if s and s[0] == item_id)

先把同种物品的堆叠逻辑放在 add 的第一步，避免出现同种物品拆在两个槽位里，这是新手最容易忽略的细节。两遍遍历的代价可以接受，毕设阶段背包槽数量很小，不需要引入哈希索引，直接线性扫描。删除物品时count大于等于存量则清空槽位，并返回是否成功；删除不存在的物品时返回 False，外部逻辑可以借此给出“背包没有该物品”的提示。钥匙、工具这类不可堆叠的物品，把 count 固定为 1 并禁止同 id 堆叠即可，不需要重新设计数据结构。

6. 存档、打包与答辩演示：三个必须提前做的事

6.1 存档的最小实现：JSON 结构与读取容错

存档用 JSON 而不是 pickle，原因是可读性和跨版本兼容性更好。答辩时可以直接用编辑器打开存档文件，逐字段解释数据结构；pickle 则是一堆二进制乱码，讲不清楚还容易因为 Python 版本不同导致反序列化失败。存档结构需要包含玩家坐标、当前天数、背包列表和作物实例数组。

# systems/save.py import json, os SAVE_PATH = "data/saves/slot1.json" def save_game(player, inventory, time_system, crops): data = { "player": {"x": player.rect.x, "y": player.rect.y}, "day": time_system.day, "inventory": [ {"item": item_id, "count": count} for item_id, count in inventory.slots if item_id ], "crops": [ {"x": c.rect.x, "y": c.rect.y, "crop_id": c.crop_id, "planted_day": c.planted_day} for c in crops ], } os.makedirs(os.path.dirname(SAVE_PATH), exist_ok=True) with open(SAVE_PATH, "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2)

存盘的重点不是写文件，而是定义“哪些字段足以恢复现场”。作物存 x/y 坐标而不是数组下标，是为了防止地图调整后坐标错位；planted_day 存原始天数，加载后调用CropInstance.update(today, config)就能恢复当前阶段，这个设计在 5.2 的公式基础上自然成立。

6.2 用 PyInstaller 打包并处理资源路径

毕设提交时通常要交一个能直接运行的 exe，PyInstaller 是当前最稳妥的方案。打包命令里必须把 data 目录一起带进去，否则运行时会因为找不到图片素材直接崩溃：

pip install pyinstaller pyinstaller --noconsole --onefile --name stardew_clone \ --add-data "data:data" main.py

打包后运行dist/stardew_clone.exe，如果报找不到文件错误，原因是 PyInstaller 解包后的临时目录路径和源码里的相对路径不同。解决方式是在存档和素材加载前统一加一层路径解析：

import sys def resource_path(relative): # PyInstaller 解包时会把资源放到 _MEIPASS 临时目录 base = getattr(sys, "_MEIPASS", os.path.abspath(".")) return os.path.join(base, relative)

所有读取图片、地图、存档的路径统一走resource_path，开发时返回项目目录，打包后自动指向临时解包目录。这个函数是打包环节最值得调试的部分，建议在打包前先写一条路径打印语句，确认资源确实被带到包里。

6.3 答辩演示的调试快捷键

最后给一个实战技巧：在游戏里预留一组调试快捷键，F5强制跳过一天，F6添加 1 个当前选中种子，F7打印存档内容。答辩现场演示农作系统时，不需要真的等作物在屏幕上长几分钟，按F5就能推动时间，配合get_time_str()的 HUD 显示，观众能直观看到日期跳动、作物阶段变化、可收获标记出现的完整因果链。

# 在 Game.update 里追加 keys = pygame.key.get_pressed() if keys[pygame.K_F5]: time_system.advance_day() for crop in crops: crop.update(time_system.day, CROPS[crop.crop_id])

调试快捷键的直接收益是演示节奏可控。答辩现场紧张状态下，常态操作容易卡顿或忘记流程，快捷键把演示变成了“按下 F5、看到变化、解释代码”的稳定三步。验收时这段代码也不会扣分，反而能体现你考虑了开发效率。演示流程我建议固定成：先走两步说明移动和碰撞，再播种、F5 两天、收获卖钱，最后存档退出重进显示角色站在原地，三条主线全部走完正好两分钟。

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