一个写了8年Python的老程序员，决定做个游戏。结果花了两周在Pygame里画羊，发现连碰撞检测都要手写。然后他打开了Godot——14天后，游戏上线itch.io，他自己却卡在了第2关。
这不是励志故事，是一次技术选型的真实代价对比。
Python版本：一个"能运行"的陷阱
开发者Weier JuJu在GitHub上开源了Python版源码。用Pygame框架，从零手写物理引擎、碰撞检测、动画循环。代码能跑，但每加一个新机制都要重写底层。
他后来回忆：「Python版本更像是在造轮子，而不是做游戏。」
Pygame的定位是教学工具，不是生产工具。JuJu花了大量时间处理帧率同步、内存管理这些Godot内置的功能。最终成果是一个「能运行」的原型，但离可发布还差很远。
关键数据：Python版本开发周期未公开，但Godot版本仅用了14天完成从迁移到上线。
Godot版本：引擎替你做决定
迁移到Godot后，JuJu的变化很明显。节点系统（Node System）替代了手写对象管理，内置的物理引擎替代了自研碰撞检测，动画状态机让角色动作从代码里抽离出来。
他保留了全部手绘素材——两只羊、草地、栅栏，没有使用任何生成式AI。美术风格极简，但统一。
游戏结构也极简：只有2个关卡。第1关教学，第2关难度陡增。JuJu自己至今没通关。
这种设计选择暴露了独立开发者的典型困境：内容量 vs 完成度。
itch.io上线：免费策略背后的考量
游戏以完全免费形式发布，支持Web端即开即玩。 itch.io平台对独立开发者零门槛，但零收入。JuJu的意图很明确：验证流程，积累反馈，而非变现。
他在发布文中直接放出了Python版GitHub链接，标注为「Python学习资源」。这个细节说明他清楚两个版本的价值定位——Python版是教学材料，Godot版是产品。
技术选型的结论写在代码仓库里：同一个创意，不同工具链，产出效率差出一个数量级。
游戏目前状态是「已完成但作者自己打不过」。JuJu在文末留下一句话：「Feel free to give it a try」——没有更新路线图，没有DLC计划，只有一个开发者对自己作品的诚实距离感。
如果你从Python转向Godot，两周足够做出一个能上线的游戏。但问题是：你会给自己设计的关卡设置多高的难度？
热门跟贴