多人关卡的准备标记通常意味着玩家已确认当前设置。如果队伍修改了关卡选项，先前的准备状态能否继续有效，需要明确约定，否则界面可能把旧确认当成新确认。
下面使用独立的一组输入，逐步记录规则如何产生结果。建议先自行推演，再寻找与记录第一次不同的位置；检查时间单位、端点归属和处理顺序。所有约定均限定在本例中，其他作品采用不同实现并不自动意味着出错。
本例约定与输入
固定三名玩家；每次设置改动把版本号加一，准备动作记住当时版本。尝试开始只在三人准备版本都等于当前版本时通过；本例开始检查不清空记录，也不处理玩家退出。
初始设置版本8，None表示尚未确认 [['准备', 0], ['准备', 1], ['准备', 2], ['开始', None], ['设置变化', None], ['开始', None], ['准备', 2], ['准备', 1], ['开始', 0], ['准备', 0], ['准备', 0], ['准备', 0], ['设置变化', 1], ['开始', 2], ['开始', 1], ['开始', 1], ['准备', 0], ['开始', 0]]
过程与结果
事件1：准备玩家0；当前版本8，三人准备版本[8, None, None]，有效准备玩家[0]。
事件2：准备玩家1；当前版本8，三人准备版本[8, 8, None]，有效准备玩家[0, 1]。
事件3：准备玩家2；当前版本8，三人准备版本[8, 8, 8]，有效准备玩家[0, 1, 2]。
事件4：开始；当前版本8，三人准备版本[8, 8, 8]，有效准备玩家[0, 1, 2]，开始检查通过。
事件5：设置变化；当前版本9，三人准备版本[8, 8, 8]，有效准备玩家[]。
事件6：开始；当前版本9，三人准备版本[8, 8, 8]，有效准备玩家[]，开始检查未通过。
事件7：准备玩家2；当前版本9，三人准备版本[8, 8, 9]，有效准备玩家[2]。
事件8：准备玩家1；当前版本9，三人准备版本[8, 9, 9]，有效准备玩家[1, 2]。
事件9：开始；当前版本9，三人准备版本[8, 9, 9]，有效准备玩家[1, 2]，开始检查未通过。
事件10：准备玩家0；当前版本9，三人准备版本[9, 9, 9]，有效准备玩家[0, 1, 2]。
事件11：准备玩家0；当前版本9，三人准备版本[9, 9, 9]，有效准备玩家[0, 1, 2]。
事件12：准备玩家0；当前版本9，三人准备版本[9, 9, 9]，有效准备玩家[0, 1, 2]。
事件13：设置变化；当前版本10，三人准备版本[9, 9, 9]，有效准备玩家[]。
事件14：开始；当前版本10，三人准备版本[9, 9, 9]，有效准备玩家[]，开始检查未通过。
事件15：开始；当前版本10，三人准备版本[9, 9, 9]，有效准备玩家[]，开始检查未通过。
事件16：开始；当前版本10，三人准备版本[9, 9, 9]，有效准备玩家[]，开始检查未通过。
事件17：准备玩家0；当前版本10，三人准备版本[10, 9, 9]，有效准备玩家[0]。
事件18：开始；当前版本10，三人准备版本[10, 9, 9]，有效准备玩家[0]，开始检查未通过。
共进行7次开始检查，其中1次通过。
如何独立复核
把每名玩家最近一次准备所处的版本与当前版本比较。设置变化后旧标记可以保留作历史，但有效准备人数必须重新按版本计算，而不能只数是否曾准备过。
此处把设置修改看作立即生效的事件，不模拟网络丢包或延迟。联网环境仍应由权威状态确认版本，界面本地亮起的准备标记不能代替服务器认可；本例只解释版本关联的逻辑。
测试时保留原始数据与中间状态，再只改变一个条件作比较。先检查空状态、相等边界、重复输入和最后一步，再比较整体结果；不要为了让最后的数字相同而跳过前面已经出现的差异。明确规则后，复核才有可以重复的依据。