【ZeloEngine】Roadmap

【ZeloEngine】Roadmap

文章目录

• 【ZeloEngine】Roadmap
• • 短期规划
  • 长期规划
  • • 编程范式
    • 引擎基础模块
    • 引擎参考
    • 引擎黑名单
    • 编辑器
  • 开发历程
  • • 2019年8月1日
    • 2021年12月29日
  • === ARCHIVED ===
  • • Python Prototype
    • C++ Runtime
    • Demo
    • 特性规划
    • RHI
    • • OpenGL
      • OpenGL vs Vulkan
  • 编辑器技术选型

短期规划

• 完善Demo，整合目前所学渲染知识
• 材质系统，可视化，可编辑的材质属性
• frame graph，或者render pass抽象
• 通用属性编辑器，自动反射属性
• imgui框架，支持C++扩展，实现拖拽（drag & drop）

长期规划

• 多编程范式
  • OOP，脚本，数据驱动
  • Data Oriented
• RHI
  • Vulkan
  • D3D12

编程范式

OOP，脚本，数据驱动是，基本功，基本熟悉了

Data Oriented，场景图初步尝试了一下，引擎的重点，缓存友好的数据结构设计

引擎基础模块

• 物理
• 粒子
• AI
• 资源管理
• 打包
• 异步
• 序列化
• 输入
• 脚本

说实话，每一样都是一个轮子，有的好搞了，还没算服务端引擎

我的想法是吃透一个技术方案即可，深度》广度

调用API，大家抄来抄去都会了，成本很低

但是比如序列化，rapidjson是milo写的最快（战神4的幕后名单里有提到，这点让我印象深刻）

引擎参考

实用主义出发，学一个自己能驾驭的，骑驴找马

Ogre
Ogre花了两个月下班时间看完了渲染部分（大致框架），然后就扔了，因为有太多固定管线影子，主要是看OOP怎么设计的，代码规范

Godot
Godot，调研了一下，但是感觉没时间去看，因为定位不明确；Godot最好是看完能贡献代码，但是和实际工作又差的太远（没人需要会Godot的人）

UE4
UE4过于复杂，作为算法参考比较合适，新手容易迷失，但是长远来看，能看懂UE4是有很大市场价值的

Unity
Unity，闭源，但是作为第一个学习的游戏引擎，有一定积累，文档，核心功能要熟悉（目前工作并不用Unity）

引擎黑名单

参考引擎，要有目的性的看

Github上开源引擎项目太多了，而且不少高star的，即使是1k+star的，也不一定值得研究

好的引擎有一个很重要的评价要求，就是用引擎做游戏，或者至少是Demo

然后是，符合自己当前的水平，可以驾驭，否则为啥不去看UE4呢

所以比如godot，虽然最近很有名，但是全部是自己造的轮子，我很难学到什么，也没法拆下来轮子自己用

Wicked，如下，代码质量太低了

编辑器

编辑器架构，我的想法：

1. ingame编辑器，imgui，game is editor
2. standalone编辑器，用tcp和客户端实例通信

编辑器开发不太被项目重视，因为收益低

一个完善的开发流程是必要的

1. 文档和手册维护，用户不知道怎么用，怎么解决问题
2. 编辑器功能设计

自己一个人写，很多按钮是哑的，没有逻辑，没有反馈

还是要有需求驱动，不断完善，不断测试

开发历程

2019年8月1日

ZeloEngine是2019年6月进了腾讯实习开始做的

公司工作量很大，但是我仍然坚持挤出很多时间学习，搞得很累，2点之后睡，很糟糕

github

• 364次提交
• 200个issue

cloc

PS D:\ZeloEngine> .\cloc.exe Src Util
      65 text files.
      65 unique files.
      22 files ignored.

github.com/AlDanial/cloc v 1.80  T=0.50 s (118.0 files/s, 19230.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                             14            683            428           3245
C/C++ Header                    18            537            587           2479
Lua                             18            178            668            **743**
CMake                            7             11             16             20
PowerShell                       2              4              8              8
-------------------------------------------------------------------------------
SUM:                            59           1413           1707           **6495**
-------------------------------------------------------------------------------

2021年12月29日

• 提交1595次
• 85个issue

github.com/AlDanial/cloc v 1.80  T=1.00 s (471.0 files/s, 74141.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C/C++ Header                   126           6533           2061          30339
C++                            107           3133            749          13743
Lua                            124           1888           1056           8541
GLSL                            22            412            305           1338
Python                          10            295             96           1016
Markdown                        28            388             12            841
CMake                           34            110             66            459
JSON                             6              0              0            265
DOS Batch                        9             36              0            160
INI                              2             28            141             77
YAML                             2              8              1             26
AutoHotkey                       1              5              0             13
-------------------------------------------------------------------------------
SUM:                           471          12836           4487          56818
-------------------------------------------------------------------------------

=== ARCHIVED ===

Python Prototype

• simple renderer (with PyOpenGL, PyGlfw)
  • directional light
  • texture
  • transform
• game framework
  • stategraph (event-driven, DSL driven)
  • b-tree (sub-tree, DSL driven)
  • entity & components
  • prefab
• GUI & editor
  • imgui (in-game editor)
  • PyQt5 (general editor)
  • scene editor
  • property editor
  • node editor
• physics
  • bullet
  • cyclone

C++ Runtime

• forward renderer
• lua script support
• scene & transform tree

Demo

• cyclone physics demo
• forward renderer demo
• TPS AI demo

特性规划

• DSL驱动引擎
  • 多种脚本语言
    • Lua
    • Python
    • C#
  • DSL驱动引擎模块，避免编辑器
    • 行为树
    • 状态机
  • DSL驱动渲染管线
    • 可编程渲染管线
    • 可编程后处理脚本
• 渲染器原型
  • RHI
    • OpenGL
    • OpenGLES
    • DirectX11
    • DirectX12
    • Vulkan
  • 前向渲染
    • 场景树
    • 模型加载
    • 应用贴图
    • 基本光照
    • 基本阴影
    • 上帝相机
  • 进阶阴影优化
  • 材质编辑器
  • PBR
• 跨平台支持
  • Windows 10
  • Linux
  • Mac OS X
  • Android
  • IOS
• 游戏逻辑框架
• 脚本支持
• 物理
  • 刚体动力学
  • 碰撞检测
• 寻路
• 骨骼动画
• 多线程引擎架构
• 跨平台渲染架构
• 网络引擎
• 使用引擎完成一个游戏

RHI

OpenGL

老的接口，我选择了OpenGL，其实一开始也尝试了DX11，DX12，但是感觉负担太重了

GL则是跨平台的，接口比较简单，比较容易上手，作为起步是比较合适的

熟悉一套接口之后，就可以用现代接口了

我觉得这个过渡是不可缺少的，在短期内，GL都不会被Vulkan淘汰

初学者的角度，感觉DX12，画个Cube那么多代码，心智负担太重，跨过这道坎的人当然不觉得

OpenGL vs Vulkan

简单调查了一下，以GL和Vulkan对比为例

GL是客户端-服务端模型，GL调用很像RPC，服务端维护GL状态（但是没有属性同步，还要自己造轮子）

管线上的GL调用就像写业务逻辑一样，get/set/call，还是CURD

预编译的管线状态，是指统一设置管线状态，然后提交，这点是为了CPU并行，然后GPU同步也更复杂了

Vulkan并不优化GPU，而且优化CPU端的并行度，以及接口更加接近硬件（Bare Metal）

编辑器技术选型

使用成熟的，应用到生命周期3年+的软件的技术

有三个选择：
1. Windows WPF
2. Qt+PyQt
3. Web前端

选择WPF的理由
1. VS是WPF开发的，成熟编辑器产品
2. C#，性能和开发效率的折衷
3. 编辑器并不需要跨平台，tcp连接游戏进程进行通信
4. MMVM，自己在UI编辑器拼UI，自动界面测试，值得一学

Qt+PyQt作为备选方案，理由
1. 也是成熟的框架，可以开发所有功能，渲染也可以接OpenGL
2. C++和Python正好是两个极端，C++ 开发效率低，Python动态性太强，类型系统差，其实无法维护大型软件