知安局1. 系列回顾与本节定位
1.1 前四篇学到了什么
从系列开篇到现在，我们其实已经走过了相当长的一段路。第一篇搭好了Godot 4.x的项目骨架，搞清楚了场景（Scene）、节点（Node）、脚本（Script）这三者到底怎么配合；第二篇把玩家角色从一张静态图片变成了能跑能跳的完整角色，顺便把InputMap输入映射和CharacterBody2D的移动逻辑理顺了；第三篇重点处理了动画，包括AnimationPlayer做帧动画、AnimatedSprite2D的切换条件，还有动画树（AnimationTree）的基本用法；第四篇引入了第一个敌人和基础战斗系统，Area2D的碰撞检测、生命值、伤害数字、简单的血条UI都是那时候做的。
到这里，一个“能玩”的游戏雏形已经有了。但如果你把前四篇做出来的东西实际跑一遍，你会发现一个问题：画面很“平”。背景就一张图，相机要么一动不动、要么跟不上角色，角色跳起来的时候没有影子，攻击敌人时没有任何受击反馈，整个画面像一张纸贴在屏幕上。
这其实是几乎所有2D游戏新手都会卡住的阶段——逻辑能跑了，但“手感”和“观感”完全不到位。而这一篇，我打算专门花一整节来解决这个问题。
1.2 本篇要解决的核心痛点
我见过太多新手项目死在这个节骨眼上：代码已经写了一两千行，角色的移动、跳跃、攻击、敌人AI全都有了，但游戏一跑起来就是没有“游戏感”。说穿了，就是缺少对2D游戏视觉层次的把控。
所谓2D视觉原理，归根结底就三件事：相机怎么跟随、画面层次怎么拉开、光效和氛围怎么叠加。这三件事做不好，哪怕你素材画得再精致，玩家也会觉得“这游戏很廉价”；反过来，哪怕是简单的几何图形拼出来的原型，只要这三件事处理到位，立刻就有商业游戏内味儿。
所以这篇的内容，我会把重点放在：
- Camera2D从“能用”到“好用”的进阶配置
- 视差背景（Parallax）让2D场景产生纵深感
- CanvasModulate全局调色与2D光照的实战搭配
- 用“视觉感知”的思路做一个简单的敌人警戒系统（这正好呼应“2D双雷达融合”的思路——一个负责距离检测，一个负责视线角度检测，融合后触发警戒）
这篇适合的读者是：前四篇都已经跟下来、角色控制和战斗循环已经能跑通的开发者。如果你是一路跳着看、直接搜到这篇的，我建议至少先把基础移动和场景切换搞清楚，不然相机和视差的代码加进去，很容易和已有逻辑冲突。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 相机系统从“能用”到“好用”的进阶配置
2.1 Camera2D的工作原理与基础配置
Godot里Camera2D这个东西，说简单也简单——把节点挂到角色下面，设个是否“当前生效”（Enabled/Current），它就会跟着角色走。但真正决定一个游戏相机手感好坏的，是下面这几个参数：
- Position Smoothing（位置平滑）：控制相机是否延迟跟随。Speed值越低，延迟越明显，画面会有一种“镜头慢半拍跟上角色”的拖拽感。
- Rotation Smoothing（旋转平滑）：2D横版游戏基本用不到，但如果你做的是2D物理小游戏或者平台跳跃的旋转关卡，这个参数能避免相机角度瞬间跳变导致的晕眩。
- Zoom（缩放）：2D游戏的分辨率适配和游戏“尺寸感”全靠它。2倍缩放让角色看起来巨大，0.5倍则能看到更宽广的场景。
- Limit（边界限制）：相机不会超出关卡边界的硬约束。
我见过很多新手在第四篇做完后，直接把Camera2D作为子节点挂在Player下面，什么都不调。结果是什么？角色跑到场景边缘，相机也跟着跑，露出一大片空白；角色跳起来，镜头立刻垂直跟随，画面上下颠簸严重。这两个问题光靠拖节点是解决不了的，必须要手动配置。
先说边缘空白问题。Camera2D给了四个边界的设置项：Left、Top、Right、Bottom。操作方法是在场景里选中Camera2D，直接拖动这四个边界框，把它对齐到你的关卡背景图片的边界。注意：一定要留出大约一个屏幕宽度的余量，否则相机在极限位置时，玩家可能突然看不到自己角色身后的敌人。
然后是上下颠簸问题。横版过关游戏中，除非有明确的垂直探索需求，否则我强烈建议你把相机在Y轴上的跟随优先级调低，甚至锁定。
2.2 配置一个手感自然的跟随相机
我实际项目里最常用的做法，是不把Camera2D挂在Player下，而是单独放到场景根节点下，用脚本来控制它跟随。好处是解耦：以后角色死亡、切换场景、回放录像时，相机逻辑不受角色生命周期影响。
脚本的核心逻辑大概是这样：
gdscript复制extends Camera2D
@export var target: Node2D
@export var follow_speed: float = 5.0
@export var y_lock_enabled: bool = true
@export var y_lock_position: float = 0.0
func _process(delta: float) -> void:
if target == null:
return
var target_pos := target.global_position
if y_lock_enabled:
target_pos.y = y_lock_position
global_position = global_position.lerp(target_pos, 1.0 - exp(-follow_speed * delta))
这里我用了一个指数平滑公式1.0 - exp(-follow_speed * delta)，而不是直接用lerp(target_pos, 0.1)。原因在于：lerp的插值系数如果写死，帧率波动时平滑速度会不一致；而指数平滑在60帧和120帧下体验几乎完全一致，这属于那种“参数看着一样但手感差距明显”的细节。
follow_speed这个值，我推荐在3到8之间调。低于3，镜头太“肉”；高于8，跟得太紧，失去平滑效果。对于普通横版动作游戏，5.5到6.0是我测试多次后的甜点区间。
另外一个非常实用的小技巧：给相机加一个“预判偏移”。角色向右跑时，相机应该稍微偏向右侧，让玩家提前看到前方的敌人和地形。实现方式是基于角色的velocity和facing方向，给目标位置加一个偏移量：
gdscript复制var look_ahead := Vector2(
target.velocity.x * 0.3,
0.0
) if target.has_method("get_velocity") else Vector2.ZERO
var target_pos := target.global_position + look_ahead
2.3 相机抖动：受击反馈的加分项
相机抖动（Screen Shake）是2D动作游戏里最划算的“打击感投资”。实现方式并不需要改动相机的核心跟随逻辑，只需在跟随过程中叠加一个随时间衰减的随机偏移。
我在项目里封装了一个CameraShakeManager单例（AutoLoad），对外暴露一个shake(intensity: float, duration: float)方法。内部维护一个shake_timer和shake_intensity，在_process中计算当前帧的随机偏移：
gdscript复制extends Camera2D
var shake_intensity: float = 0.0
var shake_timer: float = 0.0
var shake_duration: float = 0.0
var original_offset := Vector2.ZERO
func shake(intensity: float, duration: float = 0.2) -> void:
shake_intensity = intensity
shake_duration = duration
shake_timer = duration
func _process(delta: float) -> void:
if shake_timer > 0.0:
shake_timer -= delta
var ratio := shake_timer / shake_duration
offset = original_offset + Vector2(
randf_range(-1.0, 1.0) * shake_intensity * ratio,
randf_range(-1.0, 1.0) * shake_intensity * ratio
)
else:
offset = original_offset
注意几个关键点：
- 抖动幅度要乘上剩余时间的比例，实现“逐渐停下来的惯性感”，而不是突然截止。
- 抖动结束后，一定要把
offset恢复成original_offset，否则相机位置会被污染。 - 不要把抖动直接加到
position上，而是在offset上操作，这样不会影响平滑跟随的目标计算。
有了这套相机系统，我在后面做敌人警戒、受击反馈时，只需要在伤害触发处加一行camera.shake(6.0, 0.15)，打击感立刻上了一个档次。
3. 视差背景系统：让2D画面“活”起来
3.1 视差原理与素材分层策略
2D视差的本质很简单：距离观察者越远的物体，移动速度越慢。把这个原理映射到横版游戏里，就是背景的山脉比近处的树木移动慢，树木比地面移动慢。
Godot 4.x中，官方推荐使用Parallax2D节点（注意，Godot 3.x里的ParallaxBackground + ParallaxLayer在新版中仍然可用，但Parallax2D更轻量、更直观）。Parallax2D的核心配置就一个值：scroll_scale——一个二维向量，表示该图层相对相机移动的速度倍率。Vector2(1, 1)表示和主场景完全同步；Vector2(0.5, 0.5)表示移动速度减半；Vector2(0, 0)表示完全静止。
素材分层的策略，我强烈建议遵循“前中后+动态”的四层原则：
- 第0层（最远）：天空、云层、远处山体，scroll_scale约0到0.1，几乎不动。
- 第1层（远景）：远山、城市剪影、大面积树木，scroll_scale约0.2到0.4。
- 第2层（中景）：场景中的主要建筑结构、大型地形物件，scroll_scale约0.6到0.8，一般放在玩家角色的后面。
- 第3层（前景）：草丛、碎石、前景树枝，scroll_scale可以大于1（比如1.2到1.5），产生速度快于主场景的“镜头掠过”效果。
素材的宽高规格也需要注意。视差层图片最好比屏幕尺寸大出至少两倍，并且做成可无缝拼接的。如果你用的素材是AI生成或网上下载的单张图，拼接时可以用TextureRepeat的Mirror模式，但前提是图片左右边缘颜色和纹理过渡要自然。
3.2 Parallax2D节点配置与Ground层处理
我们在项目里新建一个ParallaxBackground节点作为根，下面挂多个Parallax2D子节点。每个Parallax2D里放一个Sprite2D或者TileMapLayer，用于承载具体素材。
实际操作中，我推荐这种做法：不用手动把每个视差层都用坐标对齐到场景原点，而是把每个Parallax2D选中后，在编辑器里直接设置scroll_scale，再把子节点Sprite2D的centered属性设为false，让图片以左上角为基准点放置。
在Parallax2D下面，有一个repeat_size属性用来控制纹理重复的尺寸。如果设置了重复，需要把Sprite2D的texture_repeat设为Enabled。Ground层（地面）的处理稍微特殊一点：地面本身就是玩家和敌人站立的地方，必须和物理碰撞完全同步，所以Ground层不能放进Parallax2D里，而是直接作为主场景的TileMapLayer或StaticBody2D。只有与地面深度接近的装饰物（地面上的小石子、落叶）才放到scroll_scale为1的普通图层里。
这里我踩过一个很典型的坑：给Ground装饰层设了scroll_scale=1，但主场景是一个很大的TileMap，结果相机移动时，装饰层和TileMap出现微小错位。原因在于Parallax2D对相机位置做了取整处理，而TileMap的物理位置是浮点驱动的。解决办法是给Parallax2D节点设置scroll_scale的精度修正：把Ground层放主场景原位，不用Parallax2D；或者给Parallax2D增加position_offset，微调到和TileMap对齐。
3.3 视差层复用与边缘缝隙处理
制作视差背景时，最常见的问题就是图片边缘缝隙。特别是当相机移动到场景边界附近时，视差层的重复纹理可能在左右边缘露出透明黑缝。
解决办法有两个。第一个是把所有视差层图片做成左右可无缝拼接的Tileable纹理——这在制作阶段就要想好，用Photoshop或Krita时，用“Offset Filter”配合“Heal Selection”处理边缘。第二个是在Parallax2D里，把repeat_size设置成比屏幕略大的尺寸，同时把子节点Sprite2D的region_enabled打开，启用纹理区域裁剪，这样重复区域只是显示画面内的那一段，不容易出现缝隙。
我在实际项目里是两层方案叠加使用的。素材侧尽量用Tileable图片；节点侧设置一个足够大的repeat_size + 纹理裁剪。这样即使相机跑到最边缘，视差层也不会露馅。
另外提醒一个性能问题：如果你的视差层图片分辨率较高（比如4096x4096），并且有多个Parallax2D层，那么同时存在多张高分辨率纹理在显存里，可能会引起中低端设备掉帧。解决方案是用import设置压缩纹理格式（VRAM Compressed），并适当降低远景层的分辨率——毕竟远景在屏幕上占的像素区域不大，分辨率降一半几乎看不出区别，但显存占用能省许多。
4. 2D光照与全局色调：给场景定“情绪”
4.1 CanvasModulate与Light2D家族的配合逻辑
很多新手做完场景，觉得画面刺眼、颜色“太艳太干”，又找不到具体原因。其实大部分情况下，是因为开局就没有给整个场景设置一个统一的色调基准。在2D游戏里，CanvasModulate就是用来做这件事的。
CanvasModulate是一个全局节点，它会把它设置的颜色和场景中所有CanvasItem按照乘法的混合模式叠加。说白了：你设成灰色，整个场景变暗；设成暗蓝色，整个场景像月光下的夜晚；设成橙红色，场景就是黄昏黄昏的感觉。
实际操作中，我会在场景根节点下挂一个CanvasModulate，把它的color设为纯白色（#ffffff），这样它等于不存在，之后用代码在白天夜晚切换时，只要平滑过渡这个颜色值就行。
但要注意，CanvasModulate是整体亮度调整，跟光照方向无关。如果想做出更精细的光影——比如角色手里的火把照亮周围区域、窗口透出暖色光、树木投下阴影——就需要Light2D系列登场了。
Godot 4.x中的2D光照系统基于纹理遮罩（Light Occluder）实现。你需要：
- 一个
PointLight2D（点光源）或DirectionalLight2D（平行光，类似太阳光） - 配合每个会遮挡光线的物体（比如墙壁、角色、树干）挂上
LightOccluder2D，并给它一个由OccluderPolygon2D定义的遮罩形状 - 在Light2D节点上设置
shadow_enabled = true，这样被遮挡的区域才会显示出阴影
比较关键的一个细节：Light2D默认只作用于它自己所在CanvasLayer内的节点。如果你想让它照亮整个主场景，需要把Light2D和所有要受光照的物体放在同一个CanvasLayer（通常是默认Layer 0）内。如果游戏UI是单独一个CanvasLayer，UI一般不需要被光照，所以不会受影响。
4.2 点光源参数调节与昼夜循环实现
我的项目中，火把是最常出现的光源。PointLight2D放到火把素材的位置，关键参数如下：
texture：光的形状和颜色贴图。Godot自带的默认径向渐变贴图（生成一个256x256的径向光贴图即可）。texture_scale：光的范围。我一般设置在1.5到3之间，具体看游戏单位尺寸。如果你角色高度是64像素，光源范围大约是角色高度的4到6倍。energy：光强。默认1.0，做火把时调到1.5左右，配合CanvasModulate的暗色背景，效果比较自然。shadow_color：阴影颜色。默认是黑色，但实际场景中最好调整成深蓝色（如#1a1a2e），因为现实世界中阴影不是纯黑，带一点环境色会更耐看。blend_mode：混合模式。默认Add。做特殊光源时（比如闪光灯），可以用Screen模式。
昼夜循环的实现，我推荐在场景根节点加一个DayNightManager脚本，里面直接对CanvasModulate的color和场景里所有PointLight2D的energy做插值：
gdscript复制extends CanvasModulate
@export var day_color := Color(1, 1, 1, 1)
@export var night_color := Color(0.15, 0.15, 0.3, 1)
@export var cycle_duration := 60.0
var time := 0.0
func _process(delta: float) -> void:
time += delta / cycle_duration
var phase := (sin(time * TAU - PI / 2) + 1.0) / 2.0
color = day_color.lerp(night_color, phase)
这个公式用正弦波控制昼夜过渡，phase从0到1平滑往复。基于0.5的值，我们还可以判断当前是白天还是夜晚，从而控制敌人是否进入更警觉的状态。这一环，正好和后面的敌人视觉感知系统接上。
4.3 光遮挡与性能取舍的实用建议
做2D光照时，最常见的两个问题是：光照过多导致性能下降；光遮挡边缘出现锯齿或缝隙。
先处理性能问题。每个PointLight2D在渲染时都会对其覆盖范围内所有受光照影响的CanvasItem进行逐像素计算。如果你在一张地图上摆了20个火把，再叠加CanvasModulate、多个Parallax2D，中低端手机上帧率会明显下滑。
我建议的策略是：地图上的静态光源（路灯、蜡烛、窗口灯）用Sprite2D自发光贴图做一个“伪光照”效果，即直接用一张带Alpha的发光纹理叠加在背景上，不占用实时光照预算。只有玩家身上的光源（火把、手电筒、魔法球）或需要和被遮挡物体互动的光源（比如角色能挡住光线产生动态阴影）才用真正的PointLight2D。实测下来，这个方案能让实时光源数量控制在2到3个之内，帧率非常稳。
再看阴影缝隙问题。LightOccluder2D的遮罩多边形如果不贴合碰撞体边缘，就会出现阴影边缘漏光的现象。我的修复方式是：在编辑器中给OccluderPolygon2D的“烘焙”（Bake）功能加一个1到2像素的膨胀，让遮罩往外扩一点，这样阴影边缘更扎实，也不容易被误判成碰撞。
5. 敌人视觉感知：双雷达融合的简化实现
5.1 为什么需要对敌人做“视觉感知”
前四篇里，敌人的行为模式基本都是“玩家进入固定范围的Area2D→敌人攻击”。这种模式在固定站桩敌人上没问题，但一旦敌人需要巡逻、搜索、追踪玩家，这种“全知型”的检测就显得很假——敌人不用管朝向、不用管遮挡，360度全视野，谁都会觉得诡异。
一个合格的敌人视觉系统，至少要满足这些条件：
- 玩家必须在敌人正面的一定角度范围内，这个范围内的敌人才能看见玩家。
- 玩家与敌人之间如果隔了一道墙，即使站在正面也看不见。
- 距离越远，视觉感知越弱；最好有一个“警觉”到“发现”的过程，而不是瞬间锁定。
这其实就是“2D双雷达融合”的通俗解释：一个雷达负责距离检测（圆形范围），另一个雷达负责角度检测（扇形视野），两个雷达的结果做融合处理，再加一层射线检测做“视线遮挡”过滤，最终才能决定敌人是否看到了玩家。
5.2 用Area2D + RayCast2D实现双雷达检测
具体实现上，我推荐用Area2D做距离雷达，用两个RayCast2D（或一个RayCast2D配合角度计算）做视线检测。
先在敌人节点下建一个Area2D，命名为DetectionArea，加一个CircleShape2D作为碰撞形状，半径根据敌人种类来定：普通巡逻兵给200像素，精英兵给300像素。CollisionLayer设为敌人感知层（比如Layer 3），Mask设为玩家层（Layer 1）。
然后写一个视觉检测脚本：
gdscript复制extends Node2D
@export var vision_range: float = 200.0
@export var vision_angle: float = 60.0 # 半角角度
@export var detection_loss_time: float = 0.5
var has_line_of_sight := false
var detection_timer := 0.0
@onready var detection_area: Area2D = $DetectionArea
@onready var ray: RayCast2D = $RayCast2D
func player_in_cone(player_pos: Vector2) -> bool:
var to_player := player_pos - global_position
var forward := Vector2.RIGHT.rotated(rotation)
var angle_diff := abs(rad_to_deg(to_player.angle_to(forward)))
return angle_diff <= vision_angle
func _physics_process(_delta: float) -> void:
var player := get_tree().get_first_node_in_group("player")
if player == null:
alert_level = 0.0
return
var bodies := detection_area.get_overlapping_bodies()
var player_in_range := bodies.has(player)
if player_in_range and player_in_cone(player.global_position):
ray.global_position = global_position
ray.target_position = to_local(player.global_position)
ray.force_raycast_update()
has_line_of_sight = ray.get_collider() == player
else:
has_line_of_sight = false
if has_line_of_sight:
detection_timer = detection_loss_time
else:
detection_timer = max(0.0, detection_timer - _delta)
这段代码里player_in_cone负责角度雷达的判断，detection_area.get_overlapping_bodies()负责距离雷达的判断，RayCast2D的碰撞结果负责“视线遮挡”的最终裁决。三者同时满足时，才认为敌人看见了玩家。
关键参数说明：
vision_angle：半角。60度意味着敌人总共能看到前方120度的范围。越凶猛的敌人这个值越大，但最大不建议超过85度。detection_loss_time：玩家离开视线后，敌人保持“可疑”状态的时间。这是为了给玩家一个反应窗口，让AI更自然。ray.target_position：注意这是局部坐标，用to_local(player.global_position)转换，不要直接填global_position。
5.3 警戒状态机与“发现→追踪→丢失”流程
有了视觉检测结果之后，敌人的行为需要用一个简单的状态机管理起来。我通常定义三种状态：
PATROL：巡逻状态，按预设路径点移动，视觉检测到玩家后进入SUSPICIOUS。SUSPICIOUS：警觉状态，停止巡逻辑，面朝玩家离开的方向，如果detection_timer归零则回到PATROL，如果再次看见玩家则进入CHASE。CHASE：追击状态，朝向玩家追逐；如果视觉丢失超过detection_loss_time，且找不到玩家，就回到PATROL。
在代码里就是一个枚举加一个switch_state：
gdscript复制enum State { PATROL, SUSPICIOUS, CHASE }
func _process_state() -> void:
match state:
State.PATROL:
if has_line_of_sight:
change_state(State.SUSPICIOUS)
State.SUSPICIOUS:
if has_line_of_sight:
change_state(State.CHASE)
elif detection_timer <= 0.0:
change_state(State.PATROL)
State.CHASE:
if not has_line_of_sight and detection_timer <= 0.0:
change_state(State.PATROL)
这里有一个细节：从SUSPICIOUS到CHASE的过程中，我给敌人加了一个约0.3秒的“反应延迟”，避免玩家一进入视野瞬间被锁定，给玩家一点闪避的余地。用get_tree().create_timer(0.3)实现。
这套视觉系统配合前文的相机抖动和光照系统，敌人突然发现玩家时播放一个感叹号音效、角色攻击时轻微震屏、夜晚模式下敌人视野范围缩小——这几个效果叠加在一起，游戏的整体质感和氛围立刻就不一样了。
6. 常见问题与排查技巧实录
6.1 相机和视差相关的典型问题
问题一：相机跟随时的抖动或卡顿
出现这个，先检查你是在_process还是_physics_process里更新相机位置。Godot的物理帧率（默认60Hz）和渲染帧率不一定相同。如果相机在_physics_process里更新，但场景里的物体在_process里移动，两者会不同步，导致视觉抖动。解决方法：统一把相机跟随逻辑放到_process中，或者全部放到_physics_process中，不要混用。
问题二：视差背景总是和主场景差半个像素
这个我前面提过，多半是Parallax2D的scroll_scale精度问题。将视差层里Sprite2D的centered设置为false，并检查repeat_size是否为整数。还有一点，如果相机应用了position_smoothing（平滑跟随），最终相机位置是一个带小数的浮点值，视差层计算时可能会因为舍入方式不同产生偏差。可以把视差层用Camera2D的reset_smoothing()强制同步一下。
问题三：光照让UI变暗
CanvasModulate是全局的，但UI通常会放在单独的CanvasLayer上。CanvasLayer默认的layer属性是1，而主场景的CanvasItem默认在0层。CanvasModulate作用域是所有CanvasItem，它不会管你是不是UI，都会变暗。解决方式：把UI的CanvasLayer的follow_viewport_enabled设为true，并在CanvasLayer节点上单独挂一个CanvasModulate，颜色设成白色，把全局调色抵消掉。或者更简单：把UI的图层级设成比光照后处理更高的层级，并在代码里动态同步亮度。
6.2 视觉检测和感知系统的特殊坑
问题四：敌人隔着墙也能看到玩家
这大概率是RayCast2D没有正确排除“玩家与墙之间的层级”导致的。检查RayCast2D的collision_mask，确保它只检测墙体的碰撞层和玩家碰撞层。如果遮罩混入了其他不需要的层（比如敌人之间互相遮挡），就会出现奇怪结果。另外，force_raycast_update()这个函数必须在_physics_process里调用，如果放在_process里可能因为物理同步问题导致碰撞结果过时。
问题五：玩家突然转身，敌人还能“看见”
这是cone判断里的角度计算问题。to_player.angle_to(forward)返回的是两个向量之间的夹角，范围是[-PI, PI]。但如果你把敌人的rotation直接作为视线方向，当敌人转身时（角度瞬间跳变），角度差会突变，导致上一帧满足条件、下一帧不满足。建议用rotation的变化率做平滑，或者在敌人旋转时不立即更新视觉检测，等旋转完成后再判定。我在项目中给敌人加了一个turn_speed，在CHASE状态下敌人旋转到面向玩家方向，直到角度差小于5度才判定为完全“看到”。
问题六：Area2D的范围检测有时漏判
Area2D的body_entered和body_exited信号在物理帧中触发，存在一个物理帧的延迟。如果你在_physics_process里同时读取get_overlapping_bodies()，会出现一帧内信号还没触发但已经重叠的情况。我建议视觉检测系统完全不用信号，只在_physics_process里轮询get_overlapping_bodies()，这样可以避免信号延迟带来的状态不一致。
6.3 性能排查清单
2D游戏到了这个阶段，基本已经具备了一个迷你项目的复杂度。性能排查我一般按以下顺序检查：
- 检查Draw Calls。Godot编辑器右下角的
Debug菜单打开Visible Collision Shapes和Frame Timing，看看Physics耗时长不长。如果Physics耗时高，检查碰撞体数量——TileMap每一格都自动生成碰撞体时，可能会生成太多collision shapes，可以考虑合并相似的碰撞区域。 - 检查光照贴图数量和分辨率。用
texture_scale尽量控制在2以下，过大的光照贴图在移动端是显存杀手。 - 检查Parallax2D层数。4层以内基本没问题；如果超过6层，即便都是低分辨率图，纹理采样开销也很可观。
7. 从本篇到下一步的扩展思路
相机平滑、视差、光照、视觉感知，这一套组合拳打完，你的2D游戏在“观感”和“手感”上已经甩开纯逻辑原型好几条街了。我自己在实际项目里的体验是：这几样东西并不是独立存在的，它们之间会产生很强的化学反应——夜晚模式下敌人视野缩短，玩家潜行成功后镜头轻微抖动加目标提示；玩家进入敌人视野时，光照色调略微变红，配合相机快速推近，这种“氛围感”是纯逻辑堆不出来的。
接下来你可以继续深入地做几件事：
- 把这套视觉感知扩展到“听觉感知”——玩家跑步时发出噪音，敌人虽然没有视线也能循声过来。这相当于在双雷达基础上加了一个“声呐雷达”。
- 给相机系统增加“锁定Boss”的缩放效果，靠
zoom的平滑插值实现Boss战视觉压迫力。 - 把光照系统从简单的昼夜循环升级成“区域光照遮罩”，不同区域不同色温，营造洞穴、森林、冰原等差异化环境。
这一篇的内容到这里就告一段落了。下一篇我计划开始接入简单的角色技能系统，让你的人物能释放带位移、带特效的招式，再把前面做的震屏、光照、视觉感知全部串进战斗反馈里。到时候你会发现，知识积累到这步，做系统联调比刚开始时顺畅太多了。