Contributing to FC: Pregmod
First off, thanks for taking the time to contribute!
If there is anything you don't understand feel free to ask. Many of the more advanced tools are also not required for fixing small typos or simple bugs.
Environment
Requirements
To effectively work on the project the following tools are required:
Git
-
Node.js
or another npm client - an IDE capable of working with JavaScript, TypeScript and CSS.
VS Code
is one option. - Java Runtime Environment, minimum JRE8
Setting everything up
-
Clone the project from GitGud.io (Detailed Git setup and work cycle)
-
Open a terminal (GNU/Linux) / cmd/Powershell window (Windows) and then navigate to the
fc-pregmod
root directory viacd PATH
. e.g. Windows:cd C:\path\to\project\fc-pregmod
GNU/Linux:cd /path/to/project/fc-pregmod/
-
Run
npm install
-
Open the directory in your preferred IDE
-
Configure your IDE to use ESLint.
-
It might also be worth installing the following extensions if using VS Code: Code Spell Checker and GitLens — Git supercharged.
Compiling
While you can compile it like usual (compile.bat
/compile.sh
/make
), there is also a Gulp script
that creates
source maps for easier debugging. Other than that there are no differences between compiling for development or
compiling for playing the game.
Code
Code style
Generally the code style is based on our .eslintrc.json
. If your IDE has an auto format feature it can often read the
rules from .eslintrc.json
.
Important Rules
- use spaces after commas
- do not omit semicolons
- no empty blocks
- don't pad blocks with blank lines
- prefer strict equality/inequality
- etc.
Documentation
It's a good idea to provide meaningful documentation for new functions and classes where possible. We follow Typescript's JSDoc type dialect for the most part (and we provide a Typescript configuration and auxiliary type definition files if you'd like to use it yourself – it's pretty nifty). Don't worry too much about specific type syntax if you can't make TS work or don't understand it, someone else will probably fix it for you as long as you've made the intent clear in some form of JSDoc.
Naming conventions
- JavaScript variable and function names should be
camelCase
.
// good
let fooBar;
// bad
let foobar;
let Foobar;
let FooBar;
- JavaScript classes and namespaces should be
PascalCase
.
// good
class Foo {}
App.Foo.bar();
// bad
class foo {}
class FOO {}
App.foo.bar();
- Enum members should be
ALLCAPS
.
// good
enum Foo {
BAR = 'bar',
BAZ = 'baz',
}
// bad
enum Foo {
bar = 'bar',
Baz = 'baz',
}
This also applies to JavaScript objects that are used as enums.
// good
/** @enum {string} */
const Foo = {
BAR: 'bar',
BAZ: 'baz',
}
// bad
/** @enum {string} */
const foo = {
BAR: 'bar',
BAZ: 'baz',
}
// worse
/** @enum {string} */
const foo = {
bar: 'bar',
Baz: 'baz',
}
- CSS classes are
kebob-case
.
/* good */
.foo-bar {}
/* bad */
.fooBar {}
.FOO-BAR {}
New code should generally get organized into the App
namespace. See js/002-config/fc-init-js.js
for a rough outline.
JavaScript Features
- Avoid using very new JavaScript features
- Generally, we're currently targeting ECMAScript 2018, though we use a few widely-implemented ECMAScript 2019
features, like
globalThis
.
- Generally, we're currently targeting ECMAScript 2018, though we use a few widely-implemented ECMAScript 2019
features, like
- Conversely, do use modern features, it's not 2010 anymore and we don't try to support Internet Explorer or anything
stupid like that.
- use
let
/const
rather thanvar
- prefer fat arrow functions to inline long-form functions
- etc.
- use
Code quality
There are three main tools used to ensure good code quality, ESLint
, TypeScript Compiler (tsc)
and a custom sanity
check.
ESLint
and tsc
can be setup in most IDEs aimed at web development to show errors while editing the file.
Contributions should generally not add any new sanity check errors, and it's especially important to check this if
you're making changes to .tw files.
Use ./compile.sh --dry --sanity
or the short hand ./compile.sh -d -s
on linux or mac.
On Windows run compile_debug+sanityCheck.bat
.
It searches for common spelling errors and syntax errors in the twine files. Don't worry about preexisting
errors, it's not totally clean as is and there are a few false positives.
Project Structure
Source files
-
src/
is the main directory for source code. It also contains the embedded art files. Since it is inside aneval()
statement debugging and minification is more complicated than forjs/
. -
js/
is loaded before SugarCube and therefore outside SugarCube's eval whichsrc/
is contained in. This means accessing SugarCube features (likeSugarCube.Engine
) is more complicated however it other thansrc/
it can be minified and is easier to debug. Currently contains mainly static data, however new code not relying on SC2 should be sorted in here too. -
css/
contains all CSS files. The internal structure is explained here. -
themes/
contains custom themes which are built separately.
Dev Files
-
devNotes/
contains various wiki files and other potentially interesting files. -
devTools/
contains various scripts and executables needed for working with the project or compiling. TypeScript typing files are stored here as well. -
submodules/
contains git submodules. Only the custom version of SugarCube2 right now.
Art files
-
artTools/
contains files for creating and updating vector art. -
resources/
contains various art related files.
External Programs
-
docker/
contains Docker files from which the docker containers for GitLabs CI are created. -
FCHost/
contains the sources for FCHost. -
saveTools/
contains tools for editing save files.
Further Reading
Wiki Files
- Event Writing Guides
- Twine (Twine is being phased out of the project however the concepts are still relevant)
- JavaScript
- Exception handling
- Sanity check
- Slave List
- Pronouns
- External function documentation
- Eyes
- Limbs
- Standalone functions
- Some potentially useful JS functions
- Content embedding chart (for more details refer to !7453 (comment 118616))