83 lines
3.6 KiB
ReStructuredText
83 lines
3.6 KiB
ReStructuredText
.. _doc_instancing_continued:
|
|
|
|
Instancing (continued)
|
|
======================
|
|
|
|
Recap
|
|
-----
|
|
|
|
Instancing has many handy uses. At a glance, with instancing you have:
|
|
|
|
- The ability to subdivide scenes and make them easier to manage.
|
|
- A more flexible alternative to prefabs (and much more powerful given that
|
|
instances can be nested).
|
|
- A way to organize and embed complex game flows or even UIs (in Godot, UI
|
|
Elements are nodes, too).
|
|
|
|
Design language
|
|
---------------
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
For example, here's how a simple shooter game could be imagined:
|
|
|
|
.. image:: img/shooter_instancing.png
|
|
|
|
It's pretty easy to come up with a diagram like this for almost any kind
|
|
of game. Just 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:
|
|
|
|
.. image:: img/openworld_instancing.png
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Information overload!
|
|
---------------------
|
|
|
|
This has been a lot of high level information dropped on you all at once.
|
|
However, the important part of this tutorial was to create an awareness of how
|
|
scenes and instancing are used in real projects.
|
|
|
|
Everything discussed here will become second nature to you once you start
|
|
making games and putting these concepts into practice. For now, don't worry
|
|
about it too much, and just go on to the next tutorial!
|