第一个 Luau 脚本：编写、运行并检查结果

这个练习要完成什么 #

我们编写一个练习脚本，输出路线名称与计划中的检查点数量。它不会在地图上创建检查点，也不会保存玩家进度。变量在这里用于学习存储数值并检查输出。重点是把一行代码与能够观察到的结果联系起来。

完成后，你应能在 Explorer 找到文件，解释每行代码，修改数字并验证结果。使用 Studio 和独立练习项目，实验前先保存。正式游戏可能产生大量无关消息，反而使第一次检查更困难。

1. 在 ServerScriptService 中创建 Script #

打开 Explorer，找到 ServerScriptService，通过添加对象按钮创建普通 Script，命名为 TrainingMessage。这个练习名称说明用途。确认选择的是 Script，而不是 LocalScript 或 ModuleScript。

打开文件，用下面的示例替换练习文件的初始内容。不要删除正式项目中不认识的脚本。如果 Explorer 或编辑器没有显示，先重新打开相应面板。示意图展示练习文件应该放在哪里。

2. 输入代码，逐行理解 #

第一行创建局部变量 checkpointCount，数值为 3。第二行把字符串 Training course 存入 message。第三行把两个值传给 print。数字不用引号，文本放在引号中，逗号分隔参数。

完整复制三行，包括括号和引号。声明与使用变量时拼写必须一致，checkpointCount 与 checkpointcount 不同。这里的数字只是练习数据，不会自动添加三块平台，也不会启用真正的检查点。

local checkpointCount = 3
local message = "Training course"
print(message, checkpointCount)

3. 开始测试，找到消息 #

通过 Window 或对应工具打开 Output。开始游玩测试，查找包含 Training course 和 3 的消息。旁边可能显示时间、来源和上下文。检查数据本身，不必要求所有显示细节完全相同。

print 输出到开发者日志，不是在平台上方或玩家界面显示文字。下图展示代码到 Output 的消息路径。检查完成后停止测试，再修改原始练习脚本。

4. 只修改一个值 #

把 3 改为 5。运行前先预测：路线名称不变，数字变为 5。再次测试，将消息与预测比较。这样每次运行都有明确要验证的问题。

如果仍看见 3，检查是否修改了 TrainingMessage，是否停止了之前的测试，是否正在阅读新的消息。旧日志可能仍在。不必为了修复一个文件再创建相同脚本，否则容易产生重复消息。

5. 加入简单计算 #

停止测试，用第二个示例替换文件内容。计划三个检查点，完成一个，还剩两个。减法使用数字，print 输出 Remaining 和 2。数值是手动设置的，还不会响应角色行为。

把 completedCheckpoints 改为 2，预测还剩 1，再验证。改为 3 时结果为 0，改为 4 则是 −1。这说明语法正确不等于游戏规则正确；真正的进度系统需要处理不合理状态。

local plannedCheckpoints = 3
local completedCheckpoints = 1
local remainingCheckpoints = plannedCheckpoints - completedCheckpoints
print("Remaining", remainingCheckpoints)

6. 有控制地制造一次错误 #

在已保存的练习副本中，暂时删除第一个示例里 Training course 的右引号。尝试运行并阅读错误，然后恢复引号，确认正确消息重新出现。你只改了一个字符，因此知道应该先检查哪里。

只在练习项目做这个实验。错误的具体措辞可能因编辑器和位置不同而变化。找到提示中的文件与代码位置，与可用版本对照，恢复完整一行。不要同时修改几个无关区域。

7. Output 没有消息时 #

依次检查：测试是否运行；普通 Script 是否位于 ServerScriptService；脚本是否启用；是否有错误阻止执行；Output 过滤器是否允许显示消息。这个服务器练习也要检查上下文过滤。日志中的文本搜索可能隐藏正常消息。

消息重复时，查看来源，可能有两份 TrainingMessage，也可能是多次运行的旧记录。删除前在 Explorer 确认文件。求助时保留准确错误文本与对应脚本名称。

8. 不看模板验证理解 #

创建新版本：courseName 保存练习路线名称，stageCount 保存数字 4。用 print 一起输出，始终使用新变量名。再只修改名称，确认数字保持不变。

用自己的话解释哪个值是文本、哪个是数字、哪行代码发送消息。如果解释不清，回到第一个示例，每次只改一个值。理解三行代码，比粘贴无法验证的大系统更有帮助。

下一步学什么 #

保存一个名称清楚的可用版本。下一次可练习条件判断：完成数量超过计划数量时发出警告。真正的检查点还需要对象、事件和每个玩家的状态。本练习的变量不是完整进度系统。

继续用 Output 检查小修改：预测结果、运行代码、比较数值，再调查差异的一项原因。机制变复杂后，这个习惯仍然有用。