req, style
chimchooree
3 years ago
parent
f747925c80
commit
08e79978da
@ -0,0 +1,107 @@
|
||||
% rebase('frame.tpl')
|
||||
<div class="content-grid">
|
||||
<div class="">
|
||||
<h1>style guide </h1>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<p>(many parts written by my husband) <br></p>
|
||||
<br>
|
||||
<h2>node paths </h2>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<p>Add methods to the root of a scene that does whatever is needed to the nodes
|
||||
inside. <br></p>
|
||||
<br>
|
||||
<p>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) <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li>don't use node paths to nodes higher than the scene's root </li>
|
||||
<li>don't use node paths into instanced scenes </li>
|
||||
<li>do add methods to the root of a scene that manipulates the inner nodes </li>
|
||||
</ul>
|
||||
<h2>child nodes </h2>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li>don't add child nodes to nodes higher than the scene's root </li>
|
||||
<li>don't add child nodes to instanced scenes </li>
|
||||
<li>do add methods to the root of a scene for adding or removing children </li>
|
||||
</ul>
|
||||
<h2>setters + getters </h2>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<p>One more benifit, is that a setter can be deferred called or connected to a
|
||||
signal, since its a method. <br></p>
|
||||
<br>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li>setters can execute any action when a property is changed </li>
|
||||
<li>setters can be added seamlessly, without changing how the property is set </li>
|
||||
</ul>
|
||||
<h2>serialization </h2>
|
||||
<p> <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li> </li>
|
||||
</ul>
|
||||
<h2>translations </h2>
|
||||
<p>add a fake language from the start <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li> </li>
|
||||
</ul>
|
||||
<h2>documentation </h2>
|
||||
<p> <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li> </li>
|
||||
</ul>
|
||||
<h2>time </h2>
|
||||
<p>pausing <br></p>
|
||||
<p>time control (every variable affected by time must be modified by time control) <br></p>
|
||||
<p>decouple drawing and logic <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li> </li>
|
||||
</ul>
|
||||
<h2>moddability </h2>
|
||||
<p>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. <br></p>
|
||||
<br>
|
||||
<ul>
|
||||
<li> </li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
Loading…
Reference in New Issue