Skip to content

Commit

Permalink
Formatting only
Browse files Browse the repository at this point in the history
  • Loading branch information
jessesnyder committed May 21, 2024
1 parent aa7ff6a commit a9407c9
Show file tree
Hide file tree
Showing 23 changed files with 2,754 additions and 2,584 deletions.
1 change: 0 additions & 1 deletion .codecov.yml
Original file line number Diff line number Diff line change
Expand Up @@ -17,4 +17,3 @@ coverage:
comment:
layout: "header, diff"
behavior: default

66 changes: 33 additions & 33 deletions .github/workflows/test.yml
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
55 changes: 27 additions & 28 deletions .pre-commit-config.yaml
Original file line number Diff line number Diff line change
@@ -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
55 changes: 28 additions & 27 deletions QUICKSTART.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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
Expand All @@ -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:
Expand Down Expand Up @@ -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 |
|--|--|
Expand All @@ -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:
Expand All @@ -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

Expand Down
Loading

0 comments on commit a9407c9

Please sign in to comment.