Follow this style guide to avoid confusing bugs. Code doesn't always need to
follow the style guide, but a comment needs to be left by the offending code
explaining why it's necessary. The guide is not set in stone, and can be
disputed and altered.
(many parts written by my husband)
Node paths should be treated as though they have private access. Any node
within a scene can be thought of as within scope of that scene. Nodes higher in
the tree or inside instanced scenes are out of scope of the current scene.
However, the root of an instanced scene is within scope, so a path to that is
safe. Using an "out of scope" node path will result in null pointer exceptions
at best or confusing bugs at worse if a scene's structure is ever altered.
Add methods to the root of a scene that does whatever is needed to the nodes
inside.
If a property is needed from a node inside a scene, a getter in the
scene's root can return the value its child node's property. (see Setters and
Getters)
It's fair for a script to depend on a consistent internal tree structure.
Only scripts inside a scene may alter the structure of its own tree. The tree's
structre is primarily altered by adding or removing children. Adding or
removing child nodes higer than the scene's root, or inside instanced scenes,
will cause inconsistent structure. Without this guideline, each scene would
need to constantly validate its own structure to be sure it hasn't been altered
by another script.
Add methods to the root of a scene that can add or remove children. These
methods can keep track of which nodes have been added or removed, so the
script can be aware of any changes to the scene's structure.
Often, some action always needs to be taken whenever a variable is changed.
Putting these actions in a setter method for that variable ensure that they're
always executed. If a setter is not made for a variable, there's some risk
that it may be changed without those actions being taken, and the source of
the change may be difficult to track.
Furthermore, a variable may not exist at all, but be derived from some
computation. In that case, a getter can create the illusion of a single
variable.
One more benifit, is that a setter can be deferred called or connected to a
signal, since its a method.
Variables can be changed to use getters and setters seamlessly, since they're
used no differently from variables that don't have getters and setters. If
there is a need to take some action whenever a value is set, a setter can be
added to it seamlessly.
add a fake language from the start
pausing
time control (every variable affected by time must be modified by time control)
decouple drawing and logic
Write the game by writing unit tests then passing all the tests. Run the unit tests again after making a change.
Commonly, this means making a base, then loading in the game as a mod. The content is written in a light scripting language, and it's best if I use the same API/tools a modder would.
Commonly, this means making a base, then loading in the game as a mod. The content is written in a light scripting language, and it's best if I use the same API/tools a modder would.