<li><span class=mundane>sound effects, visual effects, responsive game with feedback </span> </li>
</ul>
</ul>
<h2>1.0 - release </h2>
<h2>1.98 - involve other people (obv review after every milestone) </h2>
<ul>
<ul>
<li><span class=mundane>feature: improvements based on suggestions</span> </li>
<li><span class=mundane>playtesting - diverse playtesters like colorblind, French keyboard users, different res/older computers, etc</span> </li>
<li><span class=mundane>maintain my community - forums, Discord, Twitter, any forums tied to store platforms, etc</span> </li>
<li><span class=mundane>press - YouTubers, Twitch streamers, bloggers, game journalists, local news, etc. I'll def reach out to Godot's showcase. </span> </li>
<li><span class=mundane>festivals/contests - local conventions, Godot con, Indie Games Expo, PAX, GDC. I'll seriously consider a booth/panel at the cons in my town. </span> </li>
<li><span class=mundane>funding - kickstarter, etc (no reason not to try. Even if I can finish the game in my freetime, I can set it up to cover fees then set wild stretch goals like getting Trigger to do my animations or hiring my favorite voice actor and composer or something)</span> </li>
</ul>
<h2>1.99 - release </h2>
<ul>
<li><span class=mundane>feature: store pages</span> </li>
<li><span class=mundane>support as many input devices as possible, though this probably isn't an XBOX controller-friendly game. keyboard, mouse, touchscreen, voice commands</span> </li>
<li><span class=mundane>support as many input devices as possible, though this probably isn't an XBOX controller-friendly game. keyboard, mouse, touchscreen, voice commands</span> </li>
<li><span class=mundane>get input from colorblind people</span> </li>
<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>
chimchooree
2 years ago