C++用EGE图形库从零开发恐龙跳跃游戏

作为常年和各种窗口库、图形库打交道的C++开发者，我很清楚这类小游戏在练手和课程设计里有多受欢迎。这次要和大家聊的，是使用EGE19.01这个功能相对精简、但完全够用的图形库，从零手写一个恐龙跳跃游戏的全过程。项目版本号标的是V0.00，说明这就是一个跑通核心玩法的初版，不涉及复杂的菜单、特效或存档系统，核心就是把“跳起来躲障碍”这一套逻辑用图形方式在窗口里跑顺。

我们平时用浏览器断网时，经常玩Chrome那只小恐龙。它的核心规则非常简单：地面自动向左滚动，恐龙长期处于奔跑状态，遇到仙人掌或飞鸟时按空格或者点击屏幕触发跳跃，成功闪过就继续跑，撞上就Game Over。这种游戏看起来是个小东西，但真正用C++去实现时，会涉及到键盘输入响应、帧循环、精灵状态机、碰撞检测边界、随机障碍物生成、分数累计等一堆基础而关键的模块。用EGE来承载这些逻辑，既能获得可视化的实时反馈，又不会像SDL或SFML那样引入过多的概念负担，特别适合正在学C++语法、刚接触图形界面编程的同学。

这篇文章不仅仅是给出一份完整代码，我会把设计思路、为什么这样拆模块、每个核心环节的细节处理和踩过的坑也一并讲清楚。无论你是刚学完C++基础语法、首次接触EGE图形库的新手，还是已经在学校做过控制台小项目、想尝试把逻辑搬到图形窗口里的进阶学习者，这篇文章都能帮你少走一些弯路。

1. 项目需求拆解与EGE方案选型

1.1 恐龙跳跃游戏的核心玩法定义

动手写代码之前，先得把“什么叫做完成了一个恐龙跳跃游戏”这件事定义清楚。不是有一张图在那里跑就叫完成，而是必须把完整的交互闭环跑通。我拆出来的最低限度功能项是这个样子：

• 一个持续滚动的游戏场景，至少能看到地面、恐龙、障碍物三类元素。
• 恐龙处于自动奔跑状态，不需要玩家控制左右移动，只响应“跳跃”这一种操作。
• 障碍物从右侧随机出现，向左移动给玩家一种恐龙在向右跑的错觉。
• 当恐龙跳跃并越过障碍物时，分数持续累计。
• 当恐龙与障碍物发生碰撞时，游戏结束，并能通过按键重新开始。

再往下拆，这些功能落到实现层面，就需要解决几个关键问题：窗口如何初始化、图形如何绘制、帧循环如何驱动、键盘按键怎么不卡顿地响应、随机障碍物怎样生成才合理、碰撞判断怎么做到不“误伤”、分数怎么实时显示。把这七个问题解决掉，一个V0.00版本的恐龙跳跃游戏就已经成型了。

1.2 为什么用EGE19.01而不是SDL或Win32 API

有些同学可能会疑惑，现在做跨平台游戏都喜欢用Unity、Godot，再不济用SDL，为什么我偏偏要选一个看起来有些年头的EGE库？原因其实很实际：EGE是专门给国内C/C++学习者设计的简易绘图库，API风格极其简单。它脱胎于Borland C++时代的BGI图形库思路，用起来就是initgraph开窗口、line画直线、rectangle画方块、getch读按键这种直观操作。

对比Win32 API直接写窗口过程函数，EGE屏蔽了消息循环、窗口类注册、设备上下文管理这些Windows底层细节。对于目标是“验证C++语法理解、快速看到图形效果”的学生来说，Win32那一套需要的前置知识太多了，容易把精力耗在与游戏逻辑无关的窗口系统上。对比SDL，EGE不需要额外配置外部依赖库的加载路径，解压一个压缩包、把include和lib路径指过去，在VS或者Dev-C++里配置一次，编译就能运行，这点对新手非常友好。

把EGE19.01称为一个“轮子”，我觉得定位特别准确。它提供的是最基础的图形绘制和输入响应能力，而不是一套完整的游戏引擎。没有精灵表、没有物理引擎、没有场景树，这些都需要你自己用C++逻辑去填充。恰恰是这种“不完整”，反而给学习提供了极大的空间。你能在实现过程中理解一个游戏的骨架是如何搭建的，而不是只会在引擎里拖拽资源。

1.3 版本与开发环境的前置准备

正式开始编码前，需要先把EGE19.01环境准备好。我使用的组合是Visual Studio 2019社区版，加上从EGE官网下载的19.01版本完整包。EGE19.01这个包自带安装脚本，但它本质上就是帮你配置好头文件路径、附加库路径和连接选项。

如果你是自己手动配置，流程大致是：解压EGE压缩包，把其中的include目录下所有头文件路径放到项目配置里的“C/C++ -> 常规 -> 附加包含目录”，把lib目录下对应编译器版本的静态库路径放到“链接器 -> 常规 -> 附加库目录”。这里要特别留意分清楚x86和x64版本，EGE19.01在Visual Studio下使用Debug模式时，通常需要和工程的平台目标一致，否则链接阶段会出现LNK2019无法解析的外部符号错误。这个错误是新手最容易遇到的问题，根因往往是库选错了平台版本，或者工程是32位、库是64位。

V00这个版本编号也说明，初期并不需要把代码写得很宏大。我建议代码划分成三个文件：一个main.cpp作为程序入口和游戏主循环，一个GameLogic.cpp处理恐龙动作和碰撞，一个Obstacle.cpp管理障碍物实体。如果你还不习惯多文件工程，先写成单个main.cpp也能跑通，但多文件的工程结构在后期维护时会舒服得多。

2. 构建EGE窗口与游戏主循环

2.1 初始化图形窗口的基本写法

用EGE创建一个窗口，代码比大多数人想象的还要简单。我在main函数开头写的是这四行：

cpp复制#include <graphics.h>

int main()
{
    initgraph(800, 400);
    setbkcolor(WHITE);
    cleardevice();
    // 游戏循环...
    closegraph();
    return 0;
}

initgraph(800, 400)表示创建一个800像素宽、400像素高的窗口。这里选择800x400并非随意定的大小，而是参考了恐龙游戏常见的屏幕比例，既能让障碍物从右侧提前出现，又不会让窗口占满整个屏幕。setbkcolor(WHITE)设置背景色为白色，这也符合原版恐龙游戏白底黑边的风格。cleardevice()使用当前背景色填充整个窗口，这一步如果不做，你可能会看到窗口上残留上一次绘制的图像残留。

2.2 帧循环与游戏循环的分工

游戏循环本质上是一个无限循环，每次循环处理三件事：读取输入、更新游戏状态、绘制当前画面。我管这个叫渲染帧。在EGE里，用while循环加Sleep就能实现简单的帧率控制。

cpp复制while (true)
{
    // 处理输入
    // 更新逻辑
    // 绘制画面
    Sleep(16);   // 约60帧每秒
}

Sleep(16)是毫米级别的延时，16毫秒对应每秒60帧上下。这里有一个重要的概念叫帧率控制，如果不延时，循环会占用接近满CPU，而且游戏速度会失去控制。加了这个延时后，即使逻辑简单，画面也不会闪得那么厉害。当然，更专业的做法是用EGE自带的帧率同步函数delay_fps(60)，它会自动计算每帧需要等待的时间，比手动Sleep更准确。

从实操角度，我建议在主循环里加一个简单的帧计数器，用来辅助调试。每累计60帧就输出一次当前帧率到控制台或窗体标题，可以快速判断逻辑是不是拖慢了渲染速度。在V0.00版本里不需要过度优化性能，但保留调试输出是个好习惯。

2.3 双缓冲绘图避免画面闪烁

写图形程序时，画面闪烁是绕不开的痛点。这是因为每次绘制都直接操作显存，绘制过程中用户能看到“擦除—重画”的中间状态。EGE19.01提供了双缓冲方案来解决这个问题，核心代码是BeginBatchDraw()和EndBatchDraw()的组合。

cpp复制BeginBatchDraw();
while (true)
{
    cleardevice();
    // 绘制地面、恐龙、障碍物、分数
    FlushBatchDraw();
    delay_fps(60);
}
EndBatchDraw();

BeginBatchDraw()开启批量绘图模式，之后所有的绘制操作都被写入内存缓冲区而不是直接上交屏幕。每次循环结束时调用FlushBatchDraw()，把整块缓冲区一次性刷到屏幕上。这样用户看到的总是完整的画面，视觉体验会舒服很多。

我个人的习惯是，把cleardevice()放在循环体的最前面，配合双缓冲一起使用。每画一帧前都清空一次画布，否则上一帧的图形会残留在画布上，形成拖影。如果你在一个位置画了恐龙又移动到另一个位置，不清屏的话恐龙轨迹会连成一片。这个原理和翻页动画是一样的，清屏就是翻新一页纸，绘制则是在新页上重新作画。

3. 恐龙跳跃逻辑与碰撞检测的实现

3.1 恐龙模型的坐标与状态设计

V0.00版本中，我不打算引入精灵图片，直接用EGE的rectangle函数绘制方块恐龙，这样可以把注意力集中在游戏逻辑上。恐龙在游戏窗口中的坐标采用矩形包围盒方式定义，包含左上角x、左上角y、宽度、高度四个关键信息。

cpp复制struct Dino
{
    int x;      // 恐龙左上角x坐标
    int y;      // 恐龙左上角y坐标
    int width;
    int height;
    int vy;     // 垂直速度，正值为向上
    bool jumping;
};

恐龙初始位置在窗口左侧大约100像素处。地面是窗口底部一条水平高线，我给地面的高度定为80像素，那么恐龙的初始y值等于WINDOW_HEIGHT - GROUND_HEIGHT - DINO_HEIGHT，也就是让恐龙稳稳站在地面上。这个计算方式新手经常算错，我特地在代码注释里标清楚，避免每次重启窗口都花时间调坐标。

恐龙跳跃存在两个状态：在地面上和在空中。这两个状态用jumping布尔值标记。只有在地面状态时，玩家按空格才能触发跳跃，这种限制可以有效避免玩家在空中连续按跳跃导致角色“二段跳”的bug。真实的物理引擎要考虑加速度和空气阻力，V0.00版本用简化的速度模型就够了。

3.2 重力模拟与跳跃抛物线

跳跃的核心是给恐龙一个向上的初速度，然后让重力把它拉回地面。每次循环里，更新恐龙垂直坐标的方式是：y += vy，然后vy += GRAVITY。这两个公式就是经典的运动学模拟。我这里用一个具体的数值示例展示重力计算过程：

假设恐龙初始vy = -10，GRAVITY = 0.8，地面y = 260。第1帧时恐龙y得到-10的增量向上移动10个像素；之后vy加上重力变为-9.2；第2帧恐龙又向上移动9.2像素。随着vy不断累加，恐龙上升速度逐渐减小，当vy变为正数时，恐龙开始下落。落地后检查y >= GROUND_Y，就把y固定到地面高度，vy归零，jumping重置为false。

这个模型和现实中的抛物线运动一致，但实现起来非常简单。我在实测中调节的参数组合是初始vy = -15、GRAVITY = 0.6。这个组合在地面高度260像素、窗口400像素的条件下，跳起的最高点大约在170像素处，刚好可以越过一个高度为60像素的障碍物，又不会高到飞出窗口上边界。如果你改成不同的窗口大小或障碍物高度，这两个数值需要重新试验调整，不要直接照抄。

3.3 AABB碰撞检测的原理与边界压缩

恐龙和障碍物都是矩形，判断它们是否碰撞最直接的方法是AABB（Axis-Aligned Bounding Box，轴对齐包围盒）检测。两个矩形如果存在重叠区域，则判定碰撞，原理可以用四个不等式描述：恐龙右边界大于障碍物左边界、恐龙左边界小于障碍物右边界、恐龙下边界大于障碍物上边界、恐龙上边界小于障碍物下边界。

cpp复制bool isHit(int x1, int y1, int w1, int h1, int x2, int y2, int w2, int h2)
{
    return (x1 < x2 + w2 && x1 + w1 > x2 && y1 < y2 + h2 && y1 + h1 > y2);
}

这个判断函数是我项目里复用率最高的代码段，堪称整个碰撞系统的地基。需要特别提醒的是边界情况：当两个矩形刚好“擦边”，比如恐龙右边界等于障碍物左边界时，严格来说不算碰撞，但如果精确重叠判定，玩家会觉得难度偏大。我做的调整是碰撞边界压缩，即给恐龙和障碍物各留出一小段“容错边距”，这样从视觉上看起来碰撞了，但实际判定没有算作命中。

cpp复制// 实际碰撞检测使用缩小后的矩形
int shrinkSize = 4;
bool hit = isHit(
    dino.x + shrinkSize,
    dino.y + shrinkSize,
    dino.width - shrinkSize * 2,
    dino.height - shrinkSize * 2,
    obstacle.x + shrinkSize,
    obstacle.y + shrinkSize,
    obstacle.width - shrinkSize * 2,
    obstacle.height - shrinkSize * 2
);

这个4像素的缩小值是我在多次试玩后确定下来的。如果缩得太少，有些视觉上明显没碰到的擦肩而过也被算作撞车，会让玩家觉得瞥一眼就死了，容易产生挫败感；如果缩得太多，视觉上已经明显重叠了但游戏还在继续，会很出戏。你可以根据自己的手感调整，这是游戏调优里很重要的一环。

3.4 键盘响应与跳跃灵敏度

EGE库读取按键消息有两种常用方式：kbhit() + getch()组合，或者EGE扩展消息函数keystate。对于单一空格键触发的游戏，kbhit就够用了。

cpp复制if (kbhit())
{
    int key = getch();
    if (key == ' ')   // 空格键对应ASCII码32
    {
        if (!dino.jumping)
        {
            dino.vy = -15;
            dino.jumping = true;
        }
    }
}

这里有个小坑必须讲清楚。getch()读取普通ASCII字符时，返回的是该字符的ASCII码。但如果你按下的是方向键、功能键，getch()会先返回一个0或224的特殊前缀，需要再调用一次getch()才能取到真正的键值。我做第一个版本时，想用方向键上键跳跃，直接在getch()里判断72，结果按键完全没反应，排查了很久才发现是这个原因。

如果你确实想用方向键控制，可以这样处理：

cpp复制int key = getch();
if (key == 224)   // 特殊键前缀
{
    key = getch();
    if (key == 72) // 上方向键
    {
        // 触发跳跃
    }
}

不过在V0.00版本里，我建议先用空格键。原因很简单：空格键的处理流程更简单，不容易踩坑，而且真实桌面恐龙游戏的基本操作就是空格和点击鼠标。跑通核心逻辑后再去扩展其他按键映射，难度会低很多。

4. 障碍物随机生成与计分逻辑

4.1 障碍物的结构定义与屏幕滚动效果

障碍物的本质和恐龙类似，也是一个会移动的矩形。但障碍物有一个显著特征：它会持续向左移动，移出屏幕左侧边界后就变得无用，需要从屏幕右侧重新生成。为了处理可能同时存在多个障碍物的情况，我在V0.00版本里用的是固定数组存储方式：

cpp复制#define MAX_OBSTACLES 5

struct Obstacle
{
    int x;
    int y;
    int width;
    int height;
    bool active;
};

Obstacle obstacles[MAX_OBSTACLES];

为什么用数组而不是C++标准库的vector动态容器？一方面是EGE19.01时代，很多初学者还在使用C++98风格，数组更直观；另一方面，固定数组可以避免动态内存分配带来的潜在性能抖动。限制最多5个障碍物同时存在，对于这款游戏来说足够用了。

初始化时，我把数组里所有障碍物的active设为false，表示当前都没有启用。游戏过程中，每一个active为false的槽位都可以用来创建新的障碍物。当障碍物的x + width小于0时，说明已经彻底移出屏幕左侧，我立即把它的active置回false，腾出槽位。

4.2 随机生成逻辑与可行性筛选

障碍物的生成时机非常关键。生成频率太高，玩家没有反应时间；太低，游戏显得无聊。我用两种约束来控制生成节奏：距离约束和位置约束。

距离约束是指，新生成的障碍物与上一个障碍物的水平间隔要在300到600像素之间，这样能保证玩家有足够的跳跃空间。我用rand()生成随机数，映射到区间内。

cpp复制int interval = 300 + rand() % 300;

位置约束是指，新障碍物统一从窗口右边界之外出现，即obstacles[i].x = WINDOW_WIDTH;。每帧让所有active障碍物的x -= speed，speed是障碍物向左移动的像素值。这样一个接一个从右侧出现的视觉效果，就是“恐龙在向前跑”的经典体验。

这里还要讨论一个常见错误：rand()函数的种子问题。如果不设置srand((unsigned)time(NULL))，程序每次启动时生成的随机序列都是相同的，玩起来障碍物的出现顺序会一模一样，会让人觉得特别假。设置时间种子后，每次启动游戏都能得到不同的随机序列，这是新手经常漏掉的细节。

4.3 不同形态障碍物的高度与生成策略

V0.00版本为了画面简单，我设计了两类障碍物：小仙人掌和大仙人掌，两者高度不同。实现方式是给Obstacle结构增加一个类型字段：

cpp复制enum ObstacleType { SMALL_CACTUS, TALL_CACTUS };

生成时用rand() % 2决定类型。小仙人掌的长宽大概是20x40，高的仙人掌是20x70。由于恐龙在默认地面上奔跑，生成障碍物时y坐标是固定的：obstacle.y = GROUND_Y - obstacle.height，也就是让障碍物底部与地面平齐。这个设计能保证玩家面对的挑战统一，而且视觉上更协调。

固定障碍物高度还有另一个好处，就是跳跃高度和速度调参变得有据可依。我在3.2节里把跳跃峰值定在170像素，就是因为窗口高度减去地面高度后，高仙人掌的70像素高度加上4像素碰撞容错，要通过这个障碍至少需要跳到地面以上大约80像素。留出150像素以上的跳跃高度余量，玩家操作容错率能保持在比较舒适的区域。

4.4 计分与速度递增机制

恐龙游戏的分数本质上可以理解为奔跑距离，跑得越远分数越高。最简单直接的计分方式是每经过一帧加一分，因为帧率基本固定，所以分数就近似代表存活时间。在屏幕上显示分数的方式也很简单：

cpp复制char scoreText[32];
sprintf(scoreText, "SCORE: %d", score);
setcolor(BLACK);
setbkmode(TRANSPARENT);
outtextxy(20, 20, scoreText);

注意setbkmode(TRANSPARENT)这一项很关键。EGE默认的文字背景是OPAQUE不透明模式，如果不改成透明模式，每次绘制分数时后面会带一个矩形色块，不断叠加后会弄脏整个画面顶部区域。

随着分数增长，功能上应当做加速。我采用的是阈值触发方式：当score每超过500分，speed增加1像素。设初始speed = 5，最大速度限制在15，避免速度过快导致玩家根本没有反应时间。有了速度递增，游戏难度就有了曲线，玩家会明显在一段时间后感觉比之前更需要提前跳跃，这种张力就是游戏吸引人反复尝试的核心。

5. 图形绘制、状态控制与代码调试经验

5.1 EGE绘图API的常用组合

EGE的绘图API确实很贴心，基本图形都能直接画。恐龙跳跃游戏初版涉及的绘制主要包括：地面、恐龙、障碍物、分数。地面可以用一条水平粗线或一个矩形表示。恐龙和障碍物用rectangle加fillrectangle组合画填充矩形。

cpp复制// 绘制地面
setfillcolor(RGB(150, 150, 150));
bar(0, GROUND_Y, WINDOW_WIDTH, GROUND_Y + 4);

// 绘制恐龙
setfillcolor(RGB(0, 0, 0));
bar(dino.x, dino.y, dino.x + dino.width, dino.y + dino.height);

bar函数可以画实心矩形，它需要左上和右下两个坐标点。这个函数比fillrectangle更简洁，因为fillrectangle还要配合setfillstyle设置填充样式。在实际项目里我用的是bar，代码量和出错率都更少。恐龙如果只画一个方块确实有点枯燥，但V0.00阶段不要贪多。等核心逻辑稳定后，可以使用loadimage加载外部PNG图片，并用putimage把它绘制到恐龙坐标处，视觉表现会好很多。只是要注意图片透明度的处理，这与EGE的图片掩码机制有关，属于进阶话题。

5.2 游戏状态流与碰撞后重新开始

一个完整的游戏循环里必然有状态转换。我设计了三个状态：READY（待机）、RUNNING（奔跑中）、GAMEOVER（结束）。主循环中根据状态执行不同逻辑，这样代码不会乱成一团。

cpp复制enum GameState { READY, RUNNING, GAMEOVER };

if (gameState == RUNNING)
{
    // 更新恐龙位置
    // 更新障碍物位置
    // 检测碰撞
}
else if (gameState == GAMEOVER)
{
    // 绘制游戏结束画面
    // 等待按键重新开始
}

初始进入游戏时，我让游戏先停在READY状态，并在屏幕上显示“Press Space to Start”。玩家按空格后切到RUNNING，恐龙才开始跳跃。碰撞命中后切到GAMEOVER，屏幕上显示“Game Over!”和最终分数，此时按任意键复位恐龙位置、清空障碍物、分数归零，再切回RUNNING状态。这种简单的状态机，是游戏开发里最基础也最稳定的设计模式。

重置函数务必把所有带状态的变量都恢复初始值，只重置坐标还不够，跳跃速度、障碍物计数、active状态、速度值都要一并重置，否则会出现“复活的恐龙还在空中”这类怪问题。这个坑我踩过一次之后，就养成了写resetGame()函数的习惯，核心状态一次性统一初始化。

5.3 多文件编译与链接易错点

在Visual Studio里创建EGE多文件工程时，有一些容易疏忽的地方。第一是#include <graphics.h>的位置，EGE要求graphics.h必须在windows.h之前包含，如果反了会出现大量重定义报错。第二是预处理器定义，Windows下配合EGE使用时常需要定义_WIN32_WINNT宏，否则某些Windows API版本相关的接口可能不可用，尤其在使用较新Windows SDK时容易遇到。

如果你使用的是Visual Studio做工程，建议在“项目属性 -> 预处理器定义”里加上_CRT_SECURE_NO_WARNINGS，否则sprintf这类老牌C函数会被编译器报C4996安全警告，虽不影响编译，但会刷屏，新手容易误以为是错误。这个问题在VS2015之后的版本特别常见，提前设置能省很多麻烦。

注意main函数的写法。EGE的入口函数与普通控制台程序有细微差别，建议把main声明为int main()而不要无参返回值，并且确保主循环结束后调用closegraph()释放图形资源。否则会有图形窗口无法关闭或GDI资源泄漏的隐患。

5.4 实际调试中排掉的常见障碍

我在完成V0.00版本的过程中，遇到最典型的三类问题，以及对应的查找方法，有比较高的参考价值。

第一类是窗口不断闪烁。出现这种情况，我先检查有没有BeginBatchDraw，如果没有就立刻加上。如果加了还闪，检查是否在每次FlushBatchDraw前连续调用多次cleardevice，这种重复清空会造成无意义的空白帧。

第二类是恐龙跳不起来。按键有反应但恐龙不上升，检查vy方向和符号。坐标系的y轴是向下为正，从屏幕上方到下方y值增大，那么向上跳跃必须给vy负值。我在初版代码里把跳跃速度写成了正数，导致恐龙瞬间向下“砸地”。这个错误非常普遍，定位时直接看vy更新语句的符号就行。

第三类是障碍物从屏幕出来后一片错乱。这往往是因为数组里多个active障碍物的x坐标重叠了。问题通常出在生成逻辑上，我没有检查“当前数组中是否已有活跃障碍物”就直接创建新的。修复方法是：每次生成前遍历数组，确保生成间隔有效，并且新生成位置不小于已有障碍物的右侧位置加上最小间隔。

6. 运行效果展示与后续设想

把代码写完、调试稳定后，实际运行效果其实挺让人有成就感的。白色天空背景下，一只黑色小方块恐龙在棕色地面上奔跑，时不时遇到高矮不一的仙人掌方块，按空格起跳、落地、再跳，上方实时跳动的SCORE数字逐渐变大，速度越来越快，最后躲闪不及撞上障碍物，画面转入Game Over状态。整个过程虽然朴素，但该有的紧张感、节奏感和反馈感都有了。

框架搭完之后，后续扩展的方向很清晰。我可以把恐龙奔跑状态做成两帧动画：腿张开的形状和腿闭合的形状交替显示，模拟奔跑的腿。障碍物可以加入飞鸟类型，飞鸟在空中飞行，意味着玩家不但要控制跳跃的时机，还要判断“现在跳会不会撞到天上的东西”，难度维度会从一维变成二维。再往后，可以在窗口顶部加入分数最高纪录的持久化存储，用文件读写的方式把最高分保存到本地，这样玩几次之后还会产生更持续的挑战动力。

如果在这条路上继续深入，可以尝试把渲染部分替换成更低层的GDI接口，或者引入一个简单的ECS框架来管理游戏对象，体会一下架构设计的不同。不过这些都是后话了，V0.00版本先把一个可玩、清爽、稳定的闭环做出来，就是最扎实的起点。

我给这个项目打一个自己的体验总结：用EGE19.01做一个恐龙跳跃游戏，最大的收获不是学会了某个高深API，而是第一次完整经历了“定义问题—设计模块—编码实现—调试修复—调优体验”的闭环。这个思维路径，在之后做任何规模的项目里都是通用的。按照这个思路把代码跑起来，你得到的会是一个能拿得出手的作品，也是一个很能说明C++基础运用能力的练手项目。