Algorithm 按时间顺序排列的事件，在事件之前*有连续的评论

如果这有点含糊，我会提前道歉，但我甚至不知道如何处理这个问题的基本想法——包括是否知道有一个合适的术语可以搜索

我试图编写一个表驱动的系统，对按时间顺序排列的事件进行动画制作，在这个系统中，描述性的注释也会从表中取出，但注释是在实际事件动画之前发布的，所以不像子标题那样，子标题与屏幕上的事件同步出现

进一步解释：

给我一张桌子

Seq | Event                                  | Start | End | Pace
 1  | Walk up to A                           |       |  A  | Walk
 2  | Stand at A                             |   A   |     | Stand
 3  | Walk from A to B                       |   A   |  B  | Walk
 4  | Run from B to C                        |   B   |  C  | Run
 5  | Stand at C, turn left                  |   C   |     | Stand
 6  | Turn left at C and walk to D           |   C   |  D  | Walk
 7  | At D quickly spin around your own axis |   D   |     | Stand
 8  | Run back to A                          |   D   |  A  | Run

等等。运动的速度和站立或围绕轴心旋转的持续时间是由不同的属性决定的——毕竟，有些人比其他人更快

关键是评论——本质上是事件专栏中的文本——将在实际动作之前阅读

创建这样的序列

Seq | Commentary                               | Movement
 0  | See the toon walk up to A and stop there | animation of movement to A from random point
 1  | They now stand and will move from A to B | toon stands in place
 2  | at B they will run to C                  | toon is walking towards B
 3  | at C they will turn left                 | toon is running towards C
 4  | then they walk from C to D               | toon is still running towards C
 5  | at D they spin around their axis         | toon is walking towards D
 6  | after spin they will run back to A       | toon does the spin at D, 
    |                                          | based on timing they are running back to D

我试着在这里包括一些边缘案例。例如，如果偶数非常短，以至于评论的持续时间将比动画的持续时间长，则强制在运动之前立即背靠背阅读两篇评论

想到像视频和审计编辑这样的系统，以及它们的多轨道方法，我想我可以做一些类似的事情。我会将序列表“预编译”成一个时间轴，然后通过将其时间移到“左侧”（即时间倒转）来创建注释轨迹。回放将显示两个流

但我完全缺乏这样做的知识，甚至不知道该研究什么，所以我可以学习。这是某种形式的状态机吗？事件循环

该系统最终将在C#/.NET中开发。精确地说，Xamarin允许它在Android和iOS上运行。动画代码实际上是存在的，比如卡通人物在网格上的点之间行走、奔跑、站立（这些点可以归结为坐标）。音频评论，就像阅读事件文本一样，现在也很直截了当（甚至有独立于设备的PCL）

这是我完全失去的时间和同步！从表（和属性）中的信息中创建偏移动画和音频之间的时间流。我研究了诸如状态机和图论之类的东西，但坦率地说，很多东西都超出了我的想象

---

我应该在这里研究什么？我非常乐意回答“你想做的是叫XXX，用谷歌搜索算法”和“阅读本文了解更多关于做XXX和YYY的信息”以及“这描述了做ZZZ的算法（即使是用另一种语言或根本不是语言）”.

假设您可以计算前面动画的长度和评论的长度

action | length in sec
a1     | 5
a2     | 2
a3     | 3

commentary | length in sec
c1         | 2
c2         | 10
c3         | 5

首先为操作创建计划：

a-schedule | start | end
a1         | 0     | 5
a2         | 5     | 7
a3         | 7     | 10

现在，通过将每条评论的结束时间调整为相应操作的开始时间，为评论创建一个时间表：

c-schedule | start | end
c1         | -2    | 0
c2         | -5    | 5
c3         | 2     | 7

现在在中从第二个到最后一个元素向后遍历最后一个表，并执行以下操作：

for(int x=c.length-2;x>=0;x--) {
  if (c[x].end> c[x+1].start) {
    c[x].end-= c[x].end- c[x+1].start;
    c[x].start-= c[x].end- c[x+1].start;
  }
}

结果如下表所示：

c-schedule | start | end
c1         | -10   | -8
c2         | -8    | 2
c3         | 2     | 7

每个注释都将在相应的操作之前完成，但是，如果大多数注释的持续时间比操作的持续时间长，那么它们可能会提前完成。但是，如果有几个动作比他们的评论长，那么评论就可以在那里的动作中获益

---

该表显示，您必须在开始播放第一个动作前10秒开始播放第一个解说词。如果你想要一个基于零的时间表，你可以同时改变这两个值。

我想到的前两个步骤。我想我可以决定评论的长度（取决于API）。然后，我对你提出的创建两个时间表的建议表示赞同。现在，我盯着你的伪代码，想弄明白“为什么向后？！”。这也许管用，如果管用的话你会很聪明。但该死，如果我明白原因的话！：）如果您想播放评论，那么以下所有评论都会影响该评论的开始时间。（如果他们需要的播放时间比播放上一个动画所需的时间多）这意味着没有其他评论可以影响最后一个评论的开始时间。我们先确定它的起始位置。让我们看看前面的评论：只有在它后面的一个——有固定的开始时间——可以影响它的开始时间，所以我们也可以计算它。依此类推：我们可以用这种方法修正所有的开始时间，我们不需要重新计算它们中的任何一个。太棒了！现在正在做这件事。事实证明，要得到评论的长度并不像我想象的那么容易。我可能需要根据文本长度使用一些手势。使用某种发音词典，数一数单词中的音节或元音+增加单词数。（+一些微调：））