project_organization.rst 4.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133
  1. .. _doc_project_organization:
  2. Project organization
  3. ====================
  4. Introduction
  5. ------------
  6. This tutorial is aimed to propose a simple workflow on how to organize
  7. projects. Since Godot allows the programmer to use the file-system as he
  8. or she pleases, figuring out a way to organize the projects when
  9. starting to use the engine can be a little challenging. Because of this,
  10. a simple workflow will be described, which can be used or not, but
  11. should work as a starting point.
  12. Additionally, using version control can be challenging so this
  13. proposition will include that too.
  14. Organization
  15. ------------
  16. Other game engines often work by having an asset database, where you can
  17. browse images, models, sounds, etc. Godot is more scene-based in nature
  18. so most of the time the assets are bundled inside the scenes or just
  19. exist as files but are referenced from scenes.
  20. Importing & game folder
  21. -----------------------
  22. It is very often necessary to use asset importing in Godot. As the
  23. source assets for importing are also recognized as resources by the
  24. engine, this can become a problem if both are inside the project folder,
  25. because at the time of export the exporter will recognize them and
  26. export both.
  27. To solve this, it is a good practice to have your game folder inside
  28. another folder (the actual project folder). This allows to have the game
  29. assets separated from the source assets, and also allows to use version
  30. control (such as svn or git) for both. Here is an example:
  31. ::
  32. myproject/art/models/house.max
  33. myproject/art/models/sometexture.png
  34. myproject/sound/door_open.wav
  35. myproject/sound/door_close.wav
  36. myproject/translations/sheet.csv
  37. Then also, the game itself is, in this case, inside a game/ folder:
  38. ::
  39. myproject/game/engine.cfg
  40. myproject/game/scenes/house/house.scn
  41. myproject/game/scenes/house/sometexture.tex
  42. myproject/game/sound/door_open.smp
  43. myproject/game/sound/door_close.smp
  44. myproject/game/translations/sheet.en.xl
  45. myproject/game/translations/sheet.es.xl
  46. Following this layout, many things can be done:
  47. - The whole project is still inside a folder (myproject/).
  48. - Exporting the project will not export the .wav and .png files which
  49. were imported.
  50. - myproject/ can be put directly inside a VCS (like svn or git) for
  51. version control, both game and source assets are kept track of.
  52. - If a team is working on the project, assets can be re-imported by
  53. other project members, because Godot keeps track of source assets
  54. using relative paths.
  55. Scene organization
  56. ------------------
  57. Inside the game folder, a question that often arises is how to organize
  58. the scenes in the filesystem. Many developers try asset-type based
  59. organization and end up having a mess after a while, so the best answer
  60. is probably to organize them based on how the game works and not based
  61. on asset type. Here are some examples.
  62. If you were organizing your project based on asset type, it would look
  63. like this:
  64. ::
  65. game/engine.cfg
  66. game/scenes/scene1.scn
  67. game/scenes/scene2.scn
  68. game/textures/texturea.png
  69. game/textures/another.tex
  70. game/sounds/sound1.smp
  71. game/sounds/sound2.wav
  72. game/music/music1.ogg
  73. Which is generally a bad idea. When a project starts growing beyond a
  74. certain point, this becomes unmanageable. It's really difficult to tell
  75. what belongs to what.
  76. It's generally a better idea to use game-context based organization,
  77. something like this:
  78. ::
  79. game/engine.cfg
  80. game/scenes/house/house.scn
  81. game/scenes/house/texture.tex
  82. game/scenes/valley/canyon.scn
  83. game/scenes/valley/rock.scn
  84. game/scenes/valley/rock.tex
  85. game/scenes/common/tree.scn
  86. game/scenes/common/tree.tex
  87. game/player/player.scn
  88. game/player/player.gd
  89. game/npc/theking.scn
  90. game/npc/theking.gd
  91. game/gui/main_screen/main_sceen.scn
  92. game/gui/options/options.scn
  93. This model or similar models allows projects to grow to really large
  94. sizes and still be completely manageable. Notice that everything is
  95. based on parts of the game that can be named or described, like the
  96. settings screen or the valley. Since everything in Godot is done with
  97. scenes, and everything that can be named or described can be a scene,
  98. this workflow is very smooth and easygoing.
  99. Cache files
  100. -----------
  101. Godot uses a hidden file called ".fscache" at the root of the project.
  102. On it, it caches project files and is used to quickly know when one is
  103. modified. Make sure to **not commit this file** to git or svn, as it
  104. contains local information and might confuse another editor instance in
  105. another computer.