老游戏是怎么做性能优化的

子玥酱 （掘金 / 知乎 / CSDN / 简书同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，

在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨

👋 如果你正在做前端，或准备长期走前端这条路

📚 关注我，第一时间获取前端行业趋势与实践总结

🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）

💡 一起把技术学"明白"，也用"到位"

持续写作，持续进阶。

愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

- 引言
- [优化一：TileMap 地图复用](#优化一：TileMap 地图复用)
- 优化二：帧动画而不是骨骼动画
- 优化三：碰撞检测极简化
- 优化四：资源一次加载
- 优化五：只更新可见区域
- [优化六：对象池（Object Pool）](#优化六：对象池（Object Pool）)
- 优化七：减少浮点运算
- 优化八：预计算数据
- 为什么这些优化今天依然重要
- 总结

引言

很多开发者第一次重新体验 Claw 这类老游戏时，都会产生一个疑问：

当年的电脑性能那么弱，游戏是怎么做到这么流畅的？

要知道 90 年代的 PC，很多配置大概是这样：

复制代码

CPU：几十 MHz
内存：8MB / 16MB
显卡：没有现代 GPU

在这样的硬件条件下，游戏依然可以：

复制代码

流畅动画
复杂关卡
大量敌人

当我们研究像 OpenClaw 这样的项目时，也会发现很多经典的性能优化思路。有些方法甚至在今天依然适用。

优化一：TileMap 地图复用

老游戏很少使用大图片作为地图，而是使用：

复制代码

TileMap

也就是把地图拆成很多小图块。例如：

复制代码

16x16
32x32

然后通过索引拼接：

复制代码

tile[1] tile[1] tile[5]
tile[2] tile[3] tile[4]
tile[1] tile[1] tile[5]

优点非常明显：

复制代码

减少内存占用
重复使用图块
渲染效率更高

很多横版游戏其实都是用这种方式构建关卡的。

优化二：帧动画而不是骨骼动画

现代游戏经常使用：

复制代码

骨骼动画
实时计算

但老游戏通常使用：

复制代码

帧动画

也就是提前画好每一帧：

复制代码

run_1
run_2
run_3
run_4

播放时只需要：

复制代码

切换图片

代码可能只有：

cpp 复制代码

frame = (time / frameDuration) % frameCount;

这种方式几乎没有 CPU 开销。

优化三：碰撞检测极简化

碰撞检测是游戏中最容易消耗性能的部分之一。但很多老游戏使用的其实是：

复制代码

AABB 碰撞盒

结构非常简单：

复制代码

矩形

检测逻辑也只有几行代码：

cpp 复制代码

if (a.x < b.x + b.w &&
    a.x + a.w > b.x &&
    a.y < b.y + b.h &&
    a.y + a.h > b.y) {
    collision = true;
}

这种算法的优势是：

复制代码

计算量极小
实现简单
效率非常高

对于 2D 游戏来说已经完全足够。

优化四：资源一次加载

老游戏通常会避免频繁读取磁盘。很多资源会在游戏开始时一次性加载：

复制代码

贴图
音效
动画

例如：

cpp 复制代码

Texture* tex = loadTexture("player.png");

然后在游戏过程中重复使用。这种 资源缓存策略 可以避免：

复制代码

频繁 IO
加载卡顿

这也是很多游戏引擎的基本设计。

优化五：只更新可见区域

老游戏通常不会更新整个地图，而是只处理：

复制代码

屏幕范围

例如：

复制代码

玩家附近区域

如果地图很大，例如：

复制代码

2000 × 2000 tiles

引擎只会处理当前屏幕的：

复制代码

几十个 tile

伪代码大概是：

cpp 复制代码

for tile in visibleTiles:
    draw(tile)

这样可以大幅减少计算量。

优化六：对象池（Object Pool）

在很多游戏中，会频繁创建对象，例如：

复制代码

子弹
爆炸特效
掉落物

如果每次都：

复制代码

new
delete

就会产生大量内存分配，老游戏通常会使用：

复制代码

对象池

例如：

cpp 复制代码

Bullet* bullet = bulletPool.get();

使用完之后再回收：

复制代码

bulletPool.release(bullet)

这样可以避免频繁内存分配。

优化七：减少浮点运算

在 90 年代，CPU 处理浮点运算的能力其实很弱。很多游戏会尽量使用：

复制代码

整数运算

例如：

复制代码

位置坐标
速度
碰撞检测

例如：

复制代码

x += velocity

而不是复杂的浮点计算，这种优化在今天可能不明显，但在当时非常重要。

优化八：预计算数据

很多游戏会提前计算一些数据，例如：

复制代码

动画帧
路径
物理表

例如跳跃曲线：

复制代码

提前计算好高度

游戏运行时只需要读取表数据：

复制代码

jumpHeight[frame]

这样可以减少实时计算。

为什么这些优化今天依然重要

当我们研究 OpenClaw 这类项目时，会发现一个有趣的事实：

很多老游戏的优化方法，今天依然在使用。

例如：

复制代码

TileMap
对象池
资源缓存
可见区域更新

这些技术其实就是现代游戏引擎很多系统的基础。

总结

在硬件资源非常有限的时代，游戏开发者不得不非常重视性能优化。

很多经典游戏使用了非常高效的设计，例如：

复制代码

TileMap 地图
帧动画
AABB 碰撞
资源缓存
可见区域更新
对象池
减少浮点运算
预计算数据

正因为这些技术，像 Claw 这样的游戏才能在当年的电脑上流畅运行。

有时候回头看这些设计，你会发现一件很有意思的事情：

资源越少，工程师反而越容易写出高效的软件。