企业官网建设流程全解析

MonoGame 开发 2D 射击游戏时，很多人会遇到一个尴尬阶段：功能代码写了不少，一运行却发现画面卡顿、子弹消失、敌人穿墙、碰撞偶尔失灵、重新开始还会残留旧对象。标题里那句“你这游戏是人能玩的”，真正反映的往往不是画面不够精致，而是输入响应、碰撞判定、对象生命周期和游戏状态没有协同起来。这篇文章围绕一个自制 MonoGame 射击游戏的最小完整闭环展开，从环境搭建、项目骨架、玩家移动、射击逻辑、敌人生成、碰撞检测，到计分、音效、动画和打包发布，给出一条可复现的技术路径。读完可以自己实现一个“能玩”的 2D 射击游戏原型，也知道后续每一个模块在实际项目中该怎么打磨。

1. 先理解 MonoGame 为什么适合做 2D 射击游戏

1.1 射击游戏的核心不只是“开火”

射击游戏从玩法上看是“玩家控制角色躲避敌人并攻击目标”，但从代码角度看，它涉及几个高度耦合的系统：

• 输入系统：读取键盘、鼠标或手柄，把物理操作转换成游戏内动作。
• 对象系统：玩家、子弹、敌人、道具，每个对象都有位置、速度、生命状态和绘制方式。
• 碰撞系统：判断子弹是否命中敌人、玩家是否被敌人碰到。
• 状态系统：开始界面、游戏中、暂停、游戏结束，不同状态下 Update 和 Draw 的职责要分开。
• 资源系统：纹理、音频、字体、动画帧，如何加载和管理直接决定内存占用和启动速度。

用大而全的引擎做这些事很容易，编辑器拖拖拽拽就能跑通。但 MonoGame 让你更直接地面对“游戏循环”本身：每一帧做什么、更新哪些对象、绘制哪些内容、什么时候销毁对象。对于自制射击游戏来说，这正是理解 2D 游戏开发的关键一步。

1.2 MonoGame 是基于 Update/Draw 循环运行的框架

MonoGame 是开源跨平台游戏开发框架，是 XNA 的社区延续。它提供图形、音频、输入、内容管理等基础能力，但不提供完整编辑器和应用模板，玩家通常从继承Game类开始。

一个 MonoGame 程序的核心是游戏循环：

public class Game1 : Game { protected override void Initialize() { // 初始化非资源逻辑，比如对象列表 base.Initialize(); } protected override void LoadContent() { // 加载纹理、字体、音频 } protected override void Update(GameTime gameTime) { // 处理输入、更新对象状态、检测碰撞 base.Update(gameTime); } protected override void Draw(GameTime gameTime) { // 清屏、绘制背景、绘制对象 base.Draw(gameTime); } }

实际运行中，MonoGame 会以固定或可变时间步长不断调用Update和Draw。两个方法可以理解成生产流水线：Update负责计算位置、判断状态；Draw负责把计算结果渲染到屏幕。设计上不要在同一帧里边更新边绘制，否则会出现半更新状态，对象位置和画面不一致。

1.3 为什么不用 Unity 直接做，还要学 MonoGame

Unity 学习资源多、组件丰富，适合快速出产品。但 MonoGame 的价值在于它更接近游戏程序本身：没有场景图帮你管理对象，没有自动序列化帮你保存状态，对象池、碰撞判断、状态机都需要自己实现。

如果你的目标是学会“游戏程序如何运作”，而不是“如何配好一个大型引擎项目”，MonoGame 是合适的选择。尤其对射击游戏这种对象多、更新频繁的项目，手动管理逻辑更容易看清性能瓶颈。

2. 搭建 MonoGame 开发环境与项目骨架

2.1 需要准备的开发环境

MonoGame 的桌面开发以 .NET 为基础，开发机需要安装：

• .NET SDK：建议 7.0 或更新版本，文章示例以常见的 .NET 8 环境为参考。
• MonoGame 项目模板。
• 文本编辑器或 IDE：Visual Studio、Visual Studio Code 均可。
• 一份简单的平面纹理资源，用于玩家、子弹、敌人占位。

安装 MonoGame 模板最常用的是命令行方式：

dotnet new install MonoGame.Templates.CSharp

安装完成后，可以查看模板：

dotnet new list | grep MonoGame

不同版本模板名称略有差异，常见的是MonoGame Cross-Platform Desktop Application，短名为mgdesktopgl。创建项目：

dotnet new mgdesktopgl -o MyShooter cd MyShooter dotnet run

如果运行后出现一个黑色窗口，说明环境搭建完成。注意：模板名和 .NET 版本在不同 MonoGame 版本里可能不同，落地前先执行dotnet new list确认实际名称。

注意：不要认为窗口出现就等于项目可以交付了。模板生成的只是启动壳，真正的游戏逻辑还需要自己组织。

2.2 理解项目结构和内容管线

创建后的项目目录大致如下：

MyShooter/ ├── Content/ │ ├── Content.mgcb │ └── (图片、音频等资源文件) ├── Game1.cs ├── MyShooter.csproj ├── Program.cs └── Icon.ico

其中Content.mgcb是 MonoGame 内容管线的项目文件，它决定了哪些资源会被编译进游戏。启动项目时，纹理、音频、字体并不是直接读取原文件，而是通过内容管线处理成 MonoGame 运行时可加载的格式，再通过ContentManager加载。

Game1.cs是入口类，负责创建窗口、初始化 GraphicsDevice、加载资源和启动游戏循环。实际项目中通常不会把所有逻辑塞进Game1.cs，而是拆成多个类，比如Player、Bullet、Enemy、GameManager。

开发环境和生产环境的差异从这一步就开始体现：

• 开发环境：资源放在Content目录，修改后通过dotnet run或 IDE 启动，编译器会处理资源。
• 生产环境：发布时需要把编译后的内容文件和可执行文件一起分发，不能假设目标机器上有源工程。

2.3 第一个可运行的最小窗口

先用一个最小示例跑通窗口和更新循环，确认基础链路没问题。修改Game1.cs中的窗口标题：

protected override void Initialize() { Window.Title = "MonoGame Shooter Demo"; base.Initialize(); }

再添加一个简单的背景色，方便确认 Draw 正常工作：

protected override void Draw(GameTime gameTime) { GraphicsDevice.Clear(Color.CornflowerBlue); base.Draw(gameTime); }

运行后如果看到蓝色窗口，说明：

• MonoGame 模板安装成功。
• Update和Draw循环正常。
• 图形设备能正确创建窗口。

这一步是整个项目的地基。后面的玩家、子弹、敌人代码都要在这个循环里插入。

3. 实现核心玩法：移动、射击、敌人与碰撞

3.1 玩家类：位置、速度和边界约束

射击游戏最简单的玩家逻辑是：通过方向键或 WASD 移动，角色不能移出屏幕。定义一个Player类，集中管理玩家属性：

public class Player { public Vector2 Position; public Texture2D Texture; public float Speed = 300f; public int Health = 3; private Rectangle _bounds; public Player(Texture2D texture, Rectangle bounds) { Texture = texture; _bounds = bounds; Position = new Vector2(bounds.Width / 2f, bounds.Height - 100f); } public void Update(GameTime gameTime) { float deltaTime = (float)gameTime.ElapsedGameTime.TotalSeconds; var keyboardState = Keyboard.GetState(); Vector2 direction = Vector2.Zero; if (keyboardState.IsKeyDown(Keys.Left) || keyboardState.IsKeyDown(Keys.A)) direction.X -= 1f; if (keyboardState.IsKeyDown(Keys.Right) || keyboardState.IsKeyDown(Keys.D)) direction.X += 1f; if (keyboardState.IsKeyDown(Keys.Up) || keyboardState.IsKeyDown(Keys.W)) direction.Y -= 1f; if (keyboardState.IsKeyDown(Keys.Down) || keyboardState.IsKeyDown(Keys.S)) direction.Y += 1f; if (direction != Vector2.Zero) direction.Normalize(); Position += direction * Speed * deltaTime; Position = ClampToBounds(); } private Vector2 ClampToBounds() { float x = MathHelper.Clamp(Position.X, Texture.Width / 2f, _bounds.Width - Texture.Width / 2f); float y = MathHelper.Clamp(Position.Y, Texture.Height / 2f, _bounds.Height - Texture.Height / 2f); return new Vector2(x, y); } public void Draw(SpriteBatch spriteBatch) { spriteBatch.Draw(Texture, Position, null, Color.White, 0f, new Vector2(Texture.Width / 2f, Texture.Height / 2f), 1f, SpriteEffects.None, 0f); } }

这里有一个容易被忽略的细节：Normalize是为了让斜向移动时速度不叠加。如果不做归一化，按左下、右下方向移动时，实际速度会变成单个方向的约 1.41 倍，玩家的手感会明显变“飘”。

ClampToBounds让玩家保持在窗口范围内。使用Texture.Width / 2f作为偏移，是因为绘制时使用了纹理中心作为原点，位置和碰撞盒的中心对齐，后面的碰撞判断会简单很多。

3.2 子弹类：发射、速度和生命周期

子弹的设计比玩家更简单，但多了一个关键点：生命周期。子弹飞出屏幕后如果不销毁，会一直留在对象列表里，最终拖慢Update和Draw，严重时还会造成假死。

public class Bullet { public Vector2 Position; public Vector2 Velocity; public Texture2D Texture; public bool IsActive = true; public Bullet(Texture2D texture, Vector2 startPosition, float speed) { Texture = texture; Position = startPosition; Velocity = new Vector2(0, -speed); } public void Update(GameTime gameTime) { float deltaTime = (float)gameTime.ElapsedGameTime.TotalSeconds; Position += Velocity * deltaTime; } public Rectangle Bounds => new Rectangle( (int)(Position.X - Texture.Width / 2f), (int)(Position.Y - Texture.Height / 2f), Texture.Width, Texture.Height); }

IsActive是对象生命周期管理的核心字段。每一帧先更新子弹，再检查是否超出屏幕，超出的子弹不立即从列表移除，先标记为IsActive = false，之后统一回收，避免在遍历中途修改集合。

发射逻辑放在玩家类或一个GameManager类中，这里以玩家为例：

private float _shootCooldown; private float _shootTimer; public void TryShoot(GameTime gameTime, Texture2D bulletTexture, List<Bullet> bullets) { _shootCooldown = 0.2f; _shootTimer += (float)gameTime.ElapsedGameTime.TotalSeconds; if (_shootTimer >= _shootCooldown) { var keyboardState = Keyboard.GetState(); if (keyboardState.IsKeyDown(Keys.Space)) { bullets.Add(new Bullet(bulletTexture, Position, 500f)); _shootTimer = 0f; } } }

射击冷却非常重要。如果不加冷却时间，玩家按住空格时每帧都可能生成多颗子弹，性能下降是一方面，游戏难度也会失衡。

3.3 敌人行为与生成逻辑

敌人不需要太复杂，但必须有相对稳定的生成节奏。常见做法是定时生成，并让敌人从上方往下移动。

public class Enemy { public Vector2 Position; public Texture2D Texture; public float Speed; public bool IsActive = true; public Enemy(Texture2D texture, Vector2 startPosition, float speed) { Texture = texture; Position = startPosition; Speed = speed; } public void Update(GameTime gameTime) { float deltaTime = (float)gameTime.ElapsedGameTime.TotalSeconds; Position.Y += Speed * deltaTime; } public Rectangle Bounds => new Rectangle( (int)(Position.X - Texture.Width / 2f), (int)(Position.Y - Texture.Height / 2f), Texture.Width, Texture.Height); }

生成敌人的逻辑可以用一个spawnTimer控制：

private float _spawnTimer; private float _spawnInterval = 1.5f; private void SpawnEnemy(GameTime gameTime) { _spawnTimer += (float)gameTime.ElapsedGameTime.TotalSeconds; if (_spawnTimer >= _spawnInterval) { int x = Random.Shared.Next(20, GraphicsDevice.Viewport.Width - 20); var enemy = new Enemy(_enemyTexture, new Vector2(x, -20), 120f); _enemies.Add(enemy); _spawnTimer = 0f; } }

敌人速度、生成间隔、生成位置是三个核心调参项。生成间隔过短会让玩家没反应时间，过长又会让游戏无聊。学习阶段可以把这三个参数暴露成公开字段，运行中临时修改对比手感。

3.4 碰撞检测：从矩形相交开始

2D 射击游戏最常见的碰撞检测是 AABB（轴对齐包围盒）方式，也就是用两个矩形的相交判断是否发生碰撞。

private void CheckCollisions() { foreach (var bullet in _bullets) { if (!bullet.IsActive) continue; foreach (var enemy in _enemies) { if (!enemy.IsActive) continue; if (bullet.Bounds.Intersects(enemy.Bounds)) { bullet.IsActive = false; enemy.IsActive = false; _score += 10; break; } } } foreach (var enemy in _enemies) { if (!enemy.IsActive) continue; if (enemy.Bounds.Intersects(_player.Bounds)) { enemy.IsActive = false; _player.Health--; if (_player.Health <= 0) _gameState = GameState.GameOver; } } }

Rectangle.Intersects在只有少数对象时足够用。对象数量增大后，每一颗子弹都要遍历所有敌人，复杂度是 O(子弹数 x 敌人数)，弹幕游戏或对象量上百后会出现明显卡顿。那时才需要考虑四叉树或空间哈希，这里不展开。

对象清理放在碰撞检测之后统一进行：

_bullets.RemoveAll(b => !b.IsActive); _enemies.RemoveAll(e => !e.IsActive);

RemoveAll配合IsActive标记，是典型的延迟删除模式，安全且高效。

注意：不要在 foreach 循环中直接 Remove 正在遍历的对象。这样会修改集合大小，轻则跳过元素，重则抛出 InvalidOperationException。

4. 动画、音效和界面反馈

4.1 用序列帧让敌人动起来

静止的方块敌人虽然能玩，但视觉反馈很弱。简单做法是用精灵图做序列帧动画：把多帧图片放到同一张图里，按时间切换显示区域。

假设图片里有两帧，每帧宽 32 像素，高 32 像素。绘制时用sourceRectangle指定当前帧：

private int _currentFrame; private float _frameTimer; private float _frameTime = 0.1f; public void UpdateAnimation(GameTime gameTime) { _frameTimer += (float)gameTime.ElapsedGameTime.TotalSeconds; if (_frameTimer >= _frameTime) { _currentFrame = (_currentFrame + 1) % 2; _frameTimer = 0f; } } public void Draw(SpriteBatch spriteBatch, Texture2D spriteSheet) { var sourceRectangle = new Rectangle(_currentFrame * 32, 0, 32, 32); spriteBatch.Draw(spriteSheet, Position, sourceRectangle, Color.White); }

关键点：动画计时器和移动计时器不要在同一个变量里处理。移动使用Position计算，动画使用_currentFrame切换，两者更新频率可能不同，一旦混用会出现“敌人瞬移”或“动画抽风”的现象。

4.2 音效触发与音量控制

MonoGame 中音频文件包括.wav、.ogg、.mp3等，需要通过内容管线加入项目。加载后可以用SoundEffect播放。

private SoundEffect _shootSound; private SoundEffect _explosionSound; protected override void LoadContent() { _shootSound = Content.Load<SoundEffect>("shoot"); _explosionSound = Content.Load<SoundEffect>("explosion"); }

触发音效时要注意频率控制，子弹音效如果每颗子弹都全音量播放，会造成明显的噪声叠加：

if (bulletFired) { _shootSound.Play(0.5f, 0f, 0f); }

Play的第一个参数是音量，范围 0 到 1；第二个是音调；第三个是左右声道平衡。实际游戏里不要每次都相同音量，可以加一点随机值，避免听觉疲劳。

4.3 用 SpriteFont 显示分数和状态

MonoGame 绘制文字使用SpriteFont。在内容项目中创建的字体，代码里用名称加载：

private SpriteFont _font; protected override void LoadContent() { _font = Content.Load<SpriteFont>("Font"); } protected override void Draw(GameTime gameTime) { GraphicsDevice.Clear(Color.Black); _spriteBatch.Begin(); _spriteBatch.DrawString(_font, $"Score: {_score}", new Vector2(20, 10), Color.White); _spriteBatch.DrawString(_font, $"Health: {_player.Health}", new Vector2(20, 40), Color.Yellow); _spriteBatch.End(); }

UI 绘制顺序很重要。通常先绘制背景和对象，再绘制 UI。如果顺序反了，UI 会被角色画面遮挡，或者对象闪烁。

这个阶段要逐渐引入游戏状态。最简单的状态机：

public enum GameState { Menu, Playing, GameOver }

不同状态下Update的逻辑完全不同：菜单状态要检测开始键，游戏状态才处理移动和射击，游戏结束状态要显示最终分数并等待重新开始。不要在Update里用 if 嵌套把三种状态写在一起，后面会很难维护。

5. 运行验证与调试重点

5.1 功能性验证清单

游戏能跑起来不等于功能正确。建议用清单逐步确认：

其中“子弹飞出屏幕后消失”和“GameOver 后不能继续游戏”是最容易遗漏的边界情况。

5.2 用 FPS 和 Hitbox 可视化辅助调试

调手感时，最直接的工具是把调试信息画到屏幕上。给玩家、子弹、敌人绘制临时碰撞框：

private Texture2D _pixelTexture; protected override void LoadContent() { _pixelTexture = new Texture2D(GraphicsDevice, 1, 1); _pixelTexture.SetData(new[] { Color.White }); } private void DrawDebugBounds(SpriteBatch spriteBatch, Rectangle bounds) { // 用 1x1 白色纹理拉伸绘制边框 spriteBatch.Draw(_pixelTexture, new Rectangle(bounds.X, bounds.Y, bounds.Width, 1), Color.Red); spriteBatch.Draw(_pixelTexture, new Rectangle(bounds.X, bounds.Bottom - 1, bounds.Width, 1), Color.Red); spriteBatch.Draw(_pixelTexture, new Rectangle(bounds.X, bounds.Y, 1, bounds.Height), Color.Red); spriteBatch.Draw(_pixelTexture, new Rectangle(bounds.Right - 1, bounds.Y, 1, bounds.Height), Color.Red); }

在Draw中按下 F1 时绘制所有碰撞框，能快速判断碰撞盒和精灵图是否对齐。很多时候“明明被打中了却没检测到碰撞”或者“没碰到却扣血了”，根源就是绘制位置用了纹理左上角，而碰撞盒用了中心点。

FPS 显示可以放到窗口标题栏：

Window.Title = $"FPS: {_frameRate}";

帧率稳定在 60 左右说明主循环性能够用；如果明显低于 60，先检查对象数量、每帧分配和绘制调用量。

5.3 学习环境与生产环境关注点

学习环境通常只关注“能否跑通”，生产环境还要关注：

• 资源路径：发布后Content目录结构不能变，否则运行时报找不到资源。
• 日志输出：控制台输出在发布后不一定可见，需要把关键日志写到文件。
• 异常处理：Update中的异常会导致游戏直接崩溃，生产版本至少要有日志和恢复机制。
• 分辨率适配：窗口大小变化后，玩家边界和生成位置要根据Viewport动态计算，而不是写死 800x600。

Viewport是生产环境里必须认真处理的一个点。窗口大小变化后，玩家边界、敌人生成位置、UI 位置都需要重新计算。最简单的做法是每帧读取GraphicsDevice.Viewport来获取当前可视区域：

var viewport = GraphicsDevice.Viewport; _player.UpdateBounds(new Rectangle(0, 0, viewport.Width, viewport.Height));

6. 常见问题与排查链路

6.1 高频问题速查表

6.2 从现象倒推根因的排查步骤

遇到问题先不要直接改代码，按顺序检查：

1. 先确认输入是否到达。玩家不动，先打印键盘状态，确认按键映射正确。
2. 再确认对象是否进入 Update。有的玩家、敌人列表在 Initialize 里没有初始化，导致所有更新方法都跑在空列表上。
3. 然后确认对象是否被绘制。Draw中没有调用对应对象的 Draw 方法，画面自然没有变化。
4. 接着确认资源是否加载成功。Content.Load<T>抛异常时，优先看.mgcb中的资源名称是否与代码名称一致。
5. 再检查坐标更新顺序。Update中改了位置，但Draw用的是备份位置，画面就不会动。
6. 最后检查对象生命周期。敌人死亡后未销毁或未标记，会导致“尸体”继续参与碰撞。

一个常见错误是把物理更新写进了Draw。在某些驱动或垂直同步环境下，Draw的调用节奏和Update不同，这会让对象位置出现跳变或闪烁。

// 错误写法：在 Draw 中更新状态 protected override void Draw(GameTime gameTime) { _player.Update(gameTime); // 不应该出现在这里 _player.Draw(_spriteBatch); } // 推荐写法：Update 和 Draw 分离 protected override void Update(GameTime gameTime) { _player.Update(gameTime); base.Update(gameTime); } protected override void Draw(GameTime gameTime) { _player.Draw(_spriteBatch); base.Draw(gameTime); }

6.3 对象池：子弹数量变大后必须引入的机制

当玩家连续开火，敌人也不停生成，List<Bullet>会不断 Add 再 RemoveAll。频繁的分配和垃圾回收会导致短暂卡顿，也就是俗称的“GC spike”。

对象池的基本思路是预先创建一批子弹，射击时从池中取出一个激活，回收时放回池中。

private List<Bullet> _bulletPool = new List<Bullet>(); private List<Bullet> _activeBullets = new List<Bullet>(); private Bullet GetBullet(Texture2D texture, Vector2 position, float speed) { Bullet bullet = _bulletPool.FirstOrDefault(b => !b.IsActive); if (bullet == null) { bullet = new Bullet(texture, position, speed); _bulletPool.Add(bullet); } else { bullet.Position = position; bullet.Velocity = new Vector2(0, -speed); bullet.IsActive = true; } _activeBullets.Add(bullet); return bullet; }

对象池的收益在对象数量超过几百后非常明显，射击游戏早晚要面对。学习阶段可以先不引入，但要在架构上预留接口。

7. 发布前检查、开源策略与后续扩展

7.1 发布前检查清单

游戏逻辑写好后，发布前至少检查以下内容：

• 游戏是否有开始画面和结束画面，玩家知道怎么开始、怎么结束。
• 游戏过程中是否有明确的计分和生命状态反馈。
• 窗口大小变化后，玩家边界、敌人生成、UI 位置是否自适应。
• 游戏中是否有一些隐藏的调试键（比如 F1、F2），发布前要屏蔽或移除。
• 是否对Content资源进行了裁剪，未使用的纹理和音频不应打包发布。
• 是否处理了游戏结束后的“重新开始”状态，所有对象列表和计分变量都要重置。
• 是否存在异常日志，崩溃时至少知道错在哪一行。

7.2 从“能玩”到“好玩”的扩展方向

基础射击游戏跑通后，下一步的工作几乎都围绕“手感”和“内容量”展开：

• 移动平滑：加入加速度和惯性，让玩家移动不那么“直来直去”。
• 滚动背景：使用多个背景层以不同速度滚动，营造深度。
• 敌人行为模式：不只是直线下落，加入 Sine 波动、瞄准玩家、分裂等行为。
• 波次系统：把敌人生成改成分波次触发，而不是固定时间间隔。
• 粒子效果：击中敌人时增加简单的爆炸粒子，视觉反馈更明确。
• 音频变化：射击音效根据连续射击节奏变化，降低单调感。
• 难度曲线：随分数上升提高生成频率和敌人速度。
• 调参面板：把速度、冷却、生成间隔等参数集中到一个配置类，运行时调整。

这些扩展并不需要换框架，MonoGame 完全能支撑。关键在于对象管理、状态管理和参数配置的结构是否足够清晰。

7.3 开源还是不开源，先想清楚这几个问题

原视频标题提到“暂不开源”，这本身是合法且合理的项目发布策略。对个人开发者来说，是否开源取决于几个问题：

• 项目是否包含未获得授权的素材（图片、音频、字体）。如果用了别人的素材，开源会带来授权风险。
• 项目是否计划商用。商用项目一般不建议开源核心代码，尤其是服务器端和付费逻辑。
• 项目是否希望获得社区反馈。开源可以带来 issue、PR 和改进建议，但也要维护文档和 issue 列表。
• 项目是否有个人隐私或安全标识。硬编码的个人 API Key、服务器地址绝对不能进开源仓库。

如果想开源，许可证要提前选定：

如果暂时不开源，也可以先把核心玩法的技术笔记、结构图、开发复盘整理成文档，这类经验分享对自身成长和后续开源都有帮助。游戏项目最怕的不是代码写得不够漂亮，而是闭门开发很久后才发现方向错了。

从学习角度看，这一个小型射击游戏项目最有价值的练习点，不是把代码写得多么“高级”，而是把移动、射击、碰撞、音效、动画、状态管理六个模块串成一个完整闭环。先让每一个模块都能独立验证，再逐步加入对象池、波次系统、粒子效果这些扩展。游戏手感是一项参数调试工作，不是一次就能写对的；速度、冷却时间、碰撞范围、音效音量都要在试玩中反复调整。这个“能玩”到“好玩”的过程，才是 MonoGame 射击游戏开发真正需要积累的核心经验。