Skip to content

Future-R/DOLFishing

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Degrees of Lewdity

Lexicon of Lewdity

Looking to contribute to Degrees of Lewdity? Read the Lexicon of Lewdity.

Failure to do so can lead to your work being denied.

How to build

Changing the build version and type

  1. Open 01-config\sugarcubeConfig.js.
  2. Edit the window.StartConfig object to the relevant config type.
    • Normal Build - enableImages needs to be true and enableLinkNumberify needs to be true.
    • Text Only Build - enableImages needs to be false and enableLinkNumberify needs to be true.
    • Android Build - enableImages needs to be true and enableLinkNumberify needs to be false.
  3. version is optional between release versions but will be displayed on screen in several places and stored in the saves made.
  4. debug is optional and will only effect new games.

Compiling the html

  1. On Windows: Run compile.bat or compile-watch.bat.
  2. On Linux: Run compile.sh
  3. Open Degrees of Lewdity VERSION.html.

Build Android version (.apk)

See mobile-build.md

Development

Prerequisites

Optional Prerequisites

  1. Install Tweego and remember the path where it was installed.
  2. Add path to tweego.exe (e.g. C:\Program Files\Twine\tweego-2.1.0-windows-x64) to Windows Path environment variable.

Initial setup

  1. Install project dependencies:

    npm i
  2. If you use Visual Studio Code:

    1. Install Twee 3 Language Tools extension

    2. Install ESLint extension.

    3. Install Stylelint extension

    4. Install and configure Code Spell Checker extension:

      1. Use "English - United Kingdom" and "English - United States" dictionaries
      2. Enable spellchecking fortwee3-sugarcube-2, markdown, javascript and other programming languages
    5. Optionally enable fixing js/css on save. In settings.json set:

      // This disables built-in formatting
      "[javascript]": {
        "editor.formatOnSave": false
      },
      "[css]": {
        "editor.formatOnSave": false
      },
      // This enables running ESLint, Prettier, Stylelint formatting on file save
      "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true,
        "source.fixAll.stylelint": true
      },
      

Linting

JavaScript

JavaScript code linting is handled by ESLint.

ESLint is configured to follow some of best practices (ESLint Recommended Rules, JavaScript Standard Style) with formatting handled by Prettier (eslint --fix formats code with Prettier). You don't need to use Prettier VS Code extension to format .js files.

To run ESLint for single file:

npx eslint "game/03-JavaScript/02-Helpers/Utils.js"

or for all files inside game directory:

npx eslint "game/**"
Resolving issues

Some issues are fixable and can be auto-fixed when you save a file (provided ESLint extension is configured to run fix on save) or by running eslint --fix file_relative_path

If you find a rule that doesn't make sense for the project you can disable it inside rules section inside .eslintrc.cjs:

rules: {
  ...
  // SugarCube extends native objects and we follow it
  "no-extend-native": "off",
  ...
}

Please discuss the reasons with the team before disabling the rule. Add a comment explaining why the rule was disabled

If ESLint reports a lot of issues for particular file and you cannot fix them all at once feel free to disable particular rule for the file (there is quick actions menu when code with error is hovered):

/* eslint-disable camelcase -- TODO: Fix variables' names */
...
let demo_rainbow_colors = [
...

Add a TODO comment explaining that this will be fixed someday

Global variables

ESLint may report a issue like 'myVariable' is not defined. It means ESLint cannot figure out where the variable is defined. If you really meant to make variable global add the new variable to .eslintrc.cjs globals section inside corresponding group:

myVariable: "readonly"

If the variable is suppose to be writable set myVariable: "writable" instead.

CSS

CSS linting is handled by Stylelint.

Stylelint is configured to follow common conventions along with rules for properties order and formatting handled by Prettier (stylelint --fix formats code with Prettier). You don't need to use Prettier VS Code extension to format .css files.

To run Stylelint for the file:

npx stylelint "game/02-CSS/pillsInventory.css"

or for all CSS file inside game directory:

npx stylelint "game/**/*.css"

Resolving issues

Some issues are fixable and can be auto-fixed when you save a file (provided Stylelint extension is configured to run fix on save) or by running stylelint --fix file_relative_path.

Sometimes all issues cannot be fixed within single "fix" run (e.g. properties order). Simply run fix command several time until all auto-fixable issues are resolved.

If you find a rule that doesn't make sense for the project you can disable it inside rules section inside stylelint.config.cjs:

rules: {
  // Class and ID patterns disabled for now due to the large amounts of classes and IDs that break this rule
  "selector-class-pattern": null,
  "selector-id-pattern": null,
  ...
}

Please discuss the reasons with the team before disabling the rule. Add a comment explaining why the rule was disabled

Formatting

Formatting CSS and other non-JavaScript file is handled by Prettier. Formatting rules are set in .prettierrc.json

Pre-commit hook

On pre-commit lint-staged using husky lints/formats .js, .css with ESLint, Stylelint and formats other supported files with Prettier.

Pre-commit hook is the last quality gate to avoid "bad" code getting into the repository. It's better to make sure you aren't committing files with issues beforehand - you can run command npm run lint-staged when you've staged the files to check if there are issues.

If for some reason you really want to commit the code that fails linting add --no-verify parameter to commit call

commit --no-verify