Formatting only

.codecov.yml

@@ -17,4 +17,3 @@ coverage:
 comment:
   layout: "header, diff"
   behavior: default
-

.github/workflows/test.yml

@@ -8,39 +8,39 @@ jobs:
     name: Run tests
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@v2
-    - name: Set up Python
-      uses: actions/setup-python@v2
-      with:
-        python-version: '3.10'
-    - name: Cache dependencies
-      uses: actions/cache@v2
-      with:
-        path: ~/.cache/pip
-        key: ${{ runner.os }}-pip-${{ hashFiles('dev-requirements.txt') }}
-    - name: Install dependencies
-      run: |
-        python -m pip install --upgrade pip
-        pip install -r https://raw.githubusercontent.com/Dallinger/Dallinger/issues/5330-websocket-updates/dev-requirements.txt
-        pip install -r dev-requirements.txt
-    - name: Install dallinger
-      run: |
-        pip install git+https://github.com/Dallinger/Dallinger.git@issues/5330-websocket-updates#egg=dallinger[docker]
-    - name: Install experiment
-      run: |
-        pip install -e .[dev]
-    - name: Start dallinger services as docker containers
-      run: dallinger docker start-services
-    - name: Run pytest
-      run: pytest --junit-xml=test-results.xml
-    - name: Surface failing tests
-      if: always()
-      uses: pmeier/pytest-results-action@main
-      with:
-        path: test-results.xml
-        summary: true
-        display-options: fEX
-        fail-on-empty: true
+      - uses: actions/checkout@v2
+      - name: Set up Python
+        uses: actions/setup-python@v2
+        with:
+          python-version: "3.10"
+      - name: Cache dependencies
+        uses: actions/cache@v2
+        with:
+          path: ~/.cache/pip
+          key: ${{ runner.os }}-pip-${{ hashFiles('dev-requirements.txt') }}
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install -r https://raw.githubusercontent.com/Dallinger/Dallinger/issues/5330-websocket-updates/dev-requirements.txt
+          pip install -r dev-requirements.txt
+      - name: Install dallinger
+        run: |
+          pip install git+https://github.com/Dallinger/Dallinger.git@issues/5330-websocket-updates#egg=dallinger[docker]
+      - name: Install experiment
+        run: |
+          pip install -e .[dev]
+      - name: Start dallinger services as docker containers
+        run: dallinger docker start-services
+      - name: Run pytest
+        run: pytest --junit-xml=test-results.xml
+      - name: Surface failing tests
+        if: always()
+        uses: pmeier/pytest-results-action@main
+        with:
+          path: test-results.xml
+          summary: true
+          display-options: fEX
+          fail-on-empty: true
 
   pre-commit:
     runs-on: ubuntu-latest

.pre-commit-config.yaml

@@ -1,30 +1,29 @@
 repos:
+  - repo: https://github.com/psf/black
+    rev: 23.7.0 # update with `pre-commit autoupdate`
+    hooks:
+      - id: black
+        language_version: python3 # Should be a command that runs python3.6+
+        files: ^(test|dlgr|demos)/|setup.py
 
-- repo: https://github.com/psf/black
-  rev: 23.7.0 # update with `pre-commit autoupdate`
-  hooks:
-    - id: black
-      language_version: python3 # Should be a command that runs python3.6+
-      files: ^(test|dlgr|demos)/|setup.py
-
-- repo: https://github.com/PyCQA/flake8
-  rev: '6.0.0'
-  hooks:
-  - id: flake8
-- repo: https://github.com/pycqa/isort
-  rev: 5.12.0
-  hooks:
-    - id: isort
-      args: ["--profile", "black", "--filter-files"]
-- repo: https://github.com/pre-commit/pre-commit-hooks
-  rev: v4.4.0
-  hooks:
-    - id: check-yaml
-- repo: local
-  hooks:
-    - id: compile-js
-      name: Update JS build
-      entry: "bash -c '( yarn run build && git add dlgr/griduniverse/static/scripts/dist ) || exit 1'"
-      language: system
-      files: "\\.js$"
-      pass_filenames: false
+  - repo: https://github.com/PyCQA/flake8
+    rev: "6.0.0"
+    hooks:
+      - id: flake8
+  - repo: https://github.com/pycqa/isort
+    rev: 5.12.0
+    hooks:
+      - id: isort
+        args: ["--profile", "black", "--filter-files"]
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    hooks:
+      - id: check-yaml
+  - repo: local
+    hooks:
+      - id: compile-js
+        name: Update JS build
+        entry: "bash -c '( yarn run build && git add dlgr/griduniverse/static/scripts/dist ) || exit 1'"
+        language: system
+        files: "\\.js$"
+        pass_filenames: false

QUICKSTART.md

@@ -2,9 +2,9 @@
 
 This is a guide to get up and running with **GridUniverse** quickly. The guide assumes that you have the following software installed in your system:
 
- - Git.
- - Docker.
- - Python 3.8 or higher.
+- Git.
+- Docker.
+- Python 3.8 or higher.
 
 ## Installation
 
@@ -18,6 +18,7 @@ For now, to work on the new One Hour One Life version, you need to specifically
     $ git checkout one-hour-one-life
 
 ### Create virtual Python environment
+
 It is recommended to install all requirements into a Python virtual environment, so that your installation is self-contained and does not affect your system Python installation. To create one inside the **Griduniverse** directory, type the following:
 
     $ python -m venv venv
@@ -28,10 +29,10 @@ After this, you can activate the new `venv`, which will set up the shell to use
 
 ## Running GridUniverse in development mode
 
-Now that the environment is set up,  use `pip` from the new `venv` to install Griduniverse:
+Now that the environment is set up, use `pip` from the new `venv` to install Griduniverse:
+
+    $ pip install -e .
 
-    $ pip install -e . 
-
 ### Starting support services
 
 **Dallinger** experiments require a `PostgreSQL` database service to be available for saving experiment data. The easiest way to get one going is to use **Dallinger's** `Docker` support. You need to install the Python `docker` package into the`venv` first:
@@ -68,32 +69,33 @@ There are two separate configuration files that can be modified to set up the ex
 
 This file includes general **Dallinger** configuration options. For **GridUniverse**, the most important options are:
 
-| Option | Meaning |
-|--|--|
-| max_participants | Number of participants in the game |
-| num_rounds | How many rounds of game play will be run |
-| time_per_round | Length of each round in seconds |
+| Option           | Meaning                                  |
+| ---------------- | ---------------------------------------- |
+| max_participants | Number of participants in the game       |
+| num_rounds       | How many rounds of game play will be run |
+| time_per_round   | Length of each round in seconds          |
 
 ### GridUniverse `game_config.yml` file
 
 This file is well documented, so take a look at it to see the different options first. The most important high level concepts to understand the configuration are `items` and `transitions`. The easiest way to add your own game configuration is to start with the default configuration and change/copy items as needed.
 
 #### Items
-Items represent the objects available in the game. They can represent for example food, food sources, tools, or obstacles. They are the resources that the players need to obtain to get points. The most important item properties are:
 
-| Property | Description |
-|--|--|
-| item_id | Each item definition must include a unique item_id. |
-| item_count | How many instances of this item should the world initially include? |
-| calories | How many calories does a single instance provide when a player consumes it? |
-| interactive | Does a player need to explicitly interact with this item via the action button? |
-| n_uses | How many times can the item be used/consumed? |
-| name | Friendly name of the item that may be displayed to players. |
-| portable | Whether this item be picked up and carried to another location by the player. |
-| sprite | Visual representation of this item in the UI. This value can be any of a color, a Unicode emoji, or an image URL |
+Items represent the objects available in the game. They can represent for example food, food sources, tools, or obstacles. They are the resources that the players need to obtain to get points. The most important item properties are:
 
+| Property    | Description                                                                                                      |
+| ----------- | ---------------------------------------------------------------------------------------------------------------- |
+| item_id     | Each item definition must include a unique item_id.                                                              |
+| item_count  | How many instances of this item should the world initially include?                                              |
+| calories    | How many calories does a single instance provide when a player consumes it?                                      |
+| interactive | Does a player need to explicitly interact with this item via the action button?                                  |
+| n_uses      | How many times can the item be used/consumed?                                                                    |
+| name        | Friendly name of the item that may be displayed to players.                                                      |
+| portable    | Whether this item be picked up and carried to another location by the player.                                    |
+| sprite      | Visual representation of this item in the UI. This value can be any of a color, a Unicode emoji, or an image URL |
 
 #### Transitions
+
 Items are affected by `transitions`. A transition is usually initiated by a player and can change an object in various ways. For example, a rock can be turned into a tool by using a larger rock to shape it. This transition would happen when a player is holding a rock and stands on top of a large rock, producing a sharp rock that can be used as a tool. Other examples include turning a plant into an actual edible fruit or taking one fruit from a fruit tree. The most important transition properties are:
 | Property | Description |
 |--|--|
@@ -102,7 +104,6 @@ Items are affected by `transitions`. A transition is usually initiated by a play
 | target_end | item_id for the item that will exist in the player's grid block after the transition has executed. |
 | target_start | item_id for the item that must exist at the player's current position in order to execute the transition |
 
-
 ## Deploying the experiment using Docker
 
 To deploy the experiment you can use **Dallinger's** `Docker` support. First, add the following section to the `config.txt` file:
@@ -122,11 +123,11 @@ Once the image is built, you can try it out on the browser with this command:
 
 To deploy it to a server under your control, it's necessary to provision a server first. The server needs to be set up according to **Dallinger's** specifications. In particular:
 
- -  Ports 80 and 443 should be free (**Dallinger** will install a web server and take care of getting SSL certificates for you).
- -  `ssh` should be configured to enable passwordless login.
- -  The user on the server needs passwordless `sudo`.
+- Ports 80 and 443 should be free (**Dallinger** will install a web server and take care of getting SSL certificates for you).
+- `ssh` should be configured to enable passwordless login.
+- The user on the server needs passwordless `sudo`.
 
-Once the server is ready, the next step is to tell **Dallinger** about it. Assume the variable `$SERVER_USER` holds the user configured for `ssh` access to the server, and `$SERVER_HOSTNAME_OR_IP` holds the address of this server. To add it to the list of **Dallinger** servers, run this command: 
+Once the server is ready, the next step is to tell **Dallinger** about it. Assume the variable `$SERVER_USER` holds the user configured for `ssh` access to the server, and `$SERVER_HOSTNAME_OR_IP` holds the address of this server. To add it to the list of **Dallinger** servers, run this command:
 
     $ dallinger  docker-ssh  servers  add  --user  $SERVER_USER  --host  $SERVER_HOSTNAME_OR_IP