eesast/thuai4

THUAI4 原电子系第22届队式程序设计大赛

THUAI4

THUAI4 原电子系第22届队式程序设计大赛

赛题简介

清（pen）彩（she）无（zhan）限（shi）

框架简介

暂定架构如下：

C/S架构，实时游戏，同时支持人/AI，支持多种部署方式（局域网、服务器、本地）。

仓库说明

本仓库为所有开发工作共用仓库，请勿上传大文件，每个目录均已配置好Visual Studio开发时的.gitignore忽略规则，请根据需要自行修改，不要修改主目录下的.gitignore忽略规则。请各开发组在开发中维护好自己负责子目录内的README.md，记录设计思路、开发进度等信息（可参照示例），方便大家了解当前工作。

目录分配

• CAPI：选手接口，生成可执行文件
• communication：通信组件，生成.NET Standard 2.0， .NET Core 3.1类库与.Net Core 3.1可执行文件（Agent）
• config：配置文件，主要是游戏中数值等信息
• dependency：需要使用的各种依赖与proto文件
• installer：下载/更新器，生成Windows GUI程序
• interaction：玩家交互，生成Unity程序
• launcher：游戏启动器，生成Windows GUI程序。
• logic：游戏逻辑，生成.Net Core 3.1可执行文件
• playback：回放组件，生成.NET Standard 2.0和 .NET Core 3.1类库
• resource：用于存放主目录下markdown文件的图片等

分支

• master：工作较稳定的版本或阶段性成果，需要2 reviewers
• dev：各个小组开发工作最新进展，需要1 reviewer

开发规则

使用Git和GitHub进行版本控制，开发组成员应遵守如下开发规则：

1. Fork
2. 创建功能分支
3. 开发后Push到个人仓库
4. Pull Request
5. 删除功能分支
6. Pull eesast仓库到个人仓库

其中commit与Pull Request中的信息应认真书写，写明完成的功能。eesast仓库分为master与dev两个分支，dev分支用于日常开发，master分支用于保存阶段性成果与稳定版本，dev分支只要一个reviewer即可merge，建议同小组同学互相review，master分支需要负责人操作。

其他注意事项

• 注意代码可读性，注释要让他人能看懂
• 适时整理开发文档，对接文档等内部资料
• 注意做好部会记录，记录各种饼和锅，及时整理赛题规则，以免事后忘记
• 开发组在赛事开始前准备好规则手册，C++API手册提供给选手
• 开发过程中注意各部分的组件化，避免不同部分之间的耦合。便于下一届复用。
• 注意跨平台的问题
• 尽量不要上传大文件
• 多了解其他小组的工作

开发组成员

逻辑组：刘雪枫，李晨阳，谢童欣

交互组：张书源，潘修睿

通信组：何思成，李泽润，刘芳甫

赛事组：史益鸣，叶召城

端茶倒水：李翔宇

thuai4's Issues

CAPI 设计接口讨论

目前 CAPI 接口设计成以下这个样子

class API {
    // 选手允许进行的操作
};
class AI {
    virtual void play() {
       // 选手的逻辑
   }
}

这样倒也没有啥太大的问题，我建议设计成以下形式

class GameApi {
    // 选手允许进行的操作，全部弄成虚函数
};

class AIBase {
    virtual void play(GameApi& g) = 0;
};

using CreateAIFunc = AIBase* (*)();

int thuai4_main(int argc, char** argv, CreateAIFunc f) {
    // 平台写好的 main 函数
} 

// 以上是平台给选手的接口
// 以下是选手的代码

class AI: public AIBase {
    void play(GameApi& g) {
        // 选手的逻辑
    }
};

AIBase* CreateAI() {
    return new AI();
}

int main(int argc, char** argv) {
    return thuai4_main(argc, argv, CreateAI);
}

好处：

1. 将选手代码和平台代码彻底解耦，特别地，选手不用管 AI 类那个鬼画桃符的构造函数
2. 解耦之后，就可以把平台在常见平台上编译成 lib 给选手了，可能会方便一些。CAPI依赖那么多，不见得每个选手都会配工程。
3. 现在 GameApi 类是虚的，可以用不同的子类 hook 了，比如我们可以考虑提供一个新的方便选手调试的 GameApi 子类，里面可以打 log 或者对选手的调用合规性做一些复杂的校验，新的设计做这些更方便。

以上建议仅供参考。

编码问题之讨论

总所周知，utf-8 是世界码农之众望所归，code page 是应该最好放在勃物馆里观瞻碰都不要碰的玩意。但目前本仓库精神分裂，大部分代码都是 utf-8，但 C++ 部分代码似乎有使用 936 的趋势。

余以为这样不好，理由如下：

1. 公然使用 GB 编码有损科协之品味。
2. 选手在 windows 下面用 GB 无所谓，最后程序是要跑在 linux 上的，那用 GB 就有的搞了。

分析

Linux: 用 utf-8 就什么事都没有，不用 utf-8 就什么事都有
Windows: 系统核心编码是 utf-16，其他编码主要依靠 code page，而 code page 这套系统对 utf-8 的支持一言难尽

windows，msvc 与 编码

对于 windows 上的 C++，影响编码的有如下几个地方

源文件编码：如果没有 BOM，msvc 默认使用 code page 来读源程序，这个可以用 /source-charset:utf-8 来强制使用 utf-8

字符串编码：这个控制 msvc 如何把非 ASCII 字符串编码成字节

系统编码：描述以 A 结尾 WINAPI 如何解释字符串，可以用 GetACP() 去拿，但这个由系统 locale 设置，应用程序和编译选项无法控制这个

控制台输出编码：描述输出到控制台的字符串应该使用何种编码，可以用 SetConsoleOutputCP 修改，但这个对 utf-8 的支持非常差劲，有一系列的 bug，详见

https://stackoverflow.com/questions/10882277/properly-print-utf8-characters-in-windows-console
https://stackoverflow.com/questions/45575863/how-to-print-utf-8-strings-to-stdcout-on-windows

解决思路

其一，干掉所有注释和字符串中文，考虑到 CAPI 是要给选手看的，我觉得这个难。

其二，C++ 源代码全部改成 utf-8 with bom，windows 下没啥缺点；但 gcc 不支持 bom，linux 上会很烦。

其三，C++ 源代码全部改成 utf-8，给 msvc 工程设置 /source-charset:utf-8 选项，我觉得这个不错。

测试方法

自从 win 1903 之后，windows 可以把系统 locale 设置成 utf-8 了，分别把 locale 设置成 Chinese; Chinese with utf-8; English with utf-8 三种都测试一下，编译运行没有乱码，就说明没问题。这样就可以清理编码问题，定下来写文档里了。

注：在控制面板的 Region / Administrative / Change system locale 里设置系统 locale

缺点

方法三应该严格的比现在用 GB 来的好，但还是有两个缺点：

1. 如果 windows 下提供预编译的库，编译环境和运行环境 locale 不一致，就会乱码。
2. 如果某台 windows 电脑 locale 设置成非中文且没有开启 utf-8 支持，那么中文一定会乱码。

这两点，除非把代码里所有 cout 都换成 wcout（我建议别这么做，小心 linux 下面出玄学问题），应该就是没办法，windows 就是这么烦。