简介：基于SFML引擎开发的七大奇迹双人卡牌游戏数字重制版工程包，面向C++游戏开发学习者和桌游数字化爱好者，对经典桌游的核心机制进行了数字化复刻。项目中包含卡牌动画、资源管理、战争点数计算、科技树系统、回合制流程与多胜利条件判定等模块，适合用于复刻经典桌游并优化游戏体验。压缩包共173个文件，约44.06MB，主要包含55个png贴图、29个lib库文件、11个dll动态库、7个cpp与7个h源码、9个cmake构建配置、7个ogg音频以及1个exe可执行程序等，覆盖从源码到资源、构建及运行的完整链路。已有53人学习下载。通过本包可快速拆解SFML项目的工程结构，参考双人卡牌对战的状态机设计、资源加载与界面渲染写法，也可作为嵌入式平台或桌面端策略游戏开发的入门范例。
1. 为什么是 SFML：这个七大奇迹重制版到底解决了什么问题
一个真实场景——你想把《七大奇迹》这种桌游搬到电脑上，不是做一个 Demo，而是能双人对战的完整回合制游戏。市面上的框架一大堆，Unity 重，Qt 偏应用，纯控制台又做不了卡牌动画。这个项目给出的答案是 SFML 加 C++：轻量、跨平台、图形音频输入一套全包。拆完整个工程后我的结论是：SFML 特别适合桌面级策略卡牌的数字重制，代价是大量游戏逻辑得自己写，但反过来对 C++ 学习者和嵌入式方向转行的开发者反而是好事。
这个项目覆盖了一套卡牌策略游戏的核心模块：资源管理、战争点数判定、科技树、多胜利条件。如果你正想找一个带完整 CMake 配置的 C++ 小游戏源码做参考，或者需要一套能快速跑起来的 SFML 工程骨架，这份资源是值得下下来对着拆的。下文从工程搭建讲到玩法系统，再落到最容易翻车的配置细节。
2. 从零搭一个 SFML 工程：CMake 配置与窗口骨架
2.1 SFML 工程是这么配起来的：别再手动拖库
我第一次配 SFML 是在 Dev-C++ 里，手动加 include 和 lib 目录、还要区分 debug/release 的 lib 文件名，折腾一晚上没跑通。后来改用 CMake 就再没碰过那些事。这个项目里已经给你准备好了SFMLConfig.cmake、SFMLConfigDependencies.cmake、SFMLStaticTargets.cmake这套配置，也就是说你用 CMake 的find_package就能直接定位到 SFML，不用再手写路径。
最常见的写法是下面这个CMakeLists.txt：
cmake_minimum_required(VERSION 3.16) project(seven_wonders_digital) # 指定 SFML 的 config 文件所在目录 set(SFML_DIR "${CMAKE_CURRENT_LIST_DIR}/third_party/sfml/lib/cmake/SFML") find_package(SFML 2.6 REQUIRED COMPONENTS graphics window system network ) add_executable(seven_wonders src/main.cpp src/player.cpp ) target_link_libraries(seven_wonders PRIVATE sfml-graphics sfml-window sfml-system sfml-network ) # 让可执行文件在运行时能找到 DLL if(WIN32) set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}/bin") endif()这段配置里有两个关键点：SFML_DIR指向的是包含SFMLConfig.cmake的目录，不是 SFML 根目录，写错就报find_package找不到；find_package里列了四个组件，其中graphics会自动带出window和system，但network必须显式声明，不然连不了网战。
工程跑通后你会发现，开发期用共享库省编译时间，交付时再把SFMLSharedTargets-release.cmake换成SFMLStaticTargets-release.cmake，静态链接之后单文件就能拷到目标设备上跑。这个项目把两种 target 文件都给你备齐了，属于比较贴心的配置习惯。
2.2 别急着写玩法，先把回合状态机立起来
SFML 本身不管游戏逻辑，它只给你窗口、渲染、输入。所以工程里第一件事是把「双人轮流操作」的状态机写出来。我拆这个工程时最欣赏的一点是它没有把逻辑塞进while (window.isOpen())里，而是抽出一个GameState枚举。
enum class GameState { DEFAULT_DEAL, // 发牌阶段 PLAYER_CHOOSE, // 当前玩家选卡 PASS_CARDS, // 传牌阶段 MILITARY_RESOLVE, // 军事冲突结算 GAME_OVER }; GameState currentState = GameState::DEFAULT_DEAL; while (window.isOpen()) { sf::Event event; while (window.pollEvent(event)) { if (event.type == sf::Event::Closed) window.close(); } switch (currentState) { case GameState::DEFAULT_DEAL: dealHands(hands[0], hands[1], currentEra); currentState = GameState::PLAYER_CHOOSE; break; case GameState::PLAYER_CHOOSE: // 只有当前玩家的输入才生效 handlePlayerInput(hands[currentPlayerIndex], event); break; case GameState::PASS_CARDS: passHands(hands[0], hands[1]); currentState = GameState::PLAYER_CHOOSE; break; // ... } }这段代码里最关键的是event只在PLAYER_CHOOSE状态里传给handlePlayerInput，这样能挡掉一种常见 bug——玩家在结算动画期间乱点导致回合错乱。几乎所有回合制游戏都适合先做状态机再做界面，这个项目把状态拆成了发牌、选卡、传牌、冲突结算四个阶段，分别是七大奇迹桌游一轮里的四个核心动作。
这里有个新手常犯的错：把pollEvent和switch写在一层循环里，一旦事件队列里有多个事件，状态切换会被同一次事件干扰。正确做法是先取完所有事件，再按当前状态统一处理，而不是事件里嵌套状态判断。
3. 核心系统拆解：卡牌数据、资源管理、战争点数与科技树
3.1 卡牌与玩家的数据结构：表驱动比硬编码好维护
七大奇迹的卡牌数量不多，但每张卡同时有费用、资源产出、所属时代、种类，硬编码会写出一堆 if 语句。这个工程用的是「表驱动」方式：每张卡一个结构体，一整批卡放在数组里。
enum class CardType { RESOURCE, // 资源卡：木材、石子、陶器、布料等 MILITARY, // 军事卡：提供军事钩标 CIVIC, // 市政卡：提供市民点数 SCIENTIFIC, // 科技卡：齿轮、石板、罗盘 GUILD, // 公会卡：完成时结算 WONDER // 奇迹卡：建设阶段特殊能力 }; struct Card { int id; int era; // 所属时代 CardType type; std::unordered_map<ResourceType, int> cost; // 建造费用 std::unordered_map<ResourceType, int> produce; // 资源产出 int militaryShields; // 军事钩标数量 int civicPoints; // 市政点数 ScienceIcon scienceIcon; // 科技图标 }; const std::vector<Card> kAllCards = { { 1, 1, CardType::RESOURCE, { {ResourceType::WOOD, 1} }, { {ResourceType::WOOD, 1} }, 0, 0, ScienceIcon::NONE }, // ... 其他卡片数据 };cost和produce用unordered_map<ResourceType, int>，好处是扩展新资源不需要改函数签名。代价是查找略慢一点——但一局游戏几十张牌，这点开销可忽略。
如果你要自己动手，建议把所有卡牌数据抽到.csv或.json里，运行时加载进kAllCards。工程里选硬编码数组是为了保持单文件可部署，但你自己扩展时，表驱动加外部配置才是可维护的路线。
3.2 资源管理门道：用枚举索引直接寻址
玩过七大奇迹的都知道，资源分两类：基础资源（木材、矿石、陶器、布料）和进阶资源（玻璃、纸莎草）。建造卡牌时按数量扣资源。很多实现喜欢std::map<ResourceType, int>，每次都find一次，代码啰嗦还容易写错。这个工程做得比较聪明：资源类型是枚举，其数值就是内部数组下标。
enum class ResourceType : int { WOOD = 0, ORE = 1, CLAY = 2, CLOTH = 3, GLASS = 4, PAPYRUS = 5, COIN = 6, COUNT // 占位，表示资源种类总数 }; struct PlayerInventory { std::array<int, static_cast<size_t>(ResourceType::COUNT)> resources{}; bool canAfford(const Card& c) { for (const auto& [type, amount] : c.cost) { if (resources[static_cast<int>(type)] < amount) return false; } return true; } void payCost(const Card& c) { for (const auto& [type, amount] : c.cost) { resources[static_cast<int>(type)] -= amount; } } };这段代码的精髓是ResourceType::COUNT。有了它，数组大小跟着枚举数量走，加新资源只需改枚举，不用回头改所有数组声明。canAfford和payCost成了对同一张表的两个操作，天然避免买得起的判断与实际扣费逻辑不一致的翻车情况。
一个实现细节：金币 COIN 也放进资源数组里统一管理，购买时 COIN 就在cost里，不需要单独一套货币逻辑。我见到不少项目把金币单独设个int coin，结果想出多种「用钱换资源」的结算写法，其实统一进数组后，任何「扣资源给资源」的逻辑就一套代码通用了。
3.3 战争点数计算：把条件段变成可读的判定
七大奇迹的军事规则是每时代结束时，比较玩家间军事符号数量，赢家获得对应时代的点数，「战争点数」是衡量军事力量的核心指标。这个工程把它从 UI 层摘出来，做成独立判定模块，方便单测和调整。
// 按时代返回战斗点数 static constexpr int MILITARY_CONFLICT_POINTS[] = { 6, 8, 10 }; int resolveMilitaryConflict(int myShields, int oppShields, int era) { // 三大奇迹原版规则：时代1冲突赢者得6分，时代2得8分，时代3得10分 // （双人变体可把 6/8/10 放到配置文件里按需调整） if (myShields > oppShields) return MILITARY_CONFLICT_POINTS[era]; if (myShields == oppShields) return 0; // 平局各不得分 return -1; // 输掉冲突后，从总军事分中扣 1 分 }每次时代结束，调用一次这个函数，把返回分累加到玩家总军事分数。
关键的坑是「平局」和「战败」的分数处理容易混淆：平局是0，战败是-1。有人把战败写成-2，打了两轮后发现数值失衡。另外，这个函数的输入myShields在七大奇迹原版中来自全部军事卡的符号总数，你如果引入了「军事卡加成」或「奇迹提供钩标」的规则，记得在调用前聚合，而不是在函数里猜来源。
如果要对战争点数做调试，把它设计成一个不依赖 UI 的函数挺重要——我一般把resolveMilitaryConflict放在单独的battle.cpp里，旁边就是自动化测试代码，跑一次就知道当前规则逻辑对没对。
3.4 科技树实现：不要用图，用邻接表数组就够了
策略游戏的科技树常被做成有向无环图，但在这个项目场景下——卡牌数量不到几十张、科技效果只有三种图标组合——用图反而误事。工程的实现非常务实：每张科技卡有一个前置条件列表，canResearch遍历检查即可。
struct ScienceCardDef { int cardId; ScienceIcon icon; // GEAR, TABLET, COMPASS std::vector<int> prerequisites; // 需要已拥有的科技卡 id }; bool canResearch(const ScienceCardDef& def, const std::vector<int>& ownedScienceCards) { for (int reqId : def.prerequisites) { auto it = std::find(ownedScienceCards.begin(), ownedScienceCards.end(), reqId); if (it == ownedScienceCards.end()) return false; // 有一个前置没满足就是不行 } return true; }prerequisites是「必须全部满足」的意思，你如果想做「二选一」树，得自己加工成条件分支。对七大奇迹这类短链科技，足够实现大部分规则变体。
说完光子还有个 V 字：科技胜利的条件也很直白——凑齐三种图标各 1 个得 1 分，之后每多一套加 1 分；同种图标三张额外加 7 分。这个判定不需要建树，对玩家手里的科技图标做个频次统计就能实现：
int calcSciencePoints(const std::vector<ScienceIcon>& icons) { std::map<ScienceIcon,int> cnt; // 三种图标计数 for (auto icon : icons) cnt[icon]++; int setScore = 0; int sameScore = 0; int minSets = std::min({ cnt[GEAR], cnt[TABLET], cnt[COMPASS] }); while (minSets--) { setScore += 1; if (minSets > 0) setScore += 1; // 每套+1 } for (auto& [icon, count] : cnt) { while (count >= 3) { sameScore += 7; count -= 3; } } return setScore + sameScore; }这个循环里最容易被忽略的是sameScore累积后直接改变了count，如果你先算完总量再计分，会重复计算。我在自己项目里吃过这个亏——同一组图标里既有三件套又有成套，两个分数算完一相加，直接多了 7 分。
3.5 多胜利条件判定：聚合到 GameResult 结构
七大奇迹是典型的「多路胜利条件同时存在、最后汇总分高者胜」，而不是先触发先赢。工程里把战争、科技、市政（蓝色卡点数）、公会点数、奇迹阶段加成，全部汇总成一个结算函数。
struct GameResult { int militaryScore; int scienceScore; int civicScore; int guildScore; int wonderScore; int coinScore; int total() const { return militaryScore + scienceScore + civicScore + guildScore + wonderScore + coinScore; } }; GameResult computeFinalResult(const PlayerInventory& p) { GameResult r; r.militaryScore = p.totalMilitary; r.scienceScore = calcSciencePoints(p.collectedScienceIcons); r.civicScore = p.totalCivicPoints; r.guildScore = calcGuildPoints(p.guildCards); r.wonderScore = p.totalWonderPoints; r.coinScore = p.resources[static_cast<int>(ResourceType::COIN)] / 3; return r; }金币换算规则（3 枚金币算 1 分）也是七大奇迹原版设定，我看到不少移植版把这行写丢，最后结算时金币完全没参与。把它放到computeFinalResult里，测试时一眼能看到。
特别注意：calcGuildPoints的结算需要对手信息（部分公会卡根据对手的资源/科技计分），所以computeFinalResult应该接收两个玩家的PlayerInventory，而不是只查自己。这个依赖关系一旦漏掉，公会卡分数就全算错了，是最隐蔽的逻辑之一。
4. 卡牌动画和交互手感：刷新循环里的一门小课
4.1 卡片翻转动画：不要用线程，交给时钟驱动
卡牌游戏最核心的动效就是翻牌和移动。常见做法是用独立线程 sleep 来做延时动画，结果主循环卡、线程还和刷新循环抢资源。这个工程的动画部分完全由渲染循环内的sf::Clock驱动，每帧只算当前插值，不做任何阻塞。
sf::Clock flipClock; bool isFlipping = false; float flipProgress = 0.0f; void startFlipAnimation() { isFlipping = true; flipClock.restart(); flipProgress = 0.0f; } // 渲染循环内部，每帧调用一次 void updateFlipAnimation(sf::Sprite& cardSprite, sf::Texture& front, sf::Texture& back) { constexpr float DURATION = 0.35f; // 翻转时长，350ms 手感比较自然 if (!isFlipping) return; float dt = flipClock.getElapsedTime().asSeconds(); if (dt >= DURATION) { dt = DURATION; isFlipping = false; // 动画结束，停留在正面 } flipProgress = dt / DURATION; // 第一段 0~0.5：从正面缩到 0 宽；第二段 0.5~1：背面从 0 宽展开 float scaleX = std::cos(flipProgress * 3.14159265f); cardSprite.setScale(std::abs(scaleX), 1.0f); if (scaleX <= 0.0f && flipProgress > 0.5f) { // 在缩放为 0 的那一帧切换纹理，视觉上就是「翻面」 cardSprite.setTexture(front); } else if (scaleX > 0.0f && flipProgress < 0.5f) { cardSprite.setTexture(back); } }这段动画的关键是std::cos驱动的scaleX，在 0 到 π 之间从 1 平滑降到 -1，取绝对值后宽度缩放总是正的，负号只用来判断翻面时机。比你手写线性插值处理翻转切换要丝滑得多。
DURATION是唯一需要调的手感参数。我试过 0.2s 太快看不出翻面、0.5s 又拖节奏，0.35s 左右最接近实体桌游打牌的速度。如果你做的手游偏休闲向，可以放到 0.45s——慢一点给玩家「决策反悔」的心理缓冲。
4.2 点击拖拽与命中：只认手牌区的 CardSprite
桌游里玩家选一张卡打出去，数字版最常用的交互就是「点击手牌，再点击场上区域」。容易出现的问题是：玩家把牌拖到不属于他的区域，程序也照样响应。解决方法是命中检测先限定在手牌容器里。
struct HandCard { Card card; sf::Sprite sprite; sf::Vector2f homePos; // 手牌在界面上的固定位置 bool isDragging = false; }; // 在手牌区找被点击的那张 int hitTestHand(const std::vector<HandCard>& hand, const sf::Vector2i& mousePos) { for (size_t i = 0; i < hand.size(); ++i) { if (hand[i].sprite.getGlobalBounds().contains( static_cast<sf::Vector2f>(mousePos))) { return static_cast<int>(i); } } return -1; // 没点到牌 } // 拖拽结束：目标区合法才返回 true；否则把牌弹回 homePos bool tryPlayCard(HandCard& handCard, const sf::FloatRect& playZone, const sf::Vector2i& mousePos) { if (!playZone.contains(static_cast<sf::Vector2f>(mousePos))) return false; handCard.isDragging = false; handCard.sprite.setPosition(handCard.homePos); return true; }getGlobalBounds而不是getLocalBounds是个容易漏的细节。因为手牌被setScale动画缩放后，局部边界不随缩放变化，只有全局边界才反映实际显示区域。如果你在缩放手牌时用局部边界做点击判断，旋转和缩放后的卡片会点不准，玩家会疯狂吐槽「我明明点到了」。
手牌区的拖拽状态也可以并入前面状态机：拖拽期间把状态改成DRAGGING_CARD，此时禁掉全局快捷键。因为你用的是文本框，如果玩家拖牌时不小心碰到键盘触发跳过回合，一局的好心情就毁了。
5. 避坑常见问题：SFML 链接、静态库内存和资源路径
5.1 链接错误 undefined reference：Debug/Release 与依赖顺序
现象：项目编译能过，链接阶段出现undefined reference to sf::RenderWindow::create之类的一大串。
原因：链接器给你的是 Release 版sfml-graphics.lib，但你编译器在 Debug 模式，SFML 的 Debug 库文件叫sfml-graphics-d.lib（注意那个-d）。CMake 配置里只写组件名时容易混，因为组件名sfml-graphics在不同配置下会映射到不同文件。
解决：明确指定 CMake 使用Debug配置，并且让target_link_libraries只链接你确定存在的库。首先在 CMake 里设置：
set(CMAKE_BUILD_TYPE Debug)然后查看 SFML 的SFMLSharedTargets-debug.cmake，确认IMPORTED_LOCATION_DEBUG指向sfml-graphics-d.dll。如果手动链接，Debug 就用带-d的库，Release 用不带-d的库。另一个隐藏坑是库顺序——静态链接时，sfml-graphics要写在前面，依赖的sfml-window和sfml-system放后面。顺序反了同样报 undefined reference。
5.2 运行时黑屏或秒退：缺 DLL 和字体问题
现象：编译通过，双击 exe 黑屏后退出，没有任何报错弹窗。
原因：共享库模式下，运行时需要sfml-graphics-2.dll、sfml-window-2.dll、sfml-system-2.dll，还有openal32.dll（音频组件会依赖它）。打包时只把 exe 拷给别人，这几个 DLL 没带上，程序启动时静默失败。
解决：用sf::err()重定向错误输出，先把内部日志打出来：
std::ofstream errLog("sfml_errors.log"); sf::err().rdbuf(errLog.rdbuf());然后在工程输出目录建bin/，把SFML 安装目录/bin下所有 DLL 拷进去。如果还是黑屏，检查sf::Texture::loadFromFile的返回值——SFML 加载失败不会抛异常，只返回 false 并且静默，所以每个资源加载都值得断言一下。
5.3 中文字体显示成方块：SFML 不代字体，纯占位是不行的
现象：卡牌标题用sf::Text+ 默认字体，中文全变方块。
原因：sf::Font::getDefaultFont是 SFML 内置的像素字体（DejaVu Sans的最小子集），它根本没有中文字形，所以所有中文 render 出来都是占位符。你问我怎么确认的，把字号调大，方块变大的就是字体，不是贴图。
解决：加载系统字体或用资源包内字体文件：
sf::Font font; if (!font.loadFromFile("assets/fonts/NotoSansSC-Regular.otf")) { sf::err() << "中文字体加载失败，游戏退出" << std::endl; return -1; } sf::Text title("亚历山大图书馆", font, 24);顺带一提，lp之类的宽字符传参不会让sf::Text自动转换，字符串编码和字体字形要匹配。用u8"中文"字面量并保证源码文件是 UTF-8 编码，Windows 下尤其是古老的 VS2017 需要额外/utf-8编译选项。
5.4 回合错乱：双人在同一台电脑上按键互相抢
现象：两个玩家共用同一键盘，选卡阶段坐右边的玩家按方向键，结果是左边玩家的卡被操作了。
原因：事件处理里没有按「当前玩家」做过滤，左右方向键对两个玩家是全局监听。最初序好的时候没事，一旦有状态切换延迟，按键事件堆栈里积压了几帧，就会作用到错误的玩家。
解决：给输入处理加一层玩家锁：
if (currentPlayerIndex == 0 && event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Left) { handleSelectCard(0); } if (currentPlayerIndex == 1 && event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Right) { handleSelectCard(1); }并且在状态切换时调用while (window.pollEvent(...))清空残留事件。这算是我踩过最深的坑，比起 3D 渲染难题，双人单键盘的输入隔离才是最影响实际体验的。玩家开了一局后卡在错误回合，多半就是这个原因。
5.5 贴图发白或者闪烁：GPU 纹理绑定与加载时机冲突
现象：卡牌贴图加载完成后，拖动窗口边缘，部分贴图变白，最后整张卡消失。
原因：SFML 的纹理上传依赖 OpenGL 上下文，如果你在多个线程分别加载纹理或没限制纹理最大使用数量（旧显卡 2.x 版本有名的黑匣子），纹理在 GPU 上会被替换或驱逐，然后渲染引用的就是空纹理 ID。
解决：所有loadFromFile集中在init()里单线程顺序加载，加载完后不再新增纹理；用一个std::unordered_map<std::string, sf::Texture>做纹理缓存：
static std::unordered_map<std::string, sf::Texture> s_textureCache; const sf::Texture& loadTexture(const std::string& path) { auto it = s_textureCache.find(path); if (it != s_textureCache.end()) return it->second; sf::Texture tex; if (!tex.loadFromFile(path)) throw std::runtime_error("Texture load failed: " + path); auto result = s_textureCache.emplace(path, std::move(tex)); return result.first->second; }如果你的动画里频繁创建sf::Sprite，记得sprite.setTexture(texture)要传入引用——一旦你的缓存用了返回值，别在循环里把sf::Texture按值传给setTexture，那会造成一次复制，瞬间双倍显存占用。这个开关我翻车过，当时一局 20 张卡牌动画，显存一下子飙到 500MB，就是按值传纹理复制导致。
6. 进阶玩法：把战争点数计算做成自动化验证，再谈嵌入式适配
资源里反复出现了SFMLSharedTargets-release.cmake和SFMLStaticTargets-release.cmake，这暗示了项目最后要往嵌入式平台推。嵌入式平台上的 SFML 不是不能跑，而是去掉调度器那一套 UI 后，你得把游戏逻辑做薄。所以最后一个实战技巧：把战争点数、科技分数这类纯计算函数单独拎成test_battle.cpp，用标准 C++ 断言跑离线测试，不依赖窗口环境。
#include <cassert> void test_military_conflict() { // 时代 0：我的军队多，拿 6 分 assert(resolveMilitaryConflict(3, 1, 0) == 6); // 时代 1：平局不得分 assert(resolveMilitaryConflict(2, 2, 1) == 0); // 时代 2：输掉冲突，扣 1 分 assert(resolveMilitaryConflict(0, 4, 2) == -1); // 一个容易被忽略的边界：0 对 0 照样是平局 assert(resolveMilitaryConflict(0, 0, 0) == 0); } int main() { test_military_conflict(); sf::err() << "battle logic tests passed" << std::endl; return 0; }每次改完平衡性参数（比如把时代 1 的胜利分从 6 改成 7），就跑一次test_battle，确保没有静默改坏原有判定。这套做法让我后来调整七大奇迹变体规则几乎没引入过回归 bug。
如果你要往嵌入式设备适配，记住三件事：第一，所有纹理用静态库版本减小部署体积；第二，窗口创建分辨率固定为设备原生分辨率而不是硬编码 1920×1080，不然树莓派一类的板子渲染压力很大；第三，把window.setVerticalSyncEnabled(true)打开，避免纯 CPU 空转把嵌入式设备的功耗拉爆。
这个工程里我最喜欢的一个细节是把资源、战争点数、科技树的判定全部从 UI 层解耦了。这就是一份「学引擎顺便学游戏架构」的好素材，舍得拆、舍得跑，你会比去看 SFML 官方教程更早理解「代码组织方式决定了一个策略游戏好不好扩展」。
从那以后我每接到一个卡牌游戏项目，都会强制走一遍这套流程：先搭状态机、再写纯逻辑测试、最后才接渲染动画。顺序反了，一定会在某个加新卡牌的深夜骂自己当初怎么这么懒——希望帮到你。
本文还有配套的精品资源，点击获取
