如果今天重新做 Claw，会用什么技术

网罗开发 （小红书、快手、视频号同名）

大家好，我是展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

📣 公众号"Swift社区"，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 3 月 17 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

- 引言
- [技术选择 1：游戏引擎](#技术选择 1：游戏引擎)
- [技术选择 2：语言](#技术选择 2：语言)
- [技术选择 3：2D 渲染系统](#技术选择 3：2D 渲染系统)
- [技术选择 4：物理与碰撞](#技术选择 4：物理与碰撞)
- [技术选择 5：资源管理](#技术选择 5：资源管理)
- [技术选择 6：关卡编辑器](#技术选择 6：关卡编辑器)
- [技术选择 7：跨平台](#技术选择 7：跨平台)
- [如果今天真的重做 Claw](#如果今天真的重做 Claw)
- 但有一件事不会改变
- 总结

引言

很多开发者在研究 OpenClaw 的源码时，都会有一个非常有意思的想法：

如果今天重新开发这款游戏，会用什么技术？

那款游戏就是很多 90 后玩家熟悉的 Claw。在 1997 年，这款游戏的开发环境和今天完全不同：

CPU 只有几百 MHz
内存几十 MB
GPU 基本不存在
游戏引擎大多是自研

所以当时的开发方式通常是：

复制代码

C/C++
自研渲染
自研物理
自研资源系统

但如果今天重新做一款类似 Claw 的 2D 动作游戏，技术选择其实会完全不一样。

技术选择 1：游戏引擎

如果今天开发 Claw，第一件事情就是选择引擎。

在 90 年代，大多数游戏公司都会自己写引擎，因为没有成熟工具。

但今天开发者通常会选择现成引擎，例如：

复制代码

Unity
Unreal
Godot

如果是 2D 横版游戏 ，最常见的选择其实是：Unity

原因很简单：

2D 工具链成熟
编辑器非常完善
生态丰富

例如角色动画、碰撞、物理系统，都已经内置。简单来说：

今天开发者更关注 游戏内容 ，而不是 底层引擎。

技术选择 2：语言

当年 Claw 使用的是 C/C++。如果今天开发类似项目，常见选择可能是：

复制代码

C#
C++
Rust

例如在 Unity 中，主要语言就是：

复制代码

C#

一个简单的角色控制逻辑可能是：

csharp 复制代码

void Update() {
    if (Input.GetKey(KeyCode.LeftArrow)) {
        transform.Translate(Vector2.left * speed * Time.deltaTime);
    }
}

而如果使用轻量引擎，例如 Godot，则可以使用：

复制代码

GDScript
C#
C++

对开发者来说，门槛已经比 90 年代低很多。

技术选择 3：2D 渲染系统

在 90 年代，游戏渲染通常需要自己实现。例如：

复制代码

Sprite
TileMap
动画系统

而今天很多引擎已经直接提供：

复制代码

Sprite Renderer
TileMap Editor
Animation Controller

例如 Unity 的 TileMap 系统：

复制代码

Tile Palette
Tilemap Renderer
Tilemap Collider

开发者甚至可以 可视化编辑关卡。这和当年手写关卡数据相比，效率差异非常大。

技术选择 4：物理与碰撞

像 Claw 这种横版动作游戏，核心机制其实是：

复制代码

跳跃
碰撞
攻击

90 年代很多游戏会自己实现简单物理系统。但今天几乎所有引擎都集成了物理引擎，例如：

复制代码

Box2D
Bullet
PhysX

例如 Unity 使用：

复制代码

Box2D

开发者只需要添加组件：

复制代码

Rigidbody2D
BoxCollider2D

就能实现基本碰撞系统。

技术选择 5：资源管理

在 Claw 的时代，资源管理是非常复杂的事情。开发者通常需要：

复制代码

自定义资源格式
自定义资源加载
自定义缓存系统

而今天很多引擎已经提供完整方案，例如：

复制代码

AssetBundle
Addressables
Resource Loader

开发者只需要：

复制代码

拖入资源

引擎就会自动管理加载和缓存，这也是现代游戏开发效率提升的重要原因。

技术选择 6：关卡编辑器

在 90 年代，很多游戏的关卡工具其实是 内部工具。

甚至有些关卡数据是手写配置，如果今天重新开发 Claw，关卡设计通常会使用：

复制代码

可视化关卡编辑器

例如：

复制代码

Unity TileMap Editor
Tiled Map Editor
Godot TileMap

设计师可以直接拖拽：

复制代码

地形
机关
敌人
道具

然后实时预览效果，这极大提升了开发效率。

技术选择 7：跨平台

1997 年的 Claw 主要运行在：

复制代码

Windows PC

而如果今天开发类似游戏，通常会考虑：

复制代码

PC
iOS
Android
Switch
Steam Deck

例如 Unity 支持：

复制代码

Windows
macOS
Linux
iOS
Android
WebGL

开发者只需要：

复制代码

Build

就可以生成不同平台版本。

如果今天真的重做 Claw

如果按照现代技术栈来实现，一个典型架构可能是：

复制代码

Game
 ├─ Unity Engine
 │
 ├─ Gameplay
 │   ├─ PlayerController
 │   ├─ EnemyAI
 │   └─ CombatSystem
 │
 ├─ Level
 │   ├─ TileMap
 │   └─ Trigger
 │
 └─ UI

技术组合可能是：

复制代码

Unity
C#
Box2D
TileMap Editor
Addressables

整个开发效率会比 90 年代高很多。

但有一件事不会改变

虽然技术栈发生了巨大变化，但有一件事情其实没有变：

好的游戏设计永远比技术更重要。

Claw 能成为经典，并不是因为它的技术多先进。而是因为：

关卡设计精巧
操作手感优秀
探索感很强

这也是为什么即使过了 20 多年，很多玩家依然愿意重新体验这款游戏。

而像 OpenClaw 这样的项目，其实正是因为大家对这款游戏仍然有感情。

总结

如果今天重新开发类似 Claw 的游戏，技术选择可能会变成：

复制代码

Unity / Godot
C#
Box2D
TileMap Editor
跨平台发布

相比 90 年代，现代游戏开发工具已经成熟了很多。

开发者不需要再从零实现：

复制代码

渲染系统
物理系统
资源管理
关卡工具

但无论技术怎么变化，一款游戏真正能留下来的原因，往往还是：

优秀的玩法设计。

这也是为什么经典游戏总是会被一代代玩家重新发现。