1. 项目概述从零构建一个控制台版三国杀最近在整理硬盘翻出来一个大学时期写的C控制台版三国杀游戏项目。这个项目当时花了我不少心思从卡牌逻辑、角色技能到回合流程都力求还原桌游的核心体验并且特意考虑了跨平台编译确保在Windows、Linux和macOS上都能顺利运行。今天把它整理出来连同完整的设计文档和源码一起分享给大家。这个项目非常适合两类朋友一类是正在学习C想找一个综合性、有挑战性的练手项目来巩固面向对象、数据结构、多线程等知识点的同学另一类是对游戏逻辑设计感兴趣想了解一个复杂桌游如何被拆解成代码实现的开发者。通过这个项目你可以看到一个完整的游戏是如何从设计图一步步变成可执行程序的其中涉及的架构设计、状态管理和异常处理都是非常宝贵的实战经验。整个项目完全基于标准C和控制台输入输出不依赖任何图形库这意味着你可以把注意力完全集中在游戏的核心逻辑和代码架构上。我会带你从项目结构开始一步步拆解武将技能实现、卡牌系统、游戏循环等关键模块并分享我在跨平台编译和调试过程中踩过的那些坑。2. 项目整体架构与设计思路拆解2.1 核心设计目标与约束条件在动手写第一行代码之前明确设计目标至关重要。对于这个控制台版三国杀我设定了几个核心原则第一逻辑完整性优先于表现力。既然选择了控制台就意味着放弃了华丽的UI和动画。因此所有设计必须确保游戏的核心规则——包括卡牌效果、技能触发、回合阶段、胜负判定——被100%精确实现。玩家的体验来自于策略博弈而非视觉冲击。第二高内聚、低耦合的模块化设计。三国杀是一个状态极其复杂的游戏一个“南蛮入侵”可能触发多个武将的技能改变多个玩家的手牌和血量。如果所有代码都揉在一起后期调试将是噩梦。因此必须将游戏拆分为独立的、职责清晰的模块比如Game游戏主循环、Player玩家、Card卡牌、Skill技能等。第三为跨平台而生。从第一天起代码就要考虑在Windows的cmd/PowerShell、Linux/macOS的终端下运行。这意味着要避免使用平台特有的API如Windows的conio.h用于键盘监听所有I/O操作都使用C标准库并通过预编译指令#ifdef _WIN32来处理诸如清屏这样的平台差异操作。基于这些目标我采用了经典的模型-视图-控制器MVC架构的变体。在这个项目中模型Model 是游戏的核心数据与逻辑包括Player、Card、GameState等类。它们不关心如何显示只负责维护状态和执行业务规则。控制器Controller 主要是Game类它接收来自“视图”的输入用户选择调用“模型”的方法来更新状态并决定下一步该做什么。视图View 这里就是控制台本身。一系列独立的渲染函数如renderBattlefield、renderPlayerInfo负责将“模型”的当前状态以文本和简单字符画的形式打印到屏幕上。这种分离使得我们未来如果想移植到其他界面比如简单的图形库只需要重写“视图”部分核心游戏逻辑几乎不用改动。2.2 关键数据结构与类的设计整个项目的骨架由几个核心类构成它们之间的关系决定了代码的清晰度。1. Card卡牌类这是所有卡牌的基类。三国杀的卡牌种类基本牌、锦囊牌、装备牌虽然效果各异但都有一些共同属性名称、花色、点数、使用距离、效果描述。我设计了一个Card基类然后派生出BasicCard杀、闪、桃、TrickCard锦囊、EquipmentCard装备等子类。class Card { public: enum class Suit { SPADE, HEART, CLUB, DIAMOND }; // 花色 enum class Type { BASIC, TRICK, EQUIPMENT }; // 类型 Card(std::string name, Suit suit, int number, Type type); virtual ~Card() default; // 关键使用卡牌的抽象方法。由子类实现具体效果。 virtual bool use(Game* game, Player* source, Player* target) 0; // 获取卡牌描述用于显示 virtual std::string getDescription() const; // 获取器 std::string getName() const { return name_; } Suit getSuit() const { return suit_; } // ... 其他属性 protected: std::string name_; Suit suit_; int number_; // 点数 Type type_; };2. Player玩家类玩家类不仅存储血量、手牌、装备区、判定区这些状态更重要的是它要管理武将技能。我采用了组件模式的思想。每个武将技能被设计成一个独立的Skill类。Player对象内部有一个std::vectorstd::unique_ptrSkill用来存放该武将拥有的所有技能。class Player { public: Player(std::string name, int max_hp); void addSkill(std::unique_ptrSkill skill); // 关键在游戏事件发生时询问所有技能是否触发 void onPhaseEvent(PhaseEvent event, Game* game); void onCardEvent(CardEvent event, Game* game, Card* card); // 区域管理 void drawCard(Card* card); bool playCard(int handIndex, Game* game, Player* target nullptr); const std::vectorCard* getHandCards() const { return handCards_; } private: std::string name_; int hp_; int maxHp_; std::vectorCard* handCards_; // 手牌区 std::vectorstd::unique_ptrSkill skills_; // 技能列表 // ... 装备区、判定区 };3. Game游戏引擎类这是最核心的控制器。它持有当前游戏的所有状态玩家列表、牌堆、弃牌堆、当前回合玩家、当前游戏阶段准备、判定、摸牌、出牌、弃牌、结束等。它驱动着整个游戏循环并作为事件总线将“某玩家使用了一张杀”、“进入判定阶段”这样的事件广播给所有相关的Player和Skill对象。class Game { public: enum class Phase { PREPARE, JUDGE, DRAW, PLAY, DISCARD, END }; void initializeGame(const std::vectorstd::string playerNames); void run(); // 主游戏循环 // 事件触发接口 void triggerPhaseEvent(PhaseEvent event); void triggerCardEvent(CardEvent event, Player* source, Card* card, Player* target nullptr); // 状态查询与操作 Player* getCurrentPlayer() const { return players_[currentPlayerIndex_]; } Phase getCurrentPhase() const { return currentPhase_; } Card* drawFromDeck(); // 从牌堆摸牌 void discard(Card* card); // 弃牌 private: std::vectorstd::unique_ptrPlayer players_; std::vectorstd::unique_ptrCard deck_; // 牌堆 std::vectorCard* discardPile_; // 弃牌堆 int currentPlayerIndex_; Phase currentPhase_; bool gameOver_; // ... 其他状态 };注意这里有一个关键设计点——事件驱动。与其让Game类硬编码所有技能触发条件不如定义一套事件枚举如PhaseEvent::DRAW_START,CardEvent::BEFORE_USE。当游戏进行到某个阶段或某张牌被使用时Game就广播对应事件。每个Skill对象监听自己关心的事件并在被触发时执行自己的逻辑。这极大地降低了模块间的耦合新增技能就像插拔组件一样简单。3. 核心模块实现细节与难点解析3.1 卡牌系统的实现与效果结算链卡牌尤其是锦囊牌是三国杀逻辑复杂度的主要来源。一张“过河拆桥”的使用可能被“无懈可击”响应而“无懈可击”本身也可能被另一张“无懈可击”抵消。这形成了一个效果结算链。我的实现方案是引入一个ResolutionStack结算栈的概念。当一张牌被使用时并不立即生效而是将其包装成一个Resolution结算项对象压入Game持有的一个全局栈中。struct Resolution { Card* card; // 待结算的牌 Player* source; // 使用者 Player* target; // 目标可能为空 std::functionvoid() effect; // 卡牌真正生效的函数 };例如玩家A对玩家B使用“过河拆桥”Game::playCard被调用创建Resolution对象其effect是一个让B弃牌的lambda函数。将该Resolution压入结算栈。Game广播CardEvent::BEFORE_RESOLVE事件。其他玩家比如C可以在这个时机通过打出“无懈可击”来响应。如果C打出则创建一个新的Resolution效果是抵消前一个并压栈。此时栈顶是“无懈可击”。Game开始从栈顶依次结算。先结算“无懈可击”其效果是将栈中下一个“过河拆桥”标记为“被抵消”。接着结算“过河拆桥”检查到自己被抵消则什么都不做结算结束。这个过程完美模拟了实体卡牌游戏中“询问是否响应”的环节。所有锦囊牌AOE、单体、延时和部分技能都可以通过这个机制进行结算。实操心得结算栈的实现要特别注意对象的生命周期管理。结算项中存储的可能是Card*指针要确保在结算过程中对应的Card对象不会被意外销毁比如因为被弃置而删除。我的做法是所有卡牌对象都由Game中的deck_unique_ptr容器统一管理手牌、装备区、判定区都只存储指针。只有当卡牌进入弃牌堆且确定不再需要时才将其移回牌堆重用或标记而不是删除。这避免了悬空指针的问题。3.2 武将技能系统的动态挂载与事件监听技能系统的灵活性是这个项目的亮点。我希望做到定义一个Skill子类然后在创建Player时挂载上去这个技能就能在正确的时机自动生效。首先定义技能基类和事件类型// 游戏阶段事件枚举 enum class PhaseEvent { TURN_START, // 回合开始 DRAW_START, DRAW_END, // 摸牌阶段 PLAY_START, PLAY_END, // 出牌阶段 // ... 其他阶段 }; // 卡牌相关事件枚举 enum class CardEvent { BEFORE_USE, // 使用牌前 AFTER_USE, // 使用牌后 BEFORE_TARGET, // 指定目标前 // ... 其他时机 }; class Skill { public: Skill(const std::string name) : name_(name) {} virtual ~Skill() default; // 技能响应阶段事件 virtual void onPhase(PhaseEvent event, Game* game, Player* owner) {} // 技能响应卡牌事件 virtual void onCard(CardEvent event, Game* game, Player* owner, Card* card, Player* target nullptr) {} // 主动技能提供是否可发动的查询 virtual bool isActivatable(const Game* game, const Player* owner) const { return false; } virtual void activate(Game* game, Player* owner) {} std::string getName() const { return name_; } private: std::string name_; };然后以实现“关羽”的“武圣”技能为例可将任意红色牌当【杀】使用class WushengSkill : public Skill { public: WushengSkill() : Skill(武圣) {} // 在玩家使用牌前触发 void onCard(CardEvent event, Game* game, Player* owner, Card* card, Player* target) override { if (event CardEvent::BEFORE_USE) { // 如果玩家试图使用的牌是红色牌且目标合法则将其视为【杀】 if (card-getSuit() Card::Suit::HEART || card-getSuit() Card::Suit::DIAMOND) { // 这里可以修改card的临时类型或者创建一个虚拟的【杀】卡牌对象替换 // 为了简化我们假设Game类提供了一个接口来转换卡牌类型 game-convertCardToKill(card, owner); } } } };在Player类中需要在其生命周期关键点调用技能的监听函数void Player::onCardEvent(CardEvent event, Game* game, Card* card, Player* target) { for (auto skill : skills_) { skill-onCard(event, game, this, card, target); } }最后在Game类中当有卡牌事件发生时通知相关玩家void Game::triggerCardEvent(CardEvent event, Player* source, Card* card, Player* target) { // 通知事件发起者 source-onCardEvent(event, this, card, target); // 如果事件有目标也通知目标例如成为【杀】的目标 if (target) { target-onCardEvent(event, this, card, source); // 注意source和target互换 } // 某些事件可能需要通知所有玩家如AOE锦囊 // ... }这样一个完整的技能事件监听与响应机制就建立起来了。新增一个技能只需要继承Skill类重写对应的事件处理方法并在创建武将时addSkill即可。系统的扩展性非常好。3.3 控制台交互与状态渲染在没有图形界面的情况下如何让玩家清晰了解战场局势是关键。我的方案是将屏幕划分为几个固定的信息区域并定时刷新。1. 区域划分顶部区域显示当前回合玩家、当前阶段、剩余牌堆数量等全局信息。中部左侧以列表形式显示所有玩家包括其体力、手牌数、装备、判定区状态。当前玩家高亮显示。中部右侧显示当前玩家的详细手牌列表每张牌的名称和花色。底部区域这是一个命令行交互区用于显示操作提示、询问选择目标、展示技能发动询问等。2. 刷新策略为了避免控制台闪烁我采用了“局部刷新”和“双缓冲”的思想。并不是每次有变化都清空整个屏幕重画。对于变化频繁的区域如当前玩家手牌我会先记录上一次渲染的内容只重绘发生变化的部分。对于相对静态的区域如玩家列表标题则无需频繁重绘。在Windows上可以使用system(“cls”)清屏在Unix-like系统上则使用printf(“\033[2J\033[1;1H”)这样的ANSI转义序列。为了统一我通过预编译指令来区分void clearConsole() { #ifdef _WIN32 system(cls); #else // Assume POSIX std::cout \033[2J\033[1;1H; #endif }3. 输入处理所有玩家输入都通过标准输入std::cin获取。难点在于处理非阻塞输入和超时。例如当一张“闪电”需要判定时需要给当前玩家一个短暂的响应时间比如打出“无懈可击”如果超时则自动进行判定。 一个简单的实现方式是使用平台相关函数如Windows的_kbhit() Linux的select()或poll()来检查输入缓冲区。但在跨平台项目中我选择了一个更简单的策略对于需要即时响应的场景设置一个循环在有限时间内不断检查输入对于常规出牌则使用阻塞式输入等待玩家明确操作。虽然体验上略有折扣但保证了代码的简洁和可移植性。// 一个简单的、带超时提示的输入获取函数伪代码 std::string getInputWithTimeout(int timeoutSeconds, const std::string prompt) { std::cout prompt (超时 timeoutSeconds 秒): ; auto start std::chrono::steady_clock::now(); std::string input; while (std::chrono::steady_clock::now() - start std::chrono::seconds(timeoutSeconds)) { if (/* 检查标准输入是否有数据平台相关代码 */) { std::getline(std::cin, input); return input; } std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 避免CPU空转 } std::cout \n时间到自动跳过。\n; return ; // 返回空字符串表示超时 }4. 跨平台编译支持与构建系统让同一份C代码在Windows、Linux和macOS上都能顺利编译运行是项目一开始就定下的目标。这主要涉及两个方面构建工具的选择和平台相关代码的处理。4.1 使用CMake管理跨平台构建我选择了CMake作为构建系统生成器。CMake可以生成各种IDE的工程文件如Visual Studio的.sln或本地构建系统文件如Unix的Makefile是跨平台C项目的首选。项目的CMakeLists.txt核心部分如下cmake_minimum_required(VERSION 3.10) project(SanguoshaConsole VERSION 1.0.0 LANGUAGES CXX) # 设置C标准为C17并开启常用警告 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) if(MSVC) add_compile_options(/W4 /permissive-) # MSVC编译器选项 else() add_compile_options(-Wall -Wextra -pedantic) # GCC/Clang编译器选项 endif() # 定义可执行文件目标 add_executable(sanguosha_main src/main.cpp src/game.cpp src/player.cpp src/card.cpp src/skill.cpp # ... 列出所有源文件 ) # 如果有第三方库在这里用 find_package 或 target_link_libraries 链接 # target_link_libraries(sanguosha_main SomeLibrary)编译流程Windows (使用Visual Studio或MinGW):# 在项目根目录 mkdir build cd build cmake .. -G Visual Studio 16 2019 # 生成VS工程 # 然后用VS打开 sanguosha.sln 编译 # 或者使用MinGW cmake .. -G MinGW Makefiles mingw32-make # 或 makeLinux/macOS:mkdir build cd build cmake .. # 默认生成Makefile make -j4 # 使用4个线程并行编译4.2 处理平台相关的代码差异尽管我们尽量使用标准C但有些地方无法避免平台差异主要是终端控制和路径分隔符。1. 清屏与颜色输出如前所述清屏命令不同。对于颜色输出Windows原生控制台API和Unix的ANSI转义序列也不同。我实现了一个简单的ConsoleHelper类来封装这些操作// console_helper.h #pragma once #include string class ConsoleHelper { public: static void clearScreen(); static void setColor(const std::string colorCode); // 参数为“red, green等 static void resetColor(); }; // console_helper.cpp (部分) #ifdef _WIN32 #include windows.h void ConsoleHelper::clearScreen() { system(cls); } void ConsoleHelper::setColor(const std::string color) { HANDLE hConsole GetStdHandle(STD_OUTPUT_HANDLE); int winColor 7; // 默认白色 if (color red) winColor 12; else if (color green) winColor 10; // ... 其他颜色映射 SetConsoleTextAttribute(hConsole, winColor); } #else #include unistd.h void ConsoleHelper::clearScreen() { write(STDOUT_FILENO, \033[2J\033[1;1H, 11); } void ConsoleHelper::setColor(const std::string color) { std::string ansiCode; if (color red) ansiCode \033[31m; else if (color green) ansiCode \033[32m; // ... std::cout ansiCode; } #endif2. 文件路径在读取卡牌数据、武将配置等资源文件时路径分隔符在Windows上是反斜杠\在Unix上是正斜杠/。一个良好的实践是在代码内部统一使用正斜杠/。C标准库和大多数第三方库都能正确处理。使用CMake的configure_file命令在编译时根据平台生成正确的配置文件路径。或者将资源文件放在可执行文件同级目录的data/文件夹下使用相对路径访问。// 在代码中这样写是安全的 std::string cardDataPath data/cards.json; std::ifstream file(cardDataPath); // 跨平台注意事项跨平台编译最大的坑往往在于编译器对C标准的支持程度和第三方库的依赖。本项目刻意避免了第三方库以保持纯净。如果你需要添加网络或图形库务必选择跨平台的库如SFML、SDL2、Boost.Asio并在CMakeLists.txt中妥善处理查找和链接逻辑。同时确保你的开发环境尤其是Windows下的MinGW或MSYS2工具链完整避免出现“找不到threads”之类的链接错误。5. 设计文档的编写与维护一个完整的项目离不开文档。对于这个三国杀项目我主要维护了三类文档它们对于理解代码和后续扩展至关重要。1. 架构设计文档 (ARCHITECTURE.md):这份文档面向潜在的代码贡献者或高级用户。它解释了项目的整体架构MVC、核心类的职责、关键数据流如结算栈、事件系统以及重要的设计决策比如为什么选择事件驱动而不是硬编码。它相当于项目的“地图”。2. 模块接口说明文档 (代码注释 MODULES.md):这是最重要的部分。我采用了Doxygen风格的注释为所有公开的类、方法和重要的成员变量编写详细的注释。例如/** * class Game * brief 游戏核心引擎负责驱动游戏循环、管理状态和事件分发。 * * 该类持有游戏的所有全局状态包括玩家列表、牌堆、当前回合等。 * 它是MVC模式中的控制器Controller。 */ class Game { public: /** * brief 初始化游戏创建指定数量的玩家并分配武将。 * param playerNames 玩家名称列表 * throws std::invalid_argument 如果玩家数量不在2-8之间 */ void initializeGame(const std::vectorstd::string playerNames); // ... };同时一个单独的MODULES.md文件用更自然的方式概述每个模块如card/,player/,skill/的功能和包含的主要类。3. 卡牌与技能数据定义文档 (data/README.md或 JSON Schema):卡牌和武将的技能效果是可能变化的。我将它们设计为可配置的数据。例如使用JSON文件来定义卡牌// cards.json [ { id: slash, name: 杀, suit: spade, number: 7, type: basic, description: 对一名其他角色使用若其未打出【闪】则受到1点伤害。 }, { id: dodge, name: 闪, suit: heart, number: 2, type: basic, description: 用于响应【杀】或某些锦囊牌。 } ]对应的需要一个文档来说明这个JSON文件的格式Schema以及程序是如何加载和解析这些数据来创建卡牌对象的。这样想要添加新卡牌或修改数值平衡的人无需修改C代码只需编辑JSON文件即可。维护这些文档起初会花费一些时间但当项目规模增长或者你需要回顾几个月前的代码时它们会为你节省数十倍的时间。这也是一个优秀项目与一个“玩具代码”的重要区别。6. 常见问题排查与调试技巧实录在开发这个项目的过程中我遇到了不少典型的C游戏逻辑bug和跨平台问题。这里记录下最有代表性的几个及其解决方法。6.1 内存管理问题悬浮指针与对象生命周期问题现象游戏运行一段时间后随机崩溃或在某些特定操作如多次使用“五谷丰登”后程序访问了非法内存。排查过程使用ValgrindLinux/macOS或Visual Studio的诊断工具Windows进行内存检查发现大量“invalid read”和“use after free”错误。追踪发现问题出在卡牌对象的传递上。例如一张牌从牌堆被摸起放入玩家A的手牌区存储的是Card*然后A打出这张牌牌进入结算流程结算后放入弃牌堆。此时如果手牌区仍然持有这个指针就变成了悬浮指针。解决方案统一所有权规定所有Card对象的生命周期由Game类中的std::vectorstd::unique_ptrCard deck_唯一管理。这个容器在游戏初始化时创建所有卡牌。使用引用而非裸指针在其他地方如手牌区、装备区只存储指向deck_中对象的指针或引用这里用指针更合适因为需要支持nullptr。当卡牌需要被“销毁”如进入弃牌堆时并不是真的删除对象而是将其移动到一个“废弃区”或简单地标记状态等待牌堆重洗时复用。使用智能指针需谨慎可以考虑使用std::shared_ptrCard但要注意循环引用问题。在这个项目中由于Game明确拥有所有卡牌使用unique_ptr加原始指针观察是更清晰的选择。class Game { private: std::vectorstd::unique_ptrCard masterDeck_; // 所有卡牌的唯一所有者 std::vectorCard* drawPile_; // 牌堆持有指针 std::vectorCard* discardPile_; // 弃牌堆持有指针 // 洗牌时将discardPile_的指针移回drawPile_不涉及对象创建销毁。 };6.2 多态与容器导致的切片问题问题现象将WushengSkill对象放入std::vectorSkill中后调用其onCard方法并没有执行子类重写的版本。原因分析这是经典的对象切片问题。std::vectorSkill存储的是Skill对象当插入WushengSkill时会发生拷贝构造但只拷贝了Skill基类部分子类特有的部分被“切掉”了。解决方案存储指向多态基类的指针或智能指针。// 错误对象切片 std::vectorSkill skills; skills.push_back(WushengSkill()); // 切片发生 // 正确存储指针 std::vectorstd::unique_ptrSkill skills; skills.push_back(std::make_uniqueWushengSkill()); // 多态行为得以保留在项目中Player类的skills_成员正是采用了std::vectorstd::unique_ptrSkill。6.3 控制台乱码问题问题现象在Windows中文终端下输出的中文变成乱码或者在Linux下编译时提示“无法将UTF-8字符串转换为窄字符”。解决方案源码文件编码确保所有源代码文件.cpp, .h均以UTF-8 with BOM(Windows) 或UTF-8(Unix) 编码保存。这是现代C项目的推荐做法。执行环境编码在main函数开头设置全局locale或直接操作控制台代码页。#include locale #include codecvt // C17前可用C17后需注意其被弃用 int main() { #ifdef _WIN32 // Windows下设置控制台输出代码页为UTF-8 SetConsoleOutputCP(CP_UTF8); SetConsoleCP(CP_UTF8); #else // Linux/macOS下终端通常默认UTF-8可以设置locale std::locale::global(std::locale(en_US.UTF-8)); std::wcout.imbue(std::locale()); #endif std::cout 三国杀游戏开始 std::endl; // 现在可以正常显示中文了 // ... }字符串字面量在C11及以上可以使用u8前缀来确保字符串字面量是UTF-8编码std::string str u8中文;。但要注意std::cout输出时需要终端支持UTF-8。6.4 游戏逻辑死锁或状态异常问题现象游戏在某些特定操作组合后卡住无法继续或者玩家的状态如手牌数、血量显示不正确。调试技巧添加详细的日志在关键函数入口、状态变更处添加日志输出。例如在Game::triggerCardEvent和每个Skill::onCard方法开始时打印事件和参与者信息。这能帮你清晰地看到事件传播的链条。void Game::triggerCardEvent(CardEvent event, Player* source, Card* card, Player* target) { log(触发卡牌事件: getEventName(event) , 来源: source-getName() , 卡牌: card-getName()); // ... 后续逻辑 }设计状态检查函数编写一个Game::validateState()函数在每回合结束时或怀疑出错时调用。这个函数检查一些不变量是否被破坏例如所有玩家手牌数是否非负、牌堆和弃牌堆总牌数是否恒定、是否有玩家血量超过上限等。一旦发现异常立即打印详细错误信息并中断便于定位问题。单元测试对于最核心、最复杂的模块如结算栈ResolutionStack、技能WushengSkill编写单元测试。使用像Google Test这样的框架可以确保在修改代码后核心逻辑的正确性不被破坏。例如测试“过河拆桥被无懈可击抵消”这个场景是否按预期工作。开发这样一个规模的项目调试和测试所花费的时间往往远超最初的编码。养成边写边测、添加断言和日志的习惯能极大提升开发效率和代码质量。当游戏能稳定运行一局完整的8人局而不出现任何逻辑或崩溃问题时那种成就感是无与伦比的。
C++控制台三国杀：从零实现游戏逻辑与跨平台架构设计
1. 项目概述从零构建一个控制台版三国杀最近在整理硬盘翻出来一个大学时期写的C控制台版三国杀游戏项目。这个项目当时花了我不少心思从卡牌逻辑、角色技能到回合流程都力求还原桌游的核心体验并且特意考虑了跨平台编译确保在Windows、Linux和macOS上都能顺利运行。今天把它整理出来连同完整的设计文档和源码一起分享给大家。这个项目非常适合两类朋友一类是正在学习C想找一个综合性、有挑战性的练手项目来巩固面向对象、数据结构、多线程等知识点的同学另一类是对游戏逻辑设计感兴趣想了解一个复杂桌游如何被拆解成代码实现的开发者。通过这个项目你可以看到一个完整的游戏是如何从设计图一步步变成可执行程序的其中涉及的架构设计、状态管理和异常处理都是非常宝贵的实战经验。整个项目完全基于标准C和控制台输入输出不依赖任何图形库这意味着你可以把注意力完全集中在游戏的核心逻辑和代码架构上。我会带你从项目结构开始一步步拆解武将技能实现、卡牌系统、游戏循环等关键模块并分享我在跨平台编译和调试过程中踩过的那些坑。2. 项目整体架构与设计思路拆解2.1 核心设计目标与约束条件在动手写第一行代码之前明确设计目标至关重要。对于这个控制台版三国杀我设定了几个核心原则第一逻辑完整性优先于表现力。既然选择了控制台就意味着放弃了华丽的UI和动画。因此所有设计必须确保游戏的核心规则——包括卡牌效果、技能触发、回合阶段、胜负判定——被100%精确实现。玩家的体验来自于策略博弈而非视觉冲击。第二高内聚、低耦合的模块化设计。三国杀是一个状态极其复杂的游戏一个“南蛮入侵”可能触发多个武将的技能改变多个玩家的手牌和血量。如果所有代码都揉在一起后期调试将是噩梦。因此必须将游戏拆分为独立的、职责清晰的模块比如Game游戏主循环、Player玩家、Card卡牌、Skill技能等。第三为跨平台而生。从第一天起代码就要考虑在Windows的cmd/PowerShell、Linux/macOS的终端下运行。这意味着要避免使用平台特有的API如Windows的conio.h用于键盘监听所有I/O操作都使用C标准库并通过预编译指令#ifdef _WIN32来处理诸如清屏这样的平台差异操作。基于这些目标我采用了经典的模型-视图-控制器MVC架构的变体。在这个项目中模型Model 是游戏的核心数据与逻辑包括Player、Card、GameState等类。它们不关心如何显示只负责维护状态和执行业务规则。控制器Controller 主要是Game类它接收来自“视图”的输入用户选择调用“模型”的方法来更新状态并决定下一步该做什么。视图View 这里就是控制台本身。一系列独立的渲染函数如renderBattlefield、renderPlayerInfo负责将“模型”的当前状态以文本和简单字符画的形式打印到屏幕上。这种分离使得我们未来如果想移植到其他界面比如简单的图形库只需要重写“视图”部分核心游戏逻辑几乎不用改动。2.2 关键数据结构与类的设计整个项目的骨架由几个核心类构成它们之间的关系决定了代码的清晰度。1. Card卡牌类这是所有卡牌的基类。三国杀的卡牌种类基本牌、锦囊牌、装备牌虽然效果各异但都有一些共同属性名称、花色、点数、使用距离、效果描述。我设计了一个Card基类然后派生出BasicCard杀、闪、桃、TrickCard锦囊、EquipmentCard装备等子类。class Card { public: enum class Suit { SPADE, HEART, CLUB, DIAMOND }; // 花色 enum class Type { BASIC, TRICK, EQUIPMENT }; // 类型 Card(std::string name, Suit suit, int number, Type type); virtual ~Card() default; // 关键使用卡牌的抽象方法。由子类实现具体效果。 virtual bool use(Game* game, Player* source, Player* target) 0; // 获取卡牌描述用于显示 virtual std::string getDescription() const; // 获取器 std::string getName() const { return name_; } Suit getSuit() const { return suit_; } // ... 其他属性 protected: std::string name_; Suit suit_; int number_; // 点数 Type type_; };2. Player玩家类玩家类不仅存储血量、手牌、装备区、判定区这些状态更重要的是它要管理武将技能。我采用了组件模式的思想。每个武将技能被设计成一个独立的Skill类。Player对象内部有一个std::vectorstd::unique_ptrSkill用来存放该武将拥有的所有技能。class Player { public: Player(std::string name, int max_hp); void addSkill(std::unique_ptrSkill skill); // 关键在游戏事件发生时询问所有技能是否触发 void onPhaseEvent(PhaseEvent event, Game* game); void onCardEvent(CardEvent event, Game* game, Card* card); // 区域管理 void drawCard(Card* card); bool playCard(int handIndex, Game* game, Player* target nullptr); const std::vectorCard* getHandCards() const { return handCards_; } private: std::string name_; int hp_; int maxHp_; std::vectorCard* handCards_; // 手牌区 std::vectorstd::unique_ptrSkill skills_; // 技能列表 // ... 装备区、判定区 };3. Game游戏引擎类这是最核心的控制器。它持有当前游戏的所有状态玩家列表、牌堆、弃牌堆、当前回合玩家、当前游戏阶段准备、判定、摸牌、出牌、弃牌、结束等。它驱动着整个游戏循环并作为事件总线将“某玩家使用了一张杀”、“进入判定阶段”这样的事件广播给所有相关的Player和Skill对象。class Game { public: enum class Phase { PREPARE, JUDGE, DRAW, PLAY, DISCARD, END }; void initializeGame(const std::vectorstd::string playerNames); void run(); // 主游戏循环 // 事件触发接口 void triggerPhaseEvent(PhaseEvent event); void triggerCardEvent(CardEvent event, Player* source, Card* card, Player* target nullptr); // 状态查询与操作 Player* getCurrentPlayer() const { return players_[currentPlayerIndex_]; } Phase getCurrentPhase() const { return currentPhase_; } Card* drawFromDeck(); // 从牌堆摸牌 void discard(Card* card); // 弃牌 private: std::vectorstd::unique_ptrPlayer players_; std::vectorstd::unique_ptrCard deck_; // 牌堆 std::vectorCard* discardPile_; // 弃牌堆 int currentPlayerIndex_; Phase currentPhase_; bool gameOver_; // ... 其他状态 };注意这里有一个关键设计点——事件驱动。与其让Game类硬编码所有技能触发条件不如定义一套事件枚举如PhaseEvent::DRAW_START,CardEvent::BEFORE_USE。当游戏进行到某个阶段或某张牌被使用时Game就广播对应事件。每个Skill对象监听自己关心的事件并在被触发时执行自己的逻辑。这极大地降低了模块间的耦合新增技能就像插拔组件一样简单。3. 核心模块实现细节与难点解析3.1 卡牌系统的实现与效果结算链卡牌尤其是锦囊牌是三国杀逻辑复杂度的主要来源。一张“过河拆桥”的使用可能被“无懈可击”响应而“无懈可击”本身也可能被另一张“无懈可击”抵消。这形成了一个效果结算链。我的实现方案是引入一个ResolutionStack结算栈的概念。当一张牌被使用时并不立即生效而是将其包装成一个Resolution结算项对象压入Game持有的一个全局栈中。struct Resolution { Card* card; // 待结算的牌 Player* source; // 使用者 Player* target; // 目标可能为空 std::functionvoid() effect; // 卡牌真正生效的函数 };例如玩家A对玩家B使用“过河拆桥”Game::playCard被调用创建Resolution对象其effect是一个让B弃牌的lambda函数。将该Resolution压入结算栈。Game广播CardEvent::BEFORE_RESOLVE事件。其他玩家比如C可以在这个时机通过打出“无懈可击”来响应。如果C打出则创建一个新的Resolution效果是抵消前一个并压栈。此时栈顶是“无懈可击”。Game开始从栈顶依次结算。先结算“无懈可击”其效果是将栈中下一个“过河拆桥”标记为“被抵消”。接着结算“过河拆桥”检查到自己被抵消则什么都不做结算结束。这个过程完美模拟了实体卡牌游戏中“询问是否响应”的环节。所有锦囊牌AOE、单体、延时和部分技能都可以通过这个机制进行结算。实操心得结算栈的实现要特别注意对象的生命周期管理。结算项中存储的可能是Card*指针要确保在结算过程中对应的Card对象不会被意外销毁比如因为被弃置而删除。我的做法是所有卡牌对象都由Game中的deck_unique_ptr容器统一管理手牌、装备区、判定区都只存储指针。只有当卡牌进入弃牌堆且确定不再需要时才将其移回牌堆重用或标记而不是删除。这避免了悬空指针的问题。3.2 武将技能系统的动态挂载与事件监听技能系统的灵活性是这个项目的亮点。我希望做到定义一个Skill子类然后在创建Player时挂载上去这个技能就能在正确的时机自动生效。首先定义技能基类和事件类型// 游戏阶段事件枚举 enum class PhaseEvent { TURN_START, // 回合开始 DRAW_START, DRAW_END, // 摸牌阶段 PLAY_START, PLAY_END, // 出牌阶段 // ... 其他阶段 }; // 卡牌相关事件枚举 enum class CardEvent { BEFORE_USE, // 使用牌前 AFTER_USE, // 使用牌后 BEFORE_TARGET, // 指定目标前 // ... 其他时机 }; class Skill { public: Skill(const std::string name) : name_(name) {} virtual ~Skill() default; // 技能响应阶段事件 virtual void onPhase(PhaseEvent event, Game* game, Player* owner) {} // 技能响应卡牌事件 virtual void onCard(CardEvent event, Game* game, Player* owner, Card* card, Player* target nullptr) {} // 主动技能提供是否可发动的查询 virtual bool isActivatable(const Game* game, const Player* owner) const { return false; } virtual void activate(Game* game, Player* owner) {} std::string getName() const { return name_; } private: std::string name_; };然后以实现“关羽”的“武圣”技能为例可将任意红色牌当【杀】使用class WushengSkill : public Skill { public: WushengSkill() : Skill(武圣) {} // 在玩家使用牌前触发 void onCard(CardEvent event, Game* game, Player* owner, Card* card, Player* target) override { if (event CardEvent::BEFORE_USE) { // 如果玩家试图使用的牌是红色牌且目标合法则将其视为【杀】 if (card-getSuit() Card::Suit::HEART || card-getSuit() Card::Suit::DIAMOND) { // 这里可以修改card的临时类型或者创建一个虚拟的【杀】卡牌对象替换 // 为了简化我们假设Game类提供了一个接口来转换卡牌类型 game-convertCardToKill(card, owner); } } } };在Player类中需要在其生命周期关键点调用技能的监听函数void Player::onCardEvent(CardEvent event, Game* game, Card* card, Player* target) { for (auto skill : skills_) { skill-onCard(event, game, this, card, target); } }最后在Game类中当有卡牌事件发生时通知相关玩家void Game::triggerCardEvent(CardEvent event, Player* source, Card* card, Player* target) { // 通知事件发起者 source-onCardEvent(event, this, card, target); // 如果事件有目标也通知目标例如成为【杀】的目标 if (target) { target-onCardEvent(event, this, card, source); // 注意source和target互换 } // 某些事件可能需要通知所有玩家如AOE锦囊 // ... }这样一个完整的技能事件监听与响应机制就建立起来了。新增一个技能只需要继承Skill类重写对应的事件处理方法并在创建武将时addSkill即可。系统的扩展性非常好。3.3 控制台交互与状态渲染在没有图形界面的情况下如何让玩家清晰了解战场局势是关键。我的方案是将屏幕划分为几个固定的信息区域并定时刷新。1. 区域划分顶部区域显示当前回合玩家、当前阶段、剩余牌堆数量等全局信息。中部左侧以列表形式显示所有玩家包括其体力、手牌数、装备、判定区状态。当前玩家高亮显示。中部右侧显示当前玩家的详细手牌列表每张牌的名称和花色。底部区域这是一个命令行交互区用于显示操作提示、询问选择目标、展示技能发动询问等。2. 刷新策略为了避免控制台闪烁我采用了“局部刷新”和“双缓冲”的思想。并不是每次有变化都清空整个屏幕重画。对于变化频繁的区域如当前玩家手牌我会先记录上一次渲染的内容只重绘发生变化的部分。对于相对静态的区域如玩家列表标题则无需频繁重绘。在Windows上可以使用system(“cls”)清屏在Unix-like系统上则使用printf(“\033[2J\033[1;1H”)这样的ANSI转义序列。为了统一我通过预编译指令来区分void clearConsole() { #ifdef _WIN32 system(cls); #else // Assume POSIX std::cout \033[2J\033[1;1H; #endif }3. 输入处理所有玩家输入都通过标准输入std::cin获取。难点在于处理非阻塞输入和超时。例如当一张“闪电”需要判定时需要给当前玩家一个短暂的响应时间比如打出“无懈可击”如果超时则自动进行判定。 一个简单的实现方式是使用平台相关函数如Windows的_kbhit() Linux的select()或poll()来检查输入缓冲区。但在跨平台项目中我选择了一个更简单的策略对于需要即时响应的场景设置一个循环在有限时间内不断检查输入对于常规出牌则使用阻塞式输入等待玩家明确操作。虽然体验上略有折扣但保证了代码的简洁和可移植性。// 一个简单的、带超时提示的输入获取函数伪代码 std::string getInputWithTimeout(int timeoutSeconds, const std::string prompt) { std::cout prompt (超时 timeoutSeconds 秒): ; auto start std::chrono::steady_clock::now(); std::string input; while (std::chrono::steady_clock::now() - start std::chrono::seconds(timeoutSeconds)) { if (/* 检查标准输入是否有数据平台相关代码 */) { std::getline(std::cin, input); return input; } std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 避免CPU空转 } std::cout \n时间到自动跳过。\n; return ; // 返回空字符串表示超时 }4. 跨平台编译支持与构建系统让同一份C代码在Windows、Linux和macOS上都能顺利编译运行是项目一开始就定下的目标。这主要涉及两个方面构建工具的选择和平台相关代码的处理。4.1 使用CMake管理跨平台构建我选择了CMake作为构建系统生成器。CMake可以生成各种IDE的工程文件如Visual Studio的.sln或本地构建系统文件如Unix的Makefile是跨平台C项目的首选。项目的CMakeLists.txt核心部分如下cmake_minimum_required(VERSION 3.10) project(SanguoshaConsole VERSION 1.0.0 LANGUAGES CXX) # 设置C标准为C17并开启常用警告 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) if(MSVC) add_compile_options(/W4 /permissive-) # MSVC编译器选项 else() add_compile_options(-Wall -Wextra -pedantic) # GCC/Clang编译器选项 endif() # 定义可执行文件目标 add_executable(sanguosha_main src/main.cpp src/game.cpp src/player.cpp src/card.cpp src/skill.cpp # ... 列出所有源文件 ) # 如果有第三方库在这里用 find_package 或 target_link_libraries 链接 # target_link_libraries(sanguosha_main SomeLibrary)编译流程Windows (使用Visual Studio或MinGW):# 在项目根目录 mkdir build cd build cmake .. -G Visual Studio 16 2019 # 生成VS工程 # 然后用VS打开 sanguosha.sln 编译 # 或者使用MinGW cmake .. -G MinGW Makefiles mingw32-make # 或 makeLinux/macOS:mkdir build cd build cmake .. # 默认生成Makefile make -j4 # 使用4个线程并行编译4.2 处理平台相关的代码差异尽管我们尽量使用标准C但有些地方无法避免平台差异主要是终端控制和路径分隔符。1. 清屏与颜色输出如前所述清屏命令不同。对于颜色输出Windows原生控制台API和Unix的ANSI转义序列也不同。我实现了一个简单的ConsoleHelper类来封装这些操作// console_helper.h #pragma once #include string class ConsoleHelper { public: static void clearScreen(); static void setColor(const std::string colorCode); // 参数为“red, green等 static void resetColor(); }; // console_helper.cpp (部分) #ifdef _WIN32 #include windows.h void ConsoleHelper::clearScreen() { system(cls); } void ConsoleHelper::setColor(const std::string color) { HANDLE hConsole GetStdHandle(STD_OUTPUT_HANDLE); int winColor 7; // 默认白色 if (color red) winColor 12; else if (color green) winColor 10; // ... 其他颜色映射 SetConsoleTextAttribute(hConsole, winColor); } #else #include unistd.h void ConsoleHelper::clearScreen() { write(STDOUT_FILENO, \033[2J\033[1;1H, 11); } void ConsoleHelper::setColor(const std::string color) { std::string ansiCode; if (color red) ansiCode \033[31m; else if (color green) ansiCode \033[32m; // ... std::cout ansiCode; } #endif2. 文件路径在读取卡牌数据、武将配置等资源文件时路径分隔符在Windows上是反斜杠\在Unix上是正斜杠/。一个良好的实践是在代码内部统一使用正斜杠/。C标准库和大多数第三方库都能正确处理。使用CMake的configure_file命令在编译时根据平台生成正确的配置文件路径。或者将资源文件放在可执行文件同级目录的data/文件夹下使用相对路径访问。// 在代码中这样写是安全的 std::string cardDataPath data/cards.json; std::ifstream file(cardDataPath); // 跨平台注意事项跨平台编译最大的坑往往在于编译器对C标准的支持程度和第三方库的依赖。本项目刻意避免了第三方库以保持纯净。如果你需要添加网络或图形库务必选择跨平台的库如SFML、SDL2、Boost.Asio并在CMakeLists.txt中妥善处理查找和链接逻辑。同时确保你的开发环境尤其是Windows下的MinGW或MSYS2工具链完整避免出现“找不到threads”之类的链接错误。5. 设计文档的编写与维护一个完整的项目离不开文档。对于这个三国杀项目我主要维护了三类文档它们对于理解代码和后续扩展至关重要。1. 架构设计文档 (ARCHITECTURE.md):这份文档面向潜在的代码贡献者或高级用户。它解释了项目的整体架构MVC、核心类的职责、关键数据流如结算栈、事件系统以及重要的设计决策比如为什么选择事件驱动而不是硬编码。它相当于项目的“地图”。2. 模块接口说明文档 (代码注释 MODULES.md):这是最重要的部分。我采用了Doxygen风格的注释为所有公开的类、方法和重要的成员变量编写详细的注释。例如/** * class Game * brief 游戏核心引擎负责驱动游戏循环、管理状态和事件分发。 * * 该类持有游戏的所有全局状态包括玩家列表、牌堆、当前回合等。 * 它是MVC模式中的控制器Controller。 */ class Game { public: /** * brief 初始化游戏创建指定数量的玩家并分配武将。 * param playerNames 玩家名称列表 * throws std::invalid_argument 如果玩家数量不在2-8之间 */ void initializeGame(const std::vectorstd::string playerNames); // ... };同时一个单独的MODULES.md文件用更自然的方式概述每个模块如card/,player/,skill/的功能和包含的主要类。3. 卡牌与技能数据定义文档 (data/README.md或 JSON Schema):卡牌和武将的技能效果是可能变化的。我将它们设计为可配置的数据。例如使用JSON文件来定义卡牌// cards.json [ { id: slash, name: 杀, suit: spade, number: 7, type: basic, description: 对一名其他角色使用若其未打出【闪】则受到1点伤害。 }, { id: dodge, name: 闪, suit: heart, number: 2, type: basic, description: 用于响应【杀】或某些锦囊牌。 } ]对应的需要一个文档来说明这个JSON文件的格式Schema以及程序是如何加载和解析这些数据来创建卡牌对象的。这样想要添加新卡牌或修改数值平衡的人无需修改C代码只需编辑JSON文件即可。维护这些文档起初会花费一些时间但当项目规模增长或者你需要回顾几个月前的代码时它们会为你节省数十倍的时间。这也是一个优秀项目与一个“玩具代码”的重要区别。6. 常见问题排查与调试技巧实录在开发这个项目的过程中我遇到了不少典型的C游戏逻辑bug和跨平台问题。这里记录下最有代表性的几个及其解决方法。6.1 内存管理问题悬浮指针与对象生命周期问题现象游戏运行一段时间后随机崩溃或在某些特定操作如多次使用“五谷丰登”后程序访问了非法内存。排查过程使用ValgrindLinux/macOS或Visual Studio的诊断工具Windows进行内存检查发现大量“invalid read”和“use after free”错误。追踪发现问题出在卡牌对象的传递上。例如一张牌从牌堆被摸起放入玩家A的手牌区存储的是Card*然后A打出这张牌牌进入结算流程结算后放入弃牌堆。此时如果手牌区仍然持有这个指针就变成了悬浮指针。解决方案统一所有权规定所有Card对象的生命周期由Game类中的std::vectorstd::unique_ptrCard deck_唯一管理。这个容器在游戏初始化时创建所有卡牌。使用引用而非裸指针在其他地方如手牌区、装备区只存储指向deck_中对象的指针或引用这里用指针更合适因为需要支持nullptr。当卡牌需要被“销毁”如进入弃牌堆时并不是真的删除对象而是将其移动到一个“废弃区”或简单地标记状态等待牌堆重洗时复用。使用智能指针需谨慎可以考虑使用std::shared_ptrCard但要注意循环引用问题。在这个项目中由于Game明确拥有所有卡牌使用unique_ptr加原始指针观察是更清晰的选择。class Game { private: std::vectorstd::unique_ptrCard masterDeck_; // 所有卡牌的唯一所有者 std::vectorCard* drawPile_; // 牌堆持有指针 std::vectorCard* discardPile_; // 弃牌堆持有指针 // 洗牌时将discardPile_的指针移回drawPile_不涉及对象创建销毁。 };6.2 多态与容器导致的切片问题问题现象将WushengSkill对象放入std::vectorSkill中后调用其onCard方法并没有执行子类重写的版本。原因分析这是经典的对象切片问题。std::vectorSkill存储的是Skill对象当插入WushengSkill时会发生拷贝构造但只拷贝了Skill基类部分子类特有的部分被“切掉”了。解决方案存储指向多态基类的指针或智能指针。// 错误对象切片 std::vectorSkill skills; skills.push_back(WushengSkill()); // 切片发生 // 正确存储指针 std::vectorstd::unique_ptrSkill skills; skills.push_back(std::make_uniqueWushengSkill()); // 多态行为得以保留在项目中Player类的skills_成员正是采用了std::vectorstd::unique_ptrSkill。6.3 控制台乱码问题问题现象在Windows中文终端下输出的中文变成乱码或者在Linux下编译时提示“无法将UTF-8字符串转换为窄字符”。解决方案源码文件编码确保所有源代码文件.cpp, .h均以UTF-8 with BOM(Windows) 或UTF-8(Unix) 编码保存。这是现代C项目的推荐做法。执行环境编码在main函数开头设置全局locale或直接操作控制台代码页。#include locale #include codecvt // C17前可用C17后需注意其被弃用 int main() { #ifdef _WIN32 // Windows下设置控制台输出代码页为UTF-8 SetConsoleOutputCP(CP_UTF8); SetConsoleCP(CP_UTF8); #else // Linux/macOS下终端通常默认UTF-8可以设置locale std::locale::global(std::locale(en_US.UTF-8)); std::wcout.imbue(std::locale()); #endif std::cout 三国杀游戏开始 std::endl; // 现在可以正常显示中文了 // ... }字符串字面量在C11及以上可以使用u8前缀来确保字符串字面量是UTF-8编码std::string str u8中文;。但要注意std::cout输出时需要终端支持UTF-8。6.4 游戏逻辑死锁或状态异常问题现象游戏在某些特定操作组合后卡住无法继续或者玩家的状态如手牌数、血量显示不正确。调试技巧添加详细的日志在关键函数入口、状态变更处添加日志输出。例如在Game::triggerCardEvent和每个Skill::onCard方法开始时打印事件和参与者信息。这能帮你清晰地看到事件传播的链条。void Game::triggerCardEvent(CardEvent event, Player* source, Card* card, Player* target) { log(触发卡牌事件: getEventName(event) , 来源: source-getName() , 卡牌: card-getName()); // ... 后续逻辑 }设计状态检查函数编写一个Game::validateState()函数在每回合结束时或怀疑出错时调用。这个函数检查一些不变量是否被破坏例如所有玩家手牌数是否非负、牌堆和弃牌堆总牌数是否恒定、是否有玩家血量超过上限等。一旦发现异常立即打印详细错误信息并中断便于定位问题。单元测试对于最核心、最复杂的模块如结算栈ResolutionStack、技能WushengSkill编写单元测试。使用像Google Test这样的框架可以确保在修改代码后核心逻辑的正确性不被破坏。例如测试“过河拆桥被无懈可击抵消”这个场景是否按预期工作。开发这样一个规模的项目调试和测试所花费的时间往往远超最初的编码。养成边写边测、添加断言和日志的习惯能极大提升开发效率和代码质量。当游戏能稳定运行一局完整的8人局而不出现任何逻辑或崩溃问题时那种成就感是无与伦比的。
