1. 选型复盘：为什么这个项目没选引擎，而是落在 Python + Pygame
我决定用 Python 和 Pygame 做一款 2D 肉鸽幸存者游戏的时候，身边不少人的第一反应是：为什么不用 Unity / Godot？甚至连用 JavaScript 写个网页版都显得更“现代”。但我把需求拆开之后发现，这个项目选 Pygame 其实是一个非常理性的判断，而不是什么情怀。
肉鸽幸存者类游戏的核心玩法，说白了就几件事：玩家在一个 2D 场景里移动、武器自动索敌开火、敌人从四面八方刷出来、角色升级后从几个随机强化里三选一。这个玩法对引擎能力的要求并不高，不需要物理引擎、不需要 3D 渲染管线、不需要复杂粒子系统。真正吃功夫的是三块：游戏循环的稳定性、大量实体同屏时的性能、以及数值和随机系统的设计。前两件事 Pygame 完全能做，第三件事恰好是 Python 的舒适区。
对比一下其他方案：
- Unity / Godot：功能全面，但项目结构重、资源管线繁琐、打包体积大。做这种小体量 2D 游戏属于高射炮打蚊子。如果你只是想在周末写个游戏玩，启动一个编辑器工程的时间都够我写好两个系统了。
- 网页版（Canvas / Phaser）：适合传播，但纯前端做肉鸽游戏的存档管理、本地运行体验反而要绕弯子。
- Pygame 生态更贴近“代码直写游戏”的思路，所有东西都是类、循环、事件、Surface。你会摸到游戏开发真正的底层数据结构，而不是被引擎帮你隐藏掉。对一个想在实战里学 Python 的人来说，这个“不隐藏”反而是最大的价值。
当然，选型要有清醒的边界认知。Pygame 没有现成的 UI 系统、没有动画状态机、没有资源热更工具，这些都得自己搭。我的态度是：就是这个项目规模而言，自己搭的成本是完全可以接受的。
2. 从“装不上”到“能跑”：Python 环境与 Pygame 安装的实战排坑
这个项目还没写第一行游戏代码，就差点被环境问题劝退。搜 Pygame 相关资料时，高频出现的关键词基本都是安装相关：python 安装教程、pygame 安装、还有一条特别刺眼的error: failed to build 'pygame' when getting requirements to build wheel。如果你也卡在这，我告诉你这不是你一个人遇到，而是 Pygame 官方 wheel 分发机制和本机环境不匹配导致的经典问题。
2.1 先选对 Python 版本，能省掉八成问题
Pygame 提供了预编译的 wheel 包，正常安装应该是直接下载二进制然后解压，这个过程不需要本机有编译器。问题在于：wheel 包是按 Python 版本区分构建的，如果你的 Python 版本太新，官方还没来得构建对应版本，pip 就会退化到“从源码编译”这条路。
所以我给这个项目定的第一道规矩就是：别追求最新版 Python，用稳定且 Pygame 官方明确支持的版本。目前来说，Python 3.9 到 3.11 都是非常稳的区间，3.12 的 wheel 覆盖也已经逐渐补齐，最新版本则可能需要碰运气。反正肉鸽游戏的语法用不到什么只有新版才有的特性，没必要跟版本较劲。
设置虚拟环境是必须的步骤，不是可选项。我见过太多人直接把包往全局环境里塞，过几个月发现依赖打架、排查到崩溃。这里给出我每次开新项目的固定流程：
py -m venv survivor_env # Windows: survivor_env\Scripts\activate # macOS / Linux: source survivor_env/bin/activate pip install --upgrade pip setuptools wheel pip install pygame装完用 Python 交互模式验证一下版本：
import pygame print(pygame.version.ver)能正常输出版本号，说明环境已经通了。
2.2 “failed to build 'pygame' when getting requirements to build wheel”到底在说什么
这行报错删掉前面的壳子，核心意思是：pip 发现找不到兼容的 wheel，于是决定拉源码回来自己编译，然后编译过程挂在“获取编译依赖”这一步。绝大多数情况下，你的开发环境根本没有 C 编译器，也没有 SDL 相关的底层库，所以必然报错。
解决思路有两个方向。一个是“让 pip 找到 wheel”，另一个是“让源码编译跑通”。前者永远更省力。
排查顺序建议这样走：
- 确认 Python 架构是否 64 位。Win 下可以用
py -c "import platform; print(platform.architecture())"。如果是 32 位 Python，部分 Pygame wheel 直接不提供匹配版本，立刻换 64 位。 - 升级 pip。旧版 pip 在 wheel 解析上确实存在兼容问题，这步成本最低。
- 尝试强制只装二进制包：
pip install pygame --only-binary :all:。如果命令能成功，说明问题就出在 pip 误判了源码包；如果它直接提示找不到匹配分发，那就是 Python 版本和 Pygame 版本不兼容，考虑降级 Python。 - 如果实在只能源码编译，Windows 上需要安装 Visual Studio Build Tools（勾选 C++ 桌面开发组件），Linux 上需要
libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev，macOS 上需要 Xcode Command Line Tools。这三个平台的依赖我全部踩过一遍，哪怕只差一个libsdl2-mixer-dev，编译照样挂。
2.3 这条报错背后还藏着几个相关坑
连带出现的高频搜索词有“pygame gui”“pygame 手机版(免费)”“vscode python 环境配置”。关于 GUI 我放到后面升级界面时细说，这里先解决另外两个。
手机端跑 Pygame 不是说完全不行，Android 上有 Pydroid 3 可以直接执行 Pygame 代码。但你要有心理准备：触屏输入需要自己重写控制逻辑，虚拟摇杆的响应精度和键盘没法比；小内存设备加载稍大的图片素材会直接卡死。我的建议是把它当作验证代码的应急环境，别作为主力开发环境。
VSCode 配置 Python 环境最容易翻车的地方是解释器选错。明明在终端激活了虚拟环境，VSCode 右下角还指着全局 Python，结果点击运行后 import pygame 直接 ModuleNotFoundError。解决方法是按Ctrl+Shift+P输入 “Python: Select Interpreter”，手动选到虚拟环境路径下的python.exe。
2.4 装完跑一个冒烟测试再动手写游戏
环境装好以后，我强烈建议先跑一个最朴素的有窗程序，而不是直接往项目里怼代码：
import pygame pygame.init() screen = pygame.display.set_mode((800, 600)) pygame.display.set_caption("Survivor Test") clock = pygame.time.Clock() running = True while running: for event in pygame.event.get(): if event.type == pygame.QUIT: running = False screen.fill((20, 20, 30)) pygame.display.flip() clock.tick(60) pygame.quit()这个 15 行程序能同时验证三件事：初始化是否成功、窗口是否能创建、事件循环是否正常。一步到位能过滤掉后面 90% 的“我这代码没问题啊”阶段问题。我甚至见过有人因为电脑开了护眼模式导致窗口颜色看起来奇怪，然后怀疑 Pygame 渲染有 bug 的，这种低级焦虑最好在最开始就扫清。
3. 开局一个循环：游戏主框架与实体管理设计
环境通了之后，接下来的问题是：肉鸽幸存者游戏代码从哪下手？我的经验是，不要先从“画面好看”出发，先想清楚《游戏主循环》和《实体对象模型》。这两件事决定你后续添加玩法时会不会每加一个功能就重构一次全项目。
3.1 游戏主循环是最朴素也是最重要的“骨架”
所有 Pygame 游戏本质上都是同一个循环：处理输入、更新逻辑、绘制画面、控制帧率。肉鸽幸存者游戏因为同屏实体数量大，主循环的“更新”阶段尤其要设计得有层次，不然帧率说崩就崩。
我个人建议把主循环拆成三个阶段：handle_events()只处理玩家输入，update(dt)按逻辑顺序更新玩家、子弹、敌人、掉落物、生成器、UI，draw(surface)最后统一渲染。注意update里加了dt（delta time），这是为了把移动速度、冷却时间等所有数值跟帧率解耦。否则，帧率一旦波动，游戏速度会一起变，肉鸽这种对节奏敏感的类型会显得很“飘”。
def run(self): while self.running: dt = self.clock.tick(60) / 1000.0 self.handle_events() self.update(dt) self.draw()其实就这简简单单几行。但很多新手会把业务逻辑全部塞进事件处理里，结果按一个方向键都要卡一下。记住：事件循环里只做“记录按键状态”这件事，具体移动逻辑放到 update 中统一处理，就能避免大部分输入延迟问题。
3.2 实体类设计：玩家、敌人、子弹、掉落物
幸存者游戏的世界观里，实体分四类就够了：玩家、敌人、子弹、掉落物。不需要盲目引入复杂继承体系，但一个基础实体类很值得写。
class Entity: def __init__(self, pos, speed, radius, hp): self.pos = pos self.speed = speed self.radius = radius self.hp = hp self.alive = True def update(self, dt): raise NotImplementedError def draw(self, surface): pygame.draw.circle(surface, self.color, self.pos, self.radius) def distance_sq(self, other): dx = self.pos[0] - other.pos[0] dy = self.pos[1] - other.pos[1] return dx * dx + dy * dy这里我用圆和distance_sq作为基础的碰撞模型。肉鸽游戏里大多数敌人形状可以用圆近似，圆碰撞的判定成本低，而且没有旋转问题。如果美术素材不是规则的圆，也可以在内部维护一个圆形碰撞体，视觉归视觉，碰撞归碰撞。
玩家类继承 Entity 后，额外关心输入方向以及武器冷却。子弹类继承后只需要关心飞行方向和伤害。掉落物则更简单，通常只存一个类型 ID，代表经验、回血或磁铁效果。
3.3 管理器与状态机：游戏不是在“跑”就是在“停”
肉鸽游戏天然有状态切换：主菜单 → 游戏中 → 升级三选一 → 游戏结束。这四种状态之间频繁切换，如果全部塞进主循环的 if 里，代码会变成一团乱麻。
我用一个非常轻量的GameState枚举加字典派发来做：
class GameState(Enum): MENU = 0 PLAYING = 1 LEVEL_UP = 2 GAME_OVER = 3 class Game: def switch_state(self, new_state): self.state = new_state if new_state == GameState.LEVEL_UP: self.build_upgrade_options()在 update 里只要：
if self.state == GameState.PLAYING: self.update_playing(dt) elif self.state == GameState.LEVEL_UP: self.update_level_up(dt)这样做的最大好处是，游戏结束后的“重建新一局”只需要一个reset()方法把玩家坐标、敌人生成器、经验曲线全部重置，而不用关掉整个窗口。很多肉鸽游戏的操作体验好不好，就看重启一局顺不顺。
4. 幸存者味道的核心：自动索敌、敌人波次与碰撞判定
“幸存者”和“肉鸽”是前缀，核心语法后缀是“爽游”。爽感从哪来？我总结三个字：自动打。玩家只需要操心走位，武器自己找人打，敌人源源不断送脸上。这个玩法听起来简单，落地时全是细节。
4.1 自动索敌：给玩家一个“自己会打”的武器
自动索敌的关键问题：当同屏有几百个敌人时，每一帧都去计算所有敌人到玩家的距离，性能会非常难看。实际做法是牺牲一点点精度换来速度——把判断范围先限制在武器射程内，并且用距离平方比较，避免开根号。
def auto_aim(player, enemies, range_limit): best = None best_dist_sq = range_limit * range_limit for enemy in enemies: d2 = player.distance_sq(enemy) if d2 < best_dist_sq: best_dist_sq = d2 best = enemy return best这个函数返回射程内的最近目标。武器冷却归零时，向这个目标方向生成一颗子弹。注意子弹的方向应该由“目标当前位置——玩家当前位置”决定，但飞行过程中目标可能已经移动了，子弹的轨迹用固定方向就行，不用实时追踪。否则子弹会产生“追尾”效果，玩起来反而觉得武器黏糊。
对于不同武器类型，索敌逻辑可以反过来：霰弹枪可以考虑“扇形”内多个目标；闪电枪可以找范围内血量最高的目标。但第一版建议全部统一最近索敌，等手感调平衡了再区分武器个性。幸存者类游戏的乐趣起点是“自动打”，差异化是后话。
4.2 敌人生成：波次节奏决定游戏心跳
肉鸽幸存者的敌人刷新从来不是静态的“到达一定时间刷一波”。它的节奏更像心率曲线：随着游戏时间推移，单位时间内刷怪数量持续上升，同时每只怪的强度也在缓慢增长。这种设计逼迫玩家必须持续获得升级，才能在动态压力中生存。
我用一个简单的生成器类来管这个事：
class Spawner: def __init__(self, screen_rect): self.screen_rect = screen_rect self.timer = 0.0 self.spawn_interval = 1.2 # 初始每 1.2 秒一波 self.wave_power = 0 def update(self, dt, enemy_group): self.timer += dt self.wave_power += dt * 0.02 # 随时间线性增加难度 if self.timer >= self.spawn_interval: self.timer = 0.0 self.spawn_wave(enemy_group) def spawn_wave(self, enemy_group): base_count = 2 + int(self.wave_power / 5) boss_scale = 1.0 + self.wave_power / 30 # 从屏幕四个边缘外侧随机位置生成 ...刷新的坐标尽量取在屏幕边缘外侧，给玩家一个“看见敌人正在靠近”的反应窗口期。如果敌人直接从屏幕内冒出来，玩家会觉得自己被偷袭了，对肉鸽来说很不公平。肉鸽的公平性秘诀是：伤害可以高得离谱，但信息必须透明。
4.3 碰撞检测：别让 O(n²) 毁掉手感
敌人和子弹的碰撞检测是性能大头。如果所有子弹都和所有敌人做两两判断，复杂度是 O(n*m)，几百个敌人加几百颗子弹，一帧的循环次数就是十万级，Pygame 的 Python 代码跑这种量级会非常吃力。
我在项目里没有上来就搞四叉树，而是用了更朴素但有效的“空间分桶”。以 200 像素为一个格子，把敌人按坐标放进对应的桶里；子弹检测时，只跟“当前子弹所在格 + 相邻格”里的敌人做碰撞检测。平均下来每个子弹只需要跟少数几个敌人判断，性能一下子上去几个量级。
class SpaceBucket: def __init__(self, cell_size=200): self.cell_size = cell_size self.buckets = {} def add(self, entity): key = (entity.pos[0] // self.cell_size, entity.pos[1] // self.cell_size) self.buckets.setdefault(key, []).append(entity) def query_nearby(self, pos): x, y = int(pos[0] // self.cell_size), int(pos[1] // self.cell_size) result = [] for dx in (-1, 0, 1): for dy in (-1, 0, 1): result.extend(self.buckets.get((x + dx, y + dy), [])) return result这个桶每帧重建一次，因为敌人的位置每帧都在变化。代码量小、逻辑清晰，后续就算要换四叉树，调用方接口也能保持不变。
5. 肉鸽的随机性：升级三选一、数值曲线与地图生成
肉鸽游戏的核心是“每一局都不同”。这个“不同”不是完全随机，而是在随机中保持玩家的成长预期。完全失控的随机只会让玩家觉得上一局白打了。这里我拆成三个子系统来讲。
5.1 三选一升级系统：随机但不能失控
升级的触发条件是经验值攒满一条。升级后游戏从“战斗中”切到“待选中”状态，此时屏幕弹出三个随机强化选项。每个选项由“属性 + 数值”组成，比如“伤害 +15%”“最大生命 +20”“移动速度 +8%”。
为了让“三选一”里不会出现三个垃圾选项一起刷出来的情况，我给每个强化都配了一个权重，并且用“先分组、再抽样”的策略：
def roll_upgrade_pool(player): pool = [] pool.extend([{"type": "damage", "value": 0.15, "weight": 10}] if player.level < 8 else []) pool.append({"type": "max_hp", "value": 20, "weight": 8}) pool.append({"type": "move_speed", "value": 0.08, "weight": 5}) pool.append({"type": "fire_rate", "value": 0.12, "weight": 7}) # 已经被玩家点满的上限类型直接从池里踢掉 ... return random.choices(pool, weights=[p["weight"] for p in pool], k=3)这里面有个细节：已经满级的属性不应该再进入随机池，否则三选一里出现“移动速度已达上限”这种选项，玩家的感受等于空手而归。设计原则是：一次选择就算不是最想要的，也必须有一点实际收益。
5.2 数值曲线：伤害、冷却、移速的成长节奏
肉鸽数值最忌讳的是“线性麻木”。如果每升一级固定伤害加 10，玩家很快会算出这个数字带来的边际变化，爽感就没了。我推荐复合曲线：基础属性用加法式成长，关键武器效果用乘法式叠加，全局时间采用指数式压迫。
玩家伤害的计算模型可以是：
final_damage = base_damage * (1 + 0.12 * level) * weapon_multiplier这里面0.12是青铜级别成长的斜率，前期感受明显，后期因为weapon_multiplier的乘区开始变大，叠加出来的数字会越来越好看。
敌人的属性曲线反着来：敌人的血量增长要比玩家伤害增长更慢，但敌人的数量和刷新频率增长要更快。这会造成一种“我之前一刀一个怪，现在虽然还是一刀一个，但数量多到走位都困难”的压迫感，迫使玩家持续跑图而不是站桩输出。
5.3 地图与资源：肉鸽不止是“数值随机”
很多仿幸存者的项目只做数值随机，忘了地图随机同样是肉鸽体验的重要组成部分。我的做法是：在一张固定大小的地图上，用随机种子生成固定数量的障碍物、破片掩体和资源点。每次新开一局，种子不同，地图布局就不一样。
不用做复杂的地牢生成算法，最简单的做法是把地图切分成网格，每个网格按概率生成障碍物，但相邻障碍物不能堵死出路：
def generate_map(seed, grid_w=40, grid_h=30, obstacle_prob=0.12): random.seed(seed) grid = [[0] * grid_w for _ in range(grid_h)] for y in range(grid_h): for x in range(grid_w): if random.random() < obstacle_prob: grid[y][x] = 1 # 保证玩家出生点周边三格无障碍 ... return grid这看起来简单，实际上已经有“程序化生成”的影子了。之后如果想增加深度，可以在这张网格上做“斑块化”，比如让障碍物聚集在某些区域生成，其他地方保持空旷。肉鸽的玩家其实不指望你生成出多么精妙的结构，他们要的是“每一局的地图都能让走位策略发生变化”。
6. 性能实测：当同屏 500 个敌人时，Pygame 还撑得住吗
写到这里，你肯定担心性能问题。Pygame 是 CPU 渲染，所有绘制操作最终都是往 Surface 上画点、画线、blit 贴图。当同屏实体数飙升到几百个，性能会迅速成为瓶颈。但我实测下来，通过几个针对性优化，500 个敌人同时在场还能稳定跑 60 帧并不难。
6.1 瓶颈在哪里：明明是 2D，为什么还会卡
Pygame 在游戏循环里的耗时大头通常有三个：绘制调用数量、对象创建频率、碰撞检测复杂度。
绘制调用的核心指标是每帧blit的次数。如果你每帧对每个敌人做一次screen.blit(image, rect)，500 个敌人就是 500 次 blit，再加上子弹、粒子、UI，整个循环的绘制耗时轻轻松松超过 10ms。而 60 帧的帧预算只有 16.7ms，留给逻辑更新的时间所剩无几。
对象创建频率的问题在子弹身上最明显。如果每帧都Bullet(...)创建新对象、打空之后让它被垃圾回收，Python 的 GC 会频繁触发，表现就是帧率曲线忽高忽低。子弹数量大的时候，必须做对象池。
碰撞检测的复杂度我前面已经用空间桶解决了，这里不重复。绘制和对象复用是优化主战场。
6.2 三个立竿见影的优化手段
第一个是裁剪。绝大多数情况下，敌人从屏幕外刷出来是有前置接近过程的，距离玩家超过一个相机视野半径的敌人根本不该被绘制。我直接在 draw 阶段做视口剔除：只绘制与摄像机矩形相交的实体。
def draw_visible(self, surface, camera_rect): for enemy in self.enemies: if enemy.rect.colliderect(camera_rect): enemy.draw(surface)这一步能筛掉 30% 到 50% 的绘制调用，而且实现成本极低。
第二个是对象池。子弹这个对象在幸存者游戏里的生命周期非常短，发射后存活往往不到一秒钟。我维护一个BulletPool，池子里常驻 200 颗子弹的实例，需要用就从池里取，击中了就标记为“可回收”，而不是直接删除。
class BulletPool: def __init__(self, size=200): self.bullets = [Bullet() for _ in range(size)] def spawn(self, pos, direction): bullet = self.bullets[self.index] bullet.pos = pos bullet.direction = direction bullet.alive = True self.index = (self.index + 1) % len(self.bullets) return bullet第三个是批量绘制。如果很多敌人使用的是同一张素材图，不需要逐个 blit，而是先把它们按贴图分类，同一张贴图的敌人合并绘制。Pygame 的 blit 有硬件加速，这步对贴图类素材效果拔群。就算暂时没有美术素材，也可以先把同一颜色的圆形敌人合并画到一个临时 Surface 上，再一次性贴到屏幕。
6.3 帧率测试与取舍
我在自己的机器上做了一组对比测试，截取同样 60 秒的游戏流程，统计平均帧率：
| 场景 | 优化前 | 优化后（裁剪 + 对象池 + 空间桶） |
|---|---|---|
| 同屏 100 个敌人 | 60 帧 | 60 帧 |
| 同屏 300 个敌人 | 37 帧 | 60 帧 |
| 同屏 500 个敌人 | 21 帧 | 54 帧 |
| 同屏 800 个敌人 | 12 帧 | 38 帧 |
这个数据说明，优化真正解决的是 100 到 500 这个区间，因为这是大多数玩家的真实体验区间。800 个敌人属于极端压力测试，就算掉到 38 帧，肉鸽游戏经常因为“屏幕快被怪海淹没”而看不清状态，玩家对帧率下降的容忍度反而很高。倒不用为了极端情况无脑优化到极致，游戏是体验工程，不是跑分工具。
7. 收尾的实操建议：打包、扩展与我的开发心得
这个项目的核心玩法已经能完整跑通之后，接下来面临的就是“让别人也能玩到”和“怎么继续拓展”的问题。
7.1 打包：让朋友不装 Python 也能玩到
PyInstaller 是 Pygame 最经典的打包工具。我的打包命令长这样：
pip install pyinstaller pyinstaller --onefile --windowed --name survivor main.py--onefile打成一个单文件，方便分发；--windowed在 Windows 下不会弹出无用的命令行窗口。打包产物在dist/survivor.exe，双击就能跑。注意素材文件要放到打包目录下对应位置，我在项目里统一把素材路径写在一个RESOURCES字典里，打包时用sys._MEIPASS处理临时解压目录，这个坑很多新手会撞上，提前设计好路径接口能省很多事。
7.2 低成本扩展玩法清单
幸存者类游戏的扩展空间非常大，而且很多功能实现成本比想象中低。我列一份优先级排序：
- 新武器类型：改变子弹生成逻辑即可，例如穿透弹只需要让子弹穿过敌人后继续飞行。
- 角色差异化：每个角色有基础属性修正，比如“移速 +10%，血量 -15%”，用配置文件维护。
- 被动遗物系统：玩家可以在游戏中收集几个被动装备，每个装备改变一条公式，代码上就是一个附加乘法器或加法器。
- 特效与音效：Pygame 的
pygame.mixer可以直接播放 wav 音频；粒子效果就是一组生命周期为 0.x 秒的轻量实体类。 - 每日挑战模式：用时间种子生成固定地图和掉落分布，玩家挑战后互相比分数。这个功能在肉鸽圈子里非常受欢迎，因为它提供了“公平竞争”的共同语境。
7.3 我的几个真实心得
最后一小段，说点“如果重新做一遍，我会怎么做”的事情。
第一，素材和逻辑解耦要趁早。我一开始直接画一堆彩色圆当敌人在代码里写死，后来换美术素材时发现颜色和圆半径写进了很多逻辑里，改起来非常痛苦。正确做法是让实体类只关心image和rect，圆形碰撞属于调试期可视化，不要耦合进正式逻辑。
第二，数值配置一定要外置。我前期把伤害、冷却、刷新间隔这些硬编码散落在各个类里，调平衡时恨不得满项目跑着改数字。后来全部挪进一个balance.json，游戏启动时读进配置字典。改动数值从“改代码”变成“改配置”，测试效率提升非常多。
第三，肉鸽游戏必须频繁玩自己做的游戏。听上去像废话，但很多人写完系统就觉得自己已经懂了手感。真正跑到五分钟之后，你才会发现某个升级组合强得离谱、某个波次节奏卡到让人无处可走。把“自己玩”当成日常开发流程的一部分，而不是上线前的验收动作。
这个项目从环境搭建到最终能跑出完整的一局，前后大概两周的业余时间。如果你也正打算用 Python 练手，恰好对肉鸽幸存者玩法感兴趣，希望这篇文章能帮你把已经踩过的坑提前绕开。剩下的，就是打开编辑器，去写你的第一个pygame.init()了。
