本文系用户投稿，不代表机核网观点
明年会看到Jonathan Blow 的新作《沉星之序》(Order of the Sinking Star),
1 / 2
记得在《见证者》发布那会他吐槽用C++这类通用编程语言用的想死，之后他产生了一个这样的想法
Ideas about a new programming language for games.
他要自研编程语言。
《沉星之序》可能就是他的实践结果。 时间关系我没太深入他那个Jai语言，但在一次访谈中看到了一个看上去非常像ECS架构思想，产生了兴趣，
“任何游戏都可以归结为一个for循环，并且重点是如何组织simulate()”，我在我的IG02项目中 使用过ECS的思想(实例，组件，系统)进行解耦，已经感受到好的框架对项目持续开发的好处。乍眼一看它这像是类似的东西，可能甚至会觉得只是ECS之下的脚本组织习惯。直到我把它尝试接入到IG04时，才发现这事好像没那么简单。
//接入Unity
input指输入，并且只投射所有外力(基本指玩家)对simulate的影响。simulate作为游戏系统的模拟负责接受变化并进行验算结果。而渲染指的不是我们常接触的渲染管线，指的是负责包括任何对simulate最终验算结果的呈现部分。 这是很泛的东西，不是一个程序架构，实际上是一个比较针对游戏的设计思想，用这个结构 Jonathan 把游戏从引擎中剥离出来了。采访中他也表示，不管你用的是什么引擎，什么语言，你的游戏系统不该依赖它们。 实话讲，我被这句话搞懵了，脱离引擎能理解，脱离语言是什么意思？
把“游戏”从表现层剥离出来的思维刀法 。 游戏的灵魂不在屏幕上，而在时间里
正因为simulate()作为你的游戏黑箱，需要的是构建“约定”，这就像从纸面上设计游戏一样，世界、你、我、他、物、游戏规则123，这些东西都只需要结构和数学就能表示和模拟，跟本用不到那么多引擎级的封装，大多数语言、引擎语言封装的函数都过于累赘，它的一部分能对你的呈现起到帮助，但对抽象的设计层这些基本都没什么意义。具体说，也就是如果你在unityC#中，simulate层最好不需要using UnityEngine ,甚至可以不需要Class，用结构体和一些基本的数学函数根据输入进来的dt步长就能够模拟出游戏的抽象，甚至是可回溯的(时间是恒定的，没有多线程这类的并行)。而实例化、渲染这些都是后面render层的业务，这里才会涉及到大量依赖，才真正需要技术沉淀的力量。
当试着这么做后，虽然感觉这一下子似乎失去了很多，有些底层的必要需要自己封装，但我的系统却神奇的变强了。结构化的设计对应结构体的代码，代码本身就是设计文档。它没有强依赖，变得可移植，也天然适应服务器架构。 这样，引擎和编程语言的知识变成了更高级的对呈现的追求，而真正考虑实现游戏规则的运行就是一个个纯粹的数学问题了。
评论区
共 条评论热门最新