Instancing has many handy uses. At a glance, with instancing you have:
The ability to subdivide scenes and make them easier to manage.
A tool to manage and edit multiple node instances at once.
A way to organize and embed complex game flows or even UIs (in Godot, UI Elements are nodes, too).
实例化有许多方便的用途
①细分场景的能力,使它们更易于管理
②一种同时管理和编辑多个节点实例的工具
③一种组织和嵌入复杂游戏流甚至UI元素的方法(在godot中,ui元素也是节点)
But the greatest strength that comes with instancing scenes is that it works as an excellent design language. This is pretty much what distinguishes Godot from all the other engines out there. Godot was designed from the ground up around this concept.
但是,来自于实例化场景的最大作用是它作为优秀的设计语言工作。这正是godot区别于所有其他引擎的原因,godot是围绕这个概念设计的。
When making games with Godot, the recommended approach is to dismiss most common design patterns, such as MVC or Entity-Relationship diagrams, and instead think about your scenes in a more natural way. Start by imagining the visible elements in your game, the ones that can be named not just by a programmer, but by anyone.
用godot制作游戏时,推荐的方法是放弃大多数常见的设计模式,如MVC或实体关系图,而是用更自然的方式思考你的场景,从想象你游戏中的可见元素开始,那些元素不仅可以被程序员命名,更可以被任何人命名。
For example, here’s how a simple shooter game could be imagined
You can come up with a diagram like this for almost any kind of game. Write down the parts of the game that you can visualize, and then add arrows to represent ownership of one component by another.
你可以在几乎任何类型的游戏中想出这样的图表,写下你可以想象的游戏部分,然后添加箭头表示一个组件与另一个组件的所有权关系。
Once you have a diagram like this, the recommended process for making a game is to create a scene for each element listed in the diagram. You’ll use instancing (either by code or directly in the editor) for the ownership relationships
一旦你有像这样的图表,制作游戏的推荐过程是为图表中列出的每个元素创建一个场景,您会使用实例化(无论是代码还是直接在编辑器中)
A lot of time spent in programming games (or software in general) is on designing an architecture and fitting game components to that architecture. Designing based on scenes replaces that approach and makes development much faster and more straightforward, allowing you to concentrate on the game logic itself. Because most game components map directly to a scene, using a design based on scene instantiation means little other architectural code is needed.
在编写游戏程序或通用软件中花费的大量时间,用在设计一个体系结构并将游戏组件装配到那个架构上。
基于场景的设计取代传统方法,使开发更快更直接,让你专注于游戏逻辑本身。
因为大多数游戏组件直接映射到场景中,使用基于场景实例化的设计意味着需要很少的代码构建。
Let’s take a look at one more, somewhat more complex, example of an open-world type game with lots of assets and nested elements
让我们再看另一个例子,稍微复杂一些,具有大量资产和嵌套元素的开放世界型游戏示例。
Take a look at the room element. Let’s say we started there. We could make a couple of different room scenes, with different arrangements of furniture (also scenes) in them. Later, we could make a house scene, connecting rooms to make up its interior
看看room元素,假设我们从那里开始,我们可以用不同的家具布置(也是场景),制作几个不同的房间场景。之后,我们可以做一个房子的场景,连接房间以弥补房子的内部。
Then, we could make a citadel scene, which is made out of many instanced houses. Then, we could start working on the world map terrain, adding the citadel onto it.
然后,我们可以制作一个城堡场景,该城堡由许多实例化房子建造而成。之后,我们可以开始在加上城堡的世界地图上工作
Later, we could create scenes that represent guards (and other NPCs) and add them to the citadel as well. As a result, they would be indirectly added to the overall game world.
我们可以创建代表警卫的场景(或者别的npc)也添加进城堡里,最终,它们将被间接地添加到整个游戏世界中
With Godot, it’s easy to iterate on your game like this, as all you need to do is create and instance more scenes. Furthermore, the editor UI is designed to be user friendly for programmers and non-programmers alike. A typical team development process can involve 2D or 3D artists, level designers, game designers, and animators, all working with the editor interface.
使用godot,像这样重复你的游戏是很容易的,您需要做的是创建和实例化更多场景。
此外,编辑器UI被设计成对程序员和非程序用户友好,一个典型的团队开发过程可以涉及2D或3D,平面设计师、游戏设计师和动画师,所有的工作与编辑器接口一起。