Skip to content

Latest commit

 

History

History
executable file
·
203 lines (137 loc) · 11.9 KB

README.md

File metadata and controls

executable file
·
203 lines (137 loc) · 11.9 KB
Raw

THUAI7

清华大学第七届人工智能挑战赛电子系赛道（原电子系第 25 届队式程序设计大赛 teamstyle25）

Gitee 镜像地址：THUAI7: Gitee Mirror

GitLink 镜像地址：THUAI7: GitLink Mirror

项目主页：THUAI7 Project Home Page

关于本届及历届清华大学人工智能挑战赛与队式程序设计大赛的更多内容参见：THUAI7 Github Wiki

赛题背景

thuai7

在不久的未来，随着 AI 技术的飞速发展，人类探索太空的步伐也大大加快。太空安全对于国家安全的重要性与日俱增，因此，太空建设也成为了各国的重要任务。在这个全新的赛场上，由 AI 控制的高度自动化的太空舰船成为了竞技的主力。它们可以在太空中自由穿梭，执行各种任务，如资源采集、建筑建造、太空战斗等。 新领域的探索总是伴随着风险，太空中的舰船也不例外。在太空中，舰船之间的距离遥远，通讯延迟巨大，因此，舰船之间的冲突往往是在瞬息之间决定胜负。在这个竞技场上，AI 的控制能力、决策速度、战术策略等都将成为决定胜负的关键。

在远离地球的太空中，为了建立起牢固的防线，保卫美好的家园，一场激烈的战斗即将打响。你将扮演舰队指挥官，带领你的舰队在太空中展开一场激烈的战斗，为了最终的胜利，你需要制定合理的战术策略，部署舰船，利用资源，应对敌人的进攻，最终摧毁敌人的基地，夺取最终的胜利。

比赛规则

https://docs.eesast.com/docs/contests/THUAI7/

软件架构

structure

仓库说明

配置说明

本仓库使用 git 进行版本控制，为所有开发工作共用仓库，请勿上传不必要的文件。主目录文件结构非必要请勿修改，且主目录中已配置的 .gitignore、.gitattributes 文件非必要请勿修改；各子目录已预先包含使用 Visual Studio 开发的 .gitignore 模板，可以根据自身需要增加忽略规则；如有必要，可在子目录下自定义 .gitattributes 文件。

目录分配

子目录 说明 主要开发组
.github CI，用于选手包同步到服务器上供选手下载 运维组
CAPI 选手接口，生成可执行文件 通信组
docs 比赛的说明文档 逻辑组、通信组、运维组、界面组
dependency 项目依赖文件，如 proto、dll、lib、dockerfile、shell 脚本等 逻辑组、通信组、运维组、界面组
installer 下载器，用于选手包的下载与更新，生成可执行文件 运维组
interface Unity 界面 界面组
launcher 游戏启动器，用于快速启动游戏，生成可执行文件 运维组
logic 游戏逻辑、Server，生成可执行文件 通信组、逻辑组
playback 游戏回放组件，生成类库 逻辑组
resource 资源文件目录，用于存储主目录下 README 所用图片 端茶倒水

分支管理

  • main：代码较稳定版本或阶段性成果，需要 2 reviewers，但由总负责人（端茶倒水）维护
  • dev：各开发者开发工作的最新进展，需要 1 reviewer

开发规则

关于社区开发者

开发流程

THUAI7 开发组成员与其他贡献者应当遵循以下流程：

  1. 将 eesast/THUAI7 fork 到自己的仓库中
  2. 基于 dev 分支建立一个新的功能分支
  3. 在新的分支上进行修改与开发
  4. 向 eesast/THUAI7 的 dev 分支提出 pull request
  5. 等待其他开发组成员 review 与 merge

使用 Git 与 Github 时的注意事项

  • 非必要请勿上传大文件到 Github

  • commit 提交信息请遵循 Semantic Commit 规范，即：type: content 格式；推荐使用 VS Code 提供的 Conventional Commits 插件进行格式化提交。

    常用的 commit message type 包括：

    Type Explanation
    chore 日常代码开发；改变构建流程；增加依赖库、工具等
    fix 修复bug
    refactor 改变代码结构，但没有增加新功能
    docs 修改文档，如 README、CONTRIBUTE 等
    revert 版本回退
    ... ...

  • 鼓励开发组成员之间互相 review 并 merge 代码到 dev 分支上。merge 前建议简单检查其 pull request 是否符合上述规范

  • 一般情况下，不要向 main 分支提出 pull request，更不要 merge 到 main 分支上

  • 一般情况下，不允许 merge 无法通过 CI 的 pull request

开发约定

  • 统一使用空格缩进而非制表符缩进
  • 统一使用 4 个空格进行缩进而非 2 个
  • 统一使用 UTF-8 字符编码

代码风格

本仓库严格规定了 C++ 与 CSharp 代码风格，具体配置请参见 .clang-format

风格说明

几项重要规定如下：

  • 需严格按照要求缩进

    namespace Exp
{
    public class Program
    {
        public static void Main()
        {            
        }
    }
}

  • if、while等关键字后须加空格

    while (1)
{
    // code
}

  • 大括号须换行书写

    // Allowed
if (...)
{
   // ... 
}

// Forbidden !!!
if (...) {
    // ...
}

规范代码风格

文档风格

仓库的文档使用 Markdown 语法，具体语法可以参照 Markdown 语法文档。

中文文档的书写须严格遵循：中文技术文档规范、中文文案排版指北，以写出更美观的中文文档。例如：中文文字与西文文字间空格、全角标点符号的正确使用，等等。

西文文档的书写须遵循：

  • 在 中文技术文档规范 和 中文文案排版指北 中规定的数字和西文的规范
  • 半角空格的标点符号的使用：
    • 半角的逗号 ,、分号 ;、句号 .、叹号 !、问号 ? 等标点，在不位于行尾时，后需加空格，除非其后紧跟全角标点符号。例如："Hello, world"，是一句学习编程语言常用的句子
    • 半角的括号 ()、[]、{}、<> 等在左半括号前加空格、右半括号后加空格，除非其空格处紧跟全角标点符号或位于行首或行尾。例如：Tsinghua University (THU) and Peking University (PKU)（我是全角括号）

其他注意事项

  • 文件的字符编码格式须统一使用 UTF-8 编码，并用 4 空格缩进，尤其是 C/C++：Visual Studio 创建 cpp 文件时默认使用 GB2312 编码、TAB 缩进，因此每创建一个文件都需要注意手动设置字符编码（当代码文件中出现中文时）和缩进方式

  • 使用等宽字体进行编程，例如 Source Code Pro、Consolas 等，便于对齐

  • 注意代码的整洁性与可读性

    • 代码风格尽量统一。书写不要过于紧凑，善于使用空格、缩进与换行来让代码看起来更整洁

    • 命名风格尽量统一。相同类别的命名规则要相同，例如类名统一使用大驼峰命名法或其他常用的命名法，但是不要混用（非必要不使用匈牙利命名法）

    • 命名应当通俗易懂，让阅读代码者能够通过命名理解变量、函数等的意义。除循环变量等可以使用 i、j、k 等单字母外，其他的命名应当明白如话，且谨慎使用缩写。尽量使用众人皆知的缩写，不要自创缩写。如果连自己都不知道的缩写或根本没有众人皆知的缩写，则应当坚持使用全称，命名可以适当加长。

      常用的缩写有：

      address-addr、answer-ans、application-app、arguments-args、array-arr、assemble-asm、(a)synchronize-(a)sync、attribute-attr、begin-beg、bitmap-bmp、buffer-buf、button-btn、clock-clk、command-cmd、coordinates-coord、copy-cpy、count-cnt、current-cur、database-db、decrease-dec、default/define-def、delete-del、dependency-dep、destination-dest、device-dev、dialog-dlg、dictionary-dict、display-disp、divide-div、document-doc、educate-edu、equal-eq、error-err、extend-ext、format-fmt、frequency-freq、function-func、horizon-horz、image-img、implement-impl、increment-inc、index-idx、information-info、initialize-init、instance-inst、iterator-itr、length-len、list-lst、memory-mem、message-msg、middle-mid、number-num、object-obj、package-pkg、parameter-param、password-pwd、pointer-ptr、position-pos、previous-prev、receive-recv、reference-ref、resource/result-res、return-ret、second-sec、select-sel、semaphore-sem、signal-sig、source-src、stack-stk、standard-std、statistic/state-stat、string-str、system-sys、temporary-temp/tmp、text-txt、user-usr、value-val、variable-var、version-ver、vertical-vert、window-win

  • 命名允许较长，但不应过于啰嗦冗余，能完整表明意图即可。

  • 代码应保证良好的可读性；禁止中学 OI 竞赛的各种“卡常”奇技淫巧！！！效率并非总是最重要的，良好的可读性与可维护性往往更加重要。

  • 熟练运用面向对象编程的思想，设计架构时尽可能降低模块与模块的耦合性，保证代码的可维护性

    • 慎用全局变量、全局函数等
    • 尽可能将各功能模块化，便于日后复用；尽可能降低类与类的耦合，善用继承与多态
    • 适当设计单元测试，保证代码的正确运行

  • 注意跨平台问题，代码需保证同时支持 Windows 与 Linux，避免直接的系统调用带来的跨平台问题

  • 注意维护开发文档，便于后来者快速了解本仓库代码结构

  • 小组内合理分工，避免个人任务量过重或过轻

  • 做好部会记录，及时完成工作任务，避免拖延到ddl

  • 各组间多交流，相互了解各自的开发进度，加强协作，遇到困难互相帮助。

  • 加油，奥里给

开发组成员

  • 逻辑组：潘徐成、顾朗哲、顾又嘉
  • 通信组：肖钦帆、郭雯齐
  • 界面组：陈宇瀚、韩志峰
  • 运维组：张琨、叶芊屿
  • 端茶倒水：李羿璇