.            ★.        . blessfrey.me ..          ☆        .

style guide

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

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)


child nodes

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.


setters + getters

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.


serialization



translations

add a fake language from the start


documentation



time

pausing

time control (every variable affected by time must be modified by time control)

decouple drawing and logic


unit testing

Write the game by writing unit tests then passing all the tests. Run the unit tests again after making a change.