如何准备一场 ICPC 比赛

在大约去年的 12 月份，我接到了“存在湖北省赛出题任务”的消息，并加入了出题组？总之在经过了一些可能比较混乱的沟通，在今年的 3 月份，我们得到了要准备武汉邀请赛，并由我担任命题组组长，比赛时间初步定在 5 月份。

准备一场比赛的第一步是选择一些题目，由于先前一直不确定是否存在武汉邀请赛的命题任务，并且手上还有一场多校的命题任务，所以题目相对紧张。于是，在经过又一轮的祈祷和化缘后，我们大致凑出了足够满足一场比赛的十二道题。事实上，和正式赛相比，我们原样保留了其中的十道题目，但可以肯定的是，和最终正式的比赛相比，选手的体验绝对是悬殊的。

在完成了题目的初筛工作后，距离比赛时间尚远，我们决定重新审视现有的题目。显然，这套题目并不成熟，铜牌题是一道“构造满足一些条件的矩阵”的题目，且做法是直接给出一个可循环复制的构造。这样一道无法解释思路，只能靠打表观察做出的对于选手来说并不有趣，我们决定把他换成一道压轴的 lxl 的数据结构题，但是此时，一道原定是多项式复杂度的题目被豹子爆标到了三次方，于是整体的难度偏高了，于是我们准备加入一道相对套路的题目，来作为前期题，优化选手的做题体验。

之后考虑到银牌题的类型比较单一，我把从 cfz 手里要来的一道思考难度相对较低，但是需要有比较好的代码功底才能写明白的题加入了比赛。

之后题目大体就被敲定下来了，在 polygon 上完成了标程和数据的准备之后，我们开始了验题环节。最开始邀请的几只队伍几乎都只完成了 9～10 题。直到赛前半个月，两只足够强的队伍才入场验题，并都在原定的压轴题上，用一个相对（相当）简单的做法路径通过了，而 intended solution 是一个相当巧妙的组合双射。

于是，我们决定更换这道题，但是距离比赛已经没有太久，但好在再一次化缘之后，我们获得了一道还算清新的构造题，在我和武大的红毛哥交流后，得到了这道题一个相当棒而且足够优秀的做法。在简单讨论之后，我们决定加强这题，并使他成为了新的压轴题。

之后虽然一直在担心比赛难度过高，并且预估的金牌线从 5 题一直喊到了 3 题，但考虑到现有的题目确实区分度和梯度良好，我们就没有再换题了。

接下来就是准备比赛的各种材料了，我和邢苏瞳捏了剩下几个热身赛题。豹子帮助我们生成了中英两份题面和完整的数据包。我从青鱼手上偷来了题解的模版，并认真手写了（划重点）一份题解。

接下来就是动身前往武汉了，到达武汉后，武大的同学很热情的接待了我们，我也很顺利的配置好了热身赛的题目，热身赛也如期解决，虽然出现了一些“整个机房没有 g++ 编译器”的乌龙，但是也很快解决了，看起来明天的正赛会足够顺利。

但是在晚间配置正式赛题目的时候，我们惊奇的发现，一些测试点较多，标程（或者需要测试的错解）较多的题目上，出现了代码随机 RE 的现象。经过屡次尝试，我们复现了当且仅当同时评测的程序数量大于等于四份的时候，就会出现 RE 的情况。技术组的同学一通修理后看起来修好了这个问题，并笃定正赛的时候不会出现同一时间刻内大量提交的事件，同时我们也都认为，热身赛没有选手反馈类似的问题，那就是没问题。

但很不巧，这确实是个大问题，在正赛开赛的时候，由于我对昨天的技术问题仍有顾虑，手动重测了几份在签到题 RE 的代码后发现，昨天随机 RE 的现象又出现了。技术组的同学也暂时没有找到原因，我和圆圆只能疯狂的一条条手动重测所有的 RE 代码。幸运的是，在群里询问了对这方面技术比较精通的群友后，顺利排查出了问题并解决了，但此时比赛已经开赛 1.5h，所以也给所有赛时收到影响的同学道个歉。

后续就是看着金牌线不断的涨到了 5 题（黑子说话！），然后顺利完赛。讲评，滚榜，颁奖，赶动车回到学校...