做《万国纪·史诗长歌》这个项目，其实是我在给几个朋友讲游戏开发时偶然聊出来的。当时的想法很简单：不整那些需要复杂引擎和美术资源的大制作，就用手边最普通的工具，把一个历史题材的策略游戏从零搭起来。这游戏的核心可以概括成一句话——扮演一个文明领袖，在随机生成的六边形地图上发展城邦、训练军队、触发历史事件，最后在有限的回合内存活并扩张。它没有华丽的画面，但对理解策略游戏的核心循环、事件驱动机制和数据建模非常有帮助。
如果你正想动手做一款属于自己的游戏，又不知道从哪里切入，或者对策略类游戏“怎么就玩起来有意思”这件事感到好奇，那这篇文章应该能给你一个完整的答案。我会把这套项目的设计思路、数据模型、事件系统实现和排坑过程全部拆开讲，你不需要有很强的编程基础也能跟上，中间涉及到的代码我也尽量用简单的方式呈现。
1. 项目定位与整体设计思路
1.1 这个游戏到底是什么，解决什么问题
我做这个项目的出发点不是“我要做一个能卖钱的商业游戏”，而是“能不能用尽量少的工程量，把历史题材策略游戏的核心玩法跑通”。之所以选择历史题材的“万国纪”，是因为这类游戏有一个天然的优势：玩家天然有代入感。大家不需要你去解释什么是弓箭手、什么是商路、什么是文明更迭，这些词汇本身携带了足够的想象空间。
游戏的核心循环是这样设计的：玩家在每一回合中，可以消耗资源来执行动作，比如派军队探索地图、建造城市设施、发展科技、发起外交。执行完动作后，回合结束，系统结算产出、处理AI对手行动、触发随机事件，然后进入下一回合。这里最难处理的不是画面，而是数据流转和规则判定。我把整个游戏逻辑拆成了几张数据表：资源表、单位表、建筑表、科技表、事件表，每张表都是一个JavaScript对象数组，这样既方便初始化，也方便后续扩展。
一开始我也考虑过用Unity或者Godot这类引擎来做，但后来发现对这个项目来说属于杀鸡用牛刀。引擎带来的场景管理、资源加载、物理碰撞这些能力，在这个纯策略游戏里几乎用不到。我最后选择的是纯前端技术栈：HTML5 Canvas绘制地图、原生JavaScript处理逻辑。这样有什么好处呢？首先，没有任何环境依赖，浏览器打开就能玩；其次，Canvas的像素操作足够满足六边形网格的绘制需求，不需要引入第三方图表库；最后，这套做法特别适合讲课，因为所有代码逻辑摊在明面上，没有框架帮你偷偷藏掉细节。
1.2 方案选型：为什么不做多人，不做即时制
在项目规划阶段，我一度想加入多人联机功能。后来冷静想了想，还是把规模砍掉了，原因很简单：职责边界。这个游戏的教学重点在策略逻辑本身——地图生成、资源管理、规则引擎、事件驱动。如果加入多人联机，工作重心就会被网络同步、状态广播、断线重连这些底层问题拉扯走，结果就是教了半天，学生全在学网络编程，游戏本身的策略设计反而讲不透。
最终我把这个项目定位为单机热座模式，也就是在同一台电脑上，两个玩家轮流操作，各自管理自己的文明，互相对抗或者合作。这么做有几个具体的好处：第一，完全绕开了网络同步的所有问题，可以专心打磨游戏规则；第二，热座模式本身就是回合制策略游戏的经典形态，很多经典的文明系列早期作品都是这么设计的；第三，代码量大概能减少三分之一，这个裁剪对新手来说非常重要。
可能有人会问：“即时制是不是更刺激？”确实是，但即时制需要处理两套完全不同的问题：并发逻辑和AI决策实时性。而在回合制里，AI的决策逻辑是在每个回合结束时顺序执行的，你有大把时间把“行动优先级”“威胁评估”这些概念讲清楚。对于学习项目来说，慢反而是优势，因为每一步都有迹可循。
1.3 最小可玩版本的范围界定
我给这个项目设了一个“最小可玩版本”的边界。它不要求你完成所有功能，但必须包含以下核心模块：随机生成一张中等大小的六边形地图；两种资源（食物和金币）的产出与消耗；三类单位（探索者、战士、殖民者）；两个建筑（粮仓和军营）；一套事件卡池（至少十五个历史事件）；一个极简战斗公式；以及一个至少能判断胜负的回合系统。
说白了，这个版本的目标是让一个玩家能在一小时内完整地体验一整局游戏，从开局建城，到探索地图，到触发事件，到发生战斗，到最终占领足够领地或者被AI灭掉。对比完整版，我砍掉了科技树、宗教系统、外交协议、海上单位、气候灾难等一大堆内容。这些留到后续版本再一点一点加，每个版本只加一个系统，保证学习曲线平缓。
2. 核心模块拆解与实现原理
2.1 地图生成：六边形网格的建模方式
策略游戏的地图看起来最直观，但底层的数据结构反而是很多新手第一个卡住的地方。我选择的是六边形网格（hex grid）。相比正方形网格，六边形的优势在于每个格子到邻居的距离均匀，不会出现“斜角对角算不算相邻”的争议问题。劣势是坐标系统略复杂，但这正是一个好的学习点。
常用的六边形坐标有三种：偏移坐标、立方体坐标、轴向坐标。我这里直接推荐轴向坐标，因为它的数学表达最简洁，转换也最方便。在一个轴向坐标系里，每个格子用两个整数（q, r）表示，q代表列方向，r代表行方向。相邻六边形的关系，通过一圈固定的偏移量查表就能得到。
// 六边形轴向坐标的6个邻居偏移 const NEIGHBOR_DIRECTIONS = [ { q: 1, r: 0 }, { q: 1, r: -1 }, { q: 0, r: -1 }, { q: -1, r: 0 }, { q: -1, r: 1 }, { q: 0, r: 1 } ]; function getNeighbor(hex, direction) { return { q: hex.q + NEIGHBOR_DIRECTIONS[direction].q, r: hex.r + NEIGHBOR_DIRECTIONS[direction].r }; }地图生成时，我用了一个简单的高度图算法：先随机撒几个“地形种子”，每个种子设定一个高度影响范围，然后每个格子根据距离最近种子的远近，判断自己是平原、丘陵还是山脉。这样生成的这张地图就能自然地分隔出领地，也给后续的“探索”玩法提供了空间。整个过程其实就是一圈循环嵌套坐标计算，我在项目里用了不到六十行代码就完成了这一步。
生成完地形之后，还要在地图上撒资源点。我的规则是：每块地图上生成五到六个“富饶之地”，这些格子的食物产出是普通平原的三倍，因而成为玩家争夺的焦点。这里有个细节值得注意：资源点的分布要避免两个富饶之地紧挨着，否则玩家一旦占据就同时获得双份收益，游戏平衡就会崩。我在代码里加了一个简单的最小距离检查，如果随机生成的位置距离已有富饶之地小于三格，就重新换一个位置。
2.2 数据模型：用普通对象把世界存下来
游戏的状态管理，说白了就是用一个全局对象把所有关键数据串起来。我用一个叫做GameState的全局对象来承载：地图是二维数组，数组的元素是格子的地形信息、资源信息与所属势力；玩家的状态则是另一个对象，里面存着资源、科技等级、单位列表和建筑列表。
这里我想特别强调一个经验：写游戏逻辑时，最容易往后腐烂的，不是某个具体功能的代码，而是“变量散落得到处都是”。比如你今天的代码里用了一个cityList记录城市，过两天又在另一个地方用cities存同样的数据，后面调试起来会非常崩溃。所以做这种项目的第一天就应建立规则：凡是会被跨函数读取的数据，统一放进GameState里，并且加清晰注释。
来看一下我当时定义的玩家对象结构：
const player = { id: 0, name: '华夏文明', color: '#C0392B', resources: { food: 20, gold: 0 }, cities: [cityId], units: [unitAId, unitBId], techLevel: 1, policies: [], alive: true };这个Player对象里，我特意没把具体的资源数值散在外层，而是用嵌套的resources字段来存，因为后续可能会加入铁、石料、文化点等更多资源类型，嵌套结构方便扩展。单位列表里存的是单位的唯一ID，具体单位信息在unitsById的映射表里，这样在单位死亡时，只要从映射表里删除对象，再从这个数组里过滤掉ID就行，不会出现有单位尸体残留的问题。
地图数组里的格子结构，我用了这样的字段设计：
const tile = { q, r, terrain: 'plain' | 'hill' | 'mountain' | 'water', food, gold, ownerId, hasResource, hasBuilding };每个格子的ownerId默认是-1，表示中立无人占领。当一个玩家把城市建在某个格子上时，这个格子以及相邻一圈格子都会被标记为这个玩家的核心领土，并且每隔一定格子数，会有一个“影响力边界”的概念，边界内的中立格子也会逐渐被染上势力颜色。这个势力扩散的逻辑，让玩家一眼就能看清谁在扩张。
2.3 回合系统与行动机制
很多策略游戏新手会忽略的一个问题是：行动到底是“立即生效”还是“回合末结算”。我在这版项目里做了一个混合设计。探索、移动、攻击这类动作是立即执行的，因为玩家需要即时反馈；而资源产出、人口增长、科技研发这类过程性内容，是在回合结束阶段统一结算。
回合结束的结算顺序非常重要，我把它写死为一个固定的执行队列：先结算每个城市的食物产出，如果食物溢出则人口增长；然后是金币产出，金币用于支付单位维护费；再处理科技研发进度，最后让AI对手执行决策。这个固定顺序至少避免了游戏运行中一半以上的逻辑错乱问题。
有段时间我图省事，想让食物产出立即入账、金币也立即入账，结果导致玩家在一个回合内可以先消耗食物、再用金币买食物，形成无中生有的资源刷取漏洞。改成统一结算后，这种问题就不可能出现，因为回合内的操作只影响当前存量，不改变产出预估。这一步设计对于把规则讲清楚帮助很大。
每回合玩家的行动点（Action Point）我用了一个简单的数值：正常情况下每个玩家每回合有3点行动点，移动一个单位消耗1点，攻击消耗1点，建设城区需要消耗当前回合的所有行动点。这样做迫使玩家每回合都要做取舍：是推进探索，还是准备战斗，还是专注发展。资源有限、选择无限，是策略游戏设计里的黄金法则。
2.4 事件系统：让历史故事自动发生
“史诗长歌”的叙事感不能靠人写一段又一段剧情文本来实现，而是靠随机事件系统来制造沉浸感。我在游戏里预置了十五个事件，每个事件有几个核心属性：触发条件（比如“己方城市数量大于等于三”“金币库存低于十”“处于交战状态”）、事件正文描述、可选项分支、每个选项的资源影响和后续效果。
一个典型的事件结构长这样：
{ id: 'plague_outbreak', title: '瘟疫席卷边境', condition: (state) => state.player.cities.length >= 2 && state.turnNumber > 30, options: [ { text: '封锁城市，减少传播', effect: (state) => { state.player.resources.food -= 10; state.player.resources.gold += 0; state.player.cities.forEach(c => c.population -= 1); }, consequence: '瘟疫得到控制，但人口减少' }, { text: '开仓赈粮，稳定民心', effect: (state) => { state.player.resources.food -= 15; state.player.cities.forEach(c => c.loyalty += 10); }, consequence: '民心稳定，但食物储备告急' } ] }事件触发的机制也很简单：每回合结束时，遍历事件池里所有未被触发过的事件，检查condition函数是否返回true，满足条件的放入“本回合可触发事件”列表，再按优先级排序，显示前两个给玩家选择。这样就实现了“历史事件和游戏状态挂钩”的效果，而不是凭空冒出来。
这里我踩过的一个深坑是事件重复触发的问题。最初没写触发状态记录，结果某个回合事件被玩家连续触发三次，金币反复波动，游戏数值直接乱掉。后来我在事件对象里加了一个fired字段，同一局游戏里每个事件最多触发一次，并且把已触发的事件放入一个历史记录数组里，这样玩家可以回头看到自己决策过的所有事件回响。
3. 实操过程：从零到这个游戏跑起来
3.1 地图渲染的Canvas实现细节
既然选择了Canvas，地图的绘制就得自己动手。这一步没有太大的魔法，核心就是把每个六边形的六个顶点坐标算出来。计算顶点坐标的公式其实是个简单的三角函数问题：正六边形每个顶点相对于中心点，角度相隔60度。我把这个计算封装成一个复用度很高的函数，它接收格子的中心坐标和半径，返回六个顶点的坐标数组：
function hexCorners(centerX, centerY, size) { const corners = []; for (let i = 0; i < 6; i++) { const angle = (Math.PI / 180) * (60 * i - 30); corners.push({ x: centerX + size * Math.cos(angle), y: centerY + size * Math.sin(angle) }); } return corners; }绘制时，我先根据每个格子的地形类型决定填充色：水域是偏深的蓝、平原是浅绿、丘陵是土黄、山脉是灰褐。然后用beginPath、moveTo、lineTo把这些顶点连接起来，最后fill、stroke。每格渲染完，再把边界线用半透明白色描边，这样不同势力的领地就能在视觉上明显区分。整个渲染循环的调用顺序是：清屏、绘制网格底图、绘制资源图标、绘制单位图标、绘制城市图标、绘制高亮边框。
让我特别提一下这里的性能优化问题。最初我直接在每次需要变化时全部重绘地图，本地图上两百个格子还好，但玩到后期地图扩到五百多格的时候，每回合结束的结算阶段会掉帧。后来我把渲染逻辑分成两层：静态层，只有在地图结构变化时重绘；动态层，只有单位位置、选中高亮、攻击特效等变化时重绘。静态层先一次性绘制到一张离屏Canvas缓存里，每次重绘时先把缓存整张贴上去，再在缓存上绘制动态内容。这个改动让整体帧率稳定了很多。
3.2 AI对手的决策逻辑：按优先级排队
这个项目的AI对手，其实只是一个按照规则执行决策的函数。我给它设计了一个决策优先级列表，从上到下依次判断：如果某个敌方单位在我的领地旁边，就尝试攻击；如果发现扩张无人区里有富饶之地，就派殖民者过去建新城；如果自己城市数量落后于玩家，就加建粮仓；最后，如果无事可做，就让探索者随机移动。这个“优先级决策树”的概念特别适合新手理解，因为它非常贴近人的思考方式。
AI的核心代码逻辑是这样的：
function aiTurn() { const decisions = [ { condition: nearEnemyUnit, action: attackNearby }, { condition: hasUnclaimedFertileLand, action: expandToFertile }, { condition: cityCountIsLagging, action: buildGranary }, { condition: hasIdleExplorer, action: randomExplore } ]; for (const decision of decisions) { if (decision.condition()) { decision.action(); break; } } }这个朴素的AI当然离“聪明”还很远，但它的好处是：每一步都是可预测的，玩家能感觉到自己在跟一个“有策略”的对手过招，同时它又不会强得离谱。为了让AI的行为更多样化，我后来又给它加了一个暗地里的“战略偏向”随机值。有的AI偏向进攻，有的偏向发展，这样每局游戏的对手风格都不太一样。
3.3 UI界面：尽量少用框架，自己写布局
因为不想引入React或Vue这类框架，整个界面的交互逻辑我都是手动控制的。页面布局分左右两栏：右边是Canvas地图主体，左边是一个状态面板，用来显示玩家资源、当前回合、选中单位信息、事件描述和选项按钮。
这里最值得分享的是事件弹窗的实现方式。我没有用浏览器的alert或confirm弹窗，因为那种弹窗会阻塞JavaScript的执行线程，导致游戏状态没法正确刷新。我的做法是：在地图上方覆盖一个绝对定位的div层，里面渲染事件文本和选项按钮。当玩家点击某个选项后，执行该事件effect函数，然后把弹窗层隐藏，游戏继续运行。这样玩家可以边看地图边做决策，不会被强制切断操作。
状态面板的数据刷新，我用了最朴素的方法：每回合结束，调用一次renderInfoPanel()，直接更新DOM元素的innerHTML。因为每回合的数据量很小，不会带来性能问题，而这样写的好处是完全没有数据绑定的黑魔法，发生了什么一目了然，特别适合教学。
3.4 战斗公式：让数值看起来合理，又不复杂
战斗系统是很多新手最容易陷入数值计算泥潭的地方。这里我设计了一个尽量简单但反馈明显的公式。攻击方战力 = 单位基础攻击力 + 地形加成；防守方战力 = 单位基础防御力 + 地形加成 + 城墙加成（如果有城市防御）。然后计算一个胜负概率，随机决定结果。具体公式是这样的：
function resolveBattle(attacker, defender, tile) { const atkPower = attacker.attackPower + (terrainBonus(attacker, tile)); const defPower = defender.defensePower + (terrainBonus(defender, tile)) + (defender.isInCity ? 2 : 0); const probability = atkPower / (atkPower + defPower); if (Math.random() < probability) { return { attackerWon: true, damageToDefender: atkPower - defPower * 0.5 }; } return { attackerWon: false, damageToAttacker: defPower * 0.6 }; }这个公式的核心思路是兰彻斯特方程的简化版，只看进攻和防御的比值，通过随机数来模拟不可控的战场变化。地形加成的逻辑也很重要，我把丘陵地形设为防守方加1点防御力，水域里攻击方无法进入，山脉是天然屏障不可通行。这样的设计让地图不只是装饰，而是切切实实影响战局，玩家学会利用地形，战斗胜率会显著提升。
战斗体验上，我加了一个非常简单的动画效果：攻击方单位从自己格子上短暂挪到目标格子上，然后显示一个命中特效，再计算伤害并更新数据。因为战斗结算即时，玩家可以直观地看到谁赢了、损失了多少血。如果胜方单位还存活着，它会原地停留，本回合不能再次行动。
4. 常见问题与排查技巧实录
4.1 地图生成“卡死”与无限循环问题
在地图生成的早期版本，我遇到过最典型的问题就是程序运行到某一步突然“卡死”。排查之后发现，问题出在资源点放置的循环上——当可用中立格子已经很少时，最小距离检查一直不通过，循环无法退出。这类“死循环”问题在写地图生成逻辑时特别容易遇到，因为随机数在极端情况下可能会连续多次生成不满足条件的位置。
解决办法是在循环中加入最大重试次数限制：
let attempts = 0; while (attempts < 1000) { const candidate = randomTile(); if (isFarEnough(candidate)) break; attempts++; }为了让这种事不再发生，我还给整个随机生成流程加了一层“兜底逻辑”：如果重试超过1000次还没有找到合适位置，就在地图中央随便选一个格子作为富饶之地，保证功能不被无限循环卡死。这个经验可以推广到很多随机生成的场景里，比如名字生成、敌人刷新位置等，规则是：任何基于随机数的循环，都要有终局条件。
4.2 单位行动后“空气墙”问题
玩家移动单位的逻辑里，有一个很隐蔽的bug让我排查了很久：单位明明可以移动到某个格子，但在界面上点目标格子却没有反应。后来发现是坐标转换的问题——我从屏幕像素坐标转换成六边形轴向坐标时，边界条件写错了，导致某些贴着地图边缘的格子，在像素坐标计算时浮点误差累积，算出来的(q, r)既不是目标格子也不是邻格，于是判定“目标不可达”。
定位这个问题时，我打了一大堆console.log，把每个像素坐标转出来的格子坐标打印出来才发现的。这里给大家一个经验：碰到坐标换算类bug，别猜，直接打印关键转换前后的所有数据。比如记录鼠标点击的屏幕坐标、计算出来的(q, r)、目标格子的地图索引，三者对比，问题一下就能暴露。
4.3 事件选项点击无效的DOM事件问题
还有一个交互上的坑，差点让我怀疑人生：事件弹窗里的选项按钮，点击后有时候生效、有时候不生效。后来发现是因为我在渲染弹窗时，把一个全屏遮罩放在按钮上面，导致点击被遮罩拦截了。这种问题特别隐蔽，因为页面看起来完全正常，按钮也确实显示了，但实际点击落在了透明的遮罩层上。
排查的方法也很简单，打开浏览器的开发者工具，选中元素，在控制台里输入document.elementFromPoint(x, y)，看那个坐标返回的元素到底是什么。最后我把遮罩层的pointer-events: none专门设置在事件弹窗之外的区域，问题立刻消失。这个经验提醒我：所有覆盖型的UI遮罩，都要在布局时想清楚哪些区域需要接收点击，哪些纯粹是视觉遮挡。
4.4 性能排查：一局玩久了之后变卡
游戏运行到后期，一个明显问题是地图区域越大、单位越多，每一回合的结算耗时越长。我用Chrome的Performance面板看了一下，发现性能最耗时的其实是渲染函数里的一行代码——每次重绘时都对所有格子做了完整的状态检查，包括相邻关系、拥有者判断、资源匹配等。这在早期格子少的时候根本不是问题，但后期几百个格子确实会拖垮帧率。
优化的思路是空间换时间：我给每个格子加了一个tileVersion字段，只有在格子的数据真正发生变化时自增，渲染函数检查到这个字段没变就直接跳过重绘。这个简单的缓存机制把渲染开销降到了一个稳定的水平。如果你继续扩展项目，还可以进一步用分块渲染，只有地图中心附近的格子才参与绘制，远处区域等待滚动到视野内再渲染。但那个复杂度对当前项目来说没必要。
5. 扩展方向与我的实操体会
5.1 从“能玩”到“好玩”的几步进阶
这个最小可玩版本做完之后，真正让它从“能玩”过渡到“好玩”的，往往不是更复杂的系统，而是几处小改动。我给项目加过两个扩展功能，效果出奇的好。第一个是文明的专属特性，比如某个文明单位移动速度加一，另一个文明的建筑成本减半。这个改动只需要在玩家对象里加一个modifiers字段，再在结算时判断即可，代码量不大，但立刻让选择不同文明有了全新的体验。
第二个扩展是胜利条件选择。原版游戏只支持“消灭所有对手”的征服胜利，很容易让前期发展型玩家觉得挫败。我后来加入了“奇观胜利”：在一局游戏中集齐五张特定的历史奇观卡就算获胜。这个改动的实现更是简单——每触发一个特定事件时，给玩家的奇观进度加一，达到条件时弹出胜利横幅。但它带来的策略维度变化很大，有一部分玩家甚至完全转入“种田流”了。
5.2 后续还可以怎么继续深化
如果你打算把这个项目继续做深，我建议按这几个方向选一个深入下去：第一，完善事件系统，加入事件链（一个事件的选择会影响几十回合后另一个事件的触发）；第二，改进AI，使用简单的启发式搜索，让AI不只看当前回合，还能预估两回合后的收益；第三，数据驱动的建筑树，把建筑的解锁顺序做成配置文件，而不是写死在代码里。
其中事件链系统是我认为性价比最高的扩展方向。实现方式其实不难：在事件对象里加一个unlockEventId字段，当某个事件触发后，把新的候选事件加入事件池。这样玩家做的每个决策，都能在未来产生回响，那种“原来当初选择是为了今天”的感受非常强烈，也是“史诗长歌”这个名字真正想要追寻的效果。
5.3 个人实操经验总结
在做这个项目的整个过程中，我最大的体会有两点。第一点是：策略游戏的乐趣来源，不在于表现层有多炫酷，而在于规则之间相互牵制的张力。食物、金币、行动点、地块、事件，每一个数值都不是孤立存在的，玩家每一次操作都围绕着一个取舍展开，这种取舍才让游戏有了“策略感”。第二点是：做学习项目，永远先做最小可玩版本，不要追求一步到位。我最初列了一个超长的功能清单，如果按照那个清单去实现，这个项目大概半年都完成不了。但当我砍掉大部分功能，只保留核心循环后，一个周末就做出了第一版能跑起来的游戏，而这种“能跑”的成就感本身就是继续做下去的最大动力。
如果你也想做一款自己的游戏，不用想得太宏大，就拿这个《万国纪·史诗长歌》的框架去改，把你的创意往这些规则里套，哪怕是换皮、改数值，你都会发现游戏设计这件事变得触手可及。多试几局，你一定会找到属于自己的乐趣。
