友情提示：视频教程观看时请手动设置清晰度。
Scratch3.0的扩展功能里，有一项非常棒的功能，文字朗读。在最新的3.4版本里面已经支持中文朗读了。在联网情况下，可以很方便的实现文字朗读的功能。可以很轻松的做到角色间无缝衔接自然的朗读对话。效果如下：
那么，视频里面的效果，是怎么实现的呢？在进行角色语音对话的编程中都会有什么问题呢，下面来探究一下。
使用说功能或播放录音进行对话
在文字朗读功能出现以前一般用两种方式进行对话类编程。
第一种，无声的单纯显示文字方式。在进行小场景剧或者游戏开场白对话的程序设计时，一般采用外观模块里面的说功能，配合等待延时功能，让几个角色实现对话。虽然设计时间轴的时候有点费脑子，不过总归是能实现，并且思路是简单的。因为说……等待……秒和等待延时功能都可以严格的保证执行时间的，所以大家可以利用时间轴去编排对话。
利用时间轴进行安排角色各语句的执行时间来编写的程序运行没问题，但是可读性非常差，非常非常的差。必须把几个角色，综合分析，还原到一个时间轴上，才能看清楚程序的意图。如果掌握不了时间轴分析方法，就会导致混乱。
第二种，录音方式。播放录音文件，也可以实现朗读。并且录音文件都会显示时长。所以，还是只要把握好了时间轴，进行合理的等待延时，用播放录音的方式实现朗读，也没问题。录音方式有个弊端，就是剧本更改以后，需要重新录音。另外，录音质量会受到环境影响。使用录音的方式和文字朗读相比有些复杂了。
利用角色间广播进行有序对话的弊端
文字朗读一下子让小场景剧类的程序变得有趣起来。解决了说的问题，随之而来的是新的问题。1.文字朗读模块执行的时间长短没有具体的数值。单凭文字少，时间短，文字多，时间长，来粗略估算时间，是很不靠谱的。2.文字朗读要在联网状态下进行，受网络影响会有延迟，导致执行时间更长。所以依旧采用时间轴的方式来安排角色对话，显得已经力不从心了。
我们很自然的想到利用广播功能。比方说，A角色，说完一句话后，广播一条消息，B收到以后再说一句。然后B说完了以后，再广播一句。A收到以后再说一句，再广播……显然从逻辑上分析，这种方式是可行的。并且是最接近实际人与人对话的。那么这种方式的问题是什么呢？问题就是，A和B之间形成了太多的关联，一旦引入第三个角色C的时候，ABC之间的关联就成了一张网。
建立一张联系网是相对容易的，但是更改一张联系网的难度不亚于再重新建立一张联系网。
让导演全面指挥角色有序朗读
在上面进行了这么多的分析以后，更换一种思维方式。既然是小场景剧，那么就给它引入一个导演，导演负责全面协调演员之间的秩序。演员只管听从命令就可以了。这样写程序，一下子变得清晰，并且，程序的可读性也变强了。
那么，导演和演员是怎么具体的分工执行的呢？
这里首先给每个角色安排一个全局变量，去表征角色的状态。设定变量，小猫说话中，0表示没有进行文字朗读，1表示文字朗读进行中。其他角色类似。导演角色需要去判断其他角色有没有朗读，如果有角色在朗读就等待，如果朗读结束，就下命令让对应角色朗读下一句。
演员角色，只管接收和执行命令就可以了。
通过给程序设定一个导演，就是通信中心，让导演角色全面掌握对话类程序的流程，可以很清楚的梳理清楚程序，也可以很轻松的读懂程序。最重要的一点是这样设计程序，很有弹性，可更改性非常强，对剧本的更改或者网络延迟造成的朗读时间长短变化问题不对程序整体运行造成任何影响。
转自公众号：
xtrobot