华为普朗克计划一轮游记
个人感悟
大家看标题应该也知道，没错，快乐一轮游。
不得不说，初赛结束的时候，有一种空虚感和悔恨感，耗时一个多礼拜，却gain nothing，非常有种技不如人的感觉，令人沮丧，emo。
虽然说叫软件比赛，但我发自真心地认为，这实际上算是一种数学比赛，三个程序或许不是合理的队伍搭配。硬要我说，coding的任务一人足矣，重要的是数学建模和idea，当然还有团队沟通。
我把题目概述放在下面吧，想知道更具体题目的话，可以去网上搜。最后简单说一下我们臭臭的策略。
题目概述
目标：赚取更多的资金。
程序操控方式：选手作为运输公司来运输货物赚取资金，每个选手有5艘轮船、10个机器人。选手需要使用机器人来执行移动、搬运等动作来完成物品递送任务，同时赚取利 润。在运行结束时，选手拥有的资金数即为最终分数，所获得的资金越高越好。 初赛时间为15,000帧（最多5分钟）。
程序交付方式：选手程序通过标准输入和标准输出与判题器进行交互。判题器运行帧率为每秒50 帧，对于每一帧，判题器都会把场上的实时信息通过标准输入传递给选手程序， 同时从选手程序读取机器人的操控指令作用到各个机器人上。每一帧有 1000/50=20ms 的时间，由于判题器需保留5ms执行计算来模拟真实场景，故选手 程序需要在15ms内做出每一帧的决策，如果超过15ms未做出决策，则系统将直 接忽略这一帧的控制进入下一帧，并且在选手程序返回控制指令前，不会再发送 状态数据给程序。 注意，你不需要让自己的程序具备处理50FPS的性能，程序处理帧率低于50FPS 也能正常运行（例如只处理10FPS也可以），但是处理更高的帧率可以让你实现更 高精度的控制。 程序的输入和输出格式请参考3.4 输入与输出格式。
判题器使用：今年的比赛判题器与数据集完全开放给大家下载，并且做了跨平台设计 （Windows/Linux/MacOS），大家可以根据自己习惯选择对应版本下载。但是请注 意，比赛平台使用Linux，因此无论你选择何种平台开发调试，都必须确保你的代 码可以在Linux下编译运行。
策略记录
机器人寻路很简单，A*算法，也就是在BFS的基础上弄个启发式函数，我们选的计算曼哈顿距离，因为简单。
难点有以下几个：
- 机器人碰撞
- 机器人、港口和货物的分配逻辑
- 船只和港口的分配逻辑
机器人碰撞
我们尝试了两种方式，最后选取第二种
- 预判所有机器人的下一帧，若出现碰撞，则进行停止或绕路
- 在计算机器人路径的时候，考虑进去其他机器人在未来哪一帧会出现在哪里，将其位置当作障碍物绕开。计算好路径后，记录下此机器人未来会出现在哪里。如果机器人没活干，停下了，那就无条件给有路径的机器人让路。
舍弃第一种的原因非常简单：不论怎么优化，都不可能避免三个及以上的机器人同时卡在一起所产生的碰撞。相信我，我们在这个方案上花的时间足够长，考虑了非常多情况，最终证明这是个dead end。
第二种方法也没办法完全避免碰撞，主要问题是当复数个空闲机器人停在港口，再让路时可能会导致连环撞。当然这也只是一种可能，实际情况下概率很小，基本不会发生。
分配逻辑
我们的分配逻辑固定且简单：在前500或1000帧中，每个机器人绑定一个港口搬运货物。在此之后，竞争出货物最多的五个港口，每个港口能分配2个机器人和1艘船。
之所以采取这种“211”策略，是因为我们没有想出更高效的轮船分配机制，在众多方案中，这个方案效果最好，that’s all。
当然，有些地图有“孤岛”的情况发生，即港口之间或机器人之间并不联通，但是情况极少。在初始化阶段，进行连通性的测试即可。
除此之外，还有一些参数的设置和排序的根据（比如是先拿高价值货物，还是高性价比货物）之类的细节，就不细说了。
大致就如此吧。
唉，这种比赛真的能做到不怀着功利性参加吗？我还没到这种境界，这真的让我沮丧了一段时间。再过一两年参加会不会更好呢，我也不知道，或许吧。失败总会有，but it drains me a lot。