新媒体学生用Godot开发2D公交叙事游戏：从零实现城市记忆-平芜编程栈

1. 一个新媒体学生怎么就做起公交游戏了

先说说这个项目的来龙去脉。我是一名新媒体专业的学生，平时课程里接触的大多是图文排版、短视频剪辑、H5页面这些内容，跟"游戏开发"这四个字八竿子打不着。但上学期有一门课程作业，老师给的主题是"城市记忆"，要求用新媒体形式做一个能让人产生共鸣的作品。我一开始想的是做个短视频合集，拍一拍老街道、老站牌，但转念一想，短视频太卷了，同班同学估计一半都交视频，根本冒不出头。

后来有一天我坐公交回家，车上人不多，我靠着窗户看外面的街景一站一站往后退，突然觉得这个东西很有意思——公交线路本身就是一条叙事线，每一站都是一个节点，有上有下，有等待有出发。如果把它做成一个游戏，让玩家扮演一个公交司机或者乘客，沿着线路走一遍，是不是能把"城市记忆"这个主题讲得更有沉浸感？

这个念头一出来就压不住了。我开始在网上搜"公交模拟游戏"，发现市面上确实有一些，比如《巴士模拟》系列、《迷你公交》之类的，但要么是3D大制作，门槛高得离谱，要么是纯经营类，跟"城市记忆"的情感表达完全不搭。我就想，能不能用轻量级的工具，做一个2D的、偏叙事向的小体量公交游戏？不需要炫酷的3D建模，不需要复杂的物理引擎，重点放在"线路"和"站点故事"上。

于是就有了这个项目。最终做出来的东西，说实话，跟商业游戏没法比，但它确实是一个能跑起来、能玩、能让人看完站点故事之后有一点感触的小作品。下面我把整个制作过程拆开来讲，包括我踩过的坑、用到的工具、具体的实现思路，以及一个新媒体背景的学生是怎么一步步把"游戏"这个东西啃下来的。

提示：这篇文章适合对游戏制作感兴趣但完全没有编程基础的新媒体、设计、文科类同学阅读。如果你已经是有经验的开发者，可能觉得有些地方太基础，但里面关于"轻量叙事游戏"的设计思路和工具选型逻辑，应该还是有点参考价值的。

2. 整体设计思路与工具选型

2.1 为什么不做3D、不做经营，偏偏做2D叙事

这个决定其实是被现实逼出来的。我一开始也幻想过做一个3D的公交驾驶模拟，玩家能坐在驾驶位上转方向盘、踩油门、看后视镜。但我很快发现，光是建一个像样的公交车模型就够我学半年的3D建模，更别说还要处理物理碰撞、交通AI、天气系统这些东西。对于一个新媒体学生来说，这条路根本走不通。

所以我给自己定了一个原则：用最小的技术成本，换最大的情感表达。具体来说就是三条：

2D俯视视角：不需要建模，用简单的图形和色块就能表现道路、站点、车辆，美术门槛极低。
叙事驱动而非操作驱动：玩家不需要精确控制油门刹车，只需要在站点做出选择（比如"是否让这位乘客上车""是否在这个站多停一会儿"），推动故事发展。
短流程、高密度：整条线路控制在15到20个站点，单次通关时间15到25分钟，每个站点都有一段小故事或一个小抉择，不拖沓。

这个思路定下来之后，后面所有的工具选型和开发决策都围绕它展开。

2.2 工具选型：为什么最后选了Godot而不是Unity

工具选型这块我折腾了挺久，前后试了三个方案，最后才定下来。我把对比过程整理成表格，方便你参考：

工具	上手难度	2D支持	导出格式	适合人群	我的评价
Unity	中等偏高	一般	PC/移动/Web	有编程基础	功能强但太重，2D工作流不如专门工具顺手
Construct 3	低	很好	Web/移动	零基础	拖拽式，上手快，但免费版限制多，复杂逻辑吃力
Godot	中等	很好	PC/移动/Web	愿意学一点脚本	轻量、免费、2D原生，GDScript接近Python，文科生也能啃

我最终选Godot的原因有三个。第一，它完全免费开源，没有任何功能限制，导出Web版也不需要额外付费。第二，它的2D引擎是原生设计的，不像Unity那样2D是"3D的简化版"，节点系统对2D场景特别友好。第三，GDScript这门脚本语言语法很像Python，我之前学过一点Python做数据分析，看起来不陌生。

注意：如果你完全没碰过编程，Godot也不是不能学，但建议先花两三天过一遍官方文档的"入门"部分，把节点、场景、信号这几个概念搞清楚，后面会顺很多。

2.3 美术和音效：不会画画的人怎么解决视觉问题

美术是我最头疼的部分。我手绘水平大概就是"能画出一个人形但比例全错"的程度，找美术同学帮忙也不现实，人家有自己的作业要赶。后来我想了一个办法：用几何图形加色块做极简风格。

具体做法是这样的：

公交车用圆角矩形加两个小圆当轮子，颜色用低饱和的蓝灰色。
道路用深灰色长条，站点用圆形标记，当前站点高亮成暖黄色。
背景用渐变色的天空加简单的建筑剪影，建筑剪影直接用矩形拼，不需要任何细节。
乘客用不同颜色的小圆点表示，不同颜色代表不同身份（比如红色是上班族、绿色是学生、橙色是老人）。

这套视觉方案的好处是，它看起来"故意很简洁"，而不是"因为画不好所以很粗糙"。玩家不会觉得你美术差，反而会觉得这是一种风格选择。音效方面，我用了一个免费音效库里的环境音（车轮声、报站声、人群嘈杂声），加上几段简单的钢琴循环作为背景音乐，整体氛围就出来了。

3. 核心机制拆解与实现要点

3.1 线路系统：怎么把一条公交线变成游戏关卡

线路系统是整个游戏的骨架。我的设计是：整条线路有18个站点，每个站点是一个独立的场景节点，玩家从起点站出发，依次经过每个站，直到终点站。每个站点包含以下信息：

站点名称和编号
站点背景描述（一段50到100字的文字，营造氛围）
到站时触发的事件（可能有乘客上车、可能有乘客下车、可能什么都没有）
玩家的可选操作（比如"开门""不开门""等待""直接开走"）

在Godot里，我用一个数组来存储所有站点的数据，每个站点是一个字典（Dictionary），结构大概是这样：

var route_data = [ { "id": 1, "name": "起点站·老火车站", "description": "清晨六点，站台上只有零星几个人。空气里有一股煤灰和豆浆混在一起的味道。", "event": "boarding", "passengers": ["上班族", "学生"], "choices": ["开门上客", "稍等片刻", "直接发车"] }, { "id": 2, "name": "第二站·人民公园", "description": "公园门口的梧桐树叶子黄了一半，几个老人在打太极。", "event": "none", "passengers": [], "choices": ["继续行驶"] }, # ... 后续站点 ]

这个数据结构的好处是，我可以在不修改游戏逻辑的情况下，随时增删站点、调整故事内容。比如我想在第五站和第六站之间加一个"临时站"，只需要在数组里插入一条数据就行，代码完全不用动。

实操心得：一开始我把站点数据直接写在场景文件里，结果每次改文案都要打开Godot编辑器，特别麻烦。后来改成用JSON文件存储，用代码读取，改文案直接用文本编辑器打开JSON改就行，效率高了很多。如果你也要做类似的东西，强烈建议把数据和逻辑分离。

3.2 乘客系统：让每个小圆点都有故事

乘客系统是我花心思最多的地方。表面上看，乘客就是屏幕上移动的小圆点，但我想让每个乘客都有一点"人味"。具体实现上，每个乘客有以下属性：

身份：上班族、学生、老人、带小孩的妈妈、流浪歌手等
目的地：哪一站下车
心情值：一个0到100的数值，影响乘客的对话内容和行为
故事标记：是否触发过特殊对话

当乘客上车时，会根据身份和心情值随机生成一句短对话，显示在屏幕下方的对话框里。比如上班族可能说"今天又要迟到了"，学生可能说"作业还没写完"，老人可能说"这趟车我坐了三十年"。

心情值的设计是这样的：如果玩家在站点等待时间过长，乘客的心情值会下降；如果玩家平稳驾驶（没有急刹车），心情值会缓慢上升。心情值低于30时，乘客会表现出不耐烦，甚至在下车时留下一句抱怨。这个机制让玩家意识到，自己开的不是一辆空车，而是一车有情绪的人。

# 乘客心情值更新逻辑（简化版） func update_passenger_mood(delta): for passenger in passengers: if is_braking_hard: passenger.mood -= 5 * delta elif is_driving_smooth: passenger.mood += 1 * delta passenger.mood = clamp(passenger.mood, 0, 100)

注意：心情值的变化幅度要控制好，太快会让玩家觉得烦躁，太慢又感觉不到。我实测下来，急刹车一次扣5点左右、平稳行驶每秒回1点，这个节奏比较合适。

3.3 选择系统：每个站点都是一次小抉择

选择系统是推动叙事的关键。在每个站点，玩家会面临一个选择，选择的结果会影响后续的剧情走向。比如在"医院站"，有一个老人要上车，但车上已经满了，玩家可以选择"让老人上车，挤一挤"或者"告诉老人等下一班"。前者会让老人心情值高，但其他乘客心情值下降；后者则相反。

这些选择不会导致"游戏结束"，但会累积成一个"城市温度"的隐藏数值。通关时，根据这个数值的高低，会显示不同的结局文案。数值高的时候，结局是"这座城市虽然拥挤，但总有人愿意让一让"；数值低的时候，结局是"每个人都赶着自己的路，车窗外的风景一闪而过"。

这个设计的目的是让玩家意识到，每一个微小的选择都在塑造这座城市的温度。它不评判对错，只是呈现结果。

4. 完整实操流程与关键环节实现

4.1 从零搭建Godot项目：第一步做什么

如果你也想用Godot做类似的东西，我把从零开始的流程梳理一遍。首先去Godot官网下载最新稳定版，安装过程没什么好说的，一路下一步就行。打开之后新建一个项目，选择"2D"模板，渲染器选"Forward+"或者"Mobile"都可以，2D项目对渲染器要求不高。

项目建好之后，第一件事是规划场景结构。我的场景树大概是这样：

Main (Node2D) ├── Background (ColorRect) ├── Road (Node2D) │ ├── RoadLine (Line2D) │ └── Stations (Node2D) │ ├── Station1 (Area2D) │ ├── Station2 (Area2D) │ └── ... ├── Bus (Area2D) │ ├── BusSprite (Polygon2D) │ └── CollisionShape2D ├── Passengers (Node2D) ├── UI (CanvasLayer) │ ├── DialogueBox (Panel) │ ├── ChoiceButtons (VBoxContainer) │ └── MoodBar (ProgressBar) └── GameManager (Node)

这个结构的关键点是：UI单独放在CanvasLayer里，这样它不会随着游戏世界移动；GameManager单独一个节点，负责管理全局状态（当前站点、乘客列表、城市温度值等），其他节点通过信号跟它通信。

4.2 公交车移动与站点触发：核心代码拆解

公交车的移动逻辑其实很简单，我用的是"沿路径点移动"的方案。在Road节点下放一组Path2D和PathFollow2D，公交车作为PathFollow2D的子节点，通过改变PathFollow2D的progress值来让公交车沿着路径移动。

# 公交车移动逻辑（简化版） extends PathFollow2D var speed = 200.0 var is_moving = false var current_station_index = 0 func _process(delta): if is_moving: progress += speed * delta # 检查是否到达下一个站点 if progress >= station_positions[current_station_index]: is_moving = false progress = station_positions[current_station_index] emit_signal("arrived_at_station", current_station_index)

站点触发用的是Area2D的body_entered信号。每个站点是一个Area2D，当公交车的碰撞体进入站点区域时，触发到站逻辑。但这里有个坑：如果公交车在站点停着不动，body_entered只会触发一次，不会重复触发。所以我在到站逻辑里加了一个标志位，确保每次到站只处理一次。

实操心得：Path2D的曲线控制点要调好，不然公交车转弯的时候会"飘"出去。我的经验是，每个转弯至少放三个控制点，让曲线平滑过渡。另外，公交车的旋转角度可以用rotation = get_angle_to(path_position + path_direction)来动态计算，这样车头始终朝向行驶方向。

4.3 对话系统与选择分支：怎么让文字"活"起来

对话系统我一开始想得很复杂，后来发现其实就是一个"显示文字、等待输入、根据输入跳转"的循环。我用了一个简单的状态机来管理：

# 对话系统状态机（简化版） enum DialogueState { IDLE, SHOWING_TEXT, WAITING_CHOICE, PROCESSING } var current_state = DialogueState.IDLE var current_dialogue = [] var current_index = 0 func show_dialogue(dialogue_array): current_dialogue = dialogue_array current_index = 0 current_state = DialogueState.SHOWING_TEXT display_next_line() func display_next_line(): if current_index < current_dialogue.size(): dialogue_box.text = current_dialogue[current_index] current_index += 1 else: current_state = DialogueState.WAITING_CHOICE show_choices()

选择分支的处理是这样的：每个选择对应一个回调函数，选择之后调用对应的函数，修改游戏状态，然后继续对话。比如"让老人上车"这个选择，会调用on_let_elder_board()函数，把老人加入乘客列表，同时降低其他乘客的心情值。

这套系统的好处是，它足够简单，我不用去学什么复杂的对话树插件，自己写一百多行代码就搞定了。而且因为是自己写的，想怎么改就怎么改，加个"打字机效果"或者"角色头像"都很容易。

4.4 存档与结局系统：让玩家愿意再玩一遍

存档系统我用的是Godot内置的ConfigFile，把关键状态（当前站点、乘客列表、城市温度值）存到一个本地文件里。读档的时候反向操作就行。这个没什么技术含量，但有一个细节要注意：乘客的心情值要存，但乘客的临时对话不要存，不然读档之后乘客会说一些跟当前情境不符的话。

结局系统是根据"城市温度"这个隐藏数值来判定的。我把温度值分成三档：

温度值范围	结局文案	触发条件
0-40	"每个人都赶着自己的路，车窗外的风景一闪而过。"	多次拒绝乘客、急刹车频繁
41-70	"这座城市有时拥挤，有时空旷，但总有人在等下一班车。"	选择比较均衡
71-100	"这座城市虽然拥挤，但总有人愿意让一让。"	多次帮助乘客、平稳驾驶

这个设计让玩家有动力再玩一遍，试试不同的选择会导向什么结局。我实测下来，大部分玩家第一遍通关后都会再玩一次，想看看"如果当时让那个老人上车会怎样"。

5. 常见问题与排查技巧实录

5.1 公交车卡在站点不动了怎么办

这是我最常遇到的问题，尤其是在早期版本。原因通常有三个：一是PathFollow2D的progress值没有正确更新，二是站点触发信号重复触发导致状态机卡死，三是公交车的碰撞体跟站点的碰撞体发生了物理冲突。

排查思路是这样的：先在_process里打印progress值，看看它有没有在变化。如果progress在变但车不动，那就是PathFollow2D的父节点Path2D的曲线有问题，检查控制点是不是设成了(0,0)。如果progress不变，那就是is_moving标志位被意外设成了false，检查一下是不是有其他地方修改了这个变量。如果是碰撞冲突，把公交车的碰撞层和站点的碰撞层分开，用信号而不是物理碰撞来触发到站逻辑。

提示：Godot的调试器很好用，可以在代码里打print()，也可以在编辑器里开"远程调试"，实时看变量的值。我建议在开发阶段多打日志，上线前再删掉。

5.2 乘客心情值变化太突兀怎么调

心情值的变化曲线需要反复调。我一开始设的是急刹车扣20点，结果玩家一个急刹车，全车乘客直接暴怒，体验很差。后来改成扣5点，又觉得不痛不痒。最后我加了一个"平滑过渡"：急刹车时先扣3点，然后在接下来2秒内每秒再扣1点，总共扣5点，但玩家感觉上是"慢慢变差"而不是"突然变差"。

另外，心情值的显示也很重要。我用了一个进度条来显示每个乘客的心情，但后来发现玩家根本不会去看每个乘客的进度条。改成"整体氛围"显示——屏幕边缘的颜色会根据全车平均心情值变化，心情好是暖色调，心情差是冷色调——玩家就能直观感受到了。

5.3 导出Web版之后打不开怎么排查

Godot导出Web版有几个坑。第一，导出模板要下载对，在"编辑器设置"里找到"导出模板"下载对应版本。第二，Web版对文件大小有限制，如果项目里用了太多高清图片或音频，导出后可能加载失败。我的做法是把所有图片压缩成WebP格式，音频压缩成OGG格式，整体包体控制在10MB以内。第三，本地测试Web版不能直接双击HTML文件打开，需要起一个本地服务器，用Python的http.server或者Node的http-server都行。

# 用Python起一个本地服务器测试Web版 cd export/web python -m http.server 8000 # 然后浏览器打开 http://localhost:8000

5.4 常见问题速查表

问题现象	可能原因	解决方法
公交车不动	progress未更新或is_moving为false	检查PathFollow2D设置和标志位
到站不触发	Area2D碰撞层不匹配	检查碰撞层和掩码设置
对话文字不显示	UI层级被遮挡或字体未设置	检查CanvasLayer层级和字体资源
选择按钮点击无反应	按钮信号未连接	检查信号连接和回调函数名
导出Web版黑屏	资源加载失败或路径错误	检查资源路径和导出设置
存档读档后状态错乱	存档数据不完整	检查存档字段是否覆盖所有关键状态

实操心得：我踩过最大的坑是"信号重复连接"。在Godot里，如果场景被多次实例化，信号可能会被连接多次，导致一个操作触发多次回调。解决方法是连接信号之前先disconnect，或者用connect的CONNECT_ONE_SHOT标志。这个坑我卡了整整一个下午，最后在官方文档的角落里找到了答案。

6. 一个新媒体学生做游戏的几点真实体会

做这个项目之前，我一直觉得"游戏开发"是一个门槛很高的东西，需要会编程、会美术、会策划、会音效，一个人根本搞不定。但做完之后我发现，对于小体量的叙事游戏来说，最重要的不是技术，而是你想表达什么。技术只是工具，工具可以学，但表达的欲望和故事的积累，才是真正稀缺的东西。

我用的所有工具都是免费的，Godot不要钱，音效库不要钱，字体不要钱，连我参考的教程都是B站上免费的。整个项目从零到能玩，花了大概三周时间，其中一半时间在学Godot的基础操作，另一半时间在写代码和调细节。如果你也是新媒体或者文科背景，想做一个自己的小游戏，我的建议是：先想清楚你要讲一个什么故事，然后找一个最简单的工具把它实现出来，不要一上来就追求完美。

这个公交游戏后来在课程展上放出来，有同学玩完之后跟我说，他每天坐公交上学，从来没注意过车上的人是什么表情，玩了这个游戏之后，第二天坐车的时候特意观察了一下，发现确实每个人都有自己的故事。听到这句话的时候，我觉得这三周没白熬。

最后再分享一个小技巧：如果你也想做类似的项目，但又不想学编程，可以试试用Twine做纯文字版的公交叙事游戏，或者用Ren'Py做视觉小说风格的版本。工具不重要，重要的是你愿不愿意花时间去把脑子里的那个想法变成能让人看到、摸到的东西。我一开始也觉得自己做不出来，但做着做着，东西就出来了。