Visual C++ RPG开发实战：从Win32 API到游戏循环的底层原理剖析

1. 项目概述为什么选择Visual C做RPG如果你是一个从Windows XP时代就开始摸电脑的老玩家或者是一个对游戏开发底层有执念的开发者看到“Visual C”和“角色扮演游戏”这两个词组合在一起大概率会心头一热。这感觉就像在数字博物馆里看到了一台还能运行的CRT显示器充满了复古的硬核魅力。今天我们就来彻底拆解这个项目不光是看代码怎么跑更要弄明白在Unity、Unreal Engine 5大行其道的今天为什么还要回头去啃Visual C这块“硬骨头”以及如何通过一个完整的源码实战项目真正吃透游戏开发的核心原理。首先得明确这个项目不是一个教你用最新引擎快速拼装一个游戏的教程。它的核心价值在于“透视”和“掌控”。Visual C特别是经典的VC6到VS2019这一脉是Windows平台原生开发的基石。通过它来开发一个角色扮演游戏RPG意味着你将直面Win32 API、GDI/GDI或早期的DirectDraw/Direct3D、消息循环、资源管理这些最底层的机制。这就像学汽车维修你不是去学怎么用电脑诊断仪读故障码而是真的拿起扳手拆开发动机搞清楚每一个气缸、每一根凸轮轴是怎么协同工作的。这个过程痛苦吗确实。但一旦你走通了你对“一个游戏程序究竟是如何在操作系统上跑起来的”会有一种豁然开朗的理解这种理解是使用高级引擎很难获得的。那么这个“全书源码实战”项目具体能带给我们什么它解决的绝不仅仅是“如何用C写一个游戏”的问题更深层的是以下几个痛点第一理解游戏循环的本质。现代引擎把游戏循环Game Loop封装得非常好以至于很多开发者只知道Update()和Render()却不清楚消息泵Message Pump如何与循环结合如何精确控制帧率。第二掌握资源管理的艺术。从磁盘加载一张位图Bitmap、一段WAV音频到内存中管理它们处理释放和缓存这比在Unity里拖一个Sprite或AudioClip要复杂得多但也让你对性能开销有切肤之痛。第三构建可维护的游戏架构。在没有现成的Entity-Component-SystemECS框架的情况下如何用面向对象思想设计角色、物品、地图、战斗系统并让它们高效地通信这是对软件设计能力的绝佳锻炼。第四深度调试与问题排查能力。你将频繁使用Visual Studio的调试器去追踪内存泄漏、图形渲染错误、逻辑BUG这种能力是通用的价值远超某个特定引擎。所以这个项目适合谁它最适合两类人一是对游戏开发有浓厚兴趣不满足于黑盒使用引擎渴望理解计算机图形学、实时系统底层原理的“刨根问底派”二是已有一定C/C基础想通过一个综合性、有趣味性的项目来巩固和提升编程、架构设计能力的实践者。如果你只想要最快做出一个能玩的游戏那现代游戏引擎是更好的选择。但如果你想成为那个能造引擎或者能对引擎进行深度定制和优化的人那么这趟“复古”之旅将是你技术栈里不可或缺的一块厚重基石。2. 核心架构与设计思路拆解一个基于Visual C的RPG其架构与现代游戏引擎项目有显著不同。它更像是在用原始的工具从零搭建一座房子。我们需要先画好蓝图搞清楚各个“房间”模块的功能和连接方式。2.1 技术选型为什么是Win32 API GDI在图形渲染方面这个级别的实战项目通常不会一上来就使用复杂的Direct3D或OpenGL。GDIGraphics Device Interface是更常见和实用的起点。原因有三其一学习曲线平缓。GDI的API相对直接用于绘制2D图形、文本和位图足够能让开发者快速聚焦于游戏逻辑本身而不是复杂的图形管线。其二依赖极简。它是Windows操作系统的一部分无需额外安装运行时库除了Visual C运行库项目移植和分享非常简单。其三有助于理解核心概念。通过GDI你能深刻理解设备上下文DC、双缓冲Double Buffering消除闪烁、坐标变换等基础但至关重要的图形概念这些知识是通向DirectX/OpenGL的必经之路。对于输入处理我们依赖Win32消息机制。键盘的WM_KEYDOWN/WM_KEYUP鼠标的WM_MOUSEMOVE、WM_LBUTTONDOWN这些都是需要你在窗口过程中WndProc手动捕获和处理的。这种看似“原始”的方式让你对事件驱动的游戏输入有了最本质的认识。音频播放则可能使用老牌的PlaySound()API或更灵活的DirectSound仍属于DirectX的较简单部分。资源管理如图片、地图数据通常采用自定义的二进制文件格式或简单的文本格式如.ini、自定义的.map由程序在启动时加载到内存中的特定数据结构里。2.2 核心模块划分与数据流设计一个典型的RPG源码项目其核心模块可以划分为以下几大块应用程序框架模块这是游戏的“发动机”。它负责创建主窗口、建立消息循环、驱动游戏主循环。主循环的核心逻辑通常是处理消息 - 更新游戏状态逻辑帧- 渲染当前帧渲染帧- 控制帧间隔以稳定帧率。这里的一个关键设计是将逻辑更新与渲染绘制分离即使因为复杂计算导致某一逻辑帧变慢也可以通过插值等方式保证渲染的平滑这是很多早期游戏保持流畅的秘诀。图形渲染模块基于GDI这个模块要提供一套简单的精灵Sprite系统。功能包括从文件加载位图资源、创建内存位图用于离屏渲染双缓冲、实现精灵的绘制支持透明色早期常用洋红色RGB(255,0,255)作为透明通道、地图的拼接绘制TileMap、以及简单的摄像机Viewport系统用来控制游戏世界哪一部分显示在屏幕上。资源管理模块这是游戏的“仓库”。它需要以高效、统一的方式管理所有外部资源。通常会设计一个ResourceManager单例或静态类。其内部可能维护着几个std::map或哈希表键是资源ID或路径值是指向加载好的位图、声音、字体数据的指针或智能指针。这个模块要负责资源的加载、缓存避免重复加载、以及程序退出时的统一释放是防止内存泄漏的重点区域。游戏对象与逻辑模块这是游戏的“大脑”和“演员”。采用面向对象的设计会有基类GameObject然后派生出Player玩家角色、NPC非玩家角色、Enemy敌人、Item物品等。每个对象有自己的位置、状态如生命值、魔法值、行为逻辑AI状态机。地图GameMap本身也是一个重要的逻辑对象管理着网格Cell信息、碰撞层、事件触发点等。战斗系统、对话系统、任务系统都会作为独立的子系统与游戏对象进行交互。数据与配置模块游戏的平衡性、内容如怪物属性、物品效果、对话文本不应该硬编码在程序里。这个模块负责从外部文件如XML、JSON或自定义格式读取这些数据并在运行时提供给逻辑模块使用。这极大地提高了游戏的可修改性和可扩展性。数据流大致是这样的用户输入键盘/鼠标通过Windows消息被应用程序框架捕获转化为自定义的输入事件传递给游戏逻辑模块。逻辑模块更新所有游戏对象的状态位置、AI决策、碰撞检测等并可能触发战斗、对话等事件。渲染模块则根据当前游戏对象和地图的状态向一个离屏的设备上下文内存DC绘制每一帧最后一次性贴到窗口DC上显示出来。资源管理模块在后台为渲染和逻辑模块提供所需的数据支持。3. 关键实现细节与核心代码剖析理解了架构我们深入到代码层面看看几个最关键的环节是如何实现的。这里会结合一些典型的代码片段以现代C风格示意但保留Win32 API的调用方式进行讲解。3.1 Win32窗口创建与消息循环的“现代”封装直接使用原始的WinMain和WndProc会显得冗长且不易管理。一个好的实战项目通常会对其进行轻量级封装。// GameApp.h - 应用程序类封装 class GameApp { public: static GameApp* GetInstance(); bool Initialize(HINSTANCE hInstance, int nCmdShow); int Run(); void Shutdown(); HINSTANCE GetAppInstance() const { return m_hInstance; } HWND GetMainWnd() const { return m_hWnd; } private: GameApp(); static LRESULT CALLBACK StaticWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam); LRESULT HandleMessage(UINT message, WPARAM wParam, LPARAM lParam); bool InitWindow(int nCmdShow); void MainLoop(); // 游戏主循环 private: HINSTANCE m_hInstance; HWND m_hWnd; std::wstring m_windowTitle; int m_windowWidth; int m_windowHeight; bool m_bRunning; // 其他模块指针如 Graphics*, Input*, GameLogic*... };在Initialize方法中会调用InitWindow来注册窗口类和创建窗口。关键在于StaticWndProc这个静态函数它作为窗口过程通过GetWindowLongPtr获取与窗口关联的GameApp实例指针然后调用其HandleMessage方法。这样就将C风格的回调与C的类成员方法关联了起来使得消息处理逻辑可以写在类内部更易于组织。游戏主循环MainLoop()是核心中的核心void GameApp::MainLoop() { MSG msg {0}; auto lastTime std::chrono::high_resolution_clock::now(); float deltaTime 0.0f; while (m_bRunning) { // 1. 处理Windows消息非阻塞 while (PeekMessage(msg, nullptr, 0, 0, PM_REMOVE)) { if (msg.message WM_QUIT) { m_bRunning false; } TranslateMessage(msg); DispatchMessage(msg); } // 2. 计算帧时间差 auto currentTime std::chrono::high_resolution_clock::now(); deltaTime std::chrono::durationfloat(currentTime - lastTime).count(); lastTime currentTime; // 3. 更新游戏逻辑固定时间步长或可变步长 m_pGameLogic-Update(deltaTime); // 4. 渲染 m_pGraphics-Render(); // 5. 控制帧率例如限制到60FPS static const float targetFrameTime 1.0f / 60.0f; float elapsed std::chrono::durationfloat( std::chrono::high_resolution_clock::now() - currentTime).count(); if (elapsed targetFrameTime) { DWORD sleepMs static_castDWORD((targetFrameTime - elapsed) * 1000); Sleep(sleepMs); } } }这个循环清晰地展示了“消息 - 更新 - 渲染”的经典流程。使用PeekMessage而非GetMessage是为了避免阻塞让循环在无消息时也能持续运行。高精度计时器的使用确保了游戏速度不受帧率波动影响。3.2 基于GDI的精灵与地图渲染系统渲染模块的核心是双缓冲和精灵绘制。// GraphicsEngine.h class GraphicsEngine { public: bool Initialize(HWND hWnd, int width, int height); void Shutdown(); void BeginFrame(); // 开始绘制一帧准备内存DC void EndFrame(); // 结束绘制将内存DC内容贴到窗口 void DrawSprite(int x, int y, HBITMAP hBitmap, COLORREF transparentColor RGB(255,0,255)); private: HWND m_hWnd; int m_width, m_height; HDC m_hdcScreen; // 屏幕DC HDC m_hdcMemory; // 内存DC用于双缓冲 HBITMAP m_hbmMemory; // 内存位图 HBITMAP m_hbmOld; // 旧位图句柄用于恢复 };BeginFrame会创建一个与窗口客户区兼容的内存DC和位图并选入内存DC。之后所有的DrawSprite等绘制操作都针对这个内存DC进行完全在内存中完成用户看不到中间过程。EndFrame时使用BitBlt函数将内存DC中的完整一帧图像一次性快速复制到屏幕DC上。这彻底解决了直接绘制到屏幕DC可能引起的闪烁问题。精灵绘制函数DrawSprite的实现要点void GraphicsEngine::DrawSprite(int destX, int destY, HBITMAP hBitmap, COLORREF transparentColor) { // 1. 获取精灵位图的尺寸 BITMAP bm; GetObject(hBitmap, sizeof(BITMAP), bm); // 2. 为精灵位图创建一个临时内存DC HDC hdcSprite CreateCompatibleDC(m_hdcMemory); SelectObject(hdcSprite, hBitmap); // 3. 使用 TransparentBlt 实现透明绘制需要Windows 98/2000以上 // 或者使用老式的“掩码”方法先绘制掩码位图AND操作再绘制彩色位图OR操作 TransparentBlt(m_hdcMemory, destX, destY, bm.bmWidth, bm.bmHeight, hdcSprite, 0, 0, bm.bmWidth, bm.bmHeight, transparentColor); // 4. 清理临时DC DeleteDC(hdcSprite); }对于地图系统TileMap通常会有一个二维数组存储地图格子的索引。渲染时根据摄像机位置计算哪些格子在视口内然后循环调用DrawSprite绘制每个格子对应的地形图块。3.3 面向对象的游戏实体与状态管理游戏逻辑的核心是实体管理。一个设计良好的GameObject基类至关重要。// GameObject.h class GameObject { public: enum class State { Idle, Moving, Attacking, Dead /*...*/ }; GameObject(int id); virtual ~GameObject() default; virtual void Update(float deltaTime); // 每帧更新 virtual void Render(HDC hdc); // 渲染自身如果需要 virtual void OnCollision(GameObject* other); // 碰撞处理 // 属性 int GetID() const { return m_id; } const Vector2 GetPosition() const { return m_position; } void SetPosition(const Vector2 pos) { m_position pos; } State GetState() const { return m_state; } protected: int m_id; Vector2 m_position; Vector2 m_velocity; State m_state; // 其他通用属性如生命值、碰撞矩形等 };Player和Enemy类继承自GameObject并重写Update方法来实现特定行为。例如Player的Update会检查输入状态来改变速度和位置Enemy的Update则可能包含一个简单的有限状态机FSM根据与玩家的距离在“巡逻”、“追击”、“攻击”等状态间切换。一个简单的敌人AI状态机示例void Enemy::Update(float deltaTime) { switch (m_aiState) { case AIState::Patrol: // 沿着固定路径移动 PatrolMovement(deltaTime); if (DistanceToPlayer() m_detectRange) { m_aiState AIState::Chase; } break; case AIState::Chase: // 向玩家位置移动 MoveTowardsPlayer(deltaTime); if (DistanceToPlayer() m_loseRange) { m_aiState AIState::Patrol; } else if (DistanceToPlayer() m_attackRange) { m_aiState AIState::Attack; } break; case AIState::Attack: // 执行攻击动作可能有冷却时间 if (m_attackCooldown 0) { PerformAttack(); m_attackCooldown ATTACK_COOLDOWN_TIME; } m_attackCooldown - deltaTime; if (DistanceToPlayer() m_attackRange) { m_aiState AIState::Chase; } break; } // 调用基类更新处理位置变化等 GameObject::Update(deltaTime); }所有游戏对象由一个GameObjectManager统一管理它负责在每帧更新所有对象处理对象间的碰撞检测如简单的AABB矩形检测以及对象的创建与销毁。4. 资源管理与数据驱动的设计硬编码的游戏内容难以维护和扩展。一个实战项目必须展示如何将游戏数据外置。4.1 统一的资源管理器// ResourceManager.h class ResourceManager { public: static ResourceManager GetInstance(); HBITMAP LoadBitmap(const std::wstring filePath, const std::string key); HBITMAP GetBitmap(const std::string key); void UnloadBitmap(const std::string key); void ClearAllBitmaps(); // 类似地可以加载声音、字体、数据文件等 private: ResourceManager() default; std::unordered_mapstd::string, std::pairHBITMAP, int m_bitmapMap; // key - (handle, refCount) };资源管理器使用引用计数来管理资源。当多个对象使用同一张图片时引用计数增加当没有对象使用时引用计数归零管理器在适当时机如关卡切换或程序退出释放资源。LoadBitmap内部使用LoadImage或GDI的Bitmap类来加载图片文件。4.2 使用JSON或XML定义游戏数据假设我们使用一个简单的JSON文件来定义敌人属性需要集成如nlohmann/json这样的库// enemies.json [ { id: 1, name: 哥布林, sprite: goblin.bmp, hp: 30, attack: 5, defense: 2, exp: 10, ai_type: melee, detect_range: 150, attack_range: 40 }, { id: 2, name: 骷髅弓箭手, sprite: skeleton_archer.bmp, hp: 25, attack: 8, defense: 1, exp: 15, ai_type: ranged, detect_range: 200, attack_range: 120 } ]在游戏初始化时DataManager会加载这个JSON文件解析并存入一个std::mapint, EnemyData结构中。当需要生成一个“哥布林”敌人实例时逻辑层只需传入ID1DataManager返回对应的EnemyData结构体Enemy对象根据这些数据初始化自己的属性。物品、技能、地图事件都可以用类似的方式管理。这种数据驱动的设计使得策划人员甚至你自己可以方便地调整游戏平衡而无需重新编译代码。5. 实战中必踩的“坑”与调试技巧用Visual C做游戏开发尤其是在没有成熟框架辅助的情况下会遇到许多现代引擎已帮你解决的问题。下面是一些典型的“坑”和解决思路。5.1 内存泄漏与资源管理这是Win32/GDI编程的头号杀手。每一个CreateDC,CreateCompatibleDC,CreateBitmap,LoadImage返回的句柄HANDLE, HDC, HBITMAP等都必须有对应的DeleteDC,DeleteObject来释放。核心技巧采用RAII资源获取即初始化思想进行封装。不要直接使用裸的句柄。为每一种资源类型如GDIBitmap,MemoryDC创建一个小型包装类在构造函数中获取资源在析构函数中释放资源。利用C的栈展开特性确保资源在任何情况下包括异常发生时都能被正确释放。class ScopedHDC { public: ScopedHDC(HDC hdc) : m_hdc(hdc) {} ~ScopedHDC() { if (m_hdc) DeleteDC(m_hdc); } operator HDC() const { return m_hdc; } // 禁止拷贝允许移动如果需要 ScopedHDC(const ScopedHDC) delete; ScopedHDC operator(const ScopedHDC) delete; private: HDC m_hdc; };使用Visual Studio内置的**“诊断工具”**窗口在调试运行时开启“内存使用率”和“GPU使用率”跟踪可以直观地看到内存是否在持续增长这是发现泄漏的快速方法。对于更精确的定位可以使用_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);在程序退出时输出内存泄漏报告到输出窗口。5.2 图形闪烁与性能瓶颈即使使用了双缓冲如果绘制操作过于频繁或复杂仍然可能感到卡顿。脏矩形更新这是2D游戏优化的经典手段。不要每一帧都重绘整个屏幕。只重绘那些内容发生变化的区域“脏矩形”。你需要维护一个脏矩形列表在每帧渲染时只对这些区域进行清除和重绘。这能极大减少BitBlt操作的数据量。精灵图集Sprite Sheet将多个小精灵图片打包到一张大位图中。绘制时通过指定源矩形来绘制大图中的某一部分。这减少了加载大量小文件的开销也使得BitBlt操作更高效因为切换选入DC的位图SelectObject是有成本的。避免在游戏主循环中进行耗时的文件I/O或复杂计算。所有资源尽量在加载关卡时预加载到内存。复杂的路径查找如A*算法等计算如果一帧内无法完成可以考虑分到多帧进行。5.3 多分辨率与窗口缩放适配你的游戏窗口可能是固定的800x600但玩家的显示器分辨率千差万别。一个健壮的系统应该能处理窗口缩放。逻辑坐标与物理坐标分离定义一套固定的游戏逻辑分辨率如800x600。所有的游戏逻辑对象位置、碰撞检测都基于这个坐标系。在渲染时根据当前窗口的实际大小计算一个缩放比例将逻辑坐标转换为物理坐标再进行绘制。这保证了游戏玩法在不同窗口大小下的一致性。GDI缩放的质量问题直接使用StretchBlt缩放位图可能会导致图像模糊或像素化。对于像素风游戏这可能不是问题甚至是风格。如果需要高质量缩放可以考虑使用GDI它提供了更好的插值模式选项但性能开销稍大。5.4 输入处理的延迟与响应Win32消息队列在处理快速连续按键时比如按住左键移动WM_KEYDOWN消息之间会有WM_CHAR等消息直接处理可能会有延迟感。使用GetAsyncKeyState函数在游戏主循环的更新阶段使用GetAsyncKeyState(VK_LEFT) 0x8000这样的方式来查询按键的实时状态而不是仅仅依赖WM_KEYDOWN消息。这能实现更即时的响应常用于角色移动等持续性的输入。可以将消息处理和实时状态查询结合用消息处理按键的按下和抬起事件用于触发一次性的动作如跳跃、攻击用GetAsyncKeyState处理持续状态如移动。5.5 音频播放的异步与混音使用简单的PlaySound播放音效时如果前一个音效还没播完后一个就会被截断。对于需要同时播放多个音效的游戏如背景音乐攻击音效受伤音效这不可接受。解决方案是使用DirectSound或更现代的XAudio2。它们提供了多声道混音的能力。在实战项目中可以封装一个简单的AudioEngine类内部使用DirectSound创建辅助缓冲区Secondary Buffer来播放每个音效由DirectSound主缓冲区Primary Buffer进行混音后输出。这涉及到COM组件的初始化和释放是另一个需要仔细处理资源管理的地方。6. 从项目源码到可执行程序构建与部署拿到一个完整的Visual C RPG项目源码后如何将它变成你能运行、甚至能分发给朋友玩的.exe文件这个过程本身也充满学问。6.1 理解Visual Studio项目结构与配置一个典型的VC项目包含.sln解决方案文件和.vcxproj项目文件。你需要用对应或更高版本的Visual Studio打开它。重点关注以下几个配置字符集项目属性 - 常规 - 字符集。老项目很多是“使用多字节字符集”而新的Windows SDK更推荐“使用Unicode字符集”。如果切换所有字符串处理函数如MessageBox都需要从MessageBoxA变为MessageBoxW或者使用TCHAR宏和_T()包裹字符串字面量来保持兼容。运行库项目属性 - C/C - 代码生成 - 运行库。有“多线程调试(/MTd)”、“多线程(/MT)”、“多线程调试DLL(/MDd)”、“多线程DLL(/MD)”几种。简单理解带D的链接调试版库带d的生成文件更大用于开发调试不带D的链接发布版库用于最终分发。MT是静态链接MD是动态链接。静态链接/MT会将C运行库代码打包进你的exe文件会变大但分发时不需要用户安装额外的运行库。动态链接/MD文件小但要求目标电脑上有对应版本的Microsoft Visual C Redistributable。对于给他人分享的小游戏通常选择/MT更省事。附加依赖项项目属性 - 链接器 - 输入 - 附加依赖项。这里列出了项目所需的所有静态库.lib文件。例如如果你使用了GDI就需要添加gdiplus.lib。如果编译时提示“无法解析的外部符号”十有八九是这里的库没配置对。6.2 处理第三方库与资源文件项目可能依赖一些第三方库如用于解析JSON的nlohmann/json单头文件库或者用于音频的FMOD、BASS等。头文件包含路径在项目属性 - C/C - 常规 - 附加包含目录中添加第三方库头文件所在的目录。库文件路径在项目属性 - 链接器 - 常规 - 附加库目录中添加第三方.lib文件所在的目录。动态链接库DLL如果使用/MD或依赖了某些提供DLL的第三方库如FMOD.dll在运行程序时需要将这些DLL文件放在exe的同级目录下或者放在系统的PATH环境变量包含的目录中。资源文件如图片.bmp、声音.wav、地图数据.txt通常有两种处理方式作为外部文件直接放在exe旁边的Resources文件夹里。程序运行时从磁盘读取。这种方式管理灵活但容易丢失或被用户误删。嵌入资源在Visual Studio中可以将这些文件添加到“资源文件”.rc中编译时它们会被打包进exe。程序运行时使用FindResource,LoadResource等API从自身exe中读取。这种方式使程序变成单个文件更整洁但增大了exe体积且修改资源需要重新编译。对于学习项目建议使用第一种方式更方便调试和替换。6.3 发布构建与常见错误解决当代码调试无误后需要生成发布版本。在Visual Studio顶部的解决方案配置下拉框中从“Debug”切换到“Release”。清理解决方案生成 - 清理解决方案然后重新生成生成 - 重新生成解决方案。在项目输出目录通常是项目文件夹\x64\Release或Win32\Release下找到生成的.exe文件。发布时可能遇到的经典错误“找不到MSVCP140.dll”或类似错误这是因为你使用了/MD选项进行动态链接但目标电脑上没有安装对应版本的VC运行库。解决方法要么改用/MT静态链接重新编译要么将对应的Microsoft Visual C Redistributable安装包可以从微软官网下载和你的游戏一起打包分发。程序运行一闪而过可能是程序逻辑问题导致立即退出。更常见的是在控制台应用程序中没有添加暂停语句。对于Win32窗口程序确保消息循环正确启动。可以在WinMain开头加一个MessageBox来调试程序是否执行到此处。图形或声音不显示/播放检查资源文件的路径。在调试器中查看加载资源文件的相关函数如LoadImage,fopen是否成功。路径最好使用相对路径并且确保从正确的当前工作目录启动程序。可以在程序启动时用GetCurrentDirectory获取当前目录并输出调试信息。通过这样一个从源码到可执行文件的完整流程你不仅是在编译一个游戏更是在理解一个原生Windows应用程序的诞生过程。这份经验是使用一键打包的现代游戏引擎无法给予的。它让你对程序的分发、依赖、运行环境有了更接地气的认识。当你最终把那个也许画面简陋但完全由你掌控的RPG.exe文件发给朋友并看着他成功运行时那种成就感是独一无二的。