instancing_continued.rst 3.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
  1. .. _doc_instancing_continued:
  2. Instancing (continued)
  3. ======================
  4. Recap
  5. -----
  6. Instancing has many handy uses. At a glance, with instancing you have:
  7. - The ability to subdivide scenes and make them easier to manage.
  8. - A tool to manage and edit multiple node instances at once.
  9. - A way to organize and embed complex game flows or even UIs (in Godot, UI
  10. Elements are nodes, too).
  11. Design language
  12. ---------------
  13. But the greatest strength that comes with instancing scenes is that it works
  14. as an excellent design language. This distinguishes Godot
  15. from all the other engines out there. Godot was designed from the ground up
  16. around this concept.
  17. When making games with Godot, the recommended approach is to dismiss most
  18. common design patterns, such as MVC or Entity-Relationship diagrams, and
  19. instead think about your scenes in a more natural way. Start by imagining the
  20. visible elements in your game, the ones that can be named not just by a
  21. programmer, but by anyone.
  22. For example, here's how a simple shooter game could be imagined:
  23. .. image:: img/shooter_instancing.png
  24. You can come up with a diagram like this for almost any kind
  25. of game. Write down the parts of the game that you can visualize, and then
  26. add arrows to represent ownership of one component by another.
  27. Once you have a diagram like this, the recommended process for making a game is
  28. to create a scene for each element listed in the diagram. You'll use instancing
  29. (either by code or directly in the editor) for the ownership relationships.
  30. A lot of time spent in programming games (or software in general) is on
  31. designing an architecture and fitting game components to that architecture.
  32. Designing based on scenes replaces that approach and makes development much
  33. faster and more straightforward, allowing you to concentrate on the game logic
  34. itself. Because most game components map directly to a scene, using a design based on scene instantiation means little other architectural code is needed.
  35. Let's take a look at one more, somewhat more complex, example of an open-world
  36. type game with lots of assets and nested elements:
  37. .. image:: img/openworld_instancing.png
  38. Take a look at the room element. Let's say we started there. We could make a
  39. couple of different room scenes, with different arrangements of furniture (also
  40. scenes) in them. Later, we could make a house scene, connecting rooms to make
  41. up its interior.
  42. Then, we could make a citadel scene, which is made out of many instanced
  43. houses. Then, we could start working on the world map terrain, adding the
  44. citadel onto it.
  45. Later, we could create scenes that represent guards (and other NPCs) and add
  46. them to the citadel as well. As a result, they would be indirectly added to the
  47. overall game world.
  48. With Godot, it's easy to iterate on your game like this, as all you need to do
  49. is create and instance more scenes. Furthermore, the editor UI is designed to be user
  50. friendly for programmers and non-programmers alike. A typical team development
  51. process can involve 2D or 3D artists, level designers, game designers,
  52. and animators, all working with the editor interface.
  53. Information overload!
  54. ---------------------
  55. This has been a lot of high level information dropped on you all at once.
  56. However, the important part of this tutorial was to create an awareness of how
  57. scenes and instancing are used in real projects.
  58. Everything discussed here will become second nature to you once you start
  59. making games and putting these concepts into practice. For now, don't worry
  60. about it too much, and go on to the next tutorial!