一种Godot项目组织形式

近来启动了一个小型项目，完全采用 godot 3的引擎，旨在验证并探索一个完整游戏开发过程中的模块实现。 为了未来这个项目仍然具备一定的价值，需要一种项目组织形式，以对未来的重构和复用保留灵活性。特此记录个人观点，以便于日后反思修正。

1. 核心思想：

以每个场景的根节点为最小单位，划分独立的文件夹。每个场景文件夹尽可能的拥有独立的assets文件夹，以保留自己的美术资源。

2.根本诉求：

在脱离godot内置编辑器的情况下，可以在操作系统的文件资源理器内以文件夹为单位重新创建新项目作为试验或者复用的沙盒。

3.缺点和优点：

a. 缺点：无法全局管理项目资产
b. 优点：无论是谁，无论开发者自己是否记得住项目组织逻辑，总是可以从一个文件夹入手

4.一些细节应对：

• a. 允许出现一些以分类为目，或是保存基类为目的的文件夹，比如enemy下保有concreteEnemy1，concreteEnemy2文件夹，后两者才是最小组织单位，但是他们可以被放置于一个分类文件夹enemy下（enemy也可能就是他们的基类）。
• b. 如何组织godot的特有资源文件格式tres？与外部的资源文件不同，godot可以保存一种tres格式的资源文件。因其特殊性，建议在每个模块文件夹下单独创建tres文件夹保存他们。所谓tres指的是‘text resource’， 这些配置参数原本内嵌于场景文件中，比如animationPlayer，比如dynamic font， 而godot又允许直接将这些文本形式的内容单独保存成资源文件以方便复用，就有了tres格式，因此tres格式是将“文本配置”视作“资源”的格式，因其特殊性，我希望将他与一般外部资产分离，故选用单独文件夹保存。
• c. 关于模块内资产划分的建议： Texture, Script, Mesh, Animation, AudioStream, Font, Translation等等。

5. 实践增补：

font

fontData文件应与dynamicFont文件紧密放置

godot中接受ttf/otf格式的字体文件作为数据来源,利用名为fontData的容器来描述这个文件的位置。 fontData可被用于名为dynamicFont的抽象容器，后者可以决定如何渲染这个字体,dynamicFont是可作为节点属性直接使用的最小单位。他们关系紧密，后者依赖于前者在资源管理系统上的相对路径。因此他们应总是放置在一起而不应单独修改增删。

dynamicFont 编辑视图一览

dynamicData 编辑视图一览

目录结构例子

<my_scene_folder>
├─font
│      ArchivoNarrow-Regular.otf
│      dfont_AN_regular.tres
│
├─S1_text_by_anim
│      popup_text_by_anim.gd
│      popup_text_by_anim.tscn
│
├─S2_text_by_tween
│      popup_text_by_tween.gd
│      popup_text_by_tween.tscn
│
└─scene_test
        popup_text_test_a.gd
        popup_text_test_a.tscn

参考：

1. [YouTube] 6 Tips to Better Organize your Godot 3 Projects
2. [GodotDocs] Resources